Вечером 31 августа 2026 года начался масштабный сбой в Microsoft 365, зарегистрированный в центре администрирования как EX1464935 и позднее расширенный под номером MO1465074. Последствия не ограничились почтой. Exchange Online упал вместе с Teams, SharePoint Online и OneDrive for Business, а вместе с ними и инструменты управления и безопасности в Purview и Defender XDR. Компания, которая общалась с клиентами по почте, координировала работу внутри через чат, хранила файлы в облаке и следила за безопасностью через панель мониторинга, потеряла всё это в один и тот же момент.

Microsoft назвала причиной проблему с базовой конфигурацией аутентификации, которую используют несколько внутренних сервисов в инфраструктуре Exchange Online, и применила поэтапное устранение: компоненты аутентификации сначала повторно применили на выборке инфраструктуры, а затем расширили охват. Доставка почты и поиск были восстановлены 1 сентября, а ограниченное воздействие на небольшую часть пользователей сохранялось до 2 сентября. Полный перерыв длился больше суток, а остаточные проблемы — двое.

Эта статья не о Microsoft. У каждого крупного провайдера бывают сбои, и раньше мы уже писали о перебоях в других сервисах ИИ. Эта статья о том, что обнажил именно этот сбой, и это опаснее, чем кажется на первый взгляд.

То, что вы считаете шестью системами, может оказаться одной

Попросите любого руководителя перечислить свои системы, и вы получите список: почтовая система, система чата, файловая система, система безопасности. Четыре названия, четыре значка, обычно четыре строки в договоре. Естественное предположение: если упадёт одна, она не потянет за собой остальные, ведь это разные вещи.

Но названия не являются границами систем. Настоящая граница — это то, что эти сервисы разделяют под поверхностью: кто проверяет вашу личность, где хранятся сессии, через какую сеть они проходят. Когда четыре сервиса используют один слой аутентификации, с точки зрения риска это один сервис, как бы раздельно они ни выглядели в счёте.

Неприятность в том, что эта общность никогда не проявляется в обычное время. Напротив, именно она даёт вам удобный единый вход и плавную интеграцию между почтой и файлами. Вы покупаете удобство каждый день и расплачиваетесь за него раз в несколько лет, одним долгим днём.

Это касается средней саудовской компании не меньше, чем глобальной корпорации. Подумайте, сколько ваших сервисов держится на одной учётной записи Google, или на одном номере WhatsApp, или на одном хостинг-провайдере, или на одном сотруднике, который хранит пароли. Каждый из них — единая точка отказа. Разница в том, что ваши меньше и их гораздо проще устранить.

Составьте карту зависимостей за один час

Вам не нужны ни инструменты, ни консультант. Нужны лист бумаги, час времени и честные ответы. В первой колонке запишите каждую операцию, без которой ваш бизнес не протянет целый день: приём заказов, выставление счетов, ответы клиентам, расчёт зарплаты, оказание услуги. Затем задайте по каждой три вопроса:

  • От какого внешнего сервиса зависит эта операция? Запишите коммерческое название прямо: этот почтовый провайдер, та платформа интернет-магазина, тот платёжный шлюз, тот провайдер сообщений.
  • С какой учётной записью или идентификатором вы входите? Обычно именно здесь возникает сюрприз. Вы обнаружите четыре разных сервиса, в которые входят через одну учётную запись, или три сервиса, привязанных к одному мобильному номеру для кодов подтверждения.
  • Если это остановится прямо сейчас, какая альтернатива есть в течение часа? Если ответ — никакой, вы нашли реальную, а не теоретическую единую точку отказа.

Когда закончите, одна-две записи будут повторяться в большинстве строк. Это ваши общие зависимости. Не пытайтесь устранить их все: это и нереалистично, и неэкономно. Возьмите строку, которая останавливает выручку, и займитесь сначала ею.

Самый предотвратимый тип сбоев: сроки действия

Не все сбои одинаковы. Одни возникают из-за сложности, которую вы не контролируете. Другие — из-за даты, записанной где-то, где её никто не читает. Второй тип предотвратить проще всего, и он повторяется чаще всего, потому что ему нужно лишь отслеживание.

