Стовпова сторінка
Модернізація систем легасі
Інкрементальне рефакторинг моноліту на мікросервіси, міграція з застарілих технологій до сучасних стеків, перенесення до хмари — без перерв у бізнесі, з планом відмотки та повним аудитом сліду.
Кожна компанія має якийсь систему legacy. Деякі мають їх декілька. Аконтингова програма з 2008 року, яка якось працює. CRM написаний консультантами, яких ніхто вже не пам'ятає. Склад у Accessie. Кожен з них колись треба буде замінити — питання не чи, а коли і як.
Модернізація систем legacy це один з найважчих типів проектів IT. Він вимагає балансування трьох сил: підтримання безперервності бізнесу (система повинна працювати весь час), впровадження сучасних технологій (мікросервіси, хмару, AI) та контролю ризику (кожен рефакторинг може псувати щось, що працювало роками)
Чому недостатньо "переписати від зеро"?
З нашого досвіду 9 із 10 успішних модернізацій - це інкрементальне рефакторинг, а не переписування. Переписування спокушає концептуальною простотою ("почнемо з чистого аркуша"), але на практиці вони мають три фундаментальні проблеми:
- Невидима логіка бізнесу. Старий система містить роки правил бізнесу — умови спеціальні для найбільших клієнтів, звільнення від податків для конкретних галузей, обходи для регуляцій з 2015 року. Більшість не є задокументованою. Rewrite мусить їх усіх відтворити з пам'яті людей або аналізу коду.
- Дублювання праці. Під час написання нового системи, бізнес усе ще вимагає змін у старому (регуляції, нові клієнти, дрібні помилки). Команда або дублює працю (зміна у двох місцях), або заморожує старий систему (ризикує бізнесове).
- Big bang deployment. Після року праці, нова система є «практично готова». Перемикання всіх користувачів за одну ніч генерує монументальне ризико. Кожна неочікувана проблема означає повернення до старої системи, втрату моралі команди, підваження довіри бізнесу.
Інкрементальне рефакторинг (найчастіше за зразком Strangler Fig) розв'язує всі три: логіка бізнесу відкрита поступово, одне джерело правди для кожної сутності, деплоймент етапами з feature flagами.
Шість моделей модернізації
Кожен з них вирішує конкретний ризик. У більшості проектів ми поєднуємо кілька, вибираючи шаблон до конкретного модуля.
Странглер Фіг
Поступове «оповивання» старої системи новими компонентами. Старий код продовжує працювати, але кожна нова функціональність потрапляє до нового мікросервісу, а існуючі модулі замінюються один за одним. Через 12-24 місяці стара монолітна система виводиться з ладу.
Антикорупційний шар
Адаптер, що захищає новий код від дивностей старої системи (нечитабельні назви полів, дивні формати дат, несумісні типи). Ціла "бридка" логіка ізольована в одному місці — новий код оперує на чистій моделі домену.
Переглянда бази даних
Шаблони з книги Refactoring Databases (Ambler/Sadalage): expand-and-contract для міграції схеми, валідування даних перед видаленням старих стовпців, паралельне підтримання обох схем під час міграції додатка.
Гілка за абстракцією
Введення шару абстракції навколо старого компонента, паралельна реалізація нового компонента, поступове перемикання з 0% до 100% руху (feature flag). Без «біг бенг» деплою.
Режим тіні
Новий код запускається паралельно зі старим — обидва обробляють ті самі запити, але тільки результати старого надходять до користувача. Результати порівнюються офлайн. Після підтвердження відповідності (типово 2-4 тижні) ми переключаємо трафік на новий код.
Подія джерело для міграції
Записуємо потік бізнесових подій зі старої системи та відтворюємо його у новій. Дозволяє здійснити попередню валідацию нової архітектури без ризику для виробництва, а також повернутися до будь-якого історичного стану.
Типовий графік модернізації
Для середнього системи (моноліт ~200 тис. рядків коду, 5-10 бізнесових модулів):
- Місяць 1: Відкриття і документація. Інверсне проектування архітектури, мапування залежностей, ідентифікація потоків даних, документація бізнес-процесів з допомогою осіб бізнесу.
- Місяць 2: Цільова архітектура і пілотаж. Проект нової архітектури, вибір технологій, пілотаж на найпростішому модулі (proof of concept). Перша валідация підходу.
- Місяці 3-4: Виділення першого модульного виробництва. Strangler Fig pattern, режим тіні протягом 2-3 тижнів, перемикання трафіку, hypercare. Перша реальна бізнес-віддача.
- Місяці 5-12: Ітераційне виділення наступних модулів. Кожен у циклі 4-6 тижнів: рефакторинг → тести → шедов → виробництво → гіперкер. Постійне вдосконалення процесу, зменшення часу на наступні модулі.
- Місяці 12-18: Міграція даних і відмова від моноліту. Коли всі критичні модулі виділені, фіналізуємо міграцію історичних даних, виключаємо стару систему, архівуємо. Святкуємо.
Старий систем vs. змодернізований
| Аспект | Система спадщини (типово) | Після модернізації |
|---|---|---|
| Час впровадження нової функції | 4-8 тижнів (високе ризико регресії) | 3-7 днів (автоматичні тести мінімізують ризик) |
| Перекриття тестами | 5-15% (або відсутній) | >80%, у конвеєрі CI/CD |
| Доступність розробників | Мала (застаріла технологія) | Дужа (популярні, сучасні стеки) |
| Безпека | Старі бібліотеки з уразливостями CVE | Сканування OWASP, gitleaks, автоматичне оновлення |
| Масштабування | Вертикаль (більше ресурсів для моноліту) | Горизонтальне (масштабування конкретних мікросервісів) |
| Спостережуваність | Логі у файлах, відсутність метрик | Prometheus + Grafana + Sentry + Система моніторингу та управління інформаційною безпекою |
| Відповідність (GDPR, EU AI Act, ISO 27001) | Вимоглива, коштовна для доведення | Вбудована в архітектуру, готова до аудиту |
Шість типових ризиків — і як їх адресуємо
Ризико: Відсутність тестів у системі legacy
Митигація: Спочатку будуємо тести характеристичні (capture tests) — записуємо поточну поведінку системи на основі логів продукційних і записів руху. Лише потім починаємо рефакторинг, з тестами як захисним засобом.
Ризик: Знання зосереджені в одній особі („truck factor 1")
Мітигація: Трансфер знань починається в перший тиждень проекту. Всі зустрічі з особою, яка знає систему, записуються та транскрибуються, ключові процеси документуються, архітектурні рішення обґрунтовуються. Після проекту весь команду розуміє систему.
Ризико: Тимчасове сповільнення команди
Мітигація: У перших 2-3 місяцях команда підтримує стару систему + будує нову. Природнє сповільнення темпу змін. Ми мітигуємо їх: пріоритет для змін, які потрапляють тільки до нової системи, фріз для низькопріоритетових змін у старому коді.
Ризико: Міграція даних
Мітигація: Кожна міграція даних має три фази: dry-run (на копії продуктивної), staging (на середовищі тестовому з справжньою масштабністю даних), продукція (у вікні обслуговування або інкрементально). План відкачування готовий перед стартом.
Ризико: Опір організаційний
Мітигація: Комунікація з бізнесом від першого дня: чому модернізація, що зміниться для користувача, який графік, як ми вимірюємо успіх. Перша ітерація вибирається так, щоб швидко показати осяжну вартість (наприклад, новий UI або швидший звіт).
Ризик: Недооцінка вартості
Мітигація: Відкриття (1-2 тижні) перед оцінкою проекту. Ітерації 2-3 тиждневі з конкретними поставними результатами — легше виправити курс, ніж у довгому проекті типу "все одразу". Буджет з буфером 20-30% на непередбачені.
Найчастіші питання
Що таке системний спадок?
Чому варто модернізувати, якщо система працює?
Чи не легше написати все спочатку?
Чи потребує модернізація простою бізнесу?
Як триває типова модернізація?
З яких технологій ми міграціюємо найчастіше?
Що стосується існуючих інтеграцій з іншими системами?
Як ви обмежуєте ризик бізнесу?
Що з документацією системи, якої немає?
Які є витрати на модернізацію у порівнянні з утриманням старої системи?
Почнімо з аудиту
Тижневий технічний аудит: мапування поточного стану, ідентифікація найпрісніших областей модернізації, план етапний з конкретними бізнес-ефектами у першій ітерації.