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

دليل التشغيل ودليل الاستجابة

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

دليل التشغيل ودليل الاستجابة

الساعة 3:07 صباحًا. يوقظك هاتفك. يُخبرك PagerDuty أن خدمة الدفع متوقفة. عقلك يعمل بطاقة 30%. آخر شيء تريده هو شاشة فارغة مع توقع أن تستعيد أسابيعًا من المعرفة المؤسسية من الذاكرة وأنت تحت ضغط شديد. وجود دليل التشغيل (Runbook) هو تحديدًا ما يمنعك من ذلك — ليس كوثيقة بيروقراطية، بل كأداة نجاة تُتيح للمهندس الذي لم يستيقظ بعد حل حادثة بأولوية P1 دون تفاقمها.

في شركات كـ Google وNetflix وStripe، تُعامَل أدلة التشغيل كأصول إنتاج من الدرجة الأولى، تُحفظ في نظام التحكم بالإصدارات جنبًا إلى جنب مع كود الخدمة، وتُراجَع في طلبات السحب (Pull Requests)، وتُختبر في تمارين محاكاة الحوادث. الفارق بين فريق يُجيد إدارة الحوادث وآخر يتخبط فيها يتمحور دائمًا حول جودة أدلة التشغيل.

الفرق بين Runbook وPlaybook: دليل التشغيل (Runbook) هو إجراء لحالة فشل محددة ومعروفة — "ماذا تفعل عندما ينفد الذاكرة في Redis." أما دليل الاستجابة (Playbook) فهو مرشد استجابة رفيع المستوى لفئة من الحوادث — "كيف تُدير انقطاع قاعدة البيانات." تُنسّق أدلة الاستجابة بين أدلة تشغيل متعددة. كلاهما ضروري ولا يُغني أحدهما عن الآخر.

ما الذي يجعل دليل التشغيل قابلًا للاستخدام في الساعة 3 صباحًا

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

  • محفّز واحد محدد. يرتبط الدليل مباشرةً بالتنبيه الذي يستدعيه. يجب ألا يضطر المهندس إلى تخمين أي دليل ينطبق. يحتوي تنبيه Alertmanager أو حادثة PagerDuty على الرابط مباشرةً.
  • تأكيد الأعراض أولًا. قبل اتخاذ أي إجراء، يتأكد المهندس من أنه يواجه المشكلة الصحيحة. يبدأ كل دليل بخطوات التحقق: "يجب أن ترى X في لوحة التحكم. إذا لم تره، توقف وتصعّد."
  • خطوات مرقمة وذرية. ليست فقرات أو نثرًا. خطوات مرقمة، كل منها صغيرة بما يكفي لتنفيذها والتحقق منها بشكل مستقل. المهندسون تحت الضغط يتخطون الخطوات ويفقدون مكانهم. القوائم المرقمة أكثر موثوقية.
  • أوامر قابلة للنسخ واللصق. يجب أن يكون كل أمر في الدليل قابلًا للتشغيل دون تعديل، أو مع متغير محدد بوضوح مثل ${SERVICE_NAME} أو ${CLUSTER} يملؤه المهندس. الغموض في الساعة 3 صباحًا خطير.
  • الناتج المتوقع بعد كل أمر. "يجب أن ترى: PONG. إذا رأيت خطأ في الاتصال، انتقل إلى الخطوة 7." يحتاج المهندسون إلى تأكيد نجاح الخطوة قبل المتابعة.
  • شجرات قرار صريحة. "إذا حلّت الخطوة 4 التنبيه خلال 5 دقائق، انتقل إلى قسم التحقق. إذا لم تُحلّه، تصعّد إلى مناوب قاعدة البيانات." يجب أن تكون القرارات صريحة وليست متروكة للتقدير الشخصي عندما يكون التقدير مُثقلًا.
  • مخرج آمن. يجب أن يُخبرك كل دليل متى تتوقف عن اتباعه وتطلب المساعدة. الالتزام الأعمى بدليل في حالة فشل غير متوقعة قد يُفاقم الأمور.

