Kāpēc garlaicīgi programmatūras migrācijas projekti varētu būt jūsu slepenais ierocis?

Izpētiet šo pretējo pieeju, kā paātrināt savu ceļu, lai kļūtu par kaujās izturīgu programmatūras izstrādātāju/līderi.

Manā 14 gadu inženierzinātņu pieredzē es redzēju, ka daudzi cilvēki pieņem lēmumus par karjeru, pamatojoties uz iespēju strādāt pie pavisam jauna pakalpojuma. Šajā lēmumā nav nekā slikta. Tomēr šodien mēs izstrādāsim pretrunīgu piemēru par darbu pie garlaicīgiem migrācijas projektiem. Savas karjeras sākumā es neapzinājos, ka lielākā daļa no manām programmatūras izstrādes pamatmācībām bija no projektiem, kas bija migrācijas projekti, piemēram, pamatā esošā datu krātuves migrēšana uz citu mākoņa tehnoloģiju vai monolīta pakalpojuma novecošana par labu jauniem mikropakalpojumiem utt.

Tas ir tāpēc, ka migrēšana pēc savas būtības ir grūta: jūs esat spiests izpildīt, ja ne pat pārsniegt, esošu ierobežojumu attiecībā uz pieejamību, mērogu, latentumu un klientu pieredzi, ko gadu gaitā ir izveidojuši un pilnveidojuši vairāki inženieri. Jūs nesaskarieties ar šiem ierobežojumiem pavisam jaunā sistēmā, jo jūs varat tos definēt. Ne tikai tas, ka neatkarīgi no tā, cik rūpīgi veicat migrēšanu, skapī būs paslēpti skeleti, ar kuriem rīkoties, pārejot uz jaunām sistēmas daļām (skatiet šo interesanto rakstu par to, kā Doordash migrācija no Int uz BigInt datu bāzes laukam bija saistīta ar bloķētājiem).

Šie projekti liek jums rūpīgi pārdomāt testēšanas metodoloģiju, jaunu sistēmu rezultātu precizitāti, programmatūras izlaišanas plāniem, programmatūras atcelšanas plāniem utt., lai jūs vienmēr nebūtu jāuztraucas par darbu pie pilnīgi jaunas sistēmas, jo nav esošo klientu, kurus apkalpojat. Garlaicīgākais ir tas, ka esošajiem klientiem nevajadzētu zināt, ka jūs faktiski nomainījāt pamatā esošo sistēmu vai kodu bāzi bez viņu ziņas.

1. Bet vai jums tiešām ir nepieciešama migrācija?

Es bieži redzu jaunus inženierus, kuri vēlas izmēģināt jaunu tehnoloģiju un aizstāt esošo funkcionalitāti, vai kādu, kas vēlas veikt pilnīgu koda bāzes pārveidošanu . Ja šīs ir ierobežotas izmaiņas (piem., izmantojot labi pārbaudītu atvērtā koda bibliotēku, lai veiktu nelielu darbību pakalpojumā utt.), Man tas nav iebildumi. Bet, ja tās ir lielas arhitektūras izmaiņas vai visas koda bāzes pārstrādāšana, ir svarīgi atcerēties slaveno inženiertehnisko principu “Respektēt to, kas bija pirms tam.” (Man šis tvīts šķita smieklīgs, un tas atsaucas uz mantoto kodu kā leģendāru kodu.)

Atgriežoties pie migrācijas projektiem, vienmēr ir prātīgi izvērtēt, vai to pašu problēmu var novērst ar salīdzinoši mazāku piepūli, nevis veicot pamatīgu kodu bāzes vai arhitektūras remontu. Taču pievilcība izmantot jaunu tehnoloģiju vai dizaina modeli vienmēr ir vilinoša, tāpēc kā mēs vērtējam šo lēmumu? Šeit ir daži jautājumi un apsvērumi, kas palīdzēs jums sākt darbu, pirms sākat migrācijas ceļojumu.

