Старі системи мають дві спільні риси: вони працюють, і вони змушують усіх нервувати. Вони працюють, бо роки реального використання сформували їх навколо справжнього бізнесу. Вони змушують людей нервувати, бо ніхто не хоче їх торкатися, документація тонка, а один із початкових розробників пішов три роботи тому.
Що насправді вважається "застарілим"
Не кожна стара система застаріла. 10-річний застосунок, що працює на підтримуваному стеку, добре протестований, з активним обслуговуванням, - просто зрілий. Застаріле зазвичай означає:
- Версії платформи чи фреймворку, що більше не отримують оновлень безпеки.
- Знання, сконцентровані в одній чи двох людях.
- Страх щось змінювати, бо невеликі зміни ламають віддалені функції.
- Ручні розгортання, ручні тести, ручне геть усе.
- Зростаючий розрив між тим, що потрібно бізнесу, і тим, що система може.
Два провальні підходи
- Нічого не робити. Ризик накопичується. Врешті щось критичне ламається в поганий момент.
- Переписати з нуля. Переписування "великим вибухом" майже завжди триває довше, ніж планувалося, виявляє приховані вимоги надто пізно і працює паралельно зі старою системою так довго, що команда здається.
Підходи, що справді працюють, лежать між цими двома крайнощами.
Стратегія 1: Задушити стару систему
Тримайте застарілу систему в роботі, але поступово спрямовуйте нову функціональність через новий рівень. З часом усе більше функцій живе в новій системі; стара зменшується, доки її нарешті не вимкнуть.
Це працює для вебсайтів (переміщуйте сторінку за сторінкою), внутрішніх інструментів (переміщуйте модуль за модулем) та інтеграцій (упровадьте новий API-шлюз, потім перенаправте абонентів на нього).
Стратегія 2: Модернізувати на місці
Інколи архітектура нормальна, але стек надто старий. У такому разі оновлюйте один рівень за раз: мова/середовище виконання, потім бібліотеки, потім фреймворк, потім розгортання. Додавайте автоматизовані тести по дорозі, щоб кожен крок був перевірюваним. Не гламурно, але дуже ефективно.
Стратегія 3: Розділити, потім модернізувати
Великі монолітні системи часто легше модернізувати частина за частиною, щойно шви стають чіткими. Це означає спершу визначити межі всередині наявної системи (модулі, обмежені контексти), потім замінювати модулі незалежно. Межі важать більше, ніж вибір технології.
Що зробити перед написанням будь-якого коду
- Запишіть, що система насправді робить сьогодні, а не що вона мала робити.
- Визначте функції, на які люди покладаються щодня - вони мають продовжувати працювати протягом переходу.
- Визначте мертві функції - вони часто є значною часткою коду і мають бути тихо виведені з експлуатації.
- Проведіть інвентаризацію даних, інтеграцій, дозволів та експортів. Саме тут проєкти модернізації зазвичай натрапляють на проблеми.
- Вирішіть, що означає "готово" у вимірюваних термінах.
Заходи контролю ризику, що справді мають значення
- Резервні копії та протестовані відновлення - перед будь-якою зміною.
- Автоматизовані тести для поведінки, яка вас турбує, упроваджені поступово.
- Feature flags, щоб зміни можна було відкотити в продакшні без розгортання.
- Спостережуваність - логи, відстеження помилок, ключові бізнес-метрики - щоб ви швидко дізналися, якщо щось регресувало.
- Поетапне розгортання: новий код спершу працює для внутрішніх користувачів, потім для невеликого відсотка реальних користувачів, потім для всіх.
Патерн strangler fig. Замість ризикованого переписування "великим вибухом" ви спрямовуєте трафік через тонкий фасад, що поступово переадресовує дедалі більше запитів до нових сервісів, поки застаріла система продовжує обробляти решту, доки не спорожніє.
Приклад: мінімальний маршрут фасаду
Невеликий шлюз може вирішувати для кожного маршруту, чи піде запит до застарілого моноліту, чи до нового сервісу. Написано у незалежному від фреймворку стилі:
app.use((req, res, next) => {
if (req.path.startsWith('/api/v2/invoices')) {
return proxy(req, res, NEW_SERVICE_URL);
}
return proxy(req, res, LEGACY_URL);
});Кожен мігрований модуль переміщує один префікс з LEGACY_URL на NEW_SERVICE_URL. Користувачі ніколи не бачать переходу "великим вибухом"; команда випускає невеликі, зворотні кроки.
Поширена пастка: писати нову систему і стару так, ніби вони мають бути функціонально еквівалентними з першого дня. Не мають. Почніть із найменшої частини, що має реальну бізнес-цінність, доведіть шлях міграції, потім повторіть.
Поширені помилки
- Зведення модернізації до вибору технології. Модні нові стеки не допомагають, якщо модель даних та інтеграції все ще загадкові.
- Очікування повного редизайну перед виправленням видимих проблем. Користувачі платять ціну; інерція згасає.
- Вимкнення старої системи надто рано. Запускайте обидві паралельно достатньо довго, щоб довіряти новій.
- Втрата інституційних знань. Працюйте в парі з людьми, які знають систему. Їхні знання - справжній актив.
Реалістичний графік
- Стабілізуйте: резервні копії, моніторинг, патчі безпеки, мінімум тестів.
- Окресліть: задокументуйте те, що існує і що насправді використовується.
- Пріоритезуйте: виберіть частину, що болить зараз і цінна для модернізації першою.
- Замініть: збудуйте нову версію цієї частини поруч зі старою.
- Перемкніть: спрямуйте трафік, моніторте, виправляйте проблеми.
- Виведіть з експлуатації: демонтуйте стару частину лише після того, як вона була тихою певний час.
- Повторіть для наступної частини.
