מיקרוסופט מפרסמת ניתוח שורש לבעיות ההתחברות הגדולות של השבוע של Microsoft 365

השבוע הייתה לנו זמן השבתה של כמעט 5 שעות עבור Microsoft 365, עם משתמשים שאינם יכולים להיכנס לשירותים מרובים, כולל OneDrive ו-Microsoft Teams.

היום מיקרוסופט פרסמה ניתוח שורש של הבעיה, שלדברי מיקרוסופט נובע מעדכון שירות שנועד לכוון לטבעת בדיקת אימות פנימית, אך במקום זאת נפרס ישירות בסביבת הייצור של מיקרוסופט עקב פגם קוד סמוי במערכת Azure AD backend service Safe Deployment Process (SDP).

מיקרוסופט אומרת שבין השעה 21:25 UTC לערך ב-28 בספטמבר 2020 ו-00:23 UTC ב-29 בספטמבר 2020, לקוחות נתקלו בשגיאות בביצוע פעולות אימות עבור כל היישומים והשירותים של Microsoft ושל צד שלישי התלויים ב-Azure Active Directory (Azure AD ) לאימות. הבעיה טופלה לחלוטין עבור כולם רק בשעה 2:25 למחרת.

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

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

מיקרוסופט התנצלה בפני הלקוחות שהושפעו ואמרה שהם ממשיכים לנקוט בצעדים לשיפור פלטפורמת Microsoft Azure והתהליכים שלהם כדי להבטיח שאירועים כאלה לא יתרחשו בעתיד. אחד השלבים המתוכננים כולל החלת הגנות נוספות על מערכת ה-SDP האחורית של שירות Azure AD כדי למנוע את סוג הבעיות שזוהו.

קרא את הניתוח המלא למטה:

RCA - שגיאות אימות בין שירותי מיקרוסופט מרובים ויישומים משולבים של Azure Active Directory (זיהוי מעקב SM79-F88)

סיכום ההשפעה: בין השעה 21:25 לערך UTC ב-28 בספטמבר 2020 ו-00:23 UTC ב-29 בספטמבר 2020, לקוחות עשויים להיתקל בשגיאות בביצוע פעולות אימות עבור כל היישומים והשירותים של Microsoft ושל צד שלישי התלויים ב-Azure Active Directory (Azure AD) לצורך אימות. גם יישומים המשתמשים ב-Azure AD B2C לאימות הושפעו.

משתמשים שעדיין לא אומתו לשירותי ענן באמצעות Azure AD היו בסבירות גבוהה יותר לחוות בעיות וייתכן שראו מספר כשלים בבקשות אימות התואמות למספרי הזמינות הממוצעים המוצגים להלן. אלה נצברו על פני לקוחות ועומסי עבודה שונים.

• אירופה: אחוזי הצלחה של 81% למשך התקרית.
• אמריקה: שיעור הצלחה של 17% למשך התקרית, שיפור ל-37% רגע לפני ההפחתה.
• אסיה: שיעור הצלחה של 72% ב-120 הדקות הראשונות של התקרית. עם תחילת תנועת השיא של שעות העבודה, הזמינות ירדה ל-32% בשפל.
• אוסטרליה: שיעור הצלחה של 37% למשך התקרית.

השירות הוחזר לזמינות תפעולית רגילה עבור רוב הלקוחות עד השעה 00:23 UTC ב-29 בספטמבר 2020, עם זאת, ראינו כשלים נדירים בבקשת אימות שעשויים להשפיע על הלקוחות עד 02:25 UTC.

משתמשים שעברו אימות לפני מועד תחילת ההשפעה היו פחות סבירים לחוות בעיות בהתאם ליישומים או לשירותים שהם ניגשים אליהם.

אמצעי חוסן קיימים שירותי זהויות מנוהלות מוגנות עבור מכונות וירטואליות, ערכות קנה המידה של מכונות וירטואליות ושירותי Azure Kubernetes עם זמינות ממוצעת של 99.8% לאורך כל התקרית.

סיבה שורשית: ב-28 בספטמבר בשעה 21:25 UTC, נפרס עדכון שירות המכוון לטבעת בדיקת אימות פנימית, מה שגרם לקריסה בעת ההפעלה בשירותי הקצה האחורי של Azure AD. פגם קוד סמוי במערכת Azure AD backend service Safe Deployment Process (SDP) גרם לפריסה זו ישירות לתוך סביבת הייצור שלנו, תוך עקיפת תהליך האימות הרגיל שלנו.

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

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

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

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

• ההשפעה החלה ב-21:25 UTC, ותוך 5 דקות הניטור שלנו זיהה מצב לא בריא וההנדסה הופעלה מיד.
• במהלך 30 הדקות הבאות, במקביל לפתרון הבעיות, בוצעו סדרה של צעדים כדי לנסות למזער את השפעת הלקוחות ולזרז את הפחתה. זה כלל קנה מידה יזום של חלק משירותי Azure AD כדי לטפל בעומס הצפוי ברגע שהייתה מוחלת הפחתה וכשל בעומסי עבודה מסוימים למערכת גיבוי של Azure AD Authentication.
• בשעה 22:02 UTC, קבענו את סיבת השורש, התחלנו בתיקון והתחלנו את מנגנוני ההחזרה האוטומטיים שלנו.
• החזרה אוטומטית נכשלה עקב השחתה של המטא נתונים של SDP. בשעה 22:47 UTC התחלנו את התהליך לעדכון ידני של תצורת השירות שעוקפת את מערכת ה-SDP, וכל הפעולה הושלמה עד 23:59 UTC.
• עד 00:23 UTC חזרו מספיק מופעי שירות אחורי למצב בריא כדי להגיע לפרמטרים תפעוליים רגילים של השירות.
• כל מקרי השירות עם השפעה שיורית אוחזרו עד 02:25 UTC.

השלבים הבאים: אנו מתנצלים בכנות על ההשפעה על הלקוחות שנפגעו. אנו נוקטים כל הזמן בצעדים כדי לשפר את Microsoft Azure Platform ואת התהליכים שלנו כדי להבטיח שאירועים כאלה לא יתרחשו בעתיד. במקרה זה, זה כולל (אך לא מוגבל ל) את הדברים הבאים:

כבר השלמנו

• תוקן את פגם הקוד הסמוי במערכת Azure AD backend SDP.
• תיקן את מערכת החזרה לאחור הקיימת כדי לאפשר שחזור המטא-נתונים הידועים והטובים האחרונים כדי להגן מפני שחיתות.
• הרחב את ההיקף והתדירות של תרגילי פעולת החזרה לאחור.

השלבים הנותרים כוללים

• החל הגנות נוספות על מערכת SDP האחורית של שירות Azure AD כדי למנוע את סוג הבעיות שזוהו כאן.
• זירז את השקת מערכת אימות הגיבוי Azure AD לכל שירותי המפתח כעדיפות עליונה כדי להפחית משמעותית את ההשפעה של סוג דומה של בעיה בעתיד.
• תרחישי Azure AD לצינור התקשורת האוטומטית המפרסמת תקשורת ראשונית ללקוחות המושפעים תוך 15 דקות מהשפעה.

ספק משוב: אנא עזרו לנו לשפר את חוויית התקשורת של לקוחות Azure על ידי השתתפות בסקר שלנו: https://aka.ms/AzurePIRSurvey

באמצעות ZDNet