En utrullingshistorie som påvirket alt

Fiender av virkeligheten med 12f-2

I slutten av april, mens White Walkers beleiret Winterfell, skjedde det noe mer interessant med oss; vi gjorde en uvanlig utrulling. I prinsippet ruller vi stadig ut nye funksjoner i produksjon (som alle andre). Men denne var annerledes. Omfanget av det var slik at eventuelle potensielle feil vi kunne gjøre ville påvirke alle våre tjenester og brukere. Det resulterte i at vi rullet ut alt etter planen, innenfor den planlagte og annonserte nedetidsperioden, uten konsekvenser for salget. Artikkelen handler om hvordan vi oppnådde dette og hvordan hvem som helst kan gjenta det hjemme.

Jeg vil ikke nå beskrive de arkitektoniske og tekniske avgjørelsene vi tok eller fortelle hvordan det hele fungerer. Dette er snarere merknader i margen om hvordan en av de vanskeligste utrullingene fant sted, som jeg observerte og som jeg var direkte involvert i. Jeg påstår ikke fullstendighet eller tekniske detaljer; kanskje de vil vises i en annen artikkel.

Bakgrunn + hva slags funksjonalitet er dette?

Vi bygger en skyplattform Mail.ru skyløsninger (MCS), hvor jeg jobber som teknisk direktør. Og nå er det på tide å legge til IAM (Identity and Access Management) til plattformen vår, som gir enhetlig administrasjon av alle brukerkontoer, brukere, passord, roller, tjenester og mer. Hvorfor det er nødvendig i skyen er et åpenbart spørsmål: all brukerinformasjon er lagret i den.

Vanligvis begynner slike ting å bygges helt i begynnelsen av ethvert prosjekt. Men historisk sett har ting vært litt annerledes i MCS. MCS ble bygget i to deler:

• Openstack med sin egen Keystone-autorisasjonsmodul,
• Hotbox (S3-lagring) basert på Mail.ru Cloud-prosjektet,

som nye tjenester så dukket opp rundt.

I hovedsak var dette to forskjellige typer autorisasjoner. I tillegg brukte vi noen separate Mail.ru-utviklinger, for eksempel den generelle Mail.ru-passordlagringen, samt en selvskrevet openid-kobling, takket være hvilken SSO (ende-til-ende-autorisasjon) ble gitt i Horizon-panelet av virtuelle maskiner (native OpenStack UI).

Å lage IAM for oss innebar å koble alt sammen til et enkelt system, helt vårt eget. Samtidig vil vi ikke miste noen funksjonalitet underveis, men vil skape et grunnlag for fremtiden som gjør at vi transparent kan foredle den uten å refaktorere og skalere den med tanke på funksjonalitet. Også i starten hadde brukerne et forbilde for tilgang til tjenester (sentral RBAC, rollebasert tilgangskontroll) og noen andre småting.

Oppgaven viste seg å være ikke-triviell: python og perl, flere backends, uavhengig skrevne tjenester, flere utviklingsteam og administratorer. Og viktigst av alt, det er tusenvis av live-brukere på kampproduksjonssystemet. Alt dette måtte skrives og, viktigst av alt, rulles ut uten skader.

Hva skal vi rulle ut?

For å si det veldig grovt, på omtrent 4 måneder forberedte vi følgende:

• Vi opprettet flere nye demoner som samlet funksjoner som tidligere fungerte i forskjellige deler av infrastrukturen. Resten av tjenestene ble foreskrevet en ny backend i form av disse demonene.
• Vi skrev vår egen sentrale lagring av passord og nøkler, tilgjengelig for alle våre tjenester, som fritt kan endres etter behov.
• Vi skrev 4 nye backends for Keystone fra bunnen av (brukere, prosjekter, roller, rolletilordninger), som faktisk erstattet databasen, og fungerer nå som et enkelt depot for brukerpassordene våre.
• Vi lærte alle våre Openstack-tjenester å gå til en tredjeparts policytjeneste for deres retningslinjer i stedet for å lese disse retningslinjene lokalt fra hver server (ja, det er slik Openstack fungerer som standard!)

