ST24 — статус, мониторинг и SRE-практики 24/7

Мониторинг без шума: как выбрать SLI и настроить алерты, чтобы не выгорать

Надёжность начинается не с модных инструментов, а с договорённостей о том, что именно мы считаем «работает» и «не работает» для пользователя. Правильный набор SLI (показателей уровня сервиса) отвечает на вопрос «что ощущает клиент», а не «что удобно мерить». Для API это доля успешных запросов и время ответа по квантилям, для фронтенда — Web Vitals в реальном мире (и в условиях мобильных сетей), для оплаты — доля авторизаций без повторной попытки, для поиска — время до первого результата и релевантность. SLO — целевые значения, которые честно отражают сезонность и пиковые нагрузки, а не «99.999% потому что красиво». Error budget защищает команду от перфекционизма: он говорит, сколько «ошибок» мы можем «потратить» на релизы и рискованные изменения. Мониторинг строится на слоях: синтетика (пинг, http-проверки, сценарии входа/покупки), «чёрный ящик» (золотые сигналы — трафик, задержки, ошибки, насыщение), «белый ящик» (метрики внутренних очередей, пулы соединений, GC, лаг репликации), плюс логи и трассировки для ответа на «почему». Важная оговорка: мы измеряем из нескольких точек мира и из браузеров/устройств пользователей, иначе можно неделю «лечить» свой кластер, когда проблема — у провайдера DNS. Алерты должны приходить только тогда, когда нарушен SLO или происходит событие, требующее немедленного действия. Всё остальное — дашборды и отчёты. Паттерн «двух порогов» спасает от флип-флопа: предупреждение для тренда, критический сигнал — для срочной реакции. Инцидент начинается там, где страдает пользователь: строим плейбуки с явными треками — деградация/частичный отказ/полный отказ, и заранее решаем, что именно мы отключаем, чтобы «сохранить ядро» (ограничение фич, выключение тяжёлых отчётов, статическая страница вместо персональных рекомендаций). Качество алертов — это не «раз и навсегда»: каждую неделю проводим ревизию «ложных/шумных», объединяем сигналы в корреляции, добавляем подавление дублей и проверки «тихих» окон на релизы. Чем меньше письма напоминают загадки, тем быстрее on-call спит ночами. Правильный мониторинг — это не «всё мерять», а «мерять, что влияет на пользователя».

Реакция на инцидент — это хореография ролей, темпов и коммуникации. В первые 15 минут цели просты: безопасно стабилизировать сервис, восстановить путь пользователя и зафиксировать текущее понимание. Командир инцидента берёт на себя принятие решений и экономит когнитивные ресурсы инженеров; коммуникационный офицер ведёт внешние/внутренние апдейты в статус-канале и на статус-странице; субъект-материаловеда собирает факты: когда началось, какие метрики порвались, какие изменения были вблизи. Технические действия — минимально инвазивные: откат на предыдущую версию, выключение проблемного флага, понижение QPS, включение защитных механизмов (rate limiting, circuit breaker, timeouts), переход на read-only, изоляция «шумящих» клиентов. Если проблема — в инфраструктуре, важно иметь заранее оттестированные плановики: переключение на реплику, расщепление трафика, резервные DNS, увеличение пулов коннектов, разброс по AZ/Region. В параллели идут замеры: мы подтверждаем гипотезы метрикой, логом и трассировкой, а не «ощущением». Коммуникация — не второстепенна: регулярные апдейты снижают поток вопросов и давление на команду. Каждый шаг должен быть обратим: если попытка не помогает — откатываем за минуту, не «тянем» час. Инструменты ускорения — фичефлаги (чтобы не ждать деплоя), безопасные миграции (двухступенчатые изменения схем), тени-запросы, канарейка, нагрузочное тестирование профилей. На уровне архитектуры выигрывают системы, где отказ — не катастрофа: очереди с DLQ, идемпотентные операции, слои кэширования, резервные провайдеры, деградации «к простому». Когда инцидент закрыт, мы фиксируем «окно наблюдения» и метрики нормализации — это защищает от «ложного финиша». Хорошая реакция — это не героизм и не «ночные подвиги», а повторяемость: любой инженер по плейбуку способен сделать первые шаги без «сеньора рядом».

После инцидента начинается работа, которая делает следующий проще. Бесстыдные (blameless) постмортемы — не про поиск виноватых, а про улучшение системы: что мы не увидели, какое предположение оказалось неверным, где сигнал не превратился в действие. Мы отделяем «первопричину» (обычно это организационный/процессный зазор) от «триггера» (конкретное событие) и описываем фактическую линию времени с артефактами — графики, логи, коммиты, скриншоты статус-страницы. Из постмортема рождаются задачи с приоритетом и сроком: автоматизация рутины, алерты по SLO, перепаковка дашбордов, переписывание опасных участков, тест-контуры и хаос-инженерия в безопасных окнах. Экономика надёжности тоже важна: не все SLO стоят одинаковых денег. Error budget помогает бесстрастно торговаться между фичами и стабильностью: когда бюджет «съеден», релизы — только с явным решением и планом возврата. ФинОпс связывает инфраструктурные решения с счётом: кэш ближе к пользователю снижает не только латентность, но и расход трафика; правильные лимиты и пулы — экономят CPU; отключённые «вечные» логи — бюджет. На уровне разработчика правила просты и мощны: таймауты везде, где есть сеть; повторы с джиттером, а не «в лоб»; идемпотентность платёжных и критичных операций; измеримость (labels, trace-id); конфиги, которые меняются без ребута; «перекладывание» тяжёлых задач в очереди. Культура — это ритуалы: еженедельные «саны-чек» алертов, ревизия фичефлагов, учёт «технического долга надёжности», тренировки on-call с имитацией отказов и документированные «выходы из тонеля» (если всё плохо, что мы выключаем первым). В сумме это делает систему предсказуемой: инциденты не исчезнут, но перестают быть драмой. ST24 — про то, как шаг за шагом построить поведение и инструменты, которые берегут пользователей, бизнес и сон команды.