5 антипаттернов алертов

На новом месте работы я заметил, что алерты сливаются в общий чат и это жутко неудобно. Первое же, что я сделал - отключил уведомления :) Значит, что-то явно не так.
Решил собрать антипаттерны и рассказать об этом.

Алертов много, а пользы мало - значит, в системе есть вот это:

1. Алертит всё подряд
Проблема: Люди настраивают алерт на каждый возможный сценарий. Результат: 2000+ алертов в неделю, но только 3% требуют действия.
Лучшая практика: Google SRE рекомендуют 4 Golden Signals:
• Latency - как быстро отвечает система
• Traffic - сколько запросов приходит
• Errors - сколько ошибок
• Saturation - как насыщена система (CPU, память, диск)
Этого хватает на 80% проблем. Остальное - noise.
Действие: Перепроверьте все алерты. Если алерт не про эти 4 сигнала - удалите или переделайте.

2. Нет severity
Проблема: Все алерты одинаковые. Получаешь 50 нотификаций в час и не знаешь, что критично, а что нет.
Лучшая практика: Четыре уровня:
DISASTER - Сервис упал, есть реальные users affected
→ ЗВОНОК СЕЙЧАС, пока разговариваешь
CRITICAL - Сервис работает, но деградация
→ Разбери сегодня, но можно за час
HIGH - Тренд плохой, может стать проблемой
→ Разбери завтра, добавь в спринт
WARNING - Отслеживаем, но пока OK
→ Смотри в дашборд, не звони
Результат в VK: 98% Critical алертов получают реакцию в первые минуты.

3. Нет runbook
Проблема: Alert сработал в 3 часа ночи. On-call инженер смотрит на название алерта и не понимает, что делать. Результат: 1–2 часа на поиск информации или escalation разработчикам.
Лучшая практика: Каждый Disaster/Critical алерт ДОЛЖЕН иметь runbook.
Что включить в runbook:
• Что произошло - что именно означает этот алерт (на человеческом языке, не техно-жаргон)
• Что проверить - какие логи смотреть, какие метрики
• Как чинить - пошаговые шаги для on-call инженера
• Время - runbook должен решаться за 10 минут без escalation
Правило: Если алерт не решается за 10 минут и в нём нет инструкции - это не алерт, это шум.
LinkedIn пример: On-call получал 50 страниц в неделю из-за плохо структурированных runbook. После переделки - спит по ночам.

4. Нет владельца
Проблема: Алерт срабатывает, но никто не знает, кто за него отвечает. Ticket гуляет по сотрудникам. Никто не знает, чинить ли это или это "expected behavior".
"Алерт без ответственного - это не алерт."
Лучшая практика: Каждый алерт должен иметь владельца (может быть team).
Владелец отвечает за:
• Обновление runbook, когда меняется сервис
• Мониторинг False Positive rate этого алерта
• Удаление/переделку, если алерт не помогает
Мотивация простая: если алерт плохой - его будут будить ночью.

5. Нет SLO
Проблема: Алерты на static thresholds:
• "CPU > 90%" - alert
• "Memory > 85%" - alert
• "Latency > 500ms" - alert
Но 95% времени эти метрики выше threshold, и ничего не ломается. Результат: игнор.
Лучшая практика: Переходи на SLO-based alerting (error budgets + multi-burn-rate).
Что такое SLO-based alerting:
Вместо: "CPU > 90%"
На: "Как быстро горит ваш error budget?"
Примеры:
• SLO: 99,9% uptime (error budget: 43 минуты в месяц)
• Если за день потратили 20 минут budget - спокойно, впереди ещё 23
• Если за день потратили 40 минут - WARNING, тренд плохой
• Если за час потратили 10 минут - CRITICAL, горит со скоростью 240 минут в день!
Multi-burn-rate alerts:
• 14.4x burn rate (будет истощен через 2 дня) = PAGE NOW
• 6x burn rate (будет истощен через 5 дней) = CREATE TICKET
• 3x burn rate (будет истощен через 10 дней) = MONITOR
• 1x burn rate (планируется) = смотри дашборд, не алертим
Результат: SLO-driven approach может снизить alert noise на 80%, но catch real issues ЛУЧШЕ, потому что alert срабатывает только когда реально горит.

#sre #observability #alerts #slo #sla #sli

ПОЧЕМУ ЭТО ВАЖНО
73% outage происходят из-за ПРОИГНОРИРОВАННЫХ алертов.
Это не значит, что систему нужно мониторить лучше. Это значит, что мониторим, но дежурный видит 300 алертов и игнорит все.
Масштаб проблемы:
• Команды получают 2000+ алертов в неделю, но только 3% требуют действия
• 67% алертов игнорируются ежедневно
• 85% - это ложные срабатывания
• Cost: $5,600/минута downtime для enterprise
Парадокс Alert Fatigue:
• Нужно видеть ВСЕ проблемы
• Но когда их слишком много - пропускаешь РЕАЛЬНЫЕ проблемы
• Нужно найти баланс через правильную настройку

