هر استقرار خطراتی دارد، اما تیمهای هوشمند DevOps میدانند چگونه سرعت را با آمادگی متعادل کنند تا از ترسهای استقرار اجتناب کنند.
بسیاری از سازمانهای DevOps ابزارهای پیشرفته CI/CD، زیرساخت بهصورت کد و سایر اتوماسیونها را برای افزایش فراوانی استقرار پیاده میکنند. در گزارش State of DevOps 2023، ۱۸٪ از پاسخدهندگان بهعنوان عملکردهای برتر شناخته شدند زیرا توانستند استقرار بر‑تقاضا با زمان عرضه تغییر کمتر از یک روز انجام دهند.
با این حال، این عملکردهای برتر همچنین نرخ خطای تغییر ۵٪ را گزارش میدهند که برای برنامههایی که حیاتی نیستند یا استقرارهایی که در زمانهای کمبار انجام میشوند، ممکن است قابل قبول باشد. اما زمانی که خطاهای تغییر در برنامههای هواپیمایی، بانکی و سایر برنامههایی که نیاز به دسترسی ۹۹.۹۹۹٪ (۵‑ناین) دارند، رخ دهند، انتشار نقصها و تغییرات پیکربندی مشکلدار به تولید میتواند به کابوسهای استقرار منجر شود.
CrowdStrike بهتازگی با یک استقرار ناموفق که ۸.۵ میلیون کامپیوتر ویندوزی Microsoft را تحت تأثیر قرار داد، سرخطها را به خود جلب کرده است؛ این اتفاق تقریباً ۱۰٬۰۰۰ لغو پرواز در سرتاسر جهان را بهوجود آورد. بدیهی است که این شکست تأثیر مالی قابلملاحظهای ایجاد کرد. تحلیل ریشهای CrowdStrike این مشکل را بهعنوان یک باگ طبقهبندی کرد و گزارش داد: «حسگر انتظار داشت ۲۰ فیلد ورودی داشته باشد، در حالی که بهروزرسانی ۲۱ فیلد ورودی فراهم کرد. در این مورد، عدم تطابق منجر به خواندن حافظه خارج از محدوده شد که باعث سقوط سیستم شد.»
ممکن است زمان آن رسیده باشد که سازمانهای DevOps استراتژیهای استقرار خود را بازنگری کنند. چه زمانی انتشارهای مکرر خطرناک میشوند و تیمها باید چگونه ریسک یک تغییر را ارزیابی کنند تا از بروز مشکلات بزرگ استقرار جلوگیری کنند؟
ارزیابی الزامات و ریسکهای پیادهسازی
همه انتشارها، ویژگیها و داستانهای کاربری چابک با ریسک استقرار مساوی هم نیستند. بسیاری از سازمانها ایجاد نمرات ریسک استقرار را خودکار میکنند و سپس برای ارزیابی سطح آزمایش و بازبینی عملیاتی لازم پیش از انتشار از آنها استفاده میکنند. بهصورت سنتی، نمرات ریسک مبتنی بر ورودیهای ذهنی بوده و از متخصصان میخواستند احتمال و تأثیر هر ریسک را ارزیابی کنند، اما سازمانهای با استقرار مکرر میتوانند به رویکرد مبتنی بر یادگیری ماشین منتقل شوند.
«اجتناب از کابوسهای استقرار از فاز برنامهریزی آغاز میشود»، میگوید دیوید بروکس، معاون ارشد تبلیغات در Copado. «هوش مصنوعی میتواند به ارزیابی داستانهای کاربری کمک کند تا ابهامات، وابستگیهای مخفی و تأثیرات، و تداخل کار دیگر توسعهدهندگان را شناسایی کند.»
استراتژیهای مدیریت انتشار استقرارها را بهعنوان بخشی از ارتباطات داخلی و چارچوبهای مدیریت ریسک خود توصیف میکنند. یک رویکرد سنتی ارتقاءهای اصلی، بهبودهای جزئی و ارتقاءهای سامانه را مشخص میکند. رهبران DevOps سپس سیاستهای استقرار، الزامات میاندورهای ریسک و قوانین خودکارسازی را بر پایه انواع انتشار تعریف مینمایند.
یک رویکرد مبتنی بر داده میتواند انتشارها را طبقهبندی کرده و نمرات ریسک را بر اساس متغیرهای متعددی مانند تعداد کاربران تحتتأثیر، پوشش تست کد تحتتأثیر و معیارهای پیچیدگی وابستگیها محاسبه کند. سازمانها سپس میتوانند حلقههای بازخوردی برای تنظیم نمرات ریسک بر پایه تأثیرات واقعی تجاری انتشارها پیادهسازی کنند؛ از جمله ثبت قطعیها، مشکلات عملکرد، حوادث امنیتی و بازخورد کاربران نهایی.
درج امنیت در تجربهٔ توسعهدهنده
یافتن مشکلات امنیتی پس از استقرار یک ریسک بزرگ است و بسیاری از تیمهای DevOps با انتقال به سمت امنیت “چپ” (Shift‑Left) این مشکلات را از پیش برخوردار میکنند. این موارد شامل ترکیبی از سیاستها، کنترلها، اتوماسیونها و ابزارها میشود و مهمترین آن اطمینان از این است که امنیت برای توسعهدهندگان یک مسئولیت اولیه است.
«یکپارچهسازی امنیت و کنترلهای کیفیت در مراحل اولیه چرخهٔ توسعه نرمافزار برای یک عملکرد DevOps مدرن ضروری است»، میگوید کریستوفر هندریچ، معاون CTO شرکت SADA. «ایجاد یک پلتفرم توسعهدهنده با اتوماسیون، خدمات مبتنی بر هوش مصنوعی و بازخورد واضح دربارهٔ دلیل عدم امنیت و راهحل آن، به توسعهدهنده کمک میکند تا بر توسعه تمرکز کند و در همان زمان ذهنیت امنیتی را تقویت نماید.»
تیمهای DevOps میتوانند شیوههای زیر را برای کاهش ریسک فاجعههای استقرار در نظر بگیرند:
- ایجاد استاندارد امنیتی برای توسعهدهندگان نرمافزار بر پایهٔ راهنماییهای OWASP Security Fundamentals، چارچوب توسعهٔ نرمافزار امن NIST (SSDF)، ISO ۲۷۰۳۴ و سایر چارچوبها و استانداردهای کنترل.
- استقرار مدیریت ریسک در توسعهٔ چابک با کاهش بدهی فنی و تکمیل داستانهای پیچیده در اوایل اسپرینتها و دورههای انتشار.
- Address security risks in software development، شامل حاکمیت ضعیف نرمافزارهای منبع باز و عدم امنیت دادههای حساس.
- Implement security testing in CI/CD، شامل تست امنیت ایستا (SAST)، ردیابی وابستگیها و تست نفوذ.
پیادهسازی پیشنیازهای استقرار پیوسته
تیمهای توسعه هدف خود را بر خودکارسازی مسیر به تولید میگذارند، اما همه تیمهای DevOps برای استقرار پیوسته آماده نیستند. آنچه بهعنوان هدف آسانی برای پیادهسازی CI/CD در محیطهای تولید میآید، میتواند بهصورت کابوسهای استقرار منجر شود اگر حفاظتهای مناسب در محل نباشد، بهویژه همانطور که پیچیدگیهای معماری برنامه و میکروسرویسها افزایش مییابد.
«توسعه نرمافزار یک فرآیند پیچیده است که با تغییر یا پیر شدن عملکرد نرمافزار بهتدریج چالشبرانگیزتر میشود»، میگوید ملیسا مککی، سرپرست روابط توسعهدهندگان در JFrog. «اجرای رویکرد چند لایه، انتها‑به‑انتها، برای اطمینان از اولویتبندی امنیت و کیفیت از مرحلهٔ آمادهسازی بسته و کدنویسی تا مانیتورینگ زمان اجرا ضروری شده است.»
تیمهای DevOps که میخواهند تحویل پیوسته را برای برنامههای حیاتی و در مقیاس بزرگ اجرا کنند، باید بهترین شیوههای زیر را بهکار گیرند:
- Continuous testing با پوشش تست بالا، دادههای تست جامع و تست مبتنی بر پرسونای کاربر نهایی، شامل استفاده از synthetic data و قابلیتهای تست genAI برای کاهش نقصها در کد تولیدی.
- Feature flagging بهگونهای که تیمهای توسعه بتوانند قابلیتهای آزمایشی را بهصورت هدفمند و برای مجموعهای محدود از کاربران نهایی پیکربندی و تست کنند.
- Canary release strategies برای پشتیبانی از استقرار چندین نسخه از یک برنامه یا سرویس، کنترل نسخهای که کاربران نهایی به آن دسترسی دارند و شناسایی مشکلات در این پایهٔ محدود کاربران.
«اجرای چکهای نرمافزاری در هر مرحله کیفیت کد و تابآوری را ارتقا میدهد، در حالی که استفاده از استراتژیهای مانند تست canary بهمنظور تضمین استقرارهای پایدار کمک میکند»، افزود ملیسا مککی از JFrog.
برخی سازمانها تنها چند برنامه حیاتی در مقیاس بزرگ دارند که نیاز به تحویل پیوسته و تمام پیشنیازهای آن دارند. شرکتهای بزرگ با سبدی قابلتوجه از برنامههای حیاتی، تیمهای علم‑داده با صدها مدل هوش مصنوعی یا شرکتهای SaaS با چندین خط محصول، باید به شیوههای مهندسی پلتفرم روی آورند تا استانداردها و کاراییها را ارتقا دهند.
کوین کوکرین، CMO شرکت Vultr میگوید: «مهندسی پلتفرم برای برنامههای بومی‑ابری و بومی‑هوش مصنوعی، DevOps را بهبود میبخشد و ریسکهای سازمانها را با خودکارسازی فرآیندهای کلیدی که از AI بالغ و مسئول پشتیبانی میکند، از جمله تأمین زیرساخت، مشاهدات مدل، و حاکمیت داده، کاهش میدهد.»
بهبود مستمر قابلیت مشاهده، مانیتورینگ و AIOps
چه چیزی استقرارهای ضعیف را از داستانهای ترسناک استقرار جدا میکند میتواند با پاسخ به سه سؤال کلیدی کشف شود:
- تأثیر تجاری چیست؟ شامل تعداد کاربران تحتتأثیر، کاهش بهرهوری در عملیات، هزینههای مالی، خسارتهای اعتبار، عوامل تطبیق و پیامدهای قانونی.
- چند زمان میبرد تا سازمان مسأله را شناسایی، به کاربران نهایی اطلاع دهد، از حادثه بازیابی کند، ریشهها را پیدا کند و اقدامهای اصلاحی را اعمال نماید؟
- چند بار تیم DevOps در مواجهه با استقرارهای ناموفق پاسخ میدهد و آیا مهندسان از فشارهای مداوم «آتشنشان» خسته شدهاند؟
سرمایهگذاری بر observability، application monitoring و AIOps از قابلیتهای عملیاتی کلیدی هستند که میتوانند تأثیر تجاری را کاهش داده و میانگین زمان بازیابی (MTTR) را پس از حوادث بزرگ بهبود بخشند.
«تمام «کابوسهای» امروز DevOps — از خطاهای کاربر نهایی تا احتمال سوءتفاهمها — در اصل به عدم وجود ارتباط یا رؤیت مناسب بازمیگردد»، میگوید مادهو کوچار، معاون محصول در IBM Automation. «نمیتوانید آنچه را که نمیبینید اصلاح کنید و به همین دلیل قابلیت مشاهده، بهویژه در زمینهٔ هوش مصنوعی خودکار، برای پرداختن به نقصهای شناختهشده و ارائهٔ بینش دربارهٔ آنچه داخل سیستم یا برنامه شما رخ میدهد، بحرانی است. قابلیت مشاهده بهدستگیرندهٔ بازخورد DevOps اجازه میدهد بدون وقفه جریان دادهها ادامه یابد و تلاشهای استقرار مؤثرتری ارائه دهد که مشکلات را پیش از تأثیر بر کاربران شناسایی میکند.»
قابلیت مشاهده، خودکارسازی و مانیتورینگ استراتژیهای دفاعی کلیدی برای هشدار مرکزهای عملیات شبکه (NOC) و مهندسان قابلیت اطمینان سایت (SRE) دربارهٔ حوادث بزرگ هستند. سازمانهایی که از معماری میکروسرویسها، استقرار در چندین ابر و اتصال به سیستمهای شخص ثالث متعدد استفاده میکنند، به راهحلهای AIOps برای شناسایی ریشه حوادث و فعالسازی پاسخهای خودکار مانند بازگردانی استقرارها نیاز دارند.
«با تحول سریع محیط دیجیتال، ابزارهای مانیتورینگ سنتی دیگر برای برآورده کردن نیازهای DevOps مدرن کافی نیستند»، میگوید جیمسراج پل جاسپر، مدیر محصول ارشد در ManageEngine. «تیمها باید سامانهای هوشمندانه شامل قابلیت مشاهده مبتنی بر هوش مصنوعی و راهحلهای پیشبینیکننده پیاده کنند تا پیشدستی به مسائل احتمالی داشته باشند.»
تدوین دفترچه راهنمای حادثهٔ بزرگ
زمانی که یک استقرار ناموفق باعث حادثهٔ بزرگ میشود، سازمانهای فناوری اطلاعات باید یک دفترچهٔ عملیاتی داشته باشند تا پاسخ خود را راهنمایی کنند. آیا تیم پاسخدهی به اندازهٔ مناسب و مهارتدار وجود دارد که بداند از چه ابزارهای ارتباطی استفاده کند و چه مانیتورهای برنامهای را بررسی نماید؟ آیا برای هماهنگی اقدامات رهبری وجود دارد و آیا ذینفعان، مدیران و مشتریان دربارهٔ مسئله و وضعیت آن بهخوبی مطلع میشوند؟
در یک حادثهٔ بزرگ، بدترین سناریو این است که همه افراد، از مهندسان تا مدیران، مانند مرغهای سرپوشیده بدون مسیر واضح و ارتباط مشخص، در هم میدوند. این امر منجر به تأخیرها، اشتباهات و استرس بیشتر میشود. اکثر سازمانها یک دفترچهٔ حادثهٔ بزرگ و فرآیند مدیریت خدمات فناوری اطلاعات (ITSM) برای آمادهسازی در برابر انواع مسایل تولیدی با اثرات تجاری توسعه میدهند.
تیمهای DevOps ملزم به افزایش فراوانی استقرارها و ارائه قابلیتهای جدید به کاربران نهایی برنامه هستند. هر استقرار ریسکهای خود را دارد و استقرارهای ناموفق نیازمند بررسی ریشهای و اجرای اقدامات اصلاحی خواهند بود. با این حال، سازمانهای هوشمند DevOps سرعت را با آمادگی ترکیب میکنند تا از بروز کابوسهای استقرار جلوگیری نمایند.
پست های مرتبط
DevOps هوشمندتر: چگونه از ترسهای استقرار جلوگیری کنیم
DevOps هوشمندتر: چگونه از ترسهای استقرار جلوگیری کنیم
DevOps هوشمندتر: چگونه از ترسهای استقرار جلوگیری کنیم