Когда авария происходит у провайдера: гибридная инфраструктура и чужое обслуживание

У Microsoft Azure произошёл инфраструктурный инцидент, затронувший гибридные сценарии, VPN и облачные VMware-сервисы. По данным The Register, проблемы возникли в ходе внутренних работ по обслуживанию на стороне самого провайдера. Деталей о масштабе и длительности в сообщении нет, и додумывать их я не буду.

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

Почему чужое обслуживание опаснее вашей пиковой нагрузки

Пик - предсказуемый враг. Вы знаете свои сезоны и отчётные периоды, можете заранее поднять ресурсы, прогнать нагрузочный тест, назначить дежурных, придержать релизы. У пика есть календарь, и этот календарь ваш.

Обслуживание у провайдера устроено иначе по трём причинам.

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

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

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

Почему гибридный стык рвётся первым

В сообщении об инциденте перечислены именно гибридные сценарии, VPN и облачные VMware-сервисы. Это не случайный набор. Это самая тонкая часть связности, и зависит она сразу от двух сторон.

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

Практический эффект такой. Обрыв туннеля ощущается не как падение сервиса, а как странности. Репликация отстаёт. Аутентификация идёт в домен, который теперь за разорванным каналом, и приложение на той стороне думает дольше обычного. Половина системы работает, половина нет, и команда тратит первые дорогие минуты на то, чтобы понять, что происходит. Если инцидент начинается с вопроса "это вообще у нас?", время уже потеряно.

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

Мониторинг слепнет ровно тогда, когда он нужен

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

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

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

Что с этим делать

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

2. Мониторьте гибридный стык как отдельный объект. Состояние туннелей, задержка и потери между площадками, отставание репликации, время ответа аутентификации. Эти метрики ломаются раньше бизнес-метрик и дают запас времени.

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

4. Проверьте, что перенос действительно выполним. План переноса критичной нагрузки в другой регион или в другую среду стоит ровно столько, сколько стоит его последняя проверка. Нужны учения с секундомером, на реальных данных, с реальным переключением. Как к этому подступиться: план выхода из облака.

5. Подпишитесь на статус-страницы и уведомления провайдера заранее. Звучит банально, но в момент аварии разница между "мы два часа ищем причину у себя" и "мы увидели уведомление поставщика за пять минут" измеряется в деньгах. Заодно договоритесь внутри, кто именно смотрит эти каналы в первые минуты.

6. Опишите протокол на случай аварии у поставщика. Кто объявляет инцидент, кто и что говорит клиентам, когда включаем деградированный режим. Вывод о внешней причине должен делаться по регламенту, а не по наитию дежурного.

7. Отрепетируйте возврат, а не только отказ. Как сводим расхождения после восстановления связи, что делаем с повторно обработанными задачами, в каком порядке поднимаем системы. Эта часть почти всегда остаётся непроверенной и почти всегда оказывается самой долгой.

Честные оговорки

• Мультирегион и мультиоблако стоят денег и добавляют сложности. Растут счета и стоимость эксплуатации, появляются собственные отказы на уровне репликации и переключения. Бывает, что архитектура, построенная ради выживания в редкой аварии, ломается чаще самой аварии.

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

• Независимость точки наблюдения относительна. Второй поставщик мониторинга может сидеть в той же магистрали или у того же регистратора. Полной независимости не существует, но и частичная радикально лучше наблюдения изнутри аварии.

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

• Отказ провайдера не снимает с вас ответственности перед клиентом. Клиент видит ваш сервис. Фраза "авария у поставщика" объясняет причину и не отменяет обязательств. Кто принимает решения в такой момент, разбирал здесь: первые 30 минут инцидента.

Если коротко

• Инцидент в Azure, по данным The Register, связан с внутренними работами по обслуживанию и задел гибридные сценарии, VPN и облачные VMware-сервисы.
• Чужое обслуживание опаснее вашего пика: вы не знаете времени, не можете его отложить и не управляете откатом.
• Гибридный стык рвётся первым, потому что состояние в нём держат обе стороны сразу, а восстановление связи оставляет системы в рассинхроне.
• Мониторинг, живущий в том же облаке, показывает зелёное именно тогда, когда нужен. Внешняя точка наблюдения и отдельный канал оповещения закрывают дыру дёшево.
• Устойчивость к отказу региона платная. Какие нагрузки её заслуживают, решает бизнес, и проверяется это решение учениями, а не документом.

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