'n Uitrolverhaal wat alles beïnvloed het

Vyande van die werklikheid teen 12f-2

Aan die einde van April, terwyl die White Walkers Winterfell beleër het, het iets interessanter met ons gebeur; ons het 'n ongewone uitrol gedoen. In beginsel is ons voortdurend besig om nuwe kenmerke in produksie uit te voer (soos almal anders). Maar hierdie een was anders. Die omvang daarvan was sodanig dat enige potensiële foute wat ons kon maak al ons dienste en gebruikers sou beïnvloed. Gevolglik het ons alles volgens plan uitgerol, binne die beplande en aangekondigde stilstandtydperk, sonder gevolge vir verkope. Die artikel handel oor hoe ons dit bereik het en hoe enigiemand dit tuis kan herhaal.

Ek sal nie nou die argitektoniese en tegniese besluite wat ons geneem het beskryf of vertel hoe dit alles werk nie. Hierdie is eerder aantekeninge in die kantlyn oor hoe een van die moeilikste ontplooiings plaasgevind het, wat ek waargeneem het en waarby ek direk betrokke was. Ek maak nie aanspraak op volledigheid of tegniese besonderhede nie; miskien sal dit in 'n ander artikel verskyn.

Agtergrond + watter soort funksionaliteit is dit?

Ons bou 'n wolkplatform Mail.ru Wolkoplossings (MCS), waar ek as tegniese direkteur werk. En nou is dit tyd om IAM (Identity and Access Management) by ons platform te voeg, wat verenigde bestuur van alle gebruikersrekeninge, gebruikers, wagwoorde, rolle, dienste en meer bied. Waarom dit in die wolk nodig is, is 'n voor die hand liggende vraag: alle gebruikersinligting word daarin gestoor.

Gewoonlik begin sulke dinge heel aan die begin van enige projekte gebou word. Maar histories was dinge 'n bietjie anders in MCS. MCS is in twee dele gebou:

• Openstack met sy eie Keystone-magtigingsmodule,
• Hotbox (S3-berging) gebaseer op die Mail.ru Cloud-projek,

waaromheen nuwe dienste toe verskyn het.

In wese was dit twee verskillende tipes magtiging. Boonop het ons 'n paar aparte Mail.ru-ontwikkelings gebruik, byvoorbeeld 'n algemene Mail.ru-wagwoordberging, sowel as 'n selfgeskrewe openid-verbinding, waardeur SSO (end-tot-end-magtiging) in die Horizon-paneel verskaf is van virtuele masjiene (inheemse OpenStack UI).

Om IAM vir ons te maak, het beteken om dit alles in 'n enkele stelsel te verbind, heeltemal ons eie. Terselfdertyd sal ons nie enige funksionaliteit langs die pad verloor nie, maar sal 'n grondslag vir die toekoms skep wat ons in staat sal stel om dit deursigtig te verfyn sonder om dit te herfaktoreer en te skaal in terme van funksionaliteit. Ook aan die begin het gebruikers 'n rolmodel gehad vir toegang tot dienste (sentrale RBAC, rolgebaseerde toegangsbeheer) en 'n paar ander klein dingetjies.

Die taak het geblyk nie-triviaal te wees: luislang en perl, verskeie backends, onafhanklik geskrewe dienste, verskeie ontwikkelingspanne en administrateurs. En die belangrikste is dat daar duisende lewendige gebruikers op die gevegproduksiestelsel is. Dit alles moes geskryf word en, bowenal, sonder ongevalle uitgerol word.

Wat gaan ons uitrol?

Om dit baie rofweg te stel, in ongeveer 4 maande het ons die volgende voorberei:

• Ons het verskeie nuwe daemone geskep wat funksies saamgevoeg het wat voorheen in verskillende dele van die infrastruktuur gewerk het. Die res van die dienste is 'n nuwe agterkant in die vorm van hierdie demone voorgeskryf.
• Ons het ons eie sentrale berging van wagwoorde en sleutels geskryf, beskikbaar vir al ons dienste, wat vrylik gewysig kan word soos ons nodig het.
• Ons het 4 nuwe backends vir Keystone van nuuts af geskryf (gebruikers, projekte, rolle, roltoewysings), wat in werklikheid sy databasis vervang het, en nou dien as 'n enkele bewaarplek vir ons gebruikerswagwoorde.
• Ons het al ons Openstack-dienste geleer om na 'n derdeparty-beleiddiens te gaan vir hul beleide in plaas daarvan om hierdie beleide plaaslik vanaf elke bediener te lees (ja, dis hoe Openstack by verstek werk!)

