+− THE DAILY DIFFdev & AI news
NEEDS REVIEW

Збій відновлення Outlook від Microsoft через навантаження

Збій електронної пошти Microsoft 12–13 листопада виявив цикл відновлення: повернуті сервери могли знову стати недоступними під час трафіку.

Want to see our stories first on Google? Add us to your preferred sources — it helps us grow.

Збій електронної пошти Microsoft 12–13 листопада виявив цикл відновлення: повернуті сервери могли знову стати недоступними під час трафіку. До затвердженого часу відсікання 13 листопада, 11:04:50 UTC, відновлення було завершено в деяких частинах Азіатсько-Тихоокеанського регіону, тоді як тимчасові проблеми та роботи в інших місцях залишалися. Це доповнення пояснює залежності та заходи безпеки для затриманих листів.

Читати письмову версію (англійською) ↗

Що охоплює це відео

  • Перевіряйте залежність кожної операції від бекенду: більшість основних функцій Teams та прямий доступ до файлів SharePoint залишалися функціональними, тоді як функції, що залежать від Exchange, були порушені.
  • Microsoft повідомила, що повернуті сервери могли знову стати недоступними, коли до них надходив трафік; пояснення компонента обробки стану залишалося гіпотезою.
  • Розширений сорокавосьмигодинний тайм-аут електронної пошти мав на меті зберегти затримані листи під час обробки черги та накопичення. Це не було кінцевим терміном ремонту чи універсальною гарантією доставки.
  • Звичайні рекомендації щодо обмеження трафіку Graph радять враховувати Retry-After та експоненційну затримку, коли цей заголовок відсутній; це не діагностує та не виправляє цей інцидент.

Запитання та відповіді

Чому повернуті поштові сервери Microsoft могли знову вийти з ладу під навантаженням?

Microsoft повідомила, що повернуті сервери могли знову стати недоступними, як тільки вони отримували трафік. Її розслідування описало перевантажені процеси та можливу проблему в компоненті, що обробляє стан сервера, але початковий тригер все ще чекав остаточного звіту про інцидент. Цей епізод ілюструє концептуально послідовність повернення, роботи та рецидиву; він не претендує на доведену внутрішню архітектуру або остаточну першопричину.

Дивіться цю частину 0:00 · Microsoft 365 Status · Microsoft 365 Status · Microsoft 365 Status

Чому дзвінки Teams могли працювати, тоді як функції календаря не працювали?

Більшість основних дзвінків, зустрічей та чатів Teams залишалися функціональними, згідно з розширеним повідомленням Microsoft про стан служби. Сценарії календаря та планування залежали від Exchange Online і могли не працювати під час збою. Прямий доступ до файлів SharePoint також залишався функціональним. Корисна відмінність на рівні додатків полягає в залежності, що стоїть за операцією, а не в розгляді кожної функції під логотипом продукту як такої, що має однаковий стан відмови.

Дивіться цю частину 0:19 · Microsoft

Чи встановлював сорокавосьмигодинний тайм-аут електронної пошти термін ремонту?

Microsoft розширила вікно тайм-ауту електронної пошти, щоб зберегти затримані повідомлення, надаючи пріоритет обробці черги та накопичення. Це дало затриманій пошті більше часу під час відновлення. Публічне повідомлення не містило сорокавосьмигодинного терміну ремонту і не гарантувало, що кожне повідомлення досягне свого одержувача. Тому сповіщення, що очікує або знаходиться в черзі, вимагало фактичної перевірки доставки або результату, перш ніж на нього міг покладатися чутливий до часу робочий процес.

Дивіться цю частину 4:05 · Microsoft · Microsoft 365 Status

Як збій Exchange вплинув на програми Microsoft Graph?

Запити для пошти Exchange Online, календаря та контактів могли закінчуватися тайм-аутом, згідно з Microsoft. Програма могла зіткнутися з різними результатами в різних операціях з різними базовими залежностями. Цей епізод рекомендує перевіряти фактичну залежність операції від служби. Окрема документація Microsoft щодо звичайного обмеження трафіку обговорює врахування Retry-After та експоненційної затримки, коли цей заголовок відсутній; ці політики не встановлюють причину цього інциденту і не обіцяють відновлення послуги.

Дивіться цю частину 3:17 · Microsoft · Microsoft Learn

Який був вердикт The Daily Diff щодо відновлення Microsoft?

Вердикт The Daily Diff був ПОТРЕБУЄ ПЕРЕВІРКИ. Ніко тримав відновлення на контролі, тому що оновлення Microsoft описували, як повернуті сервери виходили з ладу під навантаженням. Корисним тестом відновлення була стійка робота з надходженням реального навантаження. Початкова причина залишалася відкритою на момент відсікання звітів епізоду, причому Microsoft обіцяла повний звіт про інцидент та дії щодо глибокого захисту після пом'якшення.

