כשהענן נופל: תקלת Microsoft 365 ומה על עסק לקחת ממנה

ב-12 בנובמבר בשעה 18:17 שעון קייב החלה ב-Microsoft 365 תקלה, והיא נמשכת גם בעת פרסום החומר הזה. תיבות דואר, יומנים, Teams ו-SharePoint הפסיקו להיפתח. נפגעו חברות ברחבי העולם, ובהן אוקראיניות, משום שכאן רוב הדואר הארגוני פועל על Microsoft 365.

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

מה בדיוק אינו עובד

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

• הכניסה לחשבון עובדת. מיקרוסופט מזהה את המשתמש ומעניקה גישה — כלומר לא הסיסמה, לא ההרשאות ולא הגדרות הגישה קשורות לעניין.
• בקשת ההודעות מחזירה שגיאת שרת — קוד 502. לא «אין גישה», לא «סיסמה שגויה», אלא «השרת לא הצליח להשיב».
• היומן נופל באותו אופן — קוד 503. כלומר העניין אינו בדואר בלבד, אלא בכל מה שיושב ב-Exchange Online.
• רשומות הדואר של הדומיין (MX) לא השתנו והן ממשיכות להצביע על מיקרוסופט. הדואר נשלח לאן שהוא אמור.

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

הכרונולוגיה הרשמית

מיקרוסופט מנהלת את התקלה תחת שני מספרים: EX1550543 — גישה לתיבות Exchange Online, ו- MO1550821 — כל מה שתלוי ב-Exchange. תקלה נפרדת של Teams (TM1550488) כבר נסגרה. בתחילה דובר על אמריקה, ולאחר מכן שונה הניסוח ל«עשוי להשפיע על משתמשים בכל אזור».

השעות שלהלן הן שעון קייב.

• 18:17, 12 בנובמבר. משתמשים אינם יכולים לפתוח את תיבותיהם. מיקרוסופט מודיעה שהיא חוקרת בעיה בגישה לדואר.
• 20:19. נרשם עומס מוגבר בכמה אזורים בבת אחת.
• 21:18. הבהרה: העומס גדל לא בשל זרם תעבורה. חלק מהשרתים הפך לפתע לבלתי זמין, ואת עבודתם נטלו על עצמם האחרים.
• 21:43. מתברר שהשרתים הפגועים אינם עוברים את בדיקת התקינות האוטומטית — והמערכת עצמה מוציאה אותם משירות.
• 21:57. «לא איתרנו שום שינוי אחרון הקשור לתחילת התקלה».
• 00:00, 13 בנובמבר. «התהליך המרכזי בשרתים הפגועים נכנס לעומס יתר, ובשל כך אובדת תפוקה».
• בלילה. הבהרה: מי שנכנס לעומס יתר הוא דווקא התהליך האחראי על יצירת חיבורים מאובטחים. במקביל מיקרוסופט מתחילה לבטל שינוי אחרון בתצורת הרשת, שעיתויו עולה בקנה אחד עם תחילת התקלה.
• 06:11. «אנו מאשרים: אין כל סימן לכך שמדובר בתוצאה של פעולה זדונית».
• 13:04. השחזור הושלם באזור אסיה-פסיפיק, התעבורה מוזרמת בהדרגה, והעבודה מורחבת לאזורים נוספים.

הסיבה: עד כה לא נאמרה

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

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

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

מה קורה להודעות

זו השאלה המטרידה ביותר, ולכן בנפרד.

• המסירה מתעכבת — מיקרוסופט מודה בכך במפורש בתיאור התקלה.
• חלון ההמתנה של הודעה הוארך ל-48 שעות. בדרך כלל שרת שלא הצליח למסור הודעה בתוך זמן מסוים מחזיר אותה לשולח בציון כישלון. חלון מוארך פירושו שההודעות לא יוקפצו בחזרה אלא ימתינו בתור.
• על אובדן נתונים מיקרוסופט לא דיווחה. אך כדאי לדייק: היא גם לא אמרה במפורש «דבר לא אבד». מה שנאמר מילולית הוא שההודעות המעוכבות נשמרות.

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

