Denetan eragina izan zuen zabalkunde istorio bat

Errealitatearen etsaiak 12f-2 arabera

Apirilaren amaieran, White Walkers Winterfell setiatzen ari zirela, zerbait interesgarriagoa gertatu zitzaigun; ezohiko zabalkundea egin genuen. Printzipioz, etengabe ari gara funtzionalitate berriak zabaltzen ekoizpenera (beste guztiak bezala). Baina hau ezberdina zen. Horren tamainak egin ditzakegun akatsek gure zerbitzu eta erabiltzaile guztiei eragingo liekeela izan zen. Ondorioz, guztia aurreikusitakoaren arabera zabaldu genuen, aurreikusitako eta iragarritako geldialdi-epearen barruan, salmentetan ondoriorik gabe. Artikulua nola lortu dugun eta edonork etxean errepika dezakeenari buruzkoa da.

Ez ditut orain hartu ditugun erabaki arkitektoniko eta teknikoak deskribatuko, ezta nola funtzionatzen duen esango ere. Hauek marjinetako oharrak dira, ikusi nuen eta zuzenean parte hartu nuen inplementazio zailenetako bat nola gertatu zen. Ez dut osotasunik edo xehetasun teknikorik aldarrikatzen; agian beste artikulu batean agertuko dira.

Aurrekariak + zer funtzio mota da hau?

Hodeiko plataforma bat eraikitzen ari gara Mail.ru Cloud Solutions (MCS), non zuzendari tekniko gisa lan egiten dut. Eta orain IAM (Identitatea eta Sarbideen Kudeaketa) gehitzeko garaia da gure plataformara, erabiltzaile-kontu, erabiltzaile, pasahitz, rol, zerbitzu eta beste guztien kudeaketa bateratua eskaintzen duena. Hodeian zergatik behar den galdera agerikoa da: erabiltzailearen informazio guztia bertan gordetzen da.

Normalean, horrelako gauzak edozein proiekturen hasieran eraikitzen hasten dira. Baina historikoki gauzak apur bat desberdinak izan dira MCSn. MCS bi zatitan eraiki zen:

• Openstack bere Keystone baimen-modulu propioarekin,
• Hotbox (S3 biltegiratzea) Mail.ru Cloud proiektuan oinarrituta,

horren inguruan zerbitzu berriak agertu ziren orduan.

Funtsean, bi baimen mota ezberdin ziren. Gainera, Mail.ru-ren garapen bereizi batzuk erabili genituen, adibidez, Mail.ru pasahitz biltegiratze orokorra, baita norberak idatzitako openid konektore bat ere, eta horri esker SSO (muturrerako baimena) eskaintzen zen Horizon panelean. makina birtualen (OpenStack UI natiboa).

Guretzat IAM egiteak sistema bakar batean konektatzea esan nahi zuen, guztiz gurea. Aldi berean, ez dugu inongo funtzionaltasunik galduko bidean, baina etorkizunerako oinarri bat sortuko dugu, gardentasunez findu ahal izateko birfaktorizatu gabe eta funtzionaltasun aldetik eskalatzeko. Hasieran ere, erabiltzaileek zerbitzuetara sartzeko eredu bat izan zuten (RBAC zentrala, roletan oinarritutako sarbide-kontrola) eta beste gauza txiki batzuk.

Zeregin ez zen hutsala izan zen: python eta perl, hainbat backend, modu independentean idatzitako zerbitzuak, hainbat garapen talde eta administratzaile. Eta garrantzitsuena, zuzeneko milaka erabiltzaile daude borroka-ekoizpen-sisteman. Hori guztia idatzi eta, batez ere, hildakorik gabe zabaldu behar zen.

Zer zabalduko dugu?

Oso gutxi gora behera esateko, 4 hilabete inguru hauetan honako hau prestatu genuen:

• Aurretik azpiegituraren zati ezberdinetan funtzionatzen zuten funtzioak batzen zituzten hainbat deabru berri sortu genituen. Gainerako zerbitzuei backend berri bat agindu zitzaien deabru horien moduan.
• Pasahitzen eta gakoen biltegiratze zentrala idatzi genuen, gure zerbitzu guztietarako erabilgarri, behar dugun moduan libreki alda daitekeena.
• Keystonerako 4 backend berri idatzi genituen hutsetik (erabiltzaileak, proiektuak, rolak, rol-esleipenak), zeinak, hain zuzen ere, bere datu-basea ordezkatu zuen, eta orain gure erabiltzaileen pasahitzen biltegi bakar gisa jarduten du.
• Gure Openstack zerbitzu guztiei irakatsi genien hirugarrenen politika-zerbitzu batera joatea beren gidalerroetarako gidalerro hauek zerbitzari bakoitzetik lokalean irakurri beharrean (bai, horrela dabil Openstack-ek lehenespenez!)

Halako birlanketa handi batek aldaketa handiak, konplexuak eta, batez ere, sinkronoak eskatzen ditu garapen talde ezberdinek idatzitako hainbat sistemetan. Behin muntatuta, sistema osoak funtzionatu beharko luke.

Nola zabaldu horrelako aldaketak eta ez izorratu? Lehenik eta behin, etorkizunera apur bat begiratzea erabaki genuen.

Zabaltzeko estrategia

• Posible litzateke produktua hainbat fasetan zabaltzea, baina horrek garapen-denbora hiru aldiz handituko luke. Gainera, denbora batez datu-baseetako datuen erabateko desinkronizazioa izango genuke. Zure sinkronizazio tresnak idatzi eta hainbat datu biltegirekin bizi beharko zenuke denbora luzez. Eta horrek askotariko arriskuak sortzen ditu.
• Erabiltzailearentzat gardenki presta zitekeen guztia aldez aurretik egin zen. 2 hilabete behar izan zituen.
• Zenbait orduz geldialdi-denbora onartu genuen - erabiltzaileen eragiketak baliabideak sortzeko eta aldatzeko soilik.
• Jada sortutako baliabide guztien funtzionamendurako, geldialdi-denbora onartezina zen. Inplementazio garaian baliabideek etenaldirik gabe funtzionatu behar zutela aurreikusi genuen eta bezeroei eraginik.
• Gure bezeroengan eragina murrizteko zerbait gaizki ateratzen bada, igande arratsaldean zabaltzea erabaki genuen. Bezero gutxiagok kudeatzen dituzte makina birtualak gauez.
• Gure bezero guztiei ohartarazi genien zabaltzeko aukeratutako epean zerbitzuen kudeaketa ez dela erabilgarri egongo.

Digresioa: zer da zabaltze bat?

<kontuz, filosofia>

IT espezialista bakoitzak erraz erantzun dezake zer den hedapena. CI/CD instalatzen duzu, eta dena automatikoki entregatzen da dendara. 🙂

Jakina, hau egia da. Baina zailtasuna da kodea entrega automatizatzeko tresna modernoekin, hedapenaren ulermena galtzen dela. Nola ahazten zaren gurpilaren asmakizunaren epikotasuna garraio modernoari begira. Dena hain automatizatuta dago, non zabaltzea sarritan irudi osoa ulertu gabe egiten da.

Eta argazki osoa honelakoa da. Lanak lau alderdi nagusi ditu:

1. Kodea bidaltzea, datuak aldatzea barne. Adibidez, haien migrazioak.
2. Kodea atzera botatzeko gaitasuna da zerbait gaizki gertatzen bada. Adibidez, babeskopiak sortuz.
3. Inplementatze/itzuli eragiketa bakoitzaren denbora. Lehenengo bi puntuetako edozein eragiketaren denbora ulertu behar duzu.
4. Eragindako funtzionaltasuna. Beharrezkoa da espero diren ondorio positiboak eta posible negatiboak ebaluatzea.

