ترس غیرمنطقی از استقرار

قطعی اخیر مربوط به CrowdStrike بر 8.5 میلیون سیستم عامل ویندوز تأثیر گذاشت و منجر به اختلال در خدمات مختلف جهانی از جمله خطوط هوایی و بیمارستان ها شد. تحلیل های متعدد علت اصلی این حادثه را بررسی کرده است.

با این حال، به‌عنوان یک مهندس نرم‌افزار، من فکر می‌کنم که ما جنبه احساسات انسانی مربوط به استقرار، به‌ویژه ترس از شکستن تولید را از دست داده‌ایم. این چیزی است که ما سعی خواهیم کرد در این مقاله به آن بپردازیم. پوشش خواهیم داد:

• درک عملکرد مهندسی انتشار.
• مهندسان نرم افزار به چه چیزهایی اهمیت می دهند و به چه چیزهایی اهمیت نمی دهند.
• تاثیر تحویل مداوم (CD).
• نگاهی به استقرار دستی.
• مشکلات استقرار دستی و راه حل این مشکلات.

مهندسی انتشار

قبل از بررسی ترس از استقرار از دیدگاه یک مهندس نرم افزار، اجازه دهید ابتدا نقش یک مهندس آزاد را درک کنیم.

مهندسی انتشار به لطف ابزارهای مدرن CI و CD و استانداردسازی Kubernetes در سال های اخیر به طور قابل توجهی تکامل یافته است. با وجود این پیشرفت‌ها، مسئولیت‌های اولیه یکسان باقی می‌ماند:

• استقرار مداوم و تکرارپذیر: استاندارد کردن فرآیندهای انتشار، خطر استقرار بد در تولید را کاهش می دهد.

• کاهش اختلالات خدمات: فرآیندهای استاندارد همچنین تضمین می‌کند که تیم‌ها برای مقابله با حوادث مضر محیط تولید تجهیز شده‌اند – به عنوان مثال، یک استراتژی بازگشت برای سناریوهایی که انتشار باعث ایجاد مشکل می‌شود.

• نظارت و بهینه سازی عملکرد: به دنبال بهبود عملکرد برای استقرار سریعتر و قابل اطمینان باشید.

• همکاری با مهندسی: با توسعه دهندگان، تیم‌های QA و DevOps همکاری نزدیک داشته باشید تا اطمینان حاصل کنید که همه سرویس‌های جدید و موجود دارای فرآیند استقرار به خوبی تعریف شده هستند.

آنچه مهندسان نرم افزار به آن اهمیت می دهند

برخلاف مهندسان انتشار، به عنوان یک مهندس نرم افزار که در تیم محصول کار می کند، ممکن است فقط به جنبه های خاصی از استقرار اهمیت دهیم:

• ادغام کدهای سریع: ادغام سریع به آنها اجازه می دهد تا کار خود را تأیید کنند و به کارهای جدید بروند یا کارهای وابسته را رفع انسداد کنند.

• حوادث تولید: اگرچه ممکن است مهندسان به همه حوادث تولید اهمیتی ندهند، اما قطعاً به تغییرات کد آنها که باعث قطعی تولید می شود اهمیت می دهند.

• برنامه استقرار: مهندسان همچنین دوست دارند تغییراتشان را ردیابی کنند که چه زمانی فعال می‌شوند یا زنده می‌شوند تا بتوانند به بازخورد بلادرنگ تغییرات خود دسترسی داشته باشند.

چیزی که مهندسان نرم افزار به آن اهمیت نمی دهند

اگرچه چیزهایی وجود دارد که ما به آنها اهمیت می دهیم، مواردی نیز وجود دارد که ما به آنها اهمیت نمی دهیم:

• روش استقرار: اگرچه ما نیاز به یک فرآیند استقرار کارآمد و قابل اعتماد را می دانیم، اما برای آنها اهمیتی ندارد که چگونه انجام شود.