מה על עסק לעשות ממש עכשיו

1. ודאו שהבעיה אינה אצלכם. אם הכניסה לחשבון עוברת וההודעה אינה נפתחת — זה הצד של הספק. מצב התקלה נראה במרכז הניהול של Microsoft 365, במדור «תקינות השירותים», לפי המספרים EX1550543 ו-MO1550821.
2. אל תיגעו בהגדרות. בזמן תקלה של אחרים, את הנזק הגדול ביותר גורמים ניסיונות «לתקן» אצלכם: רשומות דומיין שהוחלפו, תוכנות דואר שהותקנו מחדש, סיסמאות שאופסו. כשהשירות יחזור, תצטרכו להתיר את התוצאות שלכם עצמכם.
3. הפעילו ערוץ חלופי. העבירו עניינים דחופים עם לקוחות למסרונים או לטלפון למשך התקלה. הזהירו את מי שממתין לתשובה — עדיף משפט קצר «הדואר שלנו מושבת, כתבו לנו בטלגרם» על פני שתיקה.
4. תעדו את ההשבתה. אם עצירת העבודה עלתה לכם כסף, רשמו את השעה ואת התוצאות. למיקרוסופט יש התחייבויות לרמת שירות; אם התקלה הזו מקימה עילה לפיצוי דווקא במקרה שלכם — זו שאלה להסכם הרישוי שלכם ולשותף שדרכו נרכשו הרישיונות.

ארבע מסקנות לעתיד

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

1. ערוץ תקשורת חלופי חייב להתקיים לפני התקלה, ולא להימצא תוך כדי. אם כל התקשורת עם הלקוחות עוברת בדואר של ספק אחד, תקלה אצלו עוצרת אתכם לחלוטין. בוט בטלגרם, מסרון ארגוני, טלפון — כל דבר שהלקוחות מכירים מראש.
2. אל תשימו הכול בסל אחד. דואר, מסמכים, תקשורת, אימות והגנה אצל ספק יחיד נוחים בדיוק עד היום שבו משהו אצלו נשבר. אז נעצר הכול בבת אחת. כך בדיוק קרה: יחד עם הדואר נפלו Teams, SharePoint ו-Defender.
3. מה שמכניס כסף צריך להיות בשליטתכם. האתר, ההזמנות, הקטלוג, הפניות — כדאי להחזיק אותם היכן שאתם יכולים לבדוק את המצב בעצמכם, להעלות עותק ולהשיב ללקוח בלי להמתין לדוח של מישהו אחר.
4. דעו להבחין בין «אצלנו» ל«אצלם». הבדיקה הפשוטה מתחילת המאמר חוסכת שעות של בהלה ומונעת שינויים מיותרים בהגדרות.

איך זה מסודר אצלנו

אנחנו משתמשים ב-Microsoft 365 לדואר ולמסמכים — ובמהלך התקלה הזו גם התיבה שלנו לא נפתחה. לעומת זאת, מה שאנחנו עושים עבור לקוחות עבד וממשיך לעבוד: אתרים על המערכת שלנו Smart CMS, צ'אטבוטים, אזורי לקוח וטלפוניה חיים על שרתים משלנו, בנפרד מהדואר. אף אתר לקוח לא נפגע מהתקלה הזו.

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

על המקורות

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

---

את החומר הכין צוות SmartGT. אם אינכם בטוחים עד כמה העסק שלכם תלוי בספק יחיד ומה יקרה לאתר שלכם ביום כזה — כתבו לנו: center@uvc.in.net או +38 073 949 61 79. נסתכל יחד ונאמר בכנות מה כדאי לפזר בין סלים שונים.