למה Five Nines לא קורה במקרה
באוקטובר 2025 AWS עברה outage של 15+ שעות שפגע ב-140+ שירותים. הסיבה: race condition ב-DNS גרם לכשל מדורג ב-DynamoDB. מה שהפתיע מהנדסים בכל העולם, בדיקות הבריאות הרגילות עברו בהצלחה. הכשל קרה בשכבת ה-dependencies, לא בשירות עצמו. הארגונים שהתאוששו מהר היו אלה עם multi-region או hybrid infrastructure.
ב-2023 חברת לוגיסטיקה ישראלית איבדה 3 ימי data בגלל גיבוי שלא נבדק אף פעם. Backup שלא עבר restore test אינו גיבוי, זהו כשל ממתין לתאריך.
99.999% uptime (five nines) = 5.26 דקות downtime בשנה. 99.9% (three nines) = 8.7 שעות. לחברת payments ישראלית שמעבדת 2 מיליון שקל ביום, שעת downtime שווה כ-83,000 שקל. ההבדל בין שתי הרמות אינו רק טכני, הוא שאלה עסקית.
HA הוא לא DR, ההבדל שחשוב להבין
AWS עצמה מציינת במפורש: "High Availability is not Disaster Recovery." זהו אחד הבלבולים הנפוצים ביותר בתחום, והוא עולה כסף.
- High Availability (HA): מניעת downtime דרך redundancy ו-automatic failover. פועל בתוך region, Multi-AZ RDS, Auto Scaling Group, Load Balancer. מטרה: אפס זמן השבתה מכשלי חומרה או instance יחיד.
- Disaster Recovery (DR): שחזור מאירוע הרסני, כשל region שלם, ransomware, מחיקת data בטעות. פועל בין regions. מטרה: הגבלת כמות ה-data שאבד וזמן החזרה לפעילות.
RDS Multi-AZ נותן HA מצוין, automatic failover תוך 60-120 שניות בתוך us-east-1. אבל אם us-east-1 כולה נופלת (כפי שקרה ב-2025), Multi-AZ לא עוזר. לזה צריך cross-region replica.
RTO ו-RPO, שתי המטריקות שמגדירות הכל
לפני כל DR design, חייבים לקבל מה-business שני מספרים. הם קובעים את הארכיטקטורה, התקציב, וה-SLA.
- RTO (Recovery Time Objective): כמה זמן מותר להיות down? 1 דקה? שעה? יום? RTO נמוך = ארכיטקטורה יקרה יותר. Hot Standby מול Cold Standby.
- RPO (Recovery Point Objective): כמה data מותר לאבד? אפס (zero data loss) = synchronous replication. שעה = async replication עם backup כל שעה.
הכלל הפשוט: RTO ו-RPO נמוכים יותר = עלות גבוהה יותר. Active-Active multi-region מספק five nines אבל עולה פי 3. Cold Standby זול אבל RTO = שעות. הבחירה הנכונה נגזרת מעלות ה-downtime לעסק, לא מרצון הטכנולוגי.
4 דפוסי DR, Cost vs Recovery Time
| Pattern | RTO | RPO | עלות יחסית | מתאים ל |
|---|---|---|---|---|
| Backup & Restore | שעות | שעות | x1.0 | dev/staging |
| Pilot Light | 10-30 דק' | דקות | x1.2 | סטארטאפים, SaaS |
| Warm Standby | דקות | שניות | x1.5 | SaaS Enterprise, payments |
| Active-Active | ~אפס | ~אפס | x2.5-3 | fintech, banking, בריאות |
Pilot Light הוא נקודת המתיקות לרוב הסטארטאפים הישראליים: מחזיקים core infrastructure (RDS replica, Route53 health checks) תמיד פעיל ב-DR region, ומריצים בקנה מידה מלא רק בזמן אירוע. עלות נמוכה, RTO סביר.
Chaos Engineering, לבדוק לפני שהמציאות בודקת אותך
Netflix המציאה chaos engineering ב-2010 עם Chaos Monkey, כלי שמוריד instances בייצור באופן אקראי. הרעיון: אם כשלים יקרו ממילא, עדיף שהם יקרו בצורה מבוקרת ומתוכננת.
Google מפעילה DiRT (Disaster Recovery Testing), בדיקות אוטומטיות ורציפות של יכולת שחזור. המסקנה מ-Google SRE Book: "The difference between resilient systems and fragile ones is not whether failures occur, it's whether failure was anticipated, designed for, and operationally rehearsed."
עבור צוות ישראלי בן 3-4 מהנדסים, chaos engineering לא חייב להיות מורכב:
- הגדר hypothesis: "אם Redis instance אחד נופל, שאר השירות ממשיך לעבוד תוך 30 שניות"
- הגדר blast radius: מה יכול להשתבש אם ה-hypothesis שגוי?
- הרץ ב-staging עם AWS FIS (Fault Injection Simulator)
- מדוד: latency, error rate, recovery time
- Rollback מוגדר מראש
AWS Chaos Studio (GA ב-2025) הוא managed service שמוריד את החסם לצוותים קטנים. אין יותר תירוץ של "רק Netflix עושה את זה".
טעויות נפוצות בדרך ל-HA
- Backup שלא נבדק: "יש לנו גיבויים" אינו DR strategy. חברות רבות מגלות ב-incident שהגיבוי פגום, חסר, או שהתהליך לוקח 4 שעות במקום 20 דקות. כלל אחד: אם לא בדקת restore החודש, אין לך גיבוי.
- Single-AZ בחשבון Multi-AZ: לפתוח AWS account לא אומר שהשירותים שלך AZ-redundant. כל service חייב להיות deployed ב-2 AZs לפחות עם auto-failover מוגדר. בדוק את ה-Subnets שלך.
- DR Plan ללא Dry Run: Runbook שנכתב ב-2023 ולא נבדק מאז שווה כלום. Passwords השתנו, ARNs השתנו, service חדש נוסף. Quarterly dry-run הוא חובה, לא אפשרות.
סיכום: המסגרת לתכנון HA/DR
לפני שפותחים Terraform, צריך לענות על 3 שאלות:
- מהו עלות ה-downtime לשעה לעסק? זה קובע את ה-investment ceiling ב-HA.
- מהו RTO ו-RPO שה-business יכול לחיות איתם? לא מה שנוח טכנית, מה ה-business דורש בפועל.
- מתי בדקנו לאחרונה שהתהליך עובד? DR plan ללא dry run הוא wishful thinking.
Claude יכול לעזור בכל שלב: תכנון ארכיטקטורה, כתיבת Runbook מפורט, עיצוב Game Day exercise, ובניית chaos experiment plan. הכלי חזק, אבל ה-RTO ו-RPO חייבים לבוא מהבעלים של העסק, לא מהמהנדס.