كُتيِّبات الحوادث التي تُنفَّذ تلقائياً: من runbook إلى runtime

ثلاثة أسباب:

• الضغط يُضيِّق الانتباه. الدماغ تحت الضغط الحاد يتجه تلقائياً إلى pattern-matching. • ضغط الوقت يتجاوز الصواب. يفترض المهندس 'أعرف ما الذي يُحتمَل أن يكون خطأ'. • تعفُّن Runbook. الخطوة 3 تقول 'ssh إلى prod-db-01' لكن ذلك host أُلغي.

كل من هذه مشكلة لا يستطيع المستند حلها — تحتاج تنفيذاً.

المستند يصف. الكُتيِّب يفعل.

المستند يقول: 'الخطوة 2: أعد تشغيل مجموعة workers.' الكُتيِّب القابل للتنفيذ لديه زر، عند النقر، يُجري استدعاء API، ينتظر الإشارة الخضراء، ويسجِّل النتيجة في الخط الزمني للحادث.

الخاصية الثانية للكُتيِّب الحقيقي هي أن كل خطوة قابلة للتدقيق.

تستطيع Playbooks AlertsDock التشغيل التلقائي على حدث `monitor_down`.

متى يساعد التشغيل التلقائي: • العلاج الحتمي (مسح الذاكرة المؤقتة، إعادة تشغيل pool stateless). • جمع التشخيصات. • Paging والتصعيد.

متى يُحدِث التشغيل التلقائي ضوضاء: • أي إجراء مُدمِّر (scale down، إنهاء اتصالات). اطلب تأكيداً يدوياً. • أي شيء يُعيد تشغيل تتالي تنبيهات أخرى.

القاعدة: نفِّذ التشخيص والعلاج غير المُدمِّر تلقائياً. اقفل الإجراءات المُدمِّرة خلف نقرة بشرية.

Playbook جيد ليس مُؤتمَتاً بالكامل — إنه خليط من الإجراءات المُؤتمَتة التي يُجيدها الحاسوب، والنقاط اليدوية التي يُجيدها الإنسان.

• آلي — اجلب آخر 5 آثار خطأ من log pipe. • Checkbox يدوي — 'هل تحققت من أن النشر السابق تم التراجع عنه؟' • آلي-مع-زر — 'أعد تشغيل API workers' (نقرة واحدة). • Checkbox يدوي — 'هل أبلغت الدعم برقم حادث؟'

كل تشغيل playbook يُنتج خطاً زمنياً كاملاً: اسم الخطوة، من شغَّلها، الطابع الزمني، المدخلات، المخرجات.

في المراجعة تسأل:

• أي خطوات استغرقت أطول من المتوقع؟ • أي خطوات يدوية تم تخطِّيها تحت الضغط؟ • أي خطوات آلية أنتجت مخرجات غير متوقعة؟ • هل كانت هناك خطوة تشخيصية نتمنى لو أضفناها؟

مراجعة جيدة تنتهي بتعديلات على الكُتيِّب نفسه.