ПРАВИЛЬНЫЙ ПОДХОД
Метрика качества алертов: Signal-to-Noise Ratio

Signal-to-noise = (actionable alerts) / (total alerts)

• Здоровая система: 30–50% actionable
• Проблемная система: <10% actionable
Если видишь, что <10% алертов требуют действия - бери это в приоритет, переделывай систему.

Вывод: Лучше 3 полезных алерта, чем 300 шумных. А ещё лучше - алерт, который можно реально починить за 10 минут.

#sre #observability #alerts #slo #sla #sli

ЭТОТ ШАБЛОН ПОСТМОРТЕМА РЕШИЛ ВСЕ МОИ ПРОБЛЕМЫ

А теперь, когда я вас забайтил, поговорим серьезно.
Постмортем хорош не тогда, когда он «идеально оформлен», а когда он существует и уже помогает принимать решения и предотвращать повторы.

Постмортемы часто откладывают, потому что «нет времени нормально написать». Но правда в том, что самый полезный постмортем - это тот, который вы сделали хоть как-то, и уже можете из него вытащить пользу: действия, владельцев, изменения.

Минимальный бар “полезно”

Если у вас есть только это - уже ок:
Impact: что сломалось и кому/чему стало больно (1–2 предложения).
Timeline: 5–10 ключевых событий (по минутам/часам).
Root cause / contributing factors: что реально привело к эффекту (не “у нас всё плохо”, а конкретика).
Action items: 1–5 пунктов, которые уменьшают вероятность/влияние повтора.

В Google SRE прямо подсвечивают, что постмортем без конкретных action items - неэффективен, а action items без понятных владельцев часто не закрываются. Ещё один типичный антипаттерн - “слишком много владельцев у постмортема”: лучше один владелец как single point of contact и несколько коллабораторов.
​
“Мы думали, проблема в одном…”

Очень частый сценарий: начали разбирать инцидент, и внезапно выяснилось, что «корень» вообще в другом месте, а по пути всплывает куча неочевидных зависимостей/подводных камней.

Это нормально - и это как раз ценность постмортема: он вытаскивает факты наружу и превращает “кажется, у нас X” в “на самом деле, у нас Y + 3 contributing factors + план, что с этим делать”.

Пример из мира реального.

У GitHub в пост-инцидент анализе есть показательная деталь: краткая потеря связности на 43 секунды запустила цепочку событий, которая привела к деградации сервиса на 24 часа и 11 минут. При этом они отдельно фиксируют последствия (например, показ устаревших/несогласованных данных) и описывают ход восстановления как последовательность фаз, а не «всё починили».
​
Практическое правило

Сделайте “черновой” постмортем в течение 10-12 часов (с момента окончания инцидента), даже если половина пунктов пока “TBD”. Но action items - только такие, у которых есть владелец и проверяемый финальный результат (это тоже прямо рекомендуют как признак хороших action items).



Текст специально обезличенного постмортема из Додо можно почитать тут или тут.
Я все еще считаю, что это один из лучших вариантов "шаблона" постмортема что я встречал когда либо.

​Вопрос к вам: что чаще мешает сделать постмортем “хоть как-то” - отсутствие шаблона, нехватка времени, или ощущение, что «всё равно ничего не поменяется»?

#sre #postmortem

SLO-based alerting: как сделать не хуже, чем было

В прошлом посте про алерты я сказал про SLO-based alerting. Время раскрыть что это такое и как с этим жить.
Когда люди «внедряют SLO», часто всё заканчивается тем, что к старым алертам просто добавляют ещё пару дашбордов и одну-две новых нотификации. В итоге шум остался, SLO «есть», но на них никто не смотрит.

Антипаттерны SLO-алертинга

SLO как ещё один threshold на метрику
«Если за 10 минут ошибок ≥ порога - шлём алерт». Формально это SLO, по факту - тот же метрик-алерт, только сложнее. Любой всплеск = пейджер, даже если по error budget мы вообще не страдаем.

Оповещаем «по симптомам», а не по SLO
Алерты идут по CPU, памяти, очередям, отдельным эндпоинтам - но не по тому, что реально описано в SLO. В итоге on-call живёт в мире инфраструктуры, а не пользовательского опыта.

Один burn rate на все случаи жизни
Одна граница «если burn rate > X - буди» не различает: «горит всё, срочно просыпайся» и «медленно проедаем бюджет, можно спокойно посмотреть завтра».

SLO-алерты дублируют старые
Вместо того чтобы выключать/переформулировать старые, поверх них навешивают новые. Команда злится на SLO, а не на то, что их не связали с процессами.

