Ночь с пятницы на понедельник: как не утонуть в крупном инциденте Привет, %username%! Статья от Яндекса — отличный разбор того, как один региональный сбой в облаке превратился в «слоёный пирог» из нескольких ошибок и усилителей проблемы, а потом — в программу системных изменений. Главная мысль: крупные аварии почти никогда не про одну причину, это всегда стечение нескольких дыр в слоях защиты (модель «швейцарского сыра»). В их случае инцидент сложился из нескольких уровней: падение контроллера, миграции ВМ, баг в приоритизации маршрутов, отсутствие 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