یکی از مهمترین مسائلی که میبایستی در حوزه SRE رعایت کنیم و به عنوان یک فرهنگ آنرا پیاده سازی کنیم، تعریف فرآیندهای مدیریت Incident و سیستم Postmortem میباشد.
چرا به این موارد نیازمندیم؟ در شرایط Incident و Outage، معمولا به دلیل فشار کاری و استرس بالا، تصمیم گیری و مدیریت تیم و کارها بسیار سخت و بسیار چالش برانگیز می باشد؛ این فرایندها در شرایط اینگونه، میتواند به مدیریت Incident کمک کند و تصمیم گیری و فرایندها را مشخص تر و سریعتر نماید و درنهایت فرهنگی را پیاده‌سازی کند که همه از تجربه‌ی همدیگه درس گرفته و بهره‌مند شوند.
توضیحات: اصول و موارد مطرح شده در این مطب، با الگوبرداری از فصل چهاردهم و پانزدهم کتاب Site Reliability Engineering آماده شده است؛ اگر پیشنهادی برای بهبود ویا تکمیل توضیحات دارید، حتما کامنت بزارید که درموردش صحبت داشته باشیم.
چه زمانی یک رخداد را Incident مینامیم؟ در صورتی که رخداد ما با هر کدام از گزینه های ذیل تطابق داشته باشد، رخداد را Incident مینامیم.
آیا نیازی به درگیر شدن تیم(یا تیمها) دیگری در رفع رخداد وجود دارد؟
آیا سرویس‌دهنده ها یا استفاده کنندگان(تیم توسعه، تیم عملیات، مشتری‌ها و...) متوجه رخداد میشود؟
آیا رخدادی پیش آمده است که بعد از گذشت یک ساعت آنالیز دقیق همچنان حل نشده است؟
ساختار مدیریت رخداد
تقسیم وظایف
بسیار مهم است که هر کس، نقش خود را در سیستم بداند و هدررفت وقت و انرژی وجود نداشته باشد؛ هر شخص در وظایف خودش می بایست قدرت عمل و تصمیم گیری کافی را داشته باشد؛ در صورتی که Load کاری یک نفر افزایش پیدا کرد و به نقطه ای رسید که قابل مدیریت نباشد، آن شخص میبایستی از تیم لید درخواست اضافه کردن نیرو (به منظور تقسیم کار در شرایط اختلال) نماید.
وظایف میتوانند به شرح ذیل تقسیم گردد:
راهبر رخداد: راهبر رخداد مسئول مستقیم فنی و بیزینسی رخداد میباشد و در این دو لایه تصمیم گیری میکند؛ همچنین این شخص مسئول مشخص کردن افراد درگیر در رفع رخداد و تخصیص مسئولیت و تسک و اولویت بندی میباشد و همچنین تیم عملیاتیِ رفع اختلال را راهبری میکند.
افراد عملیاتی: افرادی که مستقیما توسط راهبر رخداد و به جهت رفع مشکل مدیریت میشوند؛ نکته مهم برای توجه اینست که فقط افراد عملیاتی مجاز به اعمال تغییرات در سیستم می باشد و هیچ فرد دیگری نباید تغییری در سیستم ایجاد کند. همچنین تمامی تغییرات اعمال شده به اطلاع تمامی اعضای عملیاتی و راهبر میرسد.
روابط بیرونی / واسطه: یک شخص مسئول آپدیت نگه‌داشتن Incident Report، اطلاع رسانی به افراد بیزینسی مربوطه و گرفتن فیدبک و اطلاع رسانی به تیم عملیاتی رخداد و گاهی اضافه کردن تسک در فرایند رفع رخداد میباشد(مثل آماده سازی یک گزارش خاص یا بررسی وضعیت یک سیستم ثانویه توسط تیم عملیاتی و…).
برنامه‌ریز: یک شخص که مسئول مستقیم پشتیبانی افراد عملیاتی رخداد میباشد و به شکل جداگانه، بررسی میکند که چه عواملی باعث ایجاد مشکل شده و در آینده چگونه از به وجود آمدن این مشکل جلوگیری شود و تمامی عوامل تاثیر گذار را مورد توجه و بررسی قرار میدهد.
فرآیند
حتما در قدم اول، مدیران مرتبط از پیش‌آمد رخداد و شروع فرایند رفع اختلال مطلع شوند.
بهترین حالت برای مدیریت رخداد، حضور تمامی افراد عملیاتی رخداد در یک اتاق جلسه مشترک(اصطلاحا War Room) به جهت تصمیم گیری و پیشبرد یکپارچه و متمرکز کارها میباشد.
بهتر است که تمامی رفتارهای ریکوئست ها، ترافیک و… در یک داکیومنت مرجع در بازه های زمانی متفاوت(تایم لاین مشخص) ثبت و لاگ برداری شوند.
یک داکیومنت(Incident Document) یکپارچه قابل ویرایش توسط تمامی اعضا(بستر پیشنهادی: Google Docs) که شامل تمامی رخدادهای مرتبط، تایم لاین رفع رخداد، دیالوگهای مرتبط، تغییرات و تصمیم گیریها و دلایلشان (در تیم فعلی و دیگر تیمهای سازمان) میباشد میبایستی تهیه و به شکل لحظه ای آپدیت شود. (تمپلیت کلی به منظور تمیز نگه‌داشتن ساختار دیتا میبایستی تعریف گردد).
پس از رفع اختلال، گزارش رخدادی(Postmortem) آماده شود که شامل نکات ذیل باشد و این گزارش به اطلاع همه‌ی تیمهای مرتبط به جهت یادگیری تجربه برسد:
خلاصه رخداد
تاثیر و صدمات
وضعیت فعلی
دلیل یا دلایل اصلی ایجاد رخداد(Root Causes)
تریگر(چه چیزی باعث فعال شدن باگ/اختلال شد)
توضیحات تکمیلی
وضعیت مانیتورینگ و آلرتها(چه چیزهایی دریافت کردیم و چه چیزهایی دریافت نکردیم)
چه چیزی در سیستم به شکل خوب عمل کرد و از بزرگتر شدن مشکل جلوگیری کرد.
چه چیزی در سیستم(فنی، ساختاری، تیمی و…) بد عمل کرد و می توانست بهتر باشد.
در کجای سناریو و رخداد، شرایط به شکل شانسی خوب پیش رفت و چجوری میتونیم برنامه ریزی کنیم که این اتفاق خوب را پایدار کنیم.
تایم لاین
چرا باید گزارش رخداد ویا Postmortem داشته باشیم؟
ما به عنوان افرادی با عنوان شغلی SRE، مرتبا درگیر سیستم‌های Large-scale، پیچیده و توزیع‌شده هستیم و این سیستمها به شکل متداوم در حال اعمال تغییرات و اضافه کردن فیچر میباشند؛ با توجه به ماهیت این سیستم ها، Outage و Incident اجتناب ناپذیرند و می بایستی به عنوان بخشی از ماهیت سیستمها مقبول واقع شوند؛ این فرهنگ Postmortem به ما کمک میکند که از اشتباهات خود و دیگران درس بگیریم و تجربیات خودمون در اختلال ها به اشتراک بزاریم؛ این موضوع باعث این میشه که یک اشتباه رو دوباره و در شرایط مختلف تکرار نکنیم و تجربه‌هامون رو به شکل مشترک گسترش بدیم.
چه زمان Incident Managementـی وجود ندارد و تاثیرات آن چه میباشد؟
توجه: یک نفر کارشناس فنی، پاسخگوی تمامی وجوه مشکل به لایه های بالاتر و دیگر تیمها باشد، مثل موارد تکنیکال، بیزینسی و مدیریت ارتباط با تیمهای دیگر؛ این موضوع باعث این میشود که بیشتر تمرکز در نهایت بروی مسئله Technical قرار بگیرد و خیلی وقتا تاثیرات اعمال تغییرات فنی در لایه ی بیزینسی و Big Picture(کلان) در نظر گرفته نشود.
تعاملات ضعیف: در ساختاری که کارشناس در جریان کارهایی که دیگر همکارانش در راستای حل رخداد انجام میدهند نباشد و متوجه نشود که چه تغییراتی اعمال می شوند، حل مشکل و تشخیص عوامل پیچیده تر و سخت تر میشود؛ با مدیریت این فرایند و درگیر کردن افراد تیم و تیمهای دیگر به شکل صحیح و درست از هدررفت وقت و انرژی جلوگیری میشود.
خودمختاری: تصمیم گیری خودسرانه و اعمال تغییرات(حتی با اینکه قصد افراد فقط حل مشکل میباشد) و اطلاع ندادن به تیم، باعث بدتر شدن شرایط و سخت تر شدن فرایند حل مشکل میشود.
Incident Management Best Practices
اولویت‌بندی: اولویت اولیه بکار انداختن دوباره سرویس(جلوگیری از خونریزی بیشتر!) و بازگشت به نقطه‌ی Stable میباشد. اما حتما می بایستی تمامی مدارک، لاگها و شواهد را برای بررسی دقیق تر و بیشتر نگهداری کنیم.
آمادگی: فرایندهای Incident Management خودرا می بایستی داکیومنت کرده و آپدیت نگه داریم تا تمام اعضای تیم به شکل دقیق در جریان تجربه‌ها و تصمیمات قبلی قرار بگیرند.
اعتماد: به هر عضو تیم که درگیر Incident میباشد؛ اعتماد در عملکرد داشته باشید و دست آنها را برای تصمیم گیری و ترابل شوت باز بگذارید.
احساسات: احساسات خود را در جریان Incident مدیریت کنیم؛ در صورت اینکه احساس وحشت، ترس ویا سرگیجه و سردرگمی داشتید، از دیگران کمک بگیرید.
درنظرگرفتن راهکارهای جایگزین: به شکل مداوم در فرایند حل مشکل، این گزینه را بررسی کنید که آیا ادامه دادن رویکرد فعلی با توجه به شرایط منطقی است یا نیازمند این هستیم که راهکار جایگزین دیگری را در پیش بگیریم؟
تمرین و تکرار: فرایند Incident Management را به شکل مرتب و مداوم استفاده و رعایت کنید تا تبدیل به یک رویکرد و روال طبیعی در مدیریت اختلال در سیستمها شود.
چرخش: نقش افراد تیم در حل مشکل را در هر تجربه و رخداد بچرخانید و بگذارید اعضای تیم در همه‌ی جایگاه ها قرار گرفته و با تمام فرایندهای در هر نقش به شکل کامل آشنا شوند.
امیدوارم که این مطلب برای همه دوستان مفید واقع شده باشه و خوشحال میشم نظراتتون رو باهام به اشتراک بذارید.
