С точки зрения инженера техдолг редко выглядит как одна большая проблема. Скорее как набор: временный сервис на старом Windows Server, который внезапно стал критичным; поддержка в рабочих чатах без нормальных SLA и приоритизации; bus factor = 1 по ключевой системе, где все держится на одном человеке; бэкапы, которые давно никто не поднимал в тесте. Пока все живет — это считается разумными компромиссами. До первого серьезного сбоя.
Привет, я Авдей Мартынович, руководитель подразделения по работе с СМБ в ALP ITSM. Мы регулярно приходим в инфраструктуры, которые годы росли по принципу «запустили — потом разберемся»: CMDB в головах, инциденты и запросы в одном чате, «тестовые» сервисы на проде, legacy‑монолиты, к которым страшно прикасаться. Наша задача — честно разложить этот техдолг, посчитать его последствия и помочь договориться с бизнесом, что и в каком порядке менять.
В статье разбираем:
как техдолг выглядит на трех уровнях — люди (bus factor, документация), процессы (инциденты, запросы, изменения), технологии (старый стек, отсутствие плана восстановления, «временные» решения);
как разделять инженерную и бизнес‑оценку «чинить/не чинить»;
почему попытка «ничего не трогать» часто дороже плановой миграции;
и что получает команда от ИТ‑аудита: не только презентацию для руководства, но и конкретный список рисков, архитектурных доработок и процессных изменений.
Что такое техдолг
Техдолг — это цена прошлых ИТ‑компромиссов, которые позволили вам когда‑то сделать быстрее или дешевле, но теперь возвращаются рисками и дополнительными затратами. Техдолг это те самые решения «на потом», которые принимали год, два, пять назад. Вы экономили на архитектуре, отказоустойчивости, документации, людях и процессах — и сегодня платите за это простоями, аварийными работами и ограничениями для бизнеса.
Если чуть приземлить разговор, у техдолга всегда есть две стороны.
На инженерном уровне это человеко‑часы, лицензии, новое железо, миграции, тестирование, сопровождение.
На бизнес‑уровне — стоимость часа простоя, SLA перед клиентами, штрафы, срыв поставок, упущенная выручка.
Нормальный разговор про техдолг выглядит как сравнение двух цифр: сколько стоит починить сейчас и сколько стоит не чинить до первого серьезного сбоя.
Если вторая цифра заметно больше, вопрос «дорого ли чинить» обычно отпадает.
В бухучете техдолга нет — там есть только сервера, лицензии и строчки затрат. Из‑за этого финблок его просто не видит, хотя техдолг съедает прибыль, увеличивает убытки и в какой‑то момент начинает влиять на стоимость компании. Из‑за него вы недополучаете выручку, теряете клиентов, срываете обязательства и переплачиваете за «ремонт по скорой».
Нужно думать о техдолге как о кредите под проценты. Каждый раз, когда вы откладываете «неприятное» обновление или замену старого сервера, вы как будто продлеваете этот кредит еще на месяц. Проценты набегают в виде все более дорогих ремонтов, растущей сложности поддержки и увеличивающихся рисках простоя.
Вторая метафора — нелеченые зубы. Пока не болит, кажется, что можно подождать. Но каждый месяц откладывания делает лечение дороже и болезненнее, а часть зубов уже не лечат — их просто удаляют.
С ИТ‑инфраструктурой и сервисами все устроено точно так же.
Три источника техдолга: люди, процессы, технологии
Давайте смотреть не абстрактно на «какой‑то ИТ», а комплексно, через зрелый ITSM‑подход.
В нем ИТ всегда состоит из трех блоков: люди, процессы, технологии.
И ровно в этих трех местах накапливается техдолг.
Не бывает так, что все плохо только в серверах, а люди и процессы идеальны — всегда где‑то еще есть просадка.
Большинство смотрит только на железо и софт: «старый сервер, старая версия, надо обновить».
А реальные проблемы начинаются там, где сходятся все три компонента: не хватает людей, процессы собраны на коленке, а технологии держатся на временных костылях.
Если у вас уже проседает хотя бы один из блоков, вы потихоньку создаете техдолг.
Если дыры есть во всех трех, вопрос звучит не «случится ли авария», а «когда именно и сколько это будет стоить».
Люди: когда все держится на одном герое
Очень частая картинка: у компании есть «тот самый» ИТ‑специалист, который тянет на себе один или несколько критичных сервисов.
Он единственный, кто знает, как все устроено, где лежат бэкапы, какие там костыли и что нужно «подкрутить, чтобы поехало». Снаружи кажется, что это удобно: есть свой человек, все к нему ходят, он все чинит, бизнес доволен. По факту это кадровая мина замедленного действия.
Как только у этого человека случается что‑то из набора «заболел, выгорел, уехал, уволился» — бизнес‑критичный сервис просто встает. А вместе с ним встают счета, отгрузки, закрывающие документы, отчетность и все, кто от этого сервиса зависел.
При этом параллельно копятся дыры в карте компетенций команды. Нагрузка растет, ИТ‑ландшафт усложняется, появляются новые сервисы и интеграции, требования по безопасности, а команда все так же работает в режиме «тушим пожары, остальное как‑нибудь потом».
В какой‑то момент вы внезапно обнаруживаете, что люди физически не вытягивают объем и сложность задач. Но честной инвентаризации компетенций, рисков и емкости никто не делал — все просто «героически тащили».
Это такой же техдолг, как старый сервер: долг по людям и по управлению ИТ‑командой.
Процессы: поддержка «как‑нибудь в чате»
Второй вид техдолга лежит в плоскости процессов. Чаще всего все начинается по‑простому: завели чат, посадили туда инженера, сказали бизнесу «пишите сюда, ребята помогут». Пока компания небольшая и сервисы не критичны, эта схема еще как‑то живет. Но как только растет количество пользователей и систем, начинаются классические симптомы:
заявки теряются или месяцами лежат «на подумать»;
у всех все горит, но никто не понимает, что действительно критично;
за время реакции и восстановления фактически никто не отвечает.
Формализованных SLA/OLA нет, все держится на личных договоренностях и доброй воле отдельных людей. В результате любой более‑менее серьезный инцидент превращается в хаос: бизнес ждет, что «поднимут за полчаса», ИТ что‑то делает, но общих правил игры нет.
Если смотреть через призму ITSM, здесь в одном флаконе смешаны инциденты, сервисные запросы и изменения. Нет нормальной категоризации и приоритизации (условных P1–P4), нет понятного входа в процесс управления изменениями, нет связки «инцидент → расследование → проблема → изменение».
Формально SLA могут существовать в презентации для бизнеса, но в операционке они не живут: нет мониторинга фактического выполнения, нет связи с KPI команды поддержки, нет прозрачной статистики по реакциям и восстановлению.
Процессы инцидентов и запросов на обслуживание часто остаются недостроенными, потому что когда‑то их запускали «как временное решение, потом доведем до ума».
Потом, как обычно, не наступило — и временное решение стало постоянным.
Каждый раз, когда вы говорите «ладно, сейчас не до процесса, потом улучшим», вы создаете техдолг в процессах управления ИТ. И расплачиваетесь за это тогда, когда все падает в самый неудобный момент.
Технологии: от тестового сервиса до критичной точки отказа
Третий, самый очевидный слой — технологии. Здесь обычно все начинается с истории «давайте запустим тестовый сервис, посмотрим, поедет ли, а дальше решим».
Для теста его ставят на минимальную инфраструктуру: без отказоустойчивости, без нормальных бэкапов, часто вообще на каком‑нибудь старом сервере «чтоб не жалко». Формально он временный, на нем «ничего критичного».
На практике это часто выглядит так: где‑то в углу крутится тот самый «временный» Windows Server с самописной CRM, кусочком 1С или веб‑интерфейсом, которую никто уже не хочет трогать. Поверх этого создаются интеграции, скрипты, планировщики задач — и все это работает по принципу «не трогай, пока работает». При этом нет ни нормального мониторинга метрик и состояний, ни внятных уведомлений о событиях, ни регулярной проверки восстановления из бэкапов. Хорошо, если когда‑то «для галочки» поднимали стенд из резервной копии и проверяли, что он вообще стартует.
Проходит год–два, команды подтягиваются, данные переезжают, процессы обрастают этим сервисом — и внезапно выясняется, что на этой «временной болванке» живет уже половина компании. Но архитектура, отказоустойчивость и резервирование все еще на уровне теста.
Сюда же попадает классика жанра: старое железо без поддержки и запчастей. Серверу десять лет, модель снята с производства, официальной поддержки нет, запчасти для него почти невозможно найти, но он обслуживает критичную систему, и всем его жалко трогать, потому что «вдруг не поднимем».
Отдельная история — устаревшие версии ОС и прикладного ПО, на которых «все еще как‑то живет».
Они уже не получают обновлений безопасности, вендор про них забыл, но на них завязаны бизнес‑критичные приложения, переписать которые страшно и дорого.
Любая попытка обновления превращается в квест с непредсказуемым финалом, поэтому обновление откладывают еще на год. И еще на год.
Все эти «давайте пока так оставим, работает же» складываются в очень конкретную копилку технологического техдолга.
Отдельная сложность — интеграции вокруг сервиса.Пока все работает, их стараются не трогать.
Но в момент падения оказывается, что поднимать нужно не одну систему, а целый «зоопарк» зависимых компонентов, очередь задач, синхронизаций и импортов.
Когда «временная» 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 на исправление ошибок и простои сервиса нигде формально не описаны, все держится на «мы же договорились» и «ну вы же понимаете, что это важно».
Слой технологий.
Сервис до сих пор крутится на том самом «временном» сервере, который когда‑то выделили «на тест». Нормальной отказоустойчивости нет, бэкапы делаются как получится, тестового контура, на котором можно безопасно что‑то проверить, тоже нет.
По отдельности все эти решения когда‑то казались мелочами: тут сэкономили день на согласовании сервера, тут не стали заморачиваться с процессом, тут не успели оформить нормальное дежурство и замену людей. Но в сумме это уже не мелочи, а конкретный бизнес‑риск.
Достаточно одной аварии или того, что ключевой человек внезапно выпадет из процесса, — и у вас встает критичный кусок операционной деятельности. Вот это и есть техдолг во всей красе: не один большой «провал», а много маленьких уступок, которые тихо сложились в большую проблему.
Почему техдолг дорожает каждый месяц
Техдолг — это не что‑то статичное, что можно «заморозить» и потом спокойно к нему вернуться.
Это именно кредит: вы его уже взяли, и проценты по нему капают каждый день, даже если вы делаете вид, что ничего не происходит.
Железо дорожает, новые модели стоят дороже старых, валютные качели никуда не деваются.
Лицензии и подписки тоже не стремятся дешеветь, а условия вендоров со временем, как правило, становятся жестче, а не мягче.
Работа людей тоже стоит все дороже: хороших ИТ‑специалистов на рынке не прибавляется, инфраструктуры усложняются, и любой проект миграции требует все больше квалификации и времени. То, что три года назад можно было сделать «малой кровью», сегодня превращается в тяжелый переезд на несколько недель.
Отдельная статья «процентов» — безопасность. Старые версии фреймворков, библиотек и операционных систем перестают получать патчи, а требования к защите данных и результаты внешних проверок становятся все жестче.
Закрывать новые уязвимости на старом стеке зачастую дороже, чем один раз запланированно мигрировать.
Похожая ситуация с legacy‑монолитами. Система, которую три года назад еще можно было относительно безболезненно распилить или хотя бы обложить тестами, за это время обрастает интеграциями и бизнес‑логикой. Каждое изменение по ней требует все больше усилий, и цена любого рефакторинга растет гораздо быстрее инфляции.
Каждый новый инцидент на старом сервере, вокруг неактуального сервиса или «героического» сотрудника — это не просто разовая проблема, а как раз те самые проценты по кредиту.
Вы платите за аварийные выезды, овертаймы, разовые костыли, но само тело долга никуда не девается — наоборот, риск следующей, еще более дорогой аварии только растет.
Откладывание решения здесь не экономит деньги.
Оно лишь переносит платеж на будущее, добавляя к нему надбавку за риск и за усложнившуюся за это время инфраструктуру.
Зачем здесь ИТ‑аудит и консалтинг
Чтобы вообще начать что‑то делать с техдолгом, его сначала нужно вытащить на свет. Не в формате «у нас все старое и все плохо», а в виде очень приземленного списка: где у нас риски по людям, где по процессам, где по технологиям и что именно там может хлопнуть.
По‑нормальному это делается через ИТ‑аудит. По сути, это инвентаризация техдолга и честная оценка того, во что вам обходится «ничего не менять». Мы раскладываем картину на две части: инженерная оценка — сколько стоит починить, и бизнес‑оценка — во сколько обойдется не чинить.
Дальше уже работает консалтинг: мало просто увидеть проблему, нужно договориться, в каком порядке вы этот долг будете платить. Где критичный риск и надо делать вчера, где можно заложить изменения в план работ, а где вообще хватает минимальных доработок и не нужно «переписывать все с нуля».
Наш опыт очень простой: большинство клиентов тянут с техдолгом до тех пор, пока их не «клюнет жареный петух». Устаревший сервер падает, старый сервис окончательно ломается, единственный человек, который все знает, уходит — и компания платит в разы больше, чем стоило бы плановое решение.
ИТ‑аудит как раз нужен, чтобы прийти не после аварии, а до нее. Спокойно посчитать, где риск оправдан, а где вы играете в русскую рулетку, и зафиксировать это на языке денег, а не эмоций.
С точки зрения ИТ‑команды результат нормального аудита — это не только презентация для собственников.
Это вполне конкретный план работ:
перечень рисков по ключевым сервисам и системам;
архитектурные «долги» и варианты их закрытия;
список провалов в документации;
приоритизированные изменения в процессах поддержки и эксплуатации.
При этом задача аудита — не «убедить всех срочно переписать все на новом стеке ради моды».
Цель — честно показать, где достаточно минимальных изменений и дисциплины, а где без серьезного рефакторинга или миграции риск уже неадекватен бизнесу.
Вместо вывода
Технически большинство историй про «легла CRM на два дня» или «упала 1С в конец месяца» устроены одинаково. Годы подряд бизнес и ИТ шли на маленькие компромиссы — временный сервер, костыльную интеграцию, отсутствие DR — пока один сбой не сложил эти решения в полноценный простой с очень конкретным ценником.
Хорошая новость в том, что изменить эту траекторию можно без тотального «переписывания мира». Начать можно с инвентаризации техдолга: какие сервисы реально критичны, на каких из них вы все еще живете на тестовом железе, где отсутствует нормальный change‑процесс, а где SLA существуют только в презентациях. Дальше — закрыть самые токсичные вещи: отсутствие проверяемых бэкапов, bus factor 1 вокруг ключевых систем, самописные интеграции без документации. Это скучные задачи, но именно они определяют, закончится очередная авария ночной сменой у консоли или остановкой бизнеса на двое суток.
Поделитесь в комментариях, вашими историями и мыслями то к чему приводят ситуации, когда не техдолг исключают из планов развития.