Ändra ram
Av alla enheter i den här modulen är detta verkligen en av de viktigaste. I den här lektionen ska vi överväga några idéer som kan förändra hur vi utformar vår förståelse för vad som är viktigt att övervaka och varför. För vissa människor kan detta radikalt förändra allt om hur de tänker på övervakning för att förbättra sin tillförlitlighet.
Omformulering #1: Tillförlitlighet ur kundens perspektiv
Vi har tidigare diskuterat aspekter av tillförlitlighet som vi kanske vill överväga övervakning, men det verkade bara utöka möjliga uppsättningar av saker som vi kan övervaka. Här är en idé som kan hjälpa dig att nollställa vad du bör övervaka för att förbättra din tillförlitlighet:
Tillförlitlighet måste mätas ur kundens perspektiv, inte från komponentperspektivet.
Det är jätteviktigt. Du kanske vill läsa den igen eftersom det är så viktigt. Tidigare skulle folk förespråka att "övervaka alla saker!" Om vi kunde läsa en räknare från den, rita en statistik eller placera den på en instrumentpanel, tänkte vi att vi skulle övervaka den. "Mät från kundens perspektiv" är ett mycket mer specifikt dictum.
Låt oss titta på ett kort scenario som både illustrerar poängen och understryker den.
Scenario
Du ansvarar för att driva e-handelswebbplatsen för ditt företag. Du har en webbgrupp med 100 serverinstanser. Plötsligt slutar 14 av dessa 100 instanser att fungera på grund av ett operativsystemfel, en programuppdatering, en strömfluktuation eller någon annan oväntad händelse. Dessa 14 instanser är nu helt ur drift.
För att granska: 86 serverinstanser är i drift och 14 serverinstanser är inte i drift.
Vilket av följande gäller i den här situationen?
S: Det är ingen stor sak. Du kan hantera problemet någon gång när du har tid att åtgärda det.
B: Det är allvarligt. Du bör stoppa det du gör och få tillbaka de 14 serverinstanserna i drift så snart som möjligt.
C: Det är en existentiell kris för verksamheten. Du bör meddela chefer på C-nivå och ringa alla till jobbet för att ta hand om situationen så snabbt som möjligt, även om det innebär att få dem ur sängen mitt i natten.
Ta en stund att tänka igenom det här scenariot noggrant innan du svarar och läs sedan vidare. Tror du att det är A, B eller C?
Det rätta svaret är varken A, B eller C; Det är "det beror på". Eller mer exakt, "det beror på hur dina kunder upplever detta avbrott."
Om du har skapat webbplatsen på ett sådant sätt att inga kunder ens märkte att de bakomliggande systemen gick ner och de andra 86 serverinstanserna bär upp belastningen utan problem, så finns det ingen kris här. Det kan vara en SEV-3- eller SEV-4-incident, eller kanske bara till och med ett supportärende.
Om avbrottet har gjort att hela ditt företag står helt stilla och du förlorar stora summor pengar för varje minut som servrarna ligger nere, är det förmodligen en bra anledning att trycka på den stora röda knappen och samla alla snabbt. Det kan också finnas en medelväg där svaret blir "B".
Återigen måste tillförlitlighet mätas ur kundens perspektiv, inte komponentperspektivet. Därför var komponentantalet "14 datorer nere av 100", även om det var helt korrekt, inte den viktigaste informationen i det här scenariot ur tillförlitlighetssynpunkt.
Den här idén gäller även när vi talar om mer traditionell komponentbaserad övervakning. Om du får reda på att databasservern körs vid 50% CPU-belastning, är det bra eller dåligt? Om det går upp till 90%, är det bättre eller sämre? Om tjänsten fungerar bra och användarna är nöjda kan 90% vara bra eftersom det innebär att du har förbättrat resursanvändningen avsevärt. Men om användarna klagar över hur långsamt programmet kördes med 50% processorbelastning är det inte troligt att 90% är en förbättring.
Omramning nr 2: Lämpliga tillförlitlighetsnivåer
För att konfigurera den här idén korrekt bör vi ta en snabb titt på dess ursprung. Den här idén kommer från SRE (Site Reliability Engineering). Vi kan extrahera flera användbara idéer (inklusive den för det här avsnittet) genom att noggrant undersöka definitionen av SRE:
Anteckning
Site Reliability Engineering är ett teknikområde som ägnar sig åt att hjälpa organisationer att uppnå lämplig tillförlitlighetsnivå i sina system, tjänster och produkter.
Det finns tre viktiga ord i den här definitionen:
Tillförlitlighet: Vi har talat mycket om vikten av tillförlitlighet i introduktionsenheten, så vi kommer inte att gå in på det i detalj här.
Hållbart: I detta sammanhang refererar "hållbart" till människors roll i allt detta. Det är viktigt att vi skapar en hållbar driftspraxis. Tillförlitliga system, tjänster, produkter byggs av människor. Om vi inte gör saker för att se till att vårt arbete är hållbart – om vi väcker vårt folk klockan 03:00 varje kväll med en sida, om vi inte ger dem tid med sin familj, om de inte har möjlighet att ägna tid åt att ta hand om sig själva – så finns det inte en chans att de kommer att kunna bygga tillförlitliga system. SRE tycker att det är viktigt att vi implementerar en driftspraxis som är hållbar över tid så att våra medarbetare kan ta sitt bästa till jobbet.
Lämpligt: Det här är ordet som kan vara en spelväxlare för vissa människor. Det var en gång i driftvärldens att vårt mål var att se till att allt var igång dygnet runt. Vi försökte hålla allt uppe hela dagen, hela veckan lång, hela månaden lång och hela året lång. Det var aldrig acceptabelt att något gick ner. En av de saker som platstillförlitlighetsteknik förde till driftdiskussionen var en uppfattning om att vi bör sträva efter en lämplig nivå av tillförlitlighet i stället.
Låt oss gå in på den här idén. En viktig punkt här är att 100% tillförlitlig är nästan aldrig rätt mål. Förutom vissa undantag som medicintekniska produkter eller flyg behöver vi egentligen inte att saker är 100% tillförlitliga; och i själva verket är det inte ofta möjligt att de är 100% tillförlitliga.
Här är ett exempel på "inte ens möjligt:" Nu för tiden kör vi alla system som har beroenden på andra system. Du kanske kör en programvara som måste skickas till en betalningsprocessor eller som måste anropas i autentiseringssystemet. Om betalningsprocessorn inte är 100% tillförlitlig eller om autentiseringssystemet inte är 100% tillförlitligt kan det vara mycket svårt för systemet att vara 100% tillförlitligt.
Det andra knepiga med att uppnå ett mål på 100% tillförlitlighet är att det betyder ingen stilleståndstid. Det innebär också noll chans att göra ändringar som du tror kan skapa driftstopp. Du får ingen frihet, något du förmodligen kommer att vilja ha och behöva.
Det är användbart att börja tänka på saker ur perspektivet "vad är rätt tillförlitlighetsnivå?" för en viss sak som du försöker använda. För att ta tillbaka detta till det aktuella ämnet måste vår övervakning stödja det här målet.
Med dessa två ramar i åtanke, låt oss bli praktiska och se några verktyg som hjälper oss att uppnå våra mål.