Microsoft тестирует исправление для сервиса Exchange Online после того, как сбой Outlook растянулся на несколько часов и ударил по корпоративной почте, поиску писем и авторизации. Для русскоязычных IT-команд история знакомая и неприятная: когда ложится облачная почта, встает не только переписка, но и половина рутинных процессов вокруг задач, встреч и согласований.
О проблеме, как пишет TechCrunch, Microsoft сообщила 31 августа 2026 года. Компания подтвердила масштабный инцидент в Outlook и Exchange Online, своем облачном сервисе для корпоративной почты, календаря, контактов и задач. По ходу дня формулировки в статус-апдейтах становились все конкретнее: сначала речь шла о деградации функций, затем Microsoft указала на компонент аутентификации, а позже добавила, что эффект вышел за пределы одного Exchange Online и затронул другие сервисы.
Хронология у инцидента показательная. По данным Downdetector, первые массовые жалобы начали появляться около 11:30 по восточному времени США. К 14:00 число пользовательских сообщений на площадке перевалило за 5000. В 12:43 ET Microsoft уже публично признала, что часть пользователей сталкивается с ухудшением работы разных функций Exchange Online и что инженеры изучают телеметрию и диагностические данные, чтобы локализовать источник сбоя. То есть это был не короткий всплеск и не один капризный регион, а заметная, хорошо видимая авария в одном из самых критичных корпоративных сервисов.
Симптомы тоже не ограничились фразой «почта работает нестабильно». У пользователей наблюдались задержки и ошибки при отправке и получении сообщений, проблемы с поиском содержимого в почтовых ящиках, сбои в операциях с mailbox, ошибки аутентификации и другие нарушения в цепочке доставки сообщений. Для бизнеса это как раз тот тип аварии, который неприятен не громкостью, а липкостью: формально часть сервиса может отвечать, но реальные сценарии уже ломаются. Письмо ушло или зависло? Поиск не находит переписку, потому что индексация не обновилась, или потому что пользователь вообще не может нормально авторизоваться? Такие инциденты особенно раздражают службы поддержки, потому что пользовательский опыт распадается на десятки «плавающих» симптомов.
Ключевая техническая деталь в том, что Microsoft связала инцидент с компонентом аутентификации. Компания заявила, что нашла проблему, подготовила стратегию remediation и начала применять ее к части инфраструктуры, чтобы проверить, снимает ли она влияние сбоя. Позже описание стало еще точнее: внутреннее расследование показало, что возможной причиной стала ошибка конфигурации, из-за которой компоненты аутентификации не разворачивались как ожидалось на части инфраструктуры. Параллельно Microsoft начала перепроверять недавние изменения в сервисе, чтобы понять, почему это произошло. Переводя с корпоративного на инженерный: проблема, похоже, не в абстрактном «облако устало», а в конкретной неудачной конфигурации или изменении, которое зацепило критический слой доступа к сервису.
Это важный нюанс для разработчиков и SRE-команд. Когда ломается аутентификация, последствия почти всегда выглядят шире исходной причины. Один проблемный компонент начинает портить сразу несколько пользовательских сценариев: логин, доступ к ящику, синхронизацию, поиск, часть фоновых операций и смежные сервисы, которые завязаны на те же механизмы проверки доступа. Именно поэтому Microsoft отдельно уточнила, что инцидент затронул не только Exchange Online. Для компаний, которые строят внутренние сервисы на общей auth-инфраструктуре, кейс банальный, но поучительный: единая точка входа удобна ровно до первой неудачной выкладки.
В этом смысле сбой Outlook снова напомнил, насколько сильно бизнес все еще завязан на электронной почте, даже если презентации уже третий год обещают жизнь «после почтового клиента». Пока вендоры продают Copilot, AI-агентов и автоматизацию знаний, реальная операционная ткань компаний по-прежнему держится на письмах, календарях и доступе к ящикам. И если выпадает именно Outlook с Exchange, проблема быстро перестает быть неудобством одного отдела. Она бьет по продажам, рекрутингу, согласованиям, поддержке клиентов и любым процессам, где письмо остается официальным каналом коммуникации.
Для IT-руководителей и продуктовых команд здесь нет нового откровения, зато есть старый добрый чек-лист, который многие откладывают до следующей аварии. Если компания зависит от Microsoft 365, ей нужны не только статус-страница и чат с аккаунт-менеджером, но и рабочие сценарии на случай частичной недоступности: альтернативные каналы для критичных уведомлений, понятный порядок внутренней коммуникации, резервные инструкции для саппорта, а в идеале еще и мониторинг пользовательских симптомов, а не только health-показателей провайдера. Сбой Outlook особенно неприятен тем, что внешне он может выглядеть как хаос из мелких поломок, хотя корень у него один.
На момент 17:00 ET 31 августа Microsoft все еще продолжала устранять последствия и донастраивать выбранную стратегию исправления. Для отрасли это не просто еще один красный индикатор на статус-панели, а напоминание о простой вещи: чем больше корпоративная инфраструктура централизована вокруг облачного набора одного поставщика, тем дороже становится любая ошибка в базовых компонентах вроде аутентификации. Вопрос уже не в том, случится ли следующая такая авария, а в том, сколько компаний к ней готовы не на словах, а в процедурах и архитектуре.