مدیریت حادثه؛ بخش دوم: آمادگی برای حادثه

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

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

پیش از شروع، لازمه تاکید کنم که قرار نیست همه این موارد یک شبه ایجاد بشن. ساده شروع کنین و بعد با تمرین و تجربه‌اندوزی، بهش مسلط بشین و بهترش کنین. این مستند، فقط قراره به شما کمک کنه تا یک (یا چند) قدم در این مسیر جلو بیافتین.

تعریف «حادثه»

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

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

ممکنه شرایط پیش اومده تبدیل به حادثه نشه (و چیزی آسیب نبینه). اگرچه این موارد نیازی به طی کردن چرخه مدیریت حادثه ندارن، امّا لازمه با برچسب (tag) «خورد پهلوش» (Near miss, Close Call) ثبت‌شون کنیم و فرآیند پس از حادثه (کالبدشکافی و اقدامات اصلاحی) رو براشون انجام بدیم. چون دفعه بعد ممکنه شانس نیاریم!

تدوین ارزش‌ها

یه فرآیند مدیریت حادثه نمی‌تونه تمام موقعیت‌های ممکن رو پوشش بده. به همین دلیل لازمه تا چارچوب و ارزش‌هایی تدوین بشن که:

چراغ راه تصمیم‌گیری مستقل (Autonomous) افراد و تیم‌ها در زمان حادثه و کالبدشکافی باشه
یه فرهنگ استوار و یک‌دست بین تیم‌ها برای شناسایی، مدیریت و یادگیری از حادثه‌ها ایجاد کنه
رویکرد تیم‌ها رو در تمام مراحل رویارویی با حادثه هم‌سو کنه

برای نمونه، میشه برای مراحل مختلف رویارویی با حادثه (شناسایی، حل مشکل، یادگیری و…) این ارزش‌ها رو تعریف کرد:

خبردار شدن قبل از مشتری: یه محصول باکیفیت، به اندازه‌ای ابزار رصد و هشدار داره که به‌موقع (و پیش از مشتری) ما رو از مشکل باخبر کنه. به‌علاوه، هشدارهای خوب، قبل از اینکه مشکلی تبدیل به حادثه بشه ما رو هشیار می‌کنن.
روراست بودن: کاربرها بالاخره متوجه میشن؛ چرا شما زودتر از همه بهشون خبر ندین که حادثه‌ای اتفاق افتاده و دارین برای حل کردنش تلاش می‌کنین؟
قهرمان‌بازی در نیار (دیگران رو خبر کن): همیشه به تنهایی نمی‌تونیم از پس مشکل بر بیایم. برای ارجاع به لایه بالاتر و درخواست کمک (Escalation)، تردید نکنین. کسی از اینکه برای یه حادثه بیدارش کنین ولی بعد معلوم بشه نیازی نبوده، آزرده نمی‌شه. ولی اگر بفهمه باید اونجا می‌بوده و خبرش نکردین، ناراحت میشه.
اول خون‌ریزی رو بند بیار: برای مشتری‌ها (در وهله اول) مهم نیست که چرا سرویس از دسترس خارج شده، فقط دوست دارن که سریع‌تر برگرده. پس با در نظر داشتن هدف اصلی (جلوگیری از گسترش و به حداقل رسوندن آسیب)، در به‌کارگیری یه راه‌حل سریع (هرچند موقتی) تردید نکنین.
دنبال مقصریابی و سرزنش نبودن:‌ حادثه جزیی از کاره. با پاسخگو (Accountable) دونستن تیم‌ها می‌شه سرویس‌ها رو بهبود داد، نه با سرزنش‌شون.
از یه سوراخ دوبار گزیده نشدن: ریشه‌ی مشکل و تغییرات لازم برای جلوگیری از حادثه‌های مشابه (و نه فقط این حادثه خاص) رو شناسایی می‌کنیم. متعهد می‌شویم تغییرات مشخص رو تا موعدهای مشخص انجام بدیم.

تعریف نقش‌ها و مسئولیت‌ها

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

فرمانده حادثه

اولین (و گاهی تنها) نقش، فرمانده/مدیر حادثه (Incident Commander/Manager) است. فرمانده:

در رابطه با حادثه اختیار تام داره و بهش این قدرت داده شده که هر کاری لازمه برای حل سریع مشکل انجام بده.
مرجع اصلی (Go-to person)‌ در زمان حادثه است؛ در جریان کارها قرارداره، هدایت کار رو به عهده داره و پایان حادثه رو تعیین می‌کنه.

تمامی کارها تا زمانی که به نقش/فرد دیگه‌ای سپرده نشده، با فرمانده حادثه‌ست. این وظایف رو میشه به سه بخش تقسیم کرد:

حل مشکل:

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