En slik større omarbeiding krever store, komplekse og, viktigst av alt, synkrone endringer i flere systemer skrevet av ulike utviklingsteam. Når det er montert, skal hele systemet fungere.

Hvordan rulle ut slike endringer og ikke skru det opp? Først bestemte vi oss for å se litt inn i fremtiden.

Utrullingsstrategi

• Det vil være mulig å rulle ut produktet i flere trinn, men dette vil øke utviklingstiden med tre ganger. I tillegg ville vi i noen tid ha fullstendig desynkronisering av data i databasene. Du må skrive dine egne synkroniseringsverktøy og leve med flere datalagre i lang tid. Og dette skaper en lang rekke risikoer.
• Alt som kunne utarbeides transparent for brukeren ble gjort på forhånd. Det tok 2 måneder.
• Vi tillot oss selv nedetid i flere timer – kun for brukeroperasjoner for å opprette og endre ressurser.
• For driften av alle allerede opprettede ressurser var nedetid uakseptabelt. Vi planla at under utrulling skulle ressursene fungere uten nedetid og påvirke kundene.
• For å redusere innvirkningen på kundene våre hvis noe går galt, bestemte vi oss for å rulle ut søndag kveld. Færre kunder administrerer virtuelle maskiner om natten.
• Vi advarte alle våre kunder om at tjenesteadministrasjon vil være utilgjengelig i perioden som er valgt for utrulling.

Digresjon: hva er en utrulling?

Hver IT-spesialist kan enkelt svare på hva en utrulling er. Du installerer CI/CD, og ​​alt blir automatisk levert til butikken. 🙂

Selvfølgelig er dette sant. Men vanskeligheten er at med moderne automatiseringsverktøy for kodelevering går forståelsen av selve utrullingen tapt. Hvordan du glemmer det episke ved oppfinnelsen av hjulet når du ser på moderne transport. Alt er så automatisert at utrullingen ofte gjennomføres uten å forstå helheten.

Og hele bildet er slik. Utrullingen består av fire hovedaspekter:

1. Levering av kode, inkludert datamodifikasjon. For eksempel deres migrasjoner.
2. Tilbakerulling av kode er muligheten til å gå tilbake hvis noe går galt. For eksempel gjennom å lage sikkerhetskopier.
3. Tidspunkt for hver utrulling/tilbakerulling. Du må forstå tidspunktet for enhver operasjon av de to første punktene.
4. Berørt funksjonalitet. Det er nødvendig å vurdere både de forventede positive og mulige negative effektene.

Alle disse aspektene må tas i betraktning for en vellykket utrulling. Vanligvis vurderes bare det første, eller i beste fall det andre, punktet, og deretter anses utrullingen som vellykket. Men den tredje og fjerde er enda viktigere. Hvilken bruker vil ha det hvis utrullingen tok 3 timer i stedet for ett minutt? Eller om noe unødvendig blir berørt under utrullingen? Eller vil nedetiden til én tjeneste føre til uforutsigbare konsekvenser?

Lov 1..n, forberedelse til løslatelse

Først tenkte jeg kort å beskrive møtene våre: hele teamet, dets deler, haugevis av diskusjoner på kaffepunkter, argumenter, tester, brainstorming. Da tenkte jeg at det var unødvendig. Fire måneders utvikling består alltid av dette, spesielt når du ikke skriver noe som kan leveres konstant, men én stor funksjon for et live system. Noe som påvirker alle tjenester, men ingenting skal endres for brukere bortsett fra "én knapp i nettgrensesnittet."

Vår forståelse av hvordan vi ruller ut, endret seg fra hvert nytt møte, og ganske betydelig. For eksempel skulle vi oppdatere hele faktureringsdatabasen. Men vi regnet ut tiden og innså at det var umulig å gjøre dette på en rimelig utrullingstid. Det tok oss nesten en ekstra uke å klippe og arkivere faktureringsdatabasen. Og da den forventede utrullingshastigheten fortsatt ikke var tilfredsstillende, bestilte vi ytterligere, kraftigere maskinvare, der hele basen ble dratt. Det er ikke det at vi ikke ønsket å gjøre dette tidligere, men det nåværende behovet for å rulle ut gjorde at vi ikke hadde noen alternativer.

