כשהענן מאבד קיבולת: הלקח למנמ"רים מהתקלה במיקרוסופט

שעות ארוכות ורבות של שיתוק דיגיטלי עברו בסוף השבוע על מיליוני משתמשים וארגונים רבים ביותר מ-70 מדינות, כאשר שירותי הליבה של מיקרוסופט – מאאוטלוק וטימס ועד ל-Copilot ו-SharePoint – חוו תקלות בזה אחר זה, וחלקם לא פעלו. בין הסובלים מהתקלה היו משתמשים וארגונים רבים בישראל.

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

התקלה הזו חשפה שוב עד כמה הדואר הארגוני נותר עמוד השדרה הקריטי של כל עסק – משחזור סיסמאות וחשבוניות ועד לתיאום תגובה לאירועי אבטחה – וכמה מסוכנת התלות המוחלטת בספק ענן יחיד. עבור קהילת המנמ"רים, האירוע מחדד את ההבדל בין ארגון שקופא במקום לבין ארגון שממשיך לתפקד כשהענן נחנק.

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

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

לפני המשבר: בונים חסינות ולא רק נוחות

• ראשית, שלב פנימי – על המנמ"ר להבין, ולהודות, שגם לענקיות הטכנולוגיה יש נקודות כשל.
• לאחר מכן, עליו למפות מראש את התלויות הקריטיות בארגון (למשל, מערכות שנסמכות על אקסצ'יינג' או על הזדהות אחידה של הספק). מומלץ לבנות רשימה של התהליכים הקריטיים שנעצרים כששירותי הליבה נופלים – למשל, אישורי הזמנות, חתימות, שירות לקוחות והתראות מערכת – ולזהות מערכות פנימיות וחיצוניות שנשענות על חשבון המיקרוסופט או על הזדהות אחידה (SSO).
• פעולה שלישית היא פיזור סיכונים וביטול נקודת כשל בודדת: בחינת פתרונות גיבוי והמשכיות עסקית מול ספק משני עבור שירותים קריטיים. הכוונה היא, למשל, לשירות דואר חירום חיצוני, שמאפשר קבלה ושליחה של מיילים בזמן השבתת הענן הראשי.
• ניתוק תשתית החירום מהענן של הספק: שמירת רשימת אנשי הקשר החיוניים מחוץ לאאוטלוק, כדי שתהיה זמינה גם כשתיבת המייל חסומה; ואחסון דף הנחיות המשבר ותוכנית החירום מחוץ ל-SharePoint או ל-וואן דרייב, על מנת שאלה יוכלו להיפתח גם כשהתשתיות מושבתות.
• בחינת חוזים, SLA וביטוח: בדיקה מוקדמת של מה ה-SLA של הספק מכסה בפועל (בדרך כלל זיכוי כספי שלא משפה על נזק עסקי אמיתי), לצד וידוא כי פוליסת ביטוח הסייבר או התקלות בארגון מכסה במפורש כשל של ספק ענן.
• תיעדוף תקציבי וכלכלי: על המנמ"ר להבין – בשיתוף המנכ"ל, כמובן – האם הארגון מצדיק ארכיטקטורה יקרה, מרובת עננים, או שמא שילוב של ערוץ חלופי, מיפוי תהליכים ותרגול נותן עבורו את המענה האופטימלי והמשתלם, כמו שקורה ברוב הארגונים. ערוצים אלה מאפשרים להנהלה פלטפורמה נפרדת ומוצפנת לניהול האירוע גם במקרה שבו השירותים שחבריה משתמשים בהם בשוטף מושבתים – וזה דבר שחייב לקרות.
• מיפוי תלויות שרשרת (Dependency Mapping): זיהוי כל המערכות הארגוניות שתלויות ב-Exchange Online או במנגנוני ההזדהות והאבטחה של הספק (כמו Copilot ,SharePoint וכלי אבטחה משיקים, שנפגעו גם הם בתקלה האחרונה).
• לבסוף, באחריותו להכין תיק עבודה ידני, שיגדיר לכל מחלקה קריטית בארגון – שירות לקוחות, כספים, תפעול וכדומה – נהלים לעבודה ללא מערכות מידע מרכזיות.

