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

На связи Дмитрий Бессольцев, генеральный директор ALP ITSM. Уже 30 лет наша команда помогает компаниям строить ИТ‑инфраструктуру, которая работает на бизнес: от аудита до настройки процессов поддержки и управляемого развития ИТ.

В статье разбираем:

• как именно формируется технологический долг в трех плоскостях — люди, процессы, технологии;
• чем инженерная оценка «сколько стоит починить» отличается от бизнес‑оценки «сколько стоит не чинить»;
• как считать реальную цену часа/дня простоя и сравнивать сценарии «обновить» и «подождать еще год»;
• и какую управленческую роль играет ИТ‑аудит: когда он помогает CEO, CFO и CIO принимать решения о приоритетах инвестиций, а не остается «технической детализацией».

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

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

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

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

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

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

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

Три источника техдолга: люди, процессы, технологии

Если смотреть по‑взрослому, через ITSM, то у ИТ три слоя: люди, процессы, технологии. И техдолг точно так же накапливается не в одном месте, а сразу в этих трех слоях.

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

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

Люди: когда все держится на одном герое

Частая картина: один ИТ‑специалист тащит на себе поддержку критичных сервисов.Он единственный, кто знает, как устроена система, где лежат бэкапы, как «подкрутить так, чтобы заработало».

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

Параллельно копятся дыры в карте компетенций команды.Нагрузка растет, ИТ‑ландшафт усложняется, появляются новые сервисы, интеграции, требования по безопасности, а команда работает по старой модели "спасаем, что горит, остальное потом".В какой‑то момент вы обнаруживаете, что люди физически не вытягивают объем и сложность задач, но честной инвентаризации компетенций и рисков никто не делал.

Это тоже техдолг: долг по людям и управлению ИТ‑командой.

Процессы: поддержка «как-нибудь в чате»

Второй крупный источник технического долга — это процессы.Чаще всего ИТ‑поддержка стартует «по‑простому»: чаты, звонки, личные сообщения, «пиши Васе, он поможет».

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

• заявки теряются или лежат неделями;
• нет прозрачных приоритетов, все «горит» одновременно;
• никто не отвечает за сроки реакции и восстановления.

Отсутствие формализованных SLA/OLA превращает любой серьезный инцидент в хаос.Бизнес ожидает, что все поднимут «через полчаса», ИТ пытается сделать лучшее в имеющихся условиях, но у сторон нет общих правил игры.

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

Технологии: от тестового сервиса до критичной точки отказа

Третий, наиболее очевидный слой — технологии.

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

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

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

Все эти решения — копилка технологического техдолга.

Когда «временная» CRM останавливает весь опт

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

В 2017‑м это была небольшая оптовая компания: склад 200 м², пара машин, пять человек. Заказы шли по телефону, отгрузки собирали в Excel, документы выбивали в 1С — неудобно, но терпимо. Когда доросли до нескольких десятков клиентов и небольших сетей, завели Bitrix24 «на попробовать», чтобы не терять заявки и хоть как‑то видеть воронку.

Через два года CRM стала нервной системой бизнеса. Через нее проходили входящие заказы, задачи склада и водителей, окна поставки, согласования по ценам и отсрочкам, переписка с ключевыми клиентами. Фактически, если Bitrix не работает, компания не видит заказы, обязательства и текущие операции. Но под всем этим оставался тот же «временный» фундамент: офисный сервер, «какие‑то» бэкапы, самописные интеграции с 1С без документации и без тестового контура.

По деньгам картинка выглядела прилично. В сезон компания делала 1,5–1,9 млн ₽ выручки в месяц, то есть 70–90 тысяч ₽ в день. На этом фоне сервер за 120 тысяч и «потом как‑нибудь перенесем в облако» выглядели разумной экономией.

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

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

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

Если посчитать деньги, получается неприятная арифметика. При дневной выручке 70–90 тысяч ₽ простои и срывы заказов в пиковые дни легко выливаются в 200–300 тысяч ₽ недополученной выручки и штрафов за несколько суток.

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

Теперь смотрим на вторую сторону уравнения — сколько стоило бы «сделать по уму». Перенос CRM в облако с нормальным SLA, регулярные проверяемые бэкапы, документация по интеграциям с 1С, минимальный План аварийного восстановления (Disaster Recovery plan) и тестовый контур для обновлений обошлись бы в диапазон 150 000–500 000 ₽ разово плюс 50 000–100 000 ₽ в год на инфраструктуру и сопровождение. Конкретная цифра зависит от зоопарка накопленных интеграций, но порядок именно такой: один «нормальный» проект стоит как один‑два серьезных инцидента.

Кейс Grow Food и другие публичные истории с многодневными простоями показывают, что проблема не уникальна: даже крупные компании с ИТ‑командами и бюджетами на порядок выше, иногда лежат по двое суток и больше. Для небольшого оптовика без DR‑плана двое суток простоя — это еще довольно мягкий сценарий. На этом фоне техдолг перестает быть страшилкой айтишников и превращается в очень простой управленческий выбор: заплатить один раз за решение или регулярно платить сопоставимые суммы за последствия.

Один сервис, три слоя технологического долга

Представим внутренний сервис, который когда‑то запускали «для удобства» — например, систему, через которую идут счета, закрывающие документы и часть клиентской коммуникации.

С точки зрения людей:

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

С точки зрения процессов:

• заявки на исправление ошибок в сервисе падают в чат, фиксируются как попало;
• SLA на исправление багов и простои нигде не описаны, все держится на «договорились по‑человечески».

С точки зрения технологий:

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

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

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

Почему техдолг дорожает каждый месяц

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

Железо дорожает, новые модели стоят дороже старых, валютные качели никуда не деваются.Лицензии и подписки тоже не стремятся дешеветь, а условия вендоров со временем, как правило, становятся жестче, а не мягче.

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

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

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

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

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

Зачем здесь ИТ‑аудит и консалтинг

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

Системный ИТ‑аудит как раз и работает как инвентаризация техдолга и оценка рисков.Он помогает:

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

Дальше в дело входит ИТ‑консалтинг: нужно не просто «увидеть проблему», а построить план ее поэтапного погашения. Определить, что чинить в первую очередь, где достаточно минимальных доработок, а где нужен пересмотр архитектуры.

Для вас как компании результат ИТ‑аудита в этой картине мира — это не страшилка про «все пропало», а ясная карта:

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

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

Заключение: с чего начать прямо сейчас

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

Если по описанию вы узнаете свою ситуацию — CRM на старом железе, ключевые интеграции без документации, bus factor 1 вокруг пары людей, — разумно начать с небольшого шага. Экспресс‑аудит техдолга по трем слоям (люди, процессы, технологии) и оценка стоимости простоя критичных систем дают основу для разговора на уровне совета директоров: где нужно инвестировать уже в этом году, что можно отложить, а от каких рисков пора осознанно отказаться.

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