A young Max’s notebook

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 только добавил работы. Маш… Читать полностью →

Платформа для 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. А тут их можно превращать в тре… Читать полностью →

В прошлом посте писал, что 1:1 - это не терапия и не статус-митинг, а нормальный инструмент управления, где можно увидеть человека и контекст. Теперь хочу докрутить мысль с инженерной стороны. Хороший 1:1 - это не только разговор. Это ещё и система хранения сигнала. Потому что если после встречи ничего не осталось, кроме “вроде хорошо поговорили”, то у вас не процесс, а устный лог без retention policy. Очень душевно, но дебажить потом больно. Что же должно оставаться после нормального 1:1? 1. Сигнал Не просто “человек устал”, а понятнее: - нагрузка растёт; - ясности меньше; - доверие просело; - мотивация меняется; - тема повторяется уже третью встречу. В SRE мы не очень любим “ну вроде сервис медленный”. Мы хотим метрику, baseline и динамику. С людьми сложнее, но принцип похожий: один разговор - это точка. Несколько разговоров подряд - уже тренд. 2. Контекст Иногда человек говорит не “у меня проблема”, а “да нормально всё”. А потом на 20-й минуте оказывается, что нормально там примерно ничего. Поэтому контекст надо не только услышать, но и сохранить: что было важно, какие ограничения есть, где человек сейчас находится, что влияет на работу. Не чтобы превратить 1:1 в CRM по людям. А чтобы не начинать каждый разговор с холодного старта. 3. Договорённость “Да, надо будет обсудить с командой” - это не договорённость. Договорённость начинается там, где понятно: - кто делает; - что делает; - к какому сроку; - зачем; - когда вернёмся проверить. Нет follow-up’а - нет доверия. Это я уже писал, но повторю, потому что больно. 4. Гипотеза развития Если на 1:1 постоянно всплывает одна и та же тема - это может быть не “просто поговорить”, а материал для ЛПР. Например: - сложно приоритизировать; - тяжело отказывать; - не хватает системной диагностики; - человек хочет расти, но не понимает куда; - ожидания по роли мутные. Это уже не заметка. Это гипотеза развития, которую можно превратить в цель, план или конкретный следующий шаг. 5. Память процесса Самая частая проблема … Читать полностью →

Агенту разрешают расследовать, но не разрешают чинить. Почему граница именно здесь???? В ноябре я писал про SRE Agent от PagerDuty: начинайте с read-only. Прошло десять месяцев, и спор сместился: уже не «заменит ли AI дежурного», а «где проходит граница». 24 августа в r/sre инженер после полугода on-call заметил одно и то же во всех обзорах AI SRE-инструментов: расследовать агенту дают одному, чинить - никто. Это навсегда? Что говорят цифры ORCA-bench, 30 июля, Cornell Tech, Columbia и Traversal (последние продают AI SRE-агента, держите в уме). Стенд: 19 микросервисов на OpenTelemetry, шесть дней телеметрии в Prometheus, Jaeger и OpenSearch, доступ к коду, 1 079 задач на root cause, пять фронтирных моделей. Лучшая точность RCA на задачах средней сложности (реалистичный ввод) - 25,3%, на сложных - 10,0%, разрыв сохраняется даже с Claude Fable 5. Слабейшая модель выдумывает неправдоподобную причину в 40% отчётов. Типичная ошибка: хватается за заметный симптом ниже по потоку вместо причины выше. Авторы называют это нижней границей: прод больше и грязнее стенда. Комментатор в треде сформулировал точно: плохой анализ в худшем случае тратит ваше время, запись в прод без человека - катастрофа. Граница проходит по цене ошибки. NeatContext в июле выключили автономного агента с доступом к логам: таймаут платёжного шлюза он связал со всплеском коннектов к БД двенадцатью часами раньше, через RAG унаследовал устаревший runbook и не умел сказать «не знаю». «Получили уверенный генератор галлюцинаций». Они продают свой инструмент, но симптомы знакомые. Как границу строят руками 1. Read-only, который действительно read-only. HyperProbe (Launch HN, 5 августа) даёт агентам ставить виртуальные пробы в работающий процесс. Главный вопрос треда: чем «только чтение» гарантия, а не договорённость? В Python чтение атрибута может дёрнуть @property с ленивой загрузкой из БД, в Java геттер - взять лок. Ответ: условия без вызовов методов и доступа к свойствам (order.total > 5 нельзя, total… Читать полностью →

Game of Incidents теперь в open source Понимаю, сейчас половина айтишников в РФ обсуждает падения всем известного облака. А вторая половина поднимает свои сервисы после этих падений. Ребята из Додо, душой и сердцем я с вами. Крепитесь. Но, обещал - сделал. Тренажёр в опенсорсе. Что внутри: - 22 сценария: 3 на Linux-хосте и 19 на Kubernetes. От junior («Nginx отдаёт 502», «Сломанные пробы») до senior («Фантомная сеть», «Обновление пошло не так»). У пяти junior-кейсов есть учебные версии с пошаговыми подсказками. - Установка одной командой на чистый Debian 13 или Ubuntu 24.04: bash scripts/provision/provision.sh --host <ip> --domain <домен> Можно и без домена, просто по IP. - Всё для своих сценариев. Сценарий - это папка с scenario.yaml, брифом, разбором, Dockerfile или манифестами и скриптами поломки, проверки и эталона. Есть инструкция для LLM-агента: описываешь ему свой инцидент и инфраструктуру, он пишет сценарий, проверяет и загружает на платформу. - Лицензии: код - Apache-2.0, сценарии и документация — CC BY 4.0. Теперь важный момент. Платформа запускает недоверенный код игрока в песочницах. В Kubernetes-сценариях нода кластера - привилегированный контейнер. Поэтому ставьте на выделенный сервер или ВМ и читайте SECURITY.md, прежде чем открывать регистрацию незнакомым людям. Интерфейс и большая часть документации - на русском. README и инструкция по установке есть и на английском. Попробовать: game.sresh.ru - регистрация по логину и паролю, почта не нужна. Забрать исходники: github.com/fadeinflames/game-of-incidents Буду рад сценариям из ваших постмортемов, с соблюдением NDA, пожалуйста. Для идей в репозитории есть шаблон issue - «Идея сценария». Готовые сценарии можно прислать через pull request или загрузить прямо в кабинете автора на сайте. Об уязвимостях - только в личку, не в issues. Это мой первый проект в опенсорсе, так что тряпками сразу не кидайтесь. Идеи, критику и любую другую обратную связь принимаю в личке и комментариях. #SRE #DevOps #Linux… Читать полностью →