Паттерны, которые работают лучше

Многооконный burn rate (multi-window, multi-burn)
Идея из Google SRE:
- короткое «быстро горим» окно (минуты–часы) → пейджер;
- длинное «медленно утекаем» окно (сутки–недели) → тикет/задача.
Так SLO-алерты и про пожар, и про «мы системно ухудшаемся».

Пейджим только по угрозе error budget
Не по каждому 5xx, а когда текущее поведение реально угрожает выбить нас из SLO за период. Всё остальное - в тикеты, отчёты, дашборды, но не к on-call ночью.

SLO → правила игры, а не просто график
Есть SLO → есть политика: что делаем, если бюджет выжгли (freeze релизов, приоритет на фиксы, ограничения экспериментов). Иначе алерт «SLO нарушен» - просто ещё один красный прямоугольник.

Генерация правил, а не ручной зоопарк
Инструменты вроде Sloth помогают: описал SLO в YAML → получил Prometheus recording rules, burn-rate алерты и дашборды. Не нужно каждый раз изобретать запросы. Ребята из коммунити ALLSLO на этом месте вообще запилили свой форк под свои требования - и это нормальный путь, когда SLO становятся частью платформы, а не «ручной магией». Аналогично сделали ВсеИнструменты в лице Димы @r3code - их форк. А Кир @silabeer в ВК сделал свой инструмент.

Постепенное внедрение, а не «SLO везде»
1) Берём 1-2 критичных сервиса.
2) Для каждого - один SLO (например, 99.9% успешных запросов за 30 дней).
3) Описываем его в Sloth (или аналогичный инструмент), настраиваем multi-window burn rate, выводим на дашборд.
4) Проживаем пару инцидентов, учимся принимать решения по бюджету.
5) Только потом разматываем это на остальные сервисы.


В итоге «SLO-based alerting» - это не про ещё один вид алертов, а про смену логики: мы пейджим только тогда, когда страдают пользователи и реальный error budget, и делаем это по понятным правилам. Всё остальное - фон.

Slow is the new down: 5 антипаттернов, из-за которых вы не видите деградацию

«Система работает» - любимая фраза дежурного инженера в 3 часа ночи. Uptime 99.9%, алертов нет. Но пользователи уже пишут в поддержку, что «всё тормозит».

Я специально разбираю именно антипаттерны, а не best practices. Списки в духе «сделайте SLO, внедрите трейсинг, настройте synthetic monitoring» все уже читали. Но реальные проблемы обычно прячутся не в незнании, а в привычках: что именно вы смотрите, на что алертите и что считаете «нормальной работой».

И так, начнем!

1. Алерты только на error rate, но не на latency
Классика жанра: p99 улетел в 10 секунд, ошибок ноль, Grafana молчит. Формально система «жива», фактически для пользователя она уже сломана.
Эта логика не новая: Amazon ещё много лет назад показывал, что каждые дополнительные 100 ms задержки снижали продажи примерно на 1%.
Если у вас есть SLO только на availability, но нет SLO или хотя бы алертов на tail latency (p95/p99), у вас есть мониторинг аварий, но не мониторинг производительности.

2. Смотрите на average, а не на percentiles
Средняя latency почти всегда успокаивает сильнее, чем должна.
Если 90% запросов отвечают за 100 ms, а 10% висят по 5 s, среднее может выглядеть ещё «приемлемо». Но именно в этих хвостах и живёт реальная пользовательская боль.
Поэтому смотреть нужно не только на average, а на p95 и p99. Именно они показывают, как система ведёт себя для тех, кому сейчас хуже всего.

3. Нет baseline - нет и деградации
Если вы не знаете, как выглядела нормальная работа неделю назад, то любое замедление легко объясняется фразой «ну вроде так и было».
Так деградация и живёт неделями после деплоя, пока не придёт жалоба от крупного клиента.
Полезно сравнивать метрики не только с фиксированным порогом, но и с той же точкой неделю назад в то же время: это помогает увидеть постепенное ухудшение на фоне сезонности и дневных паттернов.

4. Мониторите сервис, но не зависимости и не пользовательский путь
Ваш API может отвечать за 200 ms, но внутри ждать базу, кеш, DNS, внешний API или сеть между ними. На дашборде сервис зелёный, а пользовательский сценарий уже «разваливается».
Официальная документация OpenTelemetry хорошо формулирует, зачем здесь нужен tracing: trace показывает путь одного запроса через несколько сервисов и помогает понять, где именно ушло время.
Без трейсинга зависимости часто остаются чёрным ящиком. А без synthetic checks или RUM на критические user journeys вы меряете систему изнутри, а не то, что реально видит пользователь.

