На прошлой неделе за 4 дня мы выкатили 3 срочных релиза. Бизнес просил быстрее, мы ускорялись. К вечеру четверга все вроде бы работало, а в пятницу утром мы обнаружили, что в продакшен ушел захардкоженный токен от стороннего API.

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

Механика инженерной усталости

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

На втором срочном релизе драйв уходит. Остается чистая механика. Люди еще следят за качеством, но уже пропускают долгие проверки. Если линтер ругается на стиль кода, правило просто отключают до лучших времен.

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

Короткие решения

Самое опасное в режиме вечного аврала – это привыкание к коротким решениям. Сначала ты один раз собираешь проект в обход CI/CD пайплайна, потому что так на десять минут быстрее. Система выдерживает. На следующий день ты делаешь это снова, потому что прецедент уже создан.

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

Конец режима героизма

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

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

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