كتب التشغيل

1) ما هو كتاب اللعب وكيف يختلف عن كتاب التشغيل

Runbook هو تعليمات خطية خطوة بخطوة لعملية/تنبيه نموذجي («افعل واحدًا، اثنان، ثلاثة»).
Playbook هي شجرة قرار للسيناريوهات ذات الشوك: أعراض مختلفة → فرضيات مختلفة → فروع مختلفة من الإجراءات. يتضمن معايير الاختيار وظروف البوابة والفروع الاحتياطية.
الغرض من دليل اللعبة هو تقليل MTTA/MTTR ومستوى الارتجال في ظل عدم اليقين.

2) حيث تكون هناك حاجة إلى كتب اللعب أولاً

الحوادث: انخفاض SLO (التوافر/زمن الكمون/النجاح)، فشل SLI الأعمال (تحويل/نجاح المدفوعات).
التغييرات: الإصدارات، والهجرات، والأعلام المميزة، والتكوينات (الكناري/التراجع).
نوافذ الصيانة: تحديث قاعدة البيانات/الوسيط، تناوب الشهادات.
مقدمو الخدمات: PSP/KYC/CDN/IDP - التدهور والتأرجح.
الأمن: المفتاح المخترق، نشاط مشبوه.
DataOps: نضارة متأخرة، انجراف الدائرة، تدهور خط الأنابيب.

3) معايير قواعد اللعبة (التكوين الأدنى)

1. البطاقة: الهوية، النسخة/التاريخ، المالك (الفريق/الدور)، الخدمات/المناطق/المستأجرين، السياسات/المعايير ذات الصلة.
2. شروط الغرض والإطلاق: ما الذي نحميه من SLO/SLI، وما هي التنبيهات/المحفزات القابلة للتطبيق.
3. الأعراض ↔ الفرضيات: جدول المراسلات، كيفية قطع الفرضيات غير الصحيحة بسرعة.
4. شجرة القرار: الشوك، بوابات الأمن، معايير التوقف/الاستمرار.
5. الإجراءات: كتل الخطوات مع الأوامر/الروابط إلى كتيب التشغيل 'و.
6. الاتصالات: نموذج التحديث (Impakt→Diagnostika→Deystviya→Sled. ، والقنوات والترددات.
7. التراجع/الفولباك: خطة احتياطية واضحة وحدود وعلم تدهور UX.
8. معايير الإنجاز: المقاييس، ونوافذ وقت المراقبة.
9. الدليل: ما يجب حفظه (السجلات والرسوم البيانية ولقطات الشاشة ومعرف التذكرة).
10. تاريخ التغييرات: التغيير، القيود المعروفة.

4) تصنيف كتاب اللعبة (كتالوج مثال)

الحوادث (SLO/SLI، مقدمو الخدمات، البنية التحتية).
REL- الإصدارات، التراجع، التكوينات/الأعلام.
MW- نوافذ الصيانة (DB/quelue/cert/OS).
SEC- الأمن (الدخول، المفاتيح، الأفعال المشبوهة).
DATA- النضارة/الجودة/المخططات.
PROV- مقدمو الخدمات الخارجيون (PSP/KYC/CDN/Email/SMS).

5) دورة الحياة والملكية

1. البدء: استنادا إلى الحوادث/المحاكاة/التغيير.
2. المسودة: المؤلف = صاحب الخدمة ؛ استعراض: SRE/security/data (حسب المجال).
3. رائد: طاولة/يوم لعبة ؛ تسجيل وقت المرور والعيوب.
4. Publication: in repo (Docs-as-Code), version, tags, rinks to dashboards.
5. التحديث: وفقًا لـ RCA/CAPA، مرة واحدة على الأقل في الربع ؛ نضارة SLA.
6. المحفوظات/الاستنفاد: في حالة الاستبدال/فقدان الأهمية.

6) التكامل مع الأدوات

تنبيه → Playbook: كل قاعدة صفحة تشير بالضبط إلى كتاب لعب أساسي واحد.
ChatOps: «/بدء اللعب <id> »يفتح البطاقة، ويصلح الأدلة، ويضع مؤقتات التحديث.
CMDB/كتالوج: تحتوي الخدمة على قائمة بكتب اللعب ذات الصلة والمالكين و SLO ولوحات القيادة.
GitOps: تعيش كتب اللعب والكتب الجاهزة في Git، ولديها تقييمات العلاقات العامة والبطانات.

