SRE (Site Reliability Engineering) er en tilgang til at sikre tilgængeligheden af webprojekter. Det betragtes som en ramme for DevOps og taler om, hvordan man opnår succes med at anvende DevOps-praksis. Oversættelse i denne artikel bøger fra Google. Jeg udarbejdede selv denne oversættelse og stolede på min egen erfaring med at forstå overvågningsprocesser. I telegramkanalen и Jeg udgav også et link til oversættelsen af kapitel 4 i samme bog om serviceniveaumål.
Oversættelse af kat. God fornøjelse med at læse!
Googles SRE-teams har grundlæggende principper og bedste praksis for at skabe succesfulde overvågnings- og notifikationssystemer. Dette kapitel giver vejledning i, hvilke problemer en webside besøgende kan støde på, og hvordan man løser problemer, der gør websider svære at vise.
definere
Der er ikke et enkelt ordforråd, der bruges til at diskutere emner relateret til overvågning. Selv på Google er nedenstående udtryk ikke almindeligt brugt, men vi vil liste de mest almindelige fortolkninger.
overvågning
Indsamling, bearbejdning, aggregering og visning af kvantitative data i realtid om systemet: antal anmodninger og typer af anmodninger, antal fejl og typer af fejl, anmodningsbehandlingstid og serveroppetid.
White-box overvågning
Overvågning baseret på metrics, der vises af interne systemkomponenter, herunder logfiler, Java Virtual Machine-profileringsmetrics eller HTTP-handler-metrics, der genererer intern statistik.
Black-box overvågning
Test af applikationsadfærd fra brugerens synspunkt.
Dashboard
En grænseflade (normalt web), der giver et overblik over centrale sundhedsindikatorer for tjenester. Dashboardet kan have filtre, mulighed for at vælge de viste indikatorer osv. Interfacet er designet til at identificere de indikatorer, der er vigtigst for brugerne. Dashboardet kan også vise information til teknisk supportpersonale: en kø af anmodninger, en liste over højprioritetsfejl og en tildelt ingeniør for et givet ansvarsområde.
Advarsel (meddelelse)
Meddelelser beregnet til at blive modtaget af en person via e-mail eller på anden måde, som kan udløses af fejl eller en stigning i anmodningskøen. Notifikationer er klassificeret som: billetter, e-mail-advarsler og instant messenger-beskeder.
Hovedårsagen
En softwarefejl eller menneskelig fejl, som, når den er rettet, ikke bør forekomme igen. Problemet kan have flere hovedårsager: utilstrækkelig procesautomatisering, softwaredefekt, utilstrækkelig udarbejdelse af applikationslogikken. Hver af disse faktorer kan være årsagen, og hver af dem skal elimineres.
Node og maskine (node og maskine)
Udskiftelige termer for at referere til en enkelt forekomst af et kørende program på en fysisk server, virtuel maskine eller container. En maskine kan være vært for flere tjenester. Tjenester kan være:
- forbundet med hinanden: for eksempel en cachingserver og en webserver;
- ikke-relaterede tjenester på et enkelt stykke hardware: for eksempel et kodelager og en guide til et konfigurationssystem, som f.eks. eller .
Skub ud
Enhver ændring i softwarekonfigurationen.
Hvorfor er der behov for overvågning?
Der er flere grunde til, at applikationer skal overvåges:
Analyse af langsigtede tendenser
Hvor stor er databasen, og hvor hurtigt vokser den? Hvordan ændrer det daglige antal brugere sig?
Præstationssammenligning
Er anmodninger hurtigere på Acme Bucket of Bytes 2.72 sammenlignet med Ajax DB 3.14? Hvor meget bedre cachelagres anmodninger efter fremkomsten af en ekstra node? Kører siden langsommere sammenlignet med sidste uge?
Alarmering (meddelelser)
Noget er gået i stykker, og nogen skal reparere det. Eller noget går snart i stykker, og nogen skal snart tjekke det.
Oprettelse af dashboards
Dashboards skal besvare grundlæggende spørgsmål og indeholde noget fra — forsinkelser (latency), trafik (trafik), fejl (fejl) og belastningsstørrelse (mætning).
Udførelse af retrospektiv analyse (fejlretning)
Forsinkelsen i anmodningsbehandlingen er steget, men hvad skete der ellers omkring samme tid?
Overvågningssystemer er nyttige som en datakilde for business intelligence-systemer og til at lette analysen af sikkerhedshændelser. Fordi denne bog fokuserer på tekniske områder, hvor SRE'er har ekspertise, vil vi ikke diskutere overvågningsteknikker her.
Overvågning og alarmer giver systemet mulighed for at fortælle dig, når det er brudt sammen eller er ved at gå i stykker. Når et system ikke automatisk kan reparere sig selv, vil vi have et menneske til at analysere advarslen, afgøre, om problemet stadig er aktivt, løse det og fastslå årsagen. Hvis du ikke auditerer systemkomponenter, vil du aldrig modtage en advarsel, blot fordi "noget virker lidt mærkeligt."
At belaste en person med underretninger er en ret dyr brug af en medarbejders tid. Hvis medarbejderen arbejder, afbryder alarmen arbejdsprocessen. Hvis medarbejderen er hjemme, afbryder alarmeringen den personlige tid og evt. søvn. Når advarsler forekommer for ofte, skimmer medarbejderne dem igennem, udsætter dem eller ignorerer indgående advarsler. Fra tid til anden ignorerer de den rigtige alarm, som er maskeret af støjbegivenheder. Serviceafbrydelser kan vare i lange perioder, da støjhændelser forhindrer problemet i at blive hurtigt diagnosticeret og rettet. Effektive advarselssystemer har et godt signal-til-støj-forhold.
At sætte rimelige forventninger til overvågningssystemet
Opsætning af overvågning til en kompleks applikation er en kompleks ingeniøropgave i sig selv. Selv med en betydelig infrastruktur af indsamlings-, visnings- og alarmeringsværktøjer omfatter et Google SRE-team på 10-12 medlemmer typisk en eller to personer, hvis primære formål er at bygge og vedligeholde overvågningssystemer. Dette antal er faldet over tid, efterhånden som vi konsoliderer og centraliserer overvågningsinfrastrukturen, men hvert SRE-team har typisk mindst én person, der udelukkende er dedikeret til overvågning. Vi må sige, at selvom overvågningssystemdashboards er ret interessante at se på, undgår SRE-teams omhyggeligt situationer, der kræver, at nogen kigger på en skærm for at overvåge problemer.
Overordnet set er Google gået over til enkle og hurtige overvågningssystemer med optimale efterfølgende analyseværktøjer. Vi undgår "magiske" systemer, der forsøger at forudsige tærskler eller automatisk opdager årsagen. Sensorer, der registrerer utilsigtet indhold i slutbrugeranmodninger, er det eneste modeksempel; Så længe disse sensorer forbliver enkle, kan de hurtigt opdage årsagerne til alvorlige anomalier. Andre formater til brug af overvågningsdata, såsom kapacitetsplanlægning eller trafikprognose, er mere komplekse. Observation over en meget lang periode (måneder eller år) ved en lav stikprøvehastighed (timer eller dage) vil afsløre en langsigtet tendens.
Google SRE-teamet har haft blandet succes med komplekse afhængighedshierarkier. Vi bruger sjældent regler som "hvis jeg finder ud af, at databasen er langsom, får jeg en advarsel om, at databasen er langsom, ellers får jeg en advarsel om, at siden er langsom." Afhængighedsbaserede regler refererer typisk til uforanderlige dele af vores system, såsom systemet til filtrering af brugertrafik til datacentret. For eksempel, "hvis trafikfiltrering til datacentret er konfigureret, må du ikke advare mig om forsinkelser i behandlingen af brugeranmodninger" er en generel regel for advarsler fra datacentret. Få teams hos Google understøtter komplekse afhængighedshierarkier, fordi vores infrastruktur har en konstant hastighed af kontinuerlig refaktorering.
Nogle af ideerne beskrevet i dette kapitel er stadig relevante: Der er altid mulighed for at bevæge sig hurtigere fra symptom til grundårsag, især i konstant skiftende systemer. Selvom dette kapitel skitserer nogle mål for overvågningssystemer og hvordan man opnår disse mål, er det derfor vigtigt, at overvågningssystemerne er enkle og forståelige for alle i teamet.
Ligeledes skal tilgange til overvågning af alarmerede aktiver være meget enkle og pålidelige for at holde støjniveauet lavt og signalniveauet højt. Regler, der genererer advarsler til mennesker, skal være lette at forstå og præsentere et klart problem.
Symptomer kontra årsager
Dit overvågningssystem skal besvare to spørgsmål: "hvad gik i stykker" og "hvorfor gik det i stykker."
"Hvad gik i stykker" taler om symptomet, og "hvorfor gik det i stykker" taler om årsagen. Tabellen nedenfor viser eksempler på sådanne forbindelser.
symptom
årsag
Får HTTP-fejl 500 eller 404
Databaseservere afviser forbindelser
Langsomme serversvar
Høj CPU-udnyttelse eller beskadiget Ethernet-kabel
Brugere i Antarktis modtager ikke katte-GIF'er
Dit CDN hader videnskabsmænd og katte, så nogle IP-adresser endte med at blive sortlistet
Privat indhold er blevet tilgængeligt overalt
Udrulningen af en ny softwareudgivelse fik firewallen til at glemme alle ACL'er og lukke alle ind
"Hvad" og "hvorfor" er nogle af de vigtigste byggesten til at skabe et godt overvågningssystem med maksimalt signal og minimal støj.
Black-box vs White-box
Vi kombinerer omfattende White-box-overvågning med beskeden Black-box-overvågning til kritiske målinger. Den nemmeste måde at sammenligne Black-box med White-box på er, at Black-box er symptomfokuseret og er reaktiv snarere end proaktiv overvågning: "systemet fungerer ikke korrekt lige nu." White-box afhænger af systemernes interne verifikationsmuligheder: hændelseslogfiler eller webservere. Således giver White-box dig mulighed for at opdage forestående problemer, fejl, der ser ud til at være en gentransmission af en anmodning osv.
Bemærk, at i et flerlagssystem er et symptom i en ingeniørs ansvarsområde et symptom i en anden ingeniørs ansvarsområde. For eksempel er databasens ydeevne faldet. Langsomme databaselæsninger er et symptom på databasens SRE, der registrerer dem. Men for en front-end SRE, der observerer en langsom hjemmeside, er årsagen til den samme langsomme databaselæsning en langsom database. Derfor er white-box-overvågning nogle gange symptomfokuseret og nogle gange årsagsfokuseret, afhængigt af hvor omfattende den er.
Ved indsamling af telemetri til debugging er White-box-overvågning påkrævet. Hvis webservere er langsomme til at svare på databaseforespørgsler, skal du vide, hvor hurtigt webserveren kommunikerer med databasen, og hvor hurtigt den reagerer. Ellers vil du ikke være i stand til at skelne mellem en langsom databaseserver og et netværksproblem mellem webserveren og databasen.
Black-box-overvågning har en vigtig fordel, når du sender advarsler: du udløser meddelelsen til modtageren, når problemet allerede har resulteret i reelle symptomer. På den anden side er overvågning ubrugelig for et Black-box-problem, der endnu ikke er opstået, men som er nært forestående.
Fire gyldne signaler
De fire gyldne overvågningssignaler er latency, trafik, fejl og mætning. Hvis du kun kan måle fire brugersystemmetrics, skal du fokusere på disse fire.
forsinkelse
Den tid, det tager at behandle anmodningen. Det er vigtigt at skelne mellem forsinkelsen af vellykkede og mislykkede anmodninger. For eksempel kan en HTTP 500-fejl forårsaget af tab af forbindelse til en database eller anden backend diagnosticeres meget hurtigt, dog kan en HTTP 500-fejl indikere en mislykket anmodning. Bestemmelse af indvirkningen af en 500-fejl på den samlede latenstid kan føre til fejlagtige konklusioner. På den anden side er en langsom fejl endda en hurtig fejl! Derfor er det vigtigt at overvåge fejlforsinkelse i stedet for blot at bortfiltrere fejl.
trafik
Antallet af anmodninger til dit system måles i systemmetrics på højt niveau. For en webservice repræsenterer denne måling typisk antallet af HTTP-anmodninger pr. sekund, divideret med arten af anmodningerne (f.eks. statisk eller dynamisk indhold). For et lydstreamingsystem kan denne måling fokusere på netværkets I/O-hastighed eller antallet af samtidige sessioner. For et nøgleværdi-lagringssystem kan denne måling være transaktioner eller søgeresultater pr. sekund.
Fejl
Dette er antallet af mislykkede anmodninger, der er eksplicitte (f.eks. HTTP 500), implicitte (f.eks. HTTP 200, men kombineret med ugyldigt indhold) eller politik (f.eks. "Hvis du fangede et svar på et sekund, er ethvert sekund en fejl"). Hvis HTTP-svarkoder ikke er tilstrækkelige til at udtrykke alle fejltilstande, kan det være nødvendigt med sekundære (interne) protokoller for at detektere delvis fejl. Overvågning af alle sådanne mislykkede anmodninger er muligvis ikke informativ, mens end-to-end systemtests vil hjælpe med at opdage, at du behandler forkert indhold.
Mætning
Metrikken viser, hvor intensivt din tjeneste bruges. Dette er en systemovervågningsforanstaltning, der identificerer de ressourcer, der er mest begrænset (f.eks. på et hukommelsesbegrænset system, viser hukommelse, på et I/O-begrænset system, viser antallet af I/O'er). Bemærk, at mange systemer forringer ydeevnen, før de når 100 % udnyttelse, så det er vigtigt at have et udnyttelsesmål.
I komplekse systemer kan mætning suppleres med belastningsmålinger på højere niveau: kan din tjeneste håndtere dobbelt trafik korrekt, kun håndtere 10 % mere trafik eller håndtere endnu mindre trafik, end den gør i øjeblikket? For simple tjenester, der ikke har parametre, der ændrer kompleksiteten af anmodningen (f.eks. "Giv mig ingenting" eller "Jeg har brug for et unikt enkelt monotont heltal"), som sjældent ændrer konfigurationen, kan en statisk belastningstestværdi være tilstrækkelig. Men som diskuteret i det foregående afsnit, skal de fleste tjenester bruge indirekte signaler såsom CPU-udnyttelse eller netværksbåndbredde, som har en kendt øvre grænse. Øget latens er ofte en førende indikator for mætning. Måling af 99. percentilens responstid i et lille vindue (f.eks. et minut) kan give et meget tidligt signal om mætning.
Endelig er mætning også forbundet med forudsigelser om forestående mætning, for eksempel: "Det ser ud til, at din database vil fylde din harddisk op om 4 timer."
Hvis du måler alle fire gyldne signaler, og når der er et problem med en af metrikken (eller, i tilfælde af mætning, et næsten problem), advarer du en person, din service vil være mere eller mindre dækket af overvågning.
Bekymringer om "halen" (eller instrumentering og ydeevne)
Når man laver et overvågningssystem fra bunden, er der en fristelse til at udvikle et system baseret på gennemsnitlige værdier: gennemsnitlig latenstid, gennemsnitlig CPU-udnyttelse af noder eller gennemsnitlig databasefylde. Faren ved de sidste to eksempler er indlysende: processorer og databaser bortskaffes på en meget uforudsigelig måde. Det samme gælder for forsinkelse. Hvis du kører en webtjeneste med en gennemsnitlig latenstid på 100 ms med 1000 anmodninger i sekundet, kan 1 % af anmodningerne tage 5 sekunder. Hvis brugere er afhængige af flere sådanne webtjenester, kan 99. percentilen af en backend nemt blive den mediane responstid for frontend.
Den enkleste måde at skelne mellem det langsomme gennemsnit og den meget langsomme hale af anmodninger er at indsamle målinger af anmodninger udtrykt i statistikker (et godt værktøj til at vise er histogrammer) snarere end faktiske latenser: hvor mange anmodninger tjenesten leverede, der tog mellem 0 ms og 10 ms, mellem 10 ms og 30 ms, mellem 30 ms og 100 ms, mellem 100 ms og 300 ms osv. Udvidelse af histogramgrænserne tilnærmelsesvis eksponentielt (med en omtrentlig faktor på 3) er ofte en enkel måde at visualisere fordelingen på af anmodninger.
Valg af det passende detaljeringsniveau for målinger
Forskellige elementer i systemet skal måles på forskellige detaljeringsniveauer. For eksempel:
- Overvågning af CPU-udnyttelse over en periode vil ikke vise langsigtede spidser, der fører til høje latenstider.
- På den anden side, for en webtjeneste, der ikke er målrettet mod mere end 9 timers nedetid om året (99,9 % årlig oppetid), vil det sandsynligvis være unødvendigt hyppigt at tjekke for et HTTP 200-svar mere end én eller to gange i minuttet.
- Ligeledes er det sandsynligvis ikke nødvendigt at kontrollere harddiskplads for 99,9 % tilgængelighed mere end én gang hvert 1.-2. minut.
Pas på, hvordan du strukturerer granulariteten af dine målinger. At indsamle CPU-belastning én gang i sekundet kan give interessante data, men sådanne hyppige målinger kan være meget dyre at indsamle, opbevare og analysere. Hvis dit overvågningsmål kræver høj granularitet og ikke kræver høj reaktionsevne, kan du reducere disse omkostninger ved at konfigurere metrikindsamling på serveren og derefter opsætte et eksternt system til at indsamle og aggregere disse metrics. Kan du:
- Mål CPU-belastning hvert sekund.
- Reducer detaljer til 5 %.
- Saml målinger hvert minut.
Denne strategi giver dig mulighed for at indsamle data med en høj granularitet uden at pådrage dig høje analyser og lagringsomkostninger.
Så enkelt som muligt, men ikke enklere
Overlejringen af forskellige krav oven på hinanden kan resultere i et meget komplekst overvågningssystem. For eksempel kan dit system have følgende komplicerende elementer:
- Advarsler i henhold til forskellige tærskler for forespørgselsbehandlingsforsinkelse, i forskellige percentiler, for alle typer forskellige indikatorer.
- Skrivning af yderligere kode for at opdage og identificere mulige årsager.
- Opret relaterede dashboards for hver af de mulige årsager til problemer.
Kilderne til potentielle komplikationer slutter aldrig. Som alle softwaresystemer kan overvågning blive så kompleks, at den bliver skrøbelig og svær at ændre og vedligeholde.
Design derfor dit overvågningssystem for at forenkle det så meget som muligt. Når du vælger, hvad du vil spore, skal du huske på følgende:
- De regler, der oftest fanger reelle hændelser, skal være så enkle, forudsigelige og pålidelige som muligt.
- Konfiguration til dataindsamling, aggregering og alarmering, der udføres sjældent (f.eks. mindre end kvartalsvis for nogle SRE-hold), bør fjernes.
- Metrics, der er indsamlet, men ikke vist i nogen forhåndsvisningsdashboard eller brugt af nogen underretning, er kandidater til sletning.
Hos Google fungerer grundlæggende metrics indsamling og aggregering, kombineret med advarsler og dashboards, godt som et relativt selvstændigt system (Googles overvågningssystem er faktisk opdelt i flere undersystemer, men folk er typisk opmærksomme på alle aspekter af disse undersystemer). Det kan være fristende at kombinere overvågning med andre teknikker til at undersøge komplekse systemer: detaljeret systemprofilering, procesfejlretning, sporing af detaljer om undtagelser eller fejl, belastningstest, logindsamling og -analyse eller trafikinspektion. Mens de fleste af disse ting har fællestræk med grundlæggende overvågning, vil blanding af dem resultere i for mange resultater og skabe et komplekst og skrøbeligt system. Som med mange andre aspekter af softwareudvikling er understøttelse af forskellige systemer med klare, enkle, løst koblede integrationspunkter den bedste strategi (for eksempel at bruge en web-API til at hente aggregerede data i et format, der kan forblive konsistent over en lang periode ).
At binde principperne sammen
De principper, der diskuteres i dette kapitel, kan kombineres til en overvågnings- og advarselsfilosofi, som er godkendt og fulgt af Google SRE-teams. At overholde denne overvågningsfilosofi er ønskværdigt, er et godt udgangspunkt for at skabe eller revidere din alarmeringsmetodologi og kan hjælpe dig med at stille de rigtige spørgsmål til din driftsfunktion, uanset størrelsen på din organisation eller kompleksiteten af tjenesten eller systemet.
Når du opretter overvågnings- og varslingsregler, kan følgende spørgsmål hjælpe dig med at undgå falske positiver og unødvendige advarsler:
- Detekterer denne regel en ellers uopdagelig tilstand af systemet, der er presserende, opfordrer til handling og uundgåeligt påvirker brugeren?
- Kan jeg ignorere denne advarsel, vel vidende at den er godartet? Hvornår og hvorfor kan jeg ignorere denne advarsel, og hvordan kan jeg undgå dette scenarie?
- Betyder denne advarsel, at brugerne bliver negativt påvirket? Er der situationer, hvor brugerne ikke påvirkes negativt, f.eks. gennem trafikfiltrering eller ved brug af testsystemer, for hvilke advarsler skal filtreres?
- Kan jeg reagere på denne advarsel? Er disse foranstaltninger presserende, eller kan de vente til i morgen tidlig? Kan handlingen automatiseres sikkert? Vil denne handling være en langsigtet løsning eller en kortsigtet løsning?
- Nogle mennesker får flere advarsler for dette problem, så er der en måde at reducere antallet af advarsler på?
Disse spørgsmål afspejler den grundlæggende filosofi om advarsler og advarselssystemer:
- Hver gang der kommer en alarm, skal jeg reagere med det samme. Jeg kan reagere akut flere gange om dagen, før jeg bliver træt.
- Hver advarsel skal være relevant.
- Ethvert svar på en advarsel skal kræve menneskelig indgriben. Hvis meddelelsen kan behandles automatisk, bør den ikke ankomme.
- Advarsler bør handle om et nyt problem eller en begivenhed, der ikke eksisterede før.
Denne tilgang udvisker visse forskelle: Hvis advarslen opfylder de foregående fire betingelser, er det lige meget, om advarslen sendes fra et White-box- eller Black-Box-overvågningssystem. Denne tilgang forstærker også visse forskelle: det er bedre at bruge meget mere indsats på at identificere symptomer end på årsager; når det kommer til årsager, behøver du kun at bekymre dig om de uundgåelige årsager.
Langtidsovervågning
I nutidens produktivitetsmiljøer overvåger overvågningssystemer et produktionssystem i konstant udvikling med skiftende softwarearkitektur, arbejdsbelastningskarakteristika og ydeevnemål. Advarsler, der i øjeblikket er svære at automatisere, kan blive almindelige, måske endda værd at tage fat på. På dette tidspunkt skal nogen finde og eliminere de grundlæggende årsager til problemet; hvis en sådan løsning ikke er mulig, kræver svaret på advarslen fuld automatisering.
Det er vigtigt, at overvågningsbeslutninger træffes med langsigtede mål for øje. Hver alarm, der kører i dag, distraherer en person fra at forbedre systemet i morgen, så der er ofte en reduktion i tilgængeligheden eller ydeevnen af et produktivt system i den tid, der er nødvendig for at forbedre overvågningssystemet på lang sigt. Lad os se på to eksempler for at illustrere dette fænomen.
Bigtable SRE: A Tale of Over-Alert
Googles interne infrastruktur er typisk klargjort og målt i forhold til et serviceniveau (SLO). For mange år siden var Bigtables service SLO baseret på den gennemsnitlige ydeevne af en syntetisk transaktion, der simulerede en live klient. På grund af problemer i Bigtable og lavere niveauer af lagerstakken blev den gennemsnitlige ydeevne drevet af en "stor" hale: De værste 5 % af forespørgsler var ofte betydeligt langsommere end resten.
E-mail-meddelelser blev sendt, da SLO-tærsklen blev nærmet sig, og messenger-advarsler blev sendt, når SLO blev overskredet. Begge typer advarsler blev sendt ret ofte, hvilket forbrugte uacceptable mængder af ingeniørtid: holdet brugte en betydelig mængde tid på at sortere gennem advarslerne for at finde de få, der faktisk var relevante. Vi gik ofte glip af et problem, der faktisk påvirkede brugerne, fordi kun nogle af advarslerne var for det specifikke problem. Mange af advarslerne var ikke hastende på grund af forståelige problemer i infrastrukturen og blev behandlet på en standard måde eller blev slet ikke behandlet.
For at afhjælpe situationen tog teamet en trestrenget tilgang: Mens vi arbejdede hårdt på at forbedre Bigtables ydeevne, satte vi midlertidigt vores SLO-mål til at være den 75. percentil for forespørgselssvarsforsinkelse. Vi har også slået e-mail-alarmer fra, fordi der var så mange af dem, at det var umuligt at bruge tid på at diagnosticere dem.
Denne strategi gav os pusterum til at begynde at løse langsigtede problemer i Bigtable og de nederste lag af lagerstakken i stedet for konstant at løse taktiske problemer. Ingeniører kunne faktisk få arbejdet udført uden at blive bombarderet med advarsler hele tiden. I sidste ende gav midlertidig udsættelse af advarselsbehandlingen os mulighed for at forbedre kvaliteten af vores service.
Gmail: Forudsigelige, algoritmiske menneskelige svar
Ved starten var Gmail bygget på et modificeret Workqueue-processtyringssystem, der var designet til at batchbehandle bidder af et søgeindeks. Workqueue blev tilpasset til langlivede processer og efterfølgende anvendt på Gmail, men nogle fejl i den uigennemsigtige planlægningskode viste sig at være meget svære at rette.
På det tidspunkt var Gmail-overvågning struktureret, så advarsler ville blive udløst, når individuelle opgaver blev annulleret ved hjælp af Workqueue. Denne tilgang var ikke ideel, for selv på det tidspunkt udførte Gmail mange tusinde opgaver, som hver blev leveret til en brøkdel af en procent af vores brugere. Vi var meget bekymrede for at give Gmail-brugere en god brugeroplevelse, men det var uden for rækkevidde at håndtere så mange underretninger.
For at løse dette problem har Gmail SRE oprettet et værktøj til at hjælpe med at fejlsøge planlæggeren så godt som muligt for at minimere indvirkningen på brugerne. Holdet havde nogle diskussioner om, hvorvidt man blot skulle automatisere hele cyklussen fra problemopdagelse til afhjælpning, indtil der blev fundet en langsigtet løsning, men nogle var bekymrede for, at en sådan løsning ville forsinke den faktiske løsning af problemet.
Denne spænding var almindelig i teamet og afspejlede ofte mangel på tillid til selvdisciplin: Mens nogle teammedlemmer ønsker at give tid til den korrekte rettelse, bekymrer andre sig om, at den endelige løsning vil blive glemt, og at den midlertidige løsning vil tage evigheder. Dette problem fortjener opmærksomhed, fordi det er for nemt at løse problemer midlertidigt i stedet for at gøre situationen permanent. Ledere og teknisk personale spiller en nøglerolle i implementeringen af langsigtede rettelser, understøtter og prioriterer potentielt langsigtede rettelser, selv efter at den indledende "smerte" forsvinder.
Regelmæssige, gentagne advarsler og algoritmiske svar bør være et rødt flag. Dit teams modvilje mod at automatisere disse advarsler betyder, at teamet mangler tillid til, at de kan stole på algoritmerne. Dette er et alvorligt problem, der skal løses.
Langsigtet
Et fælles tema forbinder Bigtable- og Gmail-eksemplerne: konkurrencen mellem kortsigtet og langsigtet tilgængelighed. Ofte kan en stærk indsats hjælpe et skrøbeligt system med at opnå høj tilgængelighed, men denne vej er normalt kortvarig, fyldt med teamudbrændthed og afhængighed af et lille antal medlemmer af det samme heroiske team.
En kontrolleret, kortvarig reduktion af tilgængeligheden er ofte smertefuld, men strategisk vigtig for systemets langsigtede stabilitet. Det er vigtigt ikke at se hver enkelt alarm isoleret, men at overveje, om det overordnede niveau af alarmvolumen fører til et sundt, korrekt tilgængeligt system med et levedygtigt team og en gunstig prognose. Vi analyserer statistik over varslingsfrekvens (normalt udtrykt som hændelser pr. skift, hvor en hændelse kan bestå af flere relaterede hændelser) i kvartalsrapporter til ledelsen, hvilket giver beslutningstagere mulighed for løbende at have et overblik over belastningen af advarselssystem og teamets overordnede helbred.
Konklusion
Vejen til sund overvågning og alarmering er enkel og klar. Den fokuserer på symptomerne på problemet, der udløser advarsler, og overvågning af årsagen tjener som en hjælp til fejlfinding af problemer. Overvågning af symptomer er nemmere, jo højere du er i den stak, du kontrollerer, selvom overvågning af belastning og ydeevne af databasen bør foretages direkte på selve databasen. E-mail-meddelelser har meget begrænset anvendelighed og har en tendens til let at blive støj; i stedet bør du bruge et dashboard, der overvåger alle aktuelle problemer, der udløser e-mail-alarmer. Dashboardet kan også parres med en hændelseslog for at analysere historiske korrelationer.
På lang sigt er det nødvendigt at opnå en vellykket rotation af alarmer om symptomer og overhængende reelle problemer, ved at tilpasse målene for at sikre, at overvågning understøtter hurtig diagnosticering.
Tak fordi du læste oversættelsen til slutningen. Abonner på min telegramkanal om overvågning и .
Kilde: www.habr.com