Більшість компаній, які працюють понад десять років, мають в інфраструктурі систему, яку бояться чіпати. Вона обробляє замовлення, рахує залишки або веде облік клієнтів, але кожна зміна в ній займає тижні, а розробників, які розуміють її код, стає дедалі менше.
Відкладати модернізацію з кожним роком дорожче, проте сам процес оновлення лякає ще більше, бо збій у критичній системі клієнти й співробітники відчувають вже наступного дня.
У IT Hoot ми займаємося модернізацією та міграцією застарілих систем, і в цій статті розбираємо, як спланувати оновлення так, щоб бізнес продовжував працювати на кожному етапі.
Ризики зупинки бізнесу під час модернізації
Зупинка бізнесу під час модернізації рідко трапляється через саму нову технологію. Найчастіше її спричиняють три речі, які команда не помітила на старті проєкту.
Прихована бізнес-логіка
За роки роботи legacy-система накопичує правила, яких немає в жодній документації: особливі умови для окремих клієнтів, винятки в розрахунку доставки, нестандартні статуси замовлень.
Якщо нова версія не відтворює цю логіку, помилки проявляються вже після запуску, і першими їх помічають клієнти.
Залежність процесів від системи
Застаріла система зазвичай пов'язана з десятком інших сервісів, від складу та бухгалтерії до сайту й маркетплейсів. Зміна в одному місці може зламати інтеграцію, про яку ніхто не пам'ятав, і зупинити процес, на перший погляд не пов'язаний з модернізацією.
Перенесення даних
Дані в старій системі часто зберігаються в застарілих форматах, мають дублікати та неповні записи. Одномоментне перенесення великого масиву без перевірки цілісності створює ризик втратити історію замовлень або клієнтські дані.
Ознаки того, що застарілу систему час модернізувати
Вік системи сам по собі не є причиною її змінювати, бо програма, написана п'ятнадцять років тому, може стабільно працювати й не заважати розвитку компанії. Модернізацію варто планувати тоді, коли архітектура починає гальмувати бізнес-рішення, і найчастіше це проявляється так:
- нова функція, яка в сучасному стеку займає кілька днів, потребує кількох тижнів розробки й тестування;
- фреймворк або платформа більше не підтримуються, і оновлення безпеки перестали виходити;
- знайти розробника, готового працювати з цим стеком, складно й дорого;
- інтеграція з новими сервісами, як-от маркетплейсами, платіжними системами чи CRM, потребує обхідних рішень;
- система не витримує зростання навантаження, і пікові періоди закінчуються збоями.
Коли в системі одночасно проявляються дві-три такі ознаки, модернізацію варто вносити в план, а головним рішенням стає вибір підходу.
Підходи до модернізації legacy-системи
Повне переписування з нуля
При повному переписуванні команда проєктує нову архітектуру, обирає сучасний стек і будує систему заново, а стару вимикає після запуску нової. Цей підхід дає найбільшу свободу, бо архітектурні рішення не обмежені компромісами минулого.
Водночас це найризикованіший варіант для безперервної роботи бізнесу. Поки команда будує нову версію, стара продовжує отримувати зміни, і в день перемикання всі ризики зосереджуються в одному моменті.
Повне переписування виправдане, якщо система невелика й її функціональність можна повністю описати до старту робіт, або якщо бізнес-модель змінилася настільки, що більша частина старої логіки вже не потрібна.
Поступова міграція модулями
Поступова міграція передбачає заміну системи частинами. Команда виділяє окремий модуль, наприклад каталог товарів, оплату або обробку замовлень, переносить його на нову архітектуру й підключає до решти системи через API. У розробці цей підхід відомий як патерн Strangler Fig, за яким нова система поступово розростається навколо старої, доки та не стане непотрібною.
Головна перевага такого підходу полягає в контрольованому ризику. Кожен етап невеликий, його можна протестувати окремо, а бізнес отримує перший результат уже після першого модуля, а не наприкінці всього проєкту. Ціною цієї безпеки є довший перехідний період, упродовж якого команда підтримує дві архітектури та синхронізує дані між ними.
Комбінований підхід
На практиці часто поєднують обидва варіанти. Критичні модулі, від яких залежить виручка, мігрують поступово, а другорядні частини, які простіше створити заново, переписують повністю.
Критерії вибору підходу
Швидко звузити вибір допомагають кілька запитань:
- Чи може бізнес пережити період, коли нова система ще не готова, а стара вже не розвивається? Якщо ні, поступова міграція безпечніша.
- Наскільки добре задокументована поточна бізнес-логіка? Чим менше документації, тим вищий ризик втратити функціональність під час переписування.
- Чи можна розділити систему на незалежні модулі? Моноліт із жорсткими залежностями мігрувати частинами складніше, і тоді переписування може виявитися дешевшим.
- Скільки часу лишається до моменту, коли стара технологія стане критичною проблемою? Якщо підтримку фреймворка вже припинено, терміни можуть визначити підхід замість вас.
- Хто підтримуватиме систему після модернізації? Новий стек має відповідати компетенціям команди, яка з ним працюватиме далі.
Етапи модернізації без зупинки бізнесу
Оновити систему без простою можна за будь-якого з підходів, якщо команда дотримується послідовності етапів і не переходить до наступного, поки не завершить попередній.
Технічний аудит системи
На цьому етапі команда аналізує код, архітектуру, залежності між модулями та всі інтеграції з іншими сервісами, а також збирає бізнес-логіку, яка існує лише в коді або в досвіді співробітників.
Результатом аудиту стає карта системи з оцінкою ризиків для кожного модуля, рекомендований підхід і поетапний план із термінами та бюджетом.
Фіксація поточної поведінки тестами
Перш ніж змінювати будь-який модуль, команда покриває його тестами, які фіксують нинішні результати роботи системи. Так нову версію можна перевірити на тих самих даних і переконатися, що вона поводиться так само, включно з незадокументованими винятками.
Паралельна робота старої та нової версій
Новий модуль запускають поруч іззі старим, і він деякий час обробляє ті самі запити без впливу на користувачів. Команда порівнює результати обох версій і виправляє розбіжності ще до того, як на нову версію перейде хоч один клієнт.
Поетапне перенесення даних
Дані переносять частинами, перевіряючи цілісність після кожного кроку. Перед кожним етапом створюють резервну копію, до якої можна повернутися, а на перехідний період налаштовують синхронізацію, щоб нові записи не губилися між двома системами.
Перемикання користувачів на нову версію
Усіх користувачів не переводять одночасно. Спочатку на новий модуль спрямовують невелику частку трафіку, потім поступово збільшують її, і стару версію вимикають лише тоді, коли нова стабільно працює під повним навантаженням. Якщо щось іде не так, трафік повертають на старий модуль за кілька хвилин.
Типові помилки під час модернізації
- Старт розробки без аудиту. Команда дізнається про приховані залежності вже під час перенесення, і план доводиться переглядати на ходу.
- Нові функції паралельно з міграцією. Бажання відразу покращити логіку розмиває межі етапів і ускладнює перевірку, тому нове варто додавати після міграції відповідного модуля.
- Вибір стеку без урахування підтримки. Технологія, для якої складно знайти розробників, за кілька років перетворить нову систему на черговий legacy.
- Відсутність плану відкату. Без можливості швидко повернутися до старої версії будь-яка помилка після запуску перетворюється на простій.
Підсумок
Модернізація legacy-системи без зупинки бізнесу можлива, якщо команда добре розуміє поточну систему ще до старту робіт і замінює її керованими кроками. Аудит, тести на поточну поведінку, паралельна робота версій і план відкату знижують ризик збою настільки, що клієнти помічають модернізацію лише за тим, що система працює швидше.
Якщо ви плануєте модернізацію і хочете зрозуміти, який підхід підійде саме вашій системі, команда IT Hoot проведе аудит і запропонує поетапний план міграції.