تشريح دليل التشغيل الإنتاجي

إليك البنية التي تستخدمها فرق SRE الناضجة. هذا قالب حقيقي، وليس مجرد اقتراح — استخدمه حرفيًا وعدّل المحتوى لكل خدمة:

# دليل التشغيل: ضغط ذاكرة Redis **التنبيه:** RedisMemoryUsageHigh **الخطورة:** P2 (تتصاعد إلى P1 إذا بدأ الحذف) **المالك:** فريق SRE للمنصة **آخر اختبار:** 2025-04-18 | **آخر تحديث:** 2025-05-01 **التصعيد:** #sre-oncall → platform-lead@company.com --- ## 1. تأكيد التنبيه تحقق من أن استخدام ذاكرة Redis > 80% على الخادم المتأثر: ``` redis-cli -h ${REDIS_HOST} -p 6379 INFO memory | grep used_memory_human ``` المتوقع: قيمة > 80% من maxmemory (تحقق من CONFIG GET maxmemory). إذا كانت used_memory_human أقل من 70%، هذا تنبيه خاطئ. أبلغ فريق المراقبة. --- ## 2. فحص سياسة الحذف والحذف النشط ``` redis-cli -h ${REDIS_HOST} CONFIG GET maxmemory-policy redis-cli -h ${REDIS_HOST} INFO stats | grep evicted_keys ``` إذا كانت evicted_keys تزداد، فقد بدأ فقدان البيانات. الخطورة تتصاعد إلى P1. أبلغ مناوب المنتج فورًا. --- ## 3. تحديد أكبر المفاتيح ``` redis-cli -h ${REDIS_HOST} --bigkeys --count 200 ``` لاحظ أعلى 5 أنماط مفاتيح من حيث الحجم ومدة صلاحيتها (TTL): ``` redis-cli -h ${REDIS_HOST} DEBUG OBJECT <key> redis-cli -h ${REDIS_HOST} TTL <key> ``` --- ## 4. خيارات التخفيف (اختر واحدًا بناءً على النتائج) **الخيار أ: مفتاح بدون TTL يجب أن يكون له TTL** ``` redis-cli -h ${REDIS_HOST} EXPIRE <key> 3600 ``` **الخيار ب: تراكم جلسات مفرط** ``` # تحقق من عدد مفاتيح الجلسة redis-cli -h ${REDIS_HOST} DBSIZE # امسح قاعدة البيانات 1 فقط إذا كان ذلك آمنًا بعد التأكيد مع قائد الفريق redis-cli -h ${REDIS_HOST} -n 1 FLUSHDB ASYNC ``` ⚠️ أكّد مع القائد قبل المسح. هذا سيُخرج جميع المستخدمين النشطين من النظام. **الخيار ج: زيادة maxmemory مؤقتًا (يُعطي 30 دقيقة إضافية)** ``` redis-cli -h ${REDIS_HOST} CONFIG SET maxmemory 8gb ``` هذا حل مؤقت. أنشئ تذكرة سعة (capacity ticket) فورًا. --- ## 5. التحقق من الحل ``` redis-cli -h ${REDIS_HOST} INFO memory | grep used_memory_human ``` يجب أن يختفي التنبيه خلال 5 دقائق إذا انخفض الاستخدام دون 70%. --- ## 6. ما بعد الحادثة - حدّث الجدول الزمني للحادثة في قناة غرفة العمليات. - أنشئ تذكرة سعة إذا استُخدم الخيار ج. - أضف النتائج إلى مسودة التحليل اللاحق.
اربط أدلة التشغيل بالتنبيهات لا بصفحات الويكي. في Alertmanager، اضبط annotations.runbook_url على كل قاعدة تنبيه. في PagerDuty، أرفق الدليل كـ Response Play. لا ينبغي للمهندسين البحث عن الدليل — يجب أن يظهر في إشعار المناوبة نفسه.

دليل التشغيل كـ كود: التحكم بالإصدارات والاختبار

