Një histori e hapur që preku gjithçka

Armiqtë e realitetit me 12f-2

Në fund të prillit, ndërsa White Walkers po rrethonin Winterfell-in, na ndodhi diçka më interesante; bëmë një paraqitje të pazakontë. Në parim, ne po nxjerrim vazhdimisht veçori të reja në prodhim (si gjithë të tjerët). Por ky ishte ndryshe. Shkalla e tij ishte e tillë që çdo gabim i mundshëm që mund të bënim do të ndikonte në të gjitha shërbimet dhe përdoruesit tanë. Si rezultat, ne përpunuam gjithçka sipas planit, brenda periudhës së planifikuar dhe të shpallur joproduktive, pa pasoja për shitjet. Artikulli ka të bëjë me mënyrën se si e arritëm këtë dhe si mund ta përsërisë kushdo në shtëpi.

Unë nuk do të përshkruaj tani vendimet arkitektonike dhe teknike që morëm ose nuk do të tregoj se si funksionon gjithçka. Këto janë më tepër shënime në margjina rreth asaj se si ndodhi një nga prezantimet më të vështira, të cilën unë e vëzhgova dhe në të cilën isha i përfshirë drejtpërdrejt. Unë nuk pretendoj plotësinë apo detajet teknike; ndoshta ato do të shfaqen në një artikull tjetër.

Sfondi + çfarë lloj funksioni është ky?

Ne po ndërtojmë një platformë cloud Mail.ru Cloud Solutions (MCS), ku punoj si drejtor teknik. Dhe tani është koha për të shtuar IAM (Identity and Access Management) në platformën tonë, e cila ofron menaxhim të unifikuar të të gjitha llogarive të përdoruesve, përdoruesve, fjalëkalimeve, roleve, shërbimeve dhe më shumë. Pse është e nevojshme në cloud është një pyetje e qartë: të gjitha informacionet e përdoruesit ruhen në të.

Zakonisht gjëra të tilla fillojnë të ndërtohen që në fillim të çdo projekti. Por historikisht gjërat kanë qenë pak më ndryshe në MCS. MCS është ndërtuar në dy pjesë:

• Openstack me modulin e vet të autorizimit Keystone,
• Hotbox (ruajtje S3) bazuar në projektin Mail.ru Cloud,

rreth të cilit më pas u shfaqën shërbime të reja.

Në thelb, këto ishin dy lloje të ndryshme autorizimi. Plus, ne përdorëm disa zhvillime të veçanta të Mail.ru, për shembull, një ruajtje të përgjithshme të fjalëkalimit të Mail.ru, si dhe një lidhës openid të vetë-shkruar, falë të cilit SSO (autorizimi nga fundi në fund) u sigurua në panelin Horizon i makinave virtuale (ndërfaqja e brendshme OpenStack).

Bërja e IAM-it për ne do të thoshte t'i lidhnim të gjitha në një sistem të vetëm, tërësisht tonin. Në të njëjtën kohë, ne nuk do të humbasim asnjë funksionalitet gjatë rrugës, por do të krijojmë një themel për të ardhmen që do të na lejojë ta përsosim atë në mënyrë transparente pa e rifaktoruar dhe shkallëzuar në aspektin e funksionalitetit. Gjithashtu në fillim, përdoruesit kishin një model për aksesin në shërbime (RBAC qendrore, kontrolli i aksesit i bazuar në role) dhe disa gjëra të tjera të vogla.

Detyra doli të ishte jo e parëndësishme: python dhe perl, disa backend, shërbime të shkruara në mënyrë të pavarur, disa ekipe zhvillimi dhe administratorë. Dhe më e rëndësishmja, ka mijëra përdorues të drejtpërdrejtë në sistemin e prodhimit luftarak. E gjithë kjo duhej të shkruhej dhe, më e rëndësishmja, të shpërndahej pa viktima.

Çfarë do të nxjerrim?

Për ta thënë shumë përafërsisht, në rreth 4 muaj përgatitëm sa vijon:

