Disaster Recovery למערכות AI: תוכנית התאוששות כשהתשתית הקריטית שלכם נעלמת

מאת צוות מדיה דיל · 05.08.2026 · Enterprise AI · 11 דק׳

אסון במערכת AI לא תמיד נראה כמו שרת שנופל - זה יכול להיות איבוד embeddings, השבתת ספק שלמה, או זיהום דאטה שמתפשט בשקט. הנה איך בונים תוכנית DR שמתאימה למציאות הזו.

אסון ב-AI נראה אחרת מאסון ב-IT קלאסי

כשמדברים על Disaster Recovery בעולם ה-IT המסורתי, התרחיש הקלאסי הוא: מרכז נתונים נהרס, מעבירים ל-DR site, וממשיכים. במערכות AI, האסונות הרלוונטיים שונים ומגוונים יותר. יכולה להיות השבתה מוחלטת של ספק המודל (כמו תקלה גלובלית ב-Anthropic או OpenAI שנמשכת שעות), איבוד מסד ה-Vector Database עם כל ה-embeddings שנצברו לאורך חודשים, זיהום שקט של דאטה - למשל pipeline שמזין תוכן פגום ל-fine-tuning או ל-RAG במשך שבועות לפני שמישהו שם לב, או אפילו 'אסון' רגולטורי כמו חסימת גישה למודל מסוים באזור גיאוגרפי מסוים. תוכנית DR למערכות AI חייבת לכסות את כל הספקטרום הזה, לא רק כשל חומרה.

RPO ו-RTO בהקשר של AI

שני המושגים המרכזיים ב-DR הם RPO (Recovery Point Objective - כמה דאטה מותר לאבד) ו-RTO (Recovery Time Objective - כמה זמן מותר שהמערכת תהיה למטה). במערכות AI, RPO צריך להיות מוגדר בנפרד לכל רכיב: היסטוריית שיחות (conversation history), embeddings ב-Vector DB, ו-fine-tuned models או custom prompts שהצטברו לאורך זמן. איבוד embeddings, למשל, עלול לדרוש עיבוד מחדש של אלפי מסמכים - תהליך שיכול לקחת שעות או ימים ולעלות כסף משמעותי בקריאות API חוזרות, ולכן RPO נמוך על הרכיב הזה קריטי במיוחד.

גיבוי Vector Database - האתגר הייחודי

גיבוי Vector Database שונה מגיבוי מסד נתונים רגיל. embeddings הם תוצר של מודל ספציפי - אם משחזרים גיבוי אבל המודל ששימש ליצירת ה-embeddings השתנה או הוצא משימוש, הדאטה המשוחזר עלול להיות לא תואם לשאילתות חדשות (שנוצרות עם מודל embedding אחר). תוכנית DR טובה שומרת לא רק את הוקטורים אלא גם מטא-דאטה על גרסת המודל שיצר אותם, ומגדירה תהליך re-embedding כחלק מתרחיש שחזור, לא רק שחזור דאטה גולמי.

אסטרטגיית Multi-Region ו-Multi-Provider

ההגנה הטובה ביותר מפני השבתת ספק היא שילוב של Multi-Region (העתקת תשתית לאזורים גיאוגרפיים שונים אצל אותו ספק) ו-Multi-Provider (יכולת מעבר לספק חלופי לגמרי). Multi-Region מגן מפני תקלות אזוריות אבל לא מפני תקלה גלובלית של הספק עצמו. Multi-Provider מגן גם מפני זה, אך דורש את שכבת ה-Adapter שדנו בה בהקשר של Failover, וכן דורש תוכנית DR נפרדת שמגדירה איזה ספק הוא ה-DR site הרשמי ומה רמת המוכנות שלו (Cold, Warm או Hot Standby).

Cold, Warm ו-Hot Standby

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

תרגול תוכנית DR - Chaos Engineering ל-AI

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

דוגמת קוד: בדיקת שחזור embeddings

