بازیابی Outlook مایکروسافت تحت ترافیک با شکست مواجه شد

این ویدیو چه مواردی را پوشش می‌دهد

• وابستگی بک‌اند هر عملیات را بررسی کنید: بیشتر عملکردهای اصلی Teams و دسترسی مستقیم به فایل‌های SharePoint فعال باقی ماندند، در حالی که ویژگی‌های وابسته به Exchange دچار مشکل شدند.
• مایکروسافت گزارش داد که سرورهای بازگردانده شده می‌توانند دوباره در صورت دریافت ترافیک از کار بیفتند؛ توضیح مؤلفه پردازش سلامت آن یک فرضیه باقی ماند.
• مهلت چهل و هشت ساعته ایمیل برای حفظ ایمیل‌های تأخیردار در طول پردازش صف و بک‌لاگ در نظر گرفته شده بود. این یک مهلت تعمیر یا تضمین تحویل جهانی نبود.
• راهنمایی معمولی محدود کردن Graph توصیه می‌کند در صورت عدم وجود هدر Retry-After و عقب‌نشینی نمایی را رعایت کنید؛ این راهنمایی این حادثه را تشخیص یا تعمیر نمی‌کند.

رونوشت ترجمه شده

ترجمه شده از روایت اصلی انگلیسی. صوت و زیرنویس‌های موجود توسط YouTube کنترل می‌شوند.

چرا سرورهای بازگردانده شده دوباره از کار افتادند؟

0:00 مایکروسافت سرورهای ایمیل را به سرویس بازگرداند. آنها ممکن بود دوباره در صورت بازگشت ترافیک از کار بیفتند. اینجا پیگیری توسعه‌دهنده است. در این ویدئو، چرا بازیابی همچنان با شکست مواجه می‌شد؟ و کدام بخش‌های برنامه شما همچنان کار می‌کرد؟ مایکروسافت همچنین به ایمیل‌های تأخیردار چهل و هشت ساعت فرصت داد. این در واقع چه سودی برای شما دارد؟ جمعه، سیزدهم نوامبر است و این The Daily Diff است.

0:18 Exchange Online سرویس ایمیل میزبان مایکروسافت است و سایر ویژگی‌های مایکروسافت

کدام ویژگی‌ها به Exchange وابسته بودند؟

0:22 365 به آن وابسته هستند. این تمایز مفید از صفحه وضعیت مایکروسافت است. تماس‌های Teams و چت‌های گروهی بیشتر کار می‌کردند. ویژگی‌های تقویم و درخواست‌های داده صندوق پستی ممکن بود با شکست مواجه شوند. وابستگی‌ای را که برنامه شما واقعاً استفاده می‌کند، بررسی کنید. این به این معنی است که یک جلسه همچنان می‌تواند برگزار شود در حالی که تقویم از همکاری امتناع می‌ورزد. دسترسی مستقیم به فایل‌ها در SharePoint نیز فعال باقی ماند، در حالی که برخی از ویژگی‌های اشتراک‌گذاری تحت تأثیر قرار گرفتند.

0:42 لوگو روی پنجره اطلاعات بسیار کمی در مورد اینکه کلیک بعدی شما به کدام بک‌اند نیاز دارد، به شما می‌دهد. اختلال از پنجشنبه آغاز شد، با بررسی اولیه مایکروسافت در دسترسی به صندوق پستی در قاره آمریکا. سپس تأیید کرد که کاربران در هر منطقه‌ای ممکن است تحت تأثیر قرار گیرند. CNN مشکلات را در بانک‌ها، دولت‌ها و دادگاه‌ها گزارش کرد. یک ایمیل گم شده تا زمانی که کار واقعی کسی به رسیدن آن بستگی داشته باشد، آزاردهنده است. توضیح اولیه مایکروسافت از دست رفتن سرورهای موجود بود.

چگونه ظرفیت از دست رفته یک سرویس را بیش از حد بارگذاری می‌کند؟

1:06 کاری که آن ماشین‌ها باید انجام می‌دادند، زیرساخت‌های باقی‌مانده را تحت فشار قرار داد. شما می‌توانید یک سرویس را با تقاضای عادی بیش از حد بارگذاری کنید زمانی که ظرفیت آن از بین می‌رود. صف طولانی‌تر می‌شود حتی اگر هیچ‌کس ناگهان علاقه شدیدی به ارسال ایمیل پیدا نکرده باشد. سپس شرکت بررسی‌های سلامت خودکار را بررسی کرد. این بررسی‌ها به تصمیم‌گیری در مورد اینکه آیا یک سرور می‌تواند کار را بپذیرد، کمک می‌کنند. مایکروسافت گفت که یک مؤلفه پردازش سلامت سرور ممکن است درگیر باشد. این یک فرضیه از تحقیقاتی است که هنوز در حال انجام است. ما گزارش نهایی حادثه را نداریم که دقیقاً توضیح دهد چرا آن سرورها ابتدا

