תרחישי התאוששות מאסון

1) מדוע נדרש ד "ר ומהי המטרה

התאוששות אסון (באנגלית: Asson Recovery, בראשי תיבות: DR) היא מערכת של ארכיטקטורה, תהליכים והכשרה לשיקום שירותים לאחר אסונות (כשל במרכז המידע/אזור, איבוד נתונים, שגיאות בתצורה המונית). מטרתו של DR היא לפגוש מטרות RTOs/RPOs במחיר מבוקר וסיכון תוך שמירה על אמון לקוחות וציות רגולטורי.

מטרת זמן התאוששות (RTO) - כל זמן השבתה.
Recovery Point Objective (RPO) - אובדן נתונים (זמן מאז הנקודה העקבית האחרונה).
RLO (Recovery Level Objective): רמת פונקציונליות שאמורה לחזור ראשונה (מינימום שירות בר קיימא).

2) סיווג מערכות על ידי ביקורת

Tier 0 (חיוני): תשלומים, התחברות, KYC, עסקאות ליבה - RTO 15 min, RPO light 1-5 min.
Tier 1 (גבוה): לוחות הפעלה, מדווח D-1 - RTO lique 1 h, RPO/15-60 דקות.
Tier 2 (ממוצע): משרד אחורי, ניתוח כמעט בזמן אמת - RTO 4-8 שעות, RPO 4-8 שעות.
Tier 3 (נמוך): סיוע לא ביקורתי - RTO formare 24-72 h, RPO fall 24 h.

הקצאת Tier + target RTO/RPOS לכל שירות בקטלוג השירות; יש לבדוק החלטות ותקציבים נגדם.

3) מודל איום ותרחישים

מעשה ידי אדם: כשל של AZ/אזור/ספק, הידרדרות רשת/DNS, כשל במסד נתונים/אחסון, באג שחרור המוני.
גורם אנושי: קונפיגורציה מוטעית/IC, מחיקת נתונים, פשרת מפתח.
טבעי/חיצוני: אש/שיטפון, הפסקות חשמל, חסימות חוקיות.
עבור כל הערכה של ההסתברות/השפעה, קישור לתרחיש DR וספר המהלכים.

4) תבניות ארכיטקטורה

1. Active-Active (Multi-Region): שני האזורים משרתים את התנועה.

יתרונות: RTO/RPO מינימלי, יציבות גבוהה.
חסרונות: מורכבות נתונים/עקביות, מחיר גבוה.
איפה: קריאה-כבדה, מטענים, שירותים חסרי מדינה, רב-אמן DB (כללי קונפליקט נוקשים).

2. אקטיבי-פסיבי (Hot Standby): פסיבי חם מחזיק עותק מחומם במלואו.

RTO: דקות; אר-פי-או: דקות. דורש כשל אוטומטי ושכפול.

3. המתנה חמה: חלק מהמשאבים מתחממים, מדשדש במקרה של תאונה.

רטו: עשרות דקות; אר-פי-או: 15-60 דקות. יותר חסכוני, אבל ארוך יותר.

4. אור פיילוט: ”ניצוץ” מינימלי (metadata/images/scripts) + התפשטות מהירה.

RTO: שעות; אר-פי-או: שעות. זול, מתאים לרובד 2-3.

5. גיבוי ושחזור: גיבויים לא מקוונים + חימום ידני.

RTO/RPO: שעות/יום. רק עבור ביקורתיות נמוכה וארכיונים.

5) נתונים ועקביות

• סינכרוני - כמעט אפס RPO, אבל latentnost/stoimost.
• Asynchronous - ביצועים טובים יותר, RPO> 0 (זנב של לוגים).
• עקביות: בחר מודל (חזק/בסופו של דבר/סיבתי). לתשלומים - אך ורק עבור ניתוח - בסופו של דבר.
• Snapshots: צור נקודות עקביות באופן קבוע + רישומי אחסון (WAL/redo).
• עסקאות חוצה אזורים: להימנע 2PC; השתמש בפעולות אידמפוטנטיות, מעדנייה וחזרה (retry עם dauplication), מיקור אירועים.
• תורים/אוטובוסים: שכפול/שיקוף, DLQ, הזמנה ואידמפוטנטיות של צרכנים.