def verify_dr_readiness(vector_db_backup, embedding_model_version):
    current_version = get_active_embedding_model()
    if embedding_model_version != current_version:
        return {
            'status': 'REQUIRES_REEMBEDDING',
            'estimated_hours': estimate_reembedding_time(vector_db_backup),
            'estimated_cost_usd': estimate_api_cost(vector_db_backup)
        }
    return {'status': 'READY', 'restore_time_estimate_minutes': 15}

בדיקה כזו צריכה לרוץ אוטומטית כל שינוי בגיבוי, כדי שהצוות ידע בזמן אמת מה מצב המוכנות בפועל ולא יגלה בעיה רק כשקורה אסון אמיתי.

תיעוד ותקשורת בזמן אסון

מרכיב שלעיתים נשכח הוא Runbook ברור - מסמך שמפרט בדיוק אילו צעדים נוקטים, מי מקבל החלטות, ואיך מתקשרים עם לקוחות בזמן אמת. במערכות AI, זה כולל גם הגדרה מראש אילו הודעות שקיפות שולחים למשתמשים כשהמערכת עוברת למצב Fallback עם איכות מופחתת, כדי לא ליצור ציפיות שווא.

טעויות נפוצות בפרודקשן

• גיבוי Vector Database בלי מטא-דאטה על גרסת מודל ה-embedding, מה שהופך את הגיבוי לחסר תועלת.
• תוכנית DR שנכתבה פעם אחת ומעולם לא נבדקה בפועל.
• הסתמכות על גיבוי יומי בלבד למערכת שבה שיחות משתמשים בזמן אמת הן קריטיות עסקית.
• העדר תקציב מוגדר מראש למצב DR, מה שגורם להיסוסים בזמן אמת בשעת חירום.
• חוסר בהירות לגבי מי מוסמך להפעיל את תוכנית ה-DR - עיכוב של דקות יקרות בזמן אירוע אמיתי.

מתי כדאי ומתי לא

לכלים פנימיים לא קריטיים, תוכנית DR מלאה היא overkill - מספיק גיבוי תקופתי בסיסי. אבל לכל מערכת שמשרתת לקוחות חיצוניים או תהליכים עסקיים קריטיים, במיוחד בתעשיות מוסדרות כמו פיננסים ובריאות, DR מוגדר ומתורגל הוא דרישה בסיסית - ולעיתים אף רגולטורית. ב-מדיה דיל אנחנו בונים תוכניות DR בהתאמה לרמת הקריטיות הספציפית של כל מערכת, כדי לא לבזבז תקציב על הגנת יתר אבל גם לא להשאיר חשיפה מסוכנת.

ניהול ידע ארגוני: מה קורה כשהצוות שיודע לתפעל את המערכת לא זמין

היבט DR שלעיתים מוזנח לגמרי הוא Knowledge Continuity - מה קורה כשמי שבנה את המערכת ומכיר את כל הפרטים הדקים אינו זמין בזמן האסון. תיעוד ה-Runbook חייב להיות מפורט מספיק כדי שמהנדס שלא בנה את המערכת יוכל להפעיל את תהליך ההתאוששות בעצמו, כולל פקודות מדויקות, נתוני גישה (בצורה מאובטחת דרך Secrets Manager, לא בטקסט גלוי), וסדר פעולות ברור. ארגונים בשלים מקיימים תרגיל 'Bus Factor' - מוודאים שלפחות שני אנשים בצוות, לא רק אחד, יכולים לבצע כל שלב בתהליך ההתאוששות ללא סיוע.

תיעוד תלויות חיצוניות

חלק קריטי מתוכנית DR הוא מיפוי מלא של כל התלויות החיצוניות - לא רק ספק המודל הראשי, אלא גם שירותי embedding, שירותי אחסון קבצים, ותורי הודעות (message queues) שהמערכת מסתמכת עליהם. אסון אמיתי לרוב לא פוגע ברכיב אחד בלבד אלא חושף שרשרת תלויות שאף אחד לא מיפה במלואה מראש. תרגיל מיפוי כזה, שמכונה לעיתים Dependency Mapping או Service Mesh Audit, צריך להתבצע לפחות פעם בשנה ולהתעדכן בכל שינוי ארכיטקטוני משמעותי.

