Технический долг: что это и почему сайт и системы со временем дорожают в поддержке

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

Что такое технический долг простыми словами

Технический долг похож на кредит: вы экономите время сейчас, а потом платите проценты в виде лишних часов на каждую доработку. Метафору придумал программист Уорд Каннингем в 1992 году. В докладе на конференции OOPSLA он написал, что выпустить первую, ещё сырую версию кода похоже на то, чтобы взять в долг. Немного долга ускоряет работу, если его быстро вернуть, переписав код. Опасность в том, что долг не возвращают, и тогда каждая минута работы в обход неудачного кода становится процентами по нему.

Мартин Фаулер, автор известных книг о проектировании программ, объясняет это на примере. Допустим, новая функция при понятном устройстве системы заняла бы 4 дня, а из-за путаницы в коде занимает 6. Два лишних дня это проценты. Расчистка путаницы стоит 5 дней: это возврат основной суммы. Ради одной функции расчищать невыгодно, а если таких функций впереди три, расчистка окупается.

Финансовый долг	Технический долг	Как это выглядит в малом бизнесе
Основная сумма	Работа, которую отложили: обновление, тесты, документация, переделка	Сайт пять лет не обновляли, «потом опишем, как устроена интеграция»
Проценты	Лишние часы на каждую правку в этой части системы	Поменять поле в форме заявки стоит как новая страница
Просрочка	Сбой или уязвимость, которую уже нельзя отложить	Хостинг отключает старую версию PHP, и сайт перестаёт открываться
Рефинансирование	Плановая расчистка или замена модуля	Переписать модуль заказов, не трогая остальное

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

Признаки технического долга на сайте и во внутренних системах

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

• Простые правки стали дорогими. Добавить поле в форму или новый статус в CRM оценивают в несколько дней, хотя раньше это делали за час.
• Одно чинят, другое ломается. После исправления корзины перестаёт приходить письмо о заказе.
• Подрядчик боится обновлять. «Лучше не трогать, всё развалится» звучит при каждом вопросе про обновление движка или модулей.
• Систему знает один человек. Без конкретного программиста никто не может сказать, где лежит код и как работает обмен с 1С.
• Нет описания и доступов. Пароли от хостинга, домена и репозитория у подрядчика, а не у компании.
• Данные сверяют руками. Сотрудники каждый день проверяют, все ли заявки дошли, потому что интеграция иногда теряет записи.
• Сроки и оценки растут. Каждая следующая доработка по похожей задаче оценивается дольше предыдущей.

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

Откуда берётся долг: четыре вида по Мартину Фаулеру

Долг бывает осознанным и случайным, разумным и безрассудным. Так его разделил Мартин Фаулер в заметке о «квадранте технического долга» 2009 года. Две оси дают четыре вида, и с каждым нужно обращаться по-своему.

Вид	Как звучит	Пример в небольшой компании	Что делать
Разумный осознанный	«Запускаемся сейчас, переделаем после проверки»	Первая версия кабинета клиента без автоматических тестов, чтобы успеть к сезону	Записать в реестр долга и назначить срок возврата
Безрассудный осознанный	«На архитектуру нет времени»	Каждую новую услугу добавляют копией старой страницы с ручной правкой цен	Остановить рост: договориться, как делать правильно с этого дня
Безрассудный случайный	«А что, так нельзя было?»	Интеграцию собрал знакомый без журнала ошибок, заявки иногда пропадают	Сделать аудит и начать с того, что угрожает деньгам и данным
Разумный случайный	«Теперь мы знаем, как надо было»	Через год работы CRM стало ясно, что сделки и счета надо было разделить	Нормальная часть развития: планировать переделку, когда она окупится

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

Что не считать техническим долгом

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

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

Простой тест: долг это то, что делает будущие изменения медленнее или рискованнее. Если на будущие правки не влияет, это что-то другое.

Чем технический долг грозит бизнесу

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

Риск	Как проявляется	Чем платите
Дорогие доработки	Оценки растут, сроки срываются	Деньги и упущенные запуски
Неподдерживаемые версии	Движок, модули или язык без обновлений безопасности	Взлом, срочное обновление в аврале
Зависимость от одного человека	Только он знает, как всё устроено	Месяцы на разбор, если он уйдёт
Потери данных	Интеграция без журнала теряет заявки	Клиенты и ручная сверка
Невозможность расти	Новую услугу, оплату или кабинет «не встроить»	Переделка вместо доработки

Пример с версиями. По официальной таблице php.net ветка PHP 8.2 получает только исправления безопасности до 31 декабря 2026 года, а версии 8.1 и старше уже не поддерживаются вовсе. Многие сайты малого бизнеса до сих пор работают на старых ветках. Обновление само по себе обычно небольшая работа, но если модули сайта давно не обновляли, оно тянет за собой переделку несовместимых частей. Это и есть накопленные проценты.

Как оценить технический долг без программиста в штате

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

Колонка реестра	Что писать	Пример
Что не так	Человеческим языком, без жаргона	Обмен заказами с 1С не пишет журнал ошибок
Где мешает	Какие задачи из-за этого дольше или опаснее	Каждый сбой ищут вручную по 2–3 часа
Как часто трогаем	Сколько правок в этой части за месяц или квартал	Раз в неделю
Риск	Что будет, если не трогать: потеря данных, взлом, остановка	Потерянные заказы
Цена расчистки	Оценка в часах	16 часов
Решение	Гасим сейчас, по плану или оставляем	Гасим в этом месяце

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

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

Как гасить технический долг по плану

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

1. Стабилизировать. Резервные копии, мониторинг сайта и форм, журнал ошибок интеграций. Сначала перестаём терять данные.
2. Забрать доступы и описать. Домен, хостинг, репозиторий, сервисы на компанию. Короткая карта: какие системы есть и как они связаны.
3. Обновить то, что вышло из поддержки. Версии языка, движка, модулей. На копии, с проверкой основных сценариев.
4. Добавить проверки. Автоматические тесты или хотя бы список ручных проверок для заказа, оплаты и заявки.
5. Расчищать по реестру. Сначала части, которые меняют чаще всего. Каждую доработку в таком месте используют, чтобы заодно навести порядок рядом.

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

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

Как договориться о техдолге с подрядчиком

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

Вопросы, которые стоит задать подрядчику сейчас:

• Какие решения в нашей системе были временными и где они записаны?
• Какие версии движка, языка и модулей у нас стоят и когда у них заканчивается поддержка?
• Что станет самым дорогим через год, если ничего не делать?
• Сможет ли другой программист разобраться в системе по документации без вас?
• Где журнал ошибок интеграций и кто его смотрит?

Что прописать в договоре на поддержку или в техническом задании на новую систему:

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

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

Чек-лист: под контролем ли ваш технический долг

Отметьте то, что у вас уже есть. Чем больше отметок, тем меньше шанс, что долг неожиданно выставит счёт.

Типичные ошибки

• Не признавать долг. «Сайт же работает» звучит до первой аварии. Долг растёт именно тогда, когда его не замечают.
• Гасить всё подряд. Расчищают красивые, но стабильные части, а модуль, который правят каждую неделю, остаётся в прежнем виде.
• Переписывать с нуля без причины. Полгода без доработок, а новая система копит свой долг.
• Наказывать за честность. Если подрядчик за каждый названный долг получает претензию, он перестанет о нём говорить.
• Держать доступы у подрядчика. Смена исполнителя превращается в расследование.
• Обновлять в аварии. Версия вышла из поддержки год назад, а обновление делают в день, когда сайт уже не открывается.