SRE (Site Reliability Engineering) er en tilnærming for å sikre tilgjengeligheten av nettprosjekter. Det regnes som et rammeverk for DevOps og snakker om hvordan man kan oppnå suksess med å bruke DevOps-praksis. Oversettelse i denne artikkelen bøker fra Google. Jeg utarbeidet denne oversettelsen selv og stolte på min egen erfaring med å forstå overvåkingsprosesser. I telegramkanalen и Jeg publiserte også en lenke til oversettelsen av kapittel 4 i samme bok om servicenivåmål.
Oversettelse av katt. Liker å lese!
Googles SRE-team har grunnleggende prinsipper og beste praksis for å lage vellykkede overvåkings- og varslingssystemer. Dette kapittelet gir veiledning om hvilke problemer en nettsidebesøkende kan støte på, og hvordan man kan løse problemer som gjør nettsider vanskelige å vise.
definere
Det er ikke et enkelt vokabular som brukes til å diskutere temaer knyttet til overvåking. Selv på Google er ikke begrepene nedenfor ofte brukt, men vi vil liste opp de vanligste tolkningene.
overvåking
Innsamling, behandling, aggregering og visning av kvantitative data i sanntid om systemet: antall forespørsler og typer forespørsler, antall feil og typer feil, forespørselsbehandlingstid og serveroppetid.
White-box overvåking
Overvåking basert på beregninger som vises av interne systemkomponenter, inkludert logger, Java Virtual Machine-profileringsberegninger eller HTTP-behandlerberegninger som genererer intern statistikk.
Black-box overvåking
Testing av applikasjonsatferd fra brukerens synspunkt.
Dashbord
Et grensesnitt (vanligvis web) som gir en oversikt over sentrale helseindikatorer for tjenester. Dashbordet kan ha filtre, mulighet til å velge indikatorene som vises osv. Grensesnittet er laget for å identifisere indikatorene som er viktigst for brukerne. Dashbordet kan også vise informasjon for teknisk støttepersonell: en kø med forespørsler, en liste over høyprioriterte feil og en tildelt ingeniør for et gitt ansvarsområde.
Varsel (varsel)
Varsler ment å mottas av en person via e-post eller andre midler, som kan utløses av feil eller en økning i forespørselskøen. Varsler er klassifisert som: billetter, e-postvarsler og direktemeldinger.
Opprinnelig årsak
En programvaredefekt eller menneskelig feil som, når den er rettet, ikke skal oppstå igjen. Problemet kan ha flere hovedårsaker: utilstrekkelig prosessautomatisering, programvaredefekt, utilstrekkelig utdyping av applikasjonslogikken. Hver av disse faktorene kan være grunnårsaken, og hver av dem må elimineres.
Node og maskin (node og maskin)
Utskiftbare termer for å referere til en enkelt forekomst av en applikasjon som kjører på en fysisk server, virtuell maskin eller beholder. En maskin kan være vert for flere tjenester. Tjenester kan være:
- koblet til hverandre: for eksempel en hurtigbufferserver og en webserver;
- urelaterte tjenester på en enkelt maskinvare: for eksempel et kodelager og en veiviser for et konfigurasjonssystem, som f.eks. eller .
Skyv
Enhver endring i programvarekonfigurasjonen.
Hvorfor er overvåking nødvendig?
Det er flere grunner til at applikasjoner må overvåkes:
Analyse av langsiktige trender
Hvor stor er databasen og hvor raskt vokser den? Hvordan endres det daglige antallet brukere?
Sammenligning av ytelse
Er forespørsler raskere på Acme Bucket of Bytes 2.72 sammenlignet med Ajax DB 3.14? Hvor mye bedre bufres forespørsler etter at en ekstra node vises? Kjører siden tregere sammenlignet med forrige uke?
Varsler (varsler)
Noe er ødelagt og noen må fikse det. Eller noe går i stykker snart og noen må sjekke det snart.
Opprette dashbord
Dashboards skal svare på grunnleggende spørsmål og inkludere noe fra — forsinkelser (latens), trafikk (trafikk), feil (feil) og laststørrelse (metning).
Gjennomføre retrospektiv analyse (feilsøking)
Forsinkelsen i forespørselsbehandlingen har økt, men hva mer skjedde omtrent samtidig?
Overvåkingssystemer er nyttige som en datakilde for business intelligence-systemer og for å lette analysen av sikkerhetshendelser. Fordi denne boken fokuserer på ingeniørområder der SRE har ekspertise, vil vi ikke diskutere overvåkingsteknikker her.
Overvåking og varsler lar systemet fortelle deg når det har gått i stykker eller er i ferd med å bryte sammen. Når et system ikke kan reparere seg selv automatisk, vil vi at et menneske skal analysere varselet, finne ut om problemet fortsatt er aktivt, løse det og finne årsaken. Hvis du ikke reviderer systemkomponenter, vil du aldri motta et varsel bare fordi "noe virker litt rart."
Å belaste en person med varsler er en ganske dyr bruk av en ansatts tid. Hvis den ansatte er i arbeid, avbryter varslingen arbeidsprosessen. Hvis den ansatte er hjemme, avbryter varslingen personlig tid og eventuelt søvn. Når varsler forekommer for ofte, skumleser ansatte gjennom dem, utsetter dem eller ignorerer innkommende varsler. Fra tid til annen ignorerer de det virkelige varselet, som er maskert av støyhendelser. Tjenesteavbrudd kan vare i lange perioder ettersom støyhendelser forhindrer at problemet raskt blir diagnostisert og rettet. Effektive varslingssystemer har et godt signal/støyforhold.
Sette rimelige forventninger til overvåkingssystemet
Å sette opp overvåking for en kompleks applikasjon er en kompleks ingeniøroppgave i seg selv. Selv med en betydelig infrastruktur av innsamlings-, visnings- og varslingsverktøy, inkluderer et Google SRE-team på 10–12 medlemmer vanligvis en eller to personer hvis primære formål er å bygge og vedlikeholde overvåkingssystemer. Dette antallet har gått ned over tid ettersom vi konsoliderer og sentraliserer overvåkingsinfrastrukturen, men hvert SRE-team har vanligvis minst én person dedikert utelukkende til overvåking. Vi må si at mens overvåkingssystemdashbord er ganske interessant å se på, unngår SRE-team nøye situasjoner som krever at noen ser på en skjerm for å overvåke problemer.
Totalt sett har Google gått over til enkle og raske overvåkingssystemer med optimale etterfølgende analyseverktøy. Vi unngår «magiske» systemer som prøver å forutsi terskler eller automatisk oppdage årsaken. Sensorer som oppdager utilsiktet innhold i sluttbrukerforespørsler er det eneste moteksemplet; Så lenge disse sensorene forblir enkle, kan de raskt oppdage årsakene til alvorlige anomalier. Andre formater for bruk av overvåkingsdata, som kapasitetsplanlegging eller trafikkprognoser, er mer komplekse. Observasjon over svært lang tid (måneder eller år) med lav samplingshastighet (timer eller dager) vil avdekke en langsiktig trend.
Google SRE-teamet har hatt blandet suksess med komplekse avhengighetshierarkier. Vi bruker sjelden regler som "hvis jeg finner ut at databasen er treg, får jeg et varsel om at databasen er treg, ellers får jeg et varsel om at nettstedet er tregt." Avhengighetsbaserte regler refererer vanligvis til uforanderlige deler av systemet vårt, for eksempel systemet for filtrering av brukertrafikk til datasenteret. For eksempel, "hvis trafikkfiltrering til datasenteret er konfigurert, ikke varsle meg om forsinkelser i behandlingen av brukerforespørsler" er en generell regel for varsler fra datasenteret. Få team hos Google støtter komplekse avhengighetshierarkier fordi infrastrukturen vår har en konstant hastighet på kontinuerlig refaktorering.
Noen av ideene som er beskrevet i dette kapittelet er fortsatt relevante: det er alltid en mulighet til å bevege seg raskere fra symptom til rotårsak, spesielt i stadig skiftende systemer. Selv om dette kapittelet skisserer noen mål for overvåkingssystemer og hvordan man oppnår disse målene, er det derfor viktig at overvåkingssystemene er enkle og forståelige for alle i teamet.
På samme måte, for å holde støynivåene lave og signalnivåene høye, må tilnærminger til å overvåke varslede aktiva være svært enkle og pålitelige. Regler som genererer advarsler for folk skal være enkle å forstå og presentere et klart problem.
Symptomer kontra årsaker
Overvåkingssystemet ditt bør svare på to spørsmål: "hva gikk i stykker" og "hvorfor det gikk i stykker."
"Hva brøt" snakker om symptomet, og "hvorfor det brøt" snakker om årsaken. Tabellen nedenfor viser eksempler på slike koblinger.
symptom
årsaken
Får HTTP-feil 500 eller 404
Databaseservere avviser tilkoblinger
Trege serversvar
Høy CPU-utnyttelse eller skadet Ethernet-kabel
Brukere i Antarktis mottar ikke katte-GIF-er
CDN-en din hater forskere og katter, så noen IP-adresser endte opp med å bli svartelistet
Privat innhold har blitt tilgjengelig overalt
Utrullingen av en ny programvareversjon fikk brannmuren til å glemme alle tilgangskontrollister og slapp alle inn
«Hva» og «hvorfor» er noen av de viktigste byggesteinene for å skape et godt overvåkingssystem med maksimalt signal og minimalt med støy.
Black-box vs White-box
Vi kombinerer omfattende White-box-overvåking med beskjeden Black-box-overvåking for kritiske beregninger. Den enkleste måten å sammenligne Black-box med White-box på er at Black-box er symptomfokusert og er reaktiv i stedet for proaktiv overvåking: "systemet fungerer ikke som det skal akkurat nå." White-box avhenger av de interne verifiseringsmulighetene til systemene: hendelseslogger eller webservere. Dermed lar White-box deg oppdage forestående problemer, feil som ser ut til å være en reoverføring av en forespørsel, etc.
Merk at i et flerlagssystem er et symptom i en ingeniørs ansvarsområde et symptom i en annen ingeniørs ansvarsområde. For eksempel har databaseytelsen gått ned. Langsomme databaselesinger er et symptom på databasens SRE som oppdager dem. Men for en front-end SRE som observerer et tregt nettsted, er årsaken til den samme trege databaselesingen en treg database. Derfor er white-box-overvåking noen ganger symptomfokusert og noen ganger årsaksfokusert, avhengig av hvor omfattende den er.
Ved innsamling av telemetri for feilsøking kreves White-box-overvåking. Hvis webservere er trege til å svare på databaseforespørsler, må du vite hvor raskt webserveren kommuniserer med databasen og hvor raskt den svarer. Ellers vil du ikke kunne skille mellom en treg databaseserver og et nettverksproblem mellom webserveren og databasen.
Black-box-overvåking har en viktig fordel når du sender varsler: du utløser varselet til mottakeren når problemet allerede har resultert i reelle symptomer. På den annen side er overvåking ubrukelig for et Black-box-problem som ennå ikke har oppstått, men som er nært forestående.
Fire gylne signaler
De fire gylne overvåkingssignalene er ventetid, trafikk, feil og metning. Hvis du bare kan måle fire brukersystemberegninger, fokuser på disse fire.
Forsinkelse
Tiden det tar å behandle forespørselen. Det er viktig å skille mellom ventetiden for vellykkede og mislykkede forespørsler. For eksempel kan en HTTP 500-feil forårsaket av tap av tilkobling til en database eller annen backend diagnostiseres veldig raskt, men en HTTP 500-feil kan indikere en mislykket forespørsel. Å bestemme virkningen av en 500-feil på den totale ventetiden kan føre til feilaktige konklusjoner. På den annen side er en langsom feil til og med en rask feil! Derfor er det viktig å overvåke feilforsinkelse i stedet for bare å filtrere ut feil.
trafikk
Antall forespørsler til systemet ditt måles i systemberegninger på høyt nivå. For en nettjeneste representerer denne målingen vanligvis antall HTTP-forespørsler per sekund, delt på arten av forespørslene (for eksempel statisk eller dynamisk innhold). For et lydstreamingsystem kan denne målingen fokusere på nettverkets I/O-hastighet eller antall samtidige økter. For et nøkkelverdilagringssystem kan denne målingen være transaksjoner eller søkeresultater per sekund.
Feil
Dette er frekvensen av mislykkede forespørsler som er eksplisitte (f.eks. HTTP 500), implisitte (f.eks. HTTP 200, men kombinert med ugyldig innhold) eller policy (f.eks. "Hvis du fanget et svar på ett sekund, er et hvilket som helst sekund en feil"). Hvis HTTP-svarkoder ikke er tilstrekkelige til å uttrykke alle feiltilstander, kan det være nødvendig med sekundære (interne) protokoller for å oppdage delvis feil. Overvåking av alle slike mislykkede forespørsler er kanskje ikke informativ, mens systemtester fra ende til ende vil hjelpe med å oppdage at du behandler feil innhold.
Metning
Beregningen viser hvor intensivt tjenesten din brukes. Dette er et systemovervåkingsmål som identifiserer ressursene som er mest begrenset (for eksempel på et minnebegrenset system, viser minne, på et I/O-begrenset system, viser antall I/O). Merk at mange systemer forringer ytelsen før de når 100 % utnyttelse, så det er viktig å ha et utnyttelsesmål.
I komplekse systemer kan metning kompletteres med lastmålinger på høyere nivå: kan tjenesten din håndtere dobbel trafikk på riktig måte, håndtere bare 10 % mer trafikk, eller håndtere enda mindre trafikk enn den gjør i dag? For enkle tjenester som ikke har parametere som endrer kompleksiteten til forespørselen (for eksempel "Gi meg ingenting" eller "Jeg trenger et unikt enkelt monotont heltall"), som sjelden endrer konfigurasjon, kan en statisk lasttestverdi være tilstrekkelig. Imidlertid, som diskutert i forrige avsnitt, må de fleste tjenester bruke indirekte signaler som CPU-utnyttelse eller nettverksbåndbredde, som har en kjent øvre grense. Økende latens er ofte en ledende indikator på metning. Å måle 99. persentilens responstid i et lite vindu (f.eks. ett minutt) kan gi et veldig tidlig signal om metning.
Til slutt er metning også assosiert med spådommer om forestående metning, for eksempel: "Det ser ut til at databasen din vil fylle opp harddisken din om 4 timer."
Hvis du måler alle fire gyldne signaler og når det er et problem med en av metrikkene (eller, i tilfelle metning, et nesten problem), varsler du en person, vil tjenesten din være mer eller mindre dekket av overvåking.
Bekymringer om "halen" (eller instrumentering og ytelse)
Når du oppretter et overvåkingssystem fra bunnen av, er det en fristelse å utvikle et system basert på gjennomsnittsverdier: gjennomsnittlig latens, gjennomsnittlig CPU-utnyttelse av noder eller gjennomsnittlig databasefullhet. Faren ved de to siste eksemplene er åpenbar: prosessorer og databaser avhendes på en svært uforutsigbar måte. Det samme gjelder forsinkelse. Hvis du kjører en nettjeneste med en gjennomsnittlig ventetid på 100 ms med 1000 forespørsler per sekund, kan 1 % av forespørslene ta 5 sekunder. Hvis brukere er avhengige av flere slike nettjenester, kan 99. persentilen til én backend lett bli median responstid for frontend.
Den enkleste måten å skille mellom det langsomme gjennomsnittet og den veldig langsomme halen av forespørsler er å samle inn målinger av forespørsler uttrykt i statistikk (et godt verktøy å vise er histogrammer) i stedet for faktiske ventetider: hvor mange forespørsler tjenesten leverte som tok mellom 0 ms og 10 ms, mellom 10 ms og 30 ms, mellom 30 ms og 100 ms, mellom 100 ms og 300 ms osv. Å utvide histogramgrensene tilnærmet eksponentielt (med en omtrentlig faktor på 3) er ofte en enkel måte å visualisere fordelingen på av forespørsler.
Velge riktig detaljnivå for målinger
Ulike elementer i systemet må måles på ulike detaljnivåer. For eksempel:
- Overvåking av CPU-bruk over en tidsperiode vil ikke vise langsiktige topper som fører til høye latenstider.
- På den annen side, for en nettjeneste som ikke er målrettet mot mer enn 9 timers nedetid per år (99,9 % årlig oppetid), vil det sannsynligvis være unødvendig hyppig å se etter et HTTP 200-svar mer enn én eller to ganger i minuttet.
- På samme måte er det sannsynligvis ikke nødvendig å sjekke harddiskplass for 99,9 % tilgjengelighet mer enn én gang hvert 1-2 minutt.
Vær forsiktig med hvordan du strukturerer granulariteten til målingene dine. Å samle CPU-belastning én gang per sekund kan gi interessante data, men slike hyppige målinger kan være svært kostbare å samle inn, lagre og analysere. Hvis overvåkingsmålet ditt krever høy granularitet og ikke krever høy respons, kan du redusere disse kostnadene ved å sette opp metrikksamling på serveren og deretter sette opp et eksternt system for å samle inn og aggregere disse beregningene. Kan du:
- Mål CPU-belastningen hvert sekund.
- Reduser detaljene til 5 %.
- Samle beregninger hvert minutt.
Denne strategien lar deg samle inn data med høy granularitet uten å pådra deg høye analyser og lagringskostnader.
Så enkelt som mulig, men ikke enklere
Overlappingen av ulike krav oppå hverandre kan resultere i et svært komplekst overvåkingssystem. For eksempel kan systemet ditt ha følgende kompliserende elementer:
- Varsler i henhold til forskjellige terskler for forespørselsbehandlingsforsinkelse, i forskjellige persentiler, for alle typer forskjellige indikatorer.
- Skrive tilleggskode for å oppdage og identifisere mulige årsaker.
- Lag relaterte instrumentbord for hver av de mulige årsakene til problemer.
Kildene til potensielle komplikasjoner tar aldri slutt. Som alle programvaresystemer kan overvåking bli så kompleks at den blir skjør og vanskelig å endre og vedlikeholde.
Design derfor overvåkingssystemet ditt for å forenkle det så mye som mulig. Når du velger hva du skal spore, må du huske på følgende:
- Reglene som oftest fanger opp reelle hendelser bør være så enkle, forutsigbare og pålitelige som mulig.
- Konfigurasjon for datainnsamling, aggregering og varsling som utføres sjelden (for eksempel mindre enn kvartalsvis for enkelte SRE-team) bør fjernes.
- Beregninger som samles inn, men som ikke vises i noen forhåndsvisningsdashboard eller brukes av et varsel, er kandidater for sletting.
Hos Google fungerer grunnleggende metrikkinnsamling og aggregering, kombinert med varsler og dashbord, godt som et relativt frittstående system (Googles overvåkingssystem er faktisk delt opp i flere undersystemer, men folk er vanligvis klar over alle aspekter ved disse undersystemene). Det kan være fristende å kombinere overvåking med andre teknikker for å undersøke komplekse systemer: detaljert systemprofilering, prosessfeilsøking, sporing av detaljer om unntak eller feil, lasttesting, logginnsamling og analyse, eller trafikkinspeksjon. Mens de fleste av disse tingene har fellestrekk med grunnleggende overvåking, vil blanding av dem resultere i for mange resultater og skape et komplekst og skjørt system. Som med mange andre aspekter ved programvareutvikling, er det å støtte forskjellige systemer med klare, enkle, løst koblede integrasjonspunkter den beste strategien (for eksempel å bruke et web-API for å hente aggregerte data i et format som kan forbli konsistent over lang tid ).
Knytte prinsippene sammen
Prinsippene diskutert i dette kapittelet kan kombineres til en overvåkings- og varslingsfilosofi som støttes og følges av Googles SRE-team. Å følge denne overvåkingsfilosofien er ønskelig, er et godt utgangspunkt for å lage eller revidere varslingsmetodikken din, og kan hjelpe deg med å stille de riktige spørsmålene til driftsfunksjonen din, uavhengig av størrelsen på organisasjonen din eller kompleksiteten til tjenesten eller systemet.
Når du oppretter overvåkings- og varslingsregler, kan det å stille følgende spørsmål hjelpe deg med å unngå falske positiver og unødvendige varsler:
- Oppdager denne regelen en ellers uoppdagbar tilstand i systemet som haster, oppfordrer til handling og uunngåelig påvirker brukeren?
- Kan jeg ignorere denne advarselen og vite at den er godartet? Når og hvorfor kan jeg ignorere denne advarselen, og hvordan kan jeg unngå dette scenariet?
- Betyr dette varselet at brukere blir negativt påvirket? Er det situasjoner der brukere ikke påvirkes negativt, for eksempel gjennom trafikkfiltrering eller ved bruk av testsystemer som varsler bør filtreres for?
- Kan jeg iverksette tiltak som svar på dette varselet? Er disse tiltakene haster eller kan de vente til morgenen? Kan en handling automatiseres trygt? Vil denne handlingen være en langsiktig løsning eller en kortsiktig løsning?
- Noen mennesker får flere varsler for dette problemet, så er det en måte å redusere antall varsler på?
Disse spørsmålene gjenspeiler den grunnleggende filosofien om varslings- og varslingssystemer:
- Hver gang det kommer inn et varsel, må jeg reagere umiddelbart. Jeg kan reagere akutt flere ganger om dagen før jeg blir sliten.
- Hvert varsel må være relevant.
- Hvert svar på et varsel må kreve menneskelig inngripen. Hvis meldingen kan behandles automatisk, skal den ikke komme frem.
- Varsler skal handle om et nytt problem eller hendelse som ikke eksisterte før.
Denne tilnærmingen utvisker visse distinksjoner: Hvis varselet tilfredsstiller de fire foregående betingelsene, spiller det ingen rolle om varselet sendes fra et White-box- eller Black-Box-overvåkingssystem. Denne tilnærmingen forsterker også visse forskjeller: det er bedre å bruke mye mer innsats på å identifisere symptomer enn på årsaker; når det kommer til årsaker, trenger du bare å bekymre deg for de uunngåelige årsakene.
Langsiktig overvåking
I dagens produktivitetsmiljøer overvåker overvåkingssystemer et produksjonssystem i stadig utvikling med skiftende programvarearkitektur, arbeidsbelastningskarakteristikker og ytelsesmål. Varsler som for øyeblikket er vanskelige å automatisere kan bli vanlige, kanskje til og med verdt å ta tak i. På dette tidspunktet må noen finne og eliminere de grunnleggende årsakene til problemet; hvis slik løsning ikke er mulig, krever svaret på varselet full automatisering.
Det er viktig at overvåkingsbeslutninger tas med langsiktige mål i tankene. Hvert varsel som kjører i dag distraherer en person fra å forbedre systemet i morgen, så det er ofte en reduksjon i tilgjengeligheten eller ytelsen til et produktivt system i den tiden som trengs for å forbedre overvåkingssystemet på lang sikt. La oss se på to eksempler for å illustrere dette fenomenet.
Bigtable SRE: A Tale of Over-Alert
Googles interne infrastruktur er vanligvis klargjort og målt mot et tjenestenivå (SLO). For mange år siden var Bigtables tjeneste SLO basert på gjennomsnittlig ytelse for en syntetisk transaksjon som simulerte en live klient. På grunn av problemer i Bigtable og lavere nivåer av lagringsstabelen, ble gjennomsnittlig ytelse drevet av en "stor" hale: de verste 5 % av spørringene var ofte betydelig tregere enn resten.
E-postvarsler ble sendt etter hvert som SLO-terskelen nærmet seg, og messenger-varsler ble sendt når SLO ble overskredet. Begge typer varsler ble sendt ganske ofte, og forbrukte uakseptable mengder ingeniørtid: teamet brukte en betydelig mengde tid på å sortere gjennom varslene for å finne de få som faktisk var relevante. Vi gikk ofte glipp av et problem som faktisk påvirket brukere fordi bare noen av varslene var for det spesifikke problemet. Mange av varslene hastet ikke på grunn av forståelige problemer i infrastrukturen og ble behandlet på standard måte, eller ble ikke behandlet i det hele tatt.
For å avhjelpe situasjonen tok teamet en tredelt tilnærming: Mens vi jobbet hardt for å forbedre Bigtables ytelse, satte vi midlertidig SLO-målet vårt til å være den 75. persentilen for ventetid for spørresvar. Vi slo også av e-postvarsler fordi det var så mange av dem at det var umulig å bruke tid på å diagnostisere dem.
Denne strategien tillot oss pusterom til å begynne å fikse langsiktige problemer i Bigtable og de nedre lagene av lagringsstabelen, i stedet for å konstant fikse taktiske problemer. Ingeniører kunne faktisk få arbeidet gjort uten å bli bombardert med varsler hele tiden. Til syvende og sist, midlertidig utsettelse av varslingsbehandling tillot oss å forbedre kvaliteten på tjenesten vår.
Gmail: Forutsigbare, algoritmiske menneskelige svar
Ved oppstarten var Gmail bygget på et modifisert Workqueue-prosessstyringssystem som ble utviklet for å batchbehandle deler av en søkeindeks. Workqueue ble tilpasset langvarige prosesser og ble deretter brukt på Gmail, men noen feil i den ugjennomsiktige planleggerkoden viste seg å være svært vanskelig å fikse.
På den tiden var Gmail-overvåking strukturert slik at varsler ble utløst når individuelle oppgaver ble kansellert med Workqueue. Denne tilnærmingen var ikke ideell, for selv på den tiden utførte Gmail mange tusen oppgaver, som hver ble levert til en brøkdel av en prosent av brukerne våre. Vi var veldig opptatt av å gi Gmail-brukere en god brukeropplevelse, men å håndtere så mange varsler var utenfor rekkevidde.
For å løse dette problemet opprettet Gmail SRE et verktøy for å hjelpe til med å feilsøke planleggeren best mulig for å minimere innvirkningen på brukerne. Teamet hadde noen diskusjoner om hvorvidt de bare skulle automatisere hele syklusen fra problemoppdagelse til utbedring til en langsiktig løsning ble funnet, men noen var bekymret for at en slik løsning ville forsinke å faktisk fikse problemet.
Denne spenningen var vanlig i teamet og reflekterte ofte mangel på tillit til selvdisiplin: mens noen teammedlemmer ønsker å gi tid til den riktige løsningen, er andre bekymret for at den endelige løsningen vil bli glemt og den midlertidige løsningen vil ta evigheter. Dette problemet fortjener oppmerksomhet fordi det er for enkelt å midlertidig fikse problemer i stedet for å gjøre situasjonen permanent. Ledere og teknisk personell spiller en nøkkelrolle i å implementere langsiktige rettelser, støtte og prioritere potensielt langsiktige rettinger selv etter at den første "smerten" har avtatt.
Regelmessige, gjentatte varsler og algoritmiske svar skal være et rødt flagg. Teamets motvilje mot å automatisere disse varslene betyr at teamet mangler tillit til at de kan stole på algoritmene. Dette er et alvorlig problem som må løses.
Langsiktig
Et vanlig tema kobler sammen Bigtable- og Gmail-eksemplene: konkurransen mellom kortsiktig og langsiktig tilgjengelighet. Ofte kan en sterk innsats hjelpe et skjørt system med å oppnå høy tilgjengelighet, men denne veien er vanligvis kortvarig, full av teamutbrenthet og avhengighet av et lite antall medlemmer av det samme heroiske teamet.
Kontrollert, kortsiktig reduksjon i tilgjengelighet er ofte smertefullt, men strategisk viktig for den langsiktige stabiliteten i systemet. Det er viktig å ikke se på hver varsling isolert, men å vurdere om det totale nivået av varslingsvolum fører til et sunt, godt tilgjengelig system med et levedyktig team og en gunstig prognose. Vi analyserer varslingsfrekvensstatistikk (vanligvis uttrykt som hendelser per skift, der en hendelse kan bestå av flere relaterte hendelser) i kvartalsrapporter til ledelsen, slik at beslutningstakere kan ha en løpende oversikt over varslingssystembelastningen og teamets generelle helse.
Konklusjon
Veien til sunn overvåking og varsling er enkel og tydelig. Den fokuserer på symptomene på problemet som utløser varsler, og overvåking av årsaken fungerer som en hjelp til å feilsøke problemer. Overvåking av symptomer er lettere jo høyere du er i stabelen du kontrollerer, selv om overvåking av belastning og ytelse av databasen bør gjøres direkte på selve databasen. E-postvarsler har svært begrenset nytte og har en tendens til å lett bli støy; i stedet bør du bruke et dashbord som overvåker alle aktuelle problemer som utløser e-postvarsler. Dashbordet kan også sammenkobles med en hendelseslogg for å analysere historiske korrelasjoner.
På lang sikt er det nødvendig å oppnå en vellykket rotasjon av varsler om symptomer og overhengende reelle problemer, tilpasse mål for å sikre at overvåking støtter rask diagnose.
Takk for at du leste oversettelsen til slutten. Abonner på min telegramkanal om overvåking и .
Kilde: www.habr.com