PHP 5.6 sistema gali veikti metų metus, kol pasikeitęs serveris, mokėjimų vartų reikalavimai ar nauja naršyklės politika neparodo tikrosios kainos. Klausimas, kaip atnaujinti PHP 5.6 sistemą, nėra vien apie naują PHP versiją. Tai darbas su verslo logika, duomenų baze, bibliotekomis, serverio nustatymais ir procesais, kurių gedimas gali sustabdyti užsakymus, sąskaitų išrašymą ar klientų aptarnavimą.
PHP 5.6 nebepalaikoma nuo 2018 m. pabaigos. Tai reiškia, kad saugumo spragoms nebeleidžiami pataisymai, o šiuolaikinės bibliotekos, mokėjimo ir API integracijos nebėra kuriamos galvojant apie šią aplinką. Vis dėlto sprendimas nėra aklai perjungti serverį į PHP 8.5. Toks veiksmas dažnai baigiasi baltais puslapiais, kritinėmis vykdymo klaidomis arba tyliai neveikiančiais foniniais procesais.
Kaip atnaujinti PHP 5.6 sistemą neprarandant kontrolės
Saugus atnaujinimas prasideda ne nuo kodo keitimo, o nuo sistemos inventorizacijos. Reikia suprasti, kas iš tikrųjų veikia produkcinėje aplinkoje: kokia PHP versija naudojama per naršyklę ir per komandų eilutę, kokie plėtiniai įjungti, kaip paleidžiami „Cron“ darbai, ar veikia eilės, kokios išorinės paslaugos kviečiamos ir kur laikomi jų prisijungimo duomenys.
Praktikoje senoje sistemoje dažnai randama daugiau nei vienas vykdymo kelias. Svetainė gali naudoti PHP-FPM, naktinis kainų importas - atskirą CLI PHP interpretatorių, o laiškų siuntimas - seną „Cron“ komandą su kitu `php.ini` failu. Atnaujinus tik svetainės PHP versiją, užsakymų laiškai gali nustoti išeiti tik po vidurnakčio. Todėl auditas turi aprėpti ne vien viešus puslapius.
Pirmiausia nustatoma rizika ir prioritetai
Audito metu verta suskirstyti funkcijas pagal verslo poveikį. E. prekybos sistemoje pirmiausia tikrinamas krepšelis, atsiskaitymas, mokėjimo vartų grįžtamieji pranešimai, užsakymo sukūrimas, likučių nurašymas ir patvirtinimo laiškai. Vidinėje sistemoje kritiniai gali būti klientų duomenų importai, ataskaitų generavimas, sąskaitų perdavimas apskaitai ir darbuotojų naudojami API ryšiai.
Taip pat peržiūrimos priklausomybės: ar projektas turi `composer.json`, kokios bibliotekos įdiegtos, ar naudojama sena „Symfony“, „Laravel“, „WordPress“ versija, ar dalis kodo įkelta rankiniu būdu. Jei priklausomybių valdymo nėra, jis dažnai atkuriamas bent tiek, kad pakeitimai būtų pakartojami ir suprantami. Tai mažina riziką po kelių mėnesių nebežinoti, kodėl serveryje atsirado konkretus failas.
Svarbus audito rezultatas nėra abstraktus sąrašas „kodas pasenęs“. Reikalingas konkretus planas: kurie moduliai blokuoja perėjimą, kurie pakeitimai yra būtini paleidimui, ką galima atidėti ir kur būtina parengti grįžimo scenarijų.
Kodėl PHP 5.6 negalima tiesiog pakeisti į PHP 8.5
Tarp PHP 5.6 ir šiuolaikinių PHP versijų yra daug nesuderinamų pakeitimų, vadinamų „breaking changes“. Dalis seno kodo rodys įspėjimus, dalis sustos su klaida, o dalis pakeis elgesį be aiškaus pranešimo. Būtent pastarieji atvejai yra pavojingiausi, nes klaida gali pasirodyti tik konkrečiame užsakyme ar retai vykdomame importe.
Dažnos problemos yra pasenę `mysql_*` kvietimai, kurie naujose PHP versijose nebeegzistuoja, senas konstruktorių aprašymas, neapibrėžtų masyvo raktų naudojimas, netikslus `null` reikšmių apdorojimas ir funkcijos, kurioms dabar taikomi griežtesni tipų reikalavimai. Taip pat keičiasi klaidų pranešimo elgsena, datos apdorojimas, eilučių funkcijos ir objektų serializavimas.
Bibliotekos kelia atskirą riziką. Pavyzdžiui, sena mokėjimo tiekėjo biblioteka gali veikti su PHP 5.6, bet nebepalaikyti naujesnių TLS, sertifikatų ar API autentifikavimo reikalavimų. Tuo pat metu nauja biblioteka gali reikalauti PHP 8.1 ar naujesnės „Composer“ versijos. Todėl atnaujinamas ne vien projektas - peržiūrimas visas suderinamumo sluoksnis.
Kartais tinkamiausias kelias yra etapinis: pirmiausia stabilizuoti kodą ir pereiti į tarpinę PHP versiją, tada atnaujinti karkasą ar bibliotekas, o galiausiai pasiekti tikslinę PHP 8.x versiją. Kitais atvejais, jei sistema nedidelė ir turi gerą testų aprėptį, galima atlikti didesnį šuolį. Sprendimas priklauso nuo kodo būklės, integracijų ir leistinos veiklos rizikos, o ne nuo to, kuri PHP versija yra naujausia.
Atnaujinimo darbai turi vykti atskiroje aplinkoje
Produkciniame serveryje eksperimentuoti nereikėtų. Pirmiausia sukuriama kuo panašesnė testavimo aplinka su duomenų bazės kopija, saugiai pakeistais jautriais duomenimis ir tokia pačia serverio konfigūracija. Joje įdiegiama pasirinkta PHP versija, reikalingi plėtiniai, atnaujinamos bibliotekos ir taisomas kodas.
Vien tik klaidų ištaisymo nepakanka. Reikia stebėti PHP žurnalus, žiniatinklio serverio žurnalus ir programos klaidas. Jei sistema naudoja „Redis“, eiles, failų saugyklą ar atskirą pašto serverį, šios paslaugos tikrinamos kartu. Kitaip gali atrodyti, kad administravimo forma išsaugojo duomenis, nors užduotis, kuri turėjo perduoti juos kitai sistemai, liko eilėje arba nutrūko.
Duomenų bazė taip pat nėra šalutinis klausimas. Senoje sistemoje dažnai naudojama pasenusi „MySQL“ versija, nekorektiškas simbolių kodavimas arba užklausos, kurios veikė tik dėl laisvesnių SQL nustatymų. Atnaujinus PHP ir kartu pakeitus duomenų bazės serverį, vienu metu atsiranda per daug kintamųjų. Jei įmanoma, šie darbai planuojami atskirais etapais ir kiekvienam jų numatomi patikrinimai.
Testuojami verslo scenarijai, ne tik puslapiai
Rankinis paspaudymas per kelis puslapius nėra pakankamas testas. Reikia pereiti realų verslo srautą nuo pradžios iki pabaigos. E. prekyboje tai gali būti prekės įdėjimas į krepšelį, nuolaidos pritaikymas, apmokėjimas testiniu metodu, mokėjimo patvirtinimo gavimas, užsakymo laiško išsiuntimas, likučio atnaujinimas ir duomenų perdavimas kurjeriui ar apskaitai.
Paslaugų versle tikrinama registracija, kliento sutarties sukūrimas, dokumento generavimas, priminimų siuntimas ir integracija su CRM. Jei sistema turi importus, testuojami ir teisingi, ir neteisingi failai. Jei naudojami API raktai, būtina patikrinti klaidos atsakymą, pasibaigusį raktą ir pakartotinio bandymo logiką.
Automatiniai testai, jei jų yra, suteikia greitą signalą apie regresijas. Jei jų nėra, kritiniams procesams verta parengti bent pakartojamus scenarijus ir aiškius priėmimo kriterijus. Tai nėra perteklinė dokumentacija. Tai būdas įrodyti, kad po atnaujinimo užsakymas ne tik sukuriamas ekrane, bet ir pasiekia visus reikalingus procesus.
Paleidimas: atsarginės kopijos ir grįžimo planas
Paleidimo langas planuojamas pagal sistemos veikimą. Jei užsakymai priimami visą parą, atnaujinimo metu gali reikėti trumpam sustabdyti mokėjimus, įjungti priežiūros režimą arba atidėti ne kritines eiles. Jei verslas gali skirti naktinį langą, vis tiek svarbu numatyti, kas atsakingas už patikrinimą iškart po pakeitimų.
Prieš paleidimą parengiama patikrinta failų, duomenų bazės ir konfigūracijos kopija. Grįžimo planas turi būti realus: žinoti, kaip atkurti ankstesnį kodą, kokius migracijos veiksmus galima grąžinti ir kaip elgtis, jei tarp paleidimo ir grąžinimo jau atsirado naujų užsakymų. Duomenų bazės struktūros pakeitimai dažnai yra vieta, kur skubotas grįžimas tampa sudėtingas.
Po paleidimo stebimos klaidos, PHP-FPM apkrova, atsako laikas, eilės, „Cron“ vykdymas ir integracijų atsakymai. Pirmosiomis valandomis verta aktyviai patikrinti kelis svarbiausius srautus, o ne laukti vartotojų pranešimų. Dokumentuoti pakeitimai, atnaujinti prieigos duomenų saugojimo principai ir aiškus serverio konfigūracijos aprašas palengvina kitus priežiūros darbus.
Kada modernizuoti, o kada perrašyti dalį sistemos
Ne kiekvieną PHP 5.6 kodą verta išsaugoti tokį, koks jis yra. Jei modulis remiasi nebeveikiančia biblioteka, neturi aiškių atsakomybių ir jo pataisymas kainuoja daugiau nei ribotas perrašymas, racionaliau izoliuoti ir perkurti būtent tą dalį. Pavyzdžiui, seną failų importą, ataskaitų generatorių ar mokėjimo integraciją galima pakeisti atskiru, testuojamu moduliu neperrašant visos sistemos.
Visos platformos perrašymas nuo nulio dažnai atrodo patrauklus, tačiau jis reiškia naują projekto riziką: reikia iš naujo atkurti daug metų kauptas išimtis, vartotojų įpročius ir retus procesus. Veikianti sistema paprastai turi daugiau verslo taisyklių, nei matyti pirmame susitikime. Todėl modernizavimas etapais dažnai leidžia greičiau sumažinti saugumo riziką ir kartu išlaikyti veiklos tęstinumą.
Jei trūksta vidinės techninės komandos, „Stuff“ darbus pradeda nuo audito ir aiškaus prioritetų sąrašo, o pakeitimai atliekami tiesiogiai su programuotoju, kuris analizuoja ir kodą, ir serverio aplinką. Svarbiausia ne pasiekti gražų versijos numerį, o po kiekvieno etapo turėti patikrintą sistemą, kuria verslas gali pasitikėti kitą darbo dieną.