SRE (Site Reliability Engineering) är ett tillvägagångssätt för att göra webbprojekt tillgängliga. Det anses vara ett ramverk för DevOps och berättar hur man lyckas med tillämpningen av DevOps-praxis. Denna artikel översätts böcker från Google. Jag förberedde den här översättningen själv och förlitade mig på min egen erfarenhet av att förstå övervakningsprocesser. I telegramkanalen и Jag postade också en länk till en översättning av kapitel 4 i samma bok om Service Level Objectives.
Översättning av katt. Njut av att läsa!
Googles SRE-team har grundläggande principer och bästa praxis för att bygga framgångsrika övervaknings- och aviseringssystem. Det här kapitlet ger rekommendationer om vilka problem en webbsidabesökare kan stöta på och hur man löser problem som gör det svårt att visa webbsidor.
definiera
Det finns inget enskilt ordförråd som används för att diskutera ämnen relaterade till övervakning. Inte ens på Google är termerna nedan i vanligt bruk, men vi kommer att lista de vanligaste tolkningarna.
övervakning
Insamling, bearbetning, aggregering och visning av kvantitativa realtidsdata om systemet: antal förfrågningar och typer av förfrågningar, antal fel och typer av fel, förfrågningsbehandlingstid och serverdrifttid.
White box övervakning
Övervakning baserad på mätvärden som visas av systemets interna enheter, inklusive loggar, JVM- eller HTTP-hanterareprofileringsmått som genererar intern statistik.
Black box övervakning
Testa applikationens beteende ur användarens synvinkel.
Instrumentpanel (dashboards)
Ett gränssnitt (vanligtvis ett webbgränssnitt) som ger en översikt över tjänsternas nyckeltal för hälsan. Instrumentpanelen kan ha filter, möjlighet att välja vilka mätvärden som ska visas etc. Gränssnittet är utformat för att identifiera de viktigaste mätvärdena för användarna. Instrumentpanelen kan också visa information för teknisk supportpersonal: en förfrågningskö, en lista över högprioriterade fel, en tilldelad ingenjör för ett givet ansvarsområde.
Varning (avisering)
Meddelanden som är avsedda att tas emot av en person via e-post eller på annat sätt, som kan utlösas till följd av fel eller ökad förfrågningskö. Aviseringar kategoriseras som: biljetter, e-postvarningar och messenger-meddelanden.
Grundorsak (grundorsak)
Ett programvarufel eller mänskligt fel som, när det är åtgärdat, inte bör inträffa igen. Problemet kan ha flera huvudorsaker: otillräcklig processautomatisering, mjukvarufel, otillräcklig studie av applikationslogiken. Var och en av dessa faktorer kan vara grundorsaken, och var och en av dem måste elimineras.
Nod och maskin (nod och maskin)
Utbytbara termer för att hänvisa till en enda instans av ett program som körs på en fysisk server, virtuell maskin eller behållare. Det kan finnas flera tjänster på en maskin. Tjänster kan vara:
- relaterade till varandra: till exempel en cacheserver och en webbserver;
- orelaterade tjänster på samma hårdvara: till exempel ett kodlager och en guide för ett konfigurationssystem, som t.ex. eller .
Tryck
Eventuella ändringar av mjukvarukonfigurationen.
Varför övervakning behövs
Det finns flera skäl till varför applikationer bör övervakas:
Analys av långsiktiga trender
Hur stor är databasen och hur snabbt växer den? Hur förändras det dagliga antalet användare?
Prestandajämförelse
Är frågor snabbare på Acme Bucket of Bytes 2.72 än Ajax DB 3.14? Hur mycket bättre cachelagras förfrågningar efter uppkomsten av en extra nod? Har sidan blivit långsammare än förra veckan?
Varning (aviseringar)
Något är trasigt och någon måste laga det. Eller så går något sönder snart och någon måste kolla upp det snart.
Skapa instrumentpaneler
Instrumentpaneler ska svara på grundläggande frågor och innehålla något från - förseningar (latens), trafik (trafik), fel (fel) och belastningsvärde (mättnad).
Genomföra retrospektiv analys (felsökning)
Behandlingsfördröjningen för begäran ökade, vad mer hände vid samma tidpunkt?
Övervakningssystem är användbara som datakälla för business intelligence-system och för att underlätta analysen av säkerhetsincidenter. Eftersom den här boken fokuserar på tekniska områden där SRE har expertis, kommer vi inte att diskutera övervakningstekniker här.
Övervakning och varningar låter systemet berätta när det har gått sönder eller är på väg att gå sönder. När ett system inte automatiskt kan reparera sig själv vill vi att en människa ska analysera varningen, avgöra om problemet kvarstår, åtgärda det och fastställa dess grundorsak. Om du inte granskar systemkomponenter kommer du aldrig att få en varning bara för att "något verkar lite konstigt."
Att ladda mänskliga varningar är en ganska dyr användning av en anställds tid. Om medarbetaren arbetar avbryter varningen arbetsflödet. Om medarbetaren är hemma avbryter larmet personlig tid och eventuellt sömn. När varningar inträffar för ofta skummar, försenar eller ignorerar anställda inkommande varningar. Då och då ignorerar de den verkliga varningen, som är maskerad av bullerhändelser. Serviceavbrott kan pågå under lång tid eftersom bullerhändelser förhindrar snabb problemdiagnostik och lösning. Effektiva högtalarsystem har ett bra signal-brusförhållande.
Fastställande av rimliga förväntningar från övervakningssystemet
Att sätta upp övervakning för en komplex applikation är en komplex ingenjörsuppgift i sig. Även med en betydande infrastruktur av insamlings-, visnings- och varningsverktyg, inkluderar ett Google SRE-team på 10-12 medlemmar vanligtvis en eller två personer vars huvudsakliga syfte är att bygga och underhålla övervakningssystem. Detta antal har minskat med tiden när vi generaliserar och centraliserar övervakningsinfrastrukturen, men varje SRE-team har vanligtvis minst en anställd som endast är övervakningspersonal. Det måste sägas att även om det är ganska intressant att titta på övervakningssystems instrumentpaneler, undviker SRE-team noggrant situationer som kräver att någon tittar på skärmen för att övervaka problem.
Generellt sett har Google gått över till enkla och snabba övervakningssystem med optimala efterhandsanalysverktyg. Vi undviker "magiska" system som försöker förutsäga trösklar eller automatiskt upptäcker grundorsaken. Sensorer som upptäcker oavsiktligt innehåll i slutanvändarförfrågningar är det enda motexemplet; så länge dessa sensorer förblir enkla kan de snabbt upptäcka orsakerna till allvarliga anomalier. Andra format för att använda övervakningsdata, som kapacitetsplanering eller trafikprognoser, är mer utmanande. En observation över en mycket lång tid (månader eller år) med en låg samplingsfrekvens (timmar eller dagar) kommer att avslöja en långsiktig trend.
Googles SRE-team har hanterat komplexa beroendehierarkier med blandad framgång. Vi använder sällan regler som "om jag upptäcker att databasen har blivit långsam får jag en varning om databasnedgång, annars får jag en långsam sajtvarning." Beroendebaserade regler hänvisar vanligtvis till de oföränderliga delarna av vårt system, såsom systemet för att filtrera användartrafik till datacentret. Till exempel, "om datacentertrafikfiltrering är konfigurerad, varna mig inte om förseningar i behandlingen av användarförfrågningar" är en vanlig regel för datacentervarningar. Få team på Google stöder komplexa beroendehierarkier eftersom vår infrastruktur har en konstant hastighet av kontinuerlig omfaktorering.
Några av idéerna som beskrivs i detta kapitel håller fortfarande: det finns alltid ett sätt att gå snabbare från symptom till grundorsak, särskilt i system som ständigt förändras. Därför, även om det här kapitlet beskriver några mål för övervakningssystem och hur man uppnår dessa mål, är det viktigt att övervakningssystem är enkla och begripliga för alla i teamet.
Likaså, för att hålla brusnivån låg och signalnivån hög, måste tillvägagångssätt för att övervaka objekt som larmas vara mycket enkla och tillförlitliga. Regler som genererar varningar för människor ska vara lätta att förstå och presentera ett tydligt problem.
Symtom kontra orsaker
Ditt övervakningssystem bör svara på två frågor: "vad är trasigt" och "varför är det trasigt".
"Vad gick sönder" hänvisar till symtomet och "varför gick sönder" hänvisar till orsaken. Tabellen nedan visar exempel på sådana länkar.
symptom
anledning
Tar emot HTTP-fel 500 eller 404
Databasservrar vägrar anslutningar
Långsamma serversvar
Hög CPU-användning eller skadad Ethernet-kabel
Användare i Antarktis får inte katt-GIF
Ditt CDN hatar vetenskapsmän och kattdjur, så vissa IP-adresser är svartlistade
Privat innehåll är tillgängligt överallt
Att rulla en ny mjukvaruversion fick brandväggen att glömma alla ACL och släppa in alla
"Vad" och "varför" är en av de viktigaste byggstenarna för att skapa ett bra övervakningssystem med maximal signal och minimalt brus.
Black-box vs White-box
Vi kombinerar omfattande white-box-övervakning med blygsam black-box-övervakning för kritiska mätvärden. Det enklaste sättet att jämföra Black-box med White-box är att Black-box är symptomfokuserad och är reaktiv snarare än proaktiv övervakning: "systemet fungerar inte korrekt just nu." White-box beror på systemens interna kontrollfunktioner: händelseloggar eller webbservrar. Således låter White-box dig upptäcka kommande problem, fel som ser ut som en återsändning av en förfrågan, etc.
Observera att i ett flerskiktssystem är ett symptom inom en ingenjörs ansvarsområde ett symptom inom en annan ingenjörs ansvarsområde. Databasprestanda har till exempel minskat. Långsamma databasläsningar är ett symptom på databasen SRE som upptäcker dem. Men för en front-end SRE som tittar på en långsam webbplats är anledningen till samma långsamma databasläsning att databasen är långsam. Därför är white-box-övervakning ibland inriktad på symtom och ibland på orsaker, beroende på hur omfattande den är.
Vid insamling av telemetri för felsökning krävs White-box-övervakning. Om webbservrar är långsamma att svara på databasfrågor måste du veta hur snabbt webbservern kommunicerar med databasen och hur snabbt den svarar. Annars kommer du inte att kunna se skillnaden mellan en långsam databasserver och ett nätverksproblem mellan webbservern och databasen.
Black-box-övervakning har en viktig fördel när du skickar varningar: du utlöser ett meddelande till mottagaren när problemet redan har orsakat faktiska symptom. Å andra sidan, för Black-box-problemet som ännu inte har uppstått, men det kommande, är övervakning värdelös.
Fyra gyllene signaler
De fyra gyllene övervakningssignalerna är latens, trafik, fel och mättnad. Om du bara kan mäta fyra användarsystemstatistik, fokusera på dessa fyra.
Fördröjning
Den tid som krävs för att behandla begäran. Det är viktigt att skilja mellan fördröjningen av framgångsrika och misslyckade förfrågningar. Till exempel kan ett HTTP 500-fel orsakat av en förlorad anslutning till en databas eller en annan backend diagnostiseras mycket snabbt, men ett HTTP 500-fel kan indikera en misslyckad begäran. Att hitta effekten av ett 500-fel på den totala latensen kan leda till felaktiga slutsatser. Å andra sidan är ett långsamt fel till och med ett snabbt fel! Därför är det viktigt att spåra felfördröjning snarare än att bara filtrera bort fel.
trafik
Antalet förfrågningar till ditt system, mätt i systemmått på hög nivå. För en webbtjänst representerar detta mått vanligtvis antalet HTTP-förfrågningar per sekund dividerat med arten av förfrågningarna (till exempel statiskt eller dynamiskt innehåll). För ett ljudströmningssystem kan denna mätning vara centrerad på nätverkets I/O-hastighet eller antalet samtidiga sessioner. För ett nyckel-värde-lagringssystem kan denna mätning vara transaktioner eller uppslagningar per sekund.
Fel
Detta är antalet misslyckade förfrågningar, antingen explicit (till exempel HTTP 500), implicit (till exempel HTTP 200 men kombinerat med dåligt innehåll) eller enligt policy (till exempel "Om du fångar ett svar på en sekund, en sekund är ett fel"). Om det inte finns tillräckligt med HTTP-svarskoder för att uttrycka alla feltillstånd, kan sekundära (interna) protokoll krävas för att upptäcka partiellt fel. Att övervaka alla sådana felaktiga förfrågningar kan vara oinformativt, medan systemtester från slut till slut kan hjälpa dig att upptäcka att du bearbetar fel innehåll.
Mättnad
Mätvärdet visar hur hårt din tjänst används. Detta är en systemövervakningsåtgärd som identifierar resurser som är mest begränsade (till exempel i ett system med begränsat minne, visar minne, i ett system med begränsat I/O, visar antalet I/O). Observera att många system försämras innan de når 100 % användning, så att ha ett användningsmål är viktigt.
I komplexa system kan mättnad kompletteras med belastningsmätning på högre nivå: kan din tjänst korrekt hantera dubbel trafik, bara hantera 10 % mer trafik eller hantera ännu mindre trafik än vad den kan för närvarande? För enkla tjänster som inte har parametrar som ändrar komplexiteten i begäran (t.ex. "Ge mig ingenting" eller "Jag vill ha ett unikt monotont heltal") som sällan ändrar konfigurationen, kan ett statiskt belastningstestvärde vara tillräckligt. som diskuterats i föregående stycke bör de flesta tjänster använda indirekta signaler som CPU-användning eller nätverksbandbredd som har en känd övre gräns. Stigande latens är ofta den främsta indikatorn på mättnad. Att mäta 99:e percentilens svarstid i ett litet fönster (t.ex. en minut) kan ge en mycket tidig mättnadssignal.
Slutligen är mättnad också förknippad med förutsägelser om förestående mättnad, såsom: "Det ser ut som att din databas kommer att fylla upp din hårddisk inom 4 timmar."
Om du mäter alla fyra gyllene signaler och när det finns ett problem med någon av måtten (eller, vid mättnad, nästan ett problem), meddelar du personen, din tjänst kommer mer eller mindre att omfattas av övervakning.
Oroa dig för svansen (eller instrumentering och prestanda)
När man bygger ett övervakningssystem från grunden är det frestande att utveckla ett system baserat på medelvärden: genomsnittlig latens, genomsnittlig nod-CPU-användning eller genomsnittlig databasbeläggning. Faran med de två sista exemplen är uppenbar: processorer och databaser kasseras på ett mycket oförutsägbart sätt. Detsamma gäller förseningar. Om du kör en webbtjänst med en genomsnittlig latens på 100 ms vid 1000 1 förfrågningar per sekund, kan 5 % av förfrågningarna ta 99 sekunder. Om användare är beroende av flera sådana webbtjänster kan den XNUMX:e percentilen för en enda backend lätt bli gränssnittets mediansvarstid.
Det enklaste sättet att skilja mellan ett långsamt genomsnitt och en mycket långsam svans av förfrågningar är att samla in mätningar av förfrågningar uttryckta i statistik (histogram är ett lämpligt verktyg att visa), snarare än faktiska förseningar: hur många förfrågningar som betjänades av tjänsten som tog mellan 0 ms och 10 ms, mellan 10 ms och 30 ms, mellan 30 ms och 100 ms, mellan 100 ms och 300 ms, etc. Att expandera histogramgränserna ungefär exponentiellt (med en faktor på cirka 3) är ofta ett enkelt sätt att visualisera fördelningen av förfrågningar.
Att välja rätt granularitet för mätningar
Olika delar av systemet bör mätas med olika detaljnivåer. Till exempel:
- Att titta på CPU-användning under en tidsperiod kommer inte att visa långa toppar som resulterar i höga latenser.
- Å andra sidan, för en webbtjänst som är inriktad på högst 9 timmars driftstopp per år (99,9 % årlig drifttid), skulle det förmodligen vara onödigt ofta att kontrollera efter ett HTTP 200-svar mer än en eller två gånger per minut.
- På samma sätt är det förmodligen onödigt att leta efter ledigt utrymme på hårddisken för 99,9 % tillgänglighet mer än en gång var 1-2:e minut.
Var noga med hur du strukturerar dimensionernas granularitet. En CPU-användningshastighet på 1 per sekund kan ge intressanta data, men sådana frekventa mätningar kan vara mycket dyra att samla in, lagra och analysera. Om ditt övervakningsmål kräver hög granularitet och inte kräver hög lyhördhet, kan du minska dessa kostnader genom att ställa in mätvärdesinsamling på servern och sedan konfigurera ett externt system för att samla in och aggregera dessa mätvärden. Kan du:
- Mät CPU-användning varje sekund.
- Minska detaljnivån till 5 %.
- Samla mätvärden varje minut.
Denna strategi gör att du kan samla in mycket granulär data utan att behöva uppleva höga omkostnader för analys och lagring.
Så enkelt som möjligt, men inte lättare
Att stapla olika krav på varandra kan leda till ett mycket komplext övervakningssystem. Ditt system kan till exempel ha följande komplicerande element:
- Varningar enligt olika trösklar för fördröjningsfördröjning, i olika percentiler, över alla typer av olika mätvärden.
- Skriva ytterligare kod för att upptäcka och identifiera möjliga orsaker.
- Skapa relaterade instrumentpaneler för var och en av de möjliga orsakerna till problem.
Källorna till potentiella komplikationer tar aldrig slut. Liksom alla mjukvarusystem kan övervakning bli så komplex att den blir ömtålig, svår att ändra och underhålla.
Designa därför ditt övervakningssystem för att förenkla det så mycket som möjligt. När du väljer vad du ska spåra, tänk på följande:
- De regler som oftast fångar verkliga incidenter ska vara så enkla, förutsägbara och pålitliga som möjligt.
- Konfigurationen för datainsamling, aggregering och varning som utförs sällan (till exempel mindre än kvartalsvis för vissa SRE-team) bör tas bort.
- Mätvärden som samlas in men inte visas i någon förhandsgranskningspanel eller används av någon varning är kandidater för radering.
Hos Google fungerar grundläggande insamling och aggregering av mätvärden, kombinerat med varningar och instrumentpaneler, bra som ett relativt självständigt system (Googles övervakningssystem är faktiskt uppdelat i flera delsystem, men vanligtvis är folk medvetna om alla aspekter av dessa delsystem). Det kan vara frestande att kombinera övervakning med andra metoder för att testa komplexa system: detaljerad systemprofilering, processfelsökning, spårning av undantags- eller feldetaljer, lasttestning, logginsamling och analys eller trafikinspektion. Även om de flesta av dessa saker har gemensamma drag med grundläggande övervakning, kommer att blanda ihop dem resultera i för många resultat och skapa ett komplext och sprött system. Som med många andra aspekter av mjukvaruutveckling, är stöd för olika system med tydliga, enkla, löst kopplade integrationspunkter den bästa strategin (till exempel att använda ett webb-API för att hämta sammanfattande data i ett format som kan förbli konstant under en lång tidsperiod ).
Att länka ihop principer
Principerna som diskuteras i det här kapitlet kan kombineras till en övervaknings- och varningsfilosofi som stöds och följs av Googles SRE-team. Att hålla fast vid denna övervakningsfilosofi är önskvärt, det är en bra utgångspunkt för att skapa eller revidera en varningsmetodik och kan hjälpa dig att ställa rätt frågor till verksamheten oavsett storleken på din organisation eller tjänstens eller systemets komplexitet.
När du skapar övervaknings- och varningsregler kan följande frågor hjälpa dig att undvika falska positiva och onödiga varningar:
- Upptäcker denna regel ett annars oupptäckbart systemtillstånd som är brådskande, uppmanar till handling och oundvikligen påverkar användaren?
- Kan jag ignorera denna varning med vetskap om att den är godartad? När och varför kan jag ignorera denna varning och hur kan jag undvika detta scenario?
- Betyder denna varning att användarna påverkas negativt? Finns det situationer där användare inte påverkas negativt, till exempel på grund av trafikfiltrering eller vid användning av testsystem, varningar som bör filtreras?
- Kan jag vidta åtgärder som svar på denna varning? Är dessa åtgärder brådskande eller kan de vänta till morgonen? Är det säkert att automatisera åtgärden? Kommer denna åtgärd att vara en långsiktig lösning eller en kortsiktig lösning?
- Vissa personer får flera varningar för det här problemet, så är det möjligt att minska antalet?
Dessa frågor återspeglar den grundläggande filosofin kring varningar och varningssystem:
- Varje gång en larm kommer in måste jag reagera akut. Jag kan rusa flera gånger om dagen innan jag blir trött.
- Varje varning måste vara uppdaterad.
- Varje svar på en varning måste kräva mänskligt ingripande. Om anmälan kan behandlas automatiskt ska den inte komma.
- Varningar bör handla om ett nytt problem eller en händelse som inte har hänt tidigare.
Detta tillvägagångssätt suddar ut vissa distinktioner: om en varning uppfyller de föregående fyra villkoren spelar det ingen roll om varningen skickas från ett White-box-övervakningssystem eller en Black-Box. Detta tillvägagångssätt förstärker också vissa skillnader: det är bättre att lägga mycket mer ansträngning på att identifiera symtom än på orsaker; när det kommer till orsaker behöver du bara oroa dig för de oundvikliga orsakerna.
Långtidsövervakning
I dagens produktionsmiljöer övervakar övervakningssystem ett produktionssystem i ständig utveckling med förändrad mjukvaruarkitektur, belastningsegenskaper och prestandamål. Varningar, som för närvarande är svåra att automatisera, kan bli vanliga, kanske till och med värda att åtgärdas. Vid det här laget måste någon hitta och åtgärda grundorsakerna till problemet; om en sådan lösning inte är möjlig kräver reaktionen på varningen full automatisering.
Det är viktigt att uppföljningsbeslut fattas med långsiktiga mål i åtanke. Varje varning som körs idag tar en person bort från att förbättra systemet i morgon, så det blir ofta en minskning av tillgängligheten eller prestandan för ett produktivt system under den tid det tar att förbättra övervakningssystemet på lång sikt. Låt oss titta på två exempel som illustrerar detta fenomen.
Bigtable SRE: En berättelse om övervarning
Googles interna infrastruktur tillhandahålls vanligtvis och mäts i termer av servicenivå (SLO). För år sedan baserades SLO för Bigtable-tjänsten på den genomsnittliga prestandan för en syntetisk transaktion som simulerade en löpande klient. På grund av problem i Bigtable och lägre nivåer av lagringsstacken, drevs den genomsnittliga prestandan av en "stor" svans: de värsta 5 % av frågorna var ofta betydligt långsammare än resten.
E-postmeddelanden skickades när SLO-tröskeln närmade sig, och meddelandemeddelanden skickades när SLO-gränsen överskreds. Båda typerna av varningar skickades ganska ofta, vilket tog oacceptabla mängder teknisk tid: teamet spenderade en betydande tid på att analysera varningarna för att hitta några som faktiskt var relevanta. Vi missade ofta ett problem som faktiskt påverkade användare eftersom endast ett fåtal av varningarna gällde det specifika problemet. Många av varningarna var icke-brådskande på grund av förståeliga infrastrukturproblem och hanterades på ett vanligt sätt, eller hanterades inte alls.
För att åtgärda situationen använde teamet ett tredelat tillvägagångssätt: samtidigt som vi arbetade hårt för att förbättra Bigtables prestanda, satte vi tillfälligt in den 75:e percentilen för fördröjning av frågesvar som vårt SLO-mål. Vi stängde också av e-postvarningar, eftersom det fanns så många av dem att det var omöjligt att slösa tid på att diagnostisera dem.
Den här strategin gav oss en paus för att börja fixa långsiktiga problem i Bigtable och de lägre lagren av lagringsstacken, snarare än att ständigt fixa taktiska problem. Ingenjörer kunde faktiskt få jobbet gjort när de inte bombarderades med varningar hela tiden. I slutändan tillät den tillfälliga förseningen i behandlingen av varningar oss att förbättra kvaliteten på tjänsten.
Gmail: Förutsägbara, algoritmiska mänskliga svar
I början byggdes Gmail på ett modifierat Workqueue-processkontrollsystem som skapades för att batchbearbeta sökindexbitar. Workqueue anpassades till långlivade processer och tillämpades därefter på Gmail, men vissa buggar i den ogenomskinliga schemaläggarkoden visade sig vara mycket svåra att fixa.
På den tiden var Gmail-övervakningen strukturerad så att varningar skulle aktiveras när enskilda uppgifter avbröts med Workqueue. Det här tillvägagångssättet var inte idealiskt, eftersom Gmail även vid den tiden utförde tusentals uppgifter, som var och en gavs till bråkdelar av en procent av våra användare. Vi var noga med att säkerställa att Gmail-användare har en bra användarupplevelse, men att hantera så många varningar var uteslutet.
För att lösa detta problem skapade Gmail SRE ett verktyg för att hjälpa till att felsöka schemaläggaren så bra som möjligt för att minimera påverkan på användarna. Teamet hade flera diskussioner om huruvida man helt enkelt skulle automatisera hela cykeln från att hitta problemet till att åtgärda det tills en långsiktig lösning hittats, men några var oroliga för att en sådan lösning skulle försena den faktiska lösningen av problemet.
Sådana spänningar var vanliga inom teamet och återspeglade ofta en bristande tilltro till självdisciplin: medan vissa lagmedlemmar vill ge tid för en ordentlig fix, oroar andra sig för att den slutliga fixen kommer att glömmas bort och att den tillfälliga fixen kommer att ta en evighet. Detta problem förtjänar uppmärksamhet, eftersom det är för lätt att åtgärda problem tillfälligt, istället för att göra en permanent fix. Chefer och teknisk personal spelar en nyckelroll i implementeringen av långsiktiga fixar genom att stödja och prioritera potentiellt långsiktiga långsiktiga fixar även när den initiala smärtan avtar.
Regelbundna återkommande varningar och algoritmiska reaktioner bör vara en röd flagga. Ditt teams ovilja att automatisera dessa varningar betyder att teamet saknar förtroende för att de kan lita på algoritmerna. Detta är ett allvarligt problem som måste åtgärdas.
Långsiktigt
Ett vanligt tema kopplar ihop Bigtable- och Gmail-exemplen: konkurrensen mellan kortsiktig och långsiktig tillgänglighet. Ofta kan en stark insats hjälpa ett ömtåligt system att uppnå hög tillgänglighet, men denna väg är vanligtvis kortlivad, fylld av teamutbrändhet och beroende av ett litet antal medlemmar i samma heroiska team.
En kontrollerad, kortsiktig nedgång i tillgänglighet är ofta smärtsam, men strategiskt viktig för systemets långsiktiga stabilitet. Det är viktigt att inte betrakta varje larm isolerat, utan att överväga om den totala larmfrekvensen leder till ett sunt, ordentligt tillgängligt system med ett livskraftigt team och en gynnsam prognos. Vi analyserar varningsfrekvensstatistik (vanligtvis uttryckt som incidenter per skift, där en incident kan bestå av flera relaterade incidenter) i kvartalsrapporter med ledningen, vilket gör det möjligt för beslutsfattare att kontinuerligt presentera varningssystemets belastning och teamets övergripande hälsa.
Slutsats
Vägen till sund övervakning och varningar är enkel och okomplicerad. Den fokuserar på symptomen på problemet för vilka varningar genereras, och övervakning av orsaken fungerar som ett hjälpmedel för att felsöka problem. Symtomövervakning är lättare ju högre du är i den stack du kontrollerar, även om databasbelastning och prestandaövervakning bör göras direkt på själva databasen. E-postmeddelanden är av mycket begränsad användning och tenderar att lätt eskalera till brus; istället bör du använda en instrumentpanel som övervakar alla aktuella problem som larmas via e-post. Instrumentpanelen kan också paras ihop med en händelselogg för att analysera historiska korrelationer.
På lång sikt behöver en framgångsrik växling mellan symtomvarningar och överhängande verkliga problem uppnås och mål anpassas för att säkerställa att övervakningen stödjer snabb diagnos.
Tack för att du läste översättningen till slutet. Prenumerera på min telegramkanal om övervakning и .
Källa: will.com