Ночь с пятницы на понедельник: как не утонуть в крупном инциденте
Привет, %username%! https://habr.com/ru/companies/yandex/articles/992520/ — отличный разбор того, как один региональный сбой в облаке превратился в «слоёный пирог» из нескольких ошибок и усилителей проблемы, а потом — в программу системных изменений.
Главная мысль: крупные аварии почти никогда не про одну причину, это всегда стечение нескольких дыр в слоях защиты (модель «швейцарского сыра»). В их случае инцидент сложился из нескольких уровней: падение контроллера, миграции ВМ, баг в приоритизации маршрутов, отсутствие back pressure, не везде реализованный fail-safe, слабая static stability — каждый по отдельности терпим, вместе дают региональную боль.
Что они сделали дальше, что полезно утащить к себе:
- Перешли от «починим конкретный инцидент» к работе со слоями защиты: где можно добавить минимальные изменения, которые закрывают максимум дыр сразу.
- Ввели явное разделение метрик на lagging (SLA, реальная «боль» клиентов) и leading (минуты деградации, % затронутых пользователей, минуты×выручка и т.п.), построили дерево метрик и ранжировали, что реально снижает боль, а не просто красиво выглядит в архитектурной диаграмме.
- Осознали асимметрии: лучше сократить длительность и охват инцидентов (особенно >10% пользователей), чем бесконечно пытаться «никогда не падать»; восстановление системы часто важнее предотвращения всех возможных сбоев.
Из конкретных ставок, которые, на мой взгляд, стоит примерять каждому, у кого есть хоть какая-то сложная инфраструктура:
- Headless / Fail-Safe: Data Plane должен продолжать работать даже при падении Control Plane, иначе любой сбой управления превращается в трафик-апокалипсис.
- Zonal Shift: «царь‑рубильник» для зоны, чтобы быстро снять трафик с проблемной зоны и моментально уменьшить blast radius вместо многочасовых «точечных» танцев.
- Ограничение очередей и борьба с амплификаторами: рост очередей при инциденте должен жёстко резаться, иначе получаешь 2–3 часа восстановления вместо десятка минут.
- Maturity model релизов: явная шкала, где релизам присваивается уровень по возможным последствиям (от падения сервиса до незаметных внутренних деградаций) и времени до проявления эффекта — так можно уйти от вечного фриза к управляемым релизам.
- Пакет «десяток безопасных улучшений»: более требовательный incident management, безопасные ретраи, ручка остановки миграций, срезание лишних маршрутов, ускорение config plane и прочие маленькие штуки, которые суммарно дают большую прибавку к устойчивости.
И ещё один важный слой — человеческий: за ночными релизами, разруливанием инцидента и коммуникацией с клиентами стоят живые люди, и если команда выжата, то никакая архитектура не спасёт.
Мне любопытно:
- Как у тебя сейчас устроена работа со слоями защиты — вы больше про «чиним конкретный баг» или уже мыслите слоями и blast radius?
- Есть ли у тебя свой «zonal shift»/«царь‑рубильник» — что им является в твоей инфраструктуре?
- На что в твоей системе сейчас сильнее сделан упор: на предотвращение или на быстрое восстановление? Почему так сложилось?
- Пробовал ли строить дерево lagging/leading‑метрик для инцидентов или пока живёшь в мире SLA/SLO и MTTR?
Поделись в комментариях своими историями крупных аварий и тем, какие «слои сыра» внезапно совпали. Что после этого вы поменяли — архитектуру, процессы, метрики, культуру?
#DevOps #SRE #Postmortem #Incidents #Habr #BlastRadius #MaturityModel