5. Нагрузочное тестирование только перед релизом
Если вы проверяете производительность только перед большим релизом, то узнаёте о деградации слишком поздно.
Медленные регрессии чаще приходят не как «всё упало», а как накопительный эффект: изменился план запроса, убрали индекс, вырос объём данных, поменялась библиотека, усилилась конкуренция за CPU.
Поэтому зрелая практика сегодня - не только разовые load tests, но и регулярные synthetic latency checks, плюс continuous profiling (Pyroscope, Parca), чтобы ловить деградацию до того, как о ней напишет клиент.

SRE Report 2026 фиксирует важную вещь: почти две трети респондентов уже считают деградацию производительности настолько же серьёзной, как и даунтайм. Но только 26% организаций действительно проверяют, как улучшение производительности влияет на бизнес-метрики вроде revenue или NPS.

То есть проблема уже признана. Но измерять её по-настоящему умеют пока немногие.

Медленная система - это инцидент без пейджера.
Что из этого у вас до сих пор не настроено?

#sre #observability #performance #latency #opentelemetry

Привет, я Макс Гусев - SRE Team Lead в RWB.

В IT больше 11 лет: прошёл путь от простого инженера до TechLead SRE в финтехе и Lead Observability SRE Team в Dodo Engineering. Сейчас в RWB выстраиваю SRE-процессы, строю отказоустойчивые системы и разбираюсь, как не тонуть в тойле и как выглядит нормальный инцидент-менеджмент. На конференциях рассказываю про внедрение SRE и зачем это бизнесу и разработчикам.

Этот канал - заметки по SRE и observability: алерты, SLO, инциденты, метрики, инструменты - из практики, не из учебника. Иногда - автоматизация, хоумлаб и короткий оффтоп.

С чего начать читать
• Пять антипаттернов алертов
• SLO-based alerting: как не сделать хуже
• «Медленно» = «лежит»: антипаттерны деградации
• Минимальный полезный постмортем + примеры

Если материал зашёл - перешлите коллегам, буду благодарен.

Вопросы по темам постов - в комментариях к посту или в личку.

Wheel of Misfortune: зачем это SRE и как из него извлекать пользу

Что это?
Wheel of Misfortune (иногда встречается и название вроде «Walk the Plank») - это ролевая игра про инцидент: ведущий (Game Master) задаёт сценарий - вымышленный или основанный на прошлом сбое (что приоритетнее), а «дежурный» по очереди рассказывает, что именно сделал бы: какие алерты смотрит, какие запросы к метрикам и логам, кого пингует, как эскалирует. Остальная команда наблюдает и подключается к разбору. В материалах Google SRE это описано как регулярная практика, близкая к настольной RPG: вы в «лабиринте одинаковых консолей мониторинга», цель - отработать мышление и протокол до реального пейджа (ускорение выхода на дежурство).

Чем полезно именно SRE.
Инцидент - это не только root cause, но и управление вниманием, временем, коммуникацией и эскалацией при неполной картине. WoM даёт низкий риск для прода: можно намеренно тренировать редкие сценарии и процедуры (в том числе кто командир инцидента, как объявлять major и вести коммуникации). Это симуляция, а не реальное отключение: обучение через «низкие ставки» (Google Cloud: DiRT и Wheel of Misfortune). Рядом по смыслу - координированные учения вроде DiRT, но там другой масштаб подготовки и другой профиль риска.

Как из песочницы сделать пользу - практика.
1. Сценарии из жизни. Опирайтесь на постмортемы, странные прод-кейсы и гипотезы про будущий релиз. Если нужен зерновой набор тем, посмотрите публичное обсуждение сценариев в инфраструктурных командах - например, идеи в духе failover кластера, потери ноды, жёсткой деградации и отката деплоя (issue GitLab): не готовый сценарий, а ориентир, что описывать в своих .md или JSON.
2. Дебриф с артефактом. После сессии зафиксируйте: где споткнулись о runbook или дашборд, один конкретный шаг - обновить алерт, ссылку в playbook или порог. Без этого легко уехать в «поиграли и забыли».
3. Качество ведущего. GM выдаёт последовательно то, что запросил игрок (вид графиков, вывод команд, фрагменты логов), без преждевременного «значит вот что»: как в жизни, сигнал приходит сырой (тот же материал Google Cloud).
4. Ротация и чужие углы. Меняйте дежурного на «сцене», GM и зрителей; после хода игрока собирайте альтернативные пути отладки - так смешиваются стили мышления и знания не копятся у одного человека.
5. Связка с коммуникациями. В реальном учении команды вроде GOV.UK PaaS показывают, как к техническому расследованию добавить роль коммуникаций: сцена с пейджером и smoke tests, шаблон вопросов вроде «что сделаете первым?», «что ожидаете увидеть?», отдельно - ответственные за тексты для пользователей. Это хороший образец, если хотите тренировать не только grep по логам (запись в блоге UK government technology).

