תקלת הענק הנרחבת, שהחלה אתמול (ה') בשעות הצהריים בשרתי מיקרוסופט, ממשיכה לשבש קשות גם הבוקר את שירותי הענן והתקשורת המרכזיים של ענקית הטכנולוגיה, בראשם שירות המייל אאוטלוק, פלטפורמת Teams, מודל הבינה המלאכותית Copilot, וחלק מיישומי Microsoft 365.
מדובר בתקלה המשמעותית ביותר של החברה בשנה האחרונה: ההשבתה הממושכת פוגעת לא רק במשתמשים פרטיים, אלא גם בבתי עסק, בשירותים ציבוריים חיוניים, בבתי חולים ובמוסדות ממשלתיים ברחבי העולם, שנאלצים לעבור זמנית לתקשורת אלטרנטיבית.
הסיבה לתקלה
למרות המאמצים הגדולים שהשקיעו מהנדסי מיקרוסופט בתיקון התקלה לתוך שעות הבוקר, היא ממשיכה להשפיע על משתמשים באזורים שונים בעולם, כולל בישראל. אתרי מעקב כמו Downdetector מתעדים עדיין מאות אלפי דיווחים ממשתמשים שלא מצליחו לשלוח או לקבל הודעות מייל או להתחבר לפגישות מתוזמנות.
על-פי ניתוחים ראשוניים של מיקרוסופט ומומחים חיצוניים, התקלה אינה נובעת ממתקפת סייבר או פעילות זדונית כלשהי, אלא מתקלה בניטור שרתים: שורה של שרתים, שנכשלו בבדיקות התקינות האוטומטיות (Automated Health Checks) של המערכת, יצאו מכלל פעולה והעמיסו משקל יתר על תשתיות הגיבוי הנותרות.
צוות הסטטוס הרשמי של Microsoft 365, אישר אמש בעדכון טכני, כי מדובר בבעיה הגורמת לשרתים להיכשל בבדיקות התקינות האוטומטיות ולהפוך ללא זמינים: "התחלנו בהפעלה מחדש של כל השרתים המושפעים ואנו עוקבים אחר בריאותם עם חזרתם לשירות". במיקרוסופט אכן ניסו להעלות את השרתים מחדש, אך זרם התעבורה העצום גרם לחלקם לקרוס פעם נוספת - מה שהאריך משמעותית את משך ההשבתה.
"אנו ממשיכים לפעול בכל המסלולים הזמינים לשחזור השירות, שכן הפעולות שננקטו עד כה לא סיפקו את הפתרון הצפוי", נמסר מהחברה אמש, "הבדיקות שלנו מצאו, כי תהליך מרכזי בשרתים שנפגעו 'הוצף', מה שגורם לשרתים להפסיק להגיב ותורם לאובדן קיבולת".
צ'ארלס לאמנה, סגן נשיא בכיר בחברה, אמר בהצהרה רשמית, כי היא פועלת בדחיפות לטיפול בבעיה, אך הדגיש כי "אין שום אינדיקציה לכך שמדובר בתוצאה של פעילות זדונית או סייבר".
דיווחים עולמיים על תקלה בשירות אאוטלוק של מיקרוסופט
(צילום מסך)
על-פי צוות המחקר של חברת הניטור והתשתיות ThousandEyes (מבית סיסקו), מדובר במה שמכונה "שגיאות פסק זמן (Timeouts)". שגיאות כאלה מתרחשות כאשר מכשיר או תוכנה (כמו אאוטלוק) שולחים בקשה לשרת מרוחק, אך השרת אינו מגיב בתוך פרק זמן מוגדר מראש.
כדי שהתוכנה לא תיתקע לנצח בהמתנה לתשובה, מוגדר לה "שעון עצר" – וברגע שהזמן אוזל ללא תגובה - החיבור נקטע ומוצגת השגיאה. כאשר מדובר בשרתים רבים שנופלים, הבקשות של מיליוני משתמשים מנותבות לשרתים הבודדים שנותרו פעילים. התוצאה: השרתים הללו "מוצפים" בבת אחת ואינם מספיקים לעבד את כל הפניות בזמן.
כיוון שהמידע באינטרנט נשלח ב"חבילות" קטנות - אם התשתית עמוסה, חלק מה"חבילות" הללו "הולכות לאיבוד" בדרך והשרת לא מקבל בקשה שלמה כדי להשיב עליה.
לפי גיל מסינג, ראש מטה ענקית אבטחת המידע הישראלית צ׳ק-פוינט, גם מומחי החברה מעריכים כי מדובר בבעיה רוחבית בשירותי ה-exchange כתוצאה משינוי קונפיגורציה, שהביא לעומס יתר ולקריסה באפשרות החיבור לשרתים. "לא מדובר בתקלה נדירה בשירותים בסדר הגודל הזה, אבל בגלל המשתמשים העצום - האפקט שלה דרמטי".
לפי מסינג, מצבים כאלה של עומס יתר יכולים לקרות כתוצאה משלל סיבות: בעיה בקוד מסוים, בעיות בהזדהות מול השרתים, בעיות בניתוב בשרתים או בדרך אליהם, ועוד. הבעיה העיקרית היא משך זמן הטיפול הארוך שנדרש לכך. ברגע שיצליחו המהנדסים לתקן את זה אז - רצף השליחה והקבלה ימשיך לעבוד כרגיל.
לפי אייל רון, סמנכ״ל פיתוח ב-Eon שפיתחה פלטפורמה להגנה, גיבוי ושחזור של מידע ארגוני – "כשהמייל והכלים לשיתוף קבצים תלויים באותה תשתית, תקלה אחת יכולה לשבש יום עבודה שלם. המבחן של תוכנית התאוששות הוא אם הצוותים יכולים להגיע למידע הקריטי ולהמשיך לעבוד בזמן התקלה. את זה צריך לתרגל מראש".
