https://virgool.ir/feed/@hossein.zolfifa2026-11-12 03:27:26https://files.virgool.ir/upload/users/83531/avatar/srNW5u.pnghttps://virgool.ir/@hossein.zolfihttps://virgool.ir/@hossein.zolfi/مسابقه-ابربازی-و-پیادهسازی-یک-کامپایلر-ساده-با-go-r07lsrcnim1jhttps://www.arvancloud.com/fa/abrbaziامروز در مسابقه #ابربازی شرکت کردم. مسابقه چالشی و قشنگی بود.دوست داشتم بعد از دو سه سال دوباره خودم رو در یک مسابقه جدی محک بزنم. به این خاطر شرکت کردم.قبلا دو بار در مسابقه فن‌آورد شرکت کرده بودم و در مسابقه اول زبان برنامه‌نویسی‌ام پایتون بود و دوم شده بودم.که کدهای مسابقه در گیت‌هاب موجود است.کدهای مسابقه امروز رو هم روی گیت‌هاب قرار دادم.الان دوست دارم که خودم رو در این مسابقه تحلیل کنم.انتخاب زبان برنامه‌نویسیاستفاده از Goدر این مسابقه از زبان‌برنامه‌نویسی Go استفاده کردم. زبان Go مثل پایتون ساده است مدیریت خطای کارائي داره و static type است. تجربه‌ام از مسابقات می‌گه که عموما لازم نیست که خیلی خوب کد بنویسید؛ گرچه من همیشه سعی می‌کنم به بهترین شکل کد بنویسم و از کدنویسی لذت ببرم. مفاهیم شی‌گرائي در Goبیائید یکی از سوالات رو به صورت مختصر بررسی کنیم. در این سوال می‌خواهیم یک برنامه‌ی کوچیک بنویسیم که خط‌های یک زبان مختصر رو parse و اجرا کنه.دستورات مثل زیر هستندنمونه ورودی سوال دومزبان Go به سادگی پایتونه و کد اضافه زیادی هم نمی‌شه توش نوشت. مثلا قطعه کد زیر رو ببینیم هر کدوم از خط‌های بالا رو می‌گیره و یک Statement ازشون می‌سازه.پارس کردن هر یک دستورات ورودی کد بالا رو می‌شه از چیزی هست هم بهتر نوشت، اما وقت مسابقه بیشتر از این اجازه نمی‌ده.اما اجازه بدید که یک گام این کد رو بهبود بدیم. می‌شه به راحتی از دست switch-case خلاص شیم، مشکلی که داره که اگر بخواهیم یک دستور جدید اضافه کنیم باید کدش رو دست بزنیم. یعنی کد Open–closed principle رو رعایت نکرده.مرحله۱: اعمال OCP و حذف switch- caseتعداد خط از کد قبل کمتر نشد، اما می‌شه با یک گام بهبود، به یک کد بهتر رسید. ببینید که چقدر ساده یک نوع جدید تعریف کردیم به نام Parser. باز اشکالی که در مورد کد قبل گفتم رو باز داره. هنوز نیاز داریم که کد درونی رو عوض کنیم.مرحله۲: اعمال OCP و حذف switch- caseنتیجه‌ی پایانی، ساده، مختصر و زیباست. مگه زیباتر از این هم می‌شه. زبان Go به راحتی هر چه ساده‌تر اجازه می‌ده یک type جدید تعریف کنیم و type ها هم overhead حافظه ندارند و می‌شه رو این type ها متد جدید (در اینجا متد Parse) تعریف کرد.این بحث رو همین‌جا ببندیم سراغ یک خصوصیت زیبای دیگه Go بریم و اون هم استفاده از interface هاست.استفاده از Interface به عنوان Contract در Goبه نظرم interface در Go همون چیزیه که در زبان‌های برنامه‌نویسی بهش قرارداد (contract) می‌گیم و خیلی خوب پیاده‌سازی شده.من فقط یک interface در برنامه داشتم.یک اینترفیس ساده با Goاین interface کارم رو جواب داد اما بی‌ایراد نیست چون واقعا دلیل نداره که همه دستورات مقدار داشته باشند. بگذریم (بهبود دم دستی اینه که متد Eval چیزی بر نگردونه، اما همین بهبود روی خیلی از قسمت‌های دیگه تاثیر می‌ذاره که فعلا به این تاثیر نیاز ندارم)همین interface ساده یک حرف ساده رو هم می‌زنه هر چیزی که بخواد یک Statement باشه باید یک متد به نام Eval داشته باشه و یک int64 برگردونهمثلا یک عدد ساده یک Statement است و به صورت ضمنی interface مورد نظرمون رو پیاده‌سازی کرده.تعریف یک struct برای نگهدارییک دلیلی که Value رو به Eval پاس دادم این بود که بتونم باهاش مقدار متغییرها رو بدست بیارم. خیلی ساده به صورت زیر می‌شه یک متغییر رو تعریف کرد.تعریف یک struct برای نگهداری متغییرها (مثلا برای متغییر a)دستوری که مقدار متغییرها رو عوض می‌کنه دستور assign بود، که یک جمع ساده است (به همین خاطر حالت خیلی ساده در نظر گرفتمش)تعریف یک struct برای دستور به فرمت out = op1 + op2مدیریت خطا در Goیکی از زیبایی‌های Go مفهوم error handling اش است. که باز به نظرم به طراحی دلچسب‌تر برنامه خیلی کمک می‌کنه و عملا باعث می‌شه خطای احتمالی از زیر دستمون در نره.مثلا از کد بالاتر، قسمت زیر رو ببینیممدیرت خطا در Go به صورت سادهدر اینجا اگر ورودی دستوری باشه که هیچ کاریش نمی‌تونیم بکنیم panic می‌دیم. می‌شه از log.Fatalf هم استفاده کنم اما همین panic ساده برام کافی بود. یک نمونه‌ی دیگرش در parse کردن یک رشته و تبدیل اون به Number استفاده کردم. به نظرم با این نوع از مثال‌ها مشخص می‌شه که چقدر برنامه‌نویسی با Go خیال آدم رو راحت می‌کنه و آدم رو برنامه کنترل خیلی بهتری می‌تونه داشته باشه.نمونه‌ای از parse کردن یک رشته عددی و تبدیل آن به Numberکد می‌تونست به صورت زیر نوشته بشه و بعد خطا رو توی لایه بالاتر مدیریت کرد. اما لایه بالاتر هم عملا کاری نمی‌تونست انجام بده، پس همون panic رو زدم و بقیه رو هم راحت کردم.بهبود parse یک رشته‌ی عددیهمین مدیریت خطای ساده، جلوی یک سری اشتباهات رو از سمت برنامه‌نویس می‌گیره. چون من با یک پیش‌فرض‌هایی کد نوشتم که ممکنه اشتباه باشه. اما همون پیش‌فرض‌ها رو چک کردم. حالا اگر همین کد رو بر روی یک ورودی درست اجرا کنم و خطا بگیریم یعنی پیش‌فرضم در اونجائی که خطا داده اشتباه بوده و باید برم تصحیحش کنم. اما اگر چنین مکانیزمی نداشته باشم، باید خیلی وقت رو debug کردن بذارم و با سعی و خطا برنامه رو ببرم جلو.اما بریم سراغ بعد غیر فنی.نحوه‌ی پاسخ‌دهیاولین بار بود که Quera مسابقه می‌دادم، برام خیلی جالب بود. مسابقه پنچ تا سوال داشت.در این مسابقه چندتا ضعف داشتم.اولین ضعفی که داشتم در تحلیل دقیق و سریع سوالات بود که به نظرم رسید نمی‌تونم خیلی سریع سوالات رو تحلیل کنم، ۵ تا سوال بود هر سوال به صورت میانگین باید ۳۶ دقیقه زمان می‌برد.این زمان باید صرف چند تا کار می‌شد. خواندن و درک سوالتحلیل ورودی و خروجیپیدا کردن راه‌حل مناسبپیاده‌سازی نرم‌افزاریتست و اجراطبق قاعده اگر راه‌حل مناسب داشتیم مساله حل شده است اما در عمل اینطور نیست. جواب باید در فضا و زمان مناسب هم جواب بدهد. مثلا نباید بیشتر از ۲ ثانیه طول بکشه یا بیشتر از ۲۵۶ مگ رم مصرف کنه. اما فرض کنیم که برنامه‌مون عالیه. مشکل دیگر اینه که باید بشه ورودی‌هایی که برنامه را گیر می‌اندازه رو هم پیدا کنیم.من در قسمت ۲ موارد بالا، ضعف داشتم و این ضعف در جوابی که quera بر گردوند کاملا مشخص بود.نمونه خروجی ارسال شده از سمت کوئرایکی دیگر از مشکلاتم درک کردن سوال بود، وقتی سوال رو نشه درک کرد، نمی‌توان آن‌را حل کرد. مثلا یکی از سوال‌ها ۵ صفحه PDF بود و طولانی بودن صورت سوال، تاثیر منفی رو ذهنم گذاشت.اشکال دیگر، مدیریت استرس بود. در حل سوال دوم، زمان زیادی صرف شد. تا حدی مدیریتش کردم اما باز فشار ذهنی داشت.جمع‌بندیهدفم از مسابقه به چالش کشیدن خودم بود. آشنا شدن با نقاط ضعف و قوت خودم هدف دیگرم بود. از این جهت، از مسابقه‌ای که دادم راضی هستم.جا داره از سایت کوئرا بخاطر پلتفرم خوبشون و از ابرآروان به خاطر برگزاری مسابقه هم تشکر کنم.در پایان مشتاق شدم که در مسابقات دیگر هم شرکت کنم و تا کمک کنه که خودم رو بیشتر و بهتر محک بزنم.Hossein ZolfiHossein ZolfiSat, 16 May 2020 00:28:58 +0430https://virgool.ir/@hossein.zolfi/چالش-ذهنی-برای-جایگزینی-یک-متن-با-استفاده-از-vim-dzxury39pv9rImage: http://amzn.to/2umsBaY طرح مسالهبرای انجام کاری نیاز داشتم، که قسمتی از متن که به حالت CamelCase بود را به حالت snake_case تبدیل کنم. مانند متن شکل زیرمتن اولیهو می‌خواستم نتیجه‌ی کارم به صورت شکل زیر بشه.متن نهائیتعداد تغییرات به نسبت زیاد بود و عملا به صورت دستی انجام دادنش هم زمان‌بر بود و هم احتمالش زیاد بود که اشتباه کنم.راستش بهینه بودن کار چندان برام اهمیتی نداشت. فقط می‌خواستم کارم انجام بشه و مطلبی یاد بگیرم که در آینده باز بتونم از دانشش استفاده کنم.ویرایشگر متنی که استفاده می‌کنم ابزار Vim است.روش‌هایی ابتدائی این بود که از ابزارهای خارج از ویرایشگر (مثل sed, python و golang) استفاده کنم. این راهی بود که چندین بار قبل‌ترها استفاده کرده بودم اما مزه‌ی ماندن در محیط ویرایشگر برام بیشتر بود و اینکه اگر یاد بگیرم که چطور این کار رو انجام بدهم، تا هم به کیفیت کارم کمک کنه و هم اینکه کارم رو خیلی سریع‌تر انجام بده.خیلی روش‌های مختلفی رو تست کردم، اینجا تنها روشی که بهش رسیدم رو می‌نویسم.گام اول پیدا کردن CamelCase هانیاز دارم که کلمه‌ای مانند FilesAppended رو به کلمه‌ی مثل files_appended تبدیل کنم. پس اول این رشته‌ها رو پیدا می‌کنم. از Regular Expression برای پیدا کردن رشته‌ها استفاده کردم.طبق شکل اول بدست آوردن متن چندان سخت نیست.کافیه تمام رشته‌هایی که با jmx شروع می‌شن و تا " می‌رسن رو بندازم دور، بعد تمام رشته‌هایی که به [ ختم می‌شوند رو نگه داریم، که می‌شه عبارت زیر. برای تستش می‌تونید به این صفحه مراجعه کنید.jmx.+",(.+)\]گام دوم تبدیل CamelCase به snake_caseمرحله دوم این است که متنی که پیدا می‌شه رو با متن دلخواهمون جایگزین کنیم. با کمی سرچ تو اینترنت، دنبال اسکریپتی گشتم که CamelCase رو به snake_case تبدیل کند، که به اسکریپت زیر رسیدم و من هم این اسکریپت رو توی یک فایل دخیره (camel_to_snake.sh) کردم که بتونم صداش بزنم (احتیاط کنید تو دریای تفسیر کردن خط زیر غرق نشید، من خودم هم زیاد ازش سر در نیاوردم، البته نیازی هم نداشتم. همین که کارم رو انجام داد برام کافی بود).متن کد تبدیل CamelCase به snake_caseنتیجه اجرا یک چیزی شبیه به این می‌شه (همون چیزی که می‌خواستم)نتیجه‌ی اجرا برنامه بر روی متن نمونهگام آخر: اعمال تغییراتدر محیط Vim با زدن کلید Colon (:) ‌یک خط فرمان، مثل زیر در Vim باز می‌شه که از طریقش می‌شه یک متن رو با متن دیگه جایگزین کرد. مثلا در اینجا وقتی بخواهیم Hadoop رو با HBase جایگزین کنم کافیه متن زیر رو تایپ کنم و صفحه مثل شکل بعدش نمایش داده می‌شه:%s/Hadoop/Hbase/gcجایگزین کردن یک متن با متن دیگر در Vimبرگردیم به مسئله خودم. اما اگر بخواهیم به جای اینکه با یک متن جایگزین باشه اول یک دستوری روی متن اول اجرا کنه و خروجی دستور جایگزین بشه، کافیه بعد از / دومی به صورت زیر بنویسیم. مثلا در مثال زیر تمام کلمات Hadoop با خروجی دستور date جایگزین می‌شوند.:%s/Hadoop/\=system("date")/gcالان تقریبا به انتهای کار رسیدیم و مجروح آماده است. کافیه که اسکریپتی که پیدا کردیم روی کل متن صدا بزنیم. به صورت زیر اجرا می‌کنیم.نوشتن دستور برای جایگزین کردن متندستور بالا از دو قسمت تشکیل شده یک قسمت همون الگوییه که دنبالش بودیم. قسمت دوم هم دستوریه که روی متن‌های پیدا شده صدا زده می‌شه (و یک ستاره * کنار خروجی دستور هم قرار می‌ده).که بعد از enter زدن اولین خط رو به صورت زیر تغییر می‌ده و بقیه رو هم به همین شکل یا زدن کلید a اعمال می‌کنیم.جایگزین کردن متن با خروجی دستوردر این مرحله دو تا دستور به استفاده کردم. یکی system و دیگری submatch است. دستور system یک دستور سیستمی رو اجرا می‌کنه. دستور submatch هم گروهی که match شده رو بر می‌گردونه. که عدد داخلش 1 یعنی گروه اول و عدد 0 به معنی تمام متنیه که پیدا شده.جمع‌بندیدر این مطلب، با استفاده از امکانات یک ویرایشگر، جایگزینی یک متن با یک متن رو به صورت تقریبا خودکار انجام دادم. این کار شاید دستی بودنش یک خرده بیشتر زمان می‌برد اما چیزی که مهمه اینه که عادت بهبود مستمر رو در خودمون زنده نگه داریم و نکته‌ی دیگه اینکه یاد بگیریم که به صورت مستمر یاد بگیریم. در کارهای ساده هم می‌توان خلاقیت زد و به صورت مستمر ذهن رو به چالش کشید.راستش، من فکر نمی‌کنم هدف اصلی ما در زندگی یادگیری باشه، هدف رساندن ارزش به کسانی است که با ما در ارتباط هستند (از جمله خودمون)، یادگیری و رشد مداوم تنها ابزاری هستند که به ما کمک می‌کنند ارزش بیشتری به اطرافیانمون برسانیم.تا یادم نرفته بگم که کدها رو می‌تونید از این gist بردارید و در این صفحه می‌تونید متن Regular expression رو تست کنید.خوشحال می‌شم که در کامنت بهمون بگید که شما این مساله رو چطور حل می‌کنید و راه‌حل پیشنهادی شما چیست.Hossein ZolfiHossein ZolfiWed, 29 Apr 2020 10:53:24 +0430https://virgool.ir/SahabPardaz/ایدهای-جسورانه-برای-بالا-نگهداشتن-سرویس-قسمت-دوم-r57j7g455vfmدر مقاله‌ی قبل به این نکته اشاره کردم که در تیم SRE گام اول برای بالا نگهداشتن سرویس نرم‌افزاری، ثابت نگه داشتن نسخه‌های آن نرم افزار است. در این مقاله به این مبحث بیشتر می‌پردازم.چرا نسخه‌ی برنامه‌ها را ثابت کنیم!؟فرض کنید بخواهیم بر روی کلاستر، تغییراتی اعمال کنیم. جهت اعمال این تغییرات، از یک سری اسکرپیت‌ها استفاده می‌شود. این اسکریپت‌ها وظیفه‌ی تنظیم (config) و نصب سرویس‌ها را به عهده دارند. ثابت نگه‌داشتن نسخه‌ی برنامه و وابستگی‌هایش در زمان اجرای این اسکریپت‌ها، مزایای متعددی دارد که از جمله‌ی آن‌ها می‌توان به موارد بعدی اشاره نمود:سرویس ها از یک اجرای اسکریپت به اجرای دیگر، از یک ماشین به ماشین دیگر و از یک زمان به زمان دیگر، یکسان رفتار خواهند کرد.در صورت بروز مشکل در حین یا بعد از اجرای اسکریپت‌ها، فضای مسئله محدود و یافتن راه‌حل، ساده‌تر می شود. به این دلیل که با متغیرهای کمتری سروکار داریم.تنها سرویسی تغییر وضعیت می‌دهد که وابستگی‌ها و تنظیماتش تغییر کرده باشد. در غیر اینصورت سرویس دچار تغییر نشده و بالا می‌ماند.سوالی که ایجاد می‌شود این است که چطور محیط و نسخه‌ی برنامه‌ها را ثابت نگه داریم؟ قبل از پاسخ به این سوال، ابتدا باید بدانیم که نسخه‌سازی معنایی چیست.نسخه‌سازی معنایی (Semantic Versioning)جهت شماره‌گذاری نسخه‌ی برنامه، از نسخه‌سازی معنایی استفاده می‌کنیم؛ که به صورت Major.Minor.Patch (مانند ورژن ۲.۳.۵) بیان می‌شود.به بیان ساده‌تر هر تغییر، در بردارنده‌ی یکی از سه حالت کلی زیر است:تغییراتی در کد داده شده است که باعث اختلال در سرویس‌دهی می‌شوند -تغییر با نسخه قبل سازگار نیست- در این صورت، مقدار Major یک عدد بالاتر می‌رود. مانند ۳.۰.۰بهبودی در کد داده شده است. در این صورت، مقدار Minor یک عدد بالاتر می‌رود. مانند ۲.۴.۰یک باگ ساده رفع شده است. در این صورت، مقدار Patch یک عدد بالاتر می‌رود. مانند ۲.۳.۶لازم به ذکر است اگر مقدار Major یا Minor افزایش پیدا کند؛ اعداد پائین‌تر صفر می‌شود. برای نمونه، با بالا رفتن مقدار Major در نسخه ۲.۳.۵ شماره نسخه به صورت ۳.۳.۵ بالا نرفت، بلکه به صورت ۳.۰.۰ تغییر یافت.نسخه‌سازی معنایی، جهت سازگار بودن نسخه‌ها بیان شده است و بالاتر رفتن عددها معنای دیگری ندارد.چطور نسخه‌ی برنامه‌ها را ثابت نگه‌داریم؟برای این‌که به درک بهتری از ثابت شدن نسخه‌ها برسیم؛ اجازه دهید ابزارها را با یک سرویس پایتونی معرفی کنم.ثابت کردن پایتوناز آنجایی‌که نسخه‌ی پایتون از یک سیستم به سیستم دیگر، متفاوت است؛ پس باید ابتدا نسخه‌ی پایتون را ثابت نگه داریم. برای تعیین نسخه‌ی پایتون از ابزار Pyenv استفاده می‌کنیم.به عنوان نمونه، فرض کنید می‌خواهیم برای یکی از پروژه‌هایمان از نسخه‌ی ۳.۶.۶ پایتون استفاده کنیم. ابزار Pyenv گام‌های ذیل را انجام می‌دهد:نسخه‌ی پایتون را از فایل python-version می‌خواند.سورس کد پایتون را دانلود می‌کند.پایتون مورد نظر را می‌سازد (build می‌کند).متغیرهای محیطی را تنظیم می‌کند تا کد‌های آن پروژه، با نسخه‌ی پایتونی که تعیین شده است؛ اجرا شوند.ثابت کردن وابستگی‌ها (Dependencies)برای ثابت کردن نسخه‌ی ماژول‌ها هم از ابزار Pipenv استفاده می‌کنیم. ابزار Pipenv با استفاده از دو فایل Pipfile و Pipfile.lock‌ نسخه‌ی ماژول‌های مورد نیاز پروژه را ثابت (fix) می‌کند.ثابت کردن برنامه در حال توسعهجهت تعیین نسخه برنامه‌ی در حال توسعه‌، از نسخه‌سازی معنایی استفاده می‌شود.بعد از ثابت کردن سه مولفه‌ی پایتون، وابستگی‌ها و کد، مزایای گفته شده در مورد ثابت کردن نسخه‌ها، حاصل خواهد شد.مدیریت تغییرات (Change Management)در قسمت قبل توضیح داده شد که چگونه مولفه‌های مورد نظرمان را ثابت نگه داریم. اطلاعات مربوط به ثابت نگه‌داشتن نسخه‌ها، باید در جایی ثبت شوند. بدین‌ منظور از سیستم‌های Version Control مانند Git استفاده می‌کنیم.به عنوان نمونه، فایل‌های Pipfile ، Pipfile.lock و python-version را در Git ذخیره می‌کنیم.استفاده از ابزارهایی مانند Git مزایایی دارد:به ما این امکان را می دهد که ببینیم چه کسی و به چه علتی تغییر را اعمال کرده است.تغییرات، توسط شخص یا گروه، بازبینی (review) می‌شود و از زاویه دیدهای مختلفی به تغییرات نگاه می‌شود و افراد دیگر هم از این تغییر مطلع می‌شوند.علت خطاهایی که بعد از اجرای اسکریپت‌ها در کلاستر روی می‌دهد؛ راحت‌تر پیدا می‌شوند. فرض کنید سرویسی که در حال اجرا در کلاستر بود؛ هم اکنون دچار اختلال شده است. با توجه به تاریخچه‌ی تغییرات، علت خرابی راحت‌تر پیدا می‌شود.مهاجرت (Migration)برای تغییر یک سرویس از یک وضعیت به وضعیت دیگر از اسکریپت های Migration استفاده می‌کنیم.در این‌صورت، سرویس به نسخه جدید مهاجرت کرده و اجرای متوالی اسکرپیت‌ها، تغییری در وضعیت سرویس ایجاد نمی‌کنند.آیا باید برنامه‌نویس را در استفاده از ابزار محدود کنیم!؟‌قطعا خیر. توسعه‌دهنده‌ها باید در استفاده از سیستم‌های نرم‌افزاری آزاد باشند. مثلا توسعه دهنده باید آزادانه سیستم‌عامل خود را اعم از Ubuntu یا CentOS یا Manjaro یا هر سیستم‌عامل دیگری -البته به جزWindows- انتخاب کند.جمع بندی و نکته‌ی پایانیدراین مقاله توضیح داده شد که برای این‌که ناخواسته یک سرویس از حالت سرویس‌دهی خارج نگردد نیاز داریم:نسخه‌ی برنامه‌ها به صورت Semantic Versioning مدیریت شود.تغییرات در Version Control قرار گرفته، بازبینی و تست شوند.با مکانیزم درست مانند فرآیند Migration این تغییرات در کلاستر اعمال شود.از ابزارهایی استفاده کنیم که تا وقتی ورودی تغییر نکرده، سرویس‌ها تغییر نکنند.سعی بر این بود که با توجه به آنچه در این مطلب و در مطلب پیشین ارائه شد؛ بتوانیم از کار افتادن ناخواسته ی سرویس جلوگیری کنیم.Hossein ZolfiHossein ZolfiSat, 18 Jan 2020 11:09:42 +0330https://virgool.ir/SahabPardaz/ایدهای-رادیکالی-برای-بالا-نگهداشتن-سرویس-قسمت-اول-rph4bphznx8wبالا نگهداشتن سرویس‌های نرم‌افزاری، یکی از چالش‌های شیرین کاری است. به روش‌های مختلفی می‌توان اطمینان حاصل کرد که سرویس‌های نرم‌افزاری همیشه بالا هستند و بالا می‌مانند.در این مطلب به بیان قسمت دوم می‌پردازم، چطور اطمینان حاصل کنیم که سرویس‌های نرم‌افزاری [با اعمال تغییرات] بالا می‌مانند.ساده‌ترین روش این است که به سرویس در حال کار، دست نزنیم. اما این رویکرد یک رویکرد قدیمی است و در عمل مشکلات فراوانی دارد. رویکرد ما در تیم پایدار، کاملا خلاف این است.اگر می‌ترسید کاری که انجام می‌دهید؛ باعث خرابی می‌شود و به همین دلیل دست روی دست گذاشته‌اید؛ پس حتما به سراغش بروید و انجامش دهید.یک ایده به نسبت رادیکال و جسورانه!شاید این پرسش به ذهنتان خطور کند که "چرا باید اینکار را انجام دهیم؟" جواب را با یک مثال نسبتاً ساده بیان می‌کنم.فرض کنید یک سرور پایگاه داده دارید که زمان زیادی است که ری‌استارت نشده است و شما از ری‌استارت کردن آن می‌ترسید چون ممکن است بعد از ری‌استارت کردن؛ بالا نیاید یا باعث خرابی در سرویس‌های دیگر شود.به دلایل مختلف ممکن است دنیای واقعی با فرضیات شما جور نباشد. چه اتفاقی می‌افتد که به هر دلیل سیستم خراب شود (مانند برق رفتن، از کار افتادن یوپی‌اس، اشتباه انسانی و به روزرسانی اشتباه، خطاهای سخت‌افزاری و نرم‌افزاری، اجبار در اعمال باگ‌های امنیتی، به روزرسانی سیستم‌عامل توسط گروهی دیگر) در این صورت معلوم نیست که سرویس مورد نظر، بالا بیاید و معلوم نیست چقدر زمان ببرد تا سرویس مجددا پایدار شود.حالا فرض کنید، با استفاده از روش‌هایی (که در مطالب آتی به آن اشاره خواهم کرد) می‌توان از این معضل رهایی جست.اما تا آن موقع، اجازه دهید که یک روش بسیار ساده را بیان کنم: مشخص کردن دقیق ورژن برنامه‌هایی که در سرویس‌ها استفاده می‌شود و و ثابت نگهداشتن نسخه‌ی برنامه. به عنوان نمونه برای یک سرویس پایتون موارد ذیل حائز اهمیت است:مشخص کردن دقیق نسخه پایتون مثلاً ۳.۸.۰ماژول‌های پایتون مثلاً انسیبل ۲.۷.۱۲سیستم‌عاملی که پایتون بر روی آن نصب می‌شود مثلا اوبونتو ۱۶.۰۴.۶تعیین دقیق پکیج‌های مورد استفاده در سیستم های سیستم‌عاملقطع ارتباط با اینترنت یا شبکه‌های دیگربرای هر کدام از موارد فوق می‌توان مکانیزم‌های مختلفی ارائه داد که در قسمت دوم این مقاله، به تعدادی از آن‌ها اشاره کرده‌ام.اما این موارد تنها یک قسمت از ماجراست. قسمت مهم دیگر، راه اندازی مکانیزم‌های نرم افزاری است که روش ساده فوق را حمایت کند. ثابت نگهداشتن نسخه‌ی نرم افزار بدون داشتن این مکانیزم‌ها کمی ملال آور است. در مطالب آتی به این پرسش پاسخ خواهم داد که از چه طریق می‌توان اطمینان حاصل کرد که روش فوق واقعاً کار کند و در روز مبادا جواب‌گو باشد. با مشکل مواجه نمی‌شود و در عمل کاراست و کار می‌کند.برگردم به این سوال که "چگونه اطمینان حاصل کنیم که یک سرویس نرم افزاری با انجام تغییرات، بالا می‌ماند و ناخواسته از کار نمی‌افتد؟"گام اول ثابت نگهداشتن وابستگی‌ها، سپس تغییر نسخه‌ی وابستگی‌ها به صورت کاملا تست شده و کنترل شده است. در مورد مکانیزم‌های دیگر خواهم نوشت.Hossein ZolfiHossein ZolfiTue, 24 Dec 2019 13:56:29 +0330