مدیریت حوادث و پس از مرگ: تجزیه و تحلیل علل ریشه ای با هوش مصنوعی

سود:

• توانایی درک چرخه زندگی یک حادثه (تشخیص، تریاژ، کاهش، حل و فصل، پس از مرگ)، معیارهای MTTD/MTTR و اصل "اول کاهش، بعدا بررسی"
• امکان استفاده از هوش مصنوعی برای محدود کردن فرضیه‌ها در زمان وقوع حادثه و تولید یک طرح پس از مرگ بی‌عیب، و اعتبار هر علت اصلی با داده‌ها
• امکان اعمال نظم نوشتن به زبانی که پس از مرگ و به اشتراک گذاری داده های رویداد با پوشاندن آن مقصر نباشد.

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

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

چرخه زندگی یک رویداد

1. تشخیص: زنگ هشدار به صدا در می آید یا شکایت مشتری می آید. هر چه زودتر بهتر.
2. تریاژ: چقدر جدی است؟ دامنه چیست؟ سطوح شدت تخصیص داده می شود - معمولاً SEV1 (بسیار حیاتی، کل سیستم) به SEV4 (فرعی).
3. تیم پاسخگویی خود را جمع آوری کنید. در حوادث بحرانی، یک فرمانده حادثه هماهنگی را بر عهده می گیرد.
4. کاهش: ابتدا خونریزی را متوقف کنید - اغلب یک عقبگرد یا پوشاندن پرچم. بعداً علت اصلی را پیدا خواهید کرد.
5. راه حل: راه حل دائمی را اعمال کنید.
6. یاد بگیرید (پس از مرگ): چه اتفاقی افتاد، چرا این اتفاق افتاد، چگونه از تکرار آن جلوگیری کنیم؟

نکته: یکی از پرهزینه‌ترین اشتباهات در زمان وقوع حادثه، تأخیر در توقف خونریزی است زیرا "بیایید ابتدا به علت اصلی آن بپردازیم." قانون: ابتدا کاهش (بازیابی/بازیابی سرویس)، سپس پرس و جو. بازگشت به یک نسخه شناخته شده خوب اغلب سریعترین کاهش است.

فرهنگ پس از مرگ بدون گناه

ستون فقرات تیم های سالم، فرهنگ پس از مرگ بی تقصیر است: هدف "چه کسی این کار را انجام داد" نیست، بلکه "چه سیستم و فرآیندی اجازه این اشتباه را داده است؟" سوال است مردم اگر بدانند مجازات خواهند شد، اشتباه را پنهان می کنند. خطای پنهان تکرار می شود. Postmortem یک گزارش اتهام نیست، بلکه یک سند یادگیری است.

یک پس از مرگ خوب شامل موارد زیر است: خلاصه، تأثیر (تعداد کاربر، مدت زمان، چقدر پول)، جدول زمانی، علت(های) ریشه، چه چیزی خوب/بد بوده است، و موارد اقدام - اقدامات مشخص، هر کدام دارای مالک و تاریخ.

احتیاط: هنگام نوشتن پس از مرگ با هوش مصنوعی، حتماً زبان متهم را حذف کنید (یعنی "شخص X اشتباه کرد"). همچنین هنگام تغذیه داده‌های رویداد به هوش مصنوعی، شناسه‌های مشتری، آی‌پی‌های داخلی و اسرار را پنهان کنید - پس از مرگ اغلب به طور گسترده به اشتراک گذاشته می‌شوند.

تجزیه و تحلیل علت ریشه ای: 5 چرا و هوش مصنوعی

یک تکنیک کلاسیک "5 چرا" است: بپرسید "چرا؟" به یک مشکل با پرسیدن دوباره و دوباره از علامت سطحی به ریشه واقعی می رسید. "سرویس از کار افتاد. چرا؟ حافظه از بین رفت. چرا؟ نشت داشت. چرا؟ به روز رسانی کتابخانه..." هوش مصنوعی به سرعت این زنجیره را ایجاد می کند و شاخه های احتمالی را پیشنهاد می کند - اما شما باید هر "چرایی" را با داده های خود تأیید کنید. هوش مصنوعی همچنین می تواند یک زنجیره معقول اما اشتباه بسازد.

جدول شدت

سطح

تاثیر

مثال

مداخله

