Priča o uvođenju koja je utjecala na sve

Neprijatelji stvarnosti prema 12f-2

Krajem travnja, dok su White Walkers opsjedali Winterfell, dogodilo nam se još nešto zanimljivo; napravili smo neobičan rollout. U principu, stalno uvodimo nove značajke u proizvodnju (kao i svi ostali). Ali ovaj je bio drugačiji. Razmjer je bio takav da bi sve potencijalne pogreške koje bismo mogli napraviti utjecale na sve naše usluge i korisnike. Kao rezultat toga, izveli smo sve prema planu, unutar planiranog i najavljenog zastoja, bez posljedica za prodaju. Članak govori o tome kako smo to postigli i kako to svatko može ponoviti kod kuće.

Neću sada opisivati ​​arhitektonske i tehničke odluke koje smo donijeli niti pričati kako to sve funkcionira. Ovo su više bilješke na marginama o tome kako se odvijao jedan od najtežih rollouta koji sam promatrao iu kojem sam izravno sudjelovao. Ne zahtijevam potpunost ili tehničke detalje; možda će se pojaviti u nekom drugom članku.

Pozadina + kakva je ovo funkcija?

Gradimo platformu u oblaku Mail.ru Cloud rješenja (MCS), gdje radim kao tehnički direktor. A sada je vrijeme da našoj platformi dodamo IAM (Upravljanje identitetom i pristupom) koji pruža objedinjeno upravljanje svim korisničkim računima, korisnicima, lozinkama, ulogama, uslugama i više. Zašto je to potrebno u oblaku očito je pitanje: sve korisničke informacije pohranjuju se u njemu.

Obično se takve stvari počinju graditi na samom početku bilo kojeg projekta. Ali povijesno gledano stvari su bile malo drugačije u MCS-u. MCS je izgrađen u dva dijela:

• Openstack s vlastitim modulom za autorizaciju Keystone,
• Hotbox (S3 pohrana) temeljen na projektu Mail.ru Cloud,

oko kojih su se potom pojavile nove usluge.

U biti, radilo se o dvije različite vrste ovlaštenja. Osim toga, koristili smo neke zasebne razvoje Mail.ru, na primjer, opću pohranu lozinki za Mail.ru, kao i openid konektor koji smo napisali sami, zahvaljujući kojemu je omogućen SSO (end-to-end autorizacija) na ploči Horizon virtualnih strojeva (izvorni OpenStack UI).

Napraviti IAM za nas je značilo sve to povezati u jedinstven sustav, potpuno naš. Istodobno, usput nećemo izgubiti nikakvu funkcionalnost, već ćemo stvoriti temelj za budućnost koji će nam omogućiti da ga transparentno doradimo bez refaktoriranja i skaliramo u smislu funkcionalnosti. Također u startu su korisnici imali uzor za pristup uslugama (centralni RBAC, role-based access control) i još neke sitnice.

Zadatak se pokazao netrivijalnim: python i perl, nekoliko pozadina, neovisno napisane usluge, nekoliko razvojnih timova i administratora. I što je najvažnije, na sustavu borbene proizvodnje postoje tisuće živih korisnika. Sve je to trebalo napisati i, što je najvažnije, izvesti bez žrtava.

Što ćemo izbaciti?

Ugrubo rečeno, u otprilike 4 mjeseca pripremili smo sljedeće:

• Stvorili smo nekoliko novih demona koji su agregirali funkcije koje su prije radile u različitim dijelovima infrastrukture. Ostatak usluga je dobio novi backend u obliku ovih demona.
• Napisali smo vlastitu središnju pohranu lozinki i ključeva, dostupnu za sve naše usluge, koju možemo slobodno mijenjati po potrebi.
• Napisali smo 4 nova pozadina za Keystone od nule (korisnici, projekti, uloge, dodjele uloga), koja je zapravo zamijenila njegovu bazu podataka i sada djeluje kao jedno spremište za naše korisničke lozinke.
• Naučili smo sve naše Openstack servise da svoja pravila obrate servisu za pravila treće strane umjesto da čitaju ta pravila lokalno sa svakog poslužitelja (da, tako Openstack funkcionira prema zadanim postavkama!)

