Настоящая цена бага в продакшене

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

Плохое качество ПО обошлось экономике США примерно в 2,41 триллиона долларов только за 2022 год (CISQ). Эта цифра сложена не из сложных фиксов. Она сложена из всего, что вокруг них. Вот полный счёт, почему он растёт со временем и что реально его уменьшает.

Счёт, который вы видите, и счёт, который вы платите

Когда дефект уходит в продакшен, инженерный фикс — одна строка. Остальной счёт выглядит так:

• Инцидент. Кого-то будят пейджером. Разворачивается расследование, отрывая двух-трёх человек от того, что они строили.
• Налог на прерывание. Пожар в продакшене стоит не только времени тех, кто его тушит, — он раскалывает фокус всех втянутых, и глубокая работа не возобновляется мгновенно.
• Спешный фикс. Хотфиксы пропускают обычное ревью и тестирование. Заметная доля вносит второй баг — и вот вы платите дважды.
• Доверие клиента. Пользователь, попавший на сломанный поток, может не завести тикет. Он может просто уйти — а отток самая дорогая строка, потому что появляется не как затрата, а как отсутствие.
• Постмортем и процессный долг. Разбор, новый пункт в чек-листе, ручной шаг, который кто-то теперь гоняет «на всякий случай» перед каждым релизом. Этот шаг становится постоянными накладными.

Почему цена растёт, чем позже поймал

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

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

Охват расширяется. Ушедший в продакшен дефект не стоит на месте. На нём строят другой код. Данные записываются в неверной форме. Размотать его позже — значит размотать всё, что предполагало его корректность.

Радиус влияния растёт. Баг, пойманный в CI, не задевает никого. Тот же баг в продакшене может задеть каждого пользователя, коснувшегося потока до того, как его найдут, — а находит его часто клиент или финансы при сверке, а не вы.

Разбор на примере

Возьмём тот ценовой баг. Рефакторинг объединяет три пути промокодов в один. Юнит-тесты проходят, дифф чистый, всё мёржится. Но процентный купон теперь применяется до налога вместо после, сдвигая итог на части заказов.

Пойман в пул-реквесте: комментарий ревьюера. Цена: минуты. Автор чинит до того, как это стало реальным.

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

Один и тот же однострочный дефект. Разница между двумя счетами — не 10× и не 100×, а разница между комментарием в коде и кросс-функциональной уборкой, втягивающей четыре отдела. Именно на этот механизм и намекают множители.

AI-эпоха всё усугубляет — и делает фикс ценнее

Два сдвига расширяют зазор. Первый: около 40% нового кода теперь генерирует AI, а способность людей к ревью не растёт — так больше изменений доходит до продакшена с меньшим вниманием; это давление мы описываем в статье Почему традиционный QA не поспевает за AI-разработкой. Второй: 15–25% end-to-end тестов флаки, поэтому команды приучаются игнорировать красные сборки — значит, страховочная сетка, которая должна ловить поздние баги, тихо выключена.

Больше изменений, меньше ревью и набор тестов, которому не верят: это формула того, что больше дефектов выживает дольше. Ровно поэтому отдача от раннего отлова никогда не была выше. Каждый баг, который вы переносите из «найден в продакшене» в «найден в пул-реквесте», не просто экономит фикс — он вычёркивает целый счёт.

Что реально уменьшает счёт

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

Сдвигайте обнаружение влево. Самый дешёвый баг — пойманный до мёржа. Тестируйте критические пути end-to-end в CI, а не только юниты в изоляции — стратегия из статьи Shift-left и shift-right.

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

Валидируйте до того, как вас прервут. Набор тестов, кричащий «волки», игнорируют, а игнорируемый набор пропускает поздние баги. Сбои нужно воспроизводить и подтверждать реальными до того, как они кого-то разбудят, — различие между непрерывным тестированием и непрерывным мониторингом.

Итог

Настоящая цена продакшен-бага — это инцидент, прерывание, спешный фикс и доверие, которое не вернуть, и всё это тем сильнее, чем дольше дефект прячется. Рычаг не в том, чтобы чинить быстрее, — а в том, чтобы обнаруживать раньше и покрывать потоки, реально несущие риск.

Именно для этого создан BuniOD: подключите URL или репозиторий — он обнаруживает ваши критические потоки, валидирует их непрерывно и подтверждает реальность сбоев до того, как они дойдут до клиента, — так баги ловятся, пока они ещё комментарий в коде, а не кросс-функциональная уборка.