z 12f-2
Konec aprila, ko so Beli sprehajalci oblegali Winterfell, se nam je zgodilo nekaj bolj zanimivega; naredili smo nenavaden rollout. Načeloma nenehno uvajamo nove funkcije v proizvodnjo (kot vsi ostali). Toda ta je bil drugačen. Obseg je bil tolikšen, da bi morebitne napake, ki bi jih lahko naredili, vplivale na vse naše storitve in uporabnike. Posledično smo izpeljali vse po načrtih, v načrtovanih in napovedanih zastojih, brez posledic za prodajo. Članek govori o tem, kako smo to dosegli in kako lahko vsakdo to ponovi doma.
Ne bom zdaj opisoval arhitekturnih in tehničnih odločitev, ki smo jih sprejeli, ali kako vse skupaj deluje. To so bolj opombe ob robu o tem, kako je potekala ena najtežjih uvedb, ki sem jih opazoval in pri katerih sem neposredno sodeloval. Ne zahtevam popolnosti ali tehničnih podrobnosti; morda se bodo pojavile v drugem članku.
Ozadje + kakšna funkcionalnost je to?
Gradimo platformo v oblaku (MCS), kjer delam kot tehnični direktor. In zdaj je čas, da naši platformi dodamo IAM (Upravljanje identitete in dostopa), ki zagotavlja poenoteno upravljanje vseh uporabniških računov, uporabnikov, gesel, vlog, storitev in več. Zakaj je to potrebno v oblaku, je očitno vprašanje: vse uporabniške informacije so shranjene v njem.
Običajno se takšne stvari začnejo graditi na samem začetku katerega koli projekta. Toda zgodovinsko so bile stvari v MCS nekoliko drugačne. MCS je bil zgrajen v dveh delih:
- Openstack z lastnim avtorizacijskim modulom Keystone,
- Hotbox (shramba S3), ki temelji na projektu Mail.ru Cloud,
okoli katerega so se nato pojavile nove storitve.
V bistvu je šlo za dve različni vrsti pooblastil. Poleg tega smo uporabili nekaj ločenih razvojev Mail.ru, na primer splošno shranjevanje gesel Mail.ru, kot tudi samonapisani konektor openid, zahvaljujoč kateremu je bila na plošči Horizon zagotovljena SSO (od konca do konca). virtualnih strojev (izvorni uporabniški vmesnik OpenStack).
Izdelava IAM-a je za nas pomenila povezavo vsega v en sam sistem, popolnoma naš. Obenem na tej poti ne bomo izgubili nobene funkcionalnosti, ampak bomo ustvarili osnovo za prihodnost, ki nam bo omogočila pregledno izpopolnjevanje brez refaktoriranja in skaliranje v smislu funkcionalnosti. Tudi uporabniki so imeli na začetku vzor pri dostopu do storitev (centralni RBAC, vlog-based access control) in še nekatere malenkosti.
Naloga se je izkazala za netrivialno: python in perl, več ozadij, neodvisno napisane storitve, več razvojnih skupin in skrbnikov. In kar je najpomembnejše, na sistemu bojne proizvodnje je na tisoče uporabnikov v živo. Vse to je bilo treba napisati in, kar je najpomembneje, izpeljati brez žrtev.
Kaj bomo izpeljali?
Zelo grobo povedano smo v približno 4 mesecih pripravili:
- Ustvarili smo več novih demonov, ki so združevali funkcije, ki so prej delovale v različnih delih infrastrukture. Ostalim storitvam je bilo predpisano novo zaledje v obliki teh demonov.
- Napisali smo lastno centralno shrambo gesel in ključev, ki so na voljo za vse naše storitve in jih lahko poljubno spreminjamo.
- Za Keystone smo iz nič napisali 4 nova ozadja (uporabniki, projekti, vloge, dodelitve vlog), ki so pravzaprav nadomestila njegovo bazo podatkov in zdaj deluje kot enotno skladišče za naša uporabniška gesla.
- Vse naše storitve Openstack smo naučili, da se za svoje pravilnike obrnejo na storitev pravilnikov tretjih oseb, namesto da te pravilnike berejo lokalno iz vsakega strežnika (da, tako Openstack deluje privzeto!)
Tako velika predelava zahteva velike, kompleksne in, kar je najpomembneje, sinhrone spremembe v več sistemih, ki so jih napisale različne razvojne ekipe. Ko je sestavljen, mora celoten sistem delovati.
Kako uvesti takšne spremembe in ne zajebati? Najprej smo se odločili pogledati malo v prihodnost.
Strategija uvajanja
- Izdelek bi sicer lahko uvedli v več fazah, vendar bi s tem razvojni čas podaljšali za trikrat. Poleg tega bi nekaj časa imeli popolno desinhronizacijo podatkov v bazah. Morali bi napisati lastna orodja za sinhronizacijo in dolgo živeti z več shrambami podatkov. In to ustvarja veliko različnih tveganj.
- Vse, kar je bilo mogoče transparentno pripraviti za uporabnika, je bilo narejeno vnaprej. Trajalo je 2 meseca.
- Dovolili smo si večurne izpade – samo za uporabniške operacije ustvarjanja in spreminjanja virov.
- Za delovanje vseh že ustvarjenih virov so bili izpadi nesprejemljivi. Načrtovali smo, da bodo med uvedbo viri delovali brez izpadov in vplivali na stranke.
- Da bi zmanjšali vpliv na naše stranke, če gre kaj narobe, smo se odločili, da uvedemo v nedeljo zvečer. Manj strank upravlja virtualne stroje ponoči.
- Vse naše stranke smo opozorili, da v obdobju, izbranem za uvedbo, upravljanje storitve ne bo na voljo.
Digresija: kaj je uvajanje?
<previdnost, filozofija>
Vsak informatik lahko zlahka odgovori, kaj je rollout. Namestite CI/CD in vse se samodejno dostavi v trgovino. 🙂
Seveda je to res. Toda težava je v tem, da se s sodobnimi orodji za avtomatizacijo dostave kode izgubi razumevanje same uvedbe. Kako ob pogledu na sodoben transport pozabiš na epskost izuma kolesa. Vse je tako avtomatizirano, da se uvajanje pogosto izvaja brez razumevanja celotne slike.
In celotna slika je taka. Uvedba je sestavljena iz štirih glavnih vidikov:
- Dostava kode, vključno s spremembo podatkov. Na primer njihove selitve.
- Vrnitev kode nazaj je zmožnost vrnitve nazaj, če gre kaj narobe. Na primer z ustvarjanjem varnostnih kopij.
- Čas vsake operacije uvajanja/povrnitve. Razumeti morate časovni okvir katere koli operacije prvih dveh točk.
- Prizadeta funkcionalnost. Vrednotiti je treba tako pričakovane pozitivne kot morebitne negativne učinke.
Vse te vidike je treba upoštevati za uspešno uvedbo. Običajno se oceni samo prva ali v najboljšem primeru druga točka, nato pa se uvedba šteje za uspešno. Toda tretji in četrti sta še kako pomembni. Kateremu uporabniku bi bilo všeč, če bi uvedba trajala 3 ure namesto minute? Ali če je med uvajanjem prizadeto kaj nepotrebnega? Ali pa bo izpad ene storitve povzročil nepredvidljive posledice?
Akt 1..n, priprava na izpust
Najprej sem pomislil, da bi na kratko opisal najine sestanke: celotno ekipo, njene dele, kup razprav ob kavi, prepirov, testov, možganskih neviht. Potem sem mislil, da bi bilo nepotrebno. Štirje meseci razvoja so vedno sestavljeni iz tega, še posebej, če ne pišete nečesa, kar je mogoče nenehno dostavljati, ampak eno veliko funkcijo za sistem v živo. Kar vpliva na vse storitve, vendar se za uporabnike ne sme spremeniti nič razen »enega gumba v spletnem vmesniku«.
Naše razumevanje tega, kako uvesti, se je z vsakim novim sestankom spremenilo in precej pomembno. Na primer, nameravali smo posodobiti našo celotno zbirko podatkov o obračunavanju. Vendar smo izračunali čas in ugotovili, da je to nemogoče narediti v razumnem času uvedbe. Potrebovali smo skoraj dodaten teden, da smo razdelili in arhivirali bazo podatkov za obračunavanje. In ko pričakovana hitrost uvajanja še vedno ni bila zadovoljiva, smo naročili dodatno, zmogljivejšo strojno opremo, kjer se je povlekla celotna baza. Ne gre za to, da tega ne bi želeli storiti prej, a trenutna potreba po uvedbi nam ni pustila nobenih možnosti.
Ko je eden od nas dvomil, da bi uvedba lahko vplivala na razpoložljivost naših virtualnih strojev, smo en teden izvajali teste, poskuse, analizo kode in prejeli jasno razumevanje, da se to v naši proizvodnji ne bo zgodilo, in celo najbolj dvomljivi ljudje so se strinjali s tem.
V vmesnem času so fantje iz tehnične podpore izvajali lastne neodvisne poskuse, da bi napisali navodila za stranke o načinih povezave, ki naj bi se po uvedbi spremenili. Delali so na uporabniški UX, pripravljali navodila in osebno svetovali.
Avtomatizirali smo vse operacije uvajanja, ki so bile možne. Vsaka operacija je bila skriptirana, tudi najpreprostejša, in nenehno so se izvajali testi. Prepirali so se o najboljšem načinu za izklop storitve - izpustitev demona ali blokiranje dostopa do storitve s požarnim zidom. Ustvarili smo kontrolni seznam ekip za vsako stopnjo uvajanja in ga nenehno posodabljali. Narisali in nenehno posodabljali smo gantogram za vse uvedbe s časovnimi razporedi.
In tako…
Zadnje dejanje, pred začetkom
... čas je za začetek.
Kot pravijo, umetniškega dela ni mogoče dokončati, le dokončati delo na njem. Morate se potruditi z voljo, razumeti, da ne boste našli vsega, vendar verjeti, da ste naredili vse razumne predpostavke, poskrbeli za vse možne primere, zaprli vse kritične napake in vsi udeleženci naredili vse, kar so lahko. Več kode kot uvedete, težje se je o tem prepričati (poleg tega vsi razumejo, da je nemogoče vsega predvideti).
Odločili smo se, da smo pripravljeni na uvedbo, ko smo bili prepričani, da smo storili vse, kar je bilo v naši moči, da pokrijemo vsa tveganja za naše uporabnike, povezana z nepričakovanimi učinki in izpadi. To pomeni, da gre lahko karkoli narobe, razen:
- Vplivajo na (za nas sveto, najbolj dragoceno) uporabniško infrastrukturo,
- Funkcionalnost: uporaba naše storitve po uvedbi mora biti enaka kot pred njo.
Uvajajo
Dva zvitka, 8 ne moti
Za vse zahteve uporabnikov vzamemo izpade za 7 ur. Trenutno imamo načrt za uvedbo in načrt za povrnitev.
- Sama uvedba traja približno 3 ure.
- 2 uri za testiranje.
- 2 uri - rezerva za morebitno povrnitev sprememb.
Za vsako dejanje je bil sestavljen gantogram, koliko časa traja, kaj se dogaja zaporedno, kaj se izvaja vzporedno.
Del gantograma za uvajanje, ena od zgodnjih različic (brez vzporedne izvedbe). Najbolj dragoceno orodje za sinhronizacijo
Vsi udeleženci imajo določeno svojo vlogo pri uvajanju, katere naloge opravljajo in za kaj so odgovorni. Vsako stopnjo skušamo pripeljati do avtomatizacije, jo uvesti, vrniti nazaj, zbrati povratne informacije in jo znova uvesti.
Kronika dogajanja
Tako je v nedeljo, 15. aprila, ob 29. uri na delo prišlo 10 ljudi. Poleg ključnih udeležencev so nekateri prišli zgolj podpreti ekipo, za kar jim gre posebna zahvala.
Omeniti velja tudi, da je naš tester ključev na dopustu. Nemogoče je uvesti brez testiranja, raziskujemo možnosti. Kolegica se strinja, da nas preizkusi z dopusta, za kar prejme neizmerno hvaležnost celotne ekipe.
00:00. Stop
Ustavimo zahteve uporabnikov, izobesimo napis tehnično delo. Monitor kriči, vendar je vse normalno. Preverimo, da ni padlo nič drugega kot tisto, kar bi moralo pasti. In začnemo delati na migraciji.
Vsak ima natisnjen načrt uvajanja po točkah, vsak ve, kdo kaj dela in v katerem trenutku. Po vsaki akciji preverimo čase, da jih ne presežemo, in vse poteka po načrtih. Tisti, ki trenutno ne sodelujejo pri uvedbi neposredno, se pripravljajo na lansiranje spletne igrače (Xonotic, tip 3 quacks), da ne bi motili svojih kolegov. 🙂
02:00. Razvalja
Prijetno presenečenje - uvedbo zaključimo uro prej, zaradi optimizacije naših baz podatkov in migracijskih skriptov. Splošni krik, "razvaljano!" Vse nove funkcije so v izdelavi, vendar jih zaenkrat vidimo samo v vmesniku. Vsi gredo v način testiranja, jih razvrstijo v skupine in začnejo opazovati, kaj se je na koncu zgodilo.
Ni se izkazalo najbolje, to ugotovimo po 10 minutah, ko v projektih članov ekipe ni nič povezano ali deluje. Hitra sinhronizacija, izrazimo svoje težave, postavimo prioritete, se razdelimo v ekipe in gremo v odpravljanje napak.
02:30. Dva velika problema proti štirim očesom
Najdemo dve veliki težavi. Ugotovili smo, da stranke ne bodo videle nekaterih povezanih storitev, težave pa bodo nastale s partnerskimi računi. Oboje je posledica nepopolnih migracijskih skriptov za nekatere robne primere. Moramo popraviti zdaj.
Pišemo zahteve, ki to popravijo, z vsaj 4 očmi. Preizkušamo jih med predprodukcijo, da se prepričamo, da delujejo in da se ničesar ne pokvarijo. Lahko se kotališ naprej. Hkrati izvajamo naše redno testiranje integracije, ki razkrije še nekaj težav. Vsi so majhni, vendar jih je treba tudi popraviti.
03:00. -2 težavi +2 težavi
Prejšnji dve veliki težavi sta odpravljeni in skoraj vse manjše. Vsi tisti, ki niso zasedeni s popravki, aktivno delajo v svojih računih in poročajo, kaj najdejo. Določimo prioritete, razdelimo med ekipe in pustimo nekritične predmete za zjutraj.
Ponovno izvedemo teste, odkrijejo dve novi veliki težavi. Vsi pravilniki storitev niso prispeli pravilno, zato nekatere uporabniške zahteve ne prestanejo avtorizacije. Plus nova težava s partnerskimi računi. Pohitimo pogledat.
03:20. Sinhronizacija v sili
Ena nova težava je odpravljena. Za drugo organiziramo nujno sinhronizacijo. Razumemo, kaj se dogaja: prejšnji popravek je odpravil eno težavo, a ustvaril drugo. Vzamemo odmor, da ugotovimo, kako to narediti pravilno in brez posledic.
03:30. Šest oči
Zavedamo se, kakšno mora biti končno stanje baze, da bo vsem partnerjem šlo dobro. Napišemo zahtevo s 6 očmi, jo razvaljamo v predprodukciji, testiramo, razvaljamo za proizvodnjo.
04:00. Vse dela
Vsi testi opravljeni, kritičnih težav ni. Od časa do časa komu kaj v ekipi ne uspe, reagiramo sproti. Najpogosteje je alarm lažen. Toda včasih kaj ne pride ali pa ločena stran ne deluje. Sedimo, popravljamo, popravljamo, popravljamo. Ločena ekipa uvaja zadnjo veliko funkcijo – obračunavanje.
04:30. Točka brez povratka
Bliža se točka brez vrnitve, to je čas, ko, če se začnemo vračati nazaj, ne bomo dočakali časa, ki nam je dano. Težave so z obračunom, ki vse ve in beleži, vendar trmasto noče odpisati denarja strankam. Na posameznih straneh, dejanjih in statusih je več napak. Glavna funkcionalnost deluje, vsi testi uspešno prestali. Odločimo se, da je uvedba izvedena, ne bomo se vrnili nazaj.
06:00. Odprto za vse v uporabniškem vmesniku
Napake odpravljene. Nekatere, ki uporabnikom niso všeč, pustimo za pozneje. Vmesnik odpremo vsem. Nadaljujemo z obračunavanjem, čakamo na povratne informacije uporabnikov in spremljamo rezultate.
07:00. Težave z nalaganjem API-ja
Postane jasno, da smo nekoliko napačno načrtovali obremenitev našega API-ja in preizkusili to obremenitev, ki ni mogla prepoznati težave. Posledično ≈5 % zahtev ne uspe. Mobilizirajmo se in poiščimo razlog.
Billing je trmast in tudi noče delati. Odločimo se, da ga prestavimo na pozneje, da bi spremembe izpeljali na miren način. To pomeni, da so vsi viri zbrani v njem, vendar odpisi od strank ne gredo skozi. Seveda je to težava, a v primerjavi s splošno uvedbo se zdi nepomembna.
08:00. Popravi API
Izvedli smo popravek za obremenitev, napake so izginile. Začnemo iti domov.
10:00. Vse
Vse je popravljeno. Pri spremljanju je tiho in pri strankah ekipa postopoma zaspi. Obračun ostaja, obnovili ga bomo jutri.
Nato so čez dan potekale uvedbe, ki so popravljale dnevnike, obvestila, povratne kode in prilagoditve za nekatere naše stranke.
Torej, uvedba je bila uspešna! Seveda bi lahko bilo bolje, vendar smo sklepali, kaj nam je premalo za dosego popolnosti.
Skupno
V dveh mesecih aktivne priprave na uvedbo je bilo opravljenih 2 nalog, ki so trajale od nekaj ur do nekaj dni.
Med uvajanjem:
- novi in spremenjeni demoni - 5 kosov, ki nadomeščajo 2 monolita;
- spremembe znotraj baz - prizadetih je vseh 6 naših baz z uporabniškimi podatki, izvedeni so bili prenosi iz treh starih baz v eno novo;
- popolnoma preoblikovan frontend;
- količina prenesene kode - 33 tisoč vrstic nove kode, ≈ 3 tisoč vrstic kode v testih, ≈ 5 tisoč vrstic migracijske kode;
- vsi podatki so nedotaknjeni, noben virtualni stroj stranke ni bil poškodovan. 🙂
Dobre prakse za dobro uvajanje
Vodili so nas v tej težki situaciji. Toda na splošno jih je koristno spremljati med vsakim uvajanjem. Toda bolj ko je uvedba zapletena, večjo vlogo imajo.
- Prva stvar, ki jo morate storiti, je razumeti, kako lahko ali bo uvedba vplivala na uporabnike. Bo prišlo do izpadov? Če je tako, kolikšen je čas nedelovanja? Kako bo to vplivalo na uporabnike? Kateri so možni najboljši in najslabši možni scenariji? In pokriti tveganja.
- Načrtujte vse. Na vsaki stopnji morate razumeti vse vidike uvajanja:
- dostava kode;
- vrnitev kode;
- čas vsake operacije;
- prizadeta funkcionalnost.
- Igrajte skozi scenarije, dokler ne postanejo očitne vse stopnje uvajanja in tveganja pri vsaki od njih. Če imate kakršne koli dvome, si lahko oddahnete in ločeno preučite vprašljivo stopnjo.
- Vsako stopnjo je mogoče in treba izboljšati, če pomaga našim uporabnikom. Na primer, zmanjšal bo čas izpadov ali odstranil nekatera tveganja.
- Testiranje povrnitve je veliko pomembnejše od testiranja dostave kode. Preveriti je treba, ali se bo sistem zaradi povrnitve vrnil v prvotno stanje, in to potrditi s testi.
- Vse, kar je mogoče avtomatizirati, bi moralo biti avtomatizirano. Vse, česar ni mogoče avtomatizirati, je treba vnaprej napisati na goljufijo.
- Zapišite merilo uspeha. Katere funkcije naj bodo na voljo in ob katerem času? Če se to ne zgodi, zaženite načrt za povrnitev.
- In kar je najpomembnejše – ljudi. Vsak se mora zavedati, kaj počne, zakaj in kaj je odvisno od njegovih dejanj v procesu uvajanja.
In z enim stavkom, z dobrim načrtovanjem in elaboracijo lahko brez posledic za prodajo izpelješ kar hočeš. Tudi nekaj, kar bo vplivalo na vse vaše storitve v proizvodnji.
Vir: www.habr.com