إدارة الحوادث والمناوبة

أدوات إدارة الحوادث

18 دقيقة الدرس 9 من 28

أدوات إدارة الحوادث

الأدوات لا تحل محل العملية، لكن الأدوات الصحيحة تُزيل الاحتكاك في اللحظات التي يكون فيها الاحتكاك أشد تكلفةً — الدقائق الأولى من P0 حيث تُكلّف كل ثانية من الارتباك مالاً وثقة المستخدمين. في شركات مثل Stripe وGitHub وCloudflare، تُعامَل أدوات الحوادث باعتبارها استثماراً هندسياً من الدرجة الأولى، لا فكرة لاحقة. يتناول هذا الدرس الركائز الثلاث لأدوات الحوادث الحديثة: إدارة التنبيهات والمناوبة (PagerDuty / Opsgenie)، وتكامل ChatOps (بوتات الحوادث وسير عمل Slack)، والجداول الزمنية الآلية للحوادث.

هدف أدوات الحوادث: تقليل العبء المعرفي في أصعب اللحظات. كل ثانية يقضيها مهندس في معرفة كيفية تنبيه شخص ما، أو أين قناة الحادث، أو ماذا حدث قبل خمس دقائق، هي ثانية لا تُنفق في إصلاح المشكلة. الأدوات الجيدة تجعل الإجراء الصحيح هو الإجراء الأسهل.

PagerDuty وOpsgenie: أكثر من مجرد نظام تنبيه

PagerDuty وOpsgenie (جزء من Atlassian الآن) هما المنصتان السائدتان لإدارة المناوبة على نطاق المؤسسات. كلتاهما تشتركان في نفس النموذج المفاهيمي: الخدمات تستقبل التنبيهات من أنظمة المراقبة، وسياسات التصعيد تحدد من يُخطَر وبأي ترتيب، والجداول الزمنية تحدد من هو في المناوبة في أي لحظة. فهم نموذج البيانات أمر ضروري لأن الخطأ فيه يخلق ثغرات صامتة في التنبيهات — وضع فشل إنتاجي يُطلق فيه التنبيه لكن لا يستقبله أحد.

نموذج توجيه تنبيهات PagerDuty: من مصدر التنبيه في المراقبة عبر إزالة التكرار في الخدمة وسياسة التصعيد وجدول المناوبة وصولاً إلى المهندس الذي يُستدعى.

أهم إعداد في PagerDuty يجب الحرص على صحته هو مفتاح تكامل الخدمة وسياسة التصعيد. فشل إنتاجي شائع هو فريق يُنشئ خدمة ويوجّه جميع تنبيهاته إليها، لكنه ينسى إرفاق سياسة تصعيد — فتُطلَق التنبيهات وتُدمج وتسقط بصمت دون أن يُخطَر أحد. تحقق دائماً بإرسال تنبيه اختباري عبر السلسلة الكاملة.

# PagerDuty: إنشاء خدمة عبر REST API (تُدار بـ Terraform في الإنتاج)
# هذا المكافئ الإجرائي لما يفعله pd-terraform-provider بشكل تصريحي

curl -s -X POST https://api.pagerduty.com/services \
  -H "Authorization: Token token=$PD_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "service": {
      "name": "payments-api",
      "description": "Payments service — owns checkout and billing flows",
      "escalation_policy": {
        "id": "P3QLXYZ",
        "type": "escalation_policy_reference"
      },
      "alert_creation": "create_alerts_and_incidents",
      "alert_grouping_parameters": {
        "type": "intelligent"
      },
      "acknowledgement_timeout": 600,
      "auto_resolve_timeout": 14400
    }
  }'

# مكافئ Opsgenie عبر Terraform
# resource "opsgenie_service" "payments" {
#   name      = "payments-api"
#   team_id   = opsgenie_team.backend.id
# }

أنماط PagerDuty / Opsgenie الرئيسية على نطاق الشركات الكبرى