1. Vai bizness (vai klientu pieredze) tiek negatīvi ietekmēts vai tas tiks ietekmēts nākotnē, ja mēs neatrisināsim šo problēmu un vai komanda ir izmantojusi visas iespējas, kā to atrisināt, neveicot lielu migrācijas projektu? Izvēlieties atsauksmi no cita vecākā inženiera, kurš nav jūsu komandā un var darboties kā velna aizstāvis, lai pārbaudītu jūsu argumentāciju. Daži pamatojuma piemēri varētu būt veiklības uzlabošana par 4 izstrādātāja mēnešiem katrai funkcijas palaišanai, dažādu tehnoloģiju steks izmantošana dažādiem pakalpojumiem, lai uzlabotu p99 latentumu par 400 ms, mērogošanas vājo vietu novēršana ārpus X TPS utt. Vienmēr meklējiet domstarpības, lai šādās situācijās izjauktu jūsu apstiprinājuma novirzi.

   
   

2. Salīdziniet centienus veikt migrāciju ar ieguvumiem, ko tā dos, lai jūs varētu novērtēt, cik ilgs laiks būs nepieciešams, lai sāktu izmantot projekta priekšrocības. Personīgais piemērs, ar kuru varu dalīties, ir šāds:

   • Manai komandai piederēja divas atsevišķas sistēmas, kas apkalpo divas dažādas klientu bāzes, un katras jaunas funkcijas palaišanas gadījumā komandai bija jāveic līdzīgas, bet ne precīzas izmaiņas šajās atsevišķajās sistēmās. Kopumā dublēšanās radīja papildu pūles 1 izstrādātājam mēnesī par katru funkciju. Mēs katru gadu izlaidām aptuveni 4 šādas funkcijas, kā rezultātā izstrādātājs 4 mēnešus dublēja vai veltīja pūles. Tas inženieriem sagādāja vilšanos. Viens no inženieriem nāca klajā ar priekšlikumu apvienot šīs divas sistēmas un aprēķināja, ka darbs būs 24 izstrādātāja mēneši. Lai komanda sāktu izmantot migrācijas priekšrocības, būtu nepieciešami 24 funkciju palaišanas gadījumi un 6 gadi (pieņemot, ka gadā tiek palaists 4 līdzekļi). Mēs neveicām migrēšanu un pārgājām uz alternatīvu pieeju, izmantojot koplietojamas bibliotēkas, lai par 50% samazinātu dublēšanas piepūli, un vēlāk mēs pēc 3 gadiem sistēmas novecojām, izvēloties citu pakalpojumu.

     
     

3. Dažos gadījumos migrēšana ir no augšas uz leju vērsts norādījums, lai sasniegtu plašāku mērķi (piemēram, Amazon pāriet no Oracle ), kur jūs joprojām varat veikt analīzi, taču jums nav jāsaņem apstiprinājums, lai turpinātu projektu.

Kad esat identificējis pareizos pamatojumus migrācijas veikšanai un pārbaudījis argumentāciju ar dažiem ārējiem inženieriem vai vadītājiem, ir pienācis laiks pāriet uz nākamajām darbībām.

2. Sistēmas izkārtojuma funkcionālās un nefunkcionālās prasības

Tas ir līdzīgi tam, ko jūs darītu, gatavojoties sistēmas dizaina intervijai . Kad funkcionālās un nefunkcionālās prasības ir noteiktas, ir prātīgi pagaidām aizmirst par esošo sistēmu un izklāstīt, kā veidotu jaunu sistēmu, ja nebūtu nekādu ierobežojumu.

Šī uzdevuma veikšanas iemesls ir tas, ka daudziem esošajiem komandas locekļiem būs neapzināta aizspriedumi, lai izveidotu jaunu sistēmu, kas ļoti neatšķiras no esošās sistēmas, daudzos gadījumos pārspējot pašu migrācijas mērķi. Apsveriet citu piemēru no manas pagātnes:

• Mēs bijām nolēmuši atteikties no lokālas SQL datu bāzes mērogošanas vājo vietu un uzturēšanas problēmu dēļ. Tas notika tāpēc, ka mūsu pakalpojums izmantoja SQL datu bāzi kā plānošanas programmu, lai izsekotu ar krājumiem saistītus atjauninājumus. Mēs katru sekundi aizpildījām vairākus sarežģītus vaicājumus SQL datu bāzē, kas bija izšķērdīgi. Mūsu inženieri iepazīstināja ar dizainu mūsu SQL datu bāzes aizstāšanai ar mākoņa SQL datu bāzi . Pamatojums bija tāds, ka mākoņa SQL bija mērogojamāks, taču mēs faktiski darījām savu problēmu, kas radās no sliktiem modeļiem, uz mākoņtehnoloģiju. Mums vajadzēja labot slikto modeli, nevis novirzīt problēmu uz mākoņtehnoloģiju. Galvenais inženieris vadīja mūsu pieeju, lai izveidotu uz notikumiem balstītu sistēmu, izmantojot Pub/Sub paziņojumu un straumēšanas rindu (piem., Kafka vai AWS Kinesis u.c.), kas tika mērogoti par vairākiem lielumiem labāk nekā mūsu sākotnējais priekšlikums.