اطلاع‌رسانی (ارتباطات): اطمینان از اینکه ذینفعان داخل و خارج از شرکت (مشتریان) به صورت دوره‌ای در جریان وضعیت رسیدگی به حادثه قرار می‌گیرن، و شنیدن نقطه نظرات اون‌ها
کالبدشکافی: اطمینان از اینکه بعد از رفع مشکل، کالبدشکافی و اقدامات اصلاحی انجام میشه

در ابتدا، اولین کسی که برای حادثه خبر (page) می‌شه (معمولاً مهندس/SRE کشیک)، نقش فرمانده رو داره، و بعد براساس سطح مشکل، ممکنه دیگران رو خبر کنه و فرماندهی رو به فرد دیگه‌ای واگذار کنه. برای حادثه‌های بزرگ، مطلوب اینه که فرمانده خودش آچاربه‌دست و درگیر انجام کار نباشه.

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

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

نقش‌های دیگر

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

پیاده‌نظام (Resolvers/Responders):‌ فرمانده قرار نیست متخصص تمام کارها و حوزه‌ها باشه،‌ یا ممکنه فرصت درگیر شدن با جزییات رو نداشته باشه. در این شرایط، از متخصص‌های اون حوزه/سرویس کمک می‌گیره و اون‌ها با وارسی سیستم (Investigation)، مشکل و راه‌حل رو پیدا می‌کنن و شرایط، اقدامات و نیازمندی‌ها رو با فرمانده درمیون می‌گذارن.
مدیر فنی/عملیات: وقتی حادثه انقدر بزرگ باشه که چند نفر و/یا در چند جبهه در حال رفع مشکل هستن، مدیر عملیات روی هدایت مهندسان و جزییات روند حل مشکل تمرکز می‌کنه و فرمانده فقط در جریان کلیات و تصمیم‌گیری نهایی خواهد بود. مدیر عملیات همچنین می‌تونه در صورت لزوم افراد دیگه‌ای که برای حل مشکل به حضورشون نیاز هست رو به تیم اضافه کنه.
مدیر ارتباطات: نقطه تماس/ارتباط تیم حادثه با ذینفعان داخلی و خارجی خواهد بود و به صورت دوره‌ای، خبرهای جدید رو بین تیم و ذینفعان تبادل می‌کنه.

علاوه برا این نقش‌ها، ممکنه فرمانده نقش‌هایی مثل دبیر/منشی (Scribe؛ با مسئولیت ثبت وقایع برای کالبدشکافی) یا مدیر حقوقی (با مسئولیت بررسی ابعاد حقوق حادثه و تعهدات و قراردادها) و نظایر اون هم تعریف کنه. در واقع فرمانده همه کارها رو به جز مسئولیت تصمیم‌گیری و برطرف شدن مشکل رو می‌تونه واگذار کنه.

آماده کردن کیف نجات (ابزارهای لازم برای مدیریت حادثه)

برای رویارویی با حوادث، نیاز به منابع و ابزارهای مختلفی داریم که باید قبل از حادثه انتخاب و آماده‌شون کنیم:

رصد و پایش:‌ قبل از هر چیز، باید با راه‌اندازی ابزارهای Monitoring و Log و… به سیستم‌هامون اشراف داشته باشیم. گسترش دید، هم در شناسایی حادثه بهمون کمک می‌کنه و هم در پیدا کردن مشکل و ریشه‌یابی.
تنظیم آژیرها (Alerting): باید تعریفی از مشکلات عملکردی برای هر سیستم داشته باشیم و وقتی مشکلی پیش میاد، خیلی سریع خبردار بشیم. البته نه برای هر مشکلی؛ بلکه برای مشکلاتی که می‌تونیم براشون اقدامی انجام بدیم. به علاوه، باید به صورت دوره‌ای چک کنین که آژیرها درست کار می‌کنن (لکن اینطور نباشد که مشکلی نباشه و به صدا در بیاد، یا مشکلی باشه و به صدا در نیاد!)
مدیریت شیفت و فراخوانی: ابزار و سازوکارهایی لازم داریم که با وقوع مشکل، فرد مناسب (برای مثال SRE On-call) خبر بشه. تعریف شیفت‌ها، راهکاری برای اطلاع از اینکه الآن شیفت کیه، سیاست/قواعد خبرکردن نفر پشتیبان و/یا لایه بالاتر (Escalation Policy)، و ابزاری که به صورت خودکار طبق شیفت و این قواعد، افراد رو خبر کنه. در کنار این‌ها، خوبه که اطلاعات تماس افراد مورد نظر در دسترس باشه تا در صورت لزوم دیگران بتونن باهاشون تماس بگیرن.
ثبت و پیگیری حادثه: باید جایی برای ثبت حادثه‌ها به همراه اطلاعاتی مثل سطح/اولویت حادثه، زمان شناسایی و رفع، سیستم‌های درگیر و… داشته باشیم. این اطلاعات، بهمون کمک می‌کنن تا بتونیم عملکردمون در حادثه‌ها رو بسنجیم، ضعف‌های سیستم رو شناسایی کنیم، یا حتی هنگام وقوع حادثه، بدونیم که در گذشته چه مشکلات مشابهی داشتیم و چطوری بهشون رسیدگی کردیم.
اطلاع‌رسانی، ارتباط و مستندسازی: در زمان حادثه، ابزارهایی برای اطلاع‌رسانی (به ذینفعان داخل و خارج از سازمان)، گفتگو (با تیم حادثه)، و مستندسازی نیاز داریم.

