Технический долг сайта: когда поддерживать старую систему уже дороже, чем пересобрать
Технический долг — не синоним старого кода. Это состояние, при котором прежние решения увеличивают стоимость или риск будущих изменений. Для бизнеса долг становится существенным, когда замедляет выпуск функций, вызывает повторяющиеся инциденты, мешает обновлять компоненты или делает систему зависимой от одного человека.
Решение о пересборке нельзя принимать по возрасту сайта и количеству замечаний разработчика. Нужно сравнить будущую стоимость сохранения, рефакторинга и замены, а также отдельно оценить миграционный риск.
Как технический долг проявляется в бизнесе
Самый заметный симптом — «налог на изменение». Простая задача требует долгого исследования, затрагивает несвязанные модули, проходит через ручной выпуск и возвращается исправлением регрессий. В результате дорожает не только разработка: маркетинг позднее запускает кампании, сотрудники продолжают ручной процесс, а бизнес откладывает новые продукты.
Соберите наблюдения за одинаковый период:
- время от постановки типовой задачи до выпуска;
- долю времени на исследование и исправление последствий;
- повторяющиеся инциденты и простой;
- отложенные обновления;
- задачи roadmap, заблокированные архитектурой;
- часы поддержки и аварийных работ;
- зависимость от конкретного подрядчика;
- возможность восстановить систему и повторить выпуск.
Не превращайте один неудобный модуль в диагноз всей системе. Долг может быть локальным, и тогда изолированный рефакторинг разумнее полной замены.
Что проверить в технологическом стеке
Создайте инвентаризацию операционной системы, web-сервера, CMS, runtime, базы, плагинов, библиотек, сборки и внешних API. Для каждого компонента укажите версию, статус поддержки, известный путь обновления и ответственного.
OWASP Top 10:2025 называет риском отсутствие контроля версий прямых и транзитивных зависимостей, а также использование неподдерживаемого или устаревшего ПО. Это основание для проверки и плана обновления, но не доказательство, что конкретный сайт уже взломан.
Для PHP даты поддержки опубликованы в официальном lifecycle. Такой источник позволяет отличить проверяемый риск от общей фразы «старый стек». Аналогично проверяются CMS, плагины и серверные компоненты.
Технические вопросы аудита:
- можно ли обновить основу без переписывания продукта;
- какие зависимости блокируют обновление;
- известны ли все внешние сервисы и ключи;
- есть ли компоненты без владельца;
- отделены ли данные от интерфейса;
- можно ли заменить проблемный модуль постепенно;
- существует ли экспорт и проверка целостности данных.
Что проверить в процессе разработки
Даже современный стек быстро создаёт новый долг, если выпуск не воспроизводится. Проверьте не наличие модных инструментов, а способность команды безопасно изменить и восстановить систему.
| Зона | Управляемое состояние | Рискованное состояние |
|---|---|---|
| Репозиторий | код и конфигурация версионируются | production содержит ручные правки |
| Окружения | есть сопоставимый staging | проверка начинается на боевом сайте |
| Выпуск | шаги повторяемы и документированы | процесс знает один человек |
| Тесты | критические пути проверяются | любое изменение принимается визуально |
| Резервирование | восстановление проверено | backup существует только формально |
| Наблюдаемость | ошибки и интеграции дают сигнал | о сбое сообщает клиент |
| Документация | архитектура и API актуальны | знания хранятся в переписке |
Отсутствие автотестов не всегда требует пересборки. Для небольшого стабильного сайта может быть достаточно воспроизводимого чек-листа. Но критические формы, оплаты и обмены должны проверяться способом, соответствующим их риску.
Посчитайте стоимость сохранения системы
Для выбранного горизонта сложите подтверждённые и оценочные части отдельно:
TCO сохранения = поддержка + инциденты + обязательные обновления + дополнительная стоимость изменений + стоимость зависимости + измеримая цена задержек
Не каждую часть можно точно перевести в деньги. В таком случае сохраните диапазон и допущение, а не ставьте удобную цифру. Например, стоимость простоя можно оценить только при наличии данных о продажах и длительности инцидента.
CMU Software Engineering Institute описывает технический долг через компромиссы, будущие изменения и экономические последствия: Technical Debt: From Metaphor to Theory and Practice. Эта модель помогает говорить о долге как о портфеле конкретных решений, а не как об общем качестве разработчиков.
Посчитайте стоимость рефакторинга и пересборки
Рефакторинг включает аудит, обновление основы, изоляцию модулей, тесты, документацию и постепенный выпуск. Пересборка включает аналитику, новую архитектуру, разработку, перенос данных и контента, интеграции, QA, SEO-миграцию, параллельную работу систем, обучение и стабилизацию.
TCO пересборки = исследование + разработка + миграция + QA + инфраструктура + параллельный режим + SEO-перенос + стабилизация
Не сравнивайте год поддержки со стоимостью «чистой разработки» без миграции. Это разные scopes. Подробный выбор между вариантами разобран в статье «Дорабатывать старый сайт или делать новый».
Матрица состояния без фиктивных баллов
Это качественная модель BTD.TEAM, а не отраслевой стандарт. Оценивайте каждую зону по наблюдаемым признакам: «устойчиво», «требует внимания» или «критично». Цвет помогает быстрее различать состояния, но не заменяет подписи и не складывается в псевдоточный итоговый рейтинг.
| Зона | Устойчиво | Требует внимания | Критично |
|---|---|---|---|
| Поддержка | компоненты поддерживаются | часть близка к EOL | критическая основа не поддерживается |
| Изменения | срок предсказуем | задачи заметно замедляются | простое изменение требует исследования всей системы |
| Релизы | повторяемы | есть ручные участки | выпуск зависит от одного человека |
| Тестирование | критические пути покрыты | проверка частичная | любое изменение несёт высокий риск |
| Документация | актуальна | фрагментарна | архитектуру знает только подрядчик |
| Безопасность | обновления регулярны | есть backlog | обновление невозможно без поломки основы |
| Архитектура | изменения локальны | связи усложняют работу | почти всё затрагивает всё |
| Бизнес | roadmap выполним | накапливаются задержки | технология блокирует основные планы |
Один красный участок может требовать локального срочного решения, но не всей пересборки. Несколько взаимосвязанных красных зон делают замену сильным кандидатом для расчёта.
Когда пересборка становится рациональной
Серьёзно рассматривайте замену, если одновременно:
- ограничения затрагивают большинство будущих задач;
- обязательное обновление фактически требует переписать основу;
- стоимость и риск изменений устойчиво растут;
- данные и интеграции можно перенести контролируемо;
- бизнес способен профинансировать параллельную миграцию;
- SEO и продажи защищены отдельным планом;
- новый проект содержит правила, которые не дадут повторить тот же долг.
Даже при этих признаках сравните поэтапную модернизацию. Для транзакционной системы «большой взрыв» может быть опаснее постепенной замены модулей.
Когда старую систему лучше оставить
Legacy может быть стабильным, документированным и почти неизменяемым. Если он выполняет задачу, поддерживается в изолированном контуре и не создаёт неприемлемого риска, пересборка может не окупиться. Иногда разумнее обновить один компонент, добавить резервирование или вынести интеграцию.
Не используйте sunk cost — уже потраченные деньги — как аргумент продолжать любой путь. Но и не списывайте работающий актив ради ощущения современности.
Решение должно закончиться планом
Аудит формирует реестр: конкретный элемент долга, бизнес-последствие, доказательство, вариант действия, стоимость, риск и владелец. Затем элементы распределяются между поддержанием, снижением, устранением и осознанным принятием.
Если выбрана пересборка, следующим документом становится план миграции SEO, аналитики и заявок. Для оценки текущей системы на данных можно обсудить технический аудит с BTD.TEAM.