Da en av oss var i tvil om at utrullingen kunne påvirke tilgjengeligheten til våre virtuelle maskiner, brukte vi en uke på å gjennomføre tester, eksperimenter, kodeanalyse og fikk en klar forståelse for at dette ikke ville skje i produksjonen vår, og selv de mest tvilende var enige. med dette.

I mellomtiden gjennomførte gutta fra teknisk støtte sine egne uavhengige eksperimenter for å skrive instruksjoner for klienter om tilkoblingsmetoder, som skulle endres etter utrullingen. De jobbet med bruker-UX, utarbeidet instruksjoner og ga personlige konsultasjoner.

Vi automatiserte alle utrullingsoperasjoner som var mulig. Hver operasjon ble skriptet, selv de enkleste, og tester ble kjørt konstant. De kranglet om den beste måten å slå av tjenesten - utelate demonen eller blokkere tilgang til tjenesten med en brannmur. Vi opprettet en sjekkliste over team for hvert trinn i utrullingen og oppdaterte den kontinuerlig. Vi tegnet og oppdaterte hele tiden et Gantt-diagram for alt utrullingsarbeid, med tidspunkter.

Og så…

Siste akt, før den rulles ut

...det er på tide å rulle ut.

Som de sier, et kunstverk kan ikke fullføres, bare fullføre arbeidet med det. Du må gjøre en innsats av vilje, forstå at du ikke finner alt, men tro at du har gjort alle rimelige antakelser, sørget for alle mulige tilfeller, lukket alle kritiske feil, og alle deltakerne gjorde alt de kunne. Jo mer kode du ruller ut, jo vanskeligere er det å overbevise deg selv om dette (dessuten forstår alle at det er umulig å forutse alt).

Vi bestemte oss for at vi var klare til å rulle ut da vi var overbevist om at vi hadde gjort alt for å dekke alle risikoene for brukerne våre forbundet med uventede påvirkninger og nedetider. Det vil si at alt kan gå galt bortsett fra:

1. Påvirke (hellig for oss, mest dyrebare) brukerinfrastruktur,
2. Funksjonalitet: bruken av tjenesten vår etter utrullingen skal være den samme som før den.

Ruller ut

To kast, 8 forstyrrer ikke

Vi tar nedetid for alle forespørsler fra brukere i 7 timer. På dette tidspunktet har vi både en utrullingsplan og en tilbakeføringsplan.

• Selve utrullingen tar omtrent 3 timer.
• 2 timer for testing.
• 2 timer - forbehold om en eventuell tilbakeføring av endringer.

Det er laget et Gantt-diagram for hver handling, hvor lang tid det tar, hva som skjer sekvensielt, hva som gjøres parallelt.

En del av et utrullings Gantt-diagram, en av de tidlige versjonene (uten parallell utførelse). Det mest verdifulle synkroniseringsverktøyet

Alle deltakere får bestemt sin rolle i utrullingen, hvilke oppgaver de gjør, og hva de er ansvarlige for. Vi prøver å bringe hvert trinn til automatikk, rulle det ut, rulle det tilbake, samle tilbakemeldinger og rulle det ut igjen.

Kronikk av hendelser

Så 15 personer kom på jobb søndag 29. april kl 10. I tillegg til nøkkeldeltakerne kom noen rett og slett for å støtte laget, noe spesielt takk til dem.

Det er også verdt å nevne at nøkkeltesteren vår er på ferie. Det er umulig å rulle ut uten testing, vi utforsker alternativer. En kollega sier ja til å teste oss fra ferien, noe hun mottar enorm takknemlighet for fra hele teamet.

00:00. Stoppe
Vi stopper brukerforespørsler, henger opp et skilt som sier teknisk arbeid. Overvåkingen skriker, men alt er normalt. Vi sjekker at det ikke falt noe annet enn det som skulle falle. Og vi begynner arbeidet med migrasjon.

