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

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

Теперь хочу докрутить мысль с инженерной стороны.

Хороший 1:1 - это не только разговор. Это ещё и система хранения сигнала.

Потому что если после встречи ничего не осталось, кроме “вроде хорошо поговорили”, то у вас не процесс, а устный лог без retention policy.
Очень душевно, но дебажить потом больно.

Что же должно оставаться после нормального 1:1?

1. Сигнал
Не просто “человек устал”, а понятнее:
- нагрузка растёт;
- ясности меньше;
- доверие просело;
- мотивация меняется;
- тема повторяется уже третью встречу.

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

2. Контекст
Иногда человек говорит не “у меня проблема”, а “да нормально всё”.
А потом на 20-й минуте оказывается, что нормально там примерно ничего.
Поэтому контекст надо не только услышать, но и сохранить: что было важно, какие ограничения есть, где человек сейчас находится, что влияет на работу.
Не чтобы превратить 1:1 в CRM по людям. А чтобы не начинать каждый разговор с холодного старта.

3. Договорённость
“Да, надо будет обсудить с командой” - это не договорённость.
Договорённость начинается там, где понятно:
- кто делает;
- что делает;
- к какому сроку;
- зачем;
- когда вернёмся проверить.
Нет follow-up’а - нет доверия. Это я уже писал, но повторю, потому что больно.

4. Гипотеза развития
Если на 1:1 постоянно всплывает одна и та же тема - это может быть не “просто поговорить”, а материал для ЛПР.
Например:
- сложно приоритизировать;
- тяжело отказывать;
- не хватает системной диагностики;
- человек хочет расти, но не понимает куда;
- ожидания по роли мутные.
Это уже не заметка. Это гипотеза развития, которую можно превратить в цель, план или конкретный следующий шаг.

5. Память процесса
Самая частая проблема менеджмента: всё держится в голове руководителя.
Пока людей мало - работает.
Потом появляются несколько 1:1, найм, конфликты, performance review, срочные проекты, отпуска, увольнения, и внезапно оказывается, что “я же помнил” - плохая база данных.

Поэтому я и собрал Team Health 1:1.
Это небольшой pet-project про то, как сделать 1:1 процессом с памятью:
- общая повестка между встречами;
- пульс по энергии, нагрузке, ясности и доверию;
- живой протокол встречи;
- action items;
- ЛПР и цели;
- опросы команды;
- карта компетенций и зоны роста.
Не HR-комбайн и не замена нормальному руководителю.
Скорее попытка сделать скучную, но важную часть менеджмента наблюдаемой.
Прошу строго не судить, node.js я только учу, большая часть ui сделана через codex.

Потому что 1:1 без доверия - бесполезен.
Но 1:1 без памяти - хрупкий.

Сегодня поговорили хорошо, завтра всё забыли, через месяц удивились, что проблема никуда не делась.
В SRE такое обычно называют “алерт был, реакции не было”.

Потыкать можно тут
Тестовый вход: demo / demo
Репа: https://github.com/fadeinflames/team-health

Вопрос к вам: где у вас чаще всего теряется память 1:1 - в договорённостях, развитии, контексте или follow-up’ах?

#sre #teamhealth #onetoone #leadership

Думаешь, что не выгорел? Возможно, ты уже прогорел. Просто система всё ещё отвечает 200 OK.

Это первый пост небольшой серии о выгорании.
Сначала разберём, как сотруднику отличить «я просто устал» от устойчивой проблемы и что с этим делать. Следующий пост будет для лидов: как не сжечь команду и что делать, если человек уже на грани.

Выгорание редко начинается с красивого «я больше не могу».
Чаще ты продолжаешь ходить на дейлики, закрывать задачи и выходить на дежурства. Снаружи всё работает. Внутри ты уже отключил половину алертов, потому что на остальные нет сил реагировать.

ВОЗ описывает выгорание через три вещи:
• истощение;
• дистанцирование от работы и цинизм;
• ощущение, что ты стал хуже справляться.