• تأثیر سایر تغییرات: ما نگران تغییرات نامرتبط سایر توسعه دهندگان نیستیم، مگر اینکه همه چیز اشتباه شود.

• مدیریت استقرار: یک مهندس نسبت به مدیریت استقرار در یک تیم نرم افزاری بی تفاوت است. به عنوان مثال، ما فقط در صورتی به مدیریت استقرار اهمیت می دهیم که این کار را انجام دهیم.

تأثیر استقرار مداوم (CD)

بنابراین ترس چه ربطی به استقرار مداوم دارد؟

خیلی

مطالعات چندین مزیت استقرار مداوم (CD) را ثابت کرده‌اند، و جای تعجب نیست که بسیاری از آنها ماهیت روان‌شناختی دارند. استقرار مداوم “انسان در حلقه” را حذف می کند، بنابراین نیاز به اعتماد قوی در زیرساخت آزمایش دارد.

به عبارت دیگر، تست های خودکار نه تنها قابلیت اطمینان تولید را تضمین می کنند، بلکه ایمنی روانی را نیز فراهم می کنند، گاهی اوقات به طور غیرمنطقی، ترس از استقرار را کاهش می دهند. به‌عنوان یک توسعه‌دهنده، در مقابل اگر از من خواسته شود تغییرات را به‌صورت دستی تأیید کنم، راحت‌تر می‌توانم تغییراتی را در فرآیند CD ایجاد کنم.

با این حال، علی‌رغم محبوبیت این استراتژی‌های CD، بسیاری از شرکت‌ها هنوز به صورت دستی استقرار را آغاز می‌کنند (یک انسان در حلقه دارند)، که نشان‌دهنده رویکرد محتاطانه برای پیاده‌سازی CD است. این رفتار نشان می‌دهد که تیم‌ها ترجیح می‌دهند بر روند انتشار نظارت داشته باشند و در صورت لزوم مداخله کنند.

درک این موضوع از منظر ایمنی روانی مهم است. استقرار دستی به این معنی است که شخصی بر فرآیند نظارت دارد و در صورت بروز مشکل، مشکلات را مدیریت می کند. در حالی که این احساس امنیت را فراهم می کند، می تواند ترس را در فرد مستقر ایجاد کند و مستعد خطای انسانی است.

استقرار دستی

با وجود معایب، اکثر تیم ها استقرارها را به صورت دستی مدیریت می کنند. یک استقرار دستی معمولی ممکن است شامل چند مرحله باشد:

نظارت

قبل از اینکه نسخه منتشر شود، شخصی تمام مراحل استقرار را نگه می‌دارد. این فرد موظف است در صورت وجود علائم مشکل مداخله کند. تیم‌ها یک فرد آماده را نگه می‌دارند که استقرار آنها را مدیریت می‌کند و در صورت بروز مشکلات، آن‌ها را مدیریت می‌کند.

تیم های اختصاصی انتشار

برخی از تیم‌ها دارای یک تیم مهندسی انتشار اختصاصی هستند که تضمین می‌کند نسخه‌ها بدون مشکل پیش می‌روند. از آنجایی که این به معنای درجه بالایی از تخصص است، فرآیند استقرار می تواند کارآمدتر و قابل اعتمادتر باشد.

صفحات گسترده

برخی از شرکت‌ها صفحه‌گسترده‌ای را برای تأیید هرگونه تغییر ایجاد شده نگهداری می‌کنند. این به شرکت ها اجازه می دهد تا به طور سیستماتیک این تغییرات را بررسی و تأیید کنند و اطمینان حاصل کنند که استانداردهای کیفیت از پیش تعریف شده را رعایت می کنند.

کتابچه راهنمای QA

علاوه بر صفحات گسترده، QA دستی لایه دیگری است که شرکت ها اضافه می کنند. QA دستی نسخه‌های جدید را قبل از استقرار در محیط‌های تولید آزمایش می‌کند. با این حال، یک محیط آزمایشی بی‌خطا نیست، به طوری که برخی از سناریوهای زندگی واقعی در نظر گرفته نمی‌شوند.

