Microsoft 2 июня признала сбой Exchange Online, из-за которого письма у части клиентов шли с задержкой больше часа или не доходили вовсе. Для компаний, живущих на Microsoft 365, это не просто раздражающий инцидент: когда ломается корпоративная почта, одновременно проседают продажи, поддержка, найм и любая коммуникация, завязанная на email.
О проблеме, как пишет BleepingComputer, Microsoft сообщила в статусе инцидента EX1331830. Первое официальное подтверждение появилось в 10:33 по североамериканскому восточному времени после волны жалоб в соцсетях. Изначально речь шла о клиентах в Северной Америке и Германии, но уже к 14:24 EDT компания расширила зону возможного воздействия: в список попали также пользователи в Азиатско-Тихоокеанском регионе и остальной Европе.
Симптомы у инцидента вполне прикладные и неприятные. Одни пользователи видели временные SMTP-ошибки с сообщением о превышении лимита одновременных подключений к resource forest, после чего канал передачи закрывался. У других соединение обрывалось с ошибкой SuspiciousRemoteServerError. Если убрать терминологию, картина простая: почтовый конвейер Exchange Online начал сбоить, из-за чего отправка и получение писем стали непредсказуемыми. Для ИТ-команд это худший тип аварии: сервис формально жив, но ведет себя так, будто кому-то решил устроить хаос в рабочем дне.
Microsoft отдельно уточнила, что инженеры анализируют накопившуюся очередь писем и пытаются найти точку отказа. Это важная деталь. Когда в облачной почте растет backlog, проблема уже не сводится к единичным ошибкам доступа: начинается каскадный эффект. Письма задерживаются, потом приходят пачкой, SLA по ответам разъезжается, а бизнес-процессы, которые снаружи выглядят «автоматизированными», внезапно оказываются завязаны на старый добрый SMTP сильнее, чем принято признавать на стратегических сессиях.
Формально Microsoft классифицировала происшествие именно как incident, а не как незначительный деградационный эпизод. Для клиентов это сигнал, что влияние на сервис заметное и массовое. В корпоративной эксплуатации разница между «есть жалобы» и «объявлен инцидент» важна не только для статуса в админке. Это влияет на внутреннюю эскалацию, коммуникацию с бизнесом и на то, как быстро ИТ-отделу придется объяснять руководству, почему письма в CRM, тикеты из почты и внешние согласования вдруг стали вести себя как система из начала 2000-х.
Контекст для Microsoft тоже не самый удобный. В апреле компания уже закрывала проблемы с доступом к почтовым ящикам Exchange Online, которые неделями периодически затрагивали пользователей Outlook на iOS и macOS. Тогда же был еще один сбой Exchange Online, мешавший доступу к ящикам и календарям через Outlook в вебе, настольный Outlook, Exchange ActiveSync и другие протоколы подключения. А 1 июня Microsoft устраняла отдельный инцидент, из-за которого пользователи Teams и Office for the web не могли открывать файлы. Почти параллельно компания разбиралась и с проблемой, мешавшей настраивать многофакторную аутентификацию и заходить в My Sign-Ins. По отдельности такие истории выглядят как обычная жизнь крупного облака. Вместе они складываются в менее приятную картину: инфраструктура Microsoft 365 в 2026 году все чаще напоминает платформу, где локальные сбои быстро становятся глобальной операционной болью.
Для русскоязычной ИТ-аудитории здесь есть как минимум три практических вывода. Первый: сбой Exchange Online снова показывает, что даже «базовые» SaaS-сервисы нельзя считать бесконечно надежными только потому, что они у гиперскейлера. Второй: почта по-прежнему критична, даже если компания рассказывает про мессенджеры, коллаборацию и цифровое рабочее место. Контракты, сбросы паролей, письма от клиентов, системные уведомления, onboarding-кандидатов, алерты из легаси-систем, счета и закупки никуда не делись. Третий: планы непрерывности нужны не только для ERP, CI/CD и production, но и для email. Если команда не знает, как жить хотя бы несколько часов без стабильной доставки писем, значит, зависимость от одного облачного вендора недооценена.
Разработчикам и платформенным инженерам этот инцидент полезно читать не как новость про «упала почта», а как напоминание о проектных долгах. Если уведомления из продукта отправляются только через Exchange Online и нигде не буферизуются, деградация внешнего сервиса мгновенно становится вашей проблемой. Если внутренние автоматизации не умеют повторять отправку, менять маршрут или хотя бы честно сигнализировать пользователю о задержке, бизнес увидит вину в приложении, а не в облачной почте. Для продуктовых команд тут тоже есть повод проверить, какие пользовательские сценарии разваливаются первыми при задержке email на час и больше: логин по magic link, подтверждение регистрации, документы на подпись, платежные подтверждения, рассылки клиентам.
Бизнесу история напоминает еще об одной неприятной вещи: у массовых облачных платформ отказ редко выглядит как полное отключение, которое легко заметить и описать в одном письме. Куда опаснее серые зоны, когда часть писем проходит, часть висит, часть возвращается с техническими ошибками, а часть приходит слишком поздно, чтобы иметь смысл. В таких условиях компании теряют не только время ИТ-отдела, но и управляемость процессов. Руководители продаж не понимают, почему клиент «молчит», HR не видит ответов кандидатов, поддержка пропускает обращения, а внутренний комплаенс получает лишний источник риска там, где обычно никто не ждет сюрпризов.
Главный вопрос после этого инцидента не в том, сколько именно минут Microsoft будет разгребать очередь писем, а в том, сколько еще сервисных сбоев крупные заказчики готовы воспринимать как норму облачной зрелости. Когда даже почта в экосистеме Microsoft 365 все чаще требует сценариев обхода и ручной коммуникации, разговор о резервировании SaaS-процессов перестает быть теорией для архитектора и становится обычной задачей операционного менеджмента.