7) مقاييس جودة دليل اللعبة

قابلية العمل: ≥ 90٪ من الجري تؤدي إلى إجراءات محددة دون تصعيد دون علم.
الوقت إلى الإجراء الأول: دقيقة أو دقيقتان من الصفحة إلى الخطوة الأولى ذات المغزى.
التغطية:% تنبيهات الصفحة التي لها دليل محدد (هدف 100%).
النضارة: نسبة كتب اللعب أعذب من 90 يومًا.
معدل الخلل: تعليقات على المراجعات/المحاكاة لـ 100 كتاب لعب.
إعادة الاستخدام: كم مرة تم تطبيق دليل اللعبة بالفعل (وما هي النتائج التي أدى إليها).

8) الأنماط المضادة

«Playbook Encyclopedia» مع 20 صفحة بدون شجرة قرار.
أوامر بدون توقعات للنتيجة («تنفيذ X» - ما الذي يجب أن يتغير ؟).
لا توجد خطة وحدود احتياطية - خطر تصعيد المشكلة.
لم يتم تحديد قنوات/فترات الاتصال - نمو مخاطر العلاقات العامة.
كتاب اللعب بدون تاريخ المالك/التحديث - لا أحد يؤمن بأهميته.
العشرات من كتب اللعب المماثلة بدلاً من واحدة يمكن تحديدها.

9) نموذج Playbook المصغر (فكرة YAML)

yaml id: INC-PAY-001 name: "Payment Success Down"
version: 2. 4 (2025-10-15)
owner: team-payments@sre scope: [prod, region: eu, tenants: all]
goal: "Restore success_ratio ≥ 98% without violating SLA"
triggers:
- alert: slo. burn. payment_success_ratio
- external_status: psp-a partial outage symptoms:
- "5xx growth in payments-api"
- "p95 latency> 400ms on PSP-A"
decision_tree:
- if: "quorum(eu,us) confirms drop AND PSP-A status=partial"
then:
- action: "Reduce PSP-A weight to 30%"
runbook: rb://payments/traffic-shift guardrails: ["success_ratio improving 10m", "p95<300ms"]
- action: "Enable degrade_payments_ux"
runbook: rb://payments/feature-flags
- action: "Status update (30m) by template"
comms: statuspage://payments else:
- action: "Check database/cache/queue"
runbook: rb://payments/diag-stack fallback:
- action: "Failover на PSP-B 70%"
guardrails: ["fraud_rate stable", "chargeback risk noted"]
rollback:
- condition: "PSP-A green 60m"
- steps:
- "Weight of PSP-A 30→70→80 (every 30 m at green SLI)"
evidence:
- "SLI screenshots, p95/5xx graphs, links to logs/trails"
completion:
- "success_ratio ≥98% during 30 m, no burn in 6 h"

10) أمثلة جاهزة (شظايا)

أ) المدفوعات: «يتدهور مقدم الخدمة في منطقة واحدة»

الأعراض: انخفاض success_ratio مجموعة TR، وزيادة مهلات PSP-A.
الحلول: تقليل وزن PSP-A لـ TR، وتمكين تحلل UX، وتقوية عمليات إعادة التصوير بميزانية ≤ SLA، وإعداد تحديث للعملاء.
النسخ الاحتياطي: استعد الأوزان عند SLI أخضر لمدة 60 دقيقة.

ب) DB: «النمو p99 وأخطاء الاتصال»

الأعراض: p99↑، أخطاء إعادة ضبط الاتصال، أحداث انتظار النمو.
الحلول: تمكين نصوص القراءة فقط، والحد من حمل الكتابة، وحوض السباحة/النسخ المتماثلة، إذا لزم الأمر - فشل ساخن.
النسخ الاحتياطي: تراجع المعلمة، نسخة طبق الأصل.

ج) المخبأ: «معدل الفشل ↑ → تحميل قاعدة البيانات»

الأعراض: معدل الفشل> 40٪، نمو وحدة المعالجة المركزية DB.
الحلول: موازنة سياسة الإخلاء، زيادة الذاكرة/الشق، تمكين القراءة مؤقتًا، الحد من RPS على المفاتيح الساخنة.
التراجع: أعد السياسة، أعد إنشاء الشظية الإشكالية.