Iesaistot kādu pieredzējušāku, kurš nestrādāja ar esošajām sistēmām, saruna tika virzīta uz pilnīgi atšķirīgu sistēmu, kas bija mērogojamāka, reāllaika un vieglāk uzturējama. Tomēr tas ne vienmēr ir iespējams, taču nav par ļaunu mēģināt veikt šo vingrinājumu.

Ja veicat līdzīgu migrāciju, kā mēs ierosinājām iepriekš (ti, pārvietojat lokālu SQL DB uz mākoņa SQL DB), iespējams, jums būs vieglāk izpildīt nefunkcionālās prasības. Tomēr, ja jūsu gala sistēma krasi atšķiras no pašreizējās sistēmas, jums vajadzētu vismaz mēģināt salabot sistēmā iebūvēto pretmodeli. Piemēram, tā vietā, lai pieprasītu atjaunināšanas izmaiņas datu bāzē, varat publicēt paziņojumu par izmaiņām, izmantojot Pub/Sub pakalpojumu abonentiem.

Tomēr, tāpat kā katrs projekts sadalītās sistēmās, migrācijai būs kompromisi attiecībā uz nefunkcionālām prasībām, un jums tas būs jāplāno. Piemēram, ja ir monolīts pakalpojums ar 99,9% pieejamību, kas apstrādā divus atsevišķus ar uzņēmējdarbību saistītus aprēķinus (piegādes datuma aprēķins un piegādes izmaksu aprēķins), un mēs nolemjam sadalīt šo atbildību divos mikropakalpojumos A (piegādes datuma aprēķins) un B (piegādes maksas aprēķins), katrs ar pieejamību 99%, tad sistēmas pieejamība kopumā kļūst par 99%.

P(A) * P (B) = 0,999 * 0,999 = 99,8% pieejamība

Izveidojot mikropakalpojumus no monolīta, pieejamība tika samazināta no 99,9% līdz 99,8%.

Vienmēr atcerieties, ja jums ir nepieciešami 'n' pakalpojumu izsaukumu rezultāti (secīgi vai paralēli pakalpojumu zvani), lai atbildētu klientam, jūs reiziniet katra 'n' pakalpojuma individuālo pieejamību, lai iegūtu sistēmas galīgo pieejamību.

Lai sasniegtu vai pārsniegtu sistēmas sākotnējo pieejamību (ti, 99,9%), mums būs jādomā par citiem paņēmieniem, piemēram, saglabāšanu kešatmiņā, atkārtojumiem utt. Taču katrai no šīm iespējām ir savi trūkumi. Piemēram, kešatmiņa dažos gadījumos var nozīmēt, ka jūsu sistēmai ir jāspēj izturēt novecojušus datus; mēģinājumi var palielināt aizkavi un padarīt sistēmu jutīgu pret atkārtotu mēģinājumu vētrām utt.

Tomēr, veicot šo uzdevumu, jūs varat redzēt, vai jūs vismaz atbilstat esošajām nefunkcionālajām prasībām vai arī jums ir nepieciešams vadības apstiprinājums par jaunām nefunkcionālām prasībām, kuras vēlaties nodrošināt saviem klientiem.

3. Vai klientiem ir jāveic kādas darbības?

Izmantojot jaunu sistēmu, jūsu klienti pieņems jūsu jauno klienta versiju. Izmantojot migrācijas projektus, iespējams, būs jārisina problēma, ja visi klienti nevar migrēt uz jauno klienta versiju (ti, domājot par atpakaļejošu saderību). Ja visi jūsu klienti ir uzņēmuma iekšēji vai jums ir ierobežota adopcija ārpus uzņēmuma, varat strādāt ar visiem klientiem, lai pārvietotu tos uz jaunu klienta versiju.

