عندما ينهار الإنتاج، أول سؤال يجب على كل مهندس يحمل المناوبة الإجابة عنه هو: ما مدى خطورة الأمر؟ مستويات الخطورة تمنح الشركة بأكملها مفردات مشتركة للإجابة عن هذا السؤال في ثوانٍ — وسياسات التصعيد تحدد من يتم إيقاظه حين تكون الإجابة "خطير جداً". معاً يشكّلان هيكل عظمي لعملية الاستجابة للحوادث. بدونهما، تُهدر الفرق أول عشر دقائق من حادثة P0 في النقاش عما إذا كانت P0 أصلاً.
لماذا التصنيف الموحّد مهم؟
مستويات الخطورة ليست بيروقراطية — بل تحرّك قرارات ملموسة: أي دليل تشغيل تفتح، وكم مهنداً تستدعي، وما إذا كنت ستتصل بالمدير التنفيذي، وما هو الحد الزمني المقبول للتعافي. جوجل وPagerDuty وأتلاسيان ومعظم مؤسسات SRE الكبيرة تتقارب حول مقياس SEV 1 – SEV 4 (أو P0 – P4). الأرقام تتفاوت قليلاً بين الشركات، لكن المنطق واحد: الخطورة تعكس تأثير المستخدم والمخاطر التجارية، لا التعقيد التقني.
المقياس الرباعي المعياري
الجدول أدناه يُعبّر عن المستويات المستخدمة في معظم شركات التقنية الكبيرة. احفظ هذا النمط عن ظهر قلب — المحاورون وقادة الحوادث يتوقعون منك ذكره فوراً.
سلّم الخطورة الرباعي المعياري المستخدم في معظم شركات التقنية الكبيرة — كل مستوى يحرّك أوقات استجابة محددة ومسارات تصعيد.
الخطورة تتعلق بتأثير العميل، لا بالصعوبة التقنية. خطأ معقد لكن غير مرئي في خط أنابيب تقارير داخلية هو SEV 4. خطأ في سطر واحد من الإعدادات يوقف المدفوعات هو SEV 1. لا تدع التعقيد الهندسي يرفع مستوى خطورة حادثة لا يشعر بها أي عميل.
كتابة تعريف خطورة لا يُنسى
التعريفات المبهمة تسبب جدالاً في أسوأ الأوقات. كل مستوى SEV يحتاج إلى ثلاثة أشياء: عتبة تأثير قابلة للقياس على العميل، وSLA للإقرار بالحادثة، وهدف تصعيد صريح. هذا تعريف واقعي لـ SEV 1 يمكنك وضعه في دليل التشغيل اليوم:
# SEV1 — Critical Incident Definition
# Trigger ANY of the following:
conditions:
- error_rate > 10% # across all requests, sustained > 2 min
- p99_latency > 10s # on any public-facing endpoint
- payment_success_rate < 95%
- auth_login_success_rate < 90%
- full_region_unavailable: true
- data_loss_confirmed: true
response:
ack_sla: 5m # page escalates if no ACK within 5 minutes
bridge_open: true # war-room Slack channel + Zoom bridge opened immediately
exec_notify: true # VP Engineering + on-call PM notified
status_page: true # public status page updated within 10 min
# Once you declare SEV1, do NOT downgrade mid-incident.
# Downgrade only during postmortem if impact is confirmed lower.
سياسات التصعيد وأشجار الإنذار
سياسة التصعيد هي تسلسل الأشخاص الذي يسير خلاله نظام التنبيه عندما لا يتم الإقرار بالحادثة. PagerDuty وOpsgenie وVictorOps تُمثّل هذا كـشجرة إنذار: إذا لم يُقرّ الشخص A خلال N دقائق، أرسل إنذاراً للشخص B؛ وإذا لم يستجب B، أرسل للشخص C؛ وهكذا صعوداً حتى نقطة توقف التصعيد.
شجرة الإنذار المصممة جيداً تتكون من ثلاث طبقات:
المناوب الأول — المهندس الحامل حالياً لمسؤولية الخدمة. يُنذَر أولاً لكل حادثة.
المناوب الثاني — الاحتياطي، وعادةً ما يكون مناوب الأسبوع الماضي. يُنذَر إذا لم يُقرّ المناوب الأول خلال نافذة SLA الخاصة بمستوى الخطورة.
المدير أو قائد المجال — يُنذَر فقط عند SEV 1 أو SEV 2 التي تجاوزت المستويين دون إقرار، أو فوراً في SEV 1 المُعلن. لا يُصلح الحادثة أبداً — بل يُزيل العقبات أمام من يفعلون ذلك.
افصل شجرة التصعيد التقنية عن شجرة تصعيد التواصل. المهندسون يُصعّدون للأعلى طلباً للمساعدة. التواصل (صفحة الحالة، تحديثات الإدارة، رسائل العملاء) مسار موازٍ يملكه قائد الحادثة أو دور التواصل. الخلط بين المسارين يعني أن المهندسين يكتبون رسائل للعملاء بينما النظام لا يزال متوقفاً.
هذه سياسة تصعيد في PagerDuty معبّراً عنها كأكواد باستخدام موفر Terraform — وهو بالضبط كيف تُدار أنظمة المناوبة في الشركات التي تتبنى البنية التحتية ككود:
resource "pagerduty_escalation_policy" "payments_sev1" {
name = "Payments SEV1 Escalation"
num_loops = 2 # repeat the chain twice before giving up
rule {
escalation_delay_in_minutes = 5
target {
type = "user_reference"
id = pagerduty_user.on_call_primary.id
}
}
rule {
escalation_delay_in_minutes = 5
target {
type = "user_reference"
id = pagerduty_user.on_call_secondary.id
}
}
rule {
escalation_delay_in_minutes = 5
target {
type = "user_reference"
id = pagerduty_user.payments_eng_lead.id
}
}
rule {
escalation_delay_in_minutes = 10
target {
type = "user_reference"
id = pagerduty_user.vp_engineering.id
}
}
}
إعداد num_loops = 2 يعني أن النظام يدور عبر المستويات الأربعة مرتين (إجمالي 50 دقيقة) قبل التوقف، وعندها يُطلق PagerDuty تنبيه "لم يستجب أحد" إلى قناة Slack مخصصة حتى يتدخل إنسان يدوياً.
مخطط التصعيد: من التنبيه إلى الإدارة التنفيذية
شجرة إنذار SEV 1: التصعيد التقني (يسار) يسير بالتوازي مع مسار التواصل (يمين)، كلاهما يبدأ من اللحظة الصفر.
أنماط التصعيد الخاطئة التي يجب تجنبها
حتى مع سياسة مصممة جيداً، تقع الفرق في مصائد متوقعة:
تضخيم الخطورة — تسمية كل شيء SEV 1 حتى لا يُهمل. هذا يدمر الإشارة. إذا رأى فريق المناوبة ثلاثة تنبيهات SEV 1 في الأسبوع وواحد فقط حقيقي، سيبدأون بتجاهلها.
تقليل الخطورة — إعلان المهندسين مستوى أدنى تجنباً لإيقاظ مديرهم. أرسخ في ثقافة فريقك أن إعلان SEV 1 بحسن نية لن يُعاقب عليه أحد.
غياب التصعيد التلقائي — الاعتماد على المهندس المناوب ليطلب المساعدة يدوياً. المهندسون في أزمة ينسون. أتمتة ذلك: إذا لم تنتقل بطاقة الحادثة إلى "قيد المعالجة" خلال 20 دقيقة من إعلان SEV 1، فليُعد PagerDuty إنذار المناوب الثاني تلقائياً.
التصعيد المبكر للإدارة — إنذار نواب الرئيس لـ SEV 3 يخلق تعباً من التنبيهات على مستوى القيادة ويُضعف الثقة في منظومة المراقبة.
إعادة تقييم الخطورة أثناء الحادثة إلزامية. حادثة تبدأ كـ SEV 3 يمكن أن تتحول إلى SEV 1 خلال دقائق إذا كشف تحليل السبب الجذري أن النطاق المتضرر أوسع مما قُدّر. ادرج نقطة تفتيش في عملية الحادثة: أعد تقييم الخطورة كل 15 دقيقة للحوادث النشطة. إهمال رفع الخطورة يؤخر التصعيد ويتركك بموارد غير كافية.
ربط الخطورة بـ SLOs
المؤسسات الأكثر نضجاً تُشتق فيها الخطورة تلقائياً من مؤشرات مستوى الخدمة (SLOs). إذا أطلق تنبيه PromQL ومعدل استهلاك ميزانية الخطأ تجاوز عتبة ما، تُحسب الخطورة بدلاً من تخمينها. مثال على تنبيه معدل احتراق متعدد النوافذ عند مستوى SEV 1:
لاحظ تسمية escalation_policy — عندما يُوجّه Alertmanager هذا التنبيه إلى PagerDuty، تُعيّن هذه التسمية مباشرةً إلى اسم سياسة التصعيد، فتُطلق شجرة الإنذار الصحيحة تلقائياً. لا يحتاج أي إنسان لاتخاذ قرار من يتصل به.
ضع سياسات التصعيد في نظام التحكم بالإصدارات جنباً إلى جنب مع قواعد التنبيه. عندما يغادر أحد أعضاء الفريق أو يتغير الجدول الزمني للمناوبة، يُظهر terraform plan الفرق. أنظمة المناوبة التي تعيش فقط في واجهة PagerDuty بعيدة تحديث واحد منسي عن إنذار الشخص الخطأ بصمت.
مستويات الخطورة وسياسات التصعيد بنية تحتية حاملة للحمل. إنها ليست وثائق تجلس في ويكي — بل عقود قابلة للتنفيذ بين منظومة المراقبة والمهندسين المناوبين والعملاء. عاملها بنفس الانضباط الذي تطبقه على بيانات Kubernetes: تحت التحكم بالإصدارات، ومختبرة، ومراجعة قبل أي تغيير.
نستخدم ملفات تعريف الارتباط لتشغيل هذا الموقع وتحليل الزيارات وعرض إعلانات مخصّصة. يمكنك قبول كل ملفات تعريف الارتباط أو رفض غير الأساسية منها.
سياسة الخصوصية