«Диаграмма — это заявление о намерении, а не доказательство»: Microsoft объяснила, почему устойчивость утекает незаметно

Проект с датой окончания вместо свойства

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

Компания разводит половины ответственности. Azure даёт зоны доступности, вторичный регион на выбор и примитивы репликации, и они не дрейфуют; дрейфует вторая половина сделки — использует ли конкретная нагрузка эти инструменты так, как была спроектирована, после года изменений, которые никто не помечал как рискованные. По отраслевой оценке, которую приводит Microsoft, примерно 70% облачных сбоев так или иначе связаны с изменениями: не с драматическими отказами, а с обычными правками, радиус поражения которых никто не пересчитывал.

Отсюда вывод про дисциплину изменений, а не только про проектирование. Внутри Microsoft изменение сначала попадает в canary-регион, затем в пилотный, с выдержкой времени, в течение которой за сигналами здоровья наблюдают, прежде чем двигаться дальше. Эта практика, по словам компании, родилась из её собственного инцидента и совпадает с тем, что Well-Architected Framework называет безопасными практиками развёртывания.

Когда критическая зависимость — модель

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

Сатья Наделла на звонке по итогам четвёртого квартала 2026 финансового года сформулировал это коротко: «По какой бы то ни было причине, если конкретная модель исчезает, вас нельзя оставить у разбитого корыта. Вы должны иметь возможность продолжать свою работу».

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

Четыре вопроса, на которые диаграмма не отвечает

Диаграмма — это утверждение о системе, сделанное один раз человеком, который рассуждал о системе такой, какой он её представлял; она полезна, но доказательством не является. Microsoft перечисляет четыре вещи, которых она структурно сообщить не может.

Первое — достигается ли цель прямо сейчас. У диаграммы нет отметки времени, а у health modeling есть: описанное в Well-Architected Framework и доступное через health models в Azure Monitor, оно представляет приложение как иерархию компонентов и сигналов под ними, так что здоровье выражается в терминах, которые узнаёт бизнес, а не в стене метрик по ресурсам. В паре с индикаторами уровня сервиса это отвечает на единственный важный во время инцидента вопрос — выполняет ли приложение свою цель сейчас; при этом значим не собственный стандарт команды, потому что сервис здоров только тогда, когда здоровым его считает клиент.

Второе — что вообще значит «устойчив» для этого приложения: на диаграмме это прилагательное, а цель устойчивости делает его порогом, который либо выполнен, либо нет, и задавать его нужно на уровне приложения, а не ресурс за ресурсом. Третье — работает ли путь переключения: «каждая диаграмма рисует стрелку, и только тест доказывает её». Четвёртое — ресурсы, которые никто не нарисовал: диаграмма показывает то, что кто-то вспомнил, а сгенерированный Infrastructure-as-Code покрывает каждый ресурс приложения, и разница между этими двумя множествами — место, где начинается дрейф.

Как это устроено внутри самой Azure: вместо того чтобы просить каждую команду объявить, что значит «здорово» для её сервиса, компания стандартизировала индикаторы уровня сервиса, а затем применила машинное обучение к наблюдаемому поведению, чтобы «здорово» определялось тем, что сервис действительно делает, а не тем, что кто-то предполагал.

Когда зависимость вероятностна

Очевидный риск — модель, которая исчезает. Менее очевидный — модель, которая отвечает по-другому каждый раз; это более новый источник дрейфа, и ведёт он себя не как прежние. Заданный дважды один и тот же вопрос может получить два разных ответа, из-за чего корректность труднее определить, а изменения — труднее осмыслить: если меняются промпт, модель, harness и навыки вокруг неё, изменилось программное обеспечение, и оно заслуживает той же дисциплины, что любое другое изменение.