Takva velika prerada zahtijeva velike, složene i, što je najvažnije, sinkrone promjene u nekoliko sustava koje su napisali različiti razvojni timovi. Nakon sastavljanja, cijeli bi sustav trebao raditi.

Kako uvesti takve promjene i ne zeznuti stvar? Prvo smo odlučili pogledati malo u budućnost.

Strategija uvođenja

• Proizvod bi bilo moguće izbaciti u nekoliko faza, ali bi se time vrijeme razvoja povećalo tri puta. Osim toga, neko vrijeme bismo imali potpunu desinkronizaciju podataka u bazama. Morali biste napisati vlastite alate za sinkronizaciju i dugo živjeti s više pohrana podataka. A to stvara širok raspon rizika.
• Sve što se moglo transparentno pripremiti za korisnika napravljeno je unaprijed. Trajalo je 2 mjeseca.
• Dopustili smo si prekid rada od nekoliko sati - samo za korisničke operacije za stvaranje i promjenu resursa.
• Za rad svih već stvorenih resursa zastoji su bili nedopustivi. Planirali smo da tijekom uvođenja resursi trebaju raditi bez zastoja i utjecati na klijente.
• Kako bismo smanjili utjecaj na naše klijente ako nešto pođe po zlu, odlučili smo pokrenuti u nedjelju navečer. Manje korisnika upravlja virtualnim strojevima noću.
• Upozorili smo sve naše klijente da tijekom razdoblja odabranog za uvođenje upravljanje uslugom neće biti dostupno.

Digresija: što je rollout?

<oprez, filozofija>

Svaki IT stručnjak može lako odgovoriti što je rollout. Instalirate CI/CD i sve se automatski isporučuje u trgovinu. 🙂

Naravno da je to istina. Ali poteškoća je u tome što se s modernim alatima za automatizaciju isporuke koda gubi razumijevanje samog uvođenja. Kako zaboraviti na epskost izuma kotača kada pogledate moderni transport. Sve je toliko automatizirano da se uvođenje često provodi bez razumijevanja cijele slike.

A cijela slika je ovakva. Uvođenje se sastoji od četiri glavna aspekta:

1. Isporuka koda, uključujući modifikaciju podataka. Na primjer, njihove migracije.
2. Vraćanje koda je mogućnost vraćanja ako nešto pođe po zlu. Na primjer, stvaranjem sigurnosnih kopija.
3. Vrijeme svake operacije rollout/rollback. Morate razumjeti vrijeme svake operacije prve dvije točke.
4. Pogođena funkcionalnost. Potrebno je procijeniti kako očekivane pozitivne tako i moguće negativne učinke.

Svi ti aspekti moraju se uzeti u obzir za uspješno uvođenje. Obično se procjenjuje samo prva, ili u najboljem slučaju druga točka, a zatim se uvođenje smatra uspješnim. Ali treći i četvrti su još važniji. Koji bi korisnik volio da uvođenje traje 3 sata umjesto minute? Ili ako nešto nepotrebno bude pogođeno tijekom uvođenja? Ili će zastoj jedne usluge dovesti do nepredvidivih posljedica?

Čin 1..n, priprema za puštanje

Prvo sam mislio ukratko opisati naše sastanke: cijeli tim, njegovi dijelovi, hrpe rasprava na kavama, svađe, testovi, brainstorming. Tada sam mislio da bi to bilo nepotrebno. Četiri mjeseca razvoja uvijek se sastoji od ovoga, pogotovo kada ne pišete nešto što se može stalno isporučivati, već jednu veliku značajku za živi sustav. Što utječe na sve usluge, ali ništa se ne bi trebalo promijeniti za korisnike osim "jednog gumba u web sučelju."

Naše razumijevanje načina izvođenja mijenjalo se sa svakim novim sastankom, i to prilično značajno. Na primjer, namjeravali smo ažurirati cijelu našu bazu podataka o naplati. Ali izračunali smo vrijeme i shvatili da je to nemoguće učiniti u razumnom roku uvođenja. Trebalo nam je gotovo dodatnih tjedan dana da razbijemo i arhiviramo bazu podataka o naplati. I kada očekivana brzina uvođenja još uvijek nije bila zadovoljavajuća, naručili smo dodatni, snažniji hardver, gdje je cijela baza bila dovučena. Nije da to nismo htjeli učiniti ranije, ali trenutna potreba za uvođenjem nije nam ostavila mogućnosti.

