Runbook للحوادث عندما تتعطل عشرات البروفايلات في وقت واحد

إذا تعطلت 50 بروفايل في دقائق، معالجة كل واحد يدويًا غالبًا تضيع الوقت وتزيد الضرر. النمط المتزامن يعني أن هناك dependency مشتركة محتملة: Proxy provider، DNS، release، extension، disk pressure، أو backend داخلي. Runbook يفرض ترتيبًا ثابتًا لجمع الأدلة وتقليل التغييرات أثناء الحادث.

أعلن Incident ووقف التغييرات الواسعة

عيّن incident ID وقائدًا، وأوقف bulk actions أو deployments غير الضرورية حتى تفهم السبب. لا تجعل عدة أشخاص يغيرون proxies و settings في الوقت نفسه.

حدد Scope بسرعة

كم بروفايل؟ أي OS/version/group/provider؟ هل البروفايلات غير المتأثرة تشترك في شيء؟ Matrix affected/unaffected أقوى من قراءة logs عنصرًا عنصرًا.

افحص Dependencies المشتركة

DNS، Proxy health، disk، auth service، update rollout، extensions. استخدم checks read-only أولًا. إذا المشكلة خارجية، لا تعدل البروفايلات لتعويضها.

اختر Canary للإصلاح

طبّق أي تغيير على 1–3 بروفايلات اختبار أولًا. راقب النجاح مدة معقولة ثم وسع تدريجيًا. هذا يمنع إصلاحًا خاطئًا من الوصول لكل الحسابات.

حافظ على Evidence

قبل reset أو delete، احفظ logs/metadata اللازمة دون secrets. تغييرات كثيرة تمحو الحالة الأصلية وتصعب root cause.

تواصل بحالة مختصرة

حدث الفريق بما نعرفه وما لا نعرفه والإجراء الحالي ووقت التحديث التالي. لا ترسل تخمينات كحقائق. اربط handovers بنفس incident ID.

أغلق الحادث ب Postmortem

حدد trigger وسبب الانتشار وسبب عدم اكتشافه مبكرًا، ثم actions قابلة للقياس: alert أو test أو circuit breaker. لا يقتصر التقرير على أصلحنا وأعدنا التشغيل.

اختبر السياسة على سيناريو فريق حقيقي

في «Runbook للحوادث عندما تتعطل عشرات البروفايلات في وقت واحد» اكتب ثلاث حالات: موظف جديد، عضو يغير دوره، وعضو يغادر الفريق. مرر كل حالة على الصلاحيات والموافقات وسجل من يستطيع القراءة أو التعديل أو النشر في كل مرحلة. راقب أيضًا الحسابات المشتركة والمهام المجدولة لأنها قد تستمر بعد تغيير دور المستخدم. المراجعة الفعالة لا تعتمد على جدول أدوار جميل فقط؛ يجب أن تكشف صلاحية زائدة يمكن استغلالها بعد تغير المسؤولية. أعد هذا الاختبار دوريًا واربط الاستثناءات بتاريخ انتهاء ومالك واضح.

معيار القبول قبل الإغلاق

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

حالة فشل يجب اختبارها

اختبر «Runbook للحوادث عندما تتعطل عشرات البروفايلات في وقت واحد» بحساب لا يملك أي دور إضافي ثم امنحه أقل صلاحية لازمة. إذا اضطررت لمنحه دورًا واسعًا حتى تعمل مهمة واحدة، فهذه فجوة في نموذج الصلاحيات. سجّل الاستثناء بدل تركه دائمًا، وأعد مراجعته عند تغيير مسؤوليات الفريق.

توثيق النتيجة للفريق

بعد الانتهاء من اختبار «Runbook للحوادث عندما تتعطل عشرات البروفايلات في وقت واحد»، احفظ ملخصًا قصيرًا يوضح البيئة والخطوات والنتيجة وما الذي تغير عن ال ـbaseline. أرفق أكواد الأخطاء أو المقاييس الضرورية فقط، واربطها برقم الإصدار. هذا السجل يجعل المراجعة اللاحقة أسرع ويمنع إعادة نفس النقاش من الصفر، كما يسمح لفريق آخر بتكرار التجربة دون الاعتماد على ذاكرة الشخص الذي نفذها. إذا كانت النتيجة غير حاسمة، اكتب ذلك صراحة وحدد الاختبار التالي بدل تحويل الاحتمال إلى استنتاج نهائي.