اطلاع‌رسانی می‌تونه از طریق صفحه وضعیت (status page)، تلفن گویا (IVR)، پیامک و… انجام بشه. خود ابزارهای صفحه وضعیت معمولاً امکان اطلاع‌رسانی به افراد رو دارن و افراد می‌تونن با ایمیل، اسلک، مایکروسافت تیمز و… تغییرات وضعیت رو دریافت کنن.
برای اطلاع‌رسانی داخلی می‌تونین از یک کانال اختصاصی برای حوادث در پیام‌رسان سازمان (اسلک، تلگرام، و…) استفاده کنین.
ارتباط و گفتگو با تیم حادثه می‌تونه حضوری و در اتاق جنگ (War Room) باشه یا به صورت برخط (آنلاین) و در پیام‌رسان و تماس تصویری. گفتگوی متنی و ویدیویی کاربردهای متفاوتی دارن و هر دو باید به صورت هم‌زمان در جریان باشن. گفتگوی متنی برای ثبت وقایع مناسبه (که در کالبدشکافی بسیار ارزشمنده) و گفتگوی ویدیویی برای بحث و نتیجه‌گیری سریع یا کارهایی مثل Screen-sharing.
مسیرهای آزموده شده، کارهای انجام شده، و… در ابزاری مثل Google Docs یا Confluence ثبت میشه

مستندات فنی و دستورالعمل‌ها: برای برطرف کردن مشکل، باید مستندات فنی، راهنمای عیب‌یابی (Troubleshooting) و دستورالعمل‌ها (Runbooks) در دسترس تیم حادثه (و البته به‌روز) باشن.
کالبدشکافی و پیگیری اقدامات اصلاحی: باید جایی برای ثبت کالبدشکافی و اقدامات اصلاحی داشت باشیم. بهتر اینه که کالبدشکافی و اقدامات، به خود حادثه (در سیستمی که حوادث رو ثبت می‌کنیم) متصل بشه تا بتونیم.

ابزارهای مدیریت حادثه مثل PagerDuty و OpsGenie و Grafana IRM معمولاً قسمت‌هایی که مستقیم مربوط به حادثه است (مثل هشداردهی، مدیریت کشیک، ثبت اطلاعات حادثه و کالبدشکافی) رو پوشش می‌دن و برای برطرف کردن نیازمندی‌های دیگه (مثل گفتگو، مستندسازی یا مدیریت کارها) با ابزارهای دیگه یکپارچه (Integrate) میشن.

مانور و تمرین

برای اطمینان از اینکه سیستم‌ها به درستی کار می‌کنن و اینکه افراد به روال کار مسلط هستن، به صورت دوره‌ای مانور و/یا تمرین دورمیز برگزار می‌کنیم. در این تمرین‌ها، حادثه‌ای رو فرض می‌کنیم و روند پاسخ به حادثه رو طی می‌کنیم. ممکنه فقط روی یه قسمت (مثل ارتباطات و اطلاع‌رسانی‌ها) تمرکز کنیم، یا اینکه کل چرخه حادثه رو طی کنیم. علاوه بر مانور، بازی‌هایی مثل Keep Talking and Nobody Explodes هم می‌تونه به هماهنگی و ارتباط افراد کمک کنه.

در کنار مانور و تمرین، هر ماه در جلسه‌ای با حضور همه سرتیم‌ها (Team-leads) وضعیت کلی حادثه‌ها رو مرور و کالبدشکافی چند حادثه رو با هم بررسی می‌کنیم. این کار از یک طرف کمک می‌کنه تا با اشکالات کار در فرآیند پاسخ به حادثه و کالبدشکافی آشنا بشیم و از طرف دیگه، باعث اشتراک تجربه بین تیم‌ها میشه (از جمله اینکه اگر مشکلی رو به واسطه حادثه در تیمی پیدا کردیم، بقیه تیم‌ها هم سیستم‌هاشون رو بررسی کنن و مطمئن بشن همین آسیب‌پذیری رو ندارن)

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