25 января 2023 года глобальная сеть Azure WAN фактически легла на 1 час 40 минут, а следом подтянулись и длинные хвосты восстановления в West India и Северной Америке. Для тех, кто занимается эксплуатацией, платформой и SRE, это не просто история про большой сбой Microsoft, а показательный разбор инцидентов: самая удобная версия почти всегда оказывается самой бесполезной.
Об этом на QCon San Francisco рассказал Шон Кляйн, Principal Technical Program Manager в Microsoft Azure, сообщает InfoQ. Кляйн занимается постинцидентным анализом почти два десятилетия и формулирует тезис без дипломатии: миф о «человеческой ошибке» опасен не потому, что люди не ошибаются, а потому, что такая формулировка слишком быстро закрывает разговор. Всем становится психологически легче: нашли виноватого, назначили обязательный тренинг, поставили галочку. Система при этом остаётся примерно такой же хрупкой, как была.
Сам сбой Кляйн описывает довольно предметно. По его словам, 25 января 2023 года инженер выполнил команду на паре маршрутизаторов, которые считались непроизводственными и не обслуживали клиентский трафик. Проблема в том, что речь шла о новой роли в сети Azure WAN, созданной в рамках расширения глобальной магистрали. Эти роутеры сначала получили внешнюю адресацию, затем архитектуру скорректировали, и их пришлось переадресовать под внутреннюю схему в составе software-defined WAN. Для такой операции нужен был отдельный SOP, но документ создавался и менялся вне обычного контура контроля: без peer review, без CAB, без тестирования в эмуляции, хотя у Microsoft, по словам Кляйна, виртуализована вся WAN и изменения можно прогонять в Azure VMs до продакшена.
Дальше началась классика больших аварий, где каждая мелочь по отдельности вроде бы не тянет на катастрофу, а вместе вполне. Во время предыдущих работ возникла проблема со stale link-state packets, вендор дал рекомендацию добавить в SOP новую команду, и её добавили мимо нормальной процедуры согласования. Инженер, который выполнял изменение 25 января, следовал официальному документу и считал команду безопасной. Его ментальная модель была логичной: в сети Microsoft используются маршрутизаторы трёх производителей, на двух операционных системах эта команда локальна и не должна бить по глобальной связности. На третьей она влияет на adjacency, то есть имеет фактически глобальный радиус поражения. Дополнительно инженер ожидал, что опасные команды будут заблокированы на уровне AAA, но аудит новой роли ещё не успели закончить. В итоге он запустил команду один раз, а через 33 минуты повторил её на втором роутере пары, потому что SOP не предполагал стандартного «периода тишины» с наблюдением за ключевыми метриками: изменение ведь не считалось производственным.
Последствия оказались вполне производственными. Сначала вся Microsoft WAN ушла в пересчёт внутренней связности через IGP примерно на полчаса, потом сеть частично стабилизировалась, а затем повторный запуск добил ситуацию и спровоцировал пересчёт BGP. Из-за масштаба Azure WAN это означало пересборку примерно 15 миллионов маршрутов, на что ушло около часа и 45 минут. Во время reconvergence отказали три устройства, а системы автодетекта, автоперемаршрутизации и авторекавери пришлось временно остановить, потому что в тот момент они не помогали, а добавляли хаоса. После возврата магистрали к жизни в нескольких регионах трафик не восстанавливался до тех пор, пока деградировавшие устройства не нашли и не вывели вручную.
Именно здесь, по версии Кляйна, обычно рождается вредный корпоративный фольклор: «инженер выполнил неправильную команду и уронил мир». Формально придраться трудно. Практической пользы почти ноль. Такой разбор инцидентов плохо работает, потому что чинит не причины, а чьи-то нервы. Можно уволить человека, заставить команду лишний раз пройти обучение и даже написать грозное письмо про дисциплину изменений. Но от этого не исчезнут SOP без нормального governance, различия между поведением команд на разных ОС, незавершённый AAA-аудит, ложный статус “non-production”, отсутствие обязательного listening period и архитектурная чувствительность WAN к такой последовательности событий. Кляйн специально иронизирует над «one why analysis»: красиво, быстро, удобно для слайдов, но слишком примитивно для сложной системы.
Для инженерных руководителей тут есть неприятный, но полезный вывод. Если система позволяет одной команде из официального SOP запустить действие с глобальным эффектом, то проблема не в том, что человек оказался недостаточно героическим или недостаточно осторожным. Проблема в том, что инфраструктура и процессы не защищали исполнителя от ошибки модели. Сам Кляйн формулирует это жёстко: если инженер одной командой «выключил мир», значит, система подвела инженера. Поэтому полезные исправления лежат не только рядом с местом аварии, где можно ослабить зависимость BGP от IGP-пересчёта, но и глубже: в управлении изменениями для supposedly non-production работ, в проверке командных ограничений, в устройстве runbooks и в обучении, которое объясняет не абстрактную «осторожность», а реальные механизмы сложного отказа.
Microsoft после аварии, по словам Кляйна, не свела всё к очередному обязательному курсу. Этот инцидент теперь изучают в онбординге WAN-команды и core networking. Ход понятный: не читать людям мораль, а показывать, как нормальные решения в локальном контексте складываются в глобальный сбой. Для русскоязычного рынка это особенно узнаваемо. Во многих компаниях до сих пор любят разбор инцидентов в жанре «кто нажал не туда», потому что так быстрее готовить отчёт наверх. Но чем сложнее платформа, тем дороже такая экономия. В момент следующей аварии организация снова узнает, что “root cause: human error” отлично смотрится в документе и очень слабо помогает в продакшене.
Открытый вопрос здесь не про Microsoft, а про зрелость отрасли. Технологические компании давно повторяют мантру о blameless postmortem, но даже в крупных командах, как признаёт Кляйн, с этим знакомы далеко не все. Пока бизнесу важнее немедленно назвать виноватого, чем месяц разбираться в системных связях, большие распределённые системы будут регулярно наказывать за упрощение. Перепроверить детали выступления можно в транскрипте .