So 'n groot herbewerking vereis groot, komplekse en, bowenal, sinchrone veranderinge in verskeie stelsels wat deur verskillende ontwikkelingspanne geskryf is. Sodra dit saamgestel is, behoort die hele stelsel te werk.

Hoe om sulke veranderinge uit te voer en dit nie op te ruk nie? Eers het ons besluit om 'n bietjie in die toekoms te kyk.

Ontplooiingstrategie

• Dit sou moontlik wees om die produk in verskeie stadiums uit te rol, maar dit sal die ontwikkelingstyd met drie keer vermeerder. Daarbenewens sou ons vir 'n geruime tyd volledige desinchronisasie van data in die databasisse hê. Jy sal jou eie sinchronisasie-instrumente moet skryf en vir 'n lang tyd met veelvuldige datawinkels moet leef. En dit skep 'n wye verskeidenheid risiko's.
• Alles wat deursigtig vir die gebruiker voorberei kon word, is vooraf gedoen. Dit het 2 maande geneem.
• Ons het onsself vir 'n paar uur stilstand toegelaat - slegs vir gebruikersbedrywighede om hulpbronne te skep en te verander.
• Vir die werking van alle reeds geskepte hulpbronne was stilstand onaanvaarbaar. Ons het beplan dat hulpbronne tydens ontplooiing sonder stilstand moet werk en dit vir kliënte moet beïnvloed.
• Om die impak op ons kliënte te verminder as iets verkeerd loop, het ons besluit om Sondagaand uit te rol. Minder kliënte bestuur virtuele masjiene in die nag.
• Ons het al ons kliënte gewaarsku dat diensbestuur nie beskikbaar sal wees gedurende die tydperk wat vir ontplooiing gekies is nie.

Afwyking: wat is 'n ontplooiing?

<versigtigheid, filosofie>

Elke IT-spesialis kan maklik antwoord wat 'n ontplooiing is. Jy installeer CI/CD, en alles word outomaties by die winkel afgelewer. 🙂

Dit is natuurlik waar. Maar die moeilikheid is dat met moderne kodeafleweringsoutomatiseringsinstrumente die begrip van die uitrol self verlore gaan. Hoe jy vergeet van die epiesiteit van die uitvinding van die wiel wanneer jy na moderne vervoer kyk. Alles is so geoutomatiseer dat die ontplooiing dikwels uitgevoer word sonder om die hele prentjie te verstaan.

En die hele prentjie is so. Ontplooiing bestaan ​​uit vier hoofaspekte:

1. Lewering van kode, insluitend data wysiging. Byvoorbeeld, hul migrasies.
2. Kode terugrol is die vermoë om terug te gaan as iets verkeerd gaan. Byvoorbeeld, deur die skep van rugsteun.
3. Tyd van elke ontplooiing/terugrolbewerking. Jy moet die tydsberekening van enige bewerking van die eerste twee punte verstaan.
4. Geaffekteerde funksionaliteit. Dit is nodig om beide die verwagte positiewe en moontlike negatiewe effekte te evalueer.

Al hierdie aspekte moet in ag geneem word vir 'n suksesvolle ontplooiing. Gewoonlik word slegs die eerste, of op sy beste die tweede, punt beoordeel, en dan word die uitrol as suksesvol beskou. Maar die derde en vierde is selfs belangriker. Watter gebruiker sal daarvan hou as die ontplooiing 3 uur neem in plaas van 'n minuut? Of as iets onnodig geraak word tydens die ontplooiing? Of sal die stilstand van een diens tot onvoorspelbare gevolge lei?

Wet 1..n, voorbereiding vir vrylating

Ek het eers daaraan gedink om ons vergaderings kortliks te beskryf: die hele span, sy dele, hope besprekings by koffiepunte, argumente, toetse, dinkskrums. Toe dink ek dit sal onnodig wees. Vier maande se ontwikkeling bestaan ​​altyd hieruit, veral as jy nie iets skryf wat voortdurend afgelewer kan word nie, maar een groot kenmerk vir 'n lewendige stelsel. Wat alle dienste raak, maar niks behoort vir gebruikers te verander nie, behalwe "een knoppie in die webkoppelvlak."

