Лягли майже всі: розбираємо великий збій Azure Front Door 29-30 жовтня

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Всім привіт. Хто вчора ввечері намагався достукатися до своїх сервісів на Azure і ловив помилки — ви не одні. Microsoft щойно опублікував «попередній» звіт (Preliminary PIR) про цей масовий збій.

Це важливо: це ще не фінальний документ, а лише «що ми знаємо зараз». Повний і детальний розбір польотів з усіма висновками нам обіцяють протягом 14 днів. Але й тут є що почитати.

Отже, давайте подивимось, що ж у них там сталося.

Що трапилось?

Якщо коротко: з 15:45 UTC 29 жовтня до 00:05 UTC 30 жовтня 2025 року клієнти та сервіси Microsoft, що використовують Azure Front Door (AFD), могли спостерігати значні затримки (latency), тайм-аути та помилки.

Якщо ви не в курсі, Azure Front Door — це, по суті, глобальний фасад і балансувальник трафіку Microsoft. Через нього ходить трафік до купи сервісів. Якщо лягає він — лягає все, що за ним стоїть.

А список тих, хто «ліг» разом з ним, вражає. Це не просто «якийсь один сервіс». Постраждали (частково або повністю):

• App Service (ваші веб-додатки webapp)
• Azure Active Directory B2C (логін для зовнішніх користувачів)
• Azure Databricks
• Azure Portal
• Azure SQL Database
• Azure Virtual Desktop
• Microsoft Entra ID (старий добрий Azure AD)
• Microsoft Purview
• Microsoft Sentinel
• ...та багато інших.

Простіше кажучи, ввечері 29-го лягла значна частина інфраструктури Azure. Якщо у вас «тупив» портал, не проходили логіни через B2C чи відвалювались бази даних — ось і причина.

Наразі Microsoft каже, що помилки та затримки повернулися до норми, але зміни конфігурації в AFD тимчасово заблоковані. Вони все ще «дочищають» наслідки для невеликої кількості клієнтів.

Що пішло не так і чому?

Ось тут починається найцікавіше. Причина — «ненавмисна зміна конфігурації клієнта» (inadvertent tenant configuration change) в Azure Front Door.

Якщо перекласти з корпоративної на людську: хтось (або щось, якась автоматика) вилив нову конфігурацію на глобальний сервіс AFD. Ця зміна була «невалідною» або «непослідовною».

Що сталося далі:

1. Ця «крива» конфігурація призвела до того, що величезна кількість вузлів (нод) AFD по всьому світу не змогла нормально завантажитись.
2. Як наслідок, ці вузли почали «відвалюватися» з глобального пулу.
3. Почався «ефект доміно». Коли нездорові вузли випадали, весь трафік перекидався на ті, що ще були живі.
4. Живі вузли не витримували такого навантаження і теж починали деградувати. Це спричинило каскадний збій.

Microsoft негайно заблокував усі подальші зміни конфігурації (щоб не стало гірше) і почав розгортати «останню відому робочу» конфігурацію по всій мережі.

Відновлення було повільним, бо їм доводилося поступово перезавантажувати ноди і плавно повертати на них трафік, щоб не покласти їх знову. Класична проблема при відновленні масштабних систем.

А тепер — «вишенька на торті»

Чому цей «кривий» конфіг взагалі потрапив у прод? Microsoft пише:

«Тригером стала помилкова процедура розгортання конфігурації... Наші механізми захисту, призначені для перевірки та блокування будь-яких помилкових розгортань, не спрацювали через програмний дефект, який дозволив розгортанню обійти перевірки безпеки».

У них був баг в системі, яка мала б не допустити викатку проблемного конфігу на продакшн. Запобіжник не спрацював. Це класична помилка, коли ламається не сам сервіс, а система захисту (CI/CD, валідація, deployment gates), яка його обслуговує. Це означає, що їхні внутрішні тести та валідатори не вловили цей баг у системі деплою. Оце і є справжній root cause.

Як реагували? (Таймлайн)

Тут можна побачити, наскільки швидко (чи повільно) розвивалися події (час в UTC):

• 15:45 — Початок проблем у клієнтів.
• 16:04 — Спрацювали внутрішні моніторинги. (Майже 20 хвилин знадобилося, щоб система це помітила).
• 16:15 — Почалося розслідування, дивляться на зміни в AFD.
• 16:18 — Перше повідомлення на публічній сторінці статусу.
• 17:26 — Дуже цікавий пункт: Azure Portal був «переключений» (failed away) з Azure Front Door.
  • Це показує, наскільки все було серйозно. Вони вручну перенаправили трафік власного головного порталу в обхід свого ж проблемного сервісу. Це вже гасіння пожежі в ручному режимі.
• 17:30 — Заблокували всі нові зміни конфігурації для клієнтів.
• 17:40 — Почали розгортати «останню відому робочу» конфігурацію.
• 18:30 — Почали глобально «пушити» виправлення.
• 00:05 (30 жовтня) — Підтвердили, що вплив на клієнтів здебільшого ліквідовано.

Загалом, від перших симптомів до офіційного «полагодили» пройшло понад 8 годин. Для інфраструктури такого масштабу — це вічність.

Що далі?

Команда Azure проведе повний внутрішній ретроспективний аналіз і поділиться фінальними висновками протягом 14 днів.

Вони також нагадують (і це слушна порада) налаштувати Azure Service Health alerts.

Замість того, щоб дізнаватися про проблеми від розлючених клієнтів чи з твіттера, ви отримаєте сповіщення на пошту, в SMS чи вебхук, як тільки Microsoft визнає проблему. Перевірте, чи у вас це налаштовано: aka.ms/ash-alerts

Ну що ж, чекаємо на «фінальний» розбір польотів. З досвіду, там буде більше технічних деталей про той самий «програмний дефект» у системі захисту. А поки — перевірте свої алерти. Бо, як бачимо, навіть у хмарних гігантів бувають дуже «веселі» вечори.

Тримаємо стрій.