Большинство команд вместо этого делает smoke-тест: выглядит нормально — значит, выходит в релиз; пропускается именно оценка, то есть измерение системы против того, что вы действительно считаете ценным, а не против того, ответила ли она вообще. Первый вопрос, по версии Microsoft, — нужна ли системе вероятностная природа в принципе: нужно оставаться настолько детерминированным, насколько возможно, и применять AI там, где он это заслуживает, а не везде. Где недетерминированную систему можно обернуть в детерминированную проверку, это стоит сделать: если агент должен обновлять только версии зависимостей, вторая система проверяет, что изменились именно версии. Где детерминированная проверка невозможна, остаётся состязательное ревью — второй агент, вся работа которого состоит в поиске того, что не так в работе первого.

И ответственность не передаётся: когда кто-то разворачивает агента, кто-то остаётся ответственным за то, что этот агент делает. Это применимо и к самой Microsoft: её собственная система триажа инцидентов использует языковые модели, чтобы определить, какой сервис отвечает за инцидент, — работа, которая раньше означала поднятых ночью людей, спорящих над логами; это действительно быстрее, и это по-прежнему «доверяй, но проверяй».

Что это значит на практике

Диаграмма показывает три зоны, но не показывает, что health probe за балансировщиком нагрузки резолвится в одну из них. Зоны доступности защищают нагрузку от отказов уровня дата-центра внутри региона, но только если уровни вычислений, хранения и данных действительно разнесены по зонам.

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

Устойчивость — это и решение о стоимости, а не только о дизайне. Приложение, несущее 100 миллионов долларов выручки в отдельный день, оправдывает на этот день топологию active-active между регионами; остальной год то же приложение может работать в одном регионе с переключением active-passive, и правильный ответ здесь осознанный, а не максимальный. Радиус поражения Microsoft советует держать актуальным через reliability threat modeling — ту же дисциплину, что и security threat modeling, с вопросом «что будет, если этот компонент откажет и что мы будем с этим делать».

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

Carne Group: воспроизводимая устойчивость вместо запомненной

Пример из статьи — не теоретический. Carne Group, один из крупнейших независимых сторонних управляющих активами в Европе с триллионом долларов под управлением, перестроила свой контур на Azure с landing zones через Infrastructure-as-Code именно для того, чтобы устойчивость была воспроизводимой, а не запомненной. Поскольку определение живёт в коде, команда может поднять дубликат площадки в другом регионе, и, как говорит руководитель технологического направления Carne Group Стефан Беброн, «даже в худшем сценарии мы могли бы вернуться к работе примерно в тот же день».

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

Инструменты и честные границы

Инженерная половина ответа — Azure Infrastructure Resiliency Manager в public preview с опытом, построенным вокруг агентов, и тремя режимами. «Начать устойчиво»: определить, что значит устойчивость для приложения, задать явные цели и поручить Resiliency Agent генерацию Infrastructure-as-Code с учётом устойчивости заранее, чтобы новая нагрузка начинала устойчивой, а не исправлялась через месяцы; Service Groups позволяют представить приложение как логическую группу ресурсов и управлять устойчивостью на уровне приложения. «Стать устойчивым»: увидеть, где контур расходится с задуманным дизайном, найти ресурсы, которые никогда не были зонально устойчивыми или перестали быть после изменения, и расставить приоритеты; вместо сведения находок из нескольких инструментов команды получают рекомендации и сгенерированный Infrastructure-as-Code, так что исправление может пройти через pull request. «Остаться устойчивым»: проверить допущения пути восстановления раньше, чем это сделает реальный отказ, — для виртуальных машин зональный прогон имитирует потерю зоны доступности и показывает, что произойдёт с приложением, а для остальных сервисов есть проверка переключения, штатные средства восстановления и инъекция отказов через Azure Chaos Studio.

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

Итог Microsoft формулирует двумя фразами: «Диаграмма говорит вам, что вы задумали; только тест говорит, что у вас есть». И: «Если устойчивость нельзя проверить, ей нельзя доверять». Следующая часть серии будет посвящена тому, как измерять эту позицию в масштабе.