Вот сроки действия, которые незаметно управляют вашим бизнесом, и каждый из них должен быть в одном календаре с ответственным, названным по имени:

  • Сертификат шифрования вашего сайта. Когда он истекает, сайт не начинает тормозить — он показывает посетителям прямое предупреждение о безопасности, которое не даёт им войти. Влияние на продажи мгновенное и полное.
  • Регистрация домена. Если забыть продлить домен, одновременно лягут и сайт, и почта, потому что почта работает на том же домене. Это один из худших сбоев, потому что он отрезает именно тот канал, через который вы бы стали объясняться.
  • Сертификат печати для электронных счетов-фактур. Подробные технические руководства по электронным счетам-фактурам Управления по закяту, налогам и таможне (ZATCA) предписывают налогоплательщикам продлевать идентификатор криптографической печати своих устройств, формирующих счета, до истечения срока действия текущего, причём продление включает отзыв старого идентификатора и выпуск нового. Пропустите окно — и у вас проблема с выставлением счетов, а не просто уведомление.
  • Ключи интеграции между вашими системами. Токен доступа, связывающий ваш магазин с системой учёта запасов или вашу систему с платёжным шлюзом, имеет определённый срок жизни. Его истечение не останавливает ни одну из систем, оно останавливает мост между ними: заказы продолжают поступать, а синхронизация тихо прекращается. Такой сбой обнаруживают поздно.
  • Сертификаты подписи приложений и привязанные карты. Истёкший сертификат подписи не даст вам выпустить обновление в магазин приложений, а истёкшая карта в подписке остановит сам сервис. И то и другое обычно случается в самый неподходящий момент.

Рабочее правило простое. Всему, у чего есть срок действия, нужны три вещи: напоминание за шестьдесят дней, ответственный по имени, а не отдел, и заместитель, который знает, как продлить, если ответственного нет на месте. Если нет хотя бы одного из трёх, вы снова полагаетесь на чью-то память.

Что делать в день, когда ваш провайдер лёг

Когда случается сбой, разница между компанией, которая выглядит профессионально, и компанией, которая выглядит растерянной, не в скорости ремонта — ремонт всё равно не в ваших руках. Разница в трёх вещах, которые вы подготовили заранее:

  • Канал связи вне упавшего слоя. Если вся ваша внутренняя координация живёт в одном инструменте, при его падении координации у вас нет. Достаточно резервной группы в действительно другом канале плюс списка контактов, хранящегося вне системы.
  • Объявленный ручной режим для критических операций. Как вы примете заказ, зафиксируете платёж и окажете услугу без системы? Запишите это сегодня на одной странице и передайте команде. Компании, которые пишут такую страницу, теряют часы. Компании, которые не пишут, теряют день.
  • Готовое сообщение для клиентов. Клиентов злит не столько сбой, сколько молчание. Короткое сообщение о том, что затронуто, каков обходной путь и когда будет следующее обновление, превращает сбой в управляемую ситуацию. Не обещайте время исправления, которое вы не контролируете.

Когда всё закончится, задайте один вопрос, и не больше: что мы узнали сегодня о своих зависимостях, чего не знали раньше? Ответ на него ценнее любого отчёта, и обычно это одна строка, которая заслуживает одного изменения.

Взгляд Origami

В нашей работе владельцев бизнеса больше всего удивляет редко сам сбой. Их удивляет открытие, что системы, которые они считали независимыми, упали вместе. Решение, построенное на убеждении, что у нас есть альтернативы, рушится, когда выясняется, что все альтернативы проходят через одну и ту же дверь. Поэтому любой разговор о непрерывности мы начинаем с карты зависимостей, а не с покупки инструмента, ведь купленный инструмент вполне может стоять на том же слое и повысить риск, а не снизить его.

Мы также считаем, что правильная реакция на подобный сбой — не бегство из облака. Облачная инфраструктура серьёзного провайдера надёжнее того, что большинство компаний способны построить и эксплуатировать самостоятельно, и редкий сбой этого не меняет. Правильная реакция — точно знать, какие ваши операции остановятся, а какие продолжатся, и сделать этот выбор осознанно, а не обнаружить его в неудачный день. Непрерывность — это не система, которую покупают. Это набор небольших решений, которые вы принимаете, пока ничто не заставляет вас их принимать.

Заключение

Один сбой в общем слое аутентификации остановил шесть продуктов более чем на сутки в компаниях по всему миру. Урок не в том, чтобы сменить провайдера, а в том, чтобы знать, что ваши системы на самом деле разделяют под поверхностью. Начните с таблицы из трёх колонок, которая выявит ваши зависимости, внесите каждый срок действия в один календарь с ответственным, названным по имени, и напишите страницу ручного режима до того, как она понадобится. Это примерно три часа работы, которые отделяют вас от целого дня паралича, и потому это самая дешёвая инвестиция в непрерывность из возможных.

Источники