Alle har en trykt utrullingsplan punkt for punkt, alle vet hvem som gjør hva og i hvilket øyeblikk. Etter hver handling sjekker vi tidspunktene for å sikre at vi ikke overskrider dem, og alt går etter planen. De som ikke deltar i utrullingen direkte på det nåværende stadiet, forbereder seg ved å lansere et online leketøy (Xonotic, type 3 kvakksalvere) for ikke å forstyrre kollegene. 🙂

02:00. Rullet ut
En hyggelig overraskelse - vi avslutter utrullingen en time tidligere, på grunn av optimaliseringen av databasene og migreringsskriptene våre. Det generelle ropet, "rullet ut!" Alle nye funksjoner er i produksjon, men foreløpig er det bare vi som kan se dem i grensesnittet. Alle går inn i testmodus, sorterer dem i grupper og begynner å se hva som skjedde til slutt.

Det ble ikke veldig bra, vi innser dette etter 10 minutter, når ingenting er koblet til eller fungerer i teammedlemmenes prosjekter. Rask synkronisering, vi gir uttrykk for problemene våre, setter prioriteringer, bryter inn i team og går inn i feilsøking.

02:30. To store problemer vs fire øyne
Vi finner to store problemer. Vi innså at kunder ikke ville se noen tilkoblede tjenester, og det ville oppstå problemer med partnerkontoer. Begge skyldes ufullkomne migreringsskript for noen edge-tilfeller. Vi må fikse det nå.

Vi skriver spørringer som registrerer dette, med minst 4 øyne. Vi tester dem under pre-produksjon for å sikre at de fungerer og ikke ødelegger noe. Du kan rulle videre. Samtidig kjører vi vår vanlige integrasjonstesting, som avslører noen flere problemer. De er alle små, men de må også repareres.

03:00. -2 problemer +2 problemer
De to tidligere store problemene er fikset, og nesten alle de mindre også. Alle de som er ledige i reparasjoner jobber aktivt i kontoene sine og rapporterer det de finner. Vi prioriterer, fordeler mellom teamene og legger igjen ikke-kritiske varer til morgenen.

Vi kjører testene igjen, de oppdager to nye store problemer. Ikke alle tjenestepolicyer kom på riktig måte, så noen brukerforespørsler gir ikke godkjenning. Pluss et nytt problem med partnerkontoer. La oss skynde oss å se.

03:20. Nødsynkronisering
Ett nytt problem fikset. For det andre organiserer vi en nødsynkronisering. Vi forstår hva som skjer: den forrige løsningen løste ett problem, men skapte et annet. Vi tar en pause for å finne ut hvordan vi gjør det riktig og uten konsekvenser.

03:30. Seks øyne
Vi forstår hvordan den endelige tilstanden til basen skal være slik at alt går bra for alle partnere. Vi skriver en forespørsel med 6 øyne, ruller den ut i pre-produksjon, tester den, ruller den ut for produksjon.

04:00. Alt fungerer
Alle tester bestått, ingen kritiske problemer er synlige. Fra tid til annen er det noe i teamet som ikke fungerer for noen, vi reagerer raskt. Oftest er alarmen falsk. Men noen ganger kommer ikke noe, eller en egen side fungerer ikke. Vi sitter, fikser, fikser, fikser. Et eget team lanserer den siste store funksjonen – fakturering.

04:30. Ingen vei tilbake
Point of no return nærmer seg, det vil si tidspunktet når vi, hvis vi begynner å rulle tilbake, ikke vil møte nedetiden som er gitt oss. Det er problemer med fakturering, som vet og registrerer alt, men hardnakket nekter å avskrive penger fra klienter. Det er flere feil på individuelle sider, handlinger og statuser. Hovedfunksjonaliteten fungerer, alle tester passerer vellykket. Vi bestemmer at utrullingen har funnet sted, vi vil ikke rulle tilbake.

06:00. Åpent for alle i brukergrensesnittet
Feil fikset. Noen som ikke appellerer til brukerne blir overlatt til senere. Vi åpner grensesnittet for alle. Vi fortsetter å jobbe med fakturering, venter på tilbakemeldinger fra brukere og overvåker resultater.