בזמן המשבר: שקיפות, בלימת עומסים ועבודה ידנית

• בידוד מהיר של מקור התקלה: הצלבת מידע מול לוחות הבקרה של הספק (Service Health), כדי לשלול מתקפת סייבר או תקלת רשת פנימית, ולמנוע מצוותי ה-IT לבזבז משאבים על פתרונות מקומיים לא רלוונטיים.
• תקשורת יזומה ושקופה מול ההנהלה והעובדים: פרסום הודעת הרגעה דרך ערוצי החירום החלופיים, הבהרה שמקור הבעיה חיצוני ומתן הנחיות תפעוליות ברורות.
• מתן הנחיות ברורות לעובדים: כחלק מאותה תקשורת, על המנמ"ר לתת להם הוראות חד משמעיות מה לא לעשות – להפסיק לאפס סיסמאות (דבר שהם עושים מתוך חרדה שהחשבון נפרץ), להימנע מהתקנה מחדש של הכלים שמשתמשים בהם, למשל האאוטלוק, ולהפסיק לשלוח שוב ושוב את אותן הודעות – פעולות שיוצרות עומס עצום ומחמירות את קריסת המערכות.
• ניהול תקשורת עם ההנהלה בתדירות קבועה: למשל, בכל שעתיים. הכוונה היא לתקשורת בין אם יש מה לעדכן ובין אם לאו. ניהולה יכול למנוע ואקום, שמייצר פאניקה ושמועות.
• בלימת עומסים מלאכותיים (מניעת Retry Storms): עליו להנחות את העובדים להימנע מריענון חוזר ונשנה של התיבות והאפליקציות, ולהשהות תהליכים אוטומטיים (סקריפטים, בוטים ואינטגרציות API), שמנסים להתחבר לשרתי הספק. זהו צעד חיוני במיוחד בתקלות מסוג זה, שבהן ההתאוששות היא מדורגת ושרתים שחוזרים לאוויר עלולים לקרוס שוב תחת עומס בקשות.
• הפעלת נהלי החירום והמעבר לערוצים החלופיים: העברת התקשורת הדחופה לערוצים שהוגדרו מראש והקפאת תהליכים שאינם דחופים.
• תיעוד שוטף של האירוע: רישום מדויק של זמני ההשבתה, התהליכים העסקיים שנפגעו והעלויות הישירות. נתונים אלה ישמשו בהמשך להגשת תביעות זיכוי ולדו"חות פנימיים.

בעקבות המשבר: התאוששות, ביקורתיות ותחקיר

• בקרת התאוששות וניקוי צווארי בקבוק: לאחר שהספק (במקרה הזה מיקרוסופט) מכריז על חזרה לשגרה, יש לוודא שכל תורי המיילים שהמתינו (Backlogs) משתחררים ללא אובדן מידע, ושכל המערכות המשיקות חוזרות להסתנכרן כראוי.
• ניהול גל ההתאוששות השני – על המנמ"ר לכך שעם שחרור תורי המיילים (ה-Backlogs) יגיע זרם של הודעות ישנות, שיתקבלו בבת אחת או בכפילויות. בנוסף, הוא צריך לבצע בדיקה מדגמית, שתוודא שהודעות קריטיות שנשלחו בזמן התקלה אכן הגיעו ליעדן.
• בדיקה ביקורתית של דו"ח הספק (PIR): לדרוש מהספק דו"ח של סיכום האירוע, ולקרוא אותו בעין מקצועית וביקורתית, כולל את הטענה שמקור התקלה הוא בשדרוגי רשת ותקלות תשתית.
• תחקיר פנימי (פוסט מורטם) נטול האשמות: המנמ"ר והגורמים הרלוונטיים הנוספים בארגון צריכים לערוך סקירה שקטה כדי לבחון מה עבד בתוכנית ההמשכיות העסקית, מה כשל ומה נדרש לשנות לפעם הבאה. זאת, מבלי לבוא בהאשמות לאף אחד, שכן אלה רק יקלקלו את התהליך וייצרו מרמור לא רצוי.

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