Fail Small: اصول و اهداف اجرای تابآوری در برابر خطاها
این مقاله به Fail Small و مفاهیم کلیدی مانند break glass، controlled rollouts و Health Mediated Deployment میپردازد تا نشان دهد چگونه میتوان از تکرار حوادث مشابه جلوگیری کرد.
Code Orange: Fail Small — برنامه تابآوری ما پس از حوادث اخیر — 2025-12-19
در 18 نوامبر 2025 شبکه Cloudflare به مدت تقریباً دو ساعت و ده دقیقه در تحویل ترافیک دچار اختلال شد. نزدیک به سه هفته بعد، در 5 دسامبر 2025 دوباره شبکه نتوانست برای حدود 28٪ از اپلیکیشنهایی که پشت سرویس ما بودند، ترافیک را به مدت تقریباً 25 دقیقه سرو کند. ⚠️
بعد از هر دو رویداد پستمورتِمهای مفصلی منتشر شد، اما میدانیم که برای بازپسگیری اعتماد شما کار بیشتری لازم است. امروز جزئیات برنامهای که در Cloudflare برای جلوگیری از تکرار چنین قطعهایی در حال اجراست را توضیح میدهیم.
ما این برنامه را «Code Orange: Fail Small» نامیدهایم؛ هدفمان افزایش تابآوری شبکه در برابر خطاها و اشتباهاتی است که ممکن است منجر به قطع گسترده شوند. اعلام «Code Orange» به این معناست که این کار از اولویت بالاتر از هر چیز دیگری برخوردار است؛ همه تیمها میبایست بهصورت cross-functional روی آن تمرکز کنند و کارهای غیرضروری متوقف شوند تا بتوانیم سریعتر به نتیجه برسیم.
کارهای Code Orange در سه حوزه اصلی سازماندهی شدهاند: ۱) اجرای controlled rollouts برای هر تغییر پیکربندی که به شبکه منتشر میشود، همانطور که امروز برای انتشار باینریهای نرمافزاری انجام میدهیم. ۲) بازبینی، بهبود و تست حالتهای شکست (failure modes) تمام سیستمهایی که ترافیک شبکه را هندل میکنند تا در همه شرایط، حتی حالات خطای غیرمنتظره، رفتار مشخص و قابل اتکا داشته باشند. ۳) تغییر رویههای داخلی «break glass» و حذف وابستگیهای مدور تا در زمان حادثه، هم ما و هم مشتریان بتوانیم سریعاً عمل کنیم و به همه سیستمها دسترسی داشته باشیم. 🔧
این پروژهها به صورت گامبهگام پیش میروند و هر بهروزرسانی کوچک در مسیر باعث افزایش تابآوری خواهد شد، نه یک تغییر بزرگ منفرد در پایان پروژه. هدف نهایی این است که در پایان، شبکه Cloudflare در برابر مشکلات مشابهی که در دو ماه اخیر رخ داد مقاومتر باشد.
میدانیم این اختلالها برای مشتریان و اینترنت دردناک بودهاند و از آنها بسیار متأسفیم — این موضوع برای ما شرمآور است و به همین دلیل این کار برای همه تیمها در اولویت اول قرار گرفته است. *فرآیندهای «break glass» در Cloudflare به برخی افراد اجازه میدهد در شرایط خاص دسترسی و سطح دسترسیشان را برای اقدامات فوری افزایش دهند تا سناریوهای با شدت بالا را رفع کنند.*
چه اتفاقی افتاد؟ در حادثه اول کاربرانی که به سایتهای مشتریان متصل میشدند، صفحات خطا دریافت کردند که نشان میداد Cloudflare قادر به پاسخدهی به درخواستشان نیست. در حادثه دوم کاربران صفحات خالی دیدند.
هر دو قطعی یک الگوی مشابه داشتند: در لحظاتی قبل از هر حادثه، ما یک تغییر پیکربندی را در دیتاسنترهای خود در صدها شهر جهان بهصورت آنی اعمال کردیم و سپس مشکل در شبکه منتشر شد.
تغییر نوامبر، یک بهروزرسانی خودکار برای classifier مربوط به سرویس Bot Management بود. ما چندین مدل artificial intelligence / machine-learning را روی ترافیکی که از شبکه میگذرد اجرا میکنیم تا تشخیصهایی برای bots بسازیم و این سیستمها را مرتب آپدیت میکنیم تا جلوی بازیگران مخرب گرفته شود.
در حادثه دسامبر، در تلاش برای محافظت از مشتریان در برابر یک آسیبپذیری در فریمورک محبوب open source به نام React، تغییراتی در یک ابزار امنیتی که توسط تحلیلگران امنیتی ما برای بهبود signatures استفاده میشود اعمال شد. بهدلیل فوریتی مشابه با آپدیتهای Bot Management، لازم بود سریعاً جلوی سوءاستفاده را بگیریم؛ آن تغییر آغازگر حادثه شد.
این الگو شکاف جدیای در نحوه اعمال تغییرات پیکربندی در مقایسه با نحوه انتشار نرمافزار در Cloudflare نشان داد. وقتی آپدیت نرمافزاری منتشر میکنیم، این کار با کنترل و مانیتورینگ انجام میشود: هر رهاسازی باینری باید از چندین گیت عبور کند قبل از اینکه ترافیک جهانی را سرو کند. ابتدا روی ترافیک داخلی (کارکنان) و سپس با درصدهای افزایشی برای مشتریان، از جمله کاربران رایگان، منتشر میکنیم و در هر مرحله در صورت شناسایی آنومالی، میتوانیم بدون دخالت انسانی rollback کنیم.
تا کنون آن متدولوژی را برای تغییرات پیکربندی اجرا نکرده بودیم. برخلاف انتشار کد، تغییر پیکربندی عملاً رفتار نرمافزار را تغییر میدهد و میتواند فوراً منتشر شود — و این قدرت را به مشتریان هم دادهایم: تغییر یک تنظیم در Cloudflare ظرف چند ثانیه در سراسر جهان منتشر میشود. اگرچه سرعت مزایا دارد، ولی ریسکهایی هم به همراه دارد که باید رفع شوند؛ دو حادثه اخیر نشان داد هر تغییری در نحوه سرو ترافیک باید با همان دقت و تستی که برای کد قائلیم، اجرا شود.
قابلیت اعمال تغییرات پیکربندی در ثانیه به ثانیه، عامل مشترک اصلی در هر دو حادثه بود: در هر دو، یک پیکربندی اشتباه ظرف ثانیهها کل شبکه را از کار انداخت. بنابراین معرفی controlled rollouts برای پیکربندی، همانند انتشار نرمافزار، مهمترین جریان کاری در برنامه Code Orange است. 🔁
تغییرات پیکربندی در Cloudflare بسیار سریع منتشر میشوند: وقتی کاربری یک رکورد DNS جدید میسازد یا یک rule امنیتی اضافه میکند، ظرف چند ثانیه به حدود 90٪ سرورهای شبکه میرسد. این کار توسط کامپوننتی که ما داخلی آن را Quicksilver مینامیم انجام میشود. Quicksilver برای هر تغییر پیکربندی مورد نیاز تیمها هم استفاده میشود؛ این سرعت ویژگی است اما در هر دو حادثه باعث شد تغییر مخرب بدون عبور از گیتها ظرف ثانیهها منتشر شود. در حال کار هستیم تا پیکربندی را همانند کد با controlled deployments در Quicksilver مدیریت کنیم.
ما هر روز چندین بار آپدیت نرمافزاری را از طریق سیستمی به نام Health Mediated Deployment (HMD) منتشر میکنیم. در این فریمورک، هر تیم مالک یک سرویس باید شاخصهایی را تعریف کند که نشاندهنده موفقیت یا شکست یک رهاسازی هستند، برنامه rollout و گامهای بازیابی در صورت شکست را تعیین کنند.
سرویسهای مختلف متغیرهای متفاوتی دارند؛ برخی نیاز به زمان انتظار طولانیتر قبل از انتشار به دیتاسنترهای بیشتر دارند و بعضی دیگر تحمل خطای کمتری دارند حتی اگر سیگنالهای مثبت کاذب تولید شود. ابزار HMD ما پس از انتشار، هر مرحله را با دقت پیش میبرد و آن را مانیتور میکند؛ اگر هر مرحله شکست بخورد، rollback بهطور خودکار آغاز میشود و در صورت نیاز تیمها paging میشوند. در پایان Code Orange، بهروزرسانیهای پیکربندی هم از همین فرایند پیروی خواهند کرد تا بتوانیم پیش از تبدیل شدن مسائل به مشکلات گسترده، آنها را شناسایی کنیم.
چگونه حالتهای شکست بین سرویسها را مدیریت خواهیم کرد؟ اگرچه کنترل بهتر روی پیکربندیها احتمالاً بسیاری از مشکلات را قبل از تبدیل به حادثه میگیرد، اما میدانیم که اشتباه رخ خواهد داد. در هر دو حادثه، خطا در یک بخش شبکه به مشکلاتی در بخشهای مختلف پشته فناوری ما از جمله control plane منتهی شد که مشتریان برای پیکربندی استفاده میکنند.
باید درباره rolloutهای تدریجی نه تنها از منظر جغرافیا (گسترش به دیتاسنترهای بیشتر) یا جمعیت (کارکنان و انواع مشتریان)، بلکه از منظر progression بین سرویسها نیز برنامهریزی کنیم تا شکستها از یک محصول (مثلاً Bot Management) به محصول نامرتبطی (مانند dashboard) منتشر نشود.
برای این منظور در حال بازبینی قراردادهای رابط (interface contracts) بین هر محصول و سرویس حیاتی شبکه هستیم تا اطمینان حاصل کنیم که الف) فرض میکنیم بین هر اینترفیس شکست رخ خواهد داد و ب) آن شکست را به منطقیترین و ایمنترین شکل ممکن هندل میکنیم. در مورد شکست Bot Management دستکم دو اینترفیس کلیدی وجود داشت که اگر فرض شکست را در آنها لحاظ کرده بودیم، میتوانستیم حادثه را طوری کنترل کنیم که بهاحتمال زیاد هیچ مشتریای آسیب نمیدید: اول، اینترفیس خواندن فایل پیکربندیِ خراب شده — بهجای PANIC باید مجموعهای از defaultsِ معتبر وجود میداشت که اجازه میداد ترافیک عبور کند و نهایتاً فقط fine-tuningِ realtime از دست میرفت؛ دوم، اینترفیس بین هسته نرمافزاری شبکه و ماژول Bot Management — اگر ماژول شکست میخورد نباید بهصورت پیشفرض ترافیک را قطع میکردیم، بلکه باید یک دیفالت منطقیتر وجود میداشت تا ترافیک با یک classification قابل قبول عبور کند.
چگونه اضطراریها را سریعتر حل میکنیم؟ در جریان حوادث زمان حل مشکل برای ما طولانی بود. در هر دو مورد این موضوع با این مشکل تشدید شد که سیستمهای امنیتی مانع دسترسی تیمها به ابزارهای لازم برای رفع مشکل شدند و در برخی موارد وابستگیهای مدور باعث کندی کار شدند زیرا برخی سیستمهای داخلی نیز در دسترس نبودند. 🛠️
بهعنوان یک شرکت امنیتی، تمام ابزارهایمان پشت لایههای احراز هویت با کنترلهای دقیق دسترسی قرار دارند تا دادههای مشتریان امن بمانند و جلوگیری از دسترسی غیرمجاز صورت گیرد. با این حال، ساختاری که برای امنیت در نظر گرفته شده بود، در شرایط بحرانی مانع عمل فوری شد؛ بنابراین در Code Orange روی بازنگری رویههای «break glass»، حذف وابستگیهای مدور و طراحی مسیرهای اضطراریِ قابل اتکا کار میکنیم تا در زمان حادثه تیمهای فنی بتوانند سریع و ایمن به ابزار مورد نیاز دسترسی پیدا کنند.