Ons begrip van hoe om uit te voer, het van elke nuwe vergadering verander, en nogal aansienlik. Ons sou byvoorbeeld ons hele faktuurdatabasis opdateer. Maar ons het die tyd bereken en besef dat dit onmoontlik was om dit in 'n redelike ontplooiingstyd te doen. Dit het ons amper 'n ekstra week geneem om die faktuurdatabasis te versnipper en te argiveer. En toe die verwagte uitrolspoed steeds nie bevredigend was nie, het ons bykomende, kragtiger hardeware bestel, waar die hele basis gesleep is. Dit is nie dat ons dit nie vroeër wou doen nie, maar die huidige behoefte om uit te voer het ons geen opsies gelaat nie.

Toe een van ons twyfel dat die ontplooiing die beskikbaarheid van ons virtuele masjiene kan beïnvloed, het ons 'n week spandeer om toetse, eksperimente, kode-analise uit te voer en 'n duidelike begrip gekry dat dit nie in ons produksie sou gebeur nie, en selfs die mees twyfelagtige mense het saamgestem met hierdie.

Intussen het die ouens van tegniese ondersteuning hul eie onafhanklike eksperimente uitgevoer om instruksies vir kliënte te skryf oor verbindingsmetodes, wat veronderstel was om na die ontplooiing te verander. Hulle het aan gebruikers-UX gewerk, instruksies voorberei en persoonlike konsultasies verskaf.

Ons het alle ontplooiingsoperasies wat moontlik was, geoutomatiseer. Elke operasie is geskryf, selfs die eenvoudigste, en toetse is voortdurend uitgevoer. Hulle het gestry oor die beste manier om die diens af te skakel - laat die daemon weg of blokkeer toegang tot die diens met 'n brandmuur. Ons het 'n kontrolelys van spanne vir elke fase van ontplooiing geskep en dit voortdurend bygewerk. Ons het 'n Gantt-grafiek geteken en voortdurend opgedateer vir alle ontplooiingswerk, met tydsberekeninge.

En so…

Die laaste handeling, voor die uitrol

...dit is tyd om uit te rol.

Soos hulle sê, 'n kunswerk kan nie voltooi word nie, net klaar gewerk daaraan. Jy moet 'n wilspoging doen, verstaan ​​dat jy nie alles sal vind nie, maar glo dat jy alle redelike aannames gemaak het, voorsiening gemaak het vir alle moontlike gevalle, alle kritieke foute toegemaak het, en alle deelnemers het alles gedoen wat hulle kon. Hoe meer kode jy uitrol, hoe moeiliker is dit om jouself hiervan te oortuig (buitendien verstaan ​​almal dat dit onmoontlik is om alles te voorsien).

Ons het besluit dat ons gereed was om uit te voer toe ons oortuig was dat ons alles moontlik gedoen het om al die risiko's vir ons gebruikers wat verband hou met onverwagte invloede en stilstand te dek. Dit wil sê, enigiets kan verkeerd loop behalwe:

1. Beïnvloed (heilig vir ons, mees kosbare) gebruikersinfrastruktuur,
2. Funksionaliteit: die gebruik van ons diens na die ontplooiing moet dieselfde wees as voor dit.

Uitrol

Twee rol, 8 meng nie in nie

Ons neem stilstandtyd vir alle versoeke van gebruikers vir 7 uur. Op hierdie tydstip het ons beide 'n ontplooiingsplan en 'n terugrolplan.

• Die ontplooiing self neem ongeveer 3 uur.
• 2 uur vir toetsing.
• 2 uur - reserveer vir 'n moontlike terugrol van veranderinge.

'n Gantt-kaart is vir elke aksie opgestel, hoe lank dit neem, wat opeenvolgend gebeur, wat parallel gedoen word.

'n Stukkie van 'n Gantt-grafiek, een van die vroeë weergawes (sonder parallelle uitvoering). Die waardevolste sinchronisasie-instrument

Alle deelnemers se rol in die ontplooiing word bepaal, watter take hulle doen en waarvoor hulle verantwoordelik is. Ons probeer om elke stadium tot outomatisiteit te bring, dit uit te rol, terug te rol, terugvoer in te samel en dit weer uit te rol.

Kroniek van gebeure

So, 15 mense het Sondag, 29 April, om 10:XNUMX werk toe gekom. Benewens die sleuteldeelnemers het sommige bloot die span kom ondersteun, waarvoor spesiale dank aan hulle gerig word.

Dit is ook die moeite werd om te noem dat ons sleuteltoetser met vakansie is. Dit is onmoontlik om uit te voer sonder om te toets, ons ondersoek opsies. 'n Kollega stem in om ons van vakansie te toets, waarvoor sy groot dankbaarheid van die hele span ontvang.

