🛠️ Технический долг: что это и почему о нём молчат

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

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

Виды технического долга.

Вы думаете, что техдолг, что это только кривой код? На самом деле он бывает разным:

💥Программный: устаревшие версии ПО, необновляемые библиотеки, самописные костыли вместо готовых решений (которые сведут в могилу).

🔥Аппаратный: серверы с uptime 500+ дней (потому что их бояться перезагружать - в прошлый раз еле подняли), СХД без резервного контроллера, ИБП с севшими батареями, "виртуализация" без HA на одном диске.

🔴Архитектурный: монолит, который нельзя разбить на микросервисы; сеть, спроектированная "на коленке", отсутствие резервирования и тп.

🔖Документационный: знания только в головах «незаменимых» сотрудников, схемы сети на салфетках.

🚨Процессный: отсутствие мониторинга, бэкапов, регламентов обновления.

Пример из моей практики №1: СХД без резерва

Прихожу в компанию. СХД работает в одиночку, второй контроллер не подключён, два диска из рейда выпали. «За 2 года ни разу не падал, зачем расходы?» Через месяц СХД упала (сдох ещё один диск). Восстанавливались три дня из бэкапа полугодовой давности. Потери - миллионы. Вот вам «экономия».

Пример №2: Виртуализация «на коленке»

В одной компании виртуализация была развёрнута на серверах из того, что было: SSD без RAID, одна гигабитная карта на хост. Пока нагрузка маленькая, терпимо. Начали расти - «тормоза». Апгрейд? Нет, наймём ещё айтишника делать новые костыли. Итог: зоопарк, каждая ВМ - героический эпос. Один SSD падает и всё, приехали.

Пример №3: ПО без обновления

Классика, разрабы жили не тужили - пришлось по законодательству обновлять и все упало и уже нет возможности даже обновлять линейно и весь отдел дружно "встрял" но зато лет 5 даже не думали об этом.

Почему компании создают техдолг? Техдолг копят годами. Причины:

• Иллюзия экономии. Сейчас дешевле «срезать угол». Это как не платить по кредитке - коллекторы придут позже.
• Некомпетентность управленцев. Не видят разницы между «работает» и «надёжно работает». Пока не грянет гром.
• Страх перемен. «Работает - не трогай» лучший друг техдолга.
• Зависимость от «незаменимых». Сотрудник не документирует костыли, чтобы без него не могли. Это его рента.
• Краткосрочное мышление бизнеса. Фичи здесь и сейчас, качество потом. А потом гора мусора хоронит бизнес.

Как оценить техдолг в деньгах и рисках?

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

Метрики:

➡️Время простоя инцидентов, связанных с «legacy».

➡️Количество инцидентов, которые нельзя было предотвратить из-за отсутствия мониторинга, резервирования и т.п.

➡️Скорость вывода новых проектов (чем больше техдолга, тем она ниже).

Что делать?

➡️Признать проблему и измерять её.

➡️Вести реестр техдолга: узкие места, риски, стоимость исправления.

➡️Планировать погашение (20% времени на рефакторинг).

➡️Автоматизировать контроль: мониторинг, бэкапы, документация, обновления.

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

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