Dziiiin! Het is drie uur in de ochtend, je hebt een prachtige droom en plotseling wordt er gebeld. Je hebt deze week dienst en blijkbaar is er iets gebeurd. Het geautomatiseerde systeem belt om erachter te komen wat er mis is. Dit is een belangrijk aspect van het beheer van moderne computersystemen, maar laten we eens kijken hoe we meldingen beter voor mensen kunnen maken.
Maak kennis met de monitoringfilosofie, ontstaan tijdens tientallen jaren van mijn taken in verschillende monitoringteams. Ze werd grotendeels beïnvloed door de echte bijbel van Rob Evashchuk (Mijn Meldingsfilosofie) opgenomen in het boek over , en boek van John Alspaugh (Opmerkingen over het instellen van waarschuwingen).
, и — bedankt voor je hulp bij het bewerken van het bericht.
Wat is CASE?
Ik besloot een mooie afkorting te bedenken, zoals of . ik noem het CASE-methode. Hij beschrijft vier punten waar je op moet letten bij het werken met automatische monitoring:
- (contextgebonden)
- (praktische waarde)
- (nadruk op symptomen)
- (cijfer)
Als je CASE gebruikt, behandel je meldingen met een gezonde onverschilligheid en maak je mensen 's nachts niet wakker. Monitoring moet regelmatig worden beoordeeld op nut en effectiviteit. Wanneer een persoon de melding ontvangt, heeft hij of zij betere mentale modellen en meer zelfvertrouwen.
Om het makkelijker te onthouden, stel je voor dat je een CASE nodig hebt [dat wil zeggen, een casus, een reden - notitie van de vertaler] om elke waarschuwing te rechtvaardigen. :zonnebril:
En waarom is dit allemaal?
. Om vele redenen. En CASE zal ze niet allemaal elimineren. Maar hiermee word je 's nachts wakker met betere meldingen. Deze methode omvat verschillende organisatieprocessen die hierbij ook zullen helpen.
Het mooie van de RED- en USE-methoden is dat we met hun hulp niet alleen weten hoe we moeten werken, maar ook dezelfde taal met elkaar spreken. Ik hoop dat de CASE-methode het gemakkelijker zal maken om meldingen te bespreken die onze systemen beschermen, maar onze collega's bezig houden.
Het punt is dat u in uw organisatie een cultuur moet creëren waarin meldingen met een gezonde onverschilligheid worden behandeld. Meldingen kunnen voor een specifiek doel worden aangemaakt, maar het is geen feit dat ze later geen waarde zullen verliezen. Waarom hebben we deze melding ingesteld? Hoe lang geleden zijn de criteria herzien? Met CASE kunnen deze vragen worden beantwoord.
Context-zwaar - contextbinding
3 uur is niet de beste tijd om berichten te lezen die veel slimme woorden bevatten. Om effectief te kunnen reageren, heb je informatie nodig. Idealiter gaat het om informatie over een specifiek vraagstuk, waarvan de context direct duidelijk is, en zijn de meldingen zo ingericht dat dit mogelijk is. Dit is "observatie" en "oriëntatie" van . Het is geen schande om tijd aan deze opstelling te besteden, want het voortdurend afleiden van iemand is nog duurder. Laten we elkaar respecteren.
Problemen hebben vele bronnen. Vooral geesten.
Hoe kan ik de dienstdoende officier helpen? Het eerste wat de officier van dienst ziet is een melding, dus op basis daarvan bouwt hij alle hypothesen op. Vervolgens kijkt hij naar instructies en dashboards, maar zijn er altijd gegevens over een specifieke melding, en niet alleen algemene informatie? Alspaugh adviseert “na te denken over hoe u de melding zou kunnen interpreteren of erop reageren” (dia 29). Een goede melding is gericht op de dienstdoende persoon en niet slechts op een drempel.
Hier zijn enkele ideeën over hoe u de meldingscontext kunt verbeteren:
- Laat de gebruiker iets nuttigs en speciaal gemaakt zien, en niet alleen gewone instructies of een dashboard. Voorheen gebruikten de jongens en ik onderzoeksdashboards die waren geconfigureerd voor specifieke meldingen. Dit helpt als het probleem bekend is, maar zal anderen alleen maar in verwarring brengen. We moeten hier een evenwicht vinden.
- Vertel ons over de geschiedenis van de melding: is deze nieuw? Werkt het vaak? Is het seizoensgebonden?
- Toon recente wijzigingen in de systeemstatus. Is er onlangs iets veranderd? (Bijvoorbeeld implementatie of functionaliteit in-/uitschakelen.)
- Laat de relaties zien en geef informatie voor het mentale model: systeemafhankelijkheden moeten duidelijk zichtbaar zijn, bij voorkeur met indicatie van functionaliteit.
- Verbind de gebruiker snel met het team: kunnen ze lopende incidenten zien of kunnen ze achterhalen wie nog meer binnen het bedrijf een melding heeft ontvangen? Programma geactiveerd?
Idealiter zal een incidentmanagementprogramma advies geven over hoe de meldingscontext van incidentonderzoeken kan worden verbeterd. Er is altijd wel iets om aan te werken!
Bruikbaar - praktische waarde
Moet de officier van dienst iets doen naar aanleiding van de melding? Als je niets hoeft te doen of als het onduidelijk is wat je moet doen, waarom heb je hem dan wakker gemaakt? U moet meldingen vermijden die de dienstdoende medewerkers irriteren en geen actie vereisen.
Wat moet ik doen? Wat wil je?
In het verleden, toen de systemen eenvoudig waren en de teams klein waren, hebben we monitoring opgezet om op de hoogte te blijven. Melding dat de belasting op de heap is toegenomen, geeft ons context als de dienst vervolgens niet meer werkt. Op grote schaal zullen dergelijke meldingen alleen maar verwarring veroorzaken, omdat onze systemen altijd in een staat van achteruitgang van verschillende ernst functioneren. Dit leidt al snel tot en natuurlijk verlies van gevoeligheid. Daarom negeert of filtert de dienstdoende officier dergelijke meldingen en reageert er niet altijd op als dat nodig is. Trap niet in deze val! Stel niet alle meldingen op een rij in en stuur ze vervolgens per e-mail naar een of andere godvergeten map.
Zo ziet een mededeling met praktische waarde eruit:
- Een melding vereist actie in plaats van alleen maar nieuws te melden.
- Deze actie is moeilijk of riskant om te automatiseren. Als een actie kan worden geautomatiseerd, automatiseer deze dan en stop met het lastigvallen van mensen!
- De aankondiging bevat dringende aanbevelingen in het formulier (SLA) of (RTO). De officier van dienst kan vervolgens het incidentmanagementprogramma van de organisatie activeren.
Ik wil dit verduidelijken: ik zeg niet dat meldingen alleen moeten komen voor de belangrijkste SLO's (service-level doelstellingen) voor de API. SLO-monitoring is voortdurend gefragmenteerd en verdeeld en vereist voor alle diensten dezelfde aanpak. Het is duidelijk dat u de belangrijkste SLO's bijhoudt voor de klanten die u betalen. Maar ook infrastructuur-SLO's, zoals databases, moeten worden gemonitord. Binnenkort krijg je te maken met interne klanten en deze te ondersteunen. En zo voort tot in het oneindige.
Symptoomgebaseerd: nadruk op symptomen
Of je het nu leuk vindt of niet, je werkt in een gedistribueerd systeem (Kavaj). Als gevolg hiervan gebruikt u verschillende tactieken om services te isoleren en te beschermen tegen storingen (Trainor et al.)3. En hoewel een vertraagde garbagecollection of een vastgelopen databasequery op problemen duidt, hoeft u zich niet te haasten om deze op te lossen als gebruikers in de nabije toekomst geen problemen ondervinden.
Dit zijn belangrijke signalen en kunnen praktische waarde hebben, maar als ze de gebruikers niet storen, zijn ze niet urgent genoeg om de begeleider af te leiden. Op oorzaken gebaseerde meldingen zijn momentopnamen van onze mentale modellen over een systeemstoring. Het is beter om belangrijke symptomen op te sporen dan alle mogelijke oorzaken van een storing op te sommen.
Om meldingen betekenisvol te maken, concentreert u zich op , belangrijk voor gebruikers. Evashchuk noemt dit ‘monitoring voor gebruikers’. Bedenk dat deze filosofie in de hele organisatie moet worden toegepast. Als een dienst ergens diep in de infrastructuur dringende problemen heeft, zal het juiste team deze oplossen. Het beschermen van systemen tegen dergelijke storingen is een geheel andere zaak (Trainer et al., sectie over strategieën voor het minimaliseren van kritische afhankelijkheden).
De symptomen zijn niet zo variabel
Richard Cook herinnert ons eraan dat complexe systemen vol gebreken, tekortkomingen en problemen zitten. Proberen alle mogelijke redenen op te sommen is een Sisyphean-taak. Je probeert problemen te beschrijven, maar ze veranderen voortdurend. Cindy Sridharan gelooft dat “systemen niet elke seconde in perfecte staat hoeven te zijn” en dat het beter is om een meer menselijke aanpak te hanteren ( (“Monitoring van gedistribueerde systemen”), 7).
Vermijd meldingen na een incident
Doorgaans worden meldingen voor oorzaken geconfigureerd om incidenten te corrigeren. En deze beperkte meldingen over wat er is gebeurd, creëren een vals gevoel van veiligheid, omdat het systeem elke keer weer nieuwe manieren bedenkt om te breken.
Laat u niet misleiden door aankondigingen van goede doelen. Denk beter:
- Waarom werd het probleem niet opgemerkt in de symptoomgebaseerde melding?
- Zou het nuttig zijn om de context voor de gebruiker te verbeteren?
- Hoe kunnen monitoringtools worden verbeterd om sneller een diagnose te stellen, in plaats van meldingen te verzamelen over wat er is gebeurd?
Monitoringinstrumenten voor diagnose helpen alleen als je ze beschouwt als een manier om van symptoom naar oplossing te gaan. Zonder deze feedback wordt u eenvoudigweg gebombardeerd met late meldingen en grafieken over mislukkingen uit het verleden, en geen woord over toekomstige mislukkingen. Dit is een geweldige kans voor een organisatie om van verdediging naar aanval over te gaan. En ontwikkelaars en productmanagers zullen dezelfde verwachtingen en duidelijke doelen hebben. Het geval - CASE (:wink:) - is voor elke melding duidelijk.
Op redenen gebaseerde meldingen zijn met mate toegestaan
Soms laat ons systeem ons weinig keus als het gaat om op oorzaken gebaseerde meldingen. En soms begrijpen degenen die dienst hebben heel goed dat een symptoom zeker tot een mislukking zal leiden en daarom praktische waarde heeft. Misschien weet u gewoon niet zeker wat er aan de hand is en stelt u voor de zekerheid meldingen in. Hopelijk is deze actie tijdelijk totdat we het systeem kunnen wijzigen om het prestatieprobleem op te lossen.
Houd de andere componenten van CASE in gedachten bij het omgaan met deze situaties. Het feit dat het tijdelijk is, betekent niet dat je kunt stoppen met denken met je hoofd.
Geëvalueerd - evaluatie
Elke wijziging aan het systeem (nieuwe code, nieuwe infrastructuur, alles wat nieuw is) vergroot het bereik van fouten (Cook, 3). Werkt deze melding nog steeds zoals verwacht? Duidelijke en actuele mentale modellen van systemen en ervaringen die reageren op enkele ondersteuningsmeldingen - dit zijn de belangrijkste kenmerken . Defecten in systemen evolueren voortdurend en we moeten ze bijhouden.
U moet de kwaliteit van elke melding voortdurend evalueren om ervoor te zorgen dat deze naar verwachting werkt. Beste leiders! Het zal veel gemakkelijker zijn voor uw teams als u hen helpt dit proces op te zetten! Hier zijn enkele beoordelingsideeën:
- Gebruiken , of andere meldingstestmethoden. Het team kan het zelf doen zonder afhankelijk te zijn van een zwaar incidentbeheersysteem!
- Neem de verzameling van alle incidentgerelateerde meldingen op in uw incidentbeheerprogramma. Markeer nuttig, schadelijk, ongepast, onduidelijk, enz. Gebruik ze als feedback.
- De juiste meldingen worden onregelmatig geactiveerd en zorgvuldig getest. Zorg ervoor dat alle links werken, naar de juiste context verwijzen, enz.
- Als een melding nooit of te vaak wordt geactiveerd, is er iets mis mee. Repareer het of verwijder het. Pas op voor buitensporige passiviteit of activiteit!
- Stel tijdstempels voor meldingen met vervaldatums in. Als de vervaldatum is verstreken, evalueer dan de melding met behulp van de CASE-methode en werk de tijdstempel bij. Controleer net als bij eten regelmatig de houdbaarheidsdatum.
- Vereenvoudig het proces van het verbeteren van meldingen. Gebruik monitoring als code en bewaar meldingen in een Git-repository. Pull-verzoeken helpen het team erbij te betrekken en geven u een geschiedenis van eerdere meldingen. En u bent niet langer bang om meldingen te wijzigen of toestemming te vragen aan degenen die daarvoor verantwoordelijk zijn.
- Stel feedback in voor meldingen, ook al is het eenvoudig , zodat dienstdoende ambtenaren meldingen als nutteloos of opdringerig markeren. Sluit een link of call-to-action in de melding zelf in en bekijk uw feedback regelmatig.
- Stel een regel vast in het team: laat degenen die dienst hebben, werken om de taak te vereenvoudigen als er weinig werk is. Moge alles na jou een beetje beter zijn dan voorheen.
Conclusie
Ik geloof dat de CASE-methode ontwikkelaars en organisaties helpt bij het bespreken van het opzetten en verzenden van geautomatiseerde meldingen. Eén ontwikkelaar kan beginnen met het beoordelen van meldingen met behulp van de CASE-methode, waarna de hele organisatie samen met andere ontwikkelaars, management- en incidentmanagementprogramma's de meldingen op peil houdt. Hiervoor zijn geen speciale gereedschappen of complexe processen nodig.
De hele sector moet tijdens haar dienst aan de menselijke factor denken, zonder dat dit ten koste gaat van de eersteklas klantenservice. Al deze instrumenten en praktijken kunnen en moeten worden verbeterd. Ik hoop dat de CASE-methode hierbij zal helpen.
Geniet van verbeterde meldingen!
Bron: www.habr.com