Мадэрнізацыя legacy-сістэм: стратэгіі, кошт і бяспечны план міграцыі

Мадэрнізацыя legacy-сістэм – гэта абнаўленне софту, які ўсё яшчэ абслугоўвае бізнэс, але стаў цяжкім у змене, дарагім у змесце або рызыкоўным. Гэта можа быць дадатак на PHP 5 без тэстаў, старая CRM з самапіснымі убудовамі, дэсктопная праграма, якая працуе з агульнай базай дадзеных, або маналіт, у якім разбіраецца адзін чалавек. Мэта - не новыя тэхналогіі дзеля тэхналогій, а сістэма, якую бізнэс зноў можа бяспечна мяняць.

Мы прымаем на падтрымку і мадэрнізуем працоўныя сістэмы кліентаў - ад білінгавых платформаў да мультымоўнай e-commerce. Ніжэй - падыход, які мы выкарыстоўваем самі: маленькія зварачальныя крокі, кожны з якіх акупляецца.

Прыкметы таго, што час мадэрнізаваць

Узрост сам па сабе не прычына. Дзесяцігадовая сістэма, якая стабільная, бяспечная і недарагая ў зменах, можа заставацца як ёсць. Інвестыцыі апраўдваюць такія сігналы:

• Кожная змена - доўгая і страшная. Невялікая фіча займае тыдні, рэлізы выкочваюць уначы, а пасля кожнага дэплоя ламаецца нешта незвязанае.
• Непадтрымоўванае асяроддзе ці фрэймворк. PHP 7.x ці старэй, фрэймворк без падтрымкі, старая версія базы дадзеных або АС без абнаўленняў бяспекі. Гэты выпадак падрабязна разабраны ў нашым гайдзе па пераходзе на PHP 8.
• Залежнасць ад аднаго чалавека. Толькі адзін распрацоўшчык, часта вонкавы, ведае, як працуюць дэплой, cron-задачы і інтэграцыі.
• Інтэграцыі заблакаваныя. Нельга падлучыць новы плацежны сэрвіс, CRM ці ІІ, таму што ў сістэмы няма звычайнага API.
• Выдаткі растуць. Хостынг на залішніх серверах, дарагія ліцэнзіі, ручная праца ў абыход якія адсутнічаюць функцый і паўтараюцца інцыдэнты.
• Дзюры ў бяспецы і камплаенсе. Паролі ў адкрытым выглядзе, састарэлыя бібліятэкі з вядомымі ўразлівасцямі, няма часопіса дзеянняў, дадзеныя захоўваюцца не там, дзе павінны.

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

Мадэль 6R: стратэгіі мадэрнізацыі

6R - просты спосаб выбраць стратэгію. Галоўнае - выбіраць яе для кожнага кампанента асобна, а не для ўсёй сістэмы адразу.

• Retain (пакінуць). Кампанент не чапаем, толькі маніторым. Падыходзіць для стабільных частак, якія рэдка мяняюцца, напрыклад старога модуля справаздач.
• Rehost (перанесці як ёсць). Пераносім прыкладанне на новую інфраструктуру без змены кода, напрыклад са старога фізічнага сервера ў Docker на сучасным VPS ці ў воблаку. Хутка і нядорага: прыбірае рызыку жалеза, але не праблемы кода.
• Replatform (змяніць платформу). Невялікія змены, каб працаваць на лепшай платформе: падтрымоўваная версія PHP, кіраваная база дадзеных, чарга замест цыклаў у cron. Часта лепшыя суадносіны кошту і выніку.
• Refactor (рэфакторынг). Паляпшаем унутраную структуру без змены паводзін: дадаем тэсты, вылучаем сэрвісы, выдаляем мёртвы код, паступова ўводны пласт фрэймворка.
• Rearchitect (перапраектаваць). Змяняем архітэктуру часткі сістэмы, напрыклад выносім білінг у асобны сэрвіс з API ці заменны агульную базу дадзеных на падзеі.
• Rebuild ці replace (перапісаць ці замяніць). Пішам кампанент нанова ці заменны яго SaaS-прадуктам. Апраўдана, калі бізнэс-логіка простая і зразумелая ці гатовы прадукт яе пакрывае. Рызыкоўна для складанай недакументаванай логікі.