Дивіться цю частину 4:48 · Microsoft · Microsoft 365 Status · Microsoft 365 Status

Перекладена стенограма

Перекладено з оригінальної англійської розповіді. Доступне аудіо та субтитри контролюються YouTube.

Чому повернуті сервери знову вийшли з ладу?

0:00 Microsoft повернула поштові сервери в експлуатацію. Вони могли знову припинити відповідати, коли трафік повертався. Ось доповнення від розробників. У цьому відео: чому відновлення постійно зазнавало невдач? І які частини вашого додатка все ще працювали? Microsoft також надала затриманій електронній пошті сорок вісім годин. Що це насправді дає? П'ятниця, тринадцяте листопада, і це The Daily Diff.

0:18 Exchange Online — це хостингова служба електронної пошти Microsoft, і інші функції Microsoft 365

Які функції залежали від Exchange?

0:22 залежать від неї. Ось корисна відмінність зі сторінки стану Microsoft. Дзвінки Teams і групові чати переважно працювали. Функції календаря та запити даних поштової скриньки могли не працювати. Перевірте залежність, яку фактично використовує ваш додаток. Це означає, що зустріч все ще може відбутися, хоча календар відмовляється співпрацювати. Прямий доступ до файлів у SharePoint також залишався функціональним, тоді як деякі функції обміну були порушені.

0:42 Логотип на вікні мало що говорить про те, який бекенд потрібен вашому наступному кліку. Збій розпочався в четвер, Microsoft спочатку розслідувала доступ до поштових скриньок в Америці. Потім вона підтвердила, що користувачі в будь-якому регіоні можуть бути зачеплені. CNN повідомила про проблеми в банках, урядах та судах. Відсутність електронного листа незручна, доки чиясь реальна робота не залежить від його надходження. Раннє пояснення Microsoft полягало у втраті доступних серверів.

Як відсутня потужність перевантажує сервіс?

1:06 Робота, яку мали б виконувати ці машини, навантажувала іншу інфраструктуру. Ви можете перевантажити службу звичайною потребою, коли її потужність зникає. Черга стає довшою, навіть якщо ніхто раптово не виявив пристрасті до надсилання електронної пошти. Потім компанія досліджувала автоматичні перевірки стану. Ці перевірки допомагають вирішити, чи може сервер приймати роботу. Microsoft заявила, що компонент, який обробляє стан сервера, може бути задіяний. Це гіпотеза з розслідування, яке все ще триває.

1:29 У нас немає остаточного звіту про інцидент, який би пояснював, чому ці сервери спочатку стали недоступними. Оновлення читаються як чергування, що стає дедалі

Що Microsoft спробувала спочатку?

1:37 менш зацікавленим у сніданку. Призупинити розгортання. Перемістити трафік. Перезавантажити сервери. Microsoft перевірила альтернативну перевірку стану, яка повернула підмножину назад, і підготувала автоматизовані системи для виявлення та перезапуску недоступних машин. Кожне оновлення описувало спробу відновити потужність. Потім з'явилася фраза, яка пояснює цикл відновлення. Microsoft заявила, що сервери, повернуті в експлуатацію, можуть знову стати недоступними, як тільки вони отримають трафік.

1:59 Машина могла повернутися, отримати реальну роботу та припинити відповідати. Це спостереження є сильнішим доказом, ніж будь-яка впевнена теорія у відповідях. Уявіть той самий сервер у цих станах. Недоступний. Повернуто в експлуатацію. Приймає трафік. Знову недоступний. Це ілюструє розповідь Microsoft. Що викликає цей останній перехід, залишається без відповіді. Перезапуск може призвести до тимчасового

2:18 покращення, тоді як умова, яка виводить з ладу сервер, залишається невирішеною. Порада вимкнути його та знову ввімкнути починає нараховувати понаднормові. Інженери повинні перевірити, що відбувається після повернення роботи. Клієнти потребують, щоб послуга продовжувала працювати під час наступного запиту, і наступного. Microsoft обмежила певний трафік, що надходив до ураженої інфраструктури в деяких місцях. Вона також відновила підмножину серверів, використовуючи попередню конфігурацію, щоб

2:39 перевірити, чи залишатимуться вони чутливими. Це були повідомлені експерименти з пом'якшення наслідків. Призупинення розгортань під час відновлення не дає нам доказів того, що п'ятничне розгортання спричинило початковий збій.

Що було відомо на момент відсікання звітів?