07:00. Problemer med API-belastning
Det blir klart at vi feilplanla belastningen på API-en vår og testet denne belastningen, noe som ikke kunne identifisere problemet. Som et resultat mislykkes ≈5 % av forespørslene. La oss mobilisere og se etter årsaken.

Fakturering er sta og vil heller ikke fungere. Vi bestemmer oss for å utsette det til senere for å gjennomføre endringene på en rolig måte. Det vil si at alle ressurser samles i den, men avskrivninger fra klienter går ikke gjennom. Selvfølgelig er dette et problem, men sammenlignet med den generelle utrullingen virker det uviktig.

08:00. Fiks API
Vi rullet ut en løsning for lasten, feilene forsvant. Vi begynner å gå hjem.

10:00. Alle
Alt er fikset. Det er stille i overvåkingen og hos kundene går teamet gradvis i dvale. Faktureringen gjenstår, vi gjenoppretter den i morgen.

Så i løpet av dagen var det utrullinger som fikset logger, varsler, returkoder og tilpasninger for noen av våre kunder.

Så utrullingen var vellykket! Det kunne selvfølgelig vært bedre, men vi trakk konklusjoner om hva som ikke var nok for oss for å oppnå perfeksjon.

Totalt

I løpet av 2 måneder med aktiv forberedelse til utrullingen ble 43 oppgaver utført, som varte fra et par timer til flere dager.

Under utrulling:

• nye og endrede demoner - 5 stykker, erstatter 2 monolitter;
• endringer i databasene - alle våre 6 databaser med brukerdata er berørt, nedlastinger er gjort fra tre gamle databaser til en ny;
• fullstendig redesignet frontend;
• mengde nedlastet kode - 33 tusen linjer med ny kode, ≈ 3 tusen linjer med kode i tester, ≈ 5 tusen linjer med migrasjonskode;
• alle data er intakte, ikke en eneste kundes virtuelle maskin ble skadet. 🙂

God praksis for god utrulling

De veiledet oss i denne vanskelige situasjonen. Men generelt sett er det nyttig å følge dem under enhver utrulling. Men jo mer kompleks utrullingen er, desto større rolle spiller de.

1. Det første du må gjøre er å forstå hvordan utrullingen kan eller vil påvirke brukere. Blir det nedetid? I så fall, hva er nedetiden? Hvordan vil dette påvirke brukerne? Hva er mulige best og worst case scenarioer? Og dekker risikoen.
2. Planlegg alt. På hvert trinn må du forstå alle aspekter ved utrulling:
   • kode levering;
   • tilbakeføring av kode;
   • tidspunkt for hver operasjon;
   • påvirket funksjonalitet.
3. Spill gjennom scenariene til alle stadier av utrullingen, så vel som risikoen ved hver av dem, blir åpenbare. Hvis du er i tvil, kan du ta en pause og undersøke det tvilsomme stadiet separat.
4. Hvert trinn kan og bør forbedres hvis det hjelper brukerne våre. For eksempel vil det redusere nedetid eller fjerne noen risikoer.
5. Tilbakeføringstesting er mye viktigere enn testing av kodelevering. Det er nødvendig å kontrollere at systemet som et resultat av tilbakerullingen vil gå tilbake til sin opprinnelige tilstand, og bekrefte dette med tester.
6. Alt som kan automatiseres bør automatiseres. Alt som ikke kan automatiseres bør skrives på forhånd på et jukseark.
7. Registrer suksesskriteriet. Hvilken funksjonalitet skal være tilgjengelig og til hvilken tid? Hvis dette ikke skjer, kjør en tilbakestillingsplan.
8. Og viktigst av alt - mennesker. Alle bør være klar over hva de gjør, hvorfor og hva som avhenger av deres handlinger i utrullingsprosessen.

Og i én setning, med god planlegging og utdyping kan du rulle ut hva du vil uten konsekvenser for salget. Til og med noe som vil påvirke alle tjenestene dine i produksjonen.

Kilde: www.habr.com