تجميع التنبيهات وتقليل الضوضاء. على نطاق واسع، قد تُنتج إخفاقة بنية تحتية واحدة مئات التنبيهات في الدقيقة. كلتا المنصتين توفران التجميع: "تجميع التنبيهات الذكي" في PagerDuty (يعتمد على التعلم الآلي) و"سياسات التنبيه" في Opsgenie تدمج التنبيهات المترابطة في حادث واحد. بدون التجميع، يستقبل مهندس المناوبة 200 تنبيه في 60 ثانية لما هو في جوهره قاعدة بيانات واحدة متوقفة — يبدأ إجهاد التنبيهات في غضون دقائق ويبدأ المهندس بالتأكيد دون قراءة.

نوافذ الصيانة. اكبت التنبيهات خلال الصيانة المخططة. نسيان فتح نافذة صيانة قبل ترقية قاعدة البيانات هو السبب الأكثر شيوعاً لتنبيهات P1 غير الضرورية في المنظمات المتوسطة والكبيرة. كلتا المنصتين تدعمان النوافذ المتكررة والإنشاء عبر API حتى تستطيع خطوط النشر لديك فتح النوافذ وإغلاقها تلقائياً.

مسرحيات الاستجابة (PagerDuty) / سياسات الإشعار (Opsgenie). سير عمل استجابة محددة مسبقاً تُضيف المستجيبين تلقائياً، وتُنشئ جسر مؤتمر، وتنشر على Slack حين يُطلَق P0. هذا يُلغي فوضى "من أتصل به؟" بجعل تجميع الفريق الصحيح تلقائياً.

استخدم دائماً مفتاح رجل ميت لخط أنابيب التنبيه نفسه. يتوقع تكامل "Heartbeat" في PagerDuty (أو Opsgenie) استقبال POST HTTP دوري من AlertManager. إذا توقف POST عن الوصول، يُنبّه PagerDuty. بدون هذا، يكون AlertManager المعطّل غير مرئي — مراقبتك متوقفة ولا تعلم. اضبطه كالتالي: POST https://events.pagerduty.com/integration/<KEY>/send كل 60 ثانية من cron يعمل بشكل مستقل عن مكدسك الرئيسي.

ChatOps: بوتات الحوادث وتكامل Slack

ChatOps هو ممارسة قيادة سير العمل التشغيلي عبر منصة دردشة — إنشاء الحوادث، وتشغيل التشخيصات، وتنفيذ الإصلاحات، ونشر تحديثات الحالة، كل ذلك من داخل Slack (أو Teams). في شركات مثل GitHub وShopify وLinkedIn، تُعدّ قناة الدردشة غرفة عمليات الحادث: كل ما يحدث خلال الحادث مرئي في موضوع واحد قابل للتصفح، مما يخلق سجلاً تدقيقياً تلقائياً ويحافظ على تزامن الفرق الموزعة.

قدرات ChatOps الأساسية لإدارة الحوادث هي:

إعلان الحادث: أمر slash (/incident declare payments-api-down sev1) يُنشئ حادث PagerDuty، وينشئ قناة Slack مخصصة، ويدعو مهندس المناوبة والمعنيين ذوي الصلة، وينشر أول تحديث للحالة — كل ذلك في إجراء واحد.
البحث في دليل التشغيل: /runbook payments high-error-rate ينشر رابط دليل التشغيل ذي الصلة والأوامر الرئيسية مباشرة في القناة، حتى لا يضطر المهندسون لمغادرة سياق الحادث للبحث في wiki.
تحديثات صفحة الحالة: /statuspage update major_outage "Investigating elevated error rates on checkout" يدفع إلى Atlassian Statuspage أو Cachet بدون مغادرة Slack.
التصعيد: /page @backend-team This is a P0, need immediate help يُشغّل PagerDuty ويسحب مستجيبين إضافيين دون أن يحتاج أحد لمعرفة جدول دوران الفريق.

البوت الأكثر انتشاراً في المنظمات الكبيرة هو Rootly أو FireHydrant أو بوت مخصص مبني على Slack Bolt SDK. الثلاثة يتبعون نفس النموذج: يستمعون لأوامر slash، ويستدعون PagerDuty / Opsgenie API، ويديرون دورة حياة القناة، ويقودون تحديثات الحالة.