Citos gadījumos tas vienkārši nav iespējams. Piemēram, ja jums pieder liels mākoņpakalpojums, kas ir plaši izmantots šajā nozarē, jūs nevarat piespiest visus klientus pāriet uz jaunu klienta versiju. Tas var radīt ievērojamus bloķētājus, kā arī papildu uzturēšanas izmaksas komandai, un dažos gadījumos risinājums ir uzturēt divas sistēmas versijas, ja vecākā sistēma ir uzturēšanas režīmā (ti, šai sistēmai netiek pievienoti jauni klienti), un jūs mudināt vecākus klientus pāriet uz jaunāku sistēmas versiju, jo tas ir uzlabojis klientu priekšrocības.

Tomēr, ja jums ir tāda situācija kā saite, kuru es kopīgoju iepriekš ar Doordash, kad, izmantojot Int kā primārās atslēgas datu tipu, tiks pārpildīts, jums nav citas izvēles, kā piespiest ikvienu veikt migrāciju.

4. Vai līdzīgas migrācijas jau ir veiktas?

Veidojot jaunas sistēmas, lielākā daļa inženieru paveic brīnišķīgu darbu, aptverot gandrīz visus lietošanas gadījumus. Tomēr ar migrēšanu notiek otrādi, jo jūs strādājat ar sistēmu, kuru pirms jums izstrādāja, laboja un uzturēja desmitiem, ja ne simtiem inženieru. Pat ja vēlaties uzzināt par katru lietošanas gadījumu, koda ceļu vai sistēmas vājo vietu, ir grūti aptvert visu pakalpojumu.

Šādos gadījumos visvienkāršākais ir meklēt informāciju no komandām, vecākajiem inženieriem utt., kuri ir veikuši līdzīgas migrācijas par to, kādus procesus varat sekot, lai segtu savas aklās zonas. Daudzi uzņēmumi ievēro plašāku organizācijas līmeņa dizaina un migrācijas pārskatu procesu. Meklējiet domstarpības kā svētu procesa daļu, lai nostiprinātu savu pieeju un izpratni. Migrācijas ir pilnas ar sauszemes mīnām, kas paklūst neparedzētā veidā.

Lielākā daļa migrācijas gadījumu parasti ir vienā no divām tālāk norādītajām kategorijām vai kādā no abām kombinācijām:

1. Pakalpojumu migrēšana: esoša pakalpojuma novecošana par labu jaunai arhitektūrai, kas var ietvert pašreizējā pakalpojuma daļu un jauna pakalpojuma izmantošanu vai jaunu mikropakalpojumu palaišanu, lai aizstātu esošo sistēmu.

   
   

2. Datu krātuves migrēšana: esošā datu krātuves novecošana un aizstāšana ar jaunu datu krātuvi vai uz notikumiem balstītas sistēmas izmantošana.

Pat ja neatrodat precīzu migrācijas piemēru, vienmēr varat iegūt plašāku informāciju par šiem segmentiem. Mana personīgā pieredze liecina, ka datu krātuves migrēšana bija visgrūtākā, jo pastāv bažas par datu precizitāti, ko ietekmē konsekvences problēmas starp vecajiem un jaunajiem datu krātuvēm. Piemēram, lietotājs var redzēt vecāku datu versiju no jauna datu krātuves aizkavēšanās dēļ.

5. Veco un jauno sistēmu darbība paralēli

Paralēli darbinot esošās un jaunas sistēmas, vienlaikus apkalpojot tikai esošās sistēmas datus, varat salīdzināt abu sistēmu rezultātus ar reāliem klientu pieprasījumiem. Šis ir visnoderīgākais un efektīvākais solis, lai salīdzinātu un pārbaudītu, vai jūsu jaunā sistēma darbojas pareizi.

Daudzus gadus atpakaļ es strādāju pie pakalpojuma migrēšanas uz jaunu tehnisko steku. Ikreiz, kad mūsu vecais pakalpojums saņēma klientu pieprasījumus, mēs veicām paralēlu asinhronu zvanu uz mūsu jauno pakalpojumu aizmugursistēmā. Mēs reģistrētu esošos un jaunos pakalpojumu rezultātus S3 vietā. Pēc tam dienas beigās veicām AWS Athena vaicājumu, lai noskaidrotu visas neatbilstības un identificētu visas problēmas ar jauno pakalpojumu. Tas joprojām bija nedaudz paredzams, salīdzinot ar citu sarežģītu migrāciju, ko apstrādājām ar datu krātuvi.