Тыповы план спалучае некалькі стратэгій: спачатку перанос, каб прыбраць інфраструктурныя рызыкі, затым рэфактарынг ядра, перапраектаванне адной-двух балючых абласцей і замена тыпавых частак – адпраўкі пошты ці пошуку – праверанымі сэрвісамі. Калі выбіраеце менавіта паміж перапісваннем і паступовым паляпшэннем, ацаніце, колькі недакументаваных бізнэс-правілаў утрымоўвае стары код: кожнае забытае правіла стане багам у новай сістэме.

Спачатку аўдыт і карта рызык

Мадэрнізацыя без аўдыту - гэта варажба. За адзін-два тыдні аўдыт павінен адказаць: што менавіта працуе ў прадакшэне, дзе ляжаць дадзеныя, што далікатнае і што бізнэс не можа страціць. Падрабязны спіс пытанняў - у нашым чэк-лісце аўдыту кода. Мінімальны вынік:

• Інвентарызацыя. Серверы, дамены, рэпазітары, cron-задачы, чэргі, знешнія сэрвісы, доступы і ўладальнік кожнага акаўнта.
• Карта архітэктуры. Асноўныя модулі, базы дадзеных, інтэграцыі і патокі дадзеных, у тым ліку недакументаваныя, знойдзеныя ў кодзе і логах.
• Карта рызык. Кожная рызыка з верагоднасцю, уплывам на бізнес і спосабам выпраўлення: няма бэкапаў, няма тэстаў плацёжнай логікі, сакрэты ў рэпазітары, непадтрымоўванае асяроддзе.
• Хуткія перамогі. Выпраўленні на некалькі дзён, якія здымаюць самыя вялікія рызыкі: правераныя бэкапы, маніторынг, сакрэты па-за кодам, які прайграваецца дэплой.
• Дарожная карта. Парадак крокаў мадэрнізацыі з ацэнкамі, залежнасцямі і тым, што кожны крок дае бізнесу.

Калі вы прымаеце сістэму ад іншага распрацоўніка, сумясціце аўдыт з крокамі з нашага гайда па перадачы legacy-праекта на PHP: спачатку доступы і бэкапы, потым змены ў кодзе.

Пакрокавы план міграцыі

Самы бяспечны спосаб мадэрнізаваць працуючую сістэму – патэрн strangler fig («фікус-душыцель»): ставім проксі перад старым дадаткам і пераносім маршруты, модулі ці функцыі ў новы код па адным. Карыстальнікі бачаць адну сістэму, а за ёй старая частка паступова сціскаецца, пакуль яе не адключаць.