# Slack Bolt (Python) — هيكل بوت حوادث مبسّط
# البوتات الإنتاجية تضيف استدعاءات PD API وقاعدة بيانات وتكامل صفحة الحالة

from slack_bolt import App
from slack_bolt.adapter.socket_mode import SocketModeHandler
import requests, os

app = App(token=os.environ["SLACK_BOT_TOKEN"])
PD_TOKEN = os.environ["PD_API_TOKEN"]
PD_SERVICE_ID = os.environ["PD_SERVICE_ID"]

@app.command("/incident")
def declare_incident(ack, command, client, say):
    ack()
    text = command["text"]          # مثال: "payments-api-down sev1"
    parts = text.split()
    title, sev = parts[0], parts[1] if len(parts) > 1 else "sev2"

    # 1. إنشاء حادث PagerDuty
    pd_resp = requests.post(
        "https://api.pagerduty.com/incidents",
        headers={"Authorization": f"Token token={PD_TOKEN}", "Content-Type": "application/json"},
        json={"incident": {"type": "incident", "title": title, "service": {"id": PD_SERVICE_ID, "type": "service_reference"}, "urgency": "high"}}
    ).json()
    inc_id = pd_resp["incident"]["id"]
    inc_url = pd_resp["incident"]["html_url"]

    # 2. إنشاء قناة Slack مخصصة
    chan = client.conversations_create(name=f"inc-{inc_id.lower()}")
    chan_id = chan["channel"]["id"]

    # 3. نشر الرسالة الأولية
    client.chat_postMessage(channel=chan_id, text=f":rotating_light: *{sev.upper()} Incident Declared*\n*Title:* {title}\n*PD:* {inc_url}\n*IC:* <@{command['user_id']}>\n*Status:* Investigating")
    say(f"Incident declared. Channel: <#{ chan_id }> | PD: {inc_url}")

if __name__ == "__main__":
    SocketModeHandler(app, os.environ["SLACK_APP_TOKEN"]).start()

مصيدة إنتاجية — تضخم صلاحيات البوت. تتراكم على بوتات الحوادث نطاقات Slack مع مرور الوقت مع إضافة الميزات. البوت الذي يبدأ بـ channels:write وchat:write غالباً ما ينتهي بـ files:write وusers:read وadmin.conversations:write بحلول وصوله إلى الإنتاج. راجع نطاقات OAuth للبوت ربع سنوياً. رمز بوت مخترق بصلاحيات admin هو حادث أمني بالغ — أسوأ بكثير من ثغرة تنبيه.

الجداول الزمنية للحوادث: سجل التدقيق التلقائي

الجدول الزمني للحادث هو سجل زمني لكل حدث ذي معنى خلال الحادث: متى أُطلق التنبيه، متى استُدعي قائد الحادث وأكّد الاستلام، متى اختُبرت كل فرضية، متى حدث التراجع، متى تعافت مؤشرات SLO، متى أُغلق الحادث. في Google وStripe، يُملأ هذا الجدول تلقائياً من تكاملات الأدوات ويخدم كمدخل رئيسي لكتابة التحليل اللاحق.

الجدول الزمني قيّم لثلاثة أسباب:

دقة التحليل اللاحق: الذاكرة البشرية تتدهور سريعاً تحت الضغط. يُخطئ المهندسون باستمرار في تذكّر تسلسل الأحداث وتوقيتها بنسبة 10-30% خلال 24 ساعة. الجدول الزمني التلقائي يُزيل هذا التشويه.
حساب المقاييس: تُحسب TTD وTTM وTTR من طوابع وقت الجدول الزمني. الإبلاغ اليدوي عن TTR متفائل دائماً تقريباً — تميل الفرق لتذكّر الحل في وقت أبكر مما كان.
تحليل الأنماط: عبر عشرات أو مئات الحوادث، تكشف الجداول الزمنية أنماطاً منهجية: أي فريق يستغرق باستمرار 45 دقيقة للتأكيد، أي خدمة تظهر دائماً في الكاسكادات، أي خطوة من دليل التشغيل يتم تخطيها دائماً.