Это не диагноз по посту в Telegram. Но есть паттерны, после которых опасно продолжать говорить себе: «Да я просто устал».

1. Отдых перестал тебя возвращать
Не один плохой понедельник. Недели.
Спишь, проводишь выходные без ноутбука, берёшь свободный день — а батарея всё равно заряжается процентов до двенадцати.

2. Сарказм заменил вовлечённость
Раньше ты спорил и предлагал. Теперь любая новая задача вызывает только: «Ну конечно. Именно этого нам и не хватало».
Юмор — нормальная система охлаждения. Но когда за ним остаются только злость и безразличие, система уже перегревается.

3. Результат больше ничего не даёт
Задачи закрываются, а ощущения «я что-то сделал» нет.
После работы остаётся не удовлетворение, а только облегчение, что от тебя временно отстанут.

4. Голова работает в degraded mode
Теряешь контекст между вкладками. Перечитываешь сообщение три раза. Простая задача ощущается как ещё один инцидент.
Систематический обзор обнаружил связь клинического выгорания с ухудшением внимания, рабочей памяти и скорости обработки информации. Не доказанную причину — именно связь.

Так что «я просто стал тупее» может быть не самым точным диагнозом системы.

5. Работа закончилась, а ты из неё не вышел
Чаты закрыты, но диалоги продолжаются в голове.
Перед сном проверяешь инциденты. На прогулке дебажишь проект. В выходной мысленно (или нет) отвечаешь на рабочие сообщения.

Метаанализ 86 публикаций связал психологическое отключение от работы с меньшим истощением, меньшей усталостью и лучшим сном.

Что делать, если ты узнал себя? Я вот, честно, местами узнаю.

Не пытаться починить это дополнительной продуктивностью.

Зафиксируй конкретные сигналы: как давно не восстанавливаешься, что изменилось в работе, где стало больше ошибок, раздражения или безразличия.

С этим иди к руководителю. Не только с «кажется, я выгорел», а с конкретным запросом:
• что мы временно снимаем;
• какие сроки двигаем;
• кому передаём часть задач;
• можно ли сделать паузу в on-call;
• когда проверим, стало ли лучше.

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

Если условия не меняются даже после прямого разговора, смена проекта, команды или работы — не поражение. Иногда это единственный способ перестать обслуживать систему, которая стабильно сжигает людей.

И если состояние вышло за пределы работы, разваливается сон, пропадает интерес ко всему или появляется постоянная безнадёжность — лучше обратиться к врачу или специалисту по психическому здоровью. Пост в Telegram не отличит выгорание от депрессии или тревожного расстройства.

Что у вас ломается первым: энергия, отношение к работе или ощущение результата?

В следующем посте — что должен делать лид, кроме бесполезного «возьми отпуск и береги себя».

#teamhealth #leadership #выгорание

Выгоревший сотрудник — не сломанный ресурс, который нужно перезапустить. Иногда сломана сама система работы.

Это второй пост серии о выгорании.

В первом разобрали сигналы и действия сотрудника. Теперь неприятная часть для руководителя: что делать, если человек уже не вывозит, и как не сжечь остальных.

Начнём с простого.

Лид — не психотерапевт. Он не должен ставить диагнозы, копаться в личной жизни или героически спасать человека.
Но лид отвечает за архитектуру работы.

Нагрузку. Приоритеты. Дежурства. Количество параллельных задач. Ясность ожиданий. Возможность влиять на решения. Реакцию команды на ошибки и просьбы о помощи.
Поэтому ответить на «я больше не вывожу» ссылкой на приложение для медитации и оставить тот же roadmap — довольно странный incident response.

1. Не диагностируй — наблюдай
Смотри не на настроение одного утра, а на изменение поведения.

Человек стал молчать на встречах? Чаще ошибается? Перестал предлагать решения? Раздражается на обычные запросы? После дежурств не восстанавливается?

Это не повод объявлять «у тебя выгорание». Это повод спокойно поговорить один на один.