6) רשת, תנועה ו ־ DNS

GSLB/Anycast/DNS: מדיניות כשל/כשל, TTL נמוך (אבל לא יותר מדי), בדיקות בריאות ממספר אזורים.
ניתוב L7: מפות אזוריות, דגלי פירוק (הגבלת פונקציות).
קישורים פרטיים/VPN: ערוצי גיבוי לספקים (PSP/KYC/CDN).
קצב מגביל: הגנה על הסערה בזמן ההתאוששות.

7) סטטוטורי נגד חסר מדינה

Stateless נישא על ידי script/autoscale; סטטיסטית דורשת אסטרטגיית נתונים עקבית (שכפול, תמונות, קידום העתק, מניין).
מטמון/הפעלות: חיצוני (Redis/Memcached) עם שכפול חוצה-אזור או זרע מחדש על ידי יומנים; לקיים מפגשים באסימונים (JWT) או לאחסון משותף.

8) DR טריגרים ואוטומציה

SLO gardrails ו quorum graves = = איזור-כשל אוטומטי.
שינוי הקפאה במקרה של תאונה: בלוק לא רלוונטי משחרר/נדידה.
תשתית כקוד: פריסה של מניפסטים בכוננות, בדיקת סחיפה.
קידום תפקידים: אוטומטי קידום העתק DB + כותבים/סודות הלבשה.

9) תקשורת וציות

חדר מלחמה: IC/TL/Comms/Scribe; מרווחי עדכון SEV.
עמוד מצב: גיאוגרפיה של השפעה, זמן הגעה משוער, מעגלים.
רגולציה: תאריכי יעד הודעה, אבטחת מידע, אחסון ראיות בלתי ניתנות לשינוי.
שותפים/ספקים: אנשי קשר מאושרים, ערוץ ייעודי.

10) בדיקות ותרגילים של ד "ר

דיון בתרחיש ופתרונות.
יום המשחק (Fame/prod-light): סימולציה של כשל AZ/אזורים, כיבוי ספק, איפוס DNS.
שחזר בדיקות: החזר מדי פעם גיבויים בבידוד ואימות שלמות.
הזרקת כאוס/כישלון: רשת מבוקרת/כישלונות תלות/צומת.
תרגיל KPI: הושג RTO/RPO, פגמים בספרי המשחק, CAPA.

11) בחירת כספים ואסטרטגיה (FinOps)

לספור $ עבור RPO/RTO מופחת: ככל שהמטרות נמוכות יותר, הערוצים, הרישיונות, הרזרבות יקרים יותר.
היברידי: Tier 0 - פעיל/חם; רובד 1 - חם; רובד 2-3 - טייס/גיבוי.
נתונים יקרים: השתמש בשכבות קרות (ארכיון/S3/GLACIER), תמונות אינקרמנטליות, שכפול.
סקירה תקופתית של עלויות ד "ר אינפרה ותעודות/רישיונות.

12) ד "ר בגרות מטריצות

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

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

לפני יישום DR

ספריית שירות [ ] מכילה Tier, RTO/RPO, תלויות ובעלים.

[ ] תבנית נבחרת (AA/AP/WS/PL/BR) על ידי Tier ותקציב.

[ ] הסכמי העקביות והשכפול מתועדים.

[ ] GSLB/DNS/ניתוב ובדיקות בריאות מוגדרות ונבדקו.

[ גיבויים ], תצלומים, רישומי שינוי - הופעלו, נבדקו לשחזור.

[ ] ד "ר משחקים וקשרים מספקים מעודכנים.

במהלך התאונה (בקצרה)

[ ] הכרזת סו "ב והרכבת חדר מלחמה; להקפיא את השחרור.

[ ] בדוק מניין של גשושיות; להקליט את ההשפעה/גאוגרפיה.

