مایکروسافت تجزیه و تحلیل علت اصلی مشکلات بزرگ ورود به سیستم مایکروسافت 365 این هفته را پست می کند

این هفته تقریباً 5 ساعت از کار افتادن مایکروسافت 365 داشتیم. با کاربرانی که نمی توانند به چندین سرویس از جمله OneDrive و Microsoft Teams وارد شوند.

امروز مایکروسافت تجزیه و تحلیل علت اصلی این مشکل را منتشر کرد، که مایکروسافت می گوید به دلیل به روز رسانی سرویس بود که قرار بود حلقه آزمایش اعتبارسنجی داخلی را هدف قرار دهد اما در عوض به دلیل نقص کد پنهان در سیستم فرآیند استقرار ایمن (SDP) سرویس باطن خدمات Azure AD مستقیماً در محیط تولید مایکروسافت مستقر شد.

مایکروسافت می‌گوید که تقریباً بین ساعت 21:25 UTC در 28 سپتامبر 2020 و 00:23 UTC در 29 سپتامبر 2020، مشتریان هنگام انجام عملیات احراز هویت برای همه برنامه‌ها و سرویس‌های مایکروسافت و شخص ثالث که به 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، مشتریان ممکن است با خطاهایی در انجام عملیات احراز هویت برای همه برنامه‌ها و سرویس‌های مایکروسافت و شخص ثالث که به 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 باعث شد که مستقیماً در محیط تولید ما مستقر شود و فرآیند اعتبارسنجی عادی ما را دور بزند.

Azure AD به گونه‌ای طراحی شده است که یک سرویس توزیع‌شده جغرافیایی است که در یک پیکربندی فعال-فعال با پارتیشن‌های متعدد در مراکز داده‌های متعدد در سراسر جهان مستقر شده و با مرزهای ایزوله ساخته شده است. به طور معمول، تغییرات در ابتدا یک حلقه اعتبارسنجی را هدف قرار می دهد که حاوی داده های مشتری نیست، سپس یک حلقه داخلی که فقط شامل کاربران مایکروسافت است و در نهایت محیط تولید ما را هدف قرار می دهد. این تغییرات در مراحل مختلف در پنج حلقه در طول چند روز مستقر می شوند.

در این مورد، سیستم SDP به دلیل نقص پنهانی که بر توانایی سیستم در تفسیر فراداده استقرار تأثیر می‌گذارد، نتوانست حلقه آزمایش اعتبارسنجی را به درستی هدف قرار دهد. در نتیجه، تمام حلقه ها به طور همزمان مورد هدف قرار گرفتند. استقرار نادرست باعث کاهش در دسترس بودن سرویس شد.

در عرض چند دقیقه پس از ضربه، ما اقداماتی را برای برگرداندن تغییرات با استفاده از سیستم‌های برگشت خودکار انجام دادیم که معمولاً مدت و شدت ضربه را محدود می‌کردند. با این حال، نقص پنهان در سیستم SDP ما، ابرداده استقرار را خراب کرده بود و ما مجبور شدیم به فرآیندهای بازگشت دستی متوسل شویم. این به طور قابل توجهی زمان کاهش این موضوع را افزایش داد.

کاهش: نظارت ما در عرض چند دقیقه پس از تاثیر اولیه، تخریب سرویس را شناسایی کرد و ما بلافاصله شروع به عیب یابی کردیم. اقدامات کاهشی زیر انجام شد:

• برخورد در ساعت 21:25 UTC آغاز شد و در عرض 5 دقیقه نظارت ما وضعیت ناسالم را تشخیص داد و مهندسی بلافاصله درگیر شد.
• در طول 30 دقیقه بعد، همزمان با عیب یابی مشکل، مجموعه ای از مراحل برای به حداقل رساندن تأثیر مشتری و تسریع در کاهش آن انجام شد. این شامل کاهش پیشگیرانه برخی از سرویس‌های Azure AD برای مدیریت بار پیش‌بینی‌شده پس از اعمال تخفیف و شکست در بارهای کاری خاص به یک سیستم تأیید اعتبار Azure AD پشتیبان بود.
• در ساعت 22:02 UTC، ما علت اصلی را تعیین کردیم، اصلاح را آغاز کردیم و مکانیسم‌های بازگشت خودکار خود را آغاز کردیم.
• بازگشت خودکار به دلیل خرابی ابرداده SDP ناموفق بود. در ساعت 22:47 UTC، فرآیند به‌روزرسانی دستی پیکربندی سرویس را که سیستم SDP را دور می‌زند، آغاز کردیم و کل عملیات تا ساعت 23:59 UTC تکمیل شد.
• در ساعت 00:23 UTC تعداد کافی نمونه سرویس باطن به حالت سالم بازگشتند تا به پارامترهای عملیاتی سرویس عادی برسند.
• تمام نمونه‌های سرویس با تأثیر باقی‌مانده تا ساعت 02:25 UTC بازیابی شدند.

مراحل بعدی: ما صمیمانه بابت تأثیری که بر مشتریان متأثر شده است عذرخواهی می کنیم. ما به طور مداوم در حال انجام اقداماتی برای بهبود پلتفرم Microsoft Azure و فرآیندهای خود هستیم تا اطمینان حاصل کنیم که چنین حوادثی در آینده رخ نمی‌دهند. در این مورد، این شامل (اما محدود به) موارد زیر است:

قبلاً تکمیل کرده ایم

• رفع نقص کد پنهان در سیستم SDP باطنی Azure AD.
• سیستم بازگشت مجدد موجود را اصلاح کرد تا امکان بازیابی آخرین ابرداده خوب شناخته شده را برای محافظت در برابر فساد فراهم کند.
• دامنه و فراوانی تمرینات عملیات برگشت را گسترش دهید.

مراحل باقی مانده شامل

• برای جلوگیری از کلاس مشکلات شناسایی شده در اینجا، حفاظت های اضافی را برای سیستم SDP پشتیبان سرویس Azure AD اعمال کنید.
• تسریع در عرضه سیستم احراز هویت پشتیبان Azure AD برای همه سرویس های کلیدی به عنوان اولویت اصلی برای کاهش قابل توجه تأثیر یک نوع مشکل مشابه در آینده.
• سناریوهای Azure AD روی خط لوله ارتباطات خودکار که ارتباطات اولیه را در عرض 15 دقیقه پس از تأثیر به مشتریان آسیب دیده ارسال می کند.

ارائه بازخورد: لطفاً با شرکت در نظرسنجی به ما در بهبود تجربه ارتباط با مشتری Azure کمک کنید: https://aka.ms/AzurePIRSurvey

از طريق ZDNet