Сбой Exchange Admin Center 12 октября лишил администраторов Exchange Online доступа к основной веб-консоли управления почтой: вместо интерфейса EAC они видели сообщение «Internal Server Error». Microsoft признала инцидент в 09:37 UTC и позже восстановила сервис откатом недавнего изменения конфигурации. Для российских команд, которые продолжают использовать Microsoft 365 в международных структурах, это очередное напоминание: облачная почта может остаться доступной пользователям, но администрировать её в нужный момент окажется невозможно.
По данным The Register, проблема затрагивала попытки открыть Exchange Admin Center — веб-консоль для управления Exchange Online. Через неё администраторы работают с почтовыми ящиками, группами, настройками получателей и другими повседневными задачами. Microsoft сначала сообщила лишь о внутренних ошибках при входе в EAC, а спустя более часа уточнила техническую картину: при обращении к консоли возникали неожиданные перенаправления HTTP 302. Обходного пути в этот момент не было.
Формулировка «нет обходного пути» здесь важнее, чем может показаться. Почтовый сервис не обязательно перестаёт доставлять письма из-за недоступности админ-консоли, однако у IT-службы исчезает привычный оперативный инструмент. Нельзя быстро проверить параметры ящика, изменить членство в группе, отреагировать на запрос безопасности или исправить ошибку в настройке получателя. Для компании с распределённой поддержкой это уже не косметический дефект интерфейса, а ограничение в управлении критичным сервисом.
Примерно через два часа после первого сообщения Microsoft начала тестировать откат изменения EAC. Финальное обновление подтвердило причину: недавняя конфигурационная правка вызвала некорректные HTTP-ответы в затронутом пути запросов и не давала администраторам успешно открыть консоль. Возврат настройки восстановил штатную работу. Компания также пообещала пересмотреть само изменение, а заодно мониторинг и телеметрию, чтобы быстрее замечать похожие симптомы.
Сам по себе откат — нормальный и часто правильный способ остановить инцидент. Ненормальной выглядит повторяемость сценария у одного поставщика: изменение конфигурации попадает в рабочую среду, ломает доступ к важному компоненту, после чего сервис возвращают к предыдущему состоянию. В сентябре Microsoft уже связывала проблемы с доступом к сайтам и страницам SharePoint Online с конфигурационным изменением. В апреле аналогичная история затронула Outlook для iOS. В 2025 году конфигурационная ошибка также стала причиной масштабного сбоя Microsoft 365.
Сбой Exchange Admin Center особенно показателен тем, что проблема лежала не в сложной миграции данных и не в отказе инфраструктуры, а в слое маршрутизации и конфигурации веб-доступа. Такие изменения часто выглядят безопасными: их проще развернуть, чем новый код, и они могут не проходить тот же путь проверок. Но для SaaS-платформы конфигурация давно стала частью продукта. Ошибка в ней способна закрыть клиентам доступ к сервису не хуже неудачного релиза приложения.
Для разработчиков и SRE-команд здесь нет новой магии, зато есть неприятно знакомый список мер: поэтапное включение изменений, отдельная проверка путей аутентификации и редиректов, синтетические тесты из внешней сети, автоматический откат по метрикам доступности. Важна и наблюдаемость именно пользовательского сценария. Метрика работающих серверов ничего не скажет, если администратор получает HTTP 302 по кругу или страницу с внутренней ошибкой. Проверять нужно не только здоровье бэкенда, но и успешное завершение реальной операции в интерфейсе.
Бизнесу стоит заранее определить, какие действия невозможны при недоступной админ-консоли, кто принимает решение об эскалации и какие альтернативные каналы управления доступны. Это касается не только Exchange: у большинства SaaS-продуктов есть разрыв между доступностью пользовательской части и доступностью панели администратора. Внутренний план реагирования должен учитывать оба состояния, иначе формально «живой» сервис окажется бесполезным для службы поддержки.
Microsoft сообщила, что предварительный отчёт по инциденту выпустит в течение двух рабочих дней, а итоговый — на следующей неделе. Главный вопрос не в том, почему помог откат: причина уже названа. Вопрос в том, изменит ли компания процесс проверки конфигурационных правок так, чтобы следующий сбой Exchange Admin Center не стал ещё одной строкой в привычной серии «поправили настройку — откатили настройку».