Alderdi horiek guztiak kontuan hartu behar dira arrakastaz zabaltzeko. Normalean lehenengo puntua, edo, kasurik onenean, bigarrena bakarrik ebaluatzen da, eta gero zabaltzea arrakastatsutzat jotzen da. Baina hirugarren eta laugarrena are garrantzitsuagoa da. Zein erabiltzaileri gustatuko litzaioke inplementazioak minutu baten ordez 3 ordu behar baditu? Edo alferrikako zerbait kaltetzen bada zabaltzean? Edo zerbitzu baten geldialdiak ezusteko ondorioak ekarriko ditu?

1..n akta, kaleratzeko prestaketa

Hasieran gure bilerak labur deskribatzea pentsatu nuen: talde osoa, bere atalak, eztabaida pila kafe-guneetan, eztabaidak, probak, ideia-jasa. Orduan pentsatu nuen ez zela beharrezkoa izango. Lau hilabeteko garapena beti datza, batez ere etengabe entregatu daitekeen zerbait idazten ez duzunean, zuzeneko sistema baten ezaugarri handi bat baizik. Horrek zerbitzu guztiei eragiten die, baina erabiltzaileentzat ez da ezer aldatu behar "web interfazeko botoi bat" izan ezik.

Bilera berri bakoitzetik nola zabaldu dugun ulermena aldatu egin da, eta nabarmenki. Adibidez, gure fakturazio datu-base osoa eguneratuko genuen. Baina denbora kalkulatu genuen eta konturatu ginen ezinezkoa zela arrazoizko zabaltze-denbora batean egitea. Ia aste bat gehiago behar izan dugu fakturazio datu-basea zatitu eta artxibatzeko. Eta espero den zabaltze-abiadura oraindik asegarria ez zenean, hardware osagarri eta indartsuagoa eskatu genuen, non oinarri osoa arrastaka zegoen. Ez da hori lehenago egin nahi ez genuenik, baina egungo zabaltzeko beharrak aukerarik gabe utzi gaitu.

Gutako batek inplementazioak gure makina birtualen erabilgarritasunari eragin ziezaiokeen zalantza izan zuenean, astebete eman genuen probak, esperimentuak, kode-analisiak egiten eta gure ekoizpenean hori ez zela gertatuko ulertu genuen, eta zalantzazkoenek ere ados zeuden. honekin.

Bitartean, laguntza teknikoko mutilek beren esperimentu independenteak egin zituzten bezeroentzako argibideak idazteko konexio-metodoei buruz, zabaldu ondoren aldatu behar zirenak. Erabiltzaileen UX landu zuten, argibideak prestatu eta kontsulta pertsonalak eskaini zituzten.

Posible ziren zabaltze-eragiketa guztiak automatizatu ditugu. Eragiketa bakoitza scripted zen, sinpleenak ere, eta probak etengabe egiten ziren. Zerbitzua desaktibatzeko modurik onenari buruz eztabaidatu zuten: deabrua baztertu edo zerbitzurako sarbidea blokeatu suebaki batekin. Taldeen kontrol-zerrenda bat sortu dugu zabaltze-fase bakoitzerako eta etengabe eguneratu dugu. Gantt diagrama bat marraztu eta etengabe eguneratu genuen zabaltze-lan guztietarako, ordutegiekin.

Eta beraz…

Azken ekintza, zabaldu aurretik

... zabaltzeko garaia da.

Esaten den bezala, artelan bat ezin da bukatu, lantzen amaitu baino ez. Borondatezko ahalegina egin behar duzu, dena aurkituko ez duzula ulertuz, baina arrazoizko suposizio guztiak egin dituzula sinetsita, kasu posible guztiak eskaini, akats kritiko guztiak itxi eta parte-hartzaile guztiek ahal zuten guztia egin duzula. Zenbat eta kode gehiago zabaldu, orduan eta zailagoa da zure burua honetaz konbentzitzea (gainera, denek ulertzen dute ezinezkoa dela dena aurreikustea).

Ezusteko afektuekin eta geldialdiekin lotutako arrisku guztiak estaltzeko gure erabiltzaileentzako ahal den guztia egin genuela sinetsita geundela prest geundela erabaki genuen. Hau da, edozer gaizki joan daiteke izan ezik:

1. Eragin (guretzat sakratua, preziatuena) erabiltzaileen azpiegitura,
2. Funtzionalitatea: inplementatu ondoren gure zerbitzuaren erabilerak aurrekoaren berdina izan behar du.

Zabaltzen

Bi jaurti, 8 ez oztopatu

Erabiltzaileen eskaera guztietarako geldialdi-denbora hartzen dugu 7 orduz. Une honetan, zabaltze-plan bat eta atzera egiteko plan bat ditugu.

• Irteerak berak 3 ordu behar ditu gutxi gorabehera.
• 2 ordu probak egiteko.
• 2 ordu - erreserbatu aldaketak atzera botatzeko.

Ekintza bakoitzerako Gantt diagrama bat egin da, zenbat denbora behar den, zer gertatzen den sekuentzialki, zer egiten den paraleloan.

Hedapenerako Gantt diagrama baten zati bat, lehen bertsioetako bat (exekuzio paralelorik gabe). Sinkronizazio tresna baliotsuena

Parte-hartzaile guztiek inplementazioan duten zeregina zehaztuta dute, zer zeregin egiten dituzten eta zertaz arduratzen diren. Etapa bakoitza automatismora eramaten saiatzen gara, zabaltzen, atzera botatzen, iritzia jasotzen eta berriro zabaltzen saiatzen gara.

Gertakarien kronika

Hala, apirilaren 15an, igandea, 29:10etan XNUMX lagun etorri ziren lanera. Parte hartzaile nagusiez gain, batzuk taldeari laguntzera etorri ziren, eta horregatik eskerrak eman behar dizkiete.

Aipatzekoa da, halaber, gure funtsezko probatzailea oporretan dagoela. Ezinezkoa da probarik gabe zabaltzea, aukerak aztertzen ari gara. Lankide batek oporretan gu probatzea onartzen du, eta horregatik esker ona jasotzen du talde osoaren partetik.

00:00. Gelditu
Erabiltzaileen eskaerak geldiarazten ditugu, lan teknikoa dioen kartel bat zintzilikatzen dugu. Monitorizazioak garrasi egiten du, baina dena normala da. Erori behar zena baino ez dela ezer erori egiaztatzen dugu. Eta migrazioaren inguruan lanean hasten gara.

Denek dute inprimatutako inplementazio-plana puntuz puntu, denek daki nork zer eta zein momentutan egiten duen. Ekintza bakoitzaren ondoren, denborak egiaztatzen ditugu horiek gainditzen ez ditugula ziurtatzeko, eta dena aurreikusitakoaren arabera doa. Oraingo fasean zuzenean zabalkundean parte hartzen ez dutenak sareko jostailu bat (Xonotic, 3. motako quacks) martxan jartzen ari dira prestatzen, euren lankideak ez molestatzeko. 🙂

02:00. Atera
Sorpresa atsegina: ordubete lehenago amaitzen dugu inplementazioa, gure datu-baseen eta migrazio-scripten optimizazioaren ondorioz. Oihu orokorra, "atera!" Funtzio berri guztiak ekoizten ari dira, baina orain arte guk bakarrik ikus ditzakegu interfazean. Guztiak proba moduan sartzen dira, taldeka sailkatu eta azkenean zer gertatu den ikusten hasten da.

Ez zen oso ondo atera, 10 minuturen buruan konturatzen gara honetaz, ezer ez dagoenean konektatuta edo taldekideen proiektuetan lanean. Sinkronizazio azkarra, gure arazoak ahoskatzen ditugu, lehentasunak ezartzen ditugu, taldeetan sartzen gara eta arazketan sartzen gara.

02:30. Bi arazo handi vs lau begi
Bi arazo handi aurkituko ditugu. Konturatu ginen bezeroek ez zituztela konektatutako zerbitzu batzuk ikusiko, eta arazoak sortuko zirela bazkide-kontuekin. Biak ertz-kasu batzuen migrazio-script inperfektuengatik dira. Orain konpondu behar dugu.