1:29 غیرقابل دسترس شدند. به‌روزرسانی‌ها شبیه یک شیفت آنکال هستند که به تدریج علاقه کمتری به صبحانه پیدا می‌کند.

مایکروسافت ابتدا چه تلاشی کرد؟

1:37 استقرارها را متوقف کنید. ترافیک را جابجا کنید. سرورها را راه‌اندازی مجدد کنید. مایکروسافت یک بررسی سلامت جایگزین را تأیید کرد که زیرمجموعه‌ای را بازگرداند، و سیستم‌های خودکار را برای شناسایی و راه‌اندازی مجدد ماشین‌های غیرپاسخگو آماده کرد. هر به‌روزرسانی تلاشی برای بازیابی ظرفیت را توصیف می‌کرد. سپس خطی آمد که حلقه بازیابی را توضیح می‌دهد. مایکروسافت گفت سرورهایی که به سرویس بازگشتند ممکن است دوباره غیرپاسخگو شوند پس از دریافت ترافیک. یک ماشین ممکن است برگردد، کار واقعی دریافت کند و از پاسخ دادن دست بردارد.

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

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

2:39 بر اساس به‌روزرسانی جمعه مایکروسافت در ساعت یازده و چهار دقیقه UTC، اقدامات بازیابی در بخش‌هایی از منطقه آسیا و اقیانوسیه به پایان رسیده بود. ترافیک به تدریج در حال بازگشت بود، با بهبود در دسترسی به صندوق پستی و پردازش ایمیل‌های تأخیردار. برخی از کاربران هنوز ممکن بود با مشکلات متناوب مواجه شوند،

در زمان توقف گزارش چه چیزی مشخص بود؟

2:48 و بازیابی در جاهای دیگر ادامه داشت. این نقطه توقف گزارش ما است. مایکروسافت گفت هیچ مدرکی دال بر فعالیت مخرب ندارد، و قول یک گزارش کامل حادثه را پس از کاهش آسیب داد. من قبل از متهم کردن کسی منتظر آن گزارش خواهم ماند. کارآگاهی اینترنتی می‌تواند قبل از اینکه حتی صفحه را رفرش کرده باشید، یک مقصر به شما بدهد. برای توسعه‌دهندگان، Microsoft Graph وابستگی را به خصوص آسان می‌کند که از دست برود. درخواست‌های آن برای ایمیل، تقویم و مخاطبین Exchange ممکن بود منقضی شوند.

3:10 برنامه شما می‌تواند Graph را با موفقیت برای یک عملیات فراخوانی کند و در عملیات دیگری با شکست مواجه شود. یک درخواست نامربوط موفقیت‌آمیز اطلاعات کمی در مورد اینکه آیا عملیات صندوق پستی مورد نیاز کاربر شما کامل خواهد شد یا خیر، به شما می‌دهد. صفحه وضعیت حتی نیاز به مسیر خروج خودش داشت. مایکروسافت اطلاعات حادثه را به صورت عمومی منتشر کرد زیرا مدیران ممکن بود نتوانند مرکز مدیریت را برای خواندن وضعیت سرویس بارگذاری کنند.

چرا یک درخواست Graph ممکن است با شکست مواجه شود؟

3:20 وقتی داشبورد برای فهمیدن اینکه چه چیزی خراب است به چیزی که خراب است بستگی دارد، داشبورد به حادثه پیوسته است. یک پیوند وضعیت خارج از باند را در دسترس نگه دارید. برای محدود کردن عادی Graph، راهنمایی مایکروسافت می‌گوید که در صورت دریافت پاسخ «درخواست‌های زیاد»، تأخیر مجدد را رعایت کنید، و در صورت عدم وجود آن هدر، از عقب‌نشینی نمایی استفاده کنید. این راهنمایی مدیریت محدود کردن را انجام می‌دهد. این قطعی را تشخیص نمی‌دهد یا قول نمی‌دهد که تلاش‌های مجدد سرویس را بازیابی کنند.

3:46 حالا چهل و هشت ساعت. صفحه وضعیت گسترده مایکروسافت می‌گوید که پردازش صف و بک‌لاگ را در اولویت قرار داده و پنجره مهلت ایمیل را برای حفظ پیام‌های تأخیردار گسترش داده است. این به ایمیل‌های تأخیردار در طول بازیابی زمان بیشتری می‌دهد. این یک پنجره مهلت ایمیل را تعیین می‌کند. مایکروسافت هیچ مهلت چهل و هشت ساعته‌ای برای رفع سرویس نداد، و هیچ تضمینی نداد که هر پیامی به دست گیرنده برسد. بنابراین ادعاهای تحویل را صادقانه نگه دارید. یک اعلان تأخیردار لزوماً ناپدید نشده است،

