Oversættelsen er specielt udarbejdet til studerende på kurset , som starter allerede i dag!
Har du nogensinde lanceret en ny service i produktion? Eller har du måske arbejdet med at supportere sådan en service? Hvis ja, hvad har du så været guided af? Hvad er godt for produktion, og hvad er dårligt? Hvordan træner du nye teammedlemmer til releaser eller support af eksisterende services?
De fleste virksomheder, når det kommer til praksis for industriel drift, ender med tilgange, der minder om 'Det Vilde Vesten'. Hver team finder selv, gennem trial and error, de værktøjer og bedste praksisser, de ønsker at anvende. Men det påvirker ofte ikke kun projekternes succes, men også ingeniørerne.
Trial and error-metoden skaber et miljø, hvor skyldfordeling og ansvarsskyld er udbredt. Med denne adfærd bliver det vanskeligere at lære af fejl og undgå at gentage dem.
Succesfulde organisationer:
- er bevidste om behovet for retningslinjer for produktion,
- undersøger de bedste praksisser,
- begynder at diskutere spørgsmål om beredskab til produktion under udviklingen af nye systemer eller komponenter,
- sikrer overholdelse af reglerne for beredskab til produktion.
Forberedelse til produktion inkluderer en 'review'-proces. Reviews kan være i form af en tjekliste eller et sæt spørgsmål. Reviews kan udføres manuelt, automatisk eller ved begge metoder. I stedet for statiske kravlister kan man skabe skabeloner til tjeklister, som tilpasses specifikke behov. På den måde kan ingeniørerne få en metode til at arve viden og tilstrækkelig fleksibilitet, når det er nødvendigt.
Hvornår skal man tjekke service for beredskab til produktion?
Det er nyttigt at tjekke beredskab til produktion ikke kun lige før en release, men også ved overdragelse til et andet driftsteam eller en ny medarbejder.
Gør tjekket, når:
- Du lancerer en ny service i produktion.
- Du overdrager driften af en produktionsservice til et andet team, som f.eks. SRE.
- Du overdrager driften af en produktionsservice til nye medarbejdere.
- Du organiserer teknisk support.
Tjekliste for beredskab til produktion
For ikke så længe siden, som et eksempel, jeg tjekliste for beredskab til produktion. Selvom denne liste blev til under arbejdet med kunder hos Google Cloud, vil den også være nyttig og anvendelig uden for Google Cloud.
Design og udvikling
- Udvikl en reproducerbar byggeproces, der ikke kræver adgang til eksterne tjenester og ikke er afhængig af fejl fra eksterne systemer.
- Definer og fastsæt SLO for dine tjenester i design- og udviklingsfasen.
- Dokumentér forventningerne til tilgængeligheden af de eksterne tjenester, som du er afhængig af.
- Undgå enkeltpunktsfejl ved at fjerne afhængigheder fra en global ressource. Replikér ressourcen eller brug en backup-løsning, når ressourcen ikke er tilgængelig (f.eks. en fastkodet værdi).
Konfigurationsstyring
- Statisk, lille og ikke-fortrolig konfiguration kan videregives via kommandolinjeparametre. Brug konfigurationslagertjenester til alt andet.
- Dynamisk konfiguration skal have backups i tilfælde af, at konfigurationstjenesten ikke er tilgængelig.
- Udviklingsmiljøets konfiguration må ikke være forbundet med produktionskonfigurationen. Ellers kan det føre til, at udviklingsmiljøet får adgang til produktionsservices, hvilket kan skabe privatlivsproblemer og datalækager.
- Dokumentér hvad der kan konfigureres dynamisk, og beskriv backup-adfærden, hvis konfigurationsleveringssystemet ikke er tilgængeligt.
Udgivelseshåndtering
- Dokumentér detaljeret udgivelsesprocessen. Beskriv hvordan udgivelser påvirker SLO (f.eks. midlertidig stigning i forsinkelse på grund af cachefejl).
- Dokumentér kanariefugleudgivelser.
- Udvikl en plan for analyse af kanariefugleudgivelser, og hvis muligt, mekanismer til automatisk tilbagerulning.
- Sørg for, at tilbagerulninger kan bruge de samme processer som implementeringen.
Overvågningsduelighed (Observability)
- Sørg for, at et sæt metrics, der er nødvendige for SLO, indsamles.
- Sørg for, at der kan skelnes mellem klient- og serverdata. Det er vigtigt for fejlfinding.
- Indstil alarmer for at reducere arbejdsbyrden. For eksempel, fjern alarmer for rutinemæssige operationer.
- Hvis du bruger Stackdriver, så aktiver GCP-platformmetrikker på dine dashboards. Indstil alarmer for GCP-afhængigheder.
- Sørg altid for at videresende indgående spor. Selv hvis du ikke deltager i sporing, kan det hjælpe lavere niveau tjenester med at fejlfinde problemer i produktionen.
Beskyttelse og sikkerhed
- Sørg for, at alle eksterne forbindelser er krypterede.
- Sørg for, at dine produktionsprojekter har den korrekte IAM-konfiguration.
- Brug netværk til at isolere grupper af virtuelle maskiner.
- Brug VPN til sikker forbindelse til eksterne netværk.
- Dokumentér og overvåg brugernes adgang til data. Sørg for, at al brugeradgang til data bliver revideret og logget.
- Sørg for, at slutpunkterne til fejlfinding er begrænset af ACL.
- Sanitér brugerinput. Indstil begrænsninger for nyttelaststørrelse for brugerinput.
- Sørg for, at din tjeneste kan selektivt blokere indgående trafik for specifikke brugere. Dette gør det muligt at blokkere overtrædelser uden at påvirke andre brugere.
- Undgå eksterne slutpunkter, der indleder et stort antal interne operationer.
Kapacitetsplanlægning
- Dokumentér, hvordan din tjeneste skalerer. For eksempel: antallet af brugere, størrelsen af den indgående nyttelast, antallet af indgående meddelelser.
- Dokumentér ressourcekravene til din tjeneste. For eksempel: antal tildelte virtuelle maskiner, antal Spanner-forekomster, specialiseret hardware som GPU eller TPU.
- Dokumentér ressourcebegrænsninger: ressource type, region osv.
- Dokumentér kvotabegrænsninger for oprettelse af nye ressourcer. For eksempel, begrænsning af antallet af GCE API-forespørgsler, hvis du bruger API'et til at oprette nye instanser.
- Overvej at udføre belastningstest for at analysere ydeevneforringelse.
Det var det. Vi ses i klassen!
Kilde: habr.com
