Героизм в SRE: как выявить системную проблему и перестать на неё закрывать глаза
Когда инженер работает 14-часовые смены, чтобы удержать SLO, которого система не способна достичь сама, это не преданность делу. Это сигнал, что система сломана, а команда этого не видит. Google SRE описывает этот паттерн и называет его героизмом; автор материала — Alexander Malmberg.
Краткий ответ
Героизм в SRE — это когда инженер систематически закрывает своим временем и усилиями разрыв между тем, что система обещает, и тем, что она реально умеет. Это маскирует системные проблемы, ведёт к выгоранию и не даёт команде их исправить. Решение — дать системе сломаться и потратить часть error budget на честный сигнал о её состоянии.
Что такое героизм — и почему это не комплимент
Определение простое: героизм возникает, когда есть системный разрыв — между обещанным SLO и реальными возможностями системы, между объёмом работы и capacity команды, между автоматизацией и тем, сколько её нужно держать за руку. Инженер-герой решает заполнить этот разрыв собой.
На первый взгляд это выглядит как ответственность. Команда видит зелёные дашборды, SLO выполняется, тикеты закрыты. Никто не задаёт неудобных вопросов. Герой получает похвалу и peer-бонусы.
Проблема в том, что система при этом остаётся сломанной. Команда не обсуждает реалистичные SLO. Менеджмент не видит, что нужны инвестиции в автоматизацию или capacity. Системные проблемы не исправляются, потому что команда просто не видит, что они есть, а инженер медленно выгорает на рутинной, низкоценной работе — и, по иронии, именно за такую работу не повышают.
Три паттерна, по которым героизм легко распознать
Malmberg описывает три типичных сценария. Они встречаются в разных командах, но механика одна.
Очередь тикетов с невозможным SLO. Команда договорилась: все тикеты закрываются за 24 часа. Поток тикетов такой, что за 8-часовой рабочий день его не обработать. Один инженер начинает работать по 12-16 часов, чтобы SLO держался. Команда видит: SLO выполняется. Никто не поднимает вопрос о том, что arrival rate несовместим с обязательством.
Сервис с недостижимым SLO 99.99%. Сервис архитектурно не способен держать такую доступность: деградирует при нагрузке, alerting настроен с запозданием, release process добавляет риски. Герой каждый день вручную проверяет графики, откатывает плохие канарейки, перезапускает задачи до того, как сработает алерт. Формально SLO выполняется. Реально — только потому что один человек не отходит от мониторинга даже в выходные.
Launch process с ручной работой и нестабильной автоматизацией. Есть давление запускать быстро. Есть процесс, полный ручных шагов и автоматизации, которую нужно постоянно направлять. Герой работает 12-часовые дни перед запуском и держит руку на пульсе автоматизации всё воскресенье, чтобы в понедельник всё было готово.
Во всех трёх случаях система кажется работающей. Но это иллюзия, которую поддерживает один человек.
Почему героизм так трудно остановить
Здесь есть несколько ловушек, которые делают героизм психологически привлекательным.
Во-первых, это низкорисковая работа. Герой точно знает, что справится: задача понятна, результат предсказуем. Для человека с синдромом самозванца это особенно соблазнительно — делать то, в чём уверен.
Во-вторых, вознаграждение немедленное. Тикет закрыт, коллеги благодарны, прилетает peer-бонус. Долгосрочные последствия — выгорание, стагнация в росте, нерешённые системные проблемы — не видны здесь и сейчас.
В-третьих, это ощущается как правильное поведение. Разве не должны мы глубоко заботиться о системах, которые эксплуатируем? Граница между ответственностью и героизмом размыта, и именно поэтому её важно проговаривать явно.
Как это влияет на команду и бизнес
Для системы героизм означает, что проблемы никогда не доходят до поверхности. Команда не обсуждает реалистичные SLO, не инвестирует в долгосрочные исправления, не улучшает мониторинг и автоматизацию. Система остаётся сломанной, просто этого не видно.
Для команды героизм формирует нездоровые ожидания: что нормально работать сверхурочно, что нормально отвечать в выходные, что нормально поддерживать SLO любой ценой. Эти ожидания распространяются и на других членов команды.
Для инженера итог предсказуем: выгорание. Огромный объём рутинной, низкоценной работы не конвертируется в рост или повышение. Человек тратит лучшее время на тушение пожаров вместо работы над системными улучшениями.
Для бизнеса это означает скрытые риски: возможные проблемы с удержанием людей и инфраструктуру, которая держится на одном человеке. Системные проблемы при этом остаются нерешёнными — потому что их просто не видно, пока герой на месте.
Что делать: дать системе сломаться
Malmberg предлагает контринтуитивный, но логичный путь: дать системе сломаться.
Это звучит страшно, но обычно последствия не такие катастрофические, как кажется герою. Часто оказывается, что свойство, которое герой поддерживает, команда уже давно решила не поддерживать — просто никто не сказал об этом явно. Или что SLO был установлен без реального понимания возможностей системы.
Если у команды есть SLO, значит, есть и error budget. Потратить часть бюджета на то, чтобы получить честный сигнал о состоянии системы, — это разумная инвестиция. Сигнал о том, что система сломана, ценен. Он запускает правильные разговоры: о реалистичных SLO, о нужных инвестициях, о том, что действительно важно.
Параллельно важно помочь инженеру-герою переключиться. Как правило, у него очень хорошее понимание болевых точек системы и сырые идеи о том, как их исправить. Задача лида — направить эту энергию в долгосрочные улучшения: автоматизацию, улучшение alerting, пересмотр SLO, работу с архитектурными ограничениями.
On-call, сделанный правильно, не требует постоянного героизма. Firefighting со структурированным подходом и реалистичными ожиданиями — тоже не героизм.
Чеклист для самодиагностики
Несколько вопросов, которые помогут понять, есть ли в команде героизм:
- Есть ли инженер, который регулярно работает сверхурочно или в выходные, чтобы держать SLO?
- Если этот человек уйдёт в отпуск, что произойдёт с SLO или очередью тикетов?
- Когда команда последний раз обсуждала, реалистичны ли текущие SLO с учётом архитектуры и capacity?
- Есть ли автоматизация, которую нужно постоянно «держать за руку»?
- Получает ли кто-то регулярную похвалу за работу, которую система должна делать сама?
Если хотя бы на два вопроса ответ «да» — стоит провести честный разговор о том, что именно маскирует героизм.
Почему это важно для инженерных лидеров
Героизм — сигнал о системном разрыве, который лидер не видит или предпочитает не замечать. Пока герой держит SLO, нет давления исправлять архитектуру, пересматривать обязательства или инвестировать в автоматизацию.
Похоже, команды, которые годами держат надёжность на одном инженере, рискуют не заметить, что система не готова работать без него. Это риск для выгорания самого инженера и для его удержания в команде — оба эффекта прямо описаны в разборе Google SRE.
Работа лида — сделать героизм ненужным: через реалистичные SLO, честный разговор о capacity, инвестиции в автоматизацию и культуру, где «дать системе сломаться» — инструмент диагностики, а не провал.
FAQ
Чем героизм отличается от нормального on-call?
On-call — это структурированная ответственность с чёткими ожиданиями, ротацией и реалистичными SLO. Героизм — это когда один человек систематически перекрывает разрыв между тем, что система обещает, и тем, что она умеет, за счёт своего личного времени. Правильно выстроенный on-call не требует постоянного героизма.
Бывает ли героизм оправданным?
Да. При крупном инциденте, неожиданном сбое или ситуации, которую команда не предвидела, краткосрочный героизм уместен и ценен. Проблема возникает, когда героизм становится плановым — когда на него рассчитывают как на постоянный механизм поддержания SLO.
Как объяснить инженеру-герою, что его поведение вредит команде?
Malmberg рекомендует объяснить три уровня вреда: для самого инженера (выгорание, отсутствие роста), для команды (нереалистичные ожидания) и для системы (проблемы не исправляются). Важно помочь найти альтернативу: направить понимание болевых точек в работу над долгосрочными улучшениями.
Как понять, что SLO нереалистичен?
Если его выполнение требует постоянного ручного вмешательства или сверхурочной работы, SLO, скорее всего, не соответствует реальным возможностям системы. Честный способ проверить — убрать ручное вмешательство и посмотреть, что произойдёт. Потраченный error budget в этом случае — это инвестиция в понимание реального состояния системы.
Что делать, если менеджмент требует держать SLO любой ценой?
Это разговор о скрытых затратах. Героизм не бесплатен: он стоит выгорания инженеров, retention-рисков и нерешённых системных проблем. Задача лида — сделать эти затраты видимыми и предложить альтернативу: пересмотр SLO, инвестиции в автоматизацию или увеличение capacity.