SEV1

کل سیستم/از دست دادن حیاتی کسب و کار

پرداخت به طور کامل کاهش یافت

بلافاصله، کل تیم، فرمانده

SEV2

Major dysfunction

ورود ناموفق بود

سریع، در حال تماس + پشتیبانی

SEV3

اثر جزئی/محدود

گزارش تاخیر دارد

در ساعات کاری

SEV4

کوچک/آرایشی

غلط املایی

صف کار معمولی

سه کیف کوچک

مورد 1 - MTTR از 45 دقیقه تا 8 دقیقه. سرویس پرداخت خراب شد. مهندس موظف، گزارش‌های ماسک‌دار و آخرین اطلاعات استقرار را به هوش مصنوعی داد و پرسید: محتمل‌ترین محرک در 20 دقیقه گذشته چیست؟ او پرسید. هوش مصنوعی نشان داد که فروپاشی در همان دقیقه با آخرین استقرار آغاز شد. مهندس بلافاصله آن نسخه را پس زد. سرویس در 8 دقیقه برگشت. سپس علت اصلی (اشکال استخر اتصال در نسخه جدید) به راحتی بررسی شد.

مورد 2 - طرح پس از مرگ در 20 دقیقه. بعد از SEV2، تیم خسته بود و قدرت نوشتن گزارش را نداشت. اغلب گزارش هفته ها به تعویق می افتاد. این بار، آنها جدول زمانی و یادداشت های حادثه را به هوش مصنوعی دادند و یک طرح پس از مرگ بدون جرم تهیه کردند. هوش مصنوعی یک چارچوب منظم برای موارد تاثیر، جدول زمانی و اقدام ایجاد کرد. تیم آن را با حقایق پر کرد و در 20 دقیقه آن را منتشر کرد. درس گم نشد.

مورد 3 - علت اصلی اشتباه کشف شده است. در یک مورد، هوش مصنوعی گفت "ریشه بیش از حد پایگاه داده" و منطقی به نظر می رسید. اما مهندس این معیار را تأیید کرد: بارگذاری پایگاه داده در زمان وقوع حادثه عادی بود. علت واقعی مشکل DNS خارجی بود. فرضیه اولیه هوش مصنوعی روان اما اشتباه بود. اعتبارسنجی با داده ها از انتشار گزارش با نتیجه گیری نادرست جلوگیری کرد.

چهار قالب قابل کپی

1) تریاژ سریع در زمان وقوع حادثه:

ما در حال تجربه یک رویداد تولید هستیم. علائم ماسک شده: [علائم]. آخرین تغییرات: [آخرین استقرار/تغییر]. به من بدهید: (1) 3 فرضیه علت اصلی محتمل به ترتیب احتمال، (2) فرمان/متری که هر کدام را در 1 دقیقه تأیید می کند، (3) سریعترین مرحله کاهش ایمن (مثلاً برگشت). بیان کنید که باید هر فرضیه را تأیید کنم.

2) طرح بی گناه پس از مرگ:

از یادداشت های حادثه در زیر یک طرح پس از مرگ بی تقصیر بنویسید. بخش‌ها: خلاصه، تأثیر (کاربر/مدت/هزینه)، جدول زمانی، علت(های) ریشه‌ای، آنچه خوب پیش رفت، موارد بد، موارد اقدام (هر کدام با فیلد مالک + تاریخ). روی نامگذاری، فرآیند و سیستم تمرکز کنید. یادداشت ها: [ماسک شده]

3) تجزیه و تحلیل 5 چرا:

یک زنجیره "5 چرا" بسازید، با علامت زیر شروع کنید: [SYMPTOM]. نشان دهید که در هر مرحله بیش از یک شاخه ممکن وجود دارد. در کنار هر «چرا» شواهد (log/metric) را بنویسید که برای تأیید آن به آنها نگاه خواهم کرد. در پایان مشخص کنید کدام مراحل هنوز تایید نشده اند.

4) ایجاد موارد عملی:

با توجه به این علت اصلی، موارد قابل عملی را پیشنهاد دهید که از تکرار همان رویداد جلوگیری می کند. هر مورد را بر اساس: (الف) پیشگیری، تشخیص یا کاهش، (ب) تلاش برآورد شده، (ج) تاثیر طبقه بندی کنید. مرتب سازی بر اساس بالاترین نسبت تاثیر/تلاش. علت اصلی: [X]

