ספרי מחזות לפעולות

1) מהו ספר מהלכים וכיצד הוא שונה מאלבום מסודר

Runbook היא הוראה לינארית צעד אחר צעד עבור פעולה/התראה טיפוסית (”do 1, 2, 3”).
משחק הוא עץ החלטה לתרחישים עם מזלגות: תסמינים שונים = השערות שונות = ענפי פעולה שונים. כולל קריטריונים לבחירה, תנאי שער, וענפי גיבוי.
מטרת הספר היא להקטין את MTTA/MTTR ואת רמת האלתור תחת אי ודאות.

2) היכן שיש צורך קודם בספרי שעשועים

תקריות: ירידה ב ־ SLO (זמינות/הצלחה/latency/), כשל עסקי ב ־ SLI (המרה/הצלחה בתשלומים).
שינויים: שחרורים, נדודים, דגלים, תצורות (canary/rollback).
חלונות תחזוקה: שדרוגי מסד נתונים/ברוקר, סיבובי תעודות.
ספקים: PSP/KYC/CDN/IDP - הידרדרות ותנופה.
אבטחה: מפתח בסכנה, פעילות חשודה.
טריות מאוחרת, סחף של המעגל, השפלת הצינור.

3) סטנדרטים של ספר משחקים (קומפוזיציה מינימלית)

1. כרטיס: זיהוי, גרסה/תאריך, בעלים (קבוצה/תפקיד), שירותים/אזורים/דיירים, מדיניות/תקנים קשורים.
2. תכלית ותנאי שיגור: על איזה SLO/SLI אנו מגנים, אשר התראות/טריגרים מתאימים.
3. תסמינים ↔ היפותזות: טבלת התכתבות, איך לחתוך במהירות השערות שגויות.
4. עץ החלטה: מזלגות, שערי אבטחה, עצור/המשך קריטריון.
5. פעולות: שלב בלוקים עם פקודות/קישורים לאלבום הריצה 'ו.
6. תקשורת: עדכון תבנית (Impakt # Diagnostika # Deystviya # Sled. עדכון), ערוצים ותדרים.
7. Rollback/folback: ברור תכנית גיבוי, גבולות ודגל השפלה UX.
8. קריטריונים להשלמה: מדדים, חלונות זמן תצפית.
9. ראיות: מה לשמור (יומנים, גרפים, צילומי מסך, כרטיס זיהוי).
10. היסטוריה של שינויים: changelog, מגבלות ידועות.

4) טקסונומיה של ספרי משחקים (קטלוג לדוגמה)

תקריות (SLO/SLI, ספקים, תשתיות).
שחרורים, גלגולים, הגדרות/דגלים.
חלונות תחזוקה (DB/תור/Cert/OS).
אבטחה (גישה, מפתחות, פעולות חשודות).
DATA - רעננות/איכות/מזימות.
ספקים חיצוניים (PSP/KYC/CDN/דוא "ל/SMS).

5) מחזור חיים ובעלות

1. חניכה: בהתבסס על תקרית/סימולציה/שינוי.
2. טיוטה: מחבר = בעל שירות; סקירה: SRE/security/data (על ידי תחום).
3. פיילוט: שולחן/משחק-יום; הקלטה של זמן מעבר ופגמים.
4. פרסום: Repo (Docs-as-Code), גרסה, תגיות, קישורים ללוחות מחוונים.
5. עדכון: לפי RCA/CAPA, לפחות פעם ברבע; רעננות SLA.
6. ארכיון/ריקון: במקרה של החלפה/אובדן רלוונטיות.

6) אינטגרציה עם כלים

Assight # Playbook: כל דף מתייחס בדיוק לספר משחקים אחד בסיסי.
ChatOps: '/play start <id> 'פותח את הקלף, מתקן ראיות, קובע טיימרים עדכניים.
CMDB/קטלוג: לשירות יש רשימה של ספרי השמעה רלוונטיים, בעלים, SLO, לוחות מחוונים.
GitOps: ספרי משחק וספרי הפעלה חיים בגיט, יש ביקורות יחסי ציבור וקווים.

7) מדדים איכותיים של ספר משחקים

פעולה: 90% מהריצות גורמות לפעולות ספציפיות מבלי להסלים שלא ביודעין.
זמן לפעולה ראשונה: דקה או שתיים מפייג 'לצעד המשמעותי הראשון.
סיקור:% התראות עמוד שיש להן חוברת משחקים (100% יעד).
רעננות: הפרופורציה של ספרי שעשועים היא יותר טרייה מ-90 יום.
שיעור הפגם: הערות על ביקורות/סימולציות עבור 100 ספרי משחק.
שימוש חוזר: כמה פעמים הופעל למעשה ספר המהלכים (ואילו תוצאות הוא הוביל).