Kad je netko od nas sumnjao da bi uvođenje moglo utjecati na dostupnost naših virtualnih strojeva, proveli smo tjedan dana provodeći testove, eksperimente, analizu koda i dobili jasno razumijevanje da se to neće dogoditi u našoj proizvodnji, a čak su se i najsumnjičaviji ljudi složili s ovim.

U međuvremenu su dečki iz tehničke podrške proveli vlastite neovisne eksperimente kako bi napisali upute za klijente o načinima povezivanja, koji su se trebali promijeniti nakon rollouta. Radili su na korisničkom UX-u, pripremali upute i pružali osobne konzultacije.

Automatizirali smo sve moguće operacije uvođenja. Svaka je operacija bila skriptirana, čak i one najjednostavnije, a testovi su se neprestano izvodili. Svađali su se oko najboljeg načina za isključivanje usluge - izostavljanje demona ili blokiranje pristupa usluzi vatrozidom. Napravili smo kontrolni popis timova za svaku fazu uvođenja i stalno ga ažurirali. Nacrtali smo i stalno ažurirali gantogram za sve radove uvođenja, s vremenskim rasporedima.

I tako…

Posljednji čin, prije izlaska

...vrijeme je za izlazak.

Kako kažu, umjetničko djelo se ne može dovršiti, već samo završiti rad na njemu. Morate uložiti napor volje, shvaćajući da nećete pronaći sve, ali vjerujući da ste napravili sve razumne pretpostavke, predvidjeli sve moguće slučajeve, zatvorili sve kritične bugove i da su svi sudionici učinili sve što su mogli. Što više koda izbacite, to je teže uvjeriti se u to (osim toga, svi razumiju da je nemoguće sve predvidjeti).

Odlučili smo da smo spremni za uvođenje kada smo bili uvjereni da smo učinili sve što smo mogli da pokrijemo sve rizike za naše korisnike povezane s neočekivanim utjecajima i zastojima. Odnosno, sve može poći po zlu osim:

1. Utječu na (nama svetu, najdragocjeniju) korisničku infrastrukturu,
2. Funkcionalnost: korištenje naše usluge nakon uvođenja trebalo bi biti isto kao i prije.

Razvaljavanje

Dva bacanja, 8 ne smetaju

Za sve zahtjeve korisnika uzimamo prekid rada 7 sati. U ovom trenutku imamo i plan uvođenja i plan vraćanja.

• Samo uvođenje traje otprilike 3 sata.
• 2 sata za testiranje.
• 2 sata - rezerva za moguće vraćanje promjena.

Gantogram je napravljen za svaku radnju, koliko traje, što se događa uzastopno, što se radi paralelno.

Dio rollout gantograma, jedna od ranih verzija (bez paralelnog izvođenja). Najvrjedniji alat za sinkronizaciju

Svi sudionici imaju određenu ulogu u uvođenju, koje zadatke obavljaju i za što su odgovorni. Svaki stupanj pokušavamo dovesti do automatizma, uvoditi ga, vraćati, prikupljati povratne informacije i ponovno ga uvoditi.

Kronika događaja

Dakle, u nedjelju, 15. travnja, u 29 sata na posao je došlo 10 ljudi. Osim ključnih sudionika, neki su došli jednostavno podržati ekipu, na čemu im posebno zahvaljujemo.

Također je vrijedno spomenuti da je naš tester ključeva na odmoru. Nemoguće je pokrenuti bez testiranja, istražujemo mogućnosti. Kolegica nas pristaje testirati s godišnjeg odmora, za što dobiva ogromnu zahvalnost cijelog tima.

00:00. Stop
Zaustavljamo zahtjeve korisnika, vješamo natpis tehnički rad. Monitor vrišti, ali sve je normalno. Provjeravamo da nije palo ništa osim onoga što je trebalo pasti. I počinjemo raditi na migraciji.

