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

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

И, что самое смешное, это работает.

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

Именно в этом месте инфраструктура обычно начинает свою маленькую тихую месть.

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

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

С инфраструктурой происходит ровно то же самое.

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

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

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

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

С инфраструктурой примерно так же. Один «временный» сервер. Один «временный» скрипт. Один «временный» способ хранения бэкапов. Один «временный» ручной контроль. И однажды выясняется, что весь проект стоит на временных решениях, которым уже несколько лет.

Это очень точная формулировка. Не медленно, не сломано, не аварийно — страшно!

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

Она должна вызывать скуку.

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

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

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

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

Вот несколько известных примеров.

И самое интересное в этих историях даже не масштаб потерь.

Во всех трёх случаях проблема долго считалась терпимой. Система работала. Команда знала её ограничения. Бизнес привык жить внутри этих ограничений.

А потом наступил момент, когда цена старых компромиссов резко выросла.

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

Иногда после такого разбора оказывается, что инфраструктуру вообще не нужно радикально менять — достаточно убрать пару слабых мест, перераспределить нагрузку или подготовить систему к росту. А иногда становится понятно, что дальше тянуть уже дороже, чем пересобрать всё нормально.

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

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