Дополнительный угол.
В Open Practice Library формулируют ещё одну пользу: при грамотной подводке игра помогает проверить гипотезы о том, как ведут себя мониторинг и алертинг - не вместо реальных проверок инфраструктуры, но как разговор «ожидание vs реальность» в команде.

Инструменты и примеры контента.
Классический open-source проект - dastergon/wheel-of-misfortune: сценарии в general_incidents.json, есть sample-файл, поддержка Ink для ветвящихся интерактивных историй; демо и инструкции можно отдать команде без установки. Есть форки: у twstewart42 - например, тёмная тема и выбор «дежурного»; автор описывает ежемесячный слот, порядка двух инцидентов за час и мок blameless postmortem после сессии (пост в блоге). У alphagov/paas-unlucky-dip - вариант с бэкендом для списков сценариев, если сценарии часто меняются. Идеи формулировок «что ломаем» в учениях (в духе утёкших ключей, компрометации аккаунта) можно подсмотреть в смежных drill-гайдах - например, раздел 18F про incident response drills: это не бренд WoM, но полезный каталог заготовок для своих текстов.

Wheel of Misfortune - дешёвый по риску тренажёр инцидентного мышления, процедур и ролей. Выгода измеряется не «мы провели игру», а обновлёнными runbook’ами, более предсказуемой эскалацией и тем, что на реальном пейдже меньше трения и сюрпризов.

#SRE #WheelOfMisfortune #incident_response #oncall

5 антипаттернов on-call дежурств, которые сжигают команду

На новом месте я сразу полез смотреть как устроен on-call. И увидел знакомую картину: алертов много, реальных инцидентов мало (если сравнивать с ложными), дежурят одни и те же люди, runbook'ов нет - или они не актуальные, или пустые. Классика, я уже даже не удивляюсь. Базовая ситуация, когда SRE не было и практики не применялись.

Но пришло время всё исправлять.

Тема горячая: Catchpoint SRE Report 2026 показывает - 70% SRE называют on-call стресс прямой причиной выгорания, тойл вырос до 34% рабочего времени. PagerDuty фиксирует: из ~50 алертов в неделю на инженера только 2-5% требуют действия.

1. Все алерты - P1
Нет severity → каждый алерт будит ночью → через неделю мозг отключается. 44% организаций получили аутедж из-за проигнорированных алертов, 67% инженеров признаются, что dismissают без разбора.
Решение: DISASTER → CRITICAL → HIGH → WARNING. Если всё P1 - значит ничего не P1.

2. Один герой на линии
Один человек дежурит неделями, потому что «знает систему лучше всех». Google SRE рекомендует: макс. 2 инцидента за смену, минимум 50% времени - на проектную работу, не на тушение пожаров.
Решение: primary + secondary, ротация раз в неделю. Wheel of Misfortune - чтобы дежурить мог каждый, а не только «тот самый Андрей».

3. Runbook? Какой runbook?
Алерт в 3 ночи, on-call не понимает что делать. 40 минут на пинги в Mattermost и эскалацию. incident.io подтверждает: без runbook время разрешения x3-4.
Решение: нет runbook = нет алерта. Внутри: что случилось, что проверить, как чинить, когда эскалировать. Цель - 10 минут без эскалации.

4. Дежурство без компенсации
Инженер не спит ночами. Компенсация: спасибо в Mattermost ноль. Google прямо говорит: out-of-hours работа должна компенсироваться - отгулами или деньгами, с капом на кол-во смен.

5. Нет follow-up после инцидента
Починили → забыли → через неделю тот же алерт в 3 ночи. Runframe: тойл вырос до 30%, при этом 16% говорят что AI только добавил работы. Машины пока не спасают.
Решение: инцидент → постмортем (мой шаблон) → action items с владельцем. Без follow-up вы чините симптомы, а не систему.

Здоровый on-call - не героизм, а инженерная практика. Плохой on-call - инцидент без конца.

Что из этого есть у вас?:)

#sre #oncall #alerts #burnout

AI SRE Agent не заменит on-call

PagerDuty 12 марта 2026 выкатили Spring 2026 release с важным сигналом: SRE Agent как virtual responder, которого можно будет добавлять в schedules и escalation policies. Он первым смотрит на инцидент, делает triage/diagnosis и только потом будит человека.

Звучит как мечта: в 03:17 просыпается не инженер, а коробка с LLM внутри. Спасибо, я и так достаточно страдал.

Но горячий тейк такой: AI в incident response не чинит плохой SRE-процесс. Он делает его быстрее, дороже и увереннее в своей неправоте.

1. Если нет SLO - агент не знает, что важно

AI может сгруппировать алерты и предложить гипотезу. Но он не знает, что для бизнеса больнее: 500 ошибок в админке или +800 ms на checkout.