کجای کار با استقرار دستی اشتباه می شود؟

بسیاری از چیزها ممکن است برای هر تیم توسعه نرم افزاری که صرفاً به استقرار دستی تکیه می کند اشتباه باشد:

وابستگی به یک گروه کوچک

این می تواند تنگناهایی ایجاد کند که در برخی موارد منجر به تاخیر در انتشار و خطای انسانی می شود. همچنین، زمانی که این فرد خاص می‌رود یا نمی‌تواند وظایف مورد نیاز را انجام دهد، یک تیم ممکن است دچار مشکل شود.

بدون استراتژی کاهش ریسک

هیچ استراتژی برای پیگیری در یک حادثه تولید نامطلوب وجود ندارد. هنگامی که یک حادثه رخ می دهد، تیم انتشار باید برای یافتن ذینفعان مربوطه برای کمک به حل و فصل و تصمیم گیری دست و پنجه نرم کند.

مستعد خطای انسانی

خطاهای تایپی در دستورات یا اسکریپت ها، یا فراموش کرده اید که مراحل قبل از استقرار یا پس از استقرار را اجرا کنید.

تلاش بالا

از آنجایی که استقرار این فرآیند نیاز به مراقبت از کودک دارد، این یک تلاش زمان‌بر است. همچنین باعث کاهش قابل توجه فرکانس استقرار می شود. به عنوان مثال، اگر برای نظارت بر کل استقرار به یک ساعت زمان نیاز باشد، تیم انتشار ممکن است تصمیم بگیرد از استقرار در روزهایی که تغییرات جزئی دارند صرفه جویی کند تا در آن زمان صرفه جویی کند.

خرابی ارتباطات

از تیم های محصول درباره وضعیت عرضه ها و زمانی که تغییرات آنها وارد مرحله تولید می شود، مشخص نیست.

با نگاهی به این چالش ها، به راحتی می توان فهمید که چرا مهندسان از استقرار هراس دارند. خطر شکست استقرار، خطرات زیاد، و فشار برای پایین نگه داشتن زمان توقف نیز به این ترس کمک می کند.

این خرابی ها را می توان با افزایش اتوماسیون تست به حداقل رساند. با این حال، از آنجایی که این تست‌ها در یک محیط آزمایشی انجام می‌شوند، نباید انتظار داشته باشید که یک تست خودکار تمام خطاهای احتمالی را تشخیص دهد. شکست‌ها قابل انتظار هستند اما با نرخ کاهش یافته.

چه کاری می توانیم در مورد آن انجام دهیم؟

به سادگی استقرارهای مستمر را تنظیم کنید؟ گفتنش راحت تر از انجام دادن با وجود اشکالات، استقرار دستی اگر به خوبی مدیریت شود، هنوز مشکلی ندارد. اهداف باید:

• برای جلوگیری از حوادث تولید، نرده های محافظ تهیه کنید
• کاهش خطاهای انسانی
• هر کسی را قادر می سازد تا استقرار را راه اندازی کند
• اطمینان حاصل کنید که استقرار به طور مکرر انجام می شود

گاردریل – قناری و رول بک

استراتژی های قناری و بازگشت به عقب می توانند به کاهش تأثیر قطع برق کمک کنند و در بسیاری از موارد به طور خودکار از بحران جلوگیری کنند.

رهاسازی قناری نسخه جدید شما را در معرض بخش کوچکی از ترافیک محیط تولید قرار می دهد. این به تیم ها بینشی در مورد مسائلی می دهد که ممکن است در طول آزمایش پیش نیامده باشند.

از سوی دیگر، یک استراتژی بازگشت به عقب به مهندسان کمک می کند تا یک نسخه را به حالت نسخه پایدار قبلی خود برگردانند. این کار زمانی انجام می شود که مشکلات جدیدی پس از استقرار در محیط تولید ایجاد شود.

