troch 12f-2
Ein april, wylst de Wite Walkers Winterfell belegere, barde wat nijsgjirrigers mei ús; wy diene in ûngewoane útrol. Yn prinsipe rôlje wy konstant nije funksjes út yn produksje (lykas elkenien). Mar dizze wie oars. De skaal dêrfan wie sa dat alle mooglike flaters dy't wy koenen meitsje, al ús tsjinsten en brûkers beynfloedzje. Dêrtroch hawwe wy alles neffens plan útrôle, binnen de plande en oankundige downtime perioade, sûnder gefolgen foar de ferkeap. It artikel giet oer hoe't wy dit berikt hawwe en hoe't elkenien it thús kin werhelje.
Ik sil no de arsjitektoanyske en technyske besluten dy't wy makken net beskriuwe of fertelle hoe't it allegear wurket. Dit binne earder notysjes yn 'e marzje oer hoe't ien fan 'e dreechste útrols plakfûn, dy't ik observearre en dêr't ik direkt by belutsen wie. Ik beweare gjin folsleinens of technyske details; miskien sille se yn in oar artikel ferskine.
Eftergrûn + wat soarte fan funksjonaliteit is dit?
Wy bouwe in wolkplatfoarm (MCS), dêr't ik wurkje as technysk direkteur. En no is it tiid om IAM (Identiteits- en tagongsbehear) ta te foegjen oan ús platfoarm, dat ienriedich behear leveret fan alle brûkersakkounts, brûkers, wachtwurden, rollen, tsjinsten en mear. Wêrom is it nedich yn 'e wolk is in foar de hân lizzende fraach: alle brûkersynformaasje is deryn opslein.
Meastentiids begjinne sokke dingen oan it begjin fan alle projekten te bouwen. Mar histoarysk binne dingen in bytsje oars west yn MCS. MCS waard boud yn twa dielen:
- Openstack mei syn eigen Keystone-autorisaasjemodule,
- Hotbox (S3 opslach) basearre op it Mail.ru Cloud-projekt,
dêr't doe nije tsjinsten omhinne ferskynden.
Yn essinsje wiene dit twa ferskillende soarten autorisaasje. Plus, wy brûkten wat aparte Mail.ru-ûntwikkelingen, bygelyks in algemiene Mail.ru-wachtwurd opslach, lykas ek in selsskreaune openid-ferbining, wêrtroch SSO (end-to-end autorisaasje) waard levere yn it Horizon-paniel fan firtuele masines (native OpenStack UI).
IAM meitsje foar ús betsjutte it allegear te ferbinen yn ien systeem, folslein ús eigen. Tagelyk sille wy ûnderweis gjin funksjonaliteit ferlieze, mar sille wy in stifting foar de takomst meitsje dy't ús tastean om it transparant te ferfine sûnder te refactorearjen en te skaaljen yn termen fan funksjonaliteit. Ek by it begjin hienen brûkers in rolmodel foar tagong ta tsjinsten (sintrale RBAC, rolbasearre tagongskontrôle) en wat oare lytse dingen.
De taak die bliken net-trivial te wêzen: python en perl, ferskate backends, ûnôfhinklik skreaune tsjinsten, ferskate ûntwikkelingsteams en admins. En it wichtichste is dat d'r tûzenen live brûkers binne op it fjochtproduksjesysteem. Dit alles moast skreaun wurde en, it wichtichste, sûnder slachtoffers útrôle.
Wat sille wy útrolje?
Om it heul rûch te sizzen, hawwe wy yn sawat 4 moannen it folgjende taret:
- Wy makken ferskate nije daemons dy't funksjes aggregearren dy't earder wurken yn ferskate dielen fan 'e ynfrastruktuer. De rest fan 'e tsjinsten waarden foarskreaun in nije backend yn' e foarm fan dizze demoanen.
- Wy hawwe ús eigen sintrale opslach fan wachtwurden en kaaien skreaun, beskikber foar al ús tsjinsten, dy't frij kinne wurde oanpast as wy nedich binne.
- Wy skreaunen 4 nije backends foar Keystone fanôf it begjin (brûkers, projekten, rollen, rolopdrachten), dy't, yn feite, syn database ferfong, en no fungearret as ien repository foar ús brûkerswachtwurden.
- Wy learden al ús Openstack-tsjinsten om nei in beliedstsjinst fan tredden te gean foar har belied ynstee fan dit belied lokaal te lêzen fan elke server (ja, dat is hoe't Openstack standert wurket!)
Sa'n grutte rework fereasket grutte, komplekse en, wichtichste, syngroane feroarings yn ferskate systemen skreaun troch ferskate ûntwikkeling teams. Ienris gearstald moat it hiele systeem wurkje.
Hoe kinne sokke wizigingen útrolje en it net ferneatigje? Earst hawwe wy besletten om in bytsje yn de takomst te sjen.
Rollout strategy
- It soe mooglik wêze om it produkt yn ferskate stadia út te rôljen, mar dit soe de ûntwikkelingstiid trije kear ferheegje. Derneist soene wy foar in skoft folsleine desyngronisaasje fan gegevens yn 'e databases hawwe. Jo soene jo eigen syngronisaasje-ark moatte skriuwe en in lange tiid mei meardere gegevenswinkels libje. En dit soarget foar in breed ferskaat oan risiko's.
- Alles wat transparant foar de brûker koe wurde taret, waard foarôf dien. It duorre 2 moannen.
- Wy lieten ússels ferskate oeren downtime ta - allinich foar brûkersoperaasjes om boarnen te meitsjen en te feroarjen.
- Foar de eksploitaasje fan alle al oanmakke boarnen wie downtime net akseptabel. Wy planden dat tidens de útrol boarnen moatte wurkje sûnder downtime en ynfloed hawwe op kliïnten.
- Om de ynfloed op ús klanten te ferminderjen as der wat mis giet, hawwe wy besletten om sneintejûn út te rollen. Minder klanten beheare firtuele masines nachts.
- Wy warskôgen al ús kliïnten dat yn 'e perioade selekteare foar útrol, tsjinstbehear net beskikber sil wêze.
Digression: wat is in útrol?
<foarsichtigens, filosofy>
Elke IT-spesjalist kin maklik beäntwurdzje wat in útrol is. Jo ynstallearje CI / CD, en alles wurdt automatysk levere oan de winkel. 🙂
Fansels is dit wier. Mar de muoite is dat mei moderne ark foar automatisearring fan koadelevering, it begryp fan 'e útrol sels ferlern is. Hoe't jo ferjitte oer de episkens fan 'e útfining fan it tsjil as jo sjogge nei moderne ferfier. Alles is sa automatisearre dat de útrol faaks útfierd wurdt sûnder it hiele byld te begripen.
En it hiele byld is sa. Rollout bestiet út fjouwer wichtige aspekten:
- Levering fan koade, ynklusyf data modifikaasje. Bygelyks, harren migraasjes.
- Koade rollback is de mooglikheid om werom te gean as der wat mis giet. Bygelyks troch it meitsjen fan backups.
- Tiid fan elke rollout / rollback operaasje. Jo moatte de timing fan elke operaasje fan 'e earste twa punten begripe.
- Beynfloede funksjonaliteit. It is needsaaklik om sawol de ferwachte positive as mooglike negative effekten te evaluearjen.
Al dizze aspekten moatte rekken holden wurde foar in suksesfolle útrol. Gewoanlik wurdt allinich it earste, of op syn bêst it twadde, punt beoardiele, en dan wurdt de útrol as suksesfol beskôge. Mar de tredde en fjirde binne noch wichtiger. Hokker brûker soe it graach wolle as de útrol 3 oeren duorre ynstee fan in minút? Of as der wat net nedich wurdt beynfloede tidens de útrol? Of sil de downtime fan ien tsjinst liede ta ûnfoarspelbere gefolgen?
Wet 1..n, tarieding foar frijlitting
Earst tocht ik om ús gearkomsten koart te beskriuwen: it hiele team, syn ûnderdielen, heapen diskusjes op kofjepunten, arguminten, tests, brainstorms. Doe tocht ik dat it net nedich wêze soe. Fjouwer moannen fan ûntwikkeling bestiet altyd út dit, benammen as jo net skriuwe wat dat kin wurde levere konstant, mar ien grutte funksje foar in live systeem. Wat alle tsjinsten beynfloedet, mar neat soe feroarje moatte foar brûkers útsein "ien knop yn 'e webynterface."
Us begryp fan hoe't jo útrolje feroare fan elke nije gearkomste, en frij signifikant. Wy soene bygelyks ús hiele faktureardatabase bywurkje. Mar wy hawwe de tiid berekkene en realisearre dat it ûnmooglik wie om dit yn in ridlike útroltiid te dwaan. It hat ús hast in wike ekstra duorre om de fakturedatabase te sjitten en te argivearjen. En doe't de ferwachte útrolsnelheid noch net befredigjend wie, bestelden wy ekstra, machtiger hardware, wêr't de heule basis waard sleept. It is net dat wy dit net earder woene dwaan, mar de hjoeddeistige needsaak om út te rollen liet ús gjin opsjes hawwe.
Doe't ien fan ús twifels hie dat de útrol de beskikberens fan ús firtuele masines koe beynfloedzje, hawwe wy in wike trochbrocht oan it útfieren fan tests, eksperiminten, koade-analyze en krigen in dúdlik begryp dat dit net soe barre yn ús produksje, en sels de meast twifele minsken wiene it iens hjirmei.
Yn 'e tuskentiid hawwe de jonges fan technyske stipe har eigen ûnôfhinklike eksperiminten útfierd om ynstruksjes foar kliïnten te skriuwen oer ferbiningsmetoaden, dy't nei de útrol feroarje moasten. Se wurken oan brûkers-UX, tariede ynstruksjes en levere persoanlike konsultaasjes.
Wy automatisearren alle útroloperaasjes dy't mooglik wiene. Elke operaasje waard skreaun, sels de ienfâldichste, en tests waarden konstant útfierd. Se rieden oer de bêste manier om de tsjinst út te skeakeljen - de daemon oerlitte of tagong ta de tsjinst blokkearje mei in firewall. Wy makken in checklist fan teams foar elke faze fan útrol en hawwe dizze konstant bywurke. Wy hawwe in Gantt-diagram tekene en konstant bywurke foar alle útrolwurk, mei timings.
Ensa…
De lêste akte, foardat it útrolt
... it is tiid om út te rollen.
Sa't se sizze, in keunstwurk kin net foltôge wurde, allinne klear wurke oan it. Jo moatte meitsje in poging fan wil, begripe dat jo net fine alles, mar leauwe dat jo hawwe makke alle ridlike oannames, foarsjoen foar alle mooglike gefallen, sluten alle krityske bugs, en alle dielnimmers diene alles se koenen. Hoe mear koade jo útrolje, hoe dreger it is om josels hjirfan te oertsjûgjen (njonkenlytsen begrypt elkenien dat it ûnmooglik is om alles te foarsjen).
Wy besletten dat wy ree wiene om út te rollen doe't wy derfan oertsjûge wiene dat wy alles dien hiene om alle risiko's foar ús brûkers te dekken dy't ferbûn binne mei ûnferwachte effekten en downtimes. Dat is, alles kin ferkeard gean, útsein:
- Beynfloedzje (hillich foar ús, meast kostber) brûkersynfrastruktuer,
- Funksjonaliteit: it gebrûk fan ús tsjinst nei de útrol moat itselde wêze as dêrfoar.
Útrolje
Twa roll, 8 net interfere
Wy nimme downtime foar alle oanfragen fan brûkers foar 7 oeren. Op dit stuit hawwe wy sawol in rolloutplan as in rollbackplan.
- De útrol sels duorret sawat 3 oeren.
- 2 oeren foar testen.
- 2 oeren - reservearje foar in mooglike rollback fan feroarings.
In Gantt-diagram is opsteld foar elke aksje, hoe lang it duorret, wat bart opfolgjend, wat wurdt parallel dien.
In stik fan in rollout Gantt-diagram, ien fan 'e iere ferzjes (sûnder parallelle útfiering). De meast weardefolle syngronisaasje-ark
Alle dielnimmers hawwe har rol yn 'e útrol bepaald, hokker taken se dogge en wêr't se ferantwurdlik foar binne. Wy besykje elke poadium ta automatisiteit te bringen, rôlje it út, rôlje it werom, sammelje feedback en rôlje it wer út.
Kronyk fan barrens
Sa kamen snein 15 april om 29 oere 10 minsken oan it wurk. Njonken de wichtichste dielnimmers kamen guon gewoan om it team te stypjen, wêrfoar spesjale tank oan harren.
It is ek it neamen wurdich dat ús kaaitester op fakânsje is. It is ûnmooglik om út te rollen sûnder te testen, wy ferkenne opsjes. In kollega stimt yn om ús fan 'e fakânsje te testen, dêr't se fan it hiele team ûnbidige tankberens foar krijt.
00:00. Ophâlde
Wy stopje brûkersoanfragen, hingje in teken op dat technysk wurk seit. De monitoaring raast, mar alles is normaal. Wy kontrolearje dat der neat oars foel as wat falle soe. En wy begjinne wurk oan migraasje.
Elkenien hat punt foar punt in printe útrolplan, elkenien wit wa't wat docht en op hokker momint. Nei elke aksje kontrolearje wy de timings om te soargjen dat wy se net oerkomme, en alles giet neffens plan. Dejingen dy't net direkt meidogge oan 'e útrol yn' e hjoeddeistige poadium binne har tariede troch it lansearjen fan in online boartersguod (Xonotic, type 3 quacks) om har kollega's net te fersteuren. 🙂
02:00. Útrôle
In noflike ferrassing - wy foltôgje de útrol in oere earder, fanwegen de optimalisaasje fan ús databases en migraasjeskripts. De algemiene rop, "útrôle!" Alle nije funksjes binne yn produksje, mar oant no kinne wy se allinich sjen yn 'e ynterface. Elkenien giet yn testmodus, sortearret se yn groepen, en begjint te sjen wat der op it lêst bard is.
It slagge net sa goed, wy realisearje dit nei 10 minuten, as neat ferbûn is of wurket yn 'e projekten fan' e teamleden. Snelle syngronisaasje, wy stimme ús problemen, stelle prioriteiten, brekke yn teams en gean nei debuggen.
02:30. Twa grutte problemen vs fjouwer eagen
Wy fine twa grutte problemen. Wy realisearre dat klanten soene net sjen guon ferbûn tsjinsten, en problemen soe ûntstean mei partner akkounts. Beide binne te tankjen oan ûnfolsleine migraasjeskripts foar guon rânegefallen. Wy moatte it no reparearje.
Wy skriuwe fragen dy't dit opnimme, mei op syn minst 4 eagen. Wy testje se by preproduksje om te soargjen dat se wurkje en neat brekke. Jo kinne rôlje troch. Tagelyk fiere wy ús reguliere yntegraasjetesten út, dy't noch in pear problemen iepenbieret. Se binne allegear lyts, mar se moatte ek reparearre wurde.
03:00. -2 problemen +2 problemen
De twa eardere grutte problemen binne reparearre, en hast alle lytse ek. Al dyjingen dy't net beset binne yn fixes wurkje aktyf yn har akkounts en rapportearje wat se fine. Wy prioritearje, fersprieden ûnder teams, en litte net-krityske items foar de moarn.
Wy rinne de tests wer, se ûntdekke twa nije grutte problemen. Net alle tsjinstbelied binne goed oankommen, sadat guon brûkersfersiken gjin autorisaasje trochjaan. Plus in nij probleem mei partner akkounts. Lit ús haasten om te sjen.
03:20. Emergency syngronisaasje
Ien nij probleem fêst. Foar de twadde organisearje wy in needsyngronisaasje. Wy begripe wat der bart: de foarige fix reparearre ien probleem, mar makke in oar. Wy nimme in skoft om út te finen hoe't jo it korrekt en sûnder gefolgen dwaan kinne.
03:30. Seis eagen
Wy begripe wat de definitive steat fan 'e basis moat wêze, sadat alles goed giet foar alle partners. Wy skriuwe in fersyk mei 6 eagen, rôlje it út yn pre-produksje, test it, rôlje it út foar produksje.
04:00. Alles wurket
Alle testen binne trochjûn, gjin krityske problemen binne sichtber. Sa no en dan wurket wat yn it team net foar ien, wy reagearje prompt. Meast faak is it alarm falsk. Mar soms komt der wat net, of wurket in aparte side net. Wy sitte, reparearje, reparearje, reparearje. In apart team lanseart de lêste grutte funksje - fakturearring.
04:30. Point of no return
It punt fan gjin weromkommen komt tichterby, dat is de tiid dat, as wy begjinne te rôljen, wy de downtime dy't ús jûn is net sille foldwaan. Der binne problemen mei fakturearring, dy't alles wit en registrearret, mar stiif wegeret om jild fan kliïnten ôf te skriuwen. D'r binne ferskate bugs op yndividuele siden, aksjes en statusen. De wichtichste funksjonaliteit wurket, alle testen passe mei sukses. Wy beslute dat de útrol plakfûn hat, wy sille net werom rôlje.
06:00. Iepenje foar elkenien yn 'e UI
Bugs fêst. Guon dy't brûkers net oansprekke, wurde oerlitten foar letter. Wy iepenje de ynterface foar elkenien. Wy wurkje fierder oan fakturearring, wachtsje op brûkersfeedback en tafersjoch op resultaten.
07:00. Problemen mei API load
It wurdt dúdlik dat wy de lading op ús API in bytsje ferkeard planden en dizze lading testen, dy't it probleem net koe identifisearje. As gefolch mislearje ≈5% fan oanfragen. Lit ús mobilisearje en sykje nei de reden.
Billing is koppich en wol ek net wurkje. Wy beslute om it út te stellen oant letter om de feroarings op in kalme manier troch te fieren. Dat is, alle middels wurde sammele yn it, mar ôfskriuwings fan kliïnten net gean troch. Fansels is dit in probleem, mar yn ferliking mei de algemiene útrol liket it ûnbelangryk.
08:00. Fix API
Wy rôle in fix foar de lading, de mislearrings giene fuort. Wy begjinne nei hûs te gean.
10:00. Alle
Alles stiet fêst. It is stil by it tafersjoch en by de klanten giet it team stadichoan yn sliep. De fakturearring bliuwt, wy sille it moarn weromsette.
Dan wiene d'r oerdeis rollouts dy't logs, notifikaasjes, weromkoades en oanpassingen fêststelle foar guon fan ús kliïnten.
Dat, de útrol wie suksesfol! It koe fansels better, mar wy lutsen konklúzjes oer wat net genôch wie foar ús om folsleinens te berikken.
Totaal
Tidens 2 moannen fan aktive tarieding foar de útrol waarden 43 taken foltôge, dy't duorre fan in pear oeren oant ferskate dagen.
Tidens útrol:
- nije en feroare demoanen - 5 stikken, ferfanging fan 2 monoliten;
- feroarings binnen de databases - alle 6 fan ús databases mei brûkersgegevens binne beynfloede, downloads binne makke fan trije âlde databases nei ien nije;
- folslein opnij ûntwurpen frontend;
- bedrach fan ynladen koade - 33 tûzen rigels fan nije koade, ≈ 3 tûzen rigels koade yn tests, ≈ 5 tûzen rigels fan migraasjekoade;
- alle gegevens binne yntakt, net ien klant syn firtuele masine waard skansearre. 🙂
Goede praktiken foar goede útrol
Se liede ús yn dizze drege situaasje. Mar, oer it algemien, is it handich om se te folgjen by elke útrol. Mar hoe komplekser de útrol, hoe grutter de rol se spylje.
- It earste ding dat jo moatte dwaan is te begripen hoe't de útrol brûkers kin of sil beynfloedzje. Sil der downtime wêze? As dat sa is, wat is de downtime? Hoe sil dit ynfloed hawwe op brûkers? Wat binne de mooglike bêste en minste senario's? En dekke de risiko's.
- Plan alles. Yn elke faze moatte jo alle aspekten fan útrol begripe:
- koade levering;
- koade weromdraaie;
- tiid fan elke operaasje;
- beynfloede funksjonaliteit.
- Spielje troch de senario's oant alle stadia fan 'e útrol, lykas de risiko's by elk fan har, dúdlik wurde. As jo twifels hawwe, kinne jo in skoft nimme en it twifele poadium apart ûndersykje.
- Elke poadium kin en moat wurde ferbettere as it ús brûkers helpt. It sil bygelyks downtime ferminderje of guon risiko's fuortsmite.
- Rollback-testen is folle wichtiger dan testen foar levering fan koade. It is needsaaklik om te kontrolearjen dat as gefolch fan it weromdraaien it systeem werom sil nei syn oarspronklike steat, en befêstigje dit mei tests.
- Alles dat kin wurde automatisearre moat wurde automatisearre. Alles dat net kin wurde automatisearre, moat fan tefoaren op in cheat sheet skreaun wurde.
- Record it súkses kritearium. Hokker funksjonaliteit moat beskikber wêze en op hokker tiid? As dit net bart, fier dan in weromrolplan.
- En it wichtichste - minsken. Elkenien moat bewust wêze fan wat se dogge, wêrom en wat hinget fan har aksjes yn it útrolproses.
En yn ien sin kinne jo mei goede planning en útwurking alles útrolje dat jo wolle sûnder gefolgen foar de ferkeap. Sels iets dat sil beynfloedzje al jo tsjinsten yn produksje.
Boarne: www.habr.com