وصل إشعار يقول إن الخدمة لا تستجيب. بعده وصلت رسائل أخرى عن قاعدة البيانات والمهام الخلفية، لكن لم يسجل أحد بدء التعامل مع الحادث. إذا كنت تشتري مراقبة سيرفرات، فاسأل عما يحدث بعد وصول التنبيه: من يقرؤه، ومن يتصرف، وما الذي يثبت عودة الوظيفة التي تعطلت؟
يمكن أن تنجح أداة الإرسال بينما تفشل خدمة الاستجابة. ويمكن أن يعود الخادم للعمل بينما تظل مهمة أعمال أساسية متوقفة. اجعل نطاق المراقبة يصف رحلة حادث واحدة من الإشارة إلى الإغلاق، مع أدوار وأدلة وحدود تفويض، بدل قائمة أسماء أدوات ورسوم فقط.
ابدأ بالأثر الذي يستدعي تدخلًا
في مثال افتراضي، تستقبل منصة طلبات صيانة وتضع إرسال التأكيد في مهمة خلفية. الصفحة تفتح، لكن الرسائل لا تخرج. قد يحتاج الفريق مراقبة تراكم العمل أو فحص نتيجة مناسبة، إلى جانب قياس استجابة الخادم. هذه حالة تعليمية، وليست عطلًا وقع لدى عميل أو التزامًا تبيعه نكست ويف بزمن محدد.
اكتب الخدمات والوظائف المشمولة وما لا يشمله العرض. يختلف تنبيه امتلاء مساحة يقترب من حد معروف عن تقرير اتجاه استخدام طويل المدى. لا تحوّل كل تغير صغير إلى اتصال عاجل؛ يناقش مرجع Google SRE قيمة الإشارة المفيدة وخطر الضجيج الذي يجعل الناس يتجاهلون التنبيهات.
سجل حادث يفصل خمس لحظات
| اللحظة | الدليل المطلوب | سؤال المسؤولية |
|---|---|---|
| اكتشاف الإشارة. | القياس والشرط والخدمة والفترة المتأثرة. | هل المراقبة تعمل وهل العينة تدل على المشكلة؟ |
| وصول وإقرار. | استلام الجهة ثم قبول شخص أو دور متابعة الحادث. | من البديل إن لم يحدث الإقرار؟ |
| تشخيص واحتواء. | ما فُحص وما نُفذ وحدود أثر الإجراء. | من يملك الوصول والموافقة على التغيير؟ |
| عودة الخدمة. | فحص الوظيفة المتأثرة وما بقي متراكمًا. | من يتحقق من عودة العمل للمستخدم؟ |
| إغلاق ومراجعة. | تسلسل زمني ومجهول متبقٍ وإجراء تحسين بمالك. | من يتابع السبب بدل الاكتفاء بزوال الإشارة؟ |
لا تفترض أن هذه اللحظات لها المدة نفسها. بدء الاستجابة ليس وعد إصلاح، وزوال العرض لا يثبت معرفة السبب الجذري. يحدد عرض الخدمة ساعات التغطية والمنطقة الزمنية وقواعد التصعيد ومعاني الأزمنة المتفق عليها، مع ما يعتمد على مطور التطبيق أو مزود خارجي.
اختبر الإجراء بصلاحياته الفعلية
اطلب دليل تصرف مختصرًا لكل تنبيه مهم: ما الذي يتحقق منه المسؤول أولًا، وما الإجراءات المسموحة، ومتى يتوقف ويصعد. إعادة تشغيل عشوائية قد تخفي الدليل أو تعيد عملًا غير مناسب. يحتاج الإجراء المؤثر إلى حدود وموافقة معروفتين، لا كلمة مرور شاملة موزعة على جميع المستلمين.
في منصة الصيانة الافتراضية، حدد هل مشغّل البيئة يفحص العامل الخلفي فقط، أم يستطيع معالجة بيانات الطلب أو تعديل الكود. إذا احتاج دورًا آخر، فاكتب مسار التسليم والمعلومات المطلوبة. لا تجعل المورد يعد بحل مشكلة خارج صلاحياته دون بيان اعتماده على الجهة المخولة.
تجميع الرسائل لا يغني عن متابعة الحادث
تشرح وثائق Alertmanager تجميع التنبيهات المتشابهة وتوجيهها وكتمها لفترة ومنع إشعارات مرتبطة بعطل أصل. هذه أدوات لتقليل الضجيج، وليست دليلًا على أن شخصًا شخّص الحادث. اطلب معرفة كيف يرتبط التنبيه المجمع بسجل عمل، وما المعلومات التي تبقى متاحة لفهم الخدمات المتأثرة.
عند صيانة مخططة، اتفق على مدة الكتم وصاحبه ووقت انتهائه وطريقة التأكد من عودة التغطية. واسأل كيف يكتشف الفريق توقف نظام المراقبة أو قناة الإشعار نفسها. وجود لوحة تعمل في مكتب المورد لا يضمن أن الإشارة ستصل في الوقت الذي يغيب فيه الشخص المعتاد.
تجربة قبول لا تعطل عملاءك
في بيئة معزولة أو تمرين معتمد محدود، أنشئ إشارة اختبار واضحة وراقب التوجيه والإقرار والتصعيد وانتهاء الحالة. لا توقف خدمة حية لمجرد اختبار البريد. ثم راجع سجلًا نموذجيًا لحادث وتأكد أن الفريق يستطيع تفسير كل وقت وإجراء دون نسخ أسرار أو بيانات عميل إلى التقرير.
توزع مصفوفة التشغيل السحابي المسؤوليات العامة، ويشرح دليل DevOps تسليم عملية النشر. عند طلب مراقبة وتشغيل السحابة من نكست ويف، أرفق سجل الحادث وإجراء التنبيه لتقارن خدمة استجابة محددة لا مجرد عدد إشعارات.
مصادر التشغيل
فُتح فصل مراقبة الأنظمة لدى Google SRE وتوثيق Alertmanager في 4 نوفمبر 2026. السجل والمثال مقترحان أصليان، دون ضمان توافر أو زمن إصلاح. استعان الإعداد بالذكاء الاصطناعي مع مراجعة المعلومات والترجمة.