2. Спрашивай не «как тебе стать продуктивнее?», а «что мы должны снять?»
Когда человек уже истощён, новый трекер, курс по тайм-менеджменту и совет лучше планировать день становятся ещё одной нагрузкой.

Откройте список задач и решите:
• что останавливаем;
• что передаём;
• какие сроки двигаем;
• где сокращаем WIP;
• нужна ли пауза в on-call;
• какие встречи и процессы можно убрать.
Если приоритетов семь, приоритетов нет.

3. Верни человеку контроль и ясность
Исследователи выгорания выделяют шесть важных зон рабочей жизни:
• нагрузка;
• контроль;
• вознаграждение и признание;
• отношения;
• справедливость;
• совпадение работы с ценностями.

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

4. Перестань награждать героизм
Если человек всю ночь тушил инцидент, утром ему не нужен ни новый дейлик и ни благодарность в общем чате.

Ему нужно восстановление.

Пауза после тяжёлого дежурства, нормальная передача задач, ограничение переработок и достаточное количество людей в ротации должны быть частью процесса, а не личной привилегией тех, кто умеет громко просить.

5. Обязательно сделай follow-up
«Береги себя» — не action item.

Договоритесь:
• что конкретно меняется;
• кто это делает;
• когда изменение вступает в силу;
• когда вы снова сверяетесь;
• по каким признакам поймёте, что стало лучше.

Если через две недели человек всё ещё работает в том же режиме, значит, разговор был эмоциональной разгрузкой, а не изменением системы.
ВОЗ рекомендует работать не только с отдельным сотрудником, но и с условиями: нагрузкой, графиком, гибкостью, поддержкой, ясностью ролей и участием людей в решениях.

Метаанализ организационных вмешательств обнаружил небольшое снижение истощения; перспективнее выглядели изменения нагрузки и сочетание организационных мер с индивидуальной поддержкой. При этом качество доказательств авторы оценили как низкое — серебряной пули здесь нет.

Но направление вполне здравое:
Не только учить человека лучше переносить плохую систему. Исправлять саму систему тоже.

Лид не обязан лечить выгорание.

Но он обязан не делать вид, что постоянная перегрузка, дежурства без восстановления и пять одновременных приоритетов — личная проблема сотрудника.

Какой сигнал выгорания ваша команда обычно замечает слишком поздно?
#teamhealth #leadership #выгорание

У вашего мониторинга могут быть права на RCE. И вы сами их выдали

Залез читать изменения Kubernetes 1.36 и наткнулся на прекрасное.

У ServiceAccount вашего Prometheus, log collector или monitoring agent может быть такое правило:

resources: ["nodes/proxy"]
verbs: ["get"]

Выглядит безобидно.
Ну get же. Read-only. Просто почитать метрики и разойтись.

На деле этого права может хватить, чтобы выполнить команду в любом контейнере на доступной ноде.
Да, get.
Да, RCE.
Ага, Kubernetes moment.

Как мы вообще сюда пришли

У kubelet есть HTTPS API, обычно на порту 10250. Через него можно получать метрики, статистику, логи, список Pod — и делать exec в контейнеры.

Исторически почти все эти endpoint’ы авторизовывались через один широкий ресурс — nodes/proxy.

То есть monitoring agent, которому нужно было только сходить в /metrics, получал то же право, через которое можно добраться до /exec.
Но становится ещё веселее.

Для установки WebSocket-соединения используется HTTP GET. Kubelet сопоставлял этот запрос с RBAC-глаголом get и не выполнял дополнительную проверку на create перед началом интерактивной операции.

В результате ServiceAccount с get nodes/proxy и сетевым доступом к kubelet API мог открыть /exec и выполнять команды внутри контейнеров.
Kubernetes SIG Auth и SIG Node прямо называют nodes/proxy возможностью уровня node superuser.