Mēs pārvietojām veco SQL datu krātuvi uz jaunu NoSQL datu krātuvi, kas tika aizpildīta no uzticamāka un jauna datu avota. Tomēr laiks, kad tika atjauninātas noteiktas atslēgas starp vecajiem un jaunajiem datu krātuvēm, bija neparedzams, jo tās nāca no divām pilnīgi atšķirīgām sistēmām.

Pēc tam, kad nesekmīgi izmēģinājām vairākas metodes, lai salīdzinātu datus starp vecajiem un jaunajiem datu krātuvēm, mēs sadarbojāmies ar mūsu iepriekšējām komandām, lai atbrīvotu datu atslēgu versijas, lai mēs varētu veikt datu precizitātes salīdzināšanu noteiktai atslēgai, izmantojot versijas starp abām sistēmām. Tas bija izmests darbs, jo mums nebija vajadzīgas versijas pēc projekta, taču nebija citas iespējas, kā ar to rīkoties.

6. Gaidīt, ka lietas noies greizi: vai varat atgriezties iepriekšējā pasaulē?

Pat pēc 5. darbības veikšanas, kurā varējāt precīzi salīdzināt vecās un jaunās sistēmas rezultātus, ir pilnīgi iespējams, ka jūs nekad nesasniedzat noteikta veida pieprasījumu no dažiem klientiem, kuri reti izmanto jūsu sistēmu. Esmu zaudējis miegu, strādājot pie dažiem no šiem migrācijas projektiem, domājot: "Ko darīt, ja jaunajā sistēmā viss noiet greizi?"

Vienkāršākais veids, kā to atrisināt, bija izslēgšanas slēdzis uz jauno sistēmu, ja mūsu trauksmes signāli uztvēra kaut ko negaidītu vai mēs to aktivizējām manuāli, lai pārvietotu trafiku atpakaļ uz veco sistēmu. Ņemiet vērā, ka tas nav tik vienkārši, kā izklausās. Dažos gadījumos var nebūt iespējas pāriet uz vecāku sistēmu, taču šīs sviras izmantošana atvieglos lielu spiedienu uz komandu.

Gadījumos, kad tas nav iespējams, jūsu vienīgais paļaušanās punkts ir rūpīgi veikt 5. darbību (veco un jauno sistēmu paralēla darbība). Tam seko lēna un pakāpeniska jaunās sistēmas ieviešana. Varat definēt lēnu pakāpenisku izlaišanu, izmantojot tādas metodes kā nelielas datplūsmas procentuālās daļas pārvietošana (1%, kam seko 5%, 10%, 25%, 50%, 100%), ko apkalpos jauns pakalpojums, vai dažu klientu manuālu atlasi, kurus apkalpot jauns pakalpojums, ar kuriem cieši sadarbojaties migrācijas laikā utt.

Ir arī svarīgi plaši pārskatīt incidentu reaģēšanas rokasgrāmatu, kas operatoriem jāievēro, ja kaut kas noiet greizi. Ja viss neizdodas, manuāla iejaukšanās var palīdzēt novērst gadījumus, kas tika palaisti garām, taču tas var ātri kļūt nekontrolējams, ja ietekmēto klientu skaits pieaugs līdz tūkstošiem. Tas ir iemesls, lai atvēlētu pietiekami daudz laika 5. un 6. punktā aprakstītajām fāzēm.

Secinājums

Lai gan darbs pie migrācijas nav vienīgais veids, kā uzlabot dažas no šīm prasmēm, tas noteikti var paātrināt jūsu mācīšanos, ko varat izmantot savos turpmākajos projektos, pat ja tas nozīmē, ka tās ir pavisam jaunas iniciatīvas. Migrācijas projekti ir mazāk krāšņi, taču tie mani lika pārbaudīt, it īpaši, ja es sniedzu atsauksmes par dizaina dokumentiem vai citiem tehniskajiem dokumentiem.

Tātad, ja jums ir iespēja strādāt pie viena, izmēģiniet to: jūs nebūsiet vīlušies un iegūsit visas karjeras mācīšanos, ko, cerams, nodosit citiem, lai izveidotu elastīgas sistēmas .