پنجره ۴۸ ساعته ایمیل چه سودی دارد؟

4:05 و یک پیام در صف لزوماً به گیرنده خود نرسیده است. برای کارهای حساس به زمان، نتیجه را از طریق یک کانال مستقل تأیید شده بررسی کنید. یک پنجره کلاینت یک رسید تحویل خوش‌بینانه است زمانی که بک‌اند هنوز در حال بازیابی است. که چیزهای زیادی برای خواندن در گزارش نهایی حادثه باقی می‌گذارد. اگر ترجیح می‌دهید این را بخوانید تا اینکه من آن را بشنوید، diff هر روز صبح به صندوق ورودی شما می‌رسد، رایگان در thedailydiff.dev، پیوند زیر. بنابراین حکم امروز، NEEDS REVIEW. من بازیابی را تحت بررسی نگه می‌دارم زیرا به‌روزرسانی‌های خود مایکروسافت نشان دادند که سرورهای بازگردانده شده تحت ترافیک از کار می‌افتند.

4:28 آزمایش مفید، سرویس پایدار با کار واقعی است که از طریق آن انجام می‌شود. تا گزارش نهایی، علت اولیه باز باقی می‌ماند. و این تفاوت برای امروز است. من نیکو از Axrisi هستم. مسئولانه ادغام کنید. Microsoft’s Outlook recovery kept failing under traffic Microsoft’s November 12–13 email disruption exposed a recovery loop: returned servers could become unresponsive again under traffic. At the approved November 13 11:04:50 UTC cutoff, recovery had progressed across portions of Asia Pacific while intermittent issues and work elsewhere remained. This follow-up explains dependencies and delayed-mail safeguards.

بازیابی پایدار چه چیزی را باید اثبات کند؟

4:49 Microsoft’s November 12–13 email disruption exposed a recovery loop: returned servers could become unresponsive again under traffic. At the approved November 13 11:04:50 UTC cutoff, recovery had progressed across portions of Asia Pacific while intermittent issues and work elsewhere remained. This follow-up explains dependencies and delayed-mail safeguards. Check the backend dependency of each operation: most core Teams functionality and direct SharePoint file access remained functional, while Exchange-dependent features were impaired. Microsoft reported that returned servers could become unresponsive again when traffic reached them; its health-processing-component explanation remained a hypothesis. The extended forty-eight-hour email timeout was intended to preserve delayed mail during queue and backlog processing. It was no repair deadline or universal delivery guarantee. Ordinary Graph throttling guidance recommends honoring Retry-After and exponential backoff when that header is absent; it does not diagnose or repair this incident. Why did returned servers fail again? Which features depended on Exchange?

منابع

1. ExpandedMicrosoftservicehealth, reportingcutoffNovember13 11:04:50UTC; earlier10:01:07observationshistoricalMicrosoft
2. Returned servers can become unresponsive again once they receive trafficMicrosoft 365 Status
3. Health-processing component investigation hypothesisMicrosoft 365 Status
4. Alternative health check returned a subset of serversMicrosoft 365 Status
5. Isolate, restart and reintroduce traffic to test stabilityMicrosoft 365 Status
6. Unavailable servers strain remaining infrastructureMicrosoft 365 Status
7. Initial Exchange mailbox-access investigation in the AmericasMicrosoft 365 Status
8. Users in any region may be affectedMicrosoft 365 Status
9. Email timeout extended to preserve delayed messagesMicrosoft 365 Status
10. Paused deployments, traffic redistribution and server restartsMicrosoft 365 Status
11. Independent live reporting on the Microsoft email disruptionCNN
12. Microsoft Graph throttling guidanceMicrosoft Learn
13. Exchange Online service descriptionMicrosoft Learn
14. Satya Nadella portrait by OFFICIAL LEWEB PHOTOS (2013), CC BY 2.0. Whole portrait-based artwork adapted by cropping, background removal, resizing and text/composition; vendor identity only, no endorsement or current reaction.OFFICIAL LEWEB PHOTOS
15. Portrait-only CC BY 2.0 licence; separate from third-party source/cartoon rightsCreative Commons
16. WWE still. Brief silent process commentary; WWE, The Simpsons/20th Television/Disney, Microsoft and other source owners retain copyright. Hosting and this specific editorial-use decision provide no blanket reuse grant or copyright clearance. The portrait licence is separate from third-party source/cartoon rights.WWE / Imgflip source hosting
17. The Simpsons/Bob GIF. Brief silent process commentary; WWE, The Simpsons/20th Television/Disney, Microsoft and other source owners retain copyright. Hosting and this specific editorial-use decision provide no blanket reuse grant or copyright clearance. The portrait licence is separate from third-party source/cartoon rights.The Simpsons / 20th Television / Disney; GIPHY source hosting