المنصات الحديثة (Rootly وFireHydrant وPagerDuty Operations Cloud) تملأ الجداول الزمنية تلقائياً بالتكامل مع PagerDuty (طوابع وقت التنبيه) وSlack (طوابع وقت الرسائل) وGitHub (أحداث النشر) ومكدس المراقبة (متى تجاوزت مؤشرات SLO الحدود). النتيجة جدول زمني دقيق بالثانية، لا يتطلب أي جهد يدوي خلال الحادث نفسه.

# FireHydrant REST API: إضافة حدث جدول زمني يدوي خلال حادث
# (الأحداث التلقائية تأتي من التكاملات؛ الإدخالات اليدوية للقرارات/الفرضيات)

curl -X POST "https://api.firehydrant.io/v1/incidents/$INCIDENT_ID/milestone_updates" \
  -H "Authorization: Bearer $FH_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "occurred_at": "2025-03-14T14:42:00Z",
    "body": "Hypothesis: deploy abc123 introduced N+1 query in checkout flow. Rolling back now.",
    "type": "hypothesis"
  }'

# PagerDuty: إضافة ملاحظة (تظهر في الجدول الزمني والتحليل اللاحق)
curl -X POST "https://api.pagerduty.com/incidents/$PD_INCIDENT_ID/notes" \
  -H "Authorization: Token token=$PD_API_TOKEN" \
  -H "From: oncall@example.com" \
  -H "Content-Type: application/json" \
  -d '{
    "note": {
      "content": "Rolled back to v1.4.2 at 14:43 UTC. Monitoring error rate — expect recovery within 3 minutes."
    }
  }'

اختيار سلسلة الأدوات ودمجها

تبدو سلسلة أدوات الحوادث الإنتاجية المعيارية في منظمة تُدار بشكل جيد كالتالي: Prometheus / Datadog ← PagerDuty / Opsgenie ← Slack (بوت حوادث) ← Statuspage ← Rootly / FireHydrant (جدول زمني + تحليل لاحق). كل أداة تؤدي شيئاً واحداً بشكل جيد وتمرر السياق إلى التالية عبر webhooks وAPIs. نقاط التكامل الرئيسية هي:

المراقبة ← PagerDuty: استخدم Events v2 API لا v1. يدعم v2 مفاتيح dedup والخطورة من حمولة التنبيه وتجميع التنبيهات. اضبط dedup_key على معرّف ثابت (اسم الخدمة + اسم التنبيه) لمنع الحوادث المكررة عند تذبذب التنبيهات.
PagerDuty ← Slack: استخدم تكامل PagerDuty الأصلي مع Slack أو webhook لبوت الحوادث. يجب أن ينشئ البوت القناة تلقائياً حين يُشغَّل الحادث، لا حين يُؤكَّد — التأخير هنا يكلف دقائق.
Slack ← صفحة الحالة: يجب أن يكون كل تحديث لصفحة الحالة أمراً واحداً، لا عملية يدوية من ثلاث خطوات. المهندسون تحت الضغط يتخطون الخطوات؛ الأتمتة لا تفعل.
جميع الأدوات ← مُجمّع الجدول الزمني: Rootly أو FireHydrant أو خدمة جدولك الزمني الخاصة تشترك في webhooks من جميع المصادر وتدمجها في عرض زمني واحد مرتّب حسب معرّف الحادث.

ابدأ بـ PagerDuty + Slack، ثم طوّر تدريجياً. الإغراء في الشركات المبكرة هو بناء بوت حوادث مخصص قبل تحديد العملية. قاومه. استخدم تكامل PagerDuty الأصلي مع Slack واتفاقية تسمية قناة بسيطة لستة أشهر. بحلول ذلك الوقت ستعرف بالضبط أي الأتمتة توفّر وقتاً حقيقياً مقابل ما يبدو جيداً في العرض التوضيحي. ابنِ أو تبنّ بوتاً كاملاً فقط حين تكون نقاط الاحتكاك واضحة تجريبياً.