00:00. Stop
Ons stop gebruikersversoeke, hang 'n bordjie op wat sê tegniese werk. Die monitering skree, maar alles is normaal. Ons kyk dat niks anders geval het as wat veronderstel was om te val nie. En ons begin werk aan migrasie.

Almal het punt vir punt 'n gedrukte uitrolplan, almal weet wie wat doen en op watter oomblik. Na elke aksie gaan ons die tydsberekeninge na om te verseker dat ons dit nie oorskry nie, en alles verloop volgens plan. Diegene wat nie op die huidige stadium direk aan die ontplooiing deelneem nie, berei voor deur 'n aanlyn speelding (Xonotic, tipe 3 kwaksalwers) bekend te stel om nie hul kollegas te steur nie. 🙂

02:00. Uitgerol
'n Aangename verrassing - ons voltooi die ontplooiing 'n uur vroeër, as gevolg van die optimalisering van ons databasisse en migrasie skrifte. Die algemene kreet, "uitgerol!" Alle nuwe funksies is in produksie, maar tot dusver kan net ons dit in die koppelvlak sien. Almal gaan in toetsmodus, sorteer hulle in groepe en begin sien wat op die ou end gebeur het.

Dit het nie baie goed uitgedraai nie, ons besef dit na 10 minute, wanneer niks in die spanlede se projekte gekoppel is of werk nie. Vinnige sinchronisasie, ons spreek ons ​​probleme uit, stel prioriteite, breek in spanne in en gaan oor na ontfouting.

02:30. Twee groot probleme vs vier oë
Ons vind twee groot probleme. Ons het besef dat klante sommige gekoppelde dienste nie sou sien nie, en probleme sou met vennootrekeninge ontstaan. Albei is te wyte aan onvolmaakte migrasieskrifte vir sommige randgevalle. Ons moet dit nou regmaak.

Ons skryf navrae wat dit opteken, met ten minste 4 oë. Ons toets hulle tydens voorproduksie om seker te maak dat hulle werk en niks breek nie. Jy kan aanrol. Terselfdertyd voer ons ons gereelde integrasietoetsing uit, wat nog 'n paar probleme aan die lig bring. Hulle is almal klein, maar hulle moet ook herstel word.

03:00. -2 probleme +2 probleme
Die twee vorige groot probleme is reggestel, en byna al die klein ook. Almal wat nie besig is met regstellings nie, werk aktief in hul rekeninge en rapporteer wat hulle vind. Ons prioritiseer, versprei onder spanne, en los nie-kritieke items vir die oggend.

Ons doen die toetse weer, hulle ontdek twee nuwe groot probleme. Nie alle diensbeleide het korrek aangekom nie, so sommige gebruikerversoeke slaag nie magtiging nie. Plus 'n nuwe probleem met vennootrekeninge. Kom ons jaag om te kyk.

03:20. Noodsinkronisering
Een nuwe probleem opgelos. Vir die tweede reël ons 'n noodsinkronisering. Ons verstaan ​​wat gebeur: die vorige oplossing het een probleem opgelos, maar 'n ander geskep. Ons neem 'n breek om uit te vind hoe om dit korrek en sonder gevolge te doen.

03:30. Ses oë
Ons verstaan ​​wat die finale toestand van die basis moet wees sodat alles goed gaan vir alle vennote. Ons skryf 'n versoek met 6 oë, rol dit uit in voorproduksie, toets dit, rol dit uit vir produksie.

04:00. Alles werk
Alle toetse geslaag, geen kritieke probleme is sigbaar nie. Van tyd tot tyd werk iets in die span nie vir iemand nie, ons reageer stiptelik. Meestal is die alarm vals. Maar soms kom iets nie aan nie, of 'n aparte bladsy werk nie. Ons sit, maak reg, maak reg, maak reg. 'n Afsonderlike span stel die laaste groot kenmerk bekend - faktuur.

04:30. Punt van geen terugkeer
Die punt van geen terugkeer kom nader, dit wil sê die tyd wanneer, as ons begin terugrol, ons nie die stilstand wat aan ons gegee is, sal haal nie. Daar is probleme met fakturering, wat alles weet en opteken, maar hardnekkig weier om geld van kliënte af te skryf. Daar is verskeie foute op individuele bladsye, aksies en statusse. Die hooffunksie werk, alle toetse slaag suksesvol. Ons besluit dat die ontplooiing plaasgevind het, ons sal nie terugrol nie.

06:00. Oop vir almal in die UI
Foute reggemaak. Sommige wat nie by gebruikers aanklank vind nie, word vir later gelos. Ons maak die koppelvlak vir almal oop. Ons gaan voort om te werk aan fakturering, wag vir gebruikersterugvoer en monitering van resultate.