# nginx: new code serves /billing and /api/v2, everything else stays on the legacy app
location /billing/ { proxy_pass http://new_app; }
location /api/v2/  { proxy_pass http://new_app; }
location /         { proxy_pass http://legacy_app; }

1. Стабілізацыя. Бэкапы з правераным аднаўленнем, маніторынг даступнасці і памылак, цэнтралізаваныя логі, сакрэты па-за кодам. Пакуль гэтага няма, нічога іншага не пачынаем.
2. Прайгравальнасць. Які спакуецца прыкладанне ў Docker або іншае паўтаранае асяроддзе, паднімаем staging з абязлічанымі дадзенымі і дэплой, які адкочваецца за хвіліны.
3. Страховачная сетка. Пішам характарызацыйныя тэсты для крытычных сцэнарыяў: уваход, афармленне замовы, выстаўленне рахункаў, справаздачы, ад якіх залежаць фінансы. Яны фіксуюць, што сістэма робіць сёння, у тым ліку багі.
4. Абнаўленне платформы. Версіі мовы і фрэймворка, якія падтрымліваюцца, актуальныя бібліятэкі, сучасная версія БД. Дзе можна - аўтаматычныя прылады, а ўсё, што ловяць тэсты, выпраўляемы.
5. Перанос балючых частак. Выбіраемы модуль з самым высокім коштам змен або самай вялікай рызыкай, які будуецца замену, накіроўваем на яе частка трафіку, параўноўваем вынікі і перамыкаем цалкам.
6. Акуратная міграцыя даных. Плануем змены схемы так, каб стары і новы код працавалі адначасова, мігруем порцыямі, звяраем колькасці і сумы і захоўваем шлях адкату, пакуль стары код не выдалены.
7. Выдаленне старога кода. Выводзім з эксплуатацыі ўсё, што больш не выкарыстоўваецца. Мадэрнізацыя, якая нічога не выдаляе, проста дадае другую сістэму на падтрымку.

Кожны крок павінен выкочвацца асобна і даваць бачны вынік: менш інцыдэнтаў, хутчэй рэлізы ці ніжэй рахунак. Так праект застаецца прафінансаваным і не ператвараецца ў класічныя "два гады перапісвання без выніку".

Кошт, тэрміны і акупляльнасць

Лічбы залежаць ад памеру, якасці кода і колькасці невядомых, але гэтыя дыяпазоны для невялікай дасведчанай еўрапейскай каманды карысныя як арыенцір:

• Архітэктурны аналіз або аўдыт: €200–3k, 1-2 тыдні. Пісьмовая справаздача з рызыкамі, прыярытэтамі і дарожнай картай.
• Стабілізацыя: €3k–15k, 2-6 тыдняў. Бэкапы, маніторынг, Docker, які прайграваецца дэплой, сакрэты, самыя тэрміновыя выпраўленні бяспекі.
• Абнаўленне платформы: €5k–40k, 1-3 месяцы. Напрыклад, пераход з PHP 5 ці 7 на PHP 8 з абнаўленнем фрэймворка і тэстамі крытычных сцэнараў.
• Паэтапная мадэрнізацыя: €15k–150k, 3-12 месяцаў. Перапраектаванне ключавых модуляў, новыя API, міграцыя дадзеных і выснова старых частак з эксплуатацыі.
• Поўнае перапісванне: часта ў 1,5-3 разы даражэй за першую адзнаку. Схаваная бізнэс-правілы, міграцыю дадзеных і раўналежную падтрымку старой сістэмы звычайна недаацэньваюць.

Для разліку акупнасці параўнайце бягучы кошт legacy-сістэмы з мэтавым станам. Улічыце гадзіны распрацоўшчыкаў, страчаныя на павольныя змены, інцыдэнты і іх уплыў на бізнэс, ручную працу ў абыход адсутнічаюць функцый, хостынг і ліцэнзіі, а таксама выручку ад функцый, якія зараз немагчыма зрабіць. Звычайна мадэрнізацыя акупляецца за кошт трох эфектаў: змены робяцца ў разы хутчэй, інцыдэнтаў менш, інфраструктура таннейшая. Аб бюджэтаванні ў цэлым - у нашым гайдзе аб кошце распрацоўкі ПЗ на замову.

Тыповыя памылкі

• Перапісванне "вялікім выбухам". Старую сістэму замарожваюць на год, пакуль будуюць новую. Бізнэс працягвае мяняцца, і новая сістэма састарваецца ўжо да запуску.
• Змяненні без тэстаў. Без характарызацыйных тэстаў ніхто не ведае, ці змяніў рэфактарынг паводзіны.
• Ігнараванне дадзеных. Код можна перапісаць за тыдні, а гады няўзгодненых дадзеных чысціць і міграваць значна даўжэй.
• Рашэнні ад тэхналогіі. Мікрасэрвісы ці новы фрэймворк выбіраюць таму, што гэта модна, а не таму, што гэта вырашае вымераную праблему.
• Няма адказнага з боку бізнэсу. Нехта павінен расстаўляць прыярытэты і пацвярджаць, што перанесеныя функцыі працуюць як трэба.

Чым мы можам дапамагчы

Мы мадэрнізуем працоўныя PHP-і вэб-сістэмы па кроках: аўдыт, Docker і бяспечны дэплой, абнаўленне PHP і фрэймворкаў, новыя API і інтэграцыі – без прыпынку бізнэсу. Добры першы крок - архітэктурны аналіз ( €200): пісьмовы разбор вашай сістэмы з рызыкамі, прыярытэтамі і ацэнкай кожнага кроку мадэрнізацыі. Калі хочаце спачатку абмеркаваць сітуацыю, запішыцеся на кансультацыю ( €50 / гадзіну). Глядзіце таксама нашу паслугу па інтэграцыях і кейс білінгу PebbleHost.