2:48 За оновленням Microsoft у п'ятницю об 11:04 UTC, дії з відновлення були завершені в деяких частинах Азіатсько-Тихоокеанського регіону. Трафік поступово повертався, з покращеннями в доступі до поштових скриньок та обробці затриманих електронних листів. Деякі користувачі все ще могли стикатися з періодичними проблемами, і відновлення в інших місцях тривало. Це наш час відсікання звітів. Microsoft заявила, що не має доказів зловмисної діяльності, і пообіцяла повний звіт про інцидент після пом'якшення.

3:10 Я б зачекав на цей звіт, перш ніж призначати лиходія. Детективна робота в Інтернеті може дати вам винуватця ще до того, як ви закінчили оновлювати сторінку. Для розробників Microsoft Graph робить залежність особливо легкою для пропуску.

Чому один запит Graph міг не спрацювати?

3:20 Її запити для пошти Exchange, календаря та контактів могли закінчуватися тайм-аутом. Ваша програма може успішно викликати Graph для однієї операції та зазнати невдачі для іншої. Успішний непов'язаний запит мало що говорить про те, чи буде завершено операцію з поштовою скринькою, яка потрібна вашому користувачеві. Сторінці стану навіть потрібен був власний шлях відступу. Microsoft публічно розмістила інформацію про інцидент, оскільки адміністратори могли не мати змоги завантажити центр адміністрування для перегляду стану служби. Коли панель інструментів для з'ясування того, що зламано, залежить від того, що зламано,

3:46 панель інструментів приєдналася до інциденту. Тримайте доступним посилання на позасмуговий стан. Для звичайного обмеження трафіку Graph, рекомендації Microsoft говорять поважати затримку повторної спроби, коли запит отримує відповідь занадто багато запитів, і використовувати експоненційну затримку, коли цей заголовок відсутній. Ці рекомендації керують обмеженням трафіку. Вони не діагностують цей збій і не обіцяють, що повторні спроби відновлять послугу. Тепер сорок вісім годин.

Що дає 48-годинне вікно пошти?

4:05 Розширена сторінка стану Microsoft говорить, що вона пріоритезувала обробку черги та накопичення і розширила вікно тайм-ауту електронної пошти, щоб зберегти затримані повідомлення. Це дає затриманій пошті більше часу під час відновлення. Вона встановлює вікно тайм-ауту пошти. Microsoft не надала сорокавосьмигодинного терміну для виправлення послуги, і не дала гарантії, що кожне повідомлення надійде. Тому дотримуйтесь чесних заяв про доставку. Затримане сповіщення не обов'язково зникло,

4:28 і повідомлення в черзі не обов'язково досягло свого одержувача. Для термінової роботи перевірте результат через затверджений незалежний канал. Клієнтське вікно є оптимістичним підтвердженням доставки, коли бекенд ще відновлюється. Що залишає багато для читання в остаточному звіті про інцидент. Якщо ви волієте прочитати це, ніж почути від мене, звіт надходить у вашу поштову скриньку щоранку, безкоштовно на thedailydiff.dev, посилання нижче. Отже, сьогоднішній вердикт: ПОТРЕБУЄ ПЕРЕВІРКИ.

Що потрібно довести для стійкого відновлення?

4:49 Я б тримав відновлення на контролі, тому що власні оновлення Microsoft показували, що повернуті сервери виходили з ладу під навантаженням. Корисним тестом є стійка робота з надходженням реального навантаження. До остаточного звіту початкова причина залишається відкритою. І це The Daily Diff на сьогодні. Я Ніко з Axrisi. Об'єднуйте відповідально.

Джерела

  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

Niko from Axrisi

Nikoloz Turazashvili · Vexrail · Axrisi

LinkedIn · dev.to · GitHub · X · Substack

Пов'язані відео

daily · uk · 8 лист. 2026 р.

Microsoft AI Frontiers: розповідь Ленгфорда про реорганізацію та спільні дослідницькі конвеєри

Джон Ленгфорд каже, що AI Frontiers закінчився після його переходу до Microsoft AI. Його розповідь описує зіткнення щодо пріоритетів досліджень, спільної інфраструктури навчання та відсутнього шляху д

5:06 ↗
daily · uk · 27 жовт. 2026 р.

Спроба завантаження зонда, заблокована Qwen, краулер під назвою Roblox, видалення JIT Python і огляди LLM у Debian: чотири історії розробників в одному Daily Diff

Чотири історії розробників за один вівторок: Cohere повідомляє, що Qwen3.8-Flash-Next від Alibaba спробував завантажити файл-зонд у сховище Alibaba Cloud у Пекіні з тестового "пісочниці", яка його заб

6:25 ↗
daily · uk · 29 вер. 2026 р.

Уряд Нідерландів створює власний Linux, щоб уникнути Microsoft

Уряд Нідерландів розробляє DAWO, робоче місце на базі NixOS, призначене для зменшення залежності від іноземних постачальників технологій. Проєкт об'єднує операційну систему, офісне програмне забезпече

5:01 ↗