Парадокс предотвращенного пожара: почему инженеру в бигтехе выгодно, чтобы прод упал

Вступление

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

Это человек, который приходит не просто «закрывать задачи». Он хочет делать лучше. Видит рутину — автоматизирует. Видит хаос в процессах — предлагает порядок. Видит проблемы в мониторинге — строит графики. Видит, что команда тонет в ручной работе, — пишет внутренний инструмент.

На собеседовании такие люди звучат как мечта любого менеджера.

• «Проактивный».
• «Неравнодушный».
• «Берёт ответственность».
• «Думает шире своей зоны».

А потом этот человек попадает в большую компанию. Например, в большой модный и молодёжный банк. Вокруг микросервисы, Kafka, Kubernetes, внутренние платформы, ИИ-боты, красивые презентации, agile, OKR и прочий корпоративный технопарк.

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

Синдром неофита

Первые месяцы Лёша смотрит на всё свежим взглядом.

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

На первый взгляд всё прекрасно. Команда довольна. Рутинной работы стало меньше. Где-то сэкономили часы. Где-то быстрее нашли проблему. Где-то перестали будить трёх человек ночью.

Лёша счастлив. Он думает, что делает компанию лучше. Но большая компания смотрит на это иначе. Для неё любая инициатива — это не подарок. Это объект, который нужно классифицировать, согласовать, положить в правильный контур, назначить владельца, описать риски, определить поддержку, вписать в роадмап, провести через безопасность, архитектуру, комплаенс и ещё пару комитетов, о существовании которых Лёша узнает только после того, как уже всё написал.

Лёша сделал крутую вещь X. И сразу появляются вопросы:

• Кто её будет поддерживать?
• Кто будет добавлять новые фичи?
• Кто будет чинить её, когда Лёша уйдёт в отпуск?
• Кто согласовал доступы?
• Где документация?
• Почему это не через платформенную команду?
• Почему это не в квартальном плане?
• Почему это вообще существует?

Лёша думал, что принёс пользу. Система увидела инородный объект.

Иммунная система корпорации

У большой компании есть своя иммунная система. Любая инициатива для бигтеха — это чужеродный объект. Почти вирус. Неважно, насколько она полезна. Система не умеет радоваться автоматизации. Система умеет защищать свой покой. Архитекторы, безопасники, комплаенс, комитеты по рискам, владельцы платформ, внутренние процессы — это корпоративные лейкоциты. Их задача не всегда в том, чтобы сделать продукт лучше. Их задача часто звучит проще: сделать так, чтобы ничего не изменилось без подписи нужного человека в нужной системе.

Лёша думает, что он лечит компанию. А компания думает, что она от Лёши защищается.

И тут важно не скатиться в простую мысль «все вокруг идиоты». Нет, не все. Процессы в больших компаниях появились не просто так. Безопасность не просто так задаёт вопросы. Архитекторы не просто так требуют согласований. Комплаенс не просто так существует.

Проблема в другом.

Большая компания плохо переваривает инициативу, если у неё нет заранее подготовленного места в системе. Если идея не привязана к бюджету, владельцу, команде, SLA, поддержке и роадмапу, она превращается не в улучшение, а в организационную проблему.

Особенно если технически это хорошая вещь. Потому что хорошей вещью начнут пользоваться коллеги. А если ей начнут пользоваться, её придётся поддерживать. А если её придётся поддерживать, нужно понять, чья это ответственность. А если ответственность ничья, значит, виноват будет тот, кто это написал. То есть Лёша.

Семь кругов согласования

Представим, что Лёша написал внутренний сервис, который экономит команде десятки часов в месяц. Сервис простой. Польза очевидная. Команда пользуется. Все довольны.

Потом об этом узнаёт соседняя команда. Потом ещё одна. Потом кто-то спрашивает: «А можно нам тоже?». И вот локальная полезная штука превращается в корпоративный продукт. Только продукт без команды. Без владельца. Без бюджета. Без поддержки. Без документации уровня «чтобы понял человек, который впервые открыл Confluence после отпуска».

