ارجاع هشدار (Escalation) و آنکال برای تیم‌های کوچیک.

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

نکته‌های کلیدی

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

چرا «برای همه بفرست» جواب نمی‌ده؟

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

یه سیاست ارجاع ساده

1. سطح ۱ (دقیقه‌ی صفر): نفر آنکال پیامک و یه پیام تلگرام/بله می‌گیره.
2. سطح ۲ (بعد از ۱۰ دقیقه بدون تأیید): نفر پشتیبان به همون شکل خبر می‌شه.
3. سطح ۳ (بعد از ۲۰ دقیقه): سرپرست تیم یا صاحب کسب‌وکار خبر می‌شه.

گروه تیم همه‌ی هشدارها رو برای اطلاع می‌گیره، ولی فقط از پاسخ‌دهنده‌ی فعلی انتظار اقدام هست.

چیدن چرخه‌ی آنکال

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

از نفر آنکال محافظت کنید

• بیرون از ساعت کاری فقط مانیتورهای حیاتی خبر می‌دن؛ هشدارهای عادی تا صبح صبر می‌کنن.
• اول بزرگ‌ترین منبع‌های نویز رو درست کنید؛ کم کردن هشدارهای اشتباه رو ببینید.
• بعد از یه شب بد، استراحت بدید.
• برای هشدارهای پرتکرار runbook کوتاه بنویسید: چی رو چک کنیم، چطور ری‌استارت کنیم، به کی زنگ بزنیم.

پاسخ‌دهنده چیکار می‌کنه؟

1. تأیید؛ به تیم بگید دارید رسیدگی می‌کنید.
2. ارزیابی اثر؛ کدوم کاربرها و قابلیت‌ها درگیرن؟ لوکیشن‌ها و خطاهای مانیتور رو ببینید.
3. اطلاع‌رسانی؛ اگه کاربرها درگیرن، اولین پیام رو روی صفحه‌ی وضعیت بذارید.
4. اول مهار؛ ری‌استارت، برگشت به نسخه‌ی قبل، سوییچ به پشتیبان. تحلیل علت ریشه‌ای بعداً.
5. تحویل یا بستن؛ اگه طول کشید کمک بیارید؛ وقتی حل شد، پیام برگشت رو منتشر کنید.

از هر رخداد درس بگیرید

بعد از رخدادهای مهم، ۳۰ دقیقه برای یه مرور بدون مقصرتراشی بذارید:

• از کجا باخبر شدیم؛ مانیتور، مشتری یا اتفاقی؟
• هشدار به آدم درست رسید و جواب دادن چقدر طول کشید؟
• چه چیزی زودتر تشخیصش می‌داد؟
• کدوم تغییر جلوی تکرارش رو می‌گیره؟

میانگین زمان تشخیص (MTTD) و میانگین زمان بازیابی (MTTR) رو دنبال کنید. اگه تشخیص کنده، مانیتور اضافه کنید یا دقیق‌ترشون کنید؛ اگه بازیابی کنده، runbookها و ابزارها رو بهتر کنید.

پرسش‌های پرتکرار

• اگه مشتری‌هامون فقط ساعت کاری کار می‌کنن، باز هم آنکال لازمه؟

  +

  هنوز یه نفر باید در ساعت کاری مسئول باشه. آنکال بیرون از ساعت کاری وقتی لازم می‌شه که قطعی شب یا تعطیلات براتون پول یا اعتماد هزینه داشته باشه.

• چند هشدار در یه هفته‌ی آنکال زیاده؟

  +

  اگه نفر آنکال بیشتر از یکی دو بار در هفته از خواب بیدار بشه، هشدارها نیاز به اصلاح دارن. بیشتر شب‌ها باید آروم باشن.

• برنامه‌نویس‌ها هم باید آنکال باشن؟

  +

  وقتی کسایی که یه سرویس رو می‌سازن خودشون هم اداره‌اش می‌کنن، خوب جواب می‌ده؛ می‌دونن کجا رو نگاه کنن. اعضای جدید رو در چند چرخه‌ی اولشون با آدم‌های باتجربه همراه کنید.