Странное явление в технологических компаниях во время инцидентов.
Одни и те же люди появляются снова и снова. Давление растёт, и кто-то произносит три критические слова:
«Позовите его.»
Вы знаете этого человека. (Или вы и есть тот человек.) Подключается на пятнадцатой минуте, и через сорок минут всё работает.
Это героизм. И это знак того, что ваша система — нездоровая.
Почему ловушка появляется
Герой формируется органически. Кто-то — обычно тот, кто строил систему — знает её на уровне, недоступном остальным. Один раз во время инцидента он быстро нашёл причину. Все запомнили. В следующий раз сразу позвали его. Потом ещё раз.
Через год эта схема становится организационной нормой:
-
Когда что-то ломается → зовём героя.
-
Документация остаётся неактуальной — потому что у нас есть герой.
-
Runbook-и не пишутся — потому что у нас есть герой.
-
Onboarding новых SRE неполный — потому что у нас есть герой.
И герой работает. До определённого момента.
Что не так с этой моделью
Для человека
-
On-call никогда не заканчивается. Герой подключается даже не в свою смену, потому что «он быстрее разберётся».
-
Отпуск под угрозой. "Что если что-то случится?"
-
Карьерная ловушка: продвижение по сеньорности замедляется, потому что герой — слишком ценный на текущей роли, чтобы его отпустить расти.
-
Выгорание не за горами. Не «если», а «когда».
Для команды
Люди вокруг героя учатся вызывать героя, а не понимать систему. Их собственная глубина в системе атрофируется. Когда герой уходит в отпуск, кто-то увольняется, или просто эта неделя ему не идёт — все ломается, потому что система не имела backup-плана, кроме одного человека.
Для системы
Самое опасное: героическая модель скрывает архитектурные проблемы. Если для того, чтобы устранить инцидент, нужны уникальные знания одного человека, это сигнал, что система непознаваема для остальных. Нужны не лучшие герои — нужны лучшие observability, runbook-и, post-mortem-практики, distributed-tracing.
Признаки, что вы в ловушке героя
-
Когда кто-то конкретный в отпуске, MTTR растёт в 3+ раза.
-
Названия «Иван разберётся», «Спросите у Маши» звучат на каждом stand-up.
-
В post-mortem-документах постоянно встречается одно имя в графе «root cause discovered by».
-
Onboarding нового SRE длится 6+ месяцев до полноценной on-call.
-
Когда герой пытается передать знания — это часто формат «личных бесед», а не системной документации.
Как выйти из ловушки
1. Признайте проблему явно
Это не нападение на героя — это уважение к нему и забота о системе. Поговорите с человеком: «То, что ты делаешь во время инцидентов, ценно. И мы хотим, чтобы это можно было делать без тебя.»
Если разговор воспринимается как угроза — это другая проблема, и её надо решать отдельно.
2. Документируйте экспертные знания
Правило: после каждого инцидента, в котором участвовал герой, он не уходит, пока не зафиксировано в runbook-е, как именно он это нашёл и починил. Не «что было сделано» — это в timeline. А метод: какие команды запустил, какие графики посмотрел, какие гипотезы отверг и почему.
Это часто требует пары на сессии — один работает, другой фиксирует. На первых пяти раз это раздражает. Дальше становится нормой.
3. Назначайте не героя incident-commander-ом
Когда инцидент начинается, IC выбирается из числа не героев. Герой подключается как помощник по запросу. IC учится принимать решения, координировать команду и звать нужных людей. Через несколько месяцев на месте героя оказывается команда из 4-5 человек со сходным уровнем компетенции.
4. Game days и chaos engineering
Регулярно (раз в месяц) — учения. Сценарий: «герой в отпуске, упало X, разберитесь без него». Никаких разговоров с героем в slack-личке. Если получилось — поднимаем планку (более сложный сценарий). Если нет — пишем post-mortem на саму невозможность справиться и закрываем gap-ы.
5. Перепроектируйте observability под кратность
Если герой смотрит в систему не теми же дашбордами, что остальные — это знак, что дашборды плохие. Сделайте observability одинаковой для всех. Любой инженер должен видеть то же, что видит герой, в первые 30 секунд инцидента.
Главное
Героизм во время инцидентов — это симптом, а не достижение. Лучшая SRE-команда — та, где любой из дежурных может починить почти любой инцидент за разумное время, потому что система познаваема и наблюдаема. Герой в такой команде есть — но он используется как редкий резерв, а не как первый и единственный инструмент.