Kāpēc lielākā daļa uzņēmumu nenovērtē migrācijas apjomu un kā atgūt kontroli, pirms nav par vēlu
Klusais spiediens pamest Oracle
Daudziem CTO un IT vadītājiem Oracle → PostgreSQL migrācija vairs nav drosmīga modernizācijas ideja. Tā ir pakāpeniski pieaugošs spiediens.
Licenču izmaksas turpina pieaugt. Viena piegādātāja risks ierobežo elastību. Novecojušas platformas palēnina produktu attīstību. Valdes sāk uzdot neērtus jautājumus par nākotnes riskiem.
Tomēr, neskatoties uz šo spiedienu, daudzas organizācijas vilcinās, jo patiesais risks ir grūti definējams. “Palikt ir dārgi. Bet mēs neesam pārliecināti, cik maksās aiziešana.”
Tieši šī nenoteiktība ir vieta, kur daudzi migrācijas projekti sāk klusi noiet no kursa.
Pirmā kļūda: pieņēmums, ka migrācijas izmaksas slēpjas datos
Sākotnējās sarunās par migrāciju parasti uzmanība tiek pievērsta:
- datubāzes izmēram
- shēmu skaitam
- tabulām un indeksiem
- infrastruktūrai un hostēšanai
Šie elementi ir redzami, pazīstami un relatīvi viegli novērtējami. Taču tie reti kļūst par projekta neveiksmes cēloni.
Patiesais izmaksu faktors parasti slēpjas citur, PL/SQL procedurālajā kodā.
Gadu desmitos tajā ir uzkrāta biznesa loģika:
- pakotnēs (packages)
- procedūrās
- funkcijās
- trigeros
- Oracle specifiskos konstruktoros
Šis kods bieži ir rakstīts:
- pirms modernu versiju kontroles sistēmu ieviešanas
- bez konsekventas dokumentācijas
- komandās, kas vairs neeksistē
Šis kods nodrošina biznesa darbību, taču tikai retais var pilnībā izskaidrot, kā tas patiesībā strādā. Un tieši tur slēpjas migrācijas risks.
Slēptais slazds Nr.1: PL/SQL sarežģītība tiek atklāta pārāk vēlu
Daudzos uzņēmumu migrācijas projektos PL/SQL tiek uzskatīts par “vēlāku posmu”. Vispirms shēma. Tad dati. Procedurālais kods… vēlāk.
Līdz brīdim, kad komandas patiešām sāk analizēt PL/SQL:
- budžets jau ir apstiprināts
- termiņi jau ir apsolīti
- piegādes komandas jau ir piesaistītas
Un tikai tad sāk parādīties nepatīkamā realitāte:
- Oracle specifiski elementi, kas nepārnesas vienkārši
- cieši savstarpēji saistīta loģika simtiem objektu
- kods, kuru var migrēt tikai manuāli
Tajā brīdī komandas vairs neplāno projektu, tās mēģina ierobežot zaudējumus.
Slēptais slazds Nr.2: automatizācijas pieņēmumi bez pierādījumiem
Automatizācija bieži tiek pasniegta kā risinājums: “Mēs automatizēsim 60–70% migrācijas.”
Dažreiz tā ir taisnība, taču biežāk nē.
Automatizācijas rezultāts ir atkarīgs no:
- koda struktūras un rakstīšanas stila
- Oracle specifisku funkciju izmantošanas
- koda konsekvences
- testēšanas prasībām
Bez reālas koda analīzes automatizācijas novērtējums ir tikai minējums, un parasti optimistisks. Ja izrādās, ka automatizācijas apjoms ir mazāks nekā plānots:
- manuālais darbs strauji pieaug
- testēšanas apjoms eksplodē
- termiņi sāk slīdēt sprintu pēc sprinta
Automatizācija pati par sevi nesamazina risku. Prognozējamība to dara.
Slēptais slazds Nr.3: testēšanas apjoms sākotnējos plānos nav redzams
Migrācija nav tikai konversija. Tā ir arī uzticēšanās pārredzamam procesam.
Tas nozīmē:
- vienību testus (unit tests)
- biznesa loģikas validāciju
- regresijas testēšanu starp sistēmām
Testēšanas apjoms pieaug līdz ar sarežģītību, nevis ar datubāzes izmēru. Tomēr daudzi migrācijas plāni testēšanu rēķina kā vienkāršu procentu vai pat kā procesu, ko domāt “pēc tam”.
Rezultātā rodas situācijas, kur:
- migrētai sistēmai neviens pilnībā neuzticas
- paralēla sistēmu darbība ilgst daudz ilgāk nekā plānots
- biznesam ir grūti atteikties no Oracle
Rezultāts: dubultas izmaksas, dubulta uzturēšana un dubults stress.
Kāpēc šie slazdi atkārtojas
Pēc desmitiem modernizācijas projektu novērojumiem atkārtojas viens un tas pats modelis: Migrācijas lēmumi tiek pieņemti pirms ir pieejama reāla informācija. Excel tabulas. Augsta līmeņa pieņēmumi. Vidējie rādītāji no piegādātājiem.
Kā bieži saka LTECH klientu un IT projektu vadītājs Mārtiņš Kājiņš:
“Labus migrācijas lēmumus pieņem pirms izpildes sākuma, nevis projekta vidū.”
Kad izmaksas, riski un darba apjoms nav skaidri, organizācijas sāk cerēt:
- cerēt, ka automatizācija nosegs pietiekami daudz
- cerēt, ka sarežģītība nebūs pārāk liela
- cerēt, ka testēšana nekļūs par problēmu
Cits sākuma punkts: skaidrība pirms saistībām
Visveiksmīgākās Oracle → PostgreSQL migrācijas sākas citādi. Pirms tiek izvēlēti termiņi vai piegādātāji, komandas uzdod sev dažus būtiskus jautājumus:
- Cik sarežģīts patiesībā ir mūsu PL/SQL?
- Cik daudz var automatizēt un cik nē?
- Kur atrodas augstākā riska moduļi?
- Kāds būs testēšanas apjoms, balstoties uz reālu sarežģītību?
Lai uz to atbildētu, nepietiek ar vēl vienu plānošanas sanāksmi. Nepieciešama koda līmeņa analīze.
Tieši tāpēc LTECH izveidoja Oracle → PostgreSQL migrācijas novērtēšanas rīku– Migrafy, lai realitāti padarītu redzamu jau pašā sākumā.
Šis novērtējums:
- analizē Oracle PL/SQL kodu
- nosaka automatizācijas apjomu pret manuālo darbu
- identificē sarežģītības un riska zonas
- sagatavo CTO un vadības līmeņa pārskatus
Nav datu migrācijas. Nav viena piegādātāja risks. Nav piegādes spiediena.Tikai fakti pirms lēmumi kļūst dārgi.
Modernizācijas patiesā vērtība
Automatizācija ir noderīga. PostgreSQL ir jaudīgs. Taču patiesā vērtība ir citur:
- prognozējams budžets
- pamatoti termiņi
- mazāk pārsteigumu projekta laikā
- lielāka vadības pārliecība
Ja jūs apsverat Oracle aizstāšanu, svarīgākais solis nav izvēlēties jaunu datubāzi.
Tas ir saprast, kam jūs patiesībā gatavojaties. Skaidrība pirms saistībām maina visu.
Ja jūs apsverat Oracle → PostgreSQL migrāciju, sāciet ar to daļu, kas visbiežāk izjauc plānus : PL/SQL.
Kad slēptais darbs kļūst redzams, pārējais kļūst daudz vienkāršāks.