Важная оговорка
Это не означает, что любой установленный Prometheus автоматически уязвим.
Должны совпасть два условия:
— у ServiceAccount есть get на nodes/proxy;
— из workload можно достучаться до kubelet API на ноде.
Но для агентов, которые собирают данные напрямую с kubelet, второй пункт вполне может быть частью архитектуры.
И если такой агент или его токен скомпрометируют, blast radius будет немного больше, чем «сломался один дашборд».

Но ведь Kubernetes 1.36 это исправил?
И да, и нет. :)

В 1.36 KubeletFineGrainedAuthz стал GA и всегда включён. Вместо широкого nodes/proxy теперь можно выдавать точечные права:
— nodes/metrics для /metrics/*;
— nodes/stats для /stats/*;
— nodes/log для /logs/*;
— nodes/pods для списка Pod.
Например:

resources: ["nodes/metrics", "nodes/stats"]
verbs: ["get"]

Но апгрейд не удаляет старые разрешения.
Для обратной совместимости kubelet продолжает принимать nodes/proxy. Поэтому кластер может быть на свежей версии, все Pod зелёные, а старый blast radius никуда не делся.
Совместимость бережно сохранила не только ваши интеграции, но и лишние права. Очень заботливо.

Что я бы проверил прямо сейчас
1. Найти все ClusterRole с nodes/proxy:

kubectl get clusterroles -o json | jq -r '
.items[]
| select(any(.rules[]?;
    (.resources // []) | index("nodes/proxy")))
| .metadata.name'

2. Посмотреть, к каким ServiceAccount они привязаны. Особенно внимательно — monitoring, logging, security и разные node-level DaemonSet.

3. Проверить конкретный ServiceAccount

kubectl auth can-i get nodes/proxy \
  --as=system:serviceaccount:<namespace>:<serviceaccount>

4. Понять, какие kubelet endpoint’ы агент реально использует, и заменить nodes/proxy на минимальный набор nodes/metrics, nodes/stats, nodes/log или nodes/pods.
Не выдавайте весь набор «на всякий случай». Мы именно так сюда и приехали.
5. Проверить scrape и сбор логов на canary, удалить старое право и запретить новые workload-binding’и с nodes/proxy через admission policy. Доступ к 10250 тоже стоит ограничить на сетевом уровне.
Только не удаляйте разрешение вслепую из системных ролей: оно легитимно нужно некоторым компонентам Kubernetes. Нас интересуют обычные workload’ы, которым его выдали ради observability.

Главный вывод тут даже не про kubelet.
get — это название операции, а не гарантия безопасности.
Если ресурс называется proxy, вы разрешаете не чтение объекта. Вы открываете туннель к чужому API.
А что можно сделать внутри этого туннеля — RBAC-глагол вам уже не расскажет.

А у вас monitoring ServiceAccount всё ещё живут с nodes/proxy или вы уже перешли на fine-grained RBAC?
#kubernetes #security #sre

Встречаемся на ПерфКонф #12? ДА!

Вы, возможно, знаете, а может, и нет, но я очень люблю участвовать в программных комитетах разных конф. И вот уже второй год подряд я вхожу в ПК ПерфКонф.)))

Вместе с классными ребятами из ПК мы отбираем доклады, обсуждаем их содержание и формируем программу так, чтобы в ней было больше реального опыта, работающих решений и честных выводов — без воды и прочей ерунды.

В этом году поговорим о нагрузочном тестировании, оптимизации производительности, DevOps и CI/CD, SRE и Observability, применении ИИ, хаос-инжиниринге и других актуальных задачах.

📍 Москва, Loft Hall на Автозаводской
💻 Также можно участвовать онлайн
🗓 9 сентября 2026 года

А для тех, кто покупает билет как физлицо, есть промокод pk20 — укажите его при оформлении.

Буду рад встретиться, обсудить доклады и поговорить о том, что сейчас происходит в мире высоконагруженных систем. Присоединяйтесь!

До встречи на ПерфКонф #12! 🚀

#ПерфКонф #Performance #SRE #DevOps #НагрузочноеТестирование