Tag ansvar for tjenesten efter udrulning
Definér nyttige tjenestesignaler, beslutninger ved hændelser, gendannelse og vedligeholdelse. Hold driftsansvaret synligt, når kodegenereringen er slut.
Udgivet af TaigaSådan skriver vi
Det lærer du
- Definér et tjenestesignal fra brugerens perspektiv.
- Skeln mellem koordinering af hændelser og teknisk undersøgelse.
- Planlæg vedligeholdelse og gendannelse som vedvarende ansvar.
Definér tjenesten, brugerne er afhængige af
Udrulning gør software tilgængelig. Drift holder den nyttig, når brugere, afhængigheder, trafik og krav ændres. En kodegenerator fjerner ikke dette løbende arbejde.
For en fiktiv kundeeksport har brugerne brug for mere end en side, de kan nå. De skal have de tilladte poster i det krævede format inden for acceptabel tid. Tjenesten skal også forhindre adgang til en anden organisations data.
Udpeg ejeren før release. Registrér, hvem der reagerer uden for normal arbejdstid, hvis det er en del af tjenestens forpligtelse. En leverandør kan udføre noget af arbejdet, men organisationen har stadig brug for en klar vej til beslutninger og kommunikation.
Vælg signaler, der støtter handling
En service-level indicator, eller SLI, måler en defineret egenskab ved tjenestens adfærd. Et service-level objective, eller SLO, sætter et mål for indikatoren over en angivet periode. Vælg målet ud fra brugernes behov og driftskapaciteten.
Googles SRE-vejledning forklarer tilgangen og brugen af et fejlbudget til beslutninger om pålidelighed. Kopiér ikke en anden tjenestes mål uden at kontrollere dets betydning. SLO-vejledning, eksempel på fejlbudgetpolitik.
Definér for eksporten, hvad der tæller som en vellykket, gyldig forespørgsel. Skeln mellem forventede afvisninger og systemfejl. Dokumentér undtagelser, så et måltal ikke kan forbedres blot ved at skjule vanskelige forespørgsler.
| Signal | Hvad det hjælper med at opdage | Vigtig begrænsning |
|---|---|---|
| Offentlig tilgængelighedskontrol | Tjenesten kan ikke nås | Verificerer ikke en indlogget arbejdsgang |
| Færdiggørelse af eksport og latenstid | Gyldige forespørgsler fejler eller tager for lang tid | Kræver en præcis definition af succes |
| Kontroller af afvist adgang | En kritisk grænse får en regression | Dækker de testede betingelser |
| Ressource- og afhængighedssignaler | En sandsynlig intern årsag | Beskriver ikke alene brugerpåvirkningen |
Undgå at logge komplette eksporter for at få bedre indsigt. Indsaml de mindst nødvendige oplysninger til at diagnosticere problemet, og beskyt adgangen til dem.
Forbered hændelseshåndteringen
Beslut, hvem der koordinerer, hvem der undersøger, og hvem der kommunikerer. Rollerne kan kombineres i et lille team, men ansvaret skal forblive klart. Registrér observationer og handlinger.
Googles vejledning om hændelseshåndtering fremhæver koordinering og kommunikation sammen med teknisk afhjælpning. En teknisk korrekt rettelse kan stadig efterlade brugere uden information eller flere ansvarlige, der laver modstridende ændringer. Hændelseshåndtering.
En agent kan opsummere logs eller sammenligne hypoteser inden for godkendte datagrænser. Den bør ikke få ubegrænset produktionsbemyndigelse, fordi hændelsen haster. Brug en defineret eskaleringsvej ved ekstraordinær adgang.
Afprøv gendannelse, og finansier vedligeholdelse
Test gendannelsesproceduren med repræsentative fiktive data. Find det, en rollback af kode ikke kan fortryde, herunder slettede poster og allerede sendte beskeder. Registrér den tid og information, der kræves for at gendanne tjenesten.
Fordel løbende arbejde: opdatering af afhængigheder, adgangsreview, certifikatfornyelse hvor relevant, kapacitetsændringer og dokumentationsrettelser. En tjeneste uden vedligeholdelseskapacitet ophober forpligtelser, når lanceringsbudgettet er brugt.
Vælg efter en hændelse forbedringer, der håndterer de observerede årsager. Knyt dem til implementering og verifikation. Det lukker livscyklussen: Driftsdokumentation ændrer det, teamet specificerer og bygger næste gang.
Lav øvelsen
Skriv et driftsnotat på én side for den fiktive kundeeksport. Medtag ét brugerrettet signal, dets mål, en alarmmodtager, en sikker første reaktion, en gendannelsesgrænse og en vedligeholdelsesansvarlig. Angiv, hvad overvågningen ikke kan opdage.
Download arbejdsark (Markdown)Kontrollér din forståelse
Kilder og videre læsning
- Google SRE: Implementing SLOs ↗
- Google SRE: Incident Response ↗
- Google SRE: Example Error Budget Policy ↗
Relateret læsning fra Taiga
Fjerner du dette valg, slettes al fremgang gemt i denne browser.
Fremgangen bliver i denne browser. Ingen konto, ingen sporing.