Это всё ещё решают SLI/SLO и error budget. Без них agent будет сортировать шум по громкости, а не по impact. Получится быстрый дежурный без контекста.

2. Если телеметрия каша - AI будет гадать
OpenTelemetry semantic conventions - это база для корреляции: единые имена для traces, metrics, logs, profiles и resources. А log correlation позволяет связывать логи с traces через trace/span id.

Если в одном сервисе service, в другом app, в логах нет trace_id, владельцы живут в голове у Сережи, а деплои не связаны с инцидентами - агент будет играть в угадайку.

Сначала сделайте так, чтобы человек мог за 10 минут собрать timeline. Потом зовите AI ускорять это до одной минуты.

3. Давать write-права сразу - плохая идея

Вендоры уже говорят про approved remediations, rollback, scaling и автономные действия. Если сценарий типовой, зачем будить человека?

Но начинать надо не с "пусть сам чинит прод", а с read-only режима:
- собрать timeline;
- показать связанные алерты;
- найти похожие инциденты;
- подсветить последний deploy;
- предложить запросы к логам/трейсам;
- показать, какой runbook устарел.

Только потом - действия по allowlist: rollback canary, scale-up, рестарт consumer'а, отключение фиче-флага. И всё это должно попадать в аудит и постмортем.

Автономность без guardrails - это chaos engineering без календаря.

4. "AI написал RCA" - ещё не RCA

Root cause без доказательств - это не root cause, а уверенный autocomplete.

Нормальный AI-помощник должен показывать evidence: какая метрика изменилась, какой trace это подтверждает, какой deploy был рядом, какие логи связаны тем же trace_id.

Если агент не показывает доказательства - его выводы нельзя использовать для remediation. Максимум - как гипотезу для on-call.

5. AI не убирает toil автоматически

Catchpoint SRE Report 2026 охлаждает хайп: median toil у инженеров вырос до 34%. Почти половина респондентов говорит, что AI снизил toil, но треть не видит изменений, а часть получила новую нагрузку.

Самый неприятный пункт: только 13% уверены, что могут мониторить reliability AI/ML-компонентов.

То есть менеджмент уже видит "AI transformation", а инженер в 3 ночи всё ещё проверяет, не наврал ли ему новый помощник. Красота.

Что я бы мерил перед внедрением AI SRE:
- минуты от page до первого нормального timeline;
- процент алертов с владельцем, severity и runbook;
- сколько алертов агент сгруппировал правильно, а сколько спрятал зря;
- сколько раз AI-сводка сократила расследование или добавила проверки;
- сколько remediation-действий прошли без отката.

И только после этого можно говорить, что AI помогает reliability, а не просто красиво пересказывает дашборды.

AI SRE Agent - это не замена on-call. Это усилитель для команды, у которой уже есть SLO, нормальная телеметрия, runbook'и, ownership и культура постмортемов.

Если этого нет, AI станет новым участником инцидента. С доступом к продакшену. Что может пойти не так?

Вопрос к вам: вы бы пустили AI-агента в свой on-call хотя бы в read-only режиме?

#sre #observability #oncall #ai #incidentresponse

Кто пейджит пейджер?

На Reddit наткнулся на прекрасный по боли тред: "PagerDuty went down and my day went straight to hell".

Ситуация знакомая: система, которая должна будить on-call, сама деградирует. Инциденты создаются с задержкой, уведомления не доходят, UI тупит, а ты думаешь: "всё хорошо или я просто ослеп?"

И это не абстрактный страх. У PagerDuty есть разбор инцидента 28 августа 2025.
Там проблема в Kafka привела к деградации обработки событий, задержкам уведомлений, webhooks, REST API и chat integrations. Часть событий могла получать 502, а при восстановлении пошёл backlog.

Когда ломается paging-платформа, у вас не "просто не пришла SMS". У вас ломается нервная система production.

Плохая новость: PagerDuty, Opsgenie, incident.io, Slack, SMS-шлюз и ваш любимый webhook - это тоже зависимости.
Хорошая новость: их можно проектировать как зависимости, а не как магическую трубу.

Alerting != paging
Алертинг - это где рождается сигнал: Prometheus, Grafana, Datadog, CloudWatch, Zabbix.

Paging - это как сигнал доезжает до человека: PagerDuty, Opsgenie, Grafana OnCall, самописный бот, SMS, email, Slack, Telegram - или что там у вас.

Если единственный способ понять, что прод горит, - открыть ваш paging tool, то у вас не incident management. У вас single point of panic.

Критичные алерты должны иметь обходной путь
Не надо дублировать каждый warning в пять каналов, иначе on-call начнёт ненавидеть жизнь.

Для P0/P1 должен быть fallback:
- email напрямую из monitoring source;
- резервный Slack/Telegram канал;
- отдельный webhook;
- внешний synthetic check;
- status page watcher для критичных SaaS;
- ручной режим "смотрим главные SLI dashboards".