DD) CDN: «تدهور المحتوى الإقليمي»

الأعراض: زيادة زمن الوصول/المهلة في بلد واحد، شكاوى RUM.
الحلول: تغيير خريطة التوجيه/GSLB، تجاوز مشكلة الملوثات العضوية الثابتة، تقليل TTL، تمكين درع المنشأ.
الاتصالات: تحديثات الحالة مع جغرافيا التأثير.

هاء) KYC: «التعريفات الفاشلة»

الأعراض: انخفاض معدل الموافقة، نمو vendor_error.
الحلول: تحويل جزء من حركة المرور إلى مزود بديل، وتقليل شدة القواعد (في إطار السياسة)، والشروع في مراجعة يدوية لكبار الشخصيات.
الامتثال: تسجيل جميع التغييرات، المخاطر/الإخطارات القانونية إذا لزم الأمر.

11) الاتصالات (نموذج التحديث)

Impact: EU payment success drop (-3. 1% to SLO, 25 min).
Diagnosis: confirmed by quorum; PSP-A partial outage; p95 = 420ms.
Action: PSP-A weight reduced to 30%, degrade-UX included; next update 18:30 UTC.

12) قائمة مراجعة مؤلف كتاب اللعبة

• الهدف والمالكون و SLO/SLI والمحفزات المحددة.
• هناك جدول «أعراض ↔ فرضيات» وشجرة قرار.
• خطوات قابلة للتنفيذ مع النتائج المتوقعة والبوابات الأمنية.
• يتم توضيح ظروف التراجع/التراجع والعودة.
• نموذج الاتصال وتواتر التحديث.
• وصلات إلى لوحات القيادة/التنبيهات/عمليات البحث/المسارات.
• قسم الأدلة المطلوبة ومعايير الإنجاز.
• نسخة، تاريخ، نضارة SLA، تغيير التاريخ.

13) مراجعة القائمة المرجعية

• يمكن تشغيل كتاب اللعب على سطح الطاولة/يوم اللعبة.
• الخطوات آمنة (الحدود/الكناري/التراجع التلقائي)، ولا يتم الكشف عن الأسرار.
• الأدوار والتصعيدات واضحة ؛ تمت الإشارة إلى IC/Comms.
• عدم الازدواجية مع كتب اللعب المجاورة ؛ .
• من الواضح متى تتوقف وتذهب إلى التراجع/التراجع.
• الوثيقة متاحة من التنبيه بالنقرة 1.

14) تحديد البارامترات وإعادة استخدامها

تنفيذ المتغيرات (المنطقة، المزود، العتبات) في 'القيم. '.
وينبغي إصدار خطوات عامة (مثل «تخفيض وزن مقدم الخدمة»، و «تمكين تحلل العملة») في كتيبات منفصلة.
مولدات الدعم من القوالب: "plb new -type = INC -service = pays'.

15) خارطة طريق التنفيذ (4-6 أسابيع)

1. ينبه جرد الصفحة → خريطة لكل دليل أساسي.
2. القوالب: الموافقة على هيكل YAML/Markdown والقوائم المرجعية والبطانات.
3. سيناريوهات أعلى 5 (المدفوعات/DB/CDN/KYC/cache) → الكتابة/العودة إلى سطح الطاولة.
4. التكامل: روابط من التنبيهات وأوامر ChatOps وروبوت الأدلة.
5. حفر: دليل أسبوعي مصغر لكل مرة ؛ AAR→uluchsheniya.
6. نضارة اتفاقات البيئة المستدامة والاستعراضات الفصلية ؛ تقرير مقاييس الجودة.

16) خلاصة القول

كتب اللعب هي سيناريوهات تشغيلية ذات شوكات ودرابزين تترجم فوضى «ماذا تفعل ؟!» إلى سلسلة من القرارات يمكن التنبؤ بها. عندما يتم توحيد كتب اللعب ودمجها مع التنبيهات وتدريبها بانتظام، يستجيب الفريق بشكل أسرع، ويتم التحكم في المخاطر، ويرى العمل استقرار ونضج الاستغلال.