С этого момента у Лёши есть два сценария.

• Первый — бизнес действительно увидит ценность, выделит ресурс, создаст команду или хотя бы официально закрепит владельца. Так бывает. Иногда.
• Второй сценарий встречается чаще. У Лёши заберут его создание и отдадут другой команде. Например, платформенной. Или внутренней разработке. Или команде, которая «в целом занимается похожими вещами».

Эта команда может быть хорошей. Там могут быть сильные инженеры. Но они не жили в проблеме, которую решал Лёша. Они не понимают контекст, не чувствуют боль пользователей, не знают, почему решение сделано именно так.

И начинается классика. Сначала тулзу «перенесут на правильную платформу». Потом «переосмыслят архитектуру». Потом «добавят в бэклог». Потом «запланируют Discovery». Потом «приоритизируют после более срочных задач».

А через полгода пользователи снова делают всё руками, потому что старая версия уже запрещена, а новая ещё не родилась. Лёша стоит рядом и смотрит, как его идея медленно умирает в Jira.

Синдром бесплатного грейда

Но есть и другой путь.

Лёша может решить: ладно, с тулзой сложно, зато я могу помогать команде здесь и сейчас.

Он разработчик, но начинает брать на себя SRE-направление. Строит графики. Настраивает алерты. Следит за дежурствами. Разбирает инциденты. Подсвечивает проблемы. Чинит перформанс. Помогает QA. Подключается к нагрузочному тестированию. Лезет во фронт, когда фронтендеры перегружены. Консультирует соседние команды.

Команда выдыхает. Проблем становится меньше. Менеджмент доволен. На ретро звучит что-то вроде:

«Команда хорошо поработала, молодцы».

И вот здесь начинается магия корпорации. Лёша делает работу за разработчика, SRE, DevOps, QA, аналитика и иногда техлида. Но формально он остаётся разработчиком. И самое главное — он им и останется.

Потому что проблема не в том, сколько зон ответственности забрал на себя Лёша. Он может работать хоть за пятерых. Проблема в том, что для Лёши в системе нет места.

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

И если он добровольно делает работу ещё трёх направлений, система не скажет:

«Ого, давай повысим его до Principal и дадим зарплату x3».

Система скажет:

«О, класс, у нас закрыты четыре дыры по цене одной штатной единицы. Пиши это в KPI на следующий год».

Это и есть синдром бесплатного грейда. Инициатива в корпорации очень легко превращается в легальный способ самоэксплуатации. Ты сам даришь компании свои вечера, нервы, выходные и овертаймы, надеясь на рыночную справедливость.

Но в матричной структуре рыночная справедливость не живёт. Там живут грейдовые комитеты, калибровки, бюджеты, performance review и фраза:

«Вклад хороший, но для следующего уровня пока не хватает системного влияния».

Системного влияния. У человека, который полгода держит на себе половину инженерной инфраструктуры команды.

Парадокс предотвращённого пожара

Самая циничная часть истории начинается там, где Лёша действительно становится полезным.

Он заранее видит, что сервис деградирует. Ночью чинит прод. Пишет алерты. Разбирает причины лагов. Подкручивает конфиги. Пинает смежников. Пишет в чаты. Собирает людей. Предотвращает инцидент.

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

И вот тут возникает парадокс предотвращённого пожара.

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

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

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

Пока Лёша молча чинит всё ночами, он не решает системную проблему. Он помогает ей дольше не попадать в отчёты.

Многостаночник на окладе

Через какое-то время Лёша начинает жить в странном режиме. Днём он закрывает свои обычные задачи. Вечером разбирает чужие проблемы. Ночью смотрит графики. На планировании ему добавляют новые фичи. На ретро говорят, что команда перегружена, но «надо потерпеть». В личке менеджер осторожно намекает:

«Слушай, ты очень много помогаешь по инфраструктуре, это круто. Но по основным задачам разработки хотелось бы чуть больше предсказуемости».

И это финальный удар. Потому что система сначала с удовольствием съела дополнительную инициативу Лёши, а потом оценила его по старой роли.

• Ты взял на себя SRE? Молодец.
• Ты помогаешь QA? Спасибо.
• Ты строишь дашборды? Полезно.
• Ты тушишь инциденты? Команда ценит.

А теперь давай вернёмся к твоим story points.

• Почему задача по основному бэклогу не закрыта?
• Почему скорость просела?
• Почему ты не сфокусирован?

Лёша наконец понимает простую вещь: брать чужую зону ответственности без изменения роли, полномочий и компенсации — большая ошибка. Потому что ответственность становится твоей. А признание остаётся ничьим.

День первый и день сто восьмидесятый

В начале всё выглядит почти романтично.

День 1:

«Коллеги, я написал скрипт, который экономит нам 40 часов регресса!»

Команда радуется. В чате огоньки. Кто-то пишет «легенда». Кто-то просит добавить ещё одну фичу. Лёша чувствует, что попал туда, где можно делать настоящие улучшения.

День 180:

«Заполните форму Feature Request в канале public, я посмотрю в июне-июле, если будет капасити».

Это уже говорит сам Лёша. Не потому что он стал плохим. Не потому что он зазвездился. Не потому что перестал любить инженерку. Просто он адаптировался.

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

Великое молчание

В какой-то момент Лёша перестаёт спорить.

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

Теперь он просто кивает.

• Нужно сделать фичу поверх нестабильного сервиса? Хорошо.
• Нет времени на рефакторинг? Понял.
• Нагрузочное тестирование потом? Окей.
• Алерты шумят? Выключим.
• Техдолг не в приоритете? Принято.

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

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

Начинается паника. Собираются созвоны. Появляются срочные инициативы. Выделяются ставки. Создаётся рабочая группа. Находится бюджет.

Внезапно оказывается, что компании нужны SRE-инженеры, платформа, автоматизация, владельцы процессов и время на технический долг. То есть всё то, что Лёша полгода делал один и бесплатно. Лёша смотрит на это, закрывает ноутбук и обновляет резюме.

Кладбище инициатив

Бигтех — это не всегда место, где нет умных людей.

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

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

В результате бигтех становится кладбищем инициатив. Там лежат внутренние инструменты, которые могли экономить сотни часов. Дашборды, которыми пользовались все, пока их не запретили из-за отсутствия владельца. Скрипты, которые решали реальные проблемы, но не прошли семь кругов согласования. Процессы, которые работали, пока их не решили «нормализовать». И люди, которые когда-то хотели делать лучше, а потом научились не высовываться.

Заключение

Самый простой вывод звучит мрачно: не проявлять инициативу.

Но это неправильный вывод.

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

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

Инициатива без владельца превращается в личный долг. Дополнительная ответственность без изменения роли превращается в бесплатный грейд. Героизм без видимости превращается в норму. А инженер, который постоянно спасает систему молча, однажды обнаруживает, что система считает это его обычной работой.

Поэтому инициатива должна иметь цену.

Не в смысле «за каждое движение требовать денег». А в смысле честно обозначать: вот работа, вот эффект, вот риски, вот поддержка, вот время, вот ответственность. Если компания хочет этим пользоваться, это должно стать частью системы, а не очередной ночной подвиг одного энтузиаста.

Лёша не обязан быть корпоративным донором энергии. Он может быть сильным инженером, который делает полезные вещи. Но даже сильный инженер должен понимать границы. Потому что большая компания почти никогда не скажет:

«Стоп, ты слишком много на себя взял, давай мы тебя защитим».

Скорее она скажет:

«Классная инициатива. Можешь ещё вот это посмотреть?»