Звучит дедовски, но когда paging лежит, дедовские методы внезапно становятся enterprise-grade.

Надо мониторить не только сервисы, но и путь алерта
Типичный антипаттерн: сервис мониторится, Prometheus мониторится, Alertmanager мониторится, а дальше сигнал улетает в SaaS: "ну там серьёзные ребята, они сами себя мониторят".

Серьёзные ребята тоже падают.

Минимальный healthcheck:
- тестовый алерт раз в сутки/неделю;
- проверка, что он дошёл до нужного канала;
- проверка escalation policy и schedule;
- алерт, если status page paging-провайдера красная;
- понятный runbook: что делаем, если paging не работает.

Да, получается "мониторинг мониторинга мониторинга". Добро пожаловать в SRE.

При падении paging нужен emergency mode
Не надо героически продолжать обычный день, если вы не уверены, что пейджинг работает.

Нормальная реакция:
- объявить change freeze;
- вручную смотреть ключевые SLI dashboards;
- смотреть критичные user journeys;
- перевести коммуникацию в заранее известный fallback-канал;
- отключить шумные некритичные алерты, чтобы видеть реальный impact;
- после восстановления разобрать не только vendor outage, но и свою слепоту.

Потому что вопрос не "почему PagerDuty упал?". Любой vendor или самописный бот может упасть.

Вопрос: почему его падение сделало вас слепыми?

Vendor redundancy - не серебряная пуля
Можно подключить два paging tools. Можно три. Можно отправлять SMS через двух провайдеров и email через отдельный домен.

Но если все они получают один и тот же кривой шум без SLO, ownership и severity - вы просто построили отказоустойчивую машину для доставки мусора.

Сначала качество сигнала. Потом резервирование доставки.
Моя позиция простая: paging path - это часть production. Его надо проектировать, тестировать и разбирать в постмортемах как базу, очередь или API gateway.

Если вопрос "а что если это упадёт?" задаётся к базе и очереди, он должен задаваться и к on-call tooling.

Иначе однажды будет тихо. Очень тихо. А потом внезапно напишет клиент.

Вопрос к вам: у вас есть backup path для P0/P1, если основной paging внезапно умер?

#sre #oncall #alerts #incidentresponse #observability

Платформа для wheel of misfortune.

Ранее я рассказывал, зачем SRE-командам Wheel of Misfortune и как не превратить его в “поиграли и забыли”.
Когда то я обещал моему лиду (привет Виталя) что верну в Додо WoM, которую вел мой ментор Ренат. Мне безумно нравилось, как он это делал. А теперь я сделал платформу, чтобы это было проще проводить руками.
Репозиторий тоже открыт.

Идея простая: не хранить сценарии в разрозненных .md, табличках, Notion-страницах и “где-то у Васи”, а собрать нормальный тренажёр для incident response.

Что сейчас умеет платформа:
- создавать свои game packs;
- держать приватные и публичные наборы сценариев;
- запускать игру в режиме ведущего;
- давать игроку отдельную ссылку на сессию;
- выбирать сценарий руками или крутить колесо;
- импортировать сценарии пачкой через JSON;
- играть соло без ведущего, если хочется просто потренироваться.

Внутри сценарий — это не просто “у нас DNS сломался”. Там есть контекст, тип инцидента, сложность, примерная длительность, timeline событий, подсказки для ведущего, действия игрока и GM script: pressure-вбросы, чекпоинты, подсказки по раундам.

Мне хотелось, чтобы WoM был ближе к нормальной тренировке, а не к созвону “ну представь, что всё плохо”.
Игра разбита на фазы: Detection → Investigation → Mitigation → Recovery.

Каждый раунд игрок выбирает действие: дебажить, коммуницировать, принимать IC-решение или делать ops-фикс. Выбор влияет на panic level, service health и score. Да, это условная модель. Но она хорошо подсвечивает мысль: в инциденте важно не только “угадать root cause”, но и не забыть про коммуникацию, scope, верификацию восстановления и post-mortem.

Отдельно я добавил agent skill: можно взять описание реального инцидента, runbook или заметки после разбора, сказать агенту “Сделай JSON для импорта в WOM” — и получить сценарий в формате платформы.

Вот это для меня самая вкусная часть.

Постмортемы часто умирают в Confluence/Notion/GitHub после пары action items. А тут их можно превращать в тренировочные сценарии. Был больной инцидент с CoreDNS, NetworkPolicy, cert-manager, remote_write или ingress? Отлично, через месяц прогоняем команду через похожий кейс и смотрим, стало ли лучше.

Пока внутри есть Starter Pack: ConfigMap/env vars, DNS/CoreDNS/NetworkPolicy, DiskPressure из-за логов, ingress 503 и observability blackout. Можно зайти под demo или зарегаться и сразу покрутить.

