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 #НагрузочноеТестирование

Самый опасный деплой 2026 года - тот, который никто не считал деплоем

Залез перечитывать большие постмортемы этого года. Пока мы спорим, пускать ли AI-агента в on-call, три самых громких аутэджа года говорят совсем о другом.

Cloudflare, 20 февраля. Azure, 23 июля. Google Cloud, 20 августа. Три компании, три стека, одна причина: плановая, рутинная, «безопасная» операция, которую выполняла автоматика. Никто не катил релиз. Никто не лез в прод руками. Всё по регламенту.

1. Cloudflare: cleanup с пустым параметром
Задача чистила BYOIP-префиксы, помеченные на удаление. Параметр pending_delete ушёл в API без значения - и сервер вернул вообще все префиксы. Система честно начала удалять их вместе с зависимыми объектами. Из BGP ушли ~1 100 из 4 306 префиксов, четверть. 6 часов 7 минут. Код отработал правильно. Просто вопрос был задан неправильно. Знакомо?
2. Azure West US: blast radius посчитали не так
Рутинный break-fix на сети. Система анализа blast radius из-за дефекта расширила scope на все оптические устройства датацентра. Safety validation тоже отработала и сказала «безопасно»: она проверяла устройства по одному, а не эффект от изоляции всех сразу. Маршруты между ДЦ и WAN исчезли, около 5 часов. Алерты сработали через минуту, а вот связать аномалию с maintenance-триггером смогли только через 2,5 часа. Откат - руками.
3. Google Cloud us-west1: failover не сделал failover
Плановые работы на оптике между ДЦ. Ёмкость просела сильнее ожидаемого, automated rerouting «failed to properly redistribute traffic». Деградация трёх десятков продуктов. 2 часа 22 минуты. В remediation Google обещает «stricter safety checks and circuit redundancy requirements prior to routine maintenance». У Google. Если казалось, что только у вас так - нет.

Что общего
Uptime Institute в Annual Outage Analysis 2026: 92% считают человеческий фактор хотя бы частичной причиной последнего серьёзного сбоя, самая частая форма - failure to follow procedures (59%). 87% говорят, что аутэдж можно было избежать.
Но заметьте: во всех трёх кейсах процедуры были. И им следовали. Проблема в том, что плановые работы и «служебная» автоматика живут вне контура безопасности, который мы построили для деплоев. У релиза есть canary, progressive rollout, откат по SLO, feature flag. У «чистим префиксы» и «изолируем железку» - тикет и окно. Ну и надежда.

Что стоит проверить в любой инфраструктуре
1. Инвентаризация «не-деплоев». Cleanup-джобы, cron по удалению ресурсов, вывод нод из ротации, работы на сети и СХД, миграции DNS. Всё, что меняет прод, - это change. Даже bash по расписанию.
2. Blast radius до, а не после. Cleanup обычно удаляет 5 объектов, а собрался 25% всего? Это должно остановить задачу, а не попасть в постмортем. Cloudflare ровно это и внедряет.
3. Safety-check на совокупность, а не поштучно. Если pre-flight проверяет элементы независимо, у вас нет pre-flight.
4. Failover тестируется до maintenance. Автоматический rerouting - тоже код. Плановое окно - не время узнавать, что запасной путь не тянет.
5. Связь «что делали» и «что сломалось». Плановые работы и запуски автоматики должны быть annotation'ами на дашбордах и событиями в timeline, как деплои.
6. Ручной откат отрепетирован. Во всех трёх кейсах автоматика не откатила себя сама. Я такое гонял на Wheel of Misfortune: сценарий «плановые работы пошли не по плану» отлично ложится в формат, в моей платформе собирается за вечер. Отрезвляет, когда на словах все знают, где кнопка «стоп», а на игре её ищут пять минут.

Мы научились не бояться деплоев: сделали их частыми, маленькими и обратимыми. Плановые работы пока живут в 2015 году: редкие, большие и «там всё проверено».
Ломает прод не то, что вы считаете рискованным. А то, что перестали считать изменением.

Вопрос к вам: у ваших плановых работ и cleanup-джобов есть хоть что-то из того, что есть у деплоя? Или тоже тикет, окно и надежда?

#sre #incidentresponse #changemanagement #postmortem #wheelofmisfortune

Агенту разрешают расследовать, но не разрешают чинить. Почему граница именно здесь????

