אחרי יותר מ-17 שעות של שיבושים, תיקון לרכיב האימות והניתוב מציג שיפור חלקי, אך שירותי הדואר עדיין לא התאוששו לחלוטין וגם Teams ו-Copilot מושפעים
מיקרוסופט הצליחה להחזיר שרתים לפעילות, אבל אז גילתה שהבעיה האמיתית רק מתחילה: ברגע שהמשתמשים חזרו להתחבר, חלק מהשרתים פשוט הפסיקו להגיב שוב. התקלה שהחלה ביום חמישי בשירות Outlook הפכה לאירוע מתמשך, שמשבש את העבודה בארגונים ברחבי העולם ומאלץ את מהנדסי החברה לחפש דרכים חדשות לייצב את התשתיות. גם הבוקר (שישי), אחרי יותר מ-17 שעות, השירות עדיין לא חזר לפעילות מלאה.
בשיא האירוע נרשמו בארצות הברית קרוב ל-130 אלף דיווחי תקלות ב-Outlook בתוך פרק זמן קצר, לצד דיווחים ממדינות נוספות. משתמשים התקשו לפתוח תיבות דואר, לשלוח הודעות ולגשת ליומנים, ובחלק מהמקרים גם שירותים ארגוניים אחרים הפסיקו לתפקד כראוי. השיבושים הורגשו גם בישראל, אם כי אין נתונים רשמיים על מספר המשתמשים המקומיים שנפגעו.
כשדואר אלקטרוני משבש גם את היומן
מוקד התקלה הוא Exchange Online, שירות הדואר הארגוני שעליו נשענים Outlook ורכיבים נוספים של Microsoft 365. המשמעות היא שלא מדובר רק בבעיה באפליקציה מסוימת: המשתמשים עלולים להיתקל בשגיאות גם דרך הדפדפן, גם בתוכנת Outlook למחשב וגם בטלפונים ניידים. אפילו חיבורים באמצעות ממשקי API, שמשמשים מערכות ארגוניות להעברת מידע, עלולים להיכשל.
ההשפעה מגיעה הרבה מעבר לתיבת הדואר. ב-Microsoft Teams דווח על בעיות ביומנים, בתזמון פגישות ובהזמנות, אף שיכולות הליבה של השיחות, הצ'אטים והפגישות המקוונות המשיכו לפעול ברובן. גם Microsoft 365 Copilot נפגע, בעיקר בפעולות שדורשות גישה להודעות דואר, למסמכים ולמידע ארגוני.
ברשימת השירותים המושפעים נמצאים גם SharePoint Online, Microsoft Planner, Microsoft To Do, Microsoft Defender ורכיבים נוספים. חשוב להבחין בין תקלה בפונקציה מסוימת לבין השבתה של שירות שלם: למשל, הגישה לקבצים המאוחסנים ישירות ב-SharePoint המשיכה לפעול, גם כשיכולות אחרות התלויות בשירותי הדואר נפגעו.
הפגיעה אינה מוגבלת למשרדים פרטיים. שיבושים דווחו גם במערכות ממשלתיות ובמוסדות ציבוריים בכמה מדינות, לרבות יפן, שם אישרו הרשויות כי התקלה השפיעה על תשתיות המחשוב שלהן. כשמערכת הדואר היא גם הבסיס ליומן הארגוני, לאימות פעולות ולתהליכי עבודה, תקלה אחת מצליחה לעצור הרבה יותר מההתכתבות היומית.
המלכודת של בדיקות התקינות האוטומטיות
בתחילת האירוע זיהתה מיקרוסופט עומס חריג על שרתים בכמה אזורים בעולם. אלא שהחקירה חשפה שהעומס לא נבע מעלייה פתאומית במספר המשתמשים. שרתים רבים הפכו לבלתי זמינים, ולכן הבקשות שהיו אמורים לטפל בהן הועברו לשרתים שנותרו פעילים. אלה נאלצו להתמודד עם עומס גבוה יותר, והמערכת החלה להחזיר שגיאות חיבור.
אחד הממצאים הראשונים היה ששרתים נכשלו בבדיקות התקינות האוטומטיות שלהם (Health Checks), ולכן הוצאו ממעגל השירות. בהמשך התברר שתהליך האחראי ליצירת חיבורים מאובטחים בשרתים נכנס בעצמו לעומס חריג, עד שהשרתים הפסיקו לטפל בבקשות. זו גם הסיבה שהפעלה מחדש לא הספיקה: כשהתעבורה חזרה, הבעיה חזרה איתה.
מיקרוסופט ניסתה כמה כיווני פעולה במקביל. היא עצרה זמנית פריסות תוכנה ושינויי תצורה, העבירה תעבורה למסלולים חלופיים, הגבילה סוגי חיבורים באזורים מסוימים וניסתה להחזיר שרתים לשירות בהדרגה. החברה גם בדקה אפשרות לחזור לתצורות תוכנה קודמות כדי לברר אם שינוי שבוצע לאחרונה קשור לכשל.
אלא שלא כל הניסיונות הניבו את התוצאות הרצויות. במהלך הלילה הודיעה החברה שהשינויים שנועדו לשפר את יציבות השירות אינם פועלים כמצופה. רק בהמשך דווח על התקדמות משמעותית יותר: תיקון לרכיב תצורה הקשור לאימות ולניתוב חיבורים הצליח לשפר את יציבות השרתים שעליהם הותקן.
בעדכון שפורסם הבוקר הודיעה מיקרוסופט שהיא מרחיבה בהדרגה את פריסת התיקון, תוך מתן עדיפות לאזורים הנמצאים בשעות הפעילות העסקיות שלהם. במקביל היא ממשיכה להפעיל מחדש תשתיות, להחזיר אליהן תעבורה בהדרגה ולנטר את היציבות. נכון לעדכון מהשעה 11:05 שעון ישראל, ניכרו סימני התייצבות ראשוניים, אבל קיבולת השירות עדיין לא חזרה לרמה הרגילה.
במיקרוסופט גם הבהירו כי בשלב זה אין בידיהם אינדיקציה לפעילות זדונית שגרמה לתקלה. הסיבה הראשונית והמדויקת לאירוע עדיין נמצאת בחקירה, והחברה מתכננת לפרסם דוח מפורט לאחר השלמת ההתאוששות.
חלון של 48 שעות והמחיר של תלות בענן
אחד הצעדים המעניינים שמיקרוסופט נוקטת נוגע להודעות הדואר שלא הצליחו להגיע ליעדן. כששרתים אינם זמינים, הודעות עשויות להצטבר בתורים ולהמתין לניסיונות מסירה חוזרים. אם ההמתנה נמשכת זמן רב מדי, המערכות עלולות להפסיק לנסות להעביר אותן.
כדי להקטין את הסיכון לאובדן הודעות שממתינות למשלוח, מיקרוסופט האריכה את חלון ההמתנה של הודעות דואר ל-48 שעות. זה לא מבטיח שכל הודעה תגיע מיד כשהשירות יחזור, אבל מעניק למערכות זמן נוסף להשלים את המסירה לאחר שהעומס יפחת.
למשתמשים שנתקלים עדיין בשגיאות התחברות, אין כרגע פתרון מקומי שיכול לעקוף את הכשל בשרתים. החלפת דפדפן, התקנה מחדש של Outlook או מעבר בין מכשירים לא בהכרח יעזרו כאשר הבעיה נמצאת ב-Exchange Online עצמו. מנהלי מערכות יכולים לעקוב אחר האירוע דרך עמוד מצב השירותים הרשמי או מרכז הניהול של Microsoft 365, באמצעות מזהי האירועים EX1550543 ו-MO1550821.
התקלה ממחישה בעיה רחבה יותר בתלות של ארגונים בספקיות ענן. היתרון של Microsoft 365 הוא שכל הכלים עובדים יחד: הדואר מחובר ליומן, היומן מחובר ל-Teams, והמידע הארגוני זמין גם ל-Copilot. אבל אותו חיבור הדוק יוצר תלות משותפת. כששירות מרכזי אחד נפגע, התוצאות מגיעות למערכות שכלל לא נראות קשורות אליו.
עבור עסקים בישראל, זו תזכורת מעשית לחשיבות של ערוצי תקשורת חלופיים, גישה עצמאית למידע קריטי ותוכנית המשכיות עסקית שאינה נשענת רק על זמינות ספק הענן. אין צורך להחזיק שרת דואר פרטי לכל חברה, אבל כדאי לדעת איך ממשיכים לעבוד גם כשהדואר הארגוני אינו זמין.
מיקרוסופט כבר מציגה שיפור ביציבות השרתים, אך עדיין לא מסרה מועד מחייב לחזרת כל השירותים לפעילות תקינה. המבחן שלה כעת אינו רק להחזיר את השרתים לפעולה, אלא לוודא שהם ממשיכים לעבוד גם כשמיליוני משתמשים חוזרים אליהם.
