High Availability ו-Disaster Recovery: RTO, RPO ותכנון להתאוששות

מאת צוות מדיה דיל · 04.09.2026 · טכנולוגיה · 6 דק׳

ההבדל בין RTO ל-RPO, HA מול DR, Active-Active מול Active-Passive, Chaos Engineering לבדיקת תוכנית, ותפקיד Circuit Breakers ו-Canary Deployment.

"האתר שלנו לא נופל" היא הצהרה בלי משמעות אם אף אחד לא הגדיר כמה זמן השבתה מקובל וכמה נתונים מותר לאבד במקרה הגרוע ביותר. High Availability ו-Disaster Recovery הם שני תחומים שונים שקל לבלבל ביניהם: הראשון מונע נפילה, השני קובע מה קורה אחרי שהיא כבר קרתה.

RTO: כמה זמן מותר שהמערכת תהיה למטה

Recovery Time Objective הוא הזמן המקסימלי המקובל מרגע התקלה ועד שהמערכת חוזרת לפעול. RTO של 5 דקות דורש Failover אוטומטי לגמרי — אין זמן להתערבות אנושית. RTO של 4 שעות מאפשר תהליך שחזור ידני מבוקר. ההבדל בין השניים הוא הבדל בעלות תשתית של סדרי גודל, לא רק בתהליך.

RPO: כמה נתונים מותר לאבד

Recovery Point Objective קובע כמה נתונים — נמדד בזמן — מקובל לאבד במקרה כשל. RPO של אפס אומר שאסור לאבד עסקה אחת בודדת, ודורש Replication סינכרוני שמאשר כתיבה רק אחרי שהיא נשמרה גם באתר הגיבוי. RPO של שעה מאפשר Replication אסינכרוני זול משמעותית, במחיר של אובדן פוטנציאלי של עד שעת נתונים בתרחיש הגרוע.

High Availability: מניעת נפילה מלכתחילה

HA מתמקד בביטול נקודות כשל בודדות (Single Point of Failure) — שרתי אפליקציה מרובים מאחורי Load Balancer, מסד נתונים עם Read Replicas ומנגנון Failover אוטומטי, ואזורי זמינות (Availability Zones) נפרדים כדי שכשל בדאטה-סנטר בודד לא יפיל את כל המערכת. המטרה: המשתמש לא מרגיש שרכיב נפל בכלל.

Disaster Recovery: מה קורה כשכל האזור נופל

DR מטפל בתרחיש חמור יותר — לא כשל רכיב בודד אלא אובדן מלא של אזור שלם (Region), בגלל תקלת ספק ענן, אסון טבעי, או תקלת רשת רחבה. תוכנית DR מוגדרת מראש כוללת אתר גיבוי מלא, לפעמים באזור גיאוגרפי אחר לגמרי, ותהליך מוגדר להעברת תעבורה אליו.

Active-Active מול Active-Passive

Active-Active מפעיל שני אתרים (או יותר) בו-זמנית, שניהם מקבלים תעבורה אמיתית — Failover כמעט מיידי כי האתר השני כבר "חם" ורץ, אבל דורש פתרון סנכרון נתונים מורכב בין שני אתרים פעילים. Active-Passive מחזיק אתר גיבוי מוכן אבל לא מקבל תעבורה עד לרגע הכשל — פשוט יותר לתחזק, אבל ה-RTO גבוה יותר כי צריך זמן "להעיר" אותו.

Chaos Engineering: איך יודעים שהתוכנית באמת עובדת

תוכנית DR שמעולם לא נבדקה בפועל היא הנחה, לא עובדה. גרימת כשל מבוקר בפרודקשן — כיבוי שרת אמיתי, ניתוק Region — היא הדרך היחידה לוודא ש-Failover אכן קורה תוך זמן ה-RTO המוגדר ולא נתקע באמצע בגלל תלות שאף אחד לא זכר. צוותים בוגרים מריצים תרגילים כאלה באופן שגרתי, לא רק פעם בשנה.

Circuit Breakers כרכיב HA ברמת השירות

כשל בשירות תלות בודד לא צריך להפיל את כל המערכת — Circuit Breaker Pattern עוצר קריאות לשירות שנכשל שוב ושוב, מונע אפקט דומינו, ומאפשר לשאר המערכת להמשיך לתפקד עם דגרדציה חלקית במקום נפילה מלאה — HA ברמת השירות הבודד, לא רק ברמת התשתית כולה.

פריסה בטוחה כחלק מזמינות גבוהה

חלק גדול מתקלות בפרודקשן נגרם מ-Deploy עצמו, לא מכשל תשתית חיצוני. אסטרטגיית Blue-Green ו-Canary Deployment מצמצמת את הסיכון הזה על ידי חשיפה הדרגתית לגרסה חדשה עם יכולת חזרה מיידית — חלק בלתי נפרד מתוכנית HA שלמה, לא רק DR לתקלות חיצוניות.

מגדירים תוכנית זמינות והתאוששות לעסק שלכם? נשמח לעזור לכם לתכנן RTO ו-RPO ריאליים בוואטסאפ.

תגיות: High Availability · Disaster Recovery · RTO · RPO · DevOps

← חזרה לבלוג · צור קשר