В ноябре я писал про 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 > 50 можно) плюс бюджеты.
2. Вето вне агента. В r/kubernetes: LLM предлагает scale, rollback, cordon, drain, а детерминированный Safety Engine без LLM проверяет действие по живому состоянию API.
Комментарии: вето должно жить там, где агент не может исполнять код (отдельный процесс, admission webhook), иначе «вы построили второе мнение, а не вето»; оно должно быть stateful (бюджет blast radius, cooldown, проверка результата) и перепроверять состояние прямо перед мутацией.
3. Обратимость как критерий. Security patching автоматизировали, потому что у каждого действия известен откат. Rollback, scale, restart - митигации, а не фиксы. Команды на GitOps уже пускают агентов открывать PR («большинство RCA были верными»), но мержить и катить - человек. Mezmo выложили в open source AURA : их SRE-команда упёрлась в переполнение контекста, галлюцинации и approval fatigue и «провела жёсткую черту: права в проде не ослабляем».
Инструменты проверяются вне контекста агента, approval через webhook, по таймауту - fail-closed.

Другой полюс
Boris Tane (ex-Baselime и Cloudflare, теперь строит Polylane: «никто не должен дежурить в 2026») 21 августа опубликовал On-Call Is Now Theatre: дежурство - признание поражения, если пейджить агента бесплатно, алертов нужно радикально больше, а единственный валидный результат расследования - diff.
Он продаёт это будущее. Но даже его рецепт на первую неделю - дать агенту read-доступ к телеметрии на самом шумном алерте и две недели сравнивать его triage с людьми. То есть read-only.

Что я из этого я бы точно себе забрал?
Граница - не вопрос доверия, а отсутствие того, что в треде назвали bounded authority: система должна знать, что ей можно, при каких доказательствах и когда нужен второй approve. Без базы из ноябрьского поста (SLO, связная телеметрия, живые runbook'и) агент просто быстрее ошибается. И измеряйте: прогоните агента по своим постмортемам и посчитайте долю неверных вердиктов.

Вопрос к вам: что вашему агенту уже разрешено делать в проде без человека? И кто это разрешил - policy или привычка?

#sre #oncall #ai #incidentresponse #observability

Wheel of Misfortune, но с настоящим прод‑инцидентом внутри
Полгода назад я писал, зачем SRE нужна Wheel of Misfortune: ролевая игра про инцидент, где ведущий рассказывает, что видит дежурный, а дежурный говорит, что бы он сделал.
Полезно, дёшево, но есть одна честная проблема: это разговор. Никто ничего не чинит. «Я бы посмотрел describe pod» звучит одинаково у того, кто делал это сто раз, и у того, кто ни разу.

И тут я подгорел и сделал платформу, где инцидент настоящий, тк инцидентное мышление тренируется руками, а не словами.

Вашему вниманию - тренажёр инцидентов с живыми окружениями.

WoM Platform

Заходишь, выбираешь сценарий (или крутишь колесо), и через пару секунд для Linux‑хоста или через минуту для Kubernetes у тебя в браузере терминал в изолированный стенд, который уже сломан.
Nginx отдаёт 502, диск базы забит бинлогами, rollout завис на квоте, HPA пилит сам себя, cert-manager не может продлить сертификат.
Чинишь как на настоящем дежурстве (как будто бл* на работе мне этого не хватает, ага): логи, ss, df, kubectl describe, kubectl edit.
Жмёшь «Проверить» - грейдер смотрит на результат, а не на способ: любой честный путь засчитывается, «убрать пробу» или «поднять лимит памяти» - нет.
После решения открывается разбор: что было сломано, как диагностируется, эталонное решение, ловушки, что почитать.

Что уже готово
22 живых сценария от Junior до Senior.
Для джунов - учебные копии. У каждого junior‑кейса две версии: обычная и учебная с панелью «Нужна помощь?», которая открывает этапы диагностики по одному и объясняет, зачем нужна каждая команда. Не «вот ответ», а «вот куда смотреть и почему». Плюс шпаргалка и что почитать заранее.
Стенды настоящие. Каждый сценарий проходит регресс: свежий стенд не решён, эталонное решение решает, ловушки не проходят.

Ограничения, чтобы не было сюрпризов
Одновременно живут до 6 Kubernetes‑стендов и до 20 сессий всего, а поднимаются они по два за раз: если увидите «ждём свободный слот» или «занято», это не поломка, подождите пару минут.
Неиспользуемые 7 дней учётки отключаются автоматически. Почты пока нет, так что если не пускает или еще какие то проблемы - напишите мне, пожалуйста.
Тяжёлые стенды (cert-manager, Prometheus, ingress) поднимаются 2–3 минуты, на странице видно, что именно сейчас происходит.

Что планирую дальше?
Заопенсорсить, что бы вы могли кидать свои кейсы сами и разворачивать это у себя. Ну или смотреть как это сделано у меня и сделать лучше для себя и под себя.
Прикрутить почту, что бы была нормальная регистрация по email. Ну и конечно же, больше и больше кейсов.

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

Вопрос к вам: какой инцидент из вашей практики вы бы превратили в сценарий первым? Присылайте пост‑мортемы, самые интересные сделаю и опубликую с указанием автора.

#SRE #WheelOfMisfortune #oncall #kubernetes #incident_response