ved 12f-2
I slutningen af april, mens White Walkers belejrede Winterfell, skete der noget mere interessant for os; vi lavede en usædvanlig udrulning. I princippet ruller vi konstant nye funktioner ud i produktionen (som alle andre). Men denne var anderledes. Omfanget af det var sådan, at eventuelle potentielle fejl, vi kunne begå, ville påvirke alle vores tjenester og brugere. Det resulterede i, at vi udrullede alt efter planen, inden for den planlagte og annoncerede nedetid, uden konsekvenser for salget. Artiklen handler om, hvordan vi opnåede dette, og hvordan alle kan gentage det derhjemme.
Jeg vil ikke nu beskrive de arkitektoniske og tekniske beslutninger, vi tog, eller fortælle, hvordan det hele fungerer. Det er snarere noter i margenen om, hvordan en af de sværeste udrulninger fandt sted, som jeg observerede, og hvor jeg var direkte involveret. Jeg påstår ikke fuldstændighed eller tekniske detaljer; måske vil de blive vist i en anden artikel.
Baggrund + hvilken slags funktionalitet er dette?
Vi bygger en cloud platform (MCS), hvor jeg arbejder som teknisk direktør. Og nu er det tid til at tilføje IAM (Identity and Access Management) til vores platform, som giver ensartet administration af alle brugerkonti, brugere, adgangskoder, roller, tjenester og mere. Hvorfor det er nødvendigt i skyen er et oplagt spørgsmål: al brugerinformation er gemt i den.
Normalt begynder sådanne ting at blive bygget helt i begyndelsen af ethvert projekt. Men historisk set har tingene været lidt anderledes i MCS. MCS blev bygget i to dele:
- Openstack med sit eget Keystone-godkendelsesmodul,
- Hotbox (S3-lagring) baseret på Mail.ru Cloud-projektet,
omkring hvilke nye tjenester så dukkede op.
Grundlæggende var der tale om to forskellige typer autorisation. Derudover brugte vi nogle separate Mail.ru-udviklinger, for eksempel den generelle Mail.ru-adgangskodelagring, samt en selvskrevet openid-forbindelse, takket være hvilken SSO (ende-til-ende-godkendelse) blev leveret i Horizon-panelet af virtuelle maskiner (native OpenStack UI).
At lave IAM for os betød at forbinde det hele til et enkelt system, helt vores eget. Samtidig mister vi ikke nogen funktionalitet undervejs, men skaber et fundament for fremtiden, der gør det muligt for os på en transparent måde at forfine den uden at omfaktorere og skalere den funktionsmæssigt. Også i starten havde brugerne en rollemodel for adgang til tjenester (central RBAC, rollebaseret adgangskontrol) og nogle andre småting.
Opgaven viste sig at være ikke-triviel: python og perl, flere backends, uafhængigt skrevne tjenester, flere udviklingsteams og administratorer. Og vigtigst af alt er der tusindvis af live-brugere på kampproduktionssystemet. Alt dette skulle skrives og, vigtigst af alt, rulles ud uden tilskadekomne.
Hvad skal vi rulle ud?
For at sige det meget groft forberedte vi følgende på omkring 4 måneder:
- Vi skabte flere nye dæmoner, der samlede funktioner, der tidligere fungerede i forskellige dele af infrastrukturen. Resten af tjenesterne blev foreskrevet en ny backend i form af disse dæmoner.
- Vi skrev vores egen centrale lagring af adgangskoder og nøgler, tilgængelig for alle vores tjenester, som frit kan ændres efter behov.
- Vi skrev 4 nye backends til Keystone fra bunden (brugere, projekter, roller, rolletildelinger), som faktisk erstattede dens database og nu fungerer som et enkelt lager for vores brugeradgangskoder.
- Vi lærte alle vores Openstack-tjenester at gå til en tredjeparts politiktjeneste for deres politikker i stedet for at læse disse politikker lokalt fra hver server (ja, det er sådan Openstack fungerer som standard!)
Sådan et stort omarbejde kræver store, komplekse og vigtigst af alt synkrone ændringer i flere systemer skrevet af forskellige udviklingsteams. Når det er samlet, burde hele systemet fungere.
Hvordan ruller man sådanne ændringer ud og ikke ødelægger det? Først besluttede vi at se lidt ind i fremtiden.
Udrulningsstrategi
- Det ville være muligt at rulle produktet ud i flere trin, men det ville øge udviklingstiden med tre gange. Derudover ville vi i nogen tid have fuldstændig desynkronisering af data i databaserne. Du skulle skrive dine egne synkroniseringsværktøjer og leve med flere datalagre i lang tid. Og dette skaber en bred vifte af risici.
- Alt, hvad der kunne forberedes transparent for brugeren, blev gjort på forhånd. Det tog 2 måneder.
- Vi tillod os selv nedetid i flere timer - kun for brugeroperationer for at skabe og ændre ressourcer.
- For driften af alle allerede oprettede ressourcer var nedetid uacceptabel. Vi planlagde, at under udrulningen skulle ressourcer fungere uden nedetid og påvirke kunderne.
- For at mindske indvirkningen på vores kunder, hvis noget går galt, besluttede vi at rulle ud søndag aften. Færre kunder administrerer virtuelle maskiner om natten.
- Vi advarede alle vores kunder om, at servicestyring ikke vil være tilgængelig i den periode, der er valgt til udrulning.
Digression: hvad er en udrulning?
<forsigtighed, filosofi>
Enhver it-specialist kan nemt svare på, hvad en udrulning er. Du installerer CI/CD, og alt bliver automatisk leveret til butikken. 🙂
Selvfølgelig er dette sandt. Men vanskeligheden er, at med moderne værktøjer til automatisering af kodelevering går forståelsen af selve udrulningen tabt. Hvordan du glemmer det episke ved opfindelsen af hjulet, når du ser på moderne transport. Alt er så automatiseret, at udrulningen ofte udføres uden at forstå hele billedet.
Og hele billedet er sådan her. Udrulningen består af fire hovedaspekter:
- Levering af kode, inklusive dataændring. For eksempel deres migrationer.
- Kode rollback er muligheden for at gå tilbage, hvis noget går galt. For eksempel gennem oprettelse af sikkerhedskopier.
- Tidspunkt for hver udrulning/tilbageføring. Du skal forstå timingen af enhver operation af de første to punkter.
- Berørt funktionalitet. Det er nødvendigt at vurdere både de forventede positive og mulige negative effekter.
Alle disse aspekter skal tages i betragtning for en vellykket udrulning. Normalt vurderes kun det første, eller i bedste fald det andet, punkt, og derefter anses udrulningen for at være vellykket. Men den tredje og fjerde er endnu vigtigere. Hvilken bruger ville gerne have det, hvis udrulningen tog 3 timer i stedet for et minut? Eller hvis noget unødvendigt bliver påvirket under udrulningen? Eller vil nedetiden for én tjeneste føre til uforudsigelige konsekvenser?
Akt 1..n, forberedelse til frigivelse
Først tænkte jeg på kort at beskrive vores møder: hele teamet, dets dele, bunkevis af diskussioner på kaffesteder, argumenter, tests, brainstorms. Så tænkte jeg, at det ville være unødvendigt. Fire måneders udvikling består altid af dette, især når du ikke skriver noget, der kan leveres konstant, men én stor feature til et live system. Hvilket påvirker alle tjenester, men intet bør ændre sig for brugerne undtagen "én knap i webgrænsefladen."
Vores forståelse af, hvordan man ruller ud, ændrede sig fra hvert nyt møde, og det er ganske betydeligt. For eksempel skulle vi opdatere hele vores faktureringsdatabase. Men vi beregnede tiden og indså, at det var umuligt at gøre dette inden for en rimelig udrulningstid. Det tog os næsten en ekstra uge at skære og arkivere faktureringsdatabasen. Og da den forventede udrulningshastighed stadig ikke var tilfredsstillende, bestilte vi yderligere, kraftigere hardware, hvor hele basen blev slæbt. Det er ikke fordi, vi ikke ønskede at gøre dette før, men det nuværende behov for at rulle ud efterlod os ingen muligheder.
Da en af os var i tvivl om, at udrulningen kunne påvirke tilgængeligheden af vores virtuelle maskiner, brugte vi en uge på at udføre test, eksperimenter, kodeanalyse og fik en klar forståelse af, at dette ikke ville ske i vores produktion, og selv de mest tvivlsomme mennesker var enige. med dette.
I mellemtiden udførte fyrene fra teknisk support deres egne uafhængige eksperimenter for at skrive instruktioner til klienter om tilslutningsmetoder, som skulle ændre sig efter udrulningen. De arbejdede med bruger-UX, udarbejdede instruktioner og leverede personlige konsultationer.
Vi automatiserede alle udrulningsoperationer, der var mulige. Hver operation blev scriptet, selv de simpleste, og test blev kørt konstant. De skændtes om den bedste måde at slå tjenesten fra - udelad dæmonen eller bloker adgangen til tjenesten med en firewall. Vi oprettede en tjekliste over teams for hver fase af udrulningen og opdaterede den konstant. Vi tegnede og opdaterede konstant et Gantt-diagram for alt udrulningsarbejde med timings.
Også…
Den sidste akt, før den rulles ud
...det er tid til at rulle ud.
Som de siger, kan et kunstværk ikke færdiggøres, kun færdigbearbejde det. Du skal gøre en indsats af vilje, forstå, at du ikke finder alt, men tro, at du har gjort alle rimelige antagelser, sørget for alle mulige tilfælde, lukket alle kritiske fejl, og alle deltagere gjorde alt, hvad de kunne. Jo mere kode du ruller ud, jo sværere er det at overbevise dig selv om dette (desuden forstår alle, at det er umuligt at forudse alt).
Vi besluttede, at vi var klar til at rulle ud, da vi var overbevist om, at vi havde gjort alt for at dække alle de risici for vores brugere forbundet med uventede påvirkninger og nedetider. Det vil sige, alt kan gå galt undtagen:
- Påvirker (helligt for os, mest dyrebare) brugerinfrastruktur,
- Funktionalitet: brugen af vores service efter udrulningen skal være den samme som før den.
Ruller ud
To kast, 8 blander sig ikke
Vi tager nedetid for alle anmodninger fra brugere i 7 timer. På nuværende tidspunkt har vi både en udrulningsplan og en tilbagerulningsplan.
- Selve udrulningen tager cirka 3 timer.
- 2 timer til test.
- 2 timer - forbehold for en eventuel tilbagerulning af ændringer.
Der er udarbejdet et Gantt-diagram for hver handling, hvor lang tid det tager, hvad sker der sekventielt, hvad der udføres parallelt.
Et stykke af et udrulnings-Gantt-diagram, en af de tidlige versioner (uden parallel udførelse). Det mest værdifulde synkroniseringsværktøj
Alle deltagere får bestemt deres rolle i udrulningen, hvilke opgaver de udfører, og hvad de er ansvarlige for. Vi forsøger at bringe hvert trin til automatik, rulle det ud, rulle det tilbage, indsamle feedback og rulle det ud igen.
Begivenheds kronik
Så der kom 15 personer på arbejde søndag den 29. april kl. 10. Foruden nøgledeltagerne kom nogle blot for at støtte holdet, hvilket en særlig tak til dem.
Det er også værd at nævne, at vores nøgletester er på ferie. Det er umuligt at rulle ud uden test, vi undersøger muligheder. En kollega siger ja til at teste os fra ferien, hvilket hun modtager enorm taknemmelighed for fra hele holdet.
00:00. Hold op
Vi stopper brugeranmodninger, hænger et skilt op, hvor der står teknisk arbejde. Overvågningen skriger, men alt er normalt. Vi tjekker, at der ikke faldt andet end det, der skulle falde. Og vi begynder arbejdet med migration.
Alle har en udskrevet udrulningsplan punkt for punkt, alle ved, hvem der gør hvad og i hvilket øjeblik. Efter hver handling tjekker vi tiderne for at sikre, at vi ikke overskrider dem, og alt går efter planen. De, der ikke deltager i udrulningen direkte på nuværende tidspunkt, forbereder sig ved at lancere et online legetøj (Xonotic, type 3 kvaksalvere) for ikke at forstyrre deres kolleger. 🙂
02:00. Rullet ud
En behagelig overraskelse - vi afslutter udrulningen en time tidligere på grund af optimeringen af vores databaser og migreringsscripts. Det generelle råb, "rullet ud!" Alle nye funktioner er i produktion, men indtil videre kan kun vi se dem i grænsefladen. Alle går i testtilstand, sorterer dem i grupper og begynder at se, hvad der skete til sidst.
Det blev ikke særlig godt, det indser vi efter 10 minutter, hvor intet er forbundet eller arbejder i teammedlemmernes projekter. Hurtig synkronisering, vi giver udtryk for vores problemer, sætter prioriteter, bryder ind i teams og går ind i fejlretning.
02:30. To store problemer vs fire øjne
Vi finder to store problemer. Vi indså, at kunderne ikke ville se nogle forbundne tjenester, og der ville opstå problemer med partnerkonti. Begge skyldes ufuldstændige migreringsscripts for nogle edge cases. Vi er nødt til at ordne det nu.
Vi skriver forespørgsler, der registrerer dette, med mindst 4 øjne. Vi tester dem under præproduktionen for at sikre, at de virker og ikke går i stykker. Du kan rulle videre. Samtidig kører vi vores almindelige integrationstest, som afslører lidt flere problemer. De er alle små, men de skal også repareres.
03:00. -2 problemer +2 problemer
De to tidligere store problemer er blevet rettet, og næsten alle de mindre også. Alle dem, der ikke er optaget i rettelser, arbejder aktivt i deres konti og rapporterer, hvad de finder. Vi prioriterer, fordeler mellem teams og efterlader ikke-kritiske genstande til morgenen.
Vi kører testene igen, de opdager to nye store problemer. Ikke alle servicepolitikker ankom korrekt, så nogle brugeranmodninger går ikke igennem godkendelsen. Plus et nyt problem med partnerkonti. Lad os skynde os at se.
03:20. Nødsynkronisering
Et nyt problem rettet. For det andet organiserer vi en nødsynkronisering. Vi forstår, hvad der sker: den tidligere rettelse løste et problem, men skabte et andet. Vi holder en pause for at finde ud af, hvordan vi gør det korrekt og uden konsekvenser.
03:30. Seks øjne
Vi forstår, hvad den endelige tilstand af basen skal være, så alt går godt for alle partnere. Vi skriver en anmodning med 6 øjne, ruller den ud i præproduktion, tester den, ruller den ud til produktion.
04:00. Alt fungerer
Alle test bestået, ingen kritiske problemer er synlige. Fra tid til anden virker noget i teamet ikke for nogen, vi reagerer prompte. Oftest er alarmen falsk. Men nogle gange kommer der ikke noget, eller en separat side virker ikke. Vi sidder, fikser, fikser, fikser. Et separat team lancerer den sidste store funktion - fakturering.
04:30. Ingen vej tilbage
Point of no return nærmer sig, det vil sige tidspunktet, hvor vi, hvis vi begynder at rulle tilbage, ikke vil møde den nedetid, vi har fået. Der er problemer med fakturering, som ved og registrerer alt, men stædigt nægter at afskrive penge fra kunder. Der er flere fejl på individuelle sider, handlinger og statusser. Hovedfunktionaliteten fungerer, alle test bestået med succes. Vi beslutter at udrulningen har fundet sted, vi ruller ikke tilbage.
06:00. Åben for alle i brugergrænsefladen
Bugs rettet. Nogle, der ikke appellerer til brugerne, overlades til senere. Vi åbner grænsefladen for alle. Vi fortsætter med at arbejde med fakturering, venter på brugerfeedback og overvåger resultater.
07:00. Problemer med API-belastning
Det bliver tydeligt, at vi en smule fejlplanlagde belastningen på vores API og testede denne belastning, hvilket ikke kunne identificere problemet. Som et resultat mislykkes ≈5 % af anmodningerne. Lad os mobilisere og lede efter årsagen.
Fakturering er stædig og vil heller ikke fungere. Vi beslutter at udskyde det til senere for at gennemføre ændringerne på en rolig måde. Det vil sige, at alle ressourcer akkumuleres i det, men afskrivninger fra kunder går ikke igennem. Dette er selvfølgelig et problem, men sammenlignet med den generelle udrulning virker det ligegyldigt.
08:00. Ret API
Vi udrullede en løsning til belastningen, fejlene forsvandt. Vi begynder at gå hjem.
10:00. Alle
Alt er fikset. Der er stille i overvågningen og hos kunderne går holdet gradvist i dvale. Faktureringen forbliver, vi genopretter den i morgen.
Så i løbet af dagen var der udrulninger, der fikserede logfiler, notifikationer, returkoder og tilpasninger for nogle af vores kunder.
Så udrulningen lykkedes! Det kunne selvfølgelig være bedre, men vi trak konklusioner om, hvad der ikke var nok til, at vi opnåede perfektion.
I alt
I løbet af 2 måneders aktiv forberedelse til udrulningen blev 43 opgaver udført, der varede fra et par timer til flere dage.
Under udrulning:
- nye og ændrede dæmoner - 5 stykker, der erstatter 2 monolitter;
- ændringer i databaserne - alle 6 af vores databaser med brugerdata er blevet påvirket, downloads er foretaget fra tre gamle databaser til en ny;
- fuldstændig redesignet frontend;
- mængde af downloadet kode - 33 tusind linjer ny kode, ≈ 3 tusind linjer kode i test, ≈ 5 tusind linjer migrationskode;
- alle data er intakte, ikke en eneste kundes virtuelle maskine blev beskadiget. 🙂
God praksis for god udrulning
De vejledte os i denne vanskelige situation. Men generelt set er det nyttigt at følge dem under enhver udrulning. Men jo mere kompleks udrulningen er, jo større rolle spiller de.
- Den første ting, du skal gøre, er at forstå, hvordan udrulningen kan eller vil påvirke brugerne. Vil der være nedetid? Hvis ja, hvad er nedetiden? Hvordan vil dette påvirke brugerne? Hvad er de mulige bedste og værste scenarier? Og dækker risiciene.
- Planlæg alt. På hvert trin skal du forstå alle aspekter af udrulning:
- kode levering;
- kode tilbagerulning;
- tidspunktet for hver operation;
- påvirket funktionalitet.
- Spil scenarierne igennem, indtil alle stadier af udrulningen, såvel som risiciene ved hver af dem, bliver tydelige. Hvis du er i tvivl, kan du tage en pause og undersøge den tvivlsomme fase separat.
- Hvert trin kan og bør forbedres, hvis det hjælper vores brugere. For eksempel vil det reducere nedetid eller fjerne nogle risici.
- Rollback-test er meget vigtigere end kodeleveringstest. Det er nødvendigt at kontrollere, at systemet som følge af tilbagerulningen vil vende tilbage til sin oprindelige tilstand, og bekræfte dette med test.
- Alt, der kan automatiseres, bør automatiseres. Alt, der ikke kan automatiseres, skal på forhånd skrives på et snydeark.
- Registrer succeskriteriet. Hvilken funktionalitet skal være tilgængelig og på hvilket tidspunkt? Hvis dette ikke sker, skal du køre en tilbagerulningsplan.
- Og vigtigst af alt - mennesker. Alle bør være opmærksomme på, hvad de laver, hvorfor og hvad afhænger af deres handlinger i udrulningsprocessen.
Og i én sætning kan du med god planlægning og uddybning udrulle alt, hvad du vil, uden konsekvenser for salget. Endda noget, der vil påvirke alle dine tjenester i produktionen.
Kilde: www.habr.com