أدلة التشغيل المحفوظة في Confluence أو Google Docs تتقادم. يُصلح المهندسون النظام وينسون تحديث الوثيقة، ويتبع المناوب التالي تعليمات قديمة. عامل أدلة التشغيل كـ كود:

  • احفظها في مستودع الخدمة تحت docs/runbooks/ أو في مستودع runbooks مخصص.
  • اشترط تحديث دليل التشغيل في قائمة مراجعة PR لأي تغيير يؤثر على عتبة التنبيه أو مسار المعالجة.
  • أضف حقل "آخر اختبار". خلال تمارين محاكاة الحوادث أو الفوضى المهندسية، نفّذ الدليل فعليًا وحدّث هذا التاريخ.
  • استخدم CI للتحقق من الروابط — الروابط المكسورة للوحات التحكم وجهات التصعيد شائعة وخطيرة خلال الحوادث.
# .github/PULL_REQUEST_TEMPLATE.md (مقتطف) ## قائمة مراجعة دليل التشغيل والتنبيهات - [ ] إذا غيّر هذا سلوك خدمة، هل تم تحديث دليل التشغيل ذات الصلة؟ - [ ] إذا أضاف هذا تنبيهًا جديدًا، هل يحتوي التنبيه على runbook_url؟ - [ ] إذا غيّر هذا العتبات، هل لا تزال أقسام "الناتج المتوقع" في الدليل دقيقة؟ - [ ] رابط دليل التشغيل: ___________

أدلة الاستجابة: تنسيق الاستجابة

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

Runbook and Playbook relationship to alerts and incident response Alert Fires RedisMemoryHigh runbook_url Runbook Step-by-step fix Playbook Incident class guide Incident Declared IC assigned IC opens invokes Mitigation Steps Commands / rollback Comms + Escalation Status page, war room Postmortem Runbook updated يُحسّن
التنبيهات تُرتبط بأدلة التشغيل؛ أدلة الاستجابة تُنسّق الاستجابة للحوادث الأشمل؛ التحليل اللاحق يُعيد التحسينات إلى كليهما.

دورة حياة دليل التشغيل: الكتابة والتحقق والتقاعد

لدليل التشغيل دورة حياة. يُنشأ عند إضافة تنبيه جديد. يُتحقق منه خلال تمرين محاكاة الحوادث أو الحادثة الحقيقية التالية. يُحدَّث بعد كل تحليل لاحق يكشف عن ثغرة. يُتقاعد عندما يتغير النظام الأساسي وتختفي حالة الفشل. الفرق التي لا تُتقاعد أدلة التشغيل القديمة تُراكم ضوضاء خطيرة — يتوقف المهندسون عن الثقة بالتوثيق ويبدأون في الارتجال، مما يُهزم الغرض كله.

ادمج تدقيقًا ربع سنويًا في تقويم فريقك. راجع كل دليل: هل الأمر لا يزال يعمل؟ هل رابط لوحة التحكم يعمل؟ هل جهة التصعيد لا تزال في الفريق؟ تدقيق لساعتين كل ربع سنة يمنع ساعات من الارتباك خلال الحوادث.

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

الأتمتة: الصورة النهائية لدليل التشغيل

كل خطوة يدوية في دليل التشغيل هي خلل ينبغي إصلاحه. الهدف على المدى البعيد هو أتمتة خطوات دليل التشغيل حتى يصبح وثيقة مرجعية لحالات الحافة بدلًا من آلية استجابة أولية. عندما يُنفَّذ دليل تشغيل Redis عشر مرات والحل دائمًا هو "مسح DB 1"، يجب أن تصبح تلك الخطوة معالجة آلية مُشغَّلة بالتنبيه. أدوات مثل AWS Systems Manager Automation وRundeck والدوال السحابية المخصصة تجعل ذلك ممكنًا. يبقى دليل التشغيل موجودًا — ليصف ما تفعله الأتمتة، والشروط التي تعمل بها، وكيفية التدخل اليدوي إذا فشلت الأتمتة.