Технический долг инфраструктуры: как понять, что платить по нему пора сейчас

MAATRIX

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

Что такое технический долг инфраструктуры

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

Формы, в которых он копится, обычно узнаваемы:

• «Временные» решения, которые стали постоянными. Скрипт, который кто-то написал за вечер, чтобы закрыть срочную проблему, три года спустя — единственный механизм, который держит на себе критичный процесс. Никто не помнит, почему он вообще появился, но выключить страшно.
• Устаревшие компоненты. ОС без вендорской поддержки, СУБД на ветке, которую больше не патчат, зависимости с открытыми CVE, для закрытия которых нужна мажорная миграция, а не апдейт минорной версии.
• Недокументированные части системы. Cron, назначение которого никто не может объяснить. Правило в nginx.conf, которое боятся трогать, потому что неизвестно, что сломается. Firewall-политика, написанная человеком, который уволился два года назад.
• Ручные процессы там, где должна быть автоматизация. Деплой «по SSH и молитве», бэкапы, которые кто-то должен не забыть запустить руками, конфиги, которые правят на живом сервере без версионирования.
• Архитектурные решения под другую нагрузку. Один сервер, который был рассчитан на сотню пользователей, а держит десять тысяч — и каждое масштабирование теперь превращается в операцию с задержкой дыхания.

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

Первый признак: скорость изменений упала непропорционально задаче

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

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

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

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

Второй признак: инциденты повторяются в одних и тех же местах

Разовый инцидент — это случайность или недосмотр. Инцидент, который происходит второй, третий, пятый раз в одном и том же месте системы (пусть и с разными триггерами) — это сигнал, что «заплатка», наложенная после первого случая, не устранила причину, а замаскировала симптом.

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

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

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

Третий признак: команда боится трогать определённые части системы

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

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

• Замедляется онбординг. Новый инженер не может разобраться, что легально трогать, а что нет, потому что это знание нигде не записано — оно живёт в устных предупреждениях старших коллег.
• Растёт bus factor. Систему понимает один-два человека, и это ровно та ситуация, которую стоит разбирать отдельно — она описана в статье про bus factor, равный единице: если единственный человек, который понимает критичный узел, недоступен, изменения вокруг него останавливаются полностью.
• Копится отложенная работа. Всё, что связано со «страшным» компонентом, откладывается на потом, и «потом» превращается в постоянное состояние, а сам компонент продолжает стареть.

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

Как считать стоимость обслуживания долга

Дальше — не эмоциональная оценка «мы измотаны», а более конкретный фрейм. Сравните две стороны.

Стоимость обслуживания долга — то, что вы платите каждый месяц, продолжая жить с текущим состоянием:

• время команды, уходящее на осторожность вокруг хрупких мест (см. первый признак);
• время и репутационные издержки на повторяющиеся инциденты (второй признак);
• издержки от избегания — задачи, которые не берутся или откладываются из-за страха (третий признак);
• эмоциональное выгорание команды от постоянных «пожаров» — оно не отражается напрямую в трекере задач, но напрямую отражается в текучке и в том, кто в итоге откажется дежурить в следующий раз.

Стоимость погашения — то, что нужно заплатить один раз (или несколькими итерациями), чтобы устранить причину:

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

Практическая таблица для быстрой прикидки — не для точных цифр (ориентировочные значения ниже приведены как пример логики, а не как норматив, у вас они будут своими):

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

Как решить, платить сейчас или подождать ещё

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

Практический чек-лист для принятия решения:

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

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

Как гасить долг, не останавливая продакшн

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

Более рабочий подход:

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

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

Частые вопросы