Кажущиеся вечными ИТ-системы рушатся за день. В 2020‑м штат Нью‑Джерси в США оказался на грани: их сервис для безработных, построенный на старых мейнфреймах и ещё более старом COBOL, не выдержал потока заявок, и власти начали искать программистов-пенсионеров. При этом на COBOL обрабатывалось около $3 трлн в сутки, 95% операций в банкоматах и 80% офлайн‑платежей. Проблема оказалась не только в технологиях, но и в том, что никто не понимал, что делать.

В США до сих пор работают федеральные IT-системы возрастом 8–51 год, их поддержка обходится в $337 млн ежегодно. Бизнес тоже живёт на легаси: компании закладывают бюджет на модернизацию — в среднем это $2,7 млн в год, но 60–80% денег всё равно уходит на штопанье старого кода. При этом каждая такая система — дыра в безопасности: средний ущерб от утечки данных в 2024-м достиг $4,88 млн.

Корни таких ситуаций лежат в монополии на знания о вашей системе, когда всё держится на двух‑трёх людях. Они в голове носят знания, которых нет ни у кого. И если что-то с ними случится, то все процессы встанут.

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

Диагностика процессов: 3 симптома конца

Симптом № 1. Гейткипер релизов — один контролирует все

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

Если bus factor равен единице, то есть за всё отвечает один человек, это проявится в Lead Time — времени от создания или переработки кода до его тестирования. Вместо часов и дней цикл растянется на недели и месяцы. 

Путь к росту бизнеса может лежать в более коротком Lead Time наравне с качественным тестированием. То есть важно не просто сделать код абы как и релизить, а настроить все процессы и распределить их в команде.

Симптом №2. Священный и неприкосновенный сервер

Если в инфраструктуре продукта есть архаичный сервер или модуль, к которому никто не прикасается, любой сбой приводит к долгому простою. Команда просто не знает, как быстро поднять сервер при аварии. Отсюда высокий Mean Time To Repair (MTTR) — среднее время восстановления работы системы. 

Чем выше MTTR, тем больше риск потерь: высокий MTTR=количеству времени, когда клиенты не могут пользоваться сервисом=снижение выручки и репутационные издержки.

Симптом №3. Исторический монолит — экспериментам нет места

Монолит с многолетним легаси тормозит развитие продукта. В этом случае невозможно быстро добавить новую фичу или провести A/B-тест — слишком велик риск зацепить существующую функциональность. В итоге компания принимает решения не на основе данных, а на интуиции, потому что экспериментировать слишком дорого. 

Главный показатель здесь: число экспериментов в единицу времени. Если ваши конкуренты делают по 10 экспериментов в месяц, а вы один в квартал, разрыв в развитии будет слишком критическим.

Корень бед проекта — не сама технология, а культ знания

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

1-й слой: культура «спасти всех»

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

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

2-й слой: структура команд и систем

Есть так называемый закон Конвея, когда архитектура продукта повторяет структуру взаимодействия команд. То есть если в компании отделы фронтенда, бэкенда и, например, дизайна работают сами по себе, то и модули системы будут разорваны. Мартин Фаулер в своём анализе закона Конвея предупреждает, что такие разобщённые команды вынуждены очень долго передавать работу друг другу, что замедляет вообще всё. 

Лучше использовать обратный маневр, чтобы ускорить процессы — изменить организацию под желаемую архитектуру: маленькие кроссфункциональные команды самостоятельно ведут фичу от идеи до продакшена. Успех продукта должен измеряться количеством пользы для клиента, а не количеством реализованных фич. Если же оставить оргструктуру времён монолита, то какие бы крутые ни внедрялись технологии, разрывы в коммуникации приведут к медленным релизам и невозможности развиваться. 

3-й слой: процессы и артефакты

Старый стек часто сопровождают устаревшие процессы и отсутствие инженерной культуры. Чаще всего это ручные релизы, отсутствие автоматизированных тестов, устное и не зафиксированное нигде принятие решений. Architecture Decision Records (ADR) не ведутся — ключевые архитектурные решения теряются в почте или голове разработчика. Документация устарела или фрагментарна. В итоге — хаос и неопределённость. Никто не может точно сказать, как что работает и почему было сделано именно так. 

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

Есть ещё нюанс. Из собственного опыта знаю, что инженерная культура начинается с отношения к новаторству. Это обычно выглядит так: на одной стороне всегда есть ребята с горящими глазами, которые тянутся к новому и готовы экспериментировать. А на противоположном полюсе — консерваторы, подозрительно косящиеся на любителей изменений. 

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

Считаем потери и риски компании

Теперь разберёмся, сколько действительно стоит компании монополия на знания.

Цена промедления

Когда выход новой функции задерживается, компания теряет деньги. Для расчёта убытков в теории продуктового менеджмента используется показатель Cost of Delay — «цена промедления». Его формула:

Посчитаем на примере. Допустим, новая фича оплаты могла бы приносить 300 000 ₽ в день. Если релиз затянулся на 20 дней, потери составят 0,3 млн ₽ × 20=6 млн ₽. 

Риск срыва системы

Старый стек или компонент, который давно не обновлялся, — постоянный риск. Его оценивают через ожидаемый убыток. Есть, например, рисковая экспозиция (expected loss) — расчёт вероятности происшествия на его стоимость:

Например, вероятность крупного сбоя в устаревшем биллинге составляет 15 %, а суточный простой обойдётся в 10 млн ₽. Тогда ожидаемый убыток — 0,15 × 10 млн = 1,5 млн ₽. Пока бизнес откладывает модернизацию, эти полтора миллиона как бы заложены в бюджет риска.

Старый стек vs ROI модернизации

Чтобы понять, окупятся ли новые технологии, полезно рассчитать Return on Investment (ROI). Формула классическая:

В нашем примере переработка модуля занимает 6 месяцев и стоит 20 млн ₽. После модернизации команда выпускает релизы вдвое чаще, что приносит 20 млн ₽ дополнительной выручки за два года. Сокращение аварий (с 5 до 2) экономит ещё 12 млн ₽. Общий эффект — 32 млн ₽, минус 20 млн ₽ затрат = 12 млн ₽ чистой выгоды. Чистая прибыль (32 млн ₽ – 20 млн ₽ = 12 млн ₽) даёт ROI = (12 млн ₽ / 20 млн ₽) × 100 ≈ 60 %. Иными словами, проект окупится за два года.

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

Как спасти продукт и не терять миллионы: 5 шагов для перехода

Давайте честно — всё описанное выше не значит, что перейти на новую технологию можно за копейки. Мы говорим не о сиюминутной выгоде, а о долгосрочной. Поэтому здесь покажу, какие базовые шаги можно сделать, чтобы без лишней боли модернизировать продукт. За деталями приходите в мой ТГ-канал — там рассказываю о конкретных кейсах и как всё менять с помощью ИИ. 

1. Сделайте систему наблюдаемой

Вы не сможете что-то улучшить, пока не видите проблему. Начните с инвентаризации и мониторинга текущего ландшафта:

• Карта систем и их важности. Опишите все ключевые модули/сервисы и их связи. Определите критичность каждого по влиянию на бизнес или пользователей. Выявите, где сбой нанесёт наибольший ущерб, чтобы понять, что в приоритете.

• Service Level Objectives (SLO) и бюджет ошибок. Задайте для критичных компонентов целевой уровень доступности (SLO) и допустимое время сбоев (error budget). Если сейчас вы не отслеживаете uptime компонента, сначала внедрите мониторинг — без этого никак. Наблюдаемость — первый шаг к контролю.

• Мониторинг и алертинг. Настройте сбор ключевых метрик (нагрузка, время отклика, ошибки) и автоматические оповещения при проблемах. Для каждого важного сервиса сделайте наглядные дашборды, видимые всей команде и бизнесу — прозрачность полезна всем.

• Матрица ответственности. Назначьте ответственных за каждый компонент. Используйте для этого матрицу RACI или просто определите ответственного исполнителя. Если какой-то старый модуль сейчас «ничей», найдите ему владельца. Не должно быть ситуации, когда при падении сервиса никто не знает, что делать.

• Runbook и документация. Подготовьте простые инструкции на случай аварий. Даже очень простые вроде «если сервис X упал — перезапустить; не поднялся — звонить Васе». Задокументируйте известные проблемные места (список технического долга и ограничений легаси). Новые разработчики, читая README, должны сразу видеть предупреждения, например: «модуль Y — легаси; не изменять без согласования с Петей или до рефакторинга».

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

2. Ликвидируйте монополии на знания

Когда навели порядок, разбиваем единоличное владение частями системы и налаживаем обмен опытом в команде:

• Фиксируйте решения. Начните документировать ключевые архитектурные решения в формате Architecture Decision Record. Это короткий документ для каждого существенного изменения: какое решение приняли и почему. Через год у вас накопится база, объясняющая устройство системы, и архитектурные знания перестанут быть чьей-то монополией.

• Снижайте риски bus factor. Мотивируйте разработчиков делиться экспертизой, не сводите бас фактор к нулю или единице. Лучше, чтобы 3–4 специалиста владели полной информацией. Введите bus factor bounty — бонус или публичную похвалу за то, что сотрудник поделился знанием о модуле, который раньше знал только он, или написал недостающую документацию. Отмечайте не только выпуск новых фичей, но и снижение рисков.

• Парное программирование и ротации. Практикуйте работу в парах, особенно на легаси-модулях: ставьте новичка к хранителю легаси для совместного кода или ревью. Джун изучает бизнес-логику и тонкости старой системы, а сеньор перенимает свежие практики и инструменты. Можно устроить shadowing — когда второй разработчик временно дублирует обязанности главного, чтобы получить реальный опыт.

• Обязательный код-ревью для легаси. Ни одна правка в критичный легаси-модуль не вносится в одиночку. Любой такой pull request должен пройти через второго разработчика. 

3. Разделите старое и новое

Когда команда готова к изменениям, приходит пора технической модернизации. Ваша задача — отделить новый код от старого, чтобы легаси не тормозил развитие:

• Явные интерфейсы между модулями. Если у вас монолит или тесно связанные системы, сначала разведите их по чётким интерфейсам. Организуйте взаимодействие через API (REST, gRPC и пр.), даже если раньше модули лезли напрямую в общую базу или обменивались файлами. Покройте интеграции контрактными тестами, проверяющими, что сервис А и сервис Б правильно обмениваются данными. Все зависимости должны быть явными и проверяться тестами. Тогда при попытке обновить один модуль вы сразу узнаете, если что-то сломалось в другом — тесты упадут.

• Отделение логики через Hexagonal architecture. Примените принцип шестигранной архитектуры к ядру легаси-системы. Вынесите бизнес-логику в отдельные классы/модули, а взаимодействие с внешним миром (базы, очереди, UI) осуществляйте через слой адаптеров. Это прослойка, через которую новый код будет контактировать со старым. Так у вас будут точки, где потом можно отсечь старую реализацию и заменить её новой без переписывания всего сразу.

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

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

4. Модернизируйте постепенно

Подходите к переписыванию кода постепенно, а не переделывайте всю систему разом. Здесь помогает паттерн Strangler Fig (в переводе — удушающего фигового дерева). В природе это работает так — фиговое дерево обвивает старый ствол, пуская новые ростки, и шаг за шагом заменяет старичка, пока тот не отомрёт. В разработке то же самое:

• Выделение домена (Strangler-подход). Выберите относительно автономный участок системы (домен) и реализуйте его заново в виде нового сервиса. Лучше начать с функциональности, которую проще всего изолировать по данным и логике. На первом этапе запустите новый сервис в режиме только-чтение: пусть он берёт данные из старого хранилища или через API, но сам пока ничего не меняет. Так вы проверите, что новый код правильно воспроизводит логику.

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

  Фаза 1: новый сервис обрабатывает запросы пользователей и пишет данные в новую базу, параллельно обновляя старую базу (чтобы старый модуль тоже получал обновления). 

  Фаза 2: переключаете приложение, и новая база данных становится основной (старую переводите в read-only). Такой поэтапный переход позволяет всегда иметь резерв — старую систему — на случай отката.

• Два контура (Two-speed IT). Теперь на время появляются два контура развития: легаси-ядро (медленный, стабильный, минимум изменений) и новая надстройка (быстрые изменения, эксперименты). Это нормально. Важно только задать понятные правила взаимодействия между ними через описанные контракты и не дать медленному контуру сдерживать быстрый.

• Стоп-критерии и откаты. Чётко определите, как вы поймёте, что миграция идёт не туда, и как будете откатываться. Например, если после переключения на новый модуль показатели SLO упадут больше чем на X%, немедленно возвращаете трафик на старую систему до выяснения причин. Наличие такого «стоп-крана» понизит шансы сбоев и даст вам спать спокойно.

5. Измените стимулы и культуру

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

• Новые KPI про надёжность и автоматизацию. Пересмотрите метрики успеха для команд и лидов. Если раньше главное было сделать фичу к сроку любой ценой, то теперь во главе угла должны быть предсказуемость, качество и автоматизация. Добавьте в цели сотрудников долю процесса, покрытого CI/CD, процент инфраструктуры, описанной как код, количество автоматических тестов.

• Бонус за сокращение ручной работы. Поощряйте разработчиков, которые находят способ автоматизировать свою рутину.

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

Когда лучше не трогать «динозавра»

Есть редкие случаи, когда старое решение действительно стоит оставить в покое — там, где стабильность важнее изменений:

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

• Стабильная нагрузка и узкая задача. Если система выполняет узкую функцию при стабильной нагрузке и вы уверены, что она справляется, то риск переписывания превышает выгоду.

В заключение: полезные шаблоны и чек-листы

Собрал несколько шаблонов, которые пригодятся в работе с вашей командой.

1. Шаблон ADR

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

2. Карта сервисов/модулей

Пример таблицы для инвентаризации систем: указываются модуль, владелец, критичность, bus factor, SLO/доступность и последние инциденты. Такой список выявляет риски и зоны для приоритезации.

3. Чек-лист готовности к Strangler‑подходу

Перед выносом домена в отдельный сервис важно проверить такие процессы:

4. Набор KPI для модернизации

Здесь разделил основные DevOps‑метрики и дополнительные показатели для отслеживания прогресса команд.

5. Шаблон постмортема

Структурированный формат разбора инцидентов:

А у вас такие подходы работают или всё висит на одном супергерое? Это всё база, от которой нужно отталкиваться. В моём ТГ-канале делюсь всей подноготной про наши процессы в командах в Surf и показываю, как внедряем AI-boosted Delivery Platform, чтобы ускорить мобильную разработку в 3 раза и не просесть в качестве.