07:00. Probleme met API-lading
Dit word duidelik dat ons die las op ons API effens verkeerd beplan het en hierdie vrag getoets het, wat nie die probleem kon identifiseer nie. As gevolg hiervan misluk ≈5% van versoeke. Kom ons mobiliseer en soek die rede.

Rekening is hardnekkig en wil ook nie werk nie. Ons besluit om dit tot later uit te stel om die veranderinge op 'n rustige wyse deur te voer. Dit wil sê, alle hulpbronne word daarin opgehoop, maar afskrywings van kliënte gaan nie deur nie. Natuurlik is dit 'n probleem, maar in vergelyking met die algemene uitrol lyk dit onbelangrik.

08:00. Maak API reg
Ons het 'n oplossing vir die vrag uitgerol, die mislukkings het verdwyn. Ons begin huis toe gaan.

10:00. Almal
Alles is reggemaak. Dit is stil in monitering en by die klante se plek gaan die span geleidelik aan die slaap. Die rekening bly, ons sal dit môre herstel.

Dan was daar gedurende die dag ontplooiings wat logs, kennisgewings, terugkeerkodes en aanpassings vir sommige van ons kliënte reggemaak het.

So, die ontplooiing was suksesvol! Dit kan natuurlik beter wees, maar ons het gevolgtrekkings gemaak oor wat nie genoeg was vir ons om perfeksie te bereik nie.

In totaal

Gedurende 2 maande se aktiewe voorbereiding vir die ontplooiing is 43 take voltooi, wat van 'n paar uur tot 'n paar dae geduur het.

Tydens ontplooiing:

• nuwe en veranderde demone - 5 stukke, vervang 2 monoliete;
• veranderinge binne die databasisse - al 6 ons databasisse met gebruikersdata is geraak, aflaaie is van drie ou databasisse na een nuwe een gemaak;
• heeltemal herontwerpte voorkant;
• hoeveelheid afgelaaide kode - 33 duisend reëls nuwe kode, ≈ 3 duisend reëls kode in toetse, ≈ 5 duisend reëls migrasiekode;
• alle data is ongeskonde, nie 'n enkele kliënt se virtuele masjien is beskadig nie. 🙂

Goeie praktyke vir goeie ontplooiing

Hulle het ons in hierdie moeilike situasie gelei. Maar oor die algemeen is dit nuttig om hulle te volg tydens enige ontplooiing. Maar hoe meer kompleks die uitrol, hoe groter die rol speel hulle.

1. Die eerste ding wat u moet doen is om te verstaan ​​hoe die ontplooiing gebruikers kan of sal beïnvloed. Sal daar stilstand wees? Indien wel, wat is die stilstand? Hoe sal dit gebruikers raak? Wat is die moontlike beste en slegste scenario's? En dek die risiko's.
2. Beplan alles. In elke stadium moet jy alle aspekte van ontplooiing verstaan:
   • kode aflewering;
   • kode terugrol;
   • tyd van elke operasie;
   • geaffekteerde funksionaliteit.
3. Speel deur die scenario's totdat alle stadiums van die ontplooiing, sowel as die risiko's by elk van hulle, duidelik word. As jy enige twyfel het, kan jy 'n breek neem en die twyfelagtige stadium afsonderlik ondersoek.
4. Elke stadium kan en moet verbeter word as dit ons gebruikers help. Dit sal byvoorbeeld stilstand verminder of sommige risiko's verwyder.
5. Terugdraaitoetsing is baie belangriker as kodeafleweringstoetsing. Dit is nodig om seker te maak dat die stelsel as gevolg van die terugrol na sy oorspronklike toestand sal terugkeer, en dit met toetse bevestig.
6. Alles wat geoutomatiseer kan word, moet geoutomatiseer word. Alles wat nie geoutomatiseer kan word nie, moet vooraf op 'n cheat sheet geskryf word.
7. Teken die sukseskriterium aan. Watter funksionaliteit moet beskikbaar wees en op watter tydstip? As dit nie gebeur nie, voer 'n terugrolplan uit.
8. En die belangrikste – mense. Almal moet bewus wees van wat hulle doen, hoekom en wat afhang van hul optrede in die ontplooiingsproses.

En in een sin, met goeie beplanning en uitwerking kan jy enigiets uitrol wat jy wil sonder gevolge vir verkope. Selfs iets wat al jou dienste in produksie sal beïnvloed.

Bron: will.com