Технически это Next.js + Prisma + PostgreSQL, локально поднимается через Docker Compose. UI делал через codex, ведь я натурал совсем не фронтендер. Никакого OAuth, простой логин/пароль, потому что цель сейчас не построить enterprise LMS, а сделать штуку, которую можно быстро поднять, наполнить своими сценариями и использовать с командой. Да, местами не все так гладко, а может даже слишком криво (все же фронт писала нейронка).

Короче, если раньше я говорил про “зачем вообще WoM”, то это уже попытка сделать маленький open-source инструмент вокруг этой практики.

Заходите - https://wom.fadeinflames.ru/

Буду рад, если попробуете, покрутите, загрузите свои сценарии и скажете, где неудобно. Особенно интересно, какие поля вам нужны в сценарии, чтобы игра была полезна не только SRE, но и разработчикам, тимлидам и incident commanders. Очень хочется вашей обратной связи.

#sre #oncall #incidentresponse #postmortem #wheelofmisfortune

1:1 - это не терапия, а место, где можно по-человечески поговорить не только о работе.

Уйдем чуть-чуть от технички в более простые, но не менее важные вещи.
Раньше я воспринимал 1:1 довольно утилитарно.

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

Потом в Додо мне показали другой формат.

Оказалось, что 1:1 - это не только про задачи, перформанс и “что у тебя по проекту”. Иногда это маленький safe space, где можно сказать:
- “я устал”
- “я не вывожу”
- “меня бесит вот эта штука”
- “я не понимаю, куда дальше расти”
- “у меня сейчас сложный период вне работы”

И нормальный руководитель в этот момент не становится психологом, спасателем или мамой. Но он начинает видеть контекст.

А контекст решает.

Если руководитель видит только карточки в трекере, он управляет карточками.
Если он видит человека и контекст вокруг него, он может управлять нагрузкой, ожиданиями, ростом и рисками.

Для меня это прям поменяло отношение к 1:1. Это перестало быть встречей ради встречи и стало нормальным инструментом управления.

Что, на мой взгляд, делает 1:1 полезным:

1. Регулярность
Лучше стабильные 30 минут раз в 1-2 недели, чем “созвонимся, когда будет тема”.
Потому что “темы нет” - это тоже состояние. Иногда самое важное всплывает не в начале, а на 17-й минуте после стандартного “да вроде всё нормально”.

2. Это не статус-митинг
1:1 - это не место, куда надо переносить весь таск-трекер.
Статусы должны жить в таск-трекере, стендапах, PR, документах - где угодно, но не съедать весь 1:1.
Задачи можно обсуждать, но обычно за ними должна быть настоящая тема: блокер, конфликт, перегруз, непонятные ожидания, потеря мотивации.

Если весь 1:1 - это “ну что там по тикету?”, то поздравляю, вы изобрели плохой дейлик на двоих.

3. Повестка должна быть с двух сторон

Хорошо, когда и руководитель, и человек заранее накидывают темы.

Если повестку всегда приносит только руководитель, встреча быстро превращается в “начальник что-то хотел”. А 1:1 всё-таки должен быть местом, где человек тоже может принести то, что ему важно.

4. Safe space создаётся поведением, а не словами

Недостаточно сказать “у нас тут безопасное пространство”.
Безопасность появляется, когда тебя не перебивают, не обесценивают, не используют личное против тебя через месяц и не превращают каждую честную фразу в performance issue.

Доверие строится медленно, а ломается очень быстро. Классика, ничего нового.

5. Личное можно обсуждать, но аккуратно

1:1 - не исповедь и не терапия. Руководитель не должен лезть человеку в душу.

Но если человек сам говорит “у меня сейчас дома тяжело” или “я не вывожу”, нормальная реакция - не копаться в деталях, а понять, как это влияет на работу и чем можно помочь.

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

6. Нужны follow-up’ы

Если на 1:1 договорились что-то сделать - это надо потом вспомнить.
“Я поговорю с командой”, “посмотрю промо-план”, “помогу разгрузить”, “вернусь с ответом” - это не декоративные фразы, а action items.

Нет follow-up’а - нет доверия. Всё очень просто и очень больно.

Хороший 1:1 после себя оставляет чуть больше ясности, спокойствия или движения вперёд.

Для человека - это место, где его слышат не только как исполнителя задач.
Для руководителя - это ранний мониторинг состояния команды.
Только вместо CPU, latency и error rate у тебя мотивация, усталость, ясность, доверие и рост.

И если после 1:1 ничего не меняется ни в голове, ни в действиях, ни в отношениях - возможно, это был просто ещё один календарный алерт без runbook’а.

А у вас 1:1 больше про задачи, про людей или “ну надо же иногда созваниваться”?

#sre #teamhealth #onetoone #leadership