• Ne krijuam disa demonë të rinj që grumbulluan funksione që funksiononin më parë në pjesë të ndryshme të infrastrukturës. Pjesa tjetër e shërbimeve iu përshkrua një fund i ri në formën e këtyre demonëve.
• Ne kemi shkruar ruajtjen tonë qendrore të fjalëkalimeve dhe çelësave, të disponueshëm për të gjitha shërbimet tona, të cilat mund të modifikohen lirisht sipas nevojës.
• Ne kemi shkruar 4 backend të reja për Keystone nga e para (përdorues, projekte, role, caktime rolesh), të cilat, në fakt, zëvendësuan bazën e të dhënave të tij dhe tani vepron si një depo e vetme për fjalëkalimet tona të përdoruesve.
• Ne i mësuam të gjitha shërbimet tona Openstack që të shkojnë te një shërbim i politikave të palëve të treta për politikat e tyre në vend që t'i lexojnë këto politika në nivel lokal nga secili server (po, kështu funksionon Openstack si parazgjedhje!)

Një ripërpunim i tillë i madh kërkon ndryshime të mëdha, komplekse dhe, më e rëndësishmja, sinkron në disa sisteme të shkruara nga ekipe të ndryshme zhvillimi. Pasi të montohet, i gjithë sistemi duhet të funksionojë.

Si të hapni ndryshime të tilla dhe të mos e prishni atë? Fillimisht vendosëm të shikojmë pak në të ardhmen.

Strategjia e paraqitjes

• Do të ishte e mundur që produkti të shpërndahej në disa faza, por kjo do të rriste kohën e zhvillimit me tre herë. Përveç kësaj, për disa kohë do të kishim desinkronizim të plotë të të dhënave në bazat e të dhënave. Do t'ju duhet të shkruani mjetet tuaja të sinkronizimit dhe të jetoni me shumë dyqane të dhënash për një kohë të gjatë. Dhe kjo krijon një gamë të gjerë rreziqesh.
• Gjithçka që mund të përgatitej në mënyrë transparente për përdoruesin ishte bërë paraprakisht. U deshën 2 muaj.
• Ne i lejuam vetes kohë joproduktive për disa orë - vetëm për operacionet e përdoruesve për të krijuar dhe ndryshuar burimet.
• Për funksionimin e të gjitha burimeve të krijuara tashmë, ndërprerja ishte e papranueshme. Ne kemi planifikuar që gjatë prezantimit, burimet të funksionojnë pa ndërprerje dhe të ndikojnë tek klientët.
• Për të reduktuar ndikimin tek klientët tanë nëse diçka shkon keq, ne vendosëm të lançojmë të dielën në mbrëmje. Më pak klientë menaxhojnë makinat virtuale gjatë natës.
• Ne paralajmëruam të gjithë klientët tanë se gjatë periudhës së përzgjedhur për prezantim, menaxhimi i shërbimit nuk do të jetë i disponueshëm.

Digresioni: çfarë është një paraqitje?

<kujdes, filozofi>

Çdo specialist i IT-së mund të përgjigjet lehtësisht se çfarë është një prezantim. Ju instaloni CI/CD dhe gjithçka dorëzohet automatikisht në dyqan. 🙂

Sigurisht që kjo është e vërtetë. Por vështirësia është se me mjetet moderne të automatizimit të shpërndarjes së kodit, kuptimi i vetë prezantimit humbet. Si e harroni epitetin e shpikjes së timonit kur shikoni transportin modern. Gjithçka është aq e automatizuar saqë shpërndarja shpesh kryhet pa kuptuar tërë pamjen.

Dhe e gjithë fotografia është si kjo. Përhapja përbëhet nga katër aspekte kryesore:

1. Dorëzimi i kodit, duke përfshirë modifikimin e të dhënave. Për shembull, migrimet e tyre.
2. Rikthimi i kodit është aftësia për t'u kthyer pas nëse diçka shkon keq. Për shembull, përmes krijimit të kopjeve rezervë.
3. Koha e çdo operacioni rikthimi. Ju duhet të kuptoni kohën e çdo operacioni të dy pikave të para.
4. Funksionaliteti i prekur. Është e nevojshme të vlerësohen si efektet e pritura pozitive ashtu edhe ato negative të mundshme.