Svatko ima isprintan plan uvođenja točku po točku, svatko zna tko što radi i u kojem trenutku. Nakon svake akcije provjeravamo vremena kako bismo bili sigurni da ih ne prekoračimo i sve ide po planu. Oni koji u trenutnoj fazi ne sudjeluju izravno u uvođenju, pripremaju se pokretanjem online igračke (Xonotic, tip 3 quacks) kako ne bi ometali svoje kolege. 🙂

02:00. Odvaljano
Ugodno iznenađenje - završavamo uvođenje sat vremena ranije, zbog optimizacije naših baza podataka i migracijskih skripti. Opći povik, "otkotrljao se!" Sve nove funkcije su u produkciji, ali zasad ih samo mi možemo vidjeti u sučelju. Svi idu u modus testiranja, razvrstavaju se u grupe i počinju vidjeti što se na kraju dogodilo.

Nije ispalo baš najbolje, to shvatimo nakon 10 minuta, kada ništa nije povezano niti radi u projektima članova tima. Brza sinkronizacija, iznosimo svoje probleme, postavljamo prioritete, dijelimo se u timove i idemo u otklanjanje pogrešaka.

02:30. Dva velika problema protiv četiri oka
Nalazimo dva velika problema. Shvatili smo da korisnici neće vidjeti neke povezane usluge, a problemi će se pojaviti s partnerskim računima. Oba su posljedica nesavršenih migracijskih skripti za neke rubne slučajeve. Moramo to odmah popraviti.

Pišemo upite koji to bilježe, s najmanje 4 oka. Testiramo ih tijekom predprodukcije kako bismo bili sigurni da rade i da ništa ne kvare. Možete se kotrljati dalje. U isto vrijeme provodimo redovno testiranje integracije, koje otkriva još nekoliko problema. Svi su mali, ali i njih treba popraviti.

03:00. -2 problema +2 problema
Otklonjena su prethodna dva velika problema, ai gotovo svi manji. Svi oni koji nisu zauzeti popravcima aktivno rade na svojim računima i izvješćuju što nađu. Određujemo prioritete, raspodjeljujemo među timovima i ostavljamo nekritične stavke za jutro.

Ponovno provodimo testove, otkrivaju dva nova velika problema. Nisu sva pravila usluge stigla ispravno, tako da neki korisnički zahtjevi ne prolaze autorizaciju. Plus novi problem s partnerskim računima. Požurimo pogledati.

03:20. Hitna sinkronizacija
Riješen jedan novi problem. Za drugo, organiziramo hitnu sinkronizaciju. Razumijemo što se događa: prethodni popravak riješio je jedan problem, ali je stvorio drugi. Uzimamo pauzu kako bismo shvatili kako to učiniti ispravno i bez posljedica.

03:30. Šest očiju
Razumijemo kakvo bi trebalo biti konačno stanje baze kako bi sve prošlo dobro za sve partnere. Napišemo zahtjev sa 6 očiju, izbacimo ga u pretprodukciju, testiramo, izbacimo za proizvodnju.

04:00. Sve radi
Svi testovi su prošli, nema kritičnih problema. S vremena na vrijeme nekome nešto u ekipi ne ide, reagiramo promptno. Najčešće je alarm lažan. Ali ponekad nešto ne stigne, ili posebna stranica ne radi. Sjedimo, popravljamo, popravljamo, popravljamo. Poseban tim pokreće posljednju veliku značajku - naplatu.

04:30 sati. Točka bez povratka
Bliži se točka bez povratka, odnosno vrijeme kada, ako se krenemo vraćati unatrag, nećemo dočekati zastoj koji nam je dat. Ima problema s naplatom koja sve zna i bilježi, ali tvrdoglavo odbija otpisati novac klijentima. Postoji nekoliko grešaka na pojedinim stranicama, akcijama i statusima. Glavna funkcionalnost radi, svi testovi su uspješno prošli. Odlučimo da je uvođenje izvršeno, nećemo se vraćati.

06:00 sati. Otvoreno za sve u korisničkom sučelju
Greške ispravljene. Neke koje se ne dopadaju korisnicima ostavljamo za kasnije. Sučelje otvaramo svima. Nastavljamo s radom na naplati, čekamo povratne informacije korisnika i rezultate praćenja.