Hori erregistratzen duten kontsultak idazten ditugu, gutxienez 4 begirekin. Aurreprodukzioan probatzen ditugu funtzionatzen dutela eta ezer apurtzen ez dutela ziurtatzeko. Aurrera egin dezakezu. Aldi berean, gure ohiko integrazio-probak egiten ditugu, eta horrek arazo batzuk agerian uzten ditu. Denak txikiak dira, baina konpondu egin behar dira.

03:00. -2 arazo +2 arazo
Aurreko bi arazo handiak konpondu dira, eta ia txikienak ere bai. Konponketetan okupatu gabe dauden guztiak aktiboki lanean ari dira euren kontuetan eta aurkitzen dutenaren berri ematen. Lehenesten dugu, taldeen artean banatu eta elementu ez-kritikoak uzten ditugu goizerako.

Berriro probak egiten ditugu, bi arazo handi berri aurkitzen dituzte. Zerbitzu-politika guztiak ez dira behar bezala iritsi, beraz, erabiltzaileen eskaera batzuek ez dute baimenik ematen. Gainera, arazo berri bat bazkide-kontuekin. Presa gaitezen begiratzera.

03:20. Larrialdi sinkronizazioa
Arazo berri bat konpondu da. Bigarrenerako, larrialdietako sinkronizazioa antolatzen ari gara. Gertatzen ari dena ulertzen dugu: aurreko konponketak arazo bat konpondu zuen, baina beste bat sortu zuen. Atseden bat hartzen dugu behar bezala eta ondoriorik gabe nola egin jakiteko.

03:30. Sei begi
Ulertzen dugu zein izan behar duen oinarriaren azken egoera, dena ondo joan dadin bazkide guztientzat. Eskaera bat 6 begirekin idazten dugu, aurreprodukzioan zabaltzen dugu, probatzen dugu, ekoizten.

04:00. Dena dabil
Proba guztiak gainditu dira, ez dago arazo kritikorik ikusten. Noizean behin, taldean zerbaitek ez dio balio norbaiti, berehala erreakzionatzen dugu. Gehienetan alarma faltsua da. Baina batzuetan ez da zerbait iristen, edo aparteko orrialde batek ez du funtzionatzen. Esertzen gara, konpondu, konpondu, konpondu. Aparteko talde batek azken funtzio handia abiarazten ari da: fakturazioa.

04:30. Atzera bueltarik gabeko puntua
Itzuli gabeko puntua hurbiltzen ari da, hau da, atzera egiten hasten bagara, emandako geldialdi-denbora beteko ez dugun garaia. Arazoak daude fakturazioarekin, dena ezagutzen eta erregistratzen duena, baina bezeroei dirua kentzeari uko egiten dio temati. Hainbat akats daude orrialde, ekintza eta egoera indibidualetan. Funtzionalitate nagusiak funtzionatzen du, proba guztiak arrakastaz gainditzen dira. Inplementazioa egin dela erabakitzen dugu, ez dugu atzera egingo.

06:00. Irekia UI-ko guztientzako
Akatsak konponduta. Erabiltzaileak erakartzen ez dituzten batzuk gerorako geratzen dira. Interfazea guztientzako irekitzen dugu. Fakturazioan lanean jarraitzen dugu, erabiltzaileen iritzien zain eta emaitzen jarraipenaren zain.

07:00. Arazoak API kargarekin
Argi dago gure APIan karga apur bat oker planifikatu dugula eta karga hori probatu dugula, ezin izan baitu arazoa identifikatu. Ondorioz, eskaeren % ≈5ek huts egiten du. Mobiliza gaitezen eta bila gaitezen arrazoia.

Fakturazioa burugogorra da eta ez du lanik egin nahi ere. Gerora arte atzeratzea erabakitzen dugu aldaketak lasai egiteko. Hau da, baliabide guztiak bertan pilatzen dira, baina bezeroen bajak ez dira pasatzen. Jakina, hau arazo bat da, baina hedapen orokorrarekin alderatuta ez dirudi garrantzirik.

08:00. Konpondu APIa
Kargaren konponketa bat atera genuen, hutsegiteek desagertu egin ziren. Etxera joaten hasten gara.

10:00. Denak
Dena konponduta dago. Jarraipenean lasaia da eta bezeroen lekuan, taldea pixkanaka lo egiten doa. Fakturazioa geratzen da, bihar berreskuratuko dugu.

Ondoren, egunean zehar gure bezero batzuen erregistroak, jakinarazpenak, itzultze-kodeak eta pertsonalizazioak konpondu zituzten.

Beraz, zabaltzea arrakastatsua izan zen! Hobea izan zitekeen, noski, baina perfekzioa lortzeko nahikoa ez zenari buruzko ondorioak atera genituen.

Guztira

Inplementaziorako prestaketa aktiboan 2 hilabetetan zehar, 43 zeregin burutu ziren, ordu pare batetik egun batzuetara arte.

Zabaltzean:

• deabru berriak eta aldatuak - 5 pieza, 2 monolito ordezkatuz;
• datu-baseetan aldaketak - erabiltzaileen datuak dituzten gure 6 datu-base guztiak kaltetuak izan dira, hiru datu-base zaharretik berri batera deskargatu dira;
• frontend guztiz birmoldatua;
• Deskargatutako kodearen kopurua - 33 mila kode berri lerro, ≈ 3 mila kode lerro probetan, ≈ 5 mila kode migrazio lerro;
• datu guztiak osorik daude, bezero baten makina birtual bakar bat ere ez zen kaltetu. 🙂

Jardunbide egokiak zabaltzeko

Egoera zail honetan gidatu gintuzten. Baina, oro har, komenigarria da edozein zabaltze-lanetan jarraitzea. Baina zabalkundea zenbat eta konplexuagoa izan, orduan eta rol handiagoa betetzen dute.

1. Egin behar duzun lehenengo gauza da ulertzea inplementazioak erabiltzaileei nola eragin diezaiekeen edo izango duen. Egongo al da geldialdia? Hala bada, zein da geldialdia? Nola eragingo die horrek erabiltzaileei? Zeintzuk dira kasurik onenak eta txarrenak? Eta arriskuak estali.
2. Dena planifikatu. Etapa bakoitzean, inplementazioaren alderdi guztiak ulertu behar dituzu:
   • kodea entrega;
   • kodearen itzulera;
   • eragiketa bakoitzaren denbora;
   • kaltetutako funtzionaltasuna.
3. Jokatu agertokietan zabalkundearen fase guztiak, baita horietako bakoitzaren arriskuak ere, agerikoak izan arte. Zalantzarik baduzu, atseden bat hartu eta zalantzazko etapa bereizita aztertu dezakezu.
4. Etapa bakoitza hobetu egin daiteke eta hobetu behar da gure erabiltzaileei laguntzen badie. Adibidez, geldialdi-denbora murriztuko du edo arrisku batzuk kenduko ditu.
5. Atzera egiteko probak kodea entregatzeko probak baino askoz garrantzitsuagoa da. Egiaztatu egin behar da itzuleraren ondorioz sistema jatorrizko egoerara itzuliko dela, eta hori proben bidez baieztatu.
6. Automatizatu daitekeen guztia automatizatu behar da. Automatizatu ezin daitekeen guztia aldez aurretik idatzi behar da tranpa-orri batean.
7. Grabatu arrakasta-irizpidea. Zein funtzionalitate egon behar du erabilgarri eta zein ordutan? Hori gertatzen ez bada, exekutatu atzera egiteko plan bat.
8. Eta garrantzitsuena - jendea. Pertsona orok jakin behar du zer egiten ari den, zergatik eta zerren araberakoa den zabaltze-prozesuan bere ekintzen arabera.

Eta esaldi batean, plangintza eta lanketa onarekin nahi duzun guztia zabaldu dezakezu salmentetan ondoriorik gabe. Baita ekoizpenean zure zerbitzu guztietan eragina izango duen zerbait ere.

Iturria: www.habr.com