Технический долг и его причины: как решения «на потом» бьют по бизнесу

Автор: Авдей Мартынович, руководитель подразделения по работе со средним и малым бизнесом ALP ITSM

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

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

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

Что такое техдолг

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

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

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

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

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

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

С ИТ‑инфраструктурой и сервисами все устроено точно так же.

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

Давайте смотреть не абстрактно на «какой‑то ИТ», а комплексно, через зрелый ITSM‑подход.
В нем ИТ всегда состоит из трех блоков: люди, процессы, технологии.

И ровно в этих трех местах накапливается техдолг.
Не бывает так, что все плохо только в серверах, а люди и процессы идеальны — всегда где‑то еще есть просадка.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Все эти «давайте пока так оставим, работает же» складываются в очень конкретную копилку технологического техдолга. Если посчитать такой риск в лоб, картина становится проще. Например, отказ сервиса на четыре часа в конце месяца = (средний объем выставляемых счетов в час × 4) * (4 часа работы команды на восстановление × средняя ставка специалистов).

Чаще всего эта сумма оказывается сопоставимой или больше плановой модернизации железа и приведения процессов в порядок.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Он помогает:

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

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

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

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

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

Как превратить техдолг в управляемый проект

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

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