07:00 sati. Problemi s učitavanjem API-ja
Postaje jasno da smo malo pogrešno isplanirali opterećenje našeg API-ja i testirali ovo opterećenje, koje nije moglo identificirati problem. Kao rezultat toga, ≈5% zahtjeva ne uspije. Mobilizirajmo se i tražimo razlog.

Billing je tvrdoglav i ne želi ni raditi. Odlučujemo to odgoditi za kasnije kako bismo na miran način proveli promjene. Odnosno, u njemu se akumuliraju svi resursi, ali otpisi od klijenata ne prolaze. Naravno, to je problem, ali u usporedbi s općim uvođenjem čini se nevažnim.

08:00 sati. Popravi API
Izveli smo popravak za opterećenje, kvarovi su nestali. Počinjemo ići kući.

10:00 sati. svi
Sve je popravljeno. U nadgledanju je tiho, a kod kupaca tim postupno odlazi na spavanje. Naplata ostaje, vratit ćemo je sutra.

Zatim su tijekom dana uslijedila uvođenja koja su popravila zapisnike, obavijesti, povratne kodove i prilagodbe za neke od naših klijenata.

Dakle, uvođenje je bilo uspješno! Moglo je, naravno, bolje, ali izvukli smo zaključke o tome što nam nije dovoljno za postizanje savršenstva.

Ukupno

Tijekom 2 mjeseca aktivne pripreme za rollout odrađena su 43 zadatka u trajanju od nekoliko sati do nekoliko dana.

Tijekom uvođenja:

• novi i promijenjeni demoni - 5 komada, zamjenjujući 2 monolita;
• promjene unutar baza podataka - zahvaćeno je svih 6 naših baza podataka s korisničkim podacima, izvršena su preuzimanja iz tri stare baze podataka u jednu novu;
• potpuno redizajniran frontend;
• količina preuzetog koda - 33 tisuće redaka novog koda, ≈ 3 tisuće redaka koda u testovima, ≈ 5 tisuća redaka koda za migraciju;
• svi podaci su netaknuti, virtualni stroj nijednog kupca nije oštećen. 🙂

Dobre prakse za dobro uvođenje

Oni su nas vodili u ovoj teškoj situaciji. No, općenito govoreći, korisno ih je pratiti tijekom bilo kakvog uvođenja. Ali što je uvođenje složenije, to veću ulogu imaju.

1. Prva stvar koju trebate učiniti je razumjeti kako uvođenje može ili hoće utjecati na korisnike. Hoće li biti zastoja? Ako je tako, koje je vrijeme zastoja? Kako će to utjecati na korisnike? Koji su mogući najbolji i najgori mogući scenariji? I pokriti rizike.
2. Planirajte sve. U svakoj fazi morate razumjeti sve aspekte uvođenja:
   • dostava koda;
   • vraćanje koda;
   • vrijeme svake operacije;
   • pogođena funkcionalnost.
3. Igrajte kroz scenarije dok sve faze uvođenja, kao i rizici u svakoj od njih, ne postanu očigledni. Ako imate bilo kakvih nedoumica, možete uzeti pauzu i ispitati upitnu fazu zasebno.
4. Svaki stupanj se može i treba poboljšati ako pomaže našim korisnicima. Na primjer, smanjit će vrijeme zastoja ili ukloniti neke rizike.
5. Testiranje povrata puno je važnije od testiranja isporuke koda. Neophodno je provjeriti hoće li se sustav vratiti u prvobitno stanje kao rezultat vraćanja i to potvrditi testovima.
6. Sve što se može automatizirati treba biti automatizirano. Sve što se ne može automatizirati treba unaprijed napisati na varalicu.
7. Zabilježite kriterij uspjeha. Koja bi funkcionalnost trebala biti dostupna i u koje vrijeme? Ako se to ne dogodi, pokrenite plan vraćanja.
8. I što je najvažnije – ljudi. Svatko bi trebao biti svjestan što radi, zašto i što ovisi o njegovim radnjama u procesu uvođenja.

I jednom rečenicom, uz dobro planiranje i razradu možete izbaciti što god želite bez posljedica za prodaju. Čak i nešto što će utjecati na sve vaše usluge u proizvodnji.

Izvor: www.habr.com