کاهش خطاهای انسانی – استانداردسازی

متدولوژی های استقرار استاندارد را تعریف کنید که منجر به کارایی، سازگاری، قابلیت اطمینان و کیفیت بالای نرم افزار می شود. DORA در گزارش وضعیت DevOps خود نشان می دهد که قابلیت اطمینان عملکرد عملیاتی بهتری را پیش بینی می کند. علاوه بر این، داشتن یک فرآیند استاندارد شده امکان تکرار در فرآیندهای انتشار را فراهم می کند، که می تواند خودکار شود. خودکارسازی این فرآیند به تیم کمک می‌کند تا هزینه‌های تولید را پایین‌تر نگه دارد.

فرآیند استقرار را دموکراتیک کنید

دموکراتیک کردن فرآیند استقرار، اتکا به افراد خاص را از بین می برد. اگر به هر مهندس نرم افزاری قدرت دهیم که استقرار کند، به آرامی ترس را کاهش می دهد. “اگر “هر کسی بتواند مستقر شود، نباید خیلی سخت باشد”. لگوهای خود را به اشتراک بگذارید

استقرار مکرر

برای کاهش اضطراب استقرار، باید به دفعات بیشتر مستقر شویم، نه کمتر. گزارش DORA همچنین تاکید می‌کند که استقرار دسته‌ای کوچک‌تر احتمال بروز مشکلات کمتری دارد و به کاهش موانع روانی برای توسعه‌دهندگان کمک می‌کند.

بهبود تجربه توسعه دهنده

شفاف سازی آنچه در حال استقرار است، تجربه توسعه دهنده را افزایش می دهد. این را برای توسعه دهندگان آسان کنید تا بدانند چه زمانی استقرارها انجام می شود و چه تغییراتی شامل آنها می شود. این شفافیت به توسعه‌دهندگان کمک می‌کند تا زمان اجرا شدن تغییراتشان را ردیابی کنند و بررسی‌های حادثه را ساده‌تر می‌کند.

تعریف استراتژی های کاهش ریسک

باید مراحل مشخصی برای بازگشت به عقب و رفع فوری وجود داشته باشد، زیرا این امر به حذف هرگونه بلاتکلیفی در حوادث تولید کمک می کند. برای مثال، باید مراحل ساخت و استقرار جداگانه‌ای برای تیم‌ها وجود داشته باشد تا برای بازگشت آسان، آن‌ها را دنبال کنند

به طور مشابه، استاندارد کردن نحوه برخورد با رفع‌های فوری و cherrypicks می‌تواند کار را در زمانی که ریسک‌ها زیاد است ساده کند.

پرچم های ویژه

پرچم‌های ویژگی مانند سوئیچ‌هایی هستند که می‌توانند ویژگی جدیدی را که باعث بروز حادثه در تولید شده است، خاموش کنند. این می تواند مهندسان را قادر می سازد تا حوادث تولید را به سرعت حل کنند.

نتیجه گیری

تیم‌های نرم‌افزاری باید مهندسی انتشار را از ابتدای توسعه محصول به عنوان یک اولویت در نظر بگیرند تا از اشتباهات پرهزینه جلوگیری کنند. و ما نباید اجازه دهیم حوادثی مانند قطعی Crowdstrike رویه‌های توسعه ما را فلج کند. پرداختن به ترس از استقرار و جلوگیری از حوادث تولید شامل چندین استراتژی کلیدی است:

• در استانداردسازی فرآیندهای استقرار سرمایه گذاری کنید
• راهبردهای کاهش ریسک به خوبی تعریف شده را تنظیم کنید، مانند انتشار قناری، عرضه استراتژیک، بازگشت مجدد، و رفع فوری.
• تجربه توسعه دهندگان را با دموکراتیزه کردن استقرارها ساده کنید و همه را تشویق به مشارکت کنید.