اعلان ضعیف / اعلان قوی

ضعیف: "سرویس خراب شده است، چه کار کنم؟"

نتیجه: بدون زمینه; هوش مصنوعی می‌تواند توصیه‌های کلی را ارائه دهد که مناسب مورد شما نیست، و حتی می‌تواند دلیل اصلی قطعی پیدا کند.

Strong: "سرویس پرداخت تولید به مدت 5 دقیقه 5xx داده است. آخرین استقرار 6 دقیقه پیش بود. 3 فرضیه علت اصلی محتمل را به ترتیب احتمال بیان کنید، فرمانی را بگویید که هر کدام را تأیید می کند و سریع ترین کاهش ایمن را پیشنهاد می کند. مشخص نباشید، بیان کنید که باید تأیید کنم."

تفاوت: اعلان دوم علامت، زمان و آخرین تغییر را می دهد. این نیاز به فرضیه + تأیید + کاهش دارد و هوش مصنوعی را نادقیق نگه می دارد.

اشتباهات رایج

• قبل از تعدیل به دنبال علت اصلی باشید. توقف خونریزی را به تاخیر می اندازد و MTTR را افزایش می دهد.
• انتشار اولین فرضیه هوش مصنوعی بدون تایید آن. ریشه های مایع اما نادرست باعث نشت در گزارش می شود.
• زبان اتهامی پس از مرگ که به صورت ناشناس نوشته شده است، پنهان کاری و تکرار خطا را تقویت می کند.
• گزارش اقدام محور بدون نقطه گلوله. پیشنهاد بدون مالک و تاریخ هرگز اجرا نمی شود.
• به اشتراک گذاری داده های رویداد بدون پوشاندن آن. Postmortem به مخاطبان گسترده ای می رود. اطلاعات محرمانه/شخصی فاش شده است.
• عدم آماده سازی مسیر بازگشت از قبل. اگر معکوس کردن عملی نباشد، کاهش کند می شود.

به طور خلاصه

مدیریت حوادث در مورد شناسایی سریع، کاهش، حل و فصل و یادگیری از رویدادهای اجتناب ناپذیر است. MTTD و MTTR معیارهای کلیدی هستند. قانون طلایی این است که "اول کاهش دهید، بعدا بررسی کنید" و بازگشت به نسخه شناخته شده خوب اغلب سریعترین کاهش است. هوش مصنوعی در خلاصه کردن گزارش‌ها در زمان رویداد، محدود کردن فرضیه‌ها، و تولید طرح‌های پس از مرگ بی‌عیب پس از رویداد بسیار ارزشمند است – اما این مسئولیت شماست که هر فرضیه علت اصلی را با داده‌ها، پاک کردن زبان سرزنش و پنهان کردن داده‌های رویداد تأیید کنید.

وظیفه کاربردی

یک رویداد گذشته (یا تخیلی) را در نظر بگیرید. (1) از هوش مصنوعی بخواهید با الگوی «تریاژ سریع در صحنه» فرضیه ها و مراحل تأیید را ایجاد کند. توجه داشته باشید که کدام فرضیه را می توان با داده ها تأیید کرد. (2) یک گزارش را با استفاده از الگوی "بدون گناه پس از مرگ" ترسیم کنید و آن را با حقایق پر کنید. (3) حداقل دو مورد قابل اقدام را شناسایی کنید و برای هر کدام یک مالک و تاریخ تعیین کنید.

چک لیست

• [ ] در زمان وقوع حادثه، ابتدا به فکر کاهش (بازگشت/خاموش) افتادم و علت اصلی را به بعد واگذار کردم.
• [ ] من هر فرضیه علت ریشه ای هوش مصنوعی را با log/metric تأیید کردم.
• [ ] من آن را به زبانی نوشتم که مرگ پس از مرگ را سرزنش نمی کند، با تمرکز بر فرآیند و سیستم.
• [ ] من به هر مورد قابل اقدام یک مالک و یک تاریخ اختصاص دادم.
• [ ] من اطلاعات مخفی و شخصی را از داده های رویدادی که به هوش مصنوعی دادم پنهان کردم.
• [ ] من سطح شدت را به درستی با توجه به ضربه تعیین کردم.