da 12f-2
À a fini d'aprile, mentre i White Walkers assediavanu Winterfell, ci hè accadutu qualcosa di più interessante; avemu fattu un rollout inusual. In principiu, stendu constantemente novi funziunalità in a produzzione (cum'è tutti l'altri). Ma questu era diversu. A scala di questu era tale chì ogni sbagliu potenziale chì pudemu fà affettanu tutti i nostri servizii è utilizatori. In cunsiquenza, avemu sbulicatu tuttu secondu u pianu, in u periodu di downtime pianificatu è annunziatu, senza cunsequenze per a vendita. L'articulu hè nantu à cumu avemu ottinutu questu è cumu qualcunu pò ripetiri in casa.
Ùn aghju micca avà descriverà e decisioni architettoniche è tecniche chì avemu fattu o diceraghju cumu tuttu funziona. Quessi sò piuttostu noti in i marghjini nantu à cumu si facia unu di i rollouts più difficiuli, chì aghju osservatu è in quale era direttamente implicatu. Ùn riclamu micca a completezza o i dettagli tecnichi; forse apparisceranu in un altru articulu.
Sfondate + chì tipu di funziunalità hè questu?
Custruemu una piattaforma cloud (MCS), induve travaglià cum'è direttore tecnicu. È avà hè u tempu di aghjunghje IAM (Identity and Access Management) à a nostra piattaforma, chì furnisce una gestione unificata di tutti i cunti d'utilizatori, utilizatori, password, roli, servizii è più. Perchè hè necessariu in u nuvulu hè una quistione ovvia: tutte l'infurmazioni di l'utilizatori sò almacenati in questu.
Di solitu tali cose cumincianu à esse custruitu à u principiu di ogni prughjettu. Ma storicamente e cose sò state un pocu sfarente in MCS. MCS hè statu custruitu in dui parti:
- Openstack cù u so propiu modulu d'autorizazione Keystone,
- Hotbox (almacenamiento S3) basatu annantu à u prugettu Mail.ru Cloud,
attornu a quali novi servizii apparsu dopu.
Essenzialmente, si trattava di dui tipi diffirenti d'autorizazione. In più, avemu usatu qualchi sviluppi separati di Mail.ru, per esempiu, un almacenamentu di password generale di Mail.ru, è ancu un connettore openid auto-scrittu, grazie à quale SSO (autorizazione end-to-end) hè stata furnita in u pannellu Horizon. di macchine virtuali (interfaccia nativa OpenStack).
Fà l'IAM per noi significava cunnessu tuttu in un sistema unicu, cumpletamente u nostru. À u listessu tempu, ùn perdemu micca funziunalità in u caminu, ma creà una fundazione per u futuru chì ci permetterà di raffinà in modu trasparente senza refactoring è scala in termini di funziunalità. Ancu à u principiu, l'utilizatori avianu un mudellu di rolu per l'accessu à i servizii (RBAC centrale, cuntrollu di l'accessu basatu à u rolu) è qualchì altra cosa.
U compitu ùn hè micca trivial: python è perl, parechji backends, servizii scritti in modu indipendenti, parechji squadre di sviluppu è amministratori. È più impurtante, ci sò millaie di utilizatori in diretta nantu à u sistema di produzzione di cummattimentu. Tuttu chistu duvia esse scrittu è, più impurtante, sbulicatu senza vittime.
Chì andemu à sparghje ?
Per dì assai apprussimatamente, in circa 4 mesi avemu preparatu i seguenti:
- Avemu criatu parechji novi demoni chì aghjunghjenu funzioni chì anu travagliatu prima in diverse parti di l'infrastruttura. U restu di i servizii sò stati prescritti un novu backend in a forma di sti dimònii.
- Avemu scrittu u nostru propiu almacenamentu cintrali di password è chjave, dispunibule per tutti i nostri servizii, chì ponu esse mudificate liberamente cum'è avemu bisognu.
- Avemu scrittu 4 backends novi per Keystone da zero (utilizatori, prughjetti, roli, assignazioni di rolu), chì, in fattu, hà rimpiazzatu a so basa di dati, è avà agisce cum'è un solu repository per i nostri password d'utilizatori.
- Avemu insignatu à tutti i nostri servizii Openstack per andà in un serviziu di pulitica di terzu per e so pulitiche invece di leghje queste pulitiche in u locu da ogni servitore (iè, hè cusì chì Openstack funziona per difettu!)
Un tali rework maiò richiede cambiamenti grandi, cumplessi è, più impurtanti, sincroni in parechji sistemi scritti da diverse squadre di sviluppu. Una volta assemblatu, tuttu u sistema deve travaglià.
Cumu lancià tali cambiamenti è ùn sguassate micca? Prima avemu decisu di circà un pocu in u futuru.
Strategia di rollout
- Puderia esse rializatu u pruduttu in parechje tappe, ma questu puderia aumentà u tempu di sviluppu per trè volte. Inoltre, per qualchì tempu avemu avutu a desincronizazione completa di e dati in e basa di dati. Tu avissi a scrive u vostru propriu arnesi di sincronizazione è campà cù parechje magazzini di dati per un bellu pezzu. È questu crea una larga varietà di risichi.
- Tuttu ciò chì puderia esse preparatu in modu trasparente per l'utilizatore hè statu fattu in anticipu. Pigliò 2 mesi.
- Avemu permessu di u tempu di inattività per parechje ore - solu per l'operazioni di l'utilizatori per creà è cambià risorse.
- Per u funziunamentu di tutti i risorsi dighjà creati, u downtime era inacceptable. Avemu pianificatu chì durante u rollout, e risorse duveranu travaglià senza tempi di inattività è affettanu per i clienti.
- Per riduce l'impattu nantu à i nostri clienti se qualcosa va male, avemu decisu di lancià dumenica sera. Meno clienti gestisce e macchine virtuali di notte.
- Avemu avvistatu tutti i nostri clienti chì durante u periodu sceltu per u rollout, a gestione di u serviziu ùn serà micca dispunibule.
Digressione: chì hè un rollout?
Ogni specialista in IT pò risponde facilmente ciò chì hè un rollout. Stallà CI / CD, è tuttu hè automaticamente mandatu à a tenda. 🙂
Di sicuru, questu hè veru. Ma a difficultà hè chì cù i moderni strumenti d'automatizazione di consegna di codice, a cunniscenza di u rollout stessu hè persa. Cumu vi scurdate di l'epica di l'invenzione di a rota quandu si vede u trasportu mudernu. Tuttu hè cusì automatizatu chì u rollout hè spessu realizatu senza capisce tuttu u ritrattu.
È tutta a stampa hè cusì. U rollout hè custituitu da quattru aspetti principali:
- Consegna di codice, cumprese a mudificazione di dati. Per esempiu, e so migrazioni.
- Code rollback hè a capacità di vultà in daretu se qualcosa va male. Per esempiu, attraversu a creazione di salvezza.
- Tempu di ogni operazione di rollout / rollback. Avete bisognu di capisce u timing di ogni operazione di i primi dui punti.
- Funzionalità affettata. Hè necessariu di valutà sia l'effetti pusitivi previsti è pussibuli negativi.
Tutti questi aspetti deve esse cunsideratu per un rollout successu. Di solitu solu u primu, o in u megliu u sicondu, puntu hè valutatu, è poi u rollout hè cunsideratu successu. Ma u terzu è u quartu sò ancu più impurtanti. Quale utilizatore li piacerebbe se u rollout hà pigliatu 3 ore invece di un minutu? O se qualcosa innecessariu hè affettatu durante u rollout? O l'inattività di un serviziu porta à cunsequenze imprevisible?
Act 1..n, preparazione per a liberazione
Prima aghju pensatu à spiegà brevemente e nostre scontri : a squadra sana, e so parti, munzelli di discussioni à i punti di caffè, argumenti, teste, brainstorms. Allora pensu chì ùn saria micca necessariu. Quattru mesi di sviluppu sò sempre custituiti da questu, soprattuttu quandu ùn site micca scrittu qualcosa chì pò esse furnitu constantemente, ma una grande funzione per un sistema live. Chì tocca à tutti i servizii, ma nunda ùn deve cambià per l'utilizatori eccettu "un buttone in l'interfaccia web".
A nostra capiscitura di cumu si sparghje hà cambiatu da ogni nova riunione, è assai significativamente. Per esempiu, avemu da aghjurnà tutta a nostra basa di dati di fattura. Ma avemu calculatu u tempu è capimu chì era impussibile di fà questu in un tempu di rollout raghjone. Ci hà pigliatu quasi una settimana extra per sparghje è archivià a basa di dati di fattura. È quandu a velocità di rollout prevista ùn era micca soddisfacente, avemu urdinatu hardware supplementu, più putente, induve a basa sana hè stata trascinata. Ùn hè micca chì ùn avemu micca vulutu fà questu prima, ma l'attuale bisognu di stende ùn ci hà lasciatu senza opzioni.
Quandu unu di noi avia dubbitu chì u rollout puderia influenzà a dispunibilità di e nostre macchine virtuali, avemu passatu una settimana à fà testi, esperimenti, analisi di codice è hà ricivutu un capiscenu chjaramente chì questu ùn succede micca in a nostra pruduzzione, è ancu e persone più dubbite accunsenu. cun questu.
Intantu, i picciotti di u supportu tecnicu anu realizatu i so esperimenti indipendenti per scrive struzzioni per i clienti nantu à i metudi di cunnessione, chì duverebbe cambià dopu à u rollout. Hanu travagliatu nantu à l'UX di l'utilizatori, preparatu struzzioni è furnite cunsultazioni persunali.
Avemu automatizatu tutte e operazioni di rollout chì eranu pussibuli. Ogni operazione hè stata scritta, ancu i più sèmplice, è i testi sò stati constantemente eseguiti. Anu discutitu nantu à u megliu modu per disattivà u serviziu - omette u demoniu o bluccà l'accessu à u serviziu cù un firewall. Avemu creatu una lista di verificazione di squadre per ogni tappa di rollout è aghjurnata constantemente. Avemu tracciatu è aghjurnatu constantemente un diagramma di Gantt per tutti i travaglii di rollout, cù timings.
È cusì ...
L'attu finale, prima di rolling out
... hè ora di sparghje.
Comu dicenu, un travagliu d'arti ùn pò esse cumpletu, solu finitu di travaglià nantu à questu. Avete da fà un sforzu di vuluntà, capiscenu chì ùn truverete micca tuttu, ma crede chì avete fattu tutte l'ipotesi ragiunate, furnite per tutti i casi pussibuli, chjusu tutti i bug critichi, è tutti i participanti anu fattu tuttu ciò chì puderanu. Quantu più codice stende, u più difficiule hè di cunvince di questu (in più, ognunu capisce chì hè impussibile di prevede tuttu).
Avemu decisu chì eramu pronti à sparghje quandu eramu cunvinti chì avemu fattu tuttu ciò chì hè pussibule per copre tutti i risichi per i nostri utilizatori assuciati cù affetti inespettati è downtimes. Vale à dì, tuttu pò andà male, eccettu:
- Affectu (sacra per noi, più preziosa) infrastruttura d'utilizatori,
- Funzionalità: l'usu di u nostru serviziu dopu à u rollout deve esse u listessu cum'è prima.
Rolling out
Dui rotuli, 8 ùn interferiscenu micca
Pigliamu u tempu di inattività per tutte e dumande da l'utilizatori per 7 ore. À questu tempu, avemu un pianu di rollout è un pianu di rollback.
- U rollout stessu dura circa 3 ore.
- 2 ore per a prova.
- 2 ore - riservate per un eventuale rollback di cambiamenti.
Un diagramma di Gantt hè statu elaboratu per ogni azzione, quantu dura, ciò chì succede in sequenza, ciò chì hè fattu in parallelu.
Un pezzu di un diagramma di Gantt rollout, una di e prime versioni (senza esecuzione parallela). U Strumentu di Sincronizazione più preziosu
Tutti i participanti anu u so rolu in u rollout determinatu, ciò chì i travaglii facenu, è ciò chì sò rispunsevuli. Pruvemu di portà ogni tappa à l'automaticità, rollu, rinvià, raccoglie feedback è rinfriscà.
Cronica di l'eventi
Dunque, 15 parsoni sò ghjunti à travaglià dumenica 29 d'aprile à 10 ore di sera. In più di i participanti chjave, alcuni sò ghjunti solu per sustene a squadra, per quale ringraziu speciale per elli.
Hè vale a pena nutà chì u nostru tester chjave hè in vacanze. Hè impussibile di lancià senza pruvà, simu esplorate l'opzioni. Un cumpagnu accunsente à pruvà à noi da e vacanze, per quale ella riceve una immensa gratitudine da tutta a squadra.
00:00. Stop
Fermemu e dumande di l'utilizatori, appiccà un segnu chì dice u travagliu tecnicu. U monitoraghju urla, ma tuttu hè normale. Cuntrollamu chì nunda hè cascatu altru ch'è ciò chì duvia falà. È cuminciamu à travaglià nantu à a migrazione.
Ognunu hà un pianu di rollout stampatu puntu per puntu, ognunu sapi quale hè chì face è in quale mumentu. Dopu ogni azzione, cuntrollemu i timings per assicurà chì ùn li superemu micca, è tuttu va secondu u pianu. Quelli chì ùn participanu micca direttamente à u rollout in u stadiu attuale si preparanu lanciando un ghjoculu in linea (Xonotic, tipu 3 quacks) per ùn disturbà i so culleghi. 🙂
02:00. Sbulicatu
Una sorpresa piacevule - finiscemu u rollout una ora prima, per via di l'ottimisazione di e nostre basa di dati è script di migrazione. U gridu generale, "rottu fora!" Tutte e funzioni novi sò in produzzione, ma finu à avà solu pudemu vede in l'interfaccia. Tutti passanu in modu di prova, i sorte in gruppi, è cumincianu à vede ciò chì hè accadutu à a fine.
Ùn hè micca fattu assai bè, avemu capitu questu dopu à 10 minuti, quandu nunda hè cunnessu o chì travaglia in i prughjetti di i membri di a squadra. Sincronizazione rapida, esprimemu i nostri prublemi, stabilisce priorità, rompe in squadre è andemu in debugging.
02:30. Dui grandi prublemi versu quattru ochji
Truvemu dui grandi prublemi. Avemu capitu chì i clienti ùn anu micca vistu alcuni servizii cunnessi, è i prublemi si vanu cù i cunti di i partenarii. I dui sò dovuti à script di migrazione imperfetta per certi casi di punta. Avemu bisognu di riparà avà.
Scrivemu dumande chì registranu questu, cù almenu 4 ochji. Pruvemu durante a pre-produzione per assicurà chì travaglianu è ùn rompenu nunda. Pudete rollu nantu. À u listessu tempu, eseguimu a nostra prova di integrazione regulare, chì revela uni pochi di prublemi. Sò tutti chjuchi, ma anu ancu bisognu di riparà.
03:00. -2 prublemi + 2 prublemi
I dui grandi prublemi precedenti sò stati risolti, è quasi tutti i minuri ancu. Tutti quelli chì ùn sò micca occupati in correzioni sò attivamente travagliendu in i so cunti è raportanu ciò chì trovanu. Priurità, distributemu trà e squadre, è lasciamu articuli micca critichi per a matina.
Eseguimu i testi di novu, scopre dui novi grandi prublemi. Ùn sò micca tutte e pulitiche di serviziu ghjuntu currettamente, cusì alcune richieste di l'utilizatori ùn passanu micca l'autorizazione. In più un novu prublema cù i cunti partner. Precipitemu à vede.
03:20. Sincronizazione d'emergenza
Un novu prublema risolta. Per u sicondu, urganizemu una sincronia d'emergenza. Capemu ciò chì succede: a correzione precedente hà risoltu un prublema, ma hà creatu un altru. Facemu una pausa per capisce cumu fà bè è senza cunsequenze.
03:30. Sei ochji
Capemu ciò chì u statu finali di a basa deve esse cusì chì tuttu va bè per tutti i partenarii. Scrivemu una dumanda cù l'ochji 6, stendemu in pre-produzione, pruvemu, stendemu per a produzzione.
04:00. Tuttu travaglia
Tutte e teste sò passate, ùn ci sò micca prublemi critichi visibili. Da u tempu à u tempu, qualcosa in a squadra ùn viaghja micca per qualchissia, reagiscemu prontu. A maiò spessu l'alarma hè falsa. Ma qualchì volta qualcosa ùn ghjunghje micca, o una pagina separata ùn viaghja micca. Semu, riparemu, riparemu, riparamu. Una squadra separata lancia l'ultima grande funzione - fattura.
04:30. Puntu senza ritornu
S'avvicina u puntu di senza ritornu, vale à dì, u tempu quandu, se avemu principiatu à retrocede, ùn avemu micca scuntrà u downtime datu à noi. Ci sò prublemi cù a fattura, chì cunnosci è registra tuttu, ma stubbornly rifiuta di scrive soldi da i clienti. Ci sò parechji bug in pagine individuali, azzioni è stati. A funziunalità principale funziona, tutti i testi passanu bè. Decidiamu chì u rollout hè accadutu, ùn vulteremu micca.
06:00. Apertu per tutti in l'UI
Bugs fissi. Qualchidunu chì ùn appellu micca à l'utilizatori sò lasciati per più tardi. Avemu apertu l'interfaccia à tutti. Cuntinuemu à travaglià nantu à a fatturazione, aspittendu feedback di l'utilizatori è risultati di monitoraghju.
07:00. Prublemi cù a carica di l'API
Hè diventatu chjaru chì avemu un pocu misplanned a carica nantu à a nostra API è pruvatu sta carica, chì ùn pudia identificà u prublema. In u risultatu, ≈5% di e dumande falla. Mubilisemu è cerchemu u mutivu.
A fatturazione hè stubborn è ùn vole micca travaglià ancu. Decidiamu di posponà finu à più tardi per fà i cambiamenti in una manera tranquilla. Vale à dì, tutte e risorse sò accumulate in questu, ma scrive-off da i clienti ùn passanu micca. Di sicuru, questu hè un prublema, ma paragunatu à u rollout generale ùn pare micca impurtante.
08:00. Fix API
Avemu lanciatu una correzione per a carica, i fallimenti sò andati. Cuminciamu à andà in casa.
10:00. Tuttu
Tuttu hè fissu. Hè tranquillu in u monitoraghju è à u locu di i clienti, a squadra gradualmente si dorme. A fattura ferma, a restaurà dumane.
Dopu, durante u ghjornu, ci sò stati rollouts chì fissi logs, notificazioni, codici di ritornu è persunalizazione per alcuni di i nostri clienti.
Dunque, u rollout hè statu successu! Puderia, sicuru, esse megliu, ma avemu tiratu cunclusioni nantu à ciò chì ùn era micca abbastanza per noi per ottene a perfezione.
Tuttu
Duranti 2 mesi di preparazione attiva per u rollout, 43 compiti sò stati cumpletati, chì duranu da un paru d'ore à parechji ghjorni.
Durante u rollout:
- dimònii novi è cambiati - 5 pezzi, rimpiazzà 2 monoliti;
- cambiamenti in e basa di dati - tutte e 6 di e nostre basa di dati cù e dati di l'utilizatori sò state affettate, i scaricamenti sò stati fatti da trè vechji basa di dati à una nova;
- frontend cumplettamente riprogettatu;
- quantità di codice scaricatu - 33 mila linee di codice novu, ≈ 3 mila linee di codice in testi, ≈ 5 mila linee di codice migrazione;
- tutti i dati sò intactu, micca una sola macchina virtuale di u cliente hè stata dannata. 🙂
Bone pratiche per un bon rollout
Ci anu guidatu in questa situazione difficiule. Ma, in generale parlante, hè utile à seguità durante ogni rollout. Ma u più cumplessu u rollout, u più grande u rolu chì ghjucanu.
- A prima cosa chì duvete fà hè di capisce cumu u rollout pò influenzà l'utilizatori. Ci sarà un tempu di inattività ? Se sì, chì hè u tempu di inattività? Cumu questu affettarà l'utilizatori? Chì sò i possibili scenarii megliu è peghju? È copre i risichi.
- Pianu tuttu. In ogni tappa, avete bisognu di capiscenu tutti l'aspetti di u rollout:
- consegna codice;
- rollback codice;
- tempu di ogni operazione;
- funziunalità affettata.
- Ghjucate à traversu i scenarii finu à chì tutte e tappe di u rollout, è ancu i risichi in ognuna di elli, diventanu evidenti. Sì avete qualchì dubbiu, pudete piglià una pausa è esaminà a tappa discutibile separatamente.
- Ogni tappa pò è deve esse migliurata s'ellu aiuta i nostri utilizatori. Per esempiu, riducerà i tempi di inattività o eliminerà alcuni risichi.
- A prova di rollback hè assai più impurtante chè a prova di spedizione di codice. Hè imperativu di verificà chì, in u risultatu di u rollback, u sistema torna à u so statu originale, è cunfirmà questu cù testi.
- Tuttu ciò chì pò esse automatizatu deve esse automatizatu. Tuttu ciò chì ùn pò esse automatizatu deve esse scrittu in anticipu nantu à un fogliu di cheat.
- Registrate u criteriu di successu. Chì funziunalità deve esse dispunibule è à quale tempu? Se questu ùn succede micca, eseguite un pianu di rollback.
- E più impurtante - persone. Ognunu deve esse cuscenti di ciò chì facenu, perchè è ciò chì dipende di e so azzioni in u prucessu di rollout.
È in una frase, cù una bona pianificazione è l'elaborazione pudete sparghje tuttu ciò chì vulete senza cunsiquenzi per a vendita. Ancu qualcosa chì affetterà tutti i vostri servizii in a produzzione.
Source: www.habr.com