[ לבצע כשל ]: תנועה, קידום DB, תורים, מטמון.

[ ] אפשר השפלה - UX/limits; לפרסם עדכונים על SLA.

[ ] אספו ראיות (ציר זמן, גרפים, יומנים, פקודות).

אחרי התאונה

[ ] צפה ב ־ SLO במרווחי N; לבצע כשל כמתוכנן.

[ התנהגות ] AAR/RCA; להוציא CAPA.

[ ] עדכן ספרי משחק, זרזים ערניים, תיקי בדיקה של ד "ר.

[ ] דיווח לבעלי עניין/רגולטורים (במקרה הצורך).

14) תבניות

14. 1 כרטיס תסריט DR (דוגמה)

ID: DR-REGION-FAILOVER-01
Scope: prod EU ↔ prod US
Tier: 0 (Payments, Auth)
Targets: RTO ≤ 15m, RPO ≤ 5m
Trigger: quorum(probes EU, US) + burn-rate breach + provider status=red
Actions:
- Traffic: GSLB shift EU→US (25→50→100% with green SLIs)
- DB: promote US-replica to primary; re-point writers; freeze schema changes
- MQ: mirror switch; drain EU DLQ; idempotent reprocess
- Cache: invalidate region-specific keys; warm critical sets
- Features: enable degrade_payments_ux
- Comms: status page update q=15m; partners notify
Guardrails: payment_success ≥ 98%, p95 ≤ 300ms
Rollback/Failback: EU green 60m → 25→50→100% with guardrails
Owners: IC @platform, DB @data, Network @netops, Comms @support

14. 2 Runbook ”לקדם את בסיס הנתונים של העתק” (שבר)

1) Freeze writes; verify WAL applied (lag ≤ 30s)
2) Promote replica; update cluster VIP / writer endpoint
3) Rotate app secrets/endpoints via remote config
4) Validate: read/write checks, consistency, replication restart to new secondary
5) Lift freeze, monitor errors p95/5xx for 30m

14. 3 תוכנית התעמלות ד "ר (תקציר)

Purpose: to check RTO/RPO Tier 0 in case of EU failure
Scenario: EU incoming LB down + 60s replication delay
Success criteria: 100% traffic in US ≤ 12m; RPO ≤ 5m; SLI green 30m
Artifacts: switching logs, SLI graphs, step times, command output

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

”יש גיבויים” ללא בדיקות שחזור רגילות.
סודות/נקודות סוף לא הוחלפו אוטומטית.
אין אידמפוטנטיות * שכפול/עסקאות אבודות על כפרות.
תצורה זהה לאזורים ללא דגלים מאפיינים השפלה.
זמן רב להצהיר מחשש ל ”אזעקת שווא”.
ספקי מונורגיונל (PSP/KYC) ללא חלופה.
אין תוכנית כישלון - אנחנו חיים בטופולוגיית חירום ”לנצח”.

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

1. נד. 1-2: סיווג שירותים על ידי Tier, הגדרת המטרה RTO/RPO, בחירת דפוסי DR.
2. נד. 3-4: הגדרת שכפול/גיבויים, GSLB/DNS, הליכי קידום; ספרי שעשועים וספרי הפעלה.
3. נד. 5-6: תרגילי DR ראשונים (שלב שולחן), תיקון מדדים ו CAPA.
4. נד. 7-8: Rocked-Recorded Extreme Product-Light; כשל מעל אוטומציה.
5. נד. 9-10: אופטימיזציה עלויות (FinOps), העברה של Tier 0 לחום/AA, תרגיל רבעוני ותקנות דיווח.

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

ד "ר יעיל הוא לא רק על גיבויים. אלו הן ארכיטקטורה עקבית, אוטומציה של כשל או כשל, דיסציפלינה של נתונים (idempotency/reception), אימונים ותקשורת שקופה. כאשר ה-RTO/RPOs אמיתיים, חוברות השמעה מסתדרות, והתרגילים קבועים, האסון הופך לאירוע מבוקר, שאחריו השירותים חוזרים במהירות ובצפוי לשגרה.