עלות מול סיכון: איך מתמחרים תוכנית DR

בניית תוכנית DR מלאה עולה כסף וזמן פיתוח משמעותיים, ולכן ההחלטה על רמת ההשקעה חייבת להתבסס על ניתוח סיכון כמותי - כמה עולה לעסק כל שעת השבתה (Cost of Downtime), מוכפל בהסתברות לאירוע, מול עלות בניית ותחזוקת שכבת ה-DR. במערכות שבהן שעת השבתה עולה עשרות אלפי שקלים בהכנסות אבודות או בפגיעה במוניטין, השקעה של כמה שבועות פיתוח בתוכנית DR מלאה מחזירה את עצמה כמעט מיידית באירוע הראשון. במערכות פנימיות בעלות סיכון נמוך, ניתוח דומה עשוי להראות שה-ROI נמוך משמעותית.

אחריות משפטית וחוזית מול ספקים בזמן אסון

היבט שלעיתים מתגלה מאוחר מדי הוא רמת האחריות שהספק עצמו לוקח על עצמו במקרה של תקלה ממושכת. הסכמי SLA של ספקי AI מרכזיים מציעים לרוב זיכוי כספי חלקי על אחוזי השבתה, אך כמעט אף פעם לא מכסים נזק עקיף שנגרם לעסק שלכם כתוצאה מהתקלה. תוכנית DR מלאה כוללת גם הבנה משפטית של החוזה מול הספק - מה בדיוק ה-SLA מבטיח, מה תהליך התביעה על זיכוי, ואיזה תיעוד נדרש מהצד שלכם כדי להוכיח את ההשפעה העסקית. ארגונים גדולים לרוב מנהלים את הנושא הזה מול צוות משפטי במקביל לצוות ההנדסה, כחלק בלתי נפרד מתהליך ה-DR הכולל.

מקרה בוחן: התאוששות מאיבוד Vector Database

נבחן תרחיש שקרה בפועל אצל ארגון שבנה מערכת RAG פנימית: תקלת תצורה גרמה למחיקה שגויה של אינדקס שלם ב-Vector Database, שכלל embeddings של עשרות אלפי מסמכים פנימיים שנצברו לאורך שנה. בהעדר גיבוי עדכני, הצוות נאלץ לבנות מחדש את כל האינדקס מהמסמכים המקוריים - תהליך שדרש עיבוד מחדש של כל המסמכים דרך API של embedding, ולקח כמעט שלושה ימים בגלל מגבלות קצב וצורך בבדיקת תקינות. העלות הכספית הישירה של קריאות ה-API החוזרות הייתה משמעותית, אך העלות האמיתית הייתה שלושה ימים שבהם מערכת קריטית לעבודה השוטפת הייתה לא זמינה. לאחר האירוע, הארגון הטמיע גיבוי יומי אוטומטי של האינדקס המלא עם שמירת מטא-דאטה על גרסת מודל ה-embedding, מה שהפך תרחיש דומה עתידי לאירוע של דקות בודדות במקום ימים.

הכשרת צוות ותרגילי שולחן (Tabletop Exercises)

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

סיכום

Disaster Recovery למערכות AI דורש חשיבה מעבר לשרתים ומסדי נתונים מסורתיים - embeddings, גרסאות מודל ותלות בספקים חיצוניים הם כולם חלק מהתמונה. תוכנית שנבדקת באופן קבוע היא ההבדל בין אסון של שעות לאסון של ימים.

תגיות: Disaster Recovery · RPO RTO · Vector Database Backup · Multi-Region · AI Infrastructure · Business Continuity · Hot Standby

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