Техдолг и бизнес: разбор инцидента и переговоров

Во время рекламной кампании сервис оформления заказа начал отвечать за 4,8 секунды вместо привычных 220 миллисекунд, а доля ответов 502 достигла 7,4%. Команда знала о проблемном запросе к базе несколько месяцев, но не могла договориться с бизнесом о двух неделях на исправление: приоритетом считался новый функционал. Ниже — анонимизированный разбор такого инцидента: какие цифры принесли на переговоры, почему аргумент «нам нужен рефакторинг» не сработал и как связать техдолг с деньгами и риском.

Что произошло перед инцидентом

Сценарий относится к интернет-магазину на Django 5.0, PostgreSQL 16 и Nginx. Версии важны: конкретные настройки пула соединений, мониторинга и ORM могут отличаться в других стеках, но логика разбора сохраняется.

За несколько месяцев в сервис добавили три функции: промокоды, проверку остатков в нескольких складах и расчёт доставки. Каждая функция проходила тестирование отдельно. В боевом запросе оформления заказа они последовательно обращались к одним и тем же таблицам, а часть данных загружалась повторно. На обычном трафике проблема маскировалась короткими очередями.

Накануне кампании команда зафиксировала следующие показатели в тестовом окружении, максимально близком к боевому:

• 95-й перцентиль времени ответа — 230 мс при 20 запросах в секунду;
• 95-й перцентиль — 3,9 секунды при 80 запросах в секунду;
• пул соединений PostgreSQL заполнялся полностью;
• часть запросов к таблице остатков ждала блокировки дольше секунды.

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

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

Как техническая проблема превратилась в бизнес-риск

Цепочка отказа

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

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

Технический долг¹ здесь состоял не в одном «плохом месте», а в накопленном ограничении архитектуры: новые правила добавлялись в длинную транзакцию без проверки её поведения при параллельном доступе.

Цена для бизнеса складывалась из нескольких частей:

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

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

Какие данные принести на переговоры

Первая ошибка команды была в формулировке: «Нам нужно две недели на рефакторинг». Бизнес слышит срок, но не понимает, что изменится. Рабочий разговор начался после того, как команда заменила требование на проверяемую гипотезу: «За пять рабочих дней снизим p95 оформления заказа ниже 500 мс при 80 запросах в секунду, затем отдельно решим вопрос с дальнейшим ростом».

Перед встречей стоит собрать короткий пакет фактов:

1. Текущая граница. Укажите нагрузку, при которой p95 пересекает допустимый порог, и условия замера: размер базы, тип сервера, число параллельных запросов.
2. Повторяемость. Покажите график или результаты двух-трёх одинаковых прогонов. Один медленный запрос ещё не доказывает системную проблему.
3. Связь с пользовательским сценарием. Переведите «запрос держит блокировку» в «оформление заказа ждёт и может завершиться ошибкой».
4. Цена вариантов. Для каждого решения назовите срок, что оно снижает и чего не решает.
5. Критерий остановки. Зафиксируйте метрику, после которой команда прекращает эксперимент и возвращается к безопасному режиму.

Удобная формула для встречи выглядит так: «При X запросах в секунду получаем Y миллисекунд и Z ошибок. Кампания может дать нагрузку выше X. Предлагаем потратить N дней, чтобы проверить решение, и считаем его успешным при таком-то результате».

Четыре варианта решения и их цена

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

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

Что говорить, если бизнес просит только новую функцию

Нельзя продавать техдолг как моральную обязанность «сделать правильно». У бизнеса есть право спросить, почему работа нужна именно сейчас. Ответ должен опираться на последствия.

Вместо «код трудно поддерживать»

Скажите: «Изменение скидок сейчас затрагивает проверку остатков и расчёт доставки. По последним трём задачам тестирование занимало по два дня, потому что один сценарий ломал другой. Если оставить структуру как есть, следующая функция потребует такого же дополнительного времени».

Вместо «нам нужен рефакторинг»

Скажите: «При 80 запросах в секунду p95 уже 3,9 секунды, а при полном пуле соединений появляются 502. Нам нужно либо снизить нагрузку на этот участок, либо принять риск остановки оформления заказа во время кампании».

Вместо «это займёт две недели»

Разделите работу на этапы: диагностика, безопасный патч, нагрузочный тест, наблюдение после релиза. Для каждого этапа укажите результат. Если через два дня гипотеза не подтверждается, команда не продолжает работу вслепую, а возвращается к плану.

Что ломается первым после согласования

Даже одобренная работа может не дать эффекта, если команда измеряет не тот показатель или меняет слишком много компонентов одновременно.

• Снижение среднего времени вместо p95. Среднее может выглядеть нормально, пока часть пользователей ждёт секунды. Для пользовательского сценария смотрите p95 или p99 и долю ошибок.
• Нагрузочный тест без боевых данных. Пустая база и маленькие таблицы не показывают поведение индексов и блокировок. Объём данных и распределение запросов должны быть близки к рабочим.
• Оптимизация одного запроса без проверки транзакции. Быстрый SQL не поможет, если соединение всё равно занято внешним вызовом.
• Релиз без плана отката. Исправление техдолга часто меняет порядок операций. До выката определите, как вернуть предыдущую версию и как проверить незавершённые заказы.
• Обещание «теперь проблема решена навсегда». После патча нужно заново измерить предел нагрузки. Запас производительности не равен гарантии для любого будущего трафика.

Как проверить результат после релиза

В рассматриваемом сценарии проверка должна идти в три слоя. Сначала — автоматический тест параллельного оформления заказов с теми же ограничениями базы. Затем — короткий нагрузочный прогон с постепенным увеличением трафика. После релиза — наблюдение за p95, p99, долей 5xx, временем ожидания соединения и длительностью транзакций.

Сравнивать нужно одинаковые условия: одну версию базы, одинаковый объём данных, одинаковое число виртуальных пользователей и одинаковый набор операций. Иначе «после» может оказаться быстрее только потому, что тест стал легче.

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

Что делать дальше

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

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

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