8) אנטי דפוסים

”אנציקלופדיה למשחק” עם 20 עמודים ללא עץ החלטה.
פקודות ללא ציפיות מהתוצאה (”לבצע X” - מה צריך להשתנות?).
אין תכנית גיבוי ומגבלות - הסיכון להסלמת הבעיה.
ערוצי תקשורת/מרווחים אינם מעידים על צמיחת סיכוני יחסי הציבור.
חוברת משחקים ללא תאריך בעלים/עדכון - אף אחד לא מאמין ברלוונטיות שלה.
עשרות ספרי שעשועים דומים במקום פרמטרייה אחת.

9) מיני-תבנית של ספר משחקים (רעיון 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 דקות.

B) DB: ”גדילה p99 ושגיאות חיבור”

תסמינים: p99, חיבור איפוס שגיאות, אירועי גדילה בהמתנה.
פתרונות: אפשר תסריטים לקריאה בלבד, הגבלת עומס כתיבה, סולם ביליארד/העתקים, במידת הצורך - כשל חם.
גיבוי: פרמטר rollback, העתק-ראשוני.

C) Cache: "Miss rate lought ac.ac

סימפטומים: שיעור החטאה> 40%, גידול של מעבד DB.
פתרונות: מדיניות פינוי איזון, הגדלת זיכרון/שירוג, קריאה זמנית, הגבלת RPS על מקשים חמים.
חזרה: להחזיר את המדיניות, לשחזר את השבר הבעייתי.

ד) CDN: ”השפלת תוכן אזורי”

תסמינים: עלייה באיחור/פסק זמן במדינה אחת, תלונות ברום.
פתרונות: לשנות מפת ניתוב/GSLB, לעקוף POP בעייתי, להפחית TTL, לאפשר מקור-מגן.
תקשורת: עדכוני מצב עם גאוגרפיה של השפעה.

E) 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 ומפעיל צוין.

[ ] יש שולחן ”סימפטומים ↔ השערות” ועץ החלטה.

[ ] צעדים ניתנים להפעלה עם תוצאות צפויות ושערי ביטחון.

[ ] Backout/Fallback ותנאי החזרה מאויתים.

[ ] תבנית תקשורת ותדר עדכון.

[ ] קישורים ללוחות מחוונים/התראות/רישום חיפושים/שבילים.

[ ] נדרש סעיף ראיות וקריטריונים להשלמה.

[ גרסה ], תאריך, רעננות SLA, לשנות את ההיסטוריה.

13) רשימת בדיקות

[ ] Playbook ניתן לשחק בשולחן/משחק-יום.

[ מדרגות ] הן בטוחות (גבולות/קנרית/גלגול אוטומטי), סודות אינם נחשפים.

[ ] תפקידים והסלמה ברורים; תקשורת איי-סי מסומנת.

[ ] אין כפילות עם ספרי משחק סמוכים; הפרמטרים מוסרים.

[ ] ברור מתי לעצור וללכת לנסיגה/רולבק.

[ ] המסמך זמין מכוננות בלחיצה 1.

14) פרמטריזציה ושימוש חוזר

ביצוע משתנים (אזור, מפרנס, סף) ב 'values. '.
צעדים כלליים (לדוגמה, ”להפחית את משקל הספק”, ”לאפשר דיגרד-UX”) צריכים להיות מונפקים בספרי הפעלה נפרדים.
גנרטורים תומכים מתבנית: ”plb new - type = Inc - service = תשלומים”.

15) מימוש מפת דרכים (שבועות 4-6)

1. רשימת מלאי של Page מתריעה על המפה הבאה לכל ספר מהלכים בסיסי.
2. תבניות: לאשר מבנה YAML/Markdown, רשימות צ 'קים וקווים.
3. 5 התרחישים הטובים ביותר (תשלומים/DB/CDN/KYC/cache).
4. אינטגרציה: קישורים מהתראות, פקודות צ 'טופ, ראיה-בוט.
5. תרגיל: תרגול מיני שבועי אחד בכל פעם; AAR = uluchsheniya.
6. Treeness SLAs ו-Quarterly Review; דו "ח מדדים איכותיים.

16) השורה התחתונה

ספרי משחקים הם תרחישים מבצעיים עם מזלגות ומעקות המתרגמים את הכאוס של ”מה לעשות?” לרצף צפוי של החלטות. כאשר חוברות משחקים מתוקנות, משולבות עם התראות ומאומנות באופן קבוע, הצוות מגיב מהר יותר, הסיכונים נשלטים והעסק רואה את היציבות והבגרות של הניצול.