Залез перечитывать большие постмортемы этого года. Пока мы спорим, пускать ли AI-агента в on-call, три самых громких аутэджа года говорят совсем о другом.
Cloudflare, 20 февраля. Azure, 23 июля. Google Cloud, 20 августа. Три компании, три стека, одна причина: плановая, рутинная, «безопасная» операция, которую выполняла автоматика. Никто не катил релиз. Никто не лез в прод руками. Всё по регламенту.
1. Cloudflare: cleanup с пустым параметром
Задача чистила BYOIP-префиксы, помеченные на удаление. Параметр
pending_delete ушёл в API без значения - и сервер вернул вообще все префиксы. Система честно начала удалять их вместе с зависимыми объектами. Из BGP ушли ~1 100 из 4 306 префиксов, четверть. 6 часов 7 минут. Код отработал правильно. Просто вопрос был задан неправильно. Знакомо?2. Azure West US: blast radius посчитали не так
Рутинный break-fix на сети. Система анализа blast radius из-за дефекта расширила scope на все оптические устройства датацентра. Safety validation тоже отработала и сказала «безопасно»: она проверяла устройства по одному, а не эффект от изоляции всех сразу. Маршруты между ДЦ и WAN исчезли, около 5 часов. Алерты сработали через минуту, а вот связать аномалию с maintenance-триггером смогли только через 2,5 часа. Откат - руками.
3. Google Cloud us-west1: failover не сделал failover
Плановые работы на оптике между ДЦ. Ёмкость просела сильнее ожидаемого, automated rerouting «failed to properly redistribute traffic». Деградация трёх десятков продуктов. 2 часа 22 минуты. В remediation Google обещает «stricter safety checks and circuit redundancy requirements prior to routine maintenance». У Google. Если казалось, что только у вас так - нет.
Что общего
Uptime Institute в Annual Outage Analysis 2026: 92% считают человеческий фактор хотя бы частичной причиной последнего серьёзного сбоя, самая частая форма - failure to follow procedures (59%). 87% говорят, что аутэдж можно было избежать.
Но заметьте: во всех трёх кейсах процедуры были. И им следовали. Проблема в том, что плановые работы и «служебная» автоматика живут вне контура безопасности, который мы построили для деплоев. У релиза есть canary, progressive rollout, откат по SLO, feature flag. У «чистим префиксы» и «изолируем железку» - тикет и окно. Ну и надежда.
Что стоит проверить в любой инфраструктуре
1. Инвентаризация «не-деплоев». Cleanup-джобы, cron по удалению ресурсов, вывод нод из ротации, работы на сети и СХД, миграции DNS. Всё, что меняет прод, - это change. Даже bash по расписанию.
2. Blast radius до, а не после. Cleanup обычно удаляет 5 объектов, а собрался 25% всего? Это должно остановить задачу, а не попасть в постмортем. Cloudflare ровно это и внедряет.
3. Safety-check на совокупность, а не поштучно. Если pre-flight проверяет элементы независимо, у вас нет pre-flight.
4. Failover тестируется до maintenance. Автоматический rerouting - тоже код. Плановое окно - не время узнавать, что запасной путь не тянет.
5. Связь «что делали» и «что сломалось». Плановые работы и запуски автоматики должны быть annotation'ами на дашбордах и событиями в timeline, как деплои.
6. Ручной откат отрепетирован. Во всех трёх кейсах автоматика не откатила себя сама. Я такое гонял на Wheel of Misfortune: сценарий «плановые работы пошли не по плану» отлично ложится в формат, в моей платформе собирается за вечер. Отрезвляет, когда на словах все знают, где кнопка «стоп», а на игре её ищут пять минут.
Мы научились не бояться деплоев: сделали их частыми, маленькими и обратимыми. Плановые работы пока живут в 2015 году: редкие, большие и «там всё проверено».
Ломает прод не то, что вы считаете рискованным. А то, что перестали считать изменением.
Вопрос к вам: у ваших плановых работ и cleanup-джобов есть хоть что-то из того, что есть у деплоя? Или тоже тикет, окно и надежда?
#sre #incidentresponse #changemanagement #postmortem #wheelofmisfortune