Të gjitha këto aspekte duhet të merren parasysh për një paraqitje të suksesshme. Zakonisht vlerësohet vetëm pika e parë, ose në rastin më të mirë e dyta, dhe më pas prezantimi konsiderohet i suksesshëm. Por e treta dhe e katërta janë edhe më të rëndësishme. Cili përdorues do të donte nëse prezantimi zgjati 3 orë në vend të një minutë? Apo nëse diçka e panevojshme ndikohet gjatë prezantimit? Apo ndërprerja e një shërbimi do të çojë në pasoja të paparashikueshme?

Akti 1..n, përgatitja për lirim

Në fillim mendova të përshkruaj shkurtimisht takimet tona: i gjithë ekipi, pjesët e tij, një mori diskutimesh në pika kafeje, argumente, teste, stuhi mendimesh. Atëherë mendova se do të ishte e panevojshme. Katër muaj zhvillim konsistojnë gjithmonë në këtë, veçanërisht kur nuk jeni duke shkruar diçka që mund të dorëzohet vazhdimisht, por një veçori e madhe për një sistem të drejtpërdrejtë. E cila prek të gjitha shërbimet, por asgjë nuk duhet të ndryshojë për përdoruesit përveç "një butoni në ndërfaqen e internetit".

Kuptimi ynë se si të shpërndahej ndryshoi nga çdo takim i ri, dhe mjaft domethënës. Për shembull, ne do të përditësonim të gjithë bazën e të dhënave të faturimit. Por ne llogaritëm kohën dhe kuptuam se ishte e pamundur ta bënim këtë në një kohë të arsyeshme të prezantimit. Na u desh pothuajse një javë shtesë për të copëtuar dhe arkivuar bazën e të dhënave të faturimit. Dhe kur shpejtësia e pritshme e paraqitjes nuk ishte ende e kënaqshme, ne porositëm pajisje shtesë, më të fuqishme, ku tërhiqej e gjithë baza. Nuk është se ne nuk donim ta bënim këtë më shpejt, por nevoja aktuale për të dalë në treg nuk na la pa alternativa.

Kur njëri prej nesh kishte dyshime se prezantimi mund të ndikonte në disponueshmërinë e makinave tona virtuale, kaluam një javë duke kryer teste, eksperimente, analiza kodi dhe morëm një kuptim të qartë se kjo nuk do të ndodhte në prodhimin tonë, madje edhe njerëzit më të dyshimtë ranë dakord. me këtë.

Ndërkohë, djemtë nga mbështetja teknike kryen eksperimentet e tyre të pavarura për të shkruar udhëzime për klientët mbi metodat e lidhjes, të cilat supozohej të ndryshonin pas prezantimit. Ata punuan në UX të përdoruesit, përgatitën udhëzime dhe ofruan konsultime personale.

Ne automatizuam të gjitha operacionet e paraqitjes që ishin të mundshme. Çdo operacion ishte i shkruar, madje edhe ato më të thjeshtat, dhe testet kryheshin vazhdimisht. Ata debatuan për mënyrën më të mirë për të fikur shërbimin - të hiqni demonin ose të bllokoni hyrjen në shërbim me një mur zjarri. Ne krijuam një listë kontrolli të ekipeve për secilën fazë të paraqitjes dhe e përditësuam vazhdimisht. Ne vizatuam dhe përditësuam vazhdimisht një grafik Gantt për të gjitha punët e prezantimit, me orare.

Dhe kështu…

Akti i fundit, përpara se të dalë

...është koha për të dalë.

Siç thonë ata, një vepër arti nuk mund të përfundojë, vetëm të përfundojë duke punuar në të. Ju duhet të bëni një përpjekje vullneti, duke kuptuar se nuk do të gjeni gjithçka, por duke besuar se keni bërë të gjitha supozimet e arsyeshme, të parashikuara për të gjitha rastet e mundshme, mbyllni të gjitha gabimet kritike dhe të gjithë pjesëmarrësit bënë gjithçka që mundën. Sa më shumë kod të hapni, aq më e vështirë është të bindeni për këtë (përveç kësaj, të gjithë e kuptojnë se është e pamundur të parashikoni gjithçka).

Ne vendosëm që të ishim gati të dilnim kur ishim të bindur se kishim bërë gjithçka që ishte e mundur për të mbuluar të gjitha rreziqet për përdoruesit tanë që lidhen me ndikime të papritura dhe kohë joproduktive. Kjo do të thotë, çdo gjë mund të shkojë keq përveç:

1. Ndikoni (e shenjtë për ne, më e çmuar) infrastrukturën e përdoruesit,
2. Funksionaliteti: përdorimi i shërbimit tonë pas prezantimit duhet të jetë i njëjtë si më parë.

Rrotullimi jashtë

Dy rrotullime, 8 mos ndërhyni

Ne marrim kohë joproduktive për të gjitha kërkesat nga përdoruesit për 7 orë. Në këtë kohë, ne kemi edhe një plan të shpërndarjes dhe një plan rikthimi.

• Vetë prezantimi zgjat rreth 3 orë.
• 2 orë për testim.
• 2 orë - rezervoni për një rikthim të mundshëm të ndryshimeve.

Një grafik Gantt është hartuar për çdo veprim, sa kohë duhet, çfarë ndodh në mënyrë sekuenciale, çfarë bëhet paralelisht.

Një pjesë e një grafiku Gantt, një nga versionet e hershme (pa ekzekutim paralel). Mjeti më i vlefshëm i sinkronizimit

Të gjithë pjesëmarrësit kanë përcaktuar rolin e tyre në prezantim, çfarë detyrash bëjnë dhe për çfarë janë përgjegjës. Ne përpiqemi ta sjellim çdo fazë në automatizëm, ta nxjerrim atë, ta kthejmë përsëri, të mbledhim reagime dhe ta nxjerrim përsëri.

Kronikë e ngjarjeve

Kështu, 15 persona erdhën në punë të dielën, më 29 prill, në orën 10:XNUMX. Përveç pjesëmarrësve kryesorë, disa erdhën thjesht për të mbështetur skuadrën, për çka falënderime të veçanta për ta.

Vlen gjithashtu të përmendet se testuesi ynë kryesor është me pushime. Është e pamundur të dalësh pa testim, ne jemi duke eksploruar opsione. Një kolege pranon të na testojë nga pushimet, për të cilën merr mirënjohje të pamasë nga i gjithë ekipi.

00:00. Ndalo
Ne ndalojmë kërkesat e përdoruesve, vendosim një tabelë që thotë punë teknike. Monitorimi bërtet, por gjithçka është normale. Ne kontrollojmë se nuk ka rënë asgjë tjetër përveç asaj që është dashur të bjerë. Dhe ne fillojmë punën për migrimin.

Të gjithë kanë një plan të printuar të prezantimit pikë për pikë, të gjithë e dinë se kush po bën çfarë dhe në çfarë momenti. Pas çdo veprimi, ne kontrollojmë oraret për t'u siguruar që nuk i tejkalojmë ato dhe gjithçka shkon sipas planit. Ata që nuk po marrin pjesë drejtpërdrejt në prezantim në fazën aktuale po përgatiten duke hedhur në treg një lodër në internet (Xonotic, tip 3 quacks) në mënyrë që të mos shqetësojnë kolegët e tyre. 🙂

02:00. I mbështjellë
Një surprizë e këndshme - ne e përfundojmë prezantimin një orë më herët, për shkak të optimizimit të bazave të të dhënave tona dhe skripteve të migrimit. Thirrja e përgjithshme, "shpërtheu!" Të gjitha funksionet e reja janë në prodhim, por deri më tani vetëm ne mund t'i shohim ato në ndërfaqe. Të gjithë kalojnë në modalitetin e testimit, i renditin në grupe dhe fillojnë të shohin se çfarë ndodhi në fund.

Nuk doli shumë mirë, këtë e kuptojmë pas 10 minutash, kur asgjë nuk është e lidhur apo nuk punon në projektet e anëtarëve të ekipit. Sinkronizimi i shpejtë, ne shprehim problemet tona, vendosim prioritete, ndahemi në ekipe dhe kalojmë në korrigjimin e gabimeve.

02:30. Dy probleme të mëdha kundrejt katër syve
Ne gjejmë dy probleme të mëdha. Kuptuam që klientët nuk do të shihnin disa shërbime të lidhura dhe do të lindnin probleme me llogaritë e partnerëve. Të dyja janë për shkak të skripteve të papërsosur të migrimit për disa raste të skajeve. Duhet ta rregullojmë tani.

Ne shkruajmë pyetje që e regjistrojnë këtë, me të paktën 4 sy. Ne i testojmë ato gjatë paraprodhimit për t'u siguruar që funksionojnë dhe nuk thyejnë asgjë. Mund të rrokulliset më tej. Në të njëjtën kohë, ne kryejmë testimin tonë të rregullt të integrimit, i cili zbulon disa çështje të tjera. Janë të gjitha të vogla, por kanë nevojë edhe për riparim.

03:00. -2 probleme +2 probleme
Dy problemet e mëdha të mëparshme janë rregulluar, dhe pothuajse të gjitha ato të voglat gjithashtu. Të gjithë ata që nuk janë të zënë në rregullime po punojnë në mënyrë aktive në llogaritë e tyre dhe raportojnë atë që gjejnë. Ne japim përparësi, shpërndajmë midis ekipeve dhe lëmë artikuj jo kritikë për mëngjes.

Ne kryejmë përsëri testet, ata zbulojnë dy probleme të reja të mëdha. Jo të gjitha politikat e shërbimit arritën siç duhet, kështu që disa kërkesa përdoruesish nuk kalojnë autorizimin. Plus një problem i ri me llogaritë e partnerëve. Le të nxitojmë të shikojmë.

03:20. Sinkronizimi i urgjencës
Një problem i ri u rregullua. Për të dytën, ne po organizojmë një sinkronizim urgjent. Ne e kuptojmë se çfarë po ndodh: rregullimi i mëparshëm rregulloi një problem, por krijoi një tjetër. Ne bëjmë një pushim për të kuptuar se si ta bëjmë atë saktë dhe pa pasoja.

03:30. Gjashtë sy
Ne e kuptojmë se cila duhet të jetë gjendja përfundimtare e bazës në mënyrë që gjithçka të shkojë mirë për të gjithë partnerët. Ne shkruajmë një kërkesë me 6 sy, e nxjerrim në paraprodhim, e testojmë, e nxjerrim për prodhim.

04:00. Gjithçka po funksionon
Të gjitha testet kaluan, asnjë problem kritik nuk është i dukshëm. Herë pas here, diçka në ekip nuk funksionon për dikë, ne reagojmë menjëherë. Më shpesh, alarmi është i rremë. Por ndonjëherë diçka nuk arrin, ose një faqe e veçantë nuk funksionon. Ne ulemi, rregullojmë, rregullojmë, rregullojmë. Një ekip i veçantë po lëshon funksionin e fundit të madh - faturimin.

04:30. Pika pa kthim
Po afrohet pika e pakthimit, pra koha kur, nëse fillojmë të rikthehemi, nuk do të përballojmë kohën e pushimit që na është dhënë. Ka probleme me faturimin, i cili di dhe regjistron gjithçka, por refuzon me kokëfortësi të fshijë paratë nga klientët. Ka disa gabime në faqet, veprimet dhe statuset individuale. Funksionaliteti kryesor funksionon, të gjitha testet kalojnë me sukses. Ne vendosim që shpërndarja ka ndodhur, ne nuk do të kthehemi prapa.

06:00. Hapur për të gjithë në ndërfaqen e përdoruesit
Bugs rregulluar. Disa që nuk tërheqin përdoruesit lihen për më vonë. Ne e hapim ndërfaqen për të gjithë. Ne vazhdojmë të punojmë për faturimin, duke pritur për komentet e përdoruesve dhe rezultatet e monitorimit.

07:00. Probleme me ngarkesën API
Bëhet e qartë se ne kemi planifikuar pak gabim ngarkesën në API-në tonë dhe kemi testuar këtë ngarkesë, e cila nuk mund ta identifikonte problemin. Si rezultat, ≈5% e kërkesave dështojnë. Le të mobilizohemi dhe të kërkojmë arsyen.

Faturimi është kokëfortë dhe as nuk dëshiron të punojë. Ne vendosim ta shtyjmë për më vonë për të kryer ndryshimet në mënyrë të qetë. Kjo do të thotë, të gjitha burimet janë grumbulluar në të, por fshirjet nga klientët nuk kalojnë. Sigurisht, ky është një problem, por në krahasim me paraqitjen e përgjithshme duket i parëndësishëm.

08:00. Rregulloni API-në
Ne hapëm një rregullim për ngarkesën, dështimet u larguan. Ne fillojmë të shkojmë në shtëpi.

ora 10:00. Të gjitha
Gjithçka është rregulluar. Është e qetë në monitorim dhe në vendin e klientëve, ekipi gradualisht shkon në gjumë. Faturimi mbetet, do ta rikthejmë nesër.

Më pas, gjatë ditës pati prezantime që rregullonin regjistrat, njoftimet, kodet e kthimit dhe personalizimet për disa nga klientët tanë.

Pra, prezantimi ishte i suksesshëm! Sigurisht, mund të ishte më mirë, por ne nxorëm përfundime se çfarë nuk mjaftonte për të arritur përsosmërinë.

Në total

Gjatë 2 muajve të përgatitjes aktive për paraqitjen, u kryen 43 detyra, që zgjasin nga disa orë në disa ditë.

Gjatë prezantimit:

• demonët e rinj dhe të ndryshuar - 5 copë, duke zëvendësuar 2 monolite;
• ndryshimet brenda bazave të të dhënave - të 6 bazat tona të të dhënave me të dhënat e përdoruesve janë prekur, janë bërë shkarkime nga tre baza të dhënash të vjetra në një të re;
• frontend i ridizajnuar plotësisht;
• sasia e kodit të shkarkuar - 33 mijë rreshta kodi të ri, ≈ 3 mijë rreshta kodi në teste, ≈ 5 mijë rreshta kodi i migracionit;
• të gjitha të dhënat janë të paprekura, asnjë makinë virtuale e një klienti nuk është dëmtuar. 🙂

Praktikat e mira për paraqitje të mirë

Ata na orientuan në këtë situatë të vështirë. Por, në përgjithësi, është e dobishme t'i ndiqni ato gjatë çdo prezantimi. Por sa më komplekse të jetë prezantimi, aq më i madh është roli që ata luajnë.

1. Gjëja e parë që duhet të bëni është të kuptoni se si mund të ndikojë ose do të ndikojë përdorimi tek përdoruesit. A do të ketë kohë joproduktive? Nëse po, çfarë është koha joproduktive? Si do të ndikojë kjo tek përdoruesit? Cilat janë skenarët e mundshëm më të mirë dhe më të keq? Dhe mbuloni rreziqet.
2. Planifikoni gjithçka. Në çdo fazë, ju duhet të kuptoni të gjitha aspektet e paraqitjes:
   • dërgimi i kodit;
   • rikthimi i kodit;
   • koha e çdo operacioni;
   • funksionaliteti i prekur.
3. Luaj nëpër skenarë derisa të gjitha fazat e prezantimit, si dhe rreziqet në secilën prej tyre, të bëhen të dukshme. Nëse keni ndonjë dyshim, mund të bëni një pushim dhe të shqyrtoni veçmas fazën e diskutueshme.
4. Çdo fazë mund dhe duhet të përmirësohet nëse ndihmon përdoruesit tanë. Për shembull, do të reduktojë kohën e ndërprerjes ose do të heqë disa rreziqe.
5. Testimi i rikthimit është shumë më i rëndësishëm sesa testimi i dërgimit të kodit. Është e nevojshme të kontrollohet se si rezultat i rikthimit sistemi do të kthehet në gjendjen e tij origjinale dhe konfirmoni këtë me teste.
6. Çdo gjë që mund të automatizohet duhet të jetë e automatizuar. Çdo gjë që nuk mund të automatizohet duhet të shkruhet paraprakisht në një fletë mashtrimi.
7. Regjistroni kriterin e suksesit. Çfarë funksionaliteti duhet të jetë i disponueshëm dhe në çfarë ore? Nëse kjo nuk ndodh, zbatoni një plan rikthimi.
8. Dhe më e rëndësishmja - njerëzit. Të gjithë duhet të jenë të vetëdijshëm për atë që po bëjnë, pse dhe çfarë varet nga veprimet e tyre në procesin e prezantimit.

Dhe me një fjali, me një planifikim dhe përpunim të mirë mund të lëshoni gjithçka që dëshironi pa pasoja për shitjet. Edhe diçka që do të ndikojë në të gjitha shërbimet tuaja në prodhim.

Burimi: www.habr.com