Highload-системы: когда бизнесу действительно нужна высоконагруженная архитектура

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

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

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

Почему legacy-системы — это проблема для компаний

Почти всегда legacy — это системы, которые сложно изменять без риска для всей системы, потому что любое изменение может её сломать. Они росли годами: сначала быстро, потом обрастали временными решениями, теряли документацию и авторов и сейчас продолжают работать, но без нужды (или для починки) в них не лезут. Сегодня их поддержка по оценке рынка съедает до 60–80% ИТ-бюджета в большом бизнесе, госсекторе и на крупных производствах. При этом новые фичи выходят медленно и с высоким риском, а на масштабирование систем уже не хватает ресурсов.

Вот какие ещё проблемы legacy приносит бизнесу:

• Рост времени на любую доработку, когда, например, исправить одну опечатку в интерфейсе — это три дня согласований и риск нарушить процесс сдачи отчётности для бухгалтерии

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

• высокая латентность при пиках нагрузки: пользователи начинают ждать по минуте вместо 5-10 секунд, а в условную чёрную пятницу система просто перестаёт отвечать на запросы

• регулярные инциденты, когда система стоит из-за ошибки, которую сложно локализовать и устранить (как из-за отсутствия специалистов, так и риска сломать что-то другое)

Модернизация vs переписывание: в чём разница

Модернизация (она же рефакторинг или постепенная миграция)

Суть модернизации в том, что вы не отключаете сразу старую систему и запускаете новую, а аккуратно заменяете её части. Например, берётся один модуль (например, авторизация или каталог товаров), он переписывается на современном стеке и подключается обратно через адаптер. Всё остальное пока работает как работало, поменялся только один модуль.

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

Признаки, когда имеет смысл модернизировать систему:

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

Плюсы модернизации:

• ошибка в одном модуле не влияет критически на всю систему

• довольно быстро становится заметен результат, особенно при обновлении проблемных мест старой системы

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

Минусы:

• бывает так, что интеграция старого и нового часто превращается в усложнение архитектуры и рост технического долга

• процесс может растянуться на годы, если нет жёсткого графика или внешнего давления

• команда разработки должна держать в голове две разные архитектуры одновременно, для этого нужна хорошая квалификация

• иногда проще стереть всё и написать с нуля, чем пытаться подружить legacy-софт с новыми микросервисами.

Переписывание с нуля

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

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

Признаки, когда имеет смысл написать всё с нуля:

• старый код — настолько сложный и запутанный, что его невозможно полноценно рефакторить (ни один разработчик не хочет в него лезть и правильно делает)
• технологический стек умер (например, Delphi или Perl без поддержки) и не совместим с современным
• бизнесу нужен кардинально другой уровень производительности: например, перейти с обработки 1000 запросов в секунду на 100 000. Какое бы надёжное ни было легаси, при стократном росте нагрузки оно сломается
• наконец, если вы меняете модель работы, например, с внутреннего портала на открытое API для тысяч партнёров.

Плюсы переписывания:

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

• нет legacy‑долгов, поэтому можно выбирать любые технологии, не оглядываясь на совместимость

• команда пишет код с нуля, а не разбирается в чужом (разбираться и обновлять всегда сложнее, чем сделать заново)

• появляется запас производительности и отказоустойчивости при грамотном проектировании

Минусы:

• главный минус — цена и сроки: переписывание крупной системы занимает от 6 месяцев до 3 лет, плюс сложно даже предсказать, какой на это потребуется бюджет.

• пока пишут новое, бизнес меняется и к моменту релиза требования уже не те. Лечится скрам-подходом и обратной связью от стейкхолдеров.

• миграция данных — почти всегда потеря части информации или долгий простой (даже если вы ВСЁ предусмотрели, часть данных нужно будет переносить или восстанавливать вручную)

Критерии выбора: чек-лист для принятия решения

Вот пять вопросов, на которые нужно ответить максимально честно (желательно - совместно с техническим директором или архитектором системы).

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

Риски для бизнеса и как их минимизировать

• 1
  Перерасход бюджета и срыв сроков

  Модернизация может бесконечно затянуться, если нет чёткого плана, а переписывание почти всегда дороже и дольше, чем ожидалось.  

  В любом случае лучше всё разбивайте на этапы с конкретными измеримыми результатами. При переписывании, например, начинайте с MVP критически важной функции, а не всей системы сразу.

• 2
  Потеря данных при миграции
  

  При переходе со старой системы на новую данные теряются или дублируются (даже если технический директор убеждает, что такого точно не случится). Особенно больно это проявляется в финансах и учёте.  

  Рекомендуем внедрить временную двойную запись (в старую и новую системы) и проводите сверки до и после. И всегда держите резервную копию, откатиться на которую можно за пять минут.

• 3
  Падение производительности вместо роста
  

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

  Проводите нагрузочное тестирование на каждом этапе, имитируйте пик в 3–5 раз выше планового и увеличивайте длительность. Не верьте никому на слово, смотрите только цифры.

• 4
  Уход ключевых сотрудников

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

• 5
  Пользователи отвергают новую систему

  Интерфейс поменялся, кнопки переехали, отчёты выглядят иначе — люди злятся и саботируют (и их можно понять). 

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

Заключение

На вопрос «модернизировать или переписывать нет единственно правильного ответа — всегда будет компромисс между скоростью, деньгами и рисками. Но если вы начали замечать, что каждое обновление даётся с болью, а серверы падают при росте трафика — пришло время что‑то менять. 

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

Ключевая задача – не просто выбрать подход, а оценить текущее состояние системы, ограничения архитектуры и бизнес-требования. Именно это определяет успешность трансформации.