Dziiiiin! Sono le 3 del mattino, stai facendo un sogno meraviglioso e all'improvviso ricevi una chiamata. Sei di turno questa settimana e a quanto pare è successo qualcosa. Il sistema automatizzato chiama per scoprire cosa c'è che non va. Questo è un aspetto importante della gestione dei moderni sistemi informatici, ma diamo un'occhiata a come migliorare le notifiche per le persone.
Acquisisci familiarità con la filosofia di monitoraggio, nata nel corso di diversi decenni di lavoro in diversi team di monitoraggio. È stata in gran parte influenzata dalla vera Bibbia di Rob Evashchuk (My Notification Philosophy) incluso nel libro su e libro di John Alspaugh (Note sull'impostazione degli avvisi).
, и — grazie per il tuo aiuto nella modifica del post.
Cos'è CASO?
Ho deciso di inventare una bellissima abbreviazione come o . Lo chiamo Metodo CASO. Descrive quattro punti a cui prestare attenzione quando si lavora con il monitoraggio automatico:
- (legato al contesto)
- (valore pratico)
- (enfasi sui sintomi)
- (grado)
Se usi CASE, tratti le notifiche con una sana indifferenza e non svegli le persone di notte. Il monitoraggio dovrebbe essere regolarmente valutato per quanto riguarda l’utilità e l’efficacia. Quando una persona riceve la notifica, avrà modelli mentali migliori e maggiore sicurezza.
Per renderlo più facile da ricordare, immagina di aver bisogno di un CASO [cioè un caso, un motivo - nota del traduttore] per giustificare ogni avviso. :occhiali da sole:
E perché tutto questo?
. Per molte ragioni. E CASE non li eliminerà tutti. Ma con esso, ti sveglierai di notte con notifiche migliori. Questo metodo copre vari processi organizzativi che aiuteranno anche in questa materia.
La bellezza dei metodi RED e USE è che con il loro aiuto non solo sappiamo come lavorare, ma parliamo anche la stessa lingua tra loro. La mia speranza è che il metodo CASE semplifichi la discussione sulle notifiche che proteggono i nostri sistemi ma tengono occupati i nostri colleghi.
Il punto è che devi creare una cultura nella tua organizzazione in cui le notifiche vengono trattate con una sana indifferenza. Le notifiche possono essere create per uno scopo specifico, ma non è un dato di fatto che non perderanno valore in seguito. Perché abbiamo impostato questa notifica? Da quanto tempo sono stati rivisti i suoi criteri? Con CASE è possibile rispondere a queste domande.
Contesto pesante: associazione al contesto
Le 3 del mattino non sono il momento migliore per leggere messaggi che contengono molte parole intelligenti. Per rispondere in modo efficace, hai bisogno di informazioni. Idealmente, queste dovrebbero essere informazioni su un problema specifico, per il quale il contesto sia immediatamente chiaro, e le notifiche dovrebbero essere configurate in modo che ciò sia possibile. Questa è "osservazione" e "orientamento" da . Non è un peccato dedicare del tempo a questa configurazione, perché distrarre costantemente una persona è ancora più costoso. Rispettiamoci a vicenda.
I problemi hanno molte origini. Soprattutto fantasmi.
Come posso aiutare l'ufficiale di turno? La prima cosa che vede l'ufficiale di servizio è una notifica, quindi sulla base di essa costruisce tutte le ipotesi. Quindi esamina le istruzioni e le dashboard, ma ci sono sempre dati su una notifica specifica e non solo informazioni generali? Alspaugh consiglia di “pensare a come potresti interpretare o rispondere alla notifica” (diapositiva 29). Una buona notifica è focalizzata sulla persona di turno, non solo configurata da una soglia.
Ecco quindi alcune idee su come migliorare il contesto delle notifiche:
- Mostra all'utente qualcosa di utile e creato appositamente, e non solo normali istruzioni o una dashboard. In precedenza, io e i ragazzi utilizzavamo dashboard investigativi configurati per notifiche specifiche. Ciò aiuterà se il problema è noto, ma confonderà solo gli altri. Dobbiamo trovare un equilibrio qui.
- Raccontaci la storia della notifica: è nuova? Funziona spesso? È stagionale?
- Mostra le modifiche recenti allo stato del sistema. È cambiato qualcosa di recente? (Ad esempio, distribuzione o abilitazione/disabilitazione della funzionalità.)
- Mostrare le relazioni e fornire informazioni per il modello mentale: le dipendenze del sistema dovrebbero essere chiaramente visibili, preferibilmente con un'indicazione di funzionalità.
- Metti rapidamente in contatto l'utente con il team: può vedere gli incidenti in corso o può scoprire chi altro in azienda ha ricevuto una notifica? Programma attivato?
Idealmente, un programma di gestione degli incidenti fornirà consigli su come migliorare il contesto di notifica delle indagini sugli incidenti. C'è sempre qualcosa su cui lavorare!
Azionabile: valore pratico
L'ufficiale di turno dovrebbe fare qualcosa in risposta alla notifica? Se non hai bisogno di fare nulla o non è chiaro cosa fare, perché l'hai svegliato? Bisogna evitare notifiche che infastidiscono chi è di turno e non richiedono alcun intervento.
Cosa dovrei fare? Cosa vuoi?
In passato, quando i sistemi erano semplici e i team erano piccoli, impostavamo il monitoraggio solo per rimanere aggiornati. La notifica che il carico sull'heap è aumentato ci fornirà il contesto se il servizio successivamente non funziona correttamente. Su larga scala, tali notifiche creeranno solo confusione perché i nostri sistemi operano sempre in uno stato di degrado di varia gravità. Questo porta rapidamente a e, naturalmente, alla perdita di sensibilità. Pertanto, l'ufficiale di turno ignora o addirittura filtra tali notifiche e non sempre risponde secondo necessità. Non cadere in questa trappola! Non impostare tutte le notifiche di seguito e poi inviarle via e-mail a qualche cartella dimenticata da Dio.
Ecco come si presenta un avviso con valore pratico:
- Una notifica richiede un'azione piuttosto che una semplice segnalazione di notizie.
- Questa azione è difficile o rischiosa da automatizzare. Se un'azione può essere automatizzata, automatizzala e smetti di infastidire le persone!
- L'avviso contiene raccomandazioni urgenti nel modulo (SLA) o (RTO). L'ufficiale di servizio può quindi attivare il programma di gestione degli incidenti dell'organizzazione.
Ci tengo a precisare: non sto dicendo che le notifiche debbano arrivare solo per gli SLO (obiettivi di livello di servizio) più importanti per le API. Il monitoraggio degli SLO è costantemente frammentato e diviso e richiede lo stesso approccio a tutti i servizi. È chiaro che monitorerai gli SLO più importanti per i clienti che ti pagano. Ma anche gli SLO delle infrastrutture, come i database, devono essere monitorati. Presto dovrai occuparti dei clienti interni e supportarli. E così via all'infinito.
Basato sui sintomi: enfasi sui sintomi
Che ti piaccia o no, stai lavorando in un sistema distribuito (Kavaj). Di conseguenza, si utilizzano tattiche diverse per isolare i servizi e proteggerli dai guasti (Trainor et al.)3. E sebbene una garbage collection ritardata o una query del database bloccata indichi problemi, non è necessario affrettarsi a risolverli se gli utenti non riscontrano problemi nel prossimo futuro.
Questi sono segnali importanti e possono avere valore pratico, ma se non disturbano gli utenti, non è sufficientemente urgente da distrarre l'addetto. Le notifiche basate sulla causa sono istantanee dei nostri modelli mentali su un guasto del sistema. È meglio tenere traccia dei sintomi importanti piuttosto che cercare di elencare tutte le possibili cause di un guasto.
Per rendere le notifiche significative, concentrati su , importante per gli utenti. Evashchuk lo chiama “monitoraggio per gli utenti”. Ricorda che questa filosofia deve essere applicata in tutta l'organizzazione. Se un servizio presenta problemi urgenti in qualche punto profondo dell’infrastruttura, il team appropriato se ne occuperà. Proteggere i sistemi da tali guasti è una questione completamente separata (Trainer et al., sezione sulle strategie per ridurre al minimo le dipendenze critiche).
I sintomi non sono così variabili
Richard Cook ci ricorda che i sistemi complessi sono pieni di difetti, carenze e problemi. Cercare di elencare tutte le possibili ragioni è un compito da Sisifo. Cerchi di descrivere i problemi, ma cambiano continuamente. Cindy Sridharan ritiene che “i sistemi non devono essere in perfette condizioni ogni secondo” ed è meglio utilizzare un approccio più umano ( ("Monitoraggio dei sistemi distribuiti"), 7).
Evita le notifiche dopo un incidente
In genere, le notifiche per le cause sono configurate per correggere gli incidenti. E queste notifiche limitate sull'accaduto creano un falso senso di sicurezza, perché il sistema ogni volta escogita nuovi modi per rompere.
Non lasciarti ingannare dagli avvisi di causa. Meglio pensare:
- Perché la notifica basata sui sintomi non ha rilevato il problema?
- Sarebbe utile migliorare il contesto per l'utente?
- Come si possono migliorare gli strumenti di monitoraggio per effettuare una diagnosi più velocemente, invece di accumulare notifiche su quanto accaduto?
Gli strumenti di monitoraggio per la diagnosi saranno utili solo se li consideri come un modo per passare dal sintomo alla soluzione. Senza questo feedback, sarai semplicemente bombardato da notifiche tardive e grafici sui fallimenti passati, e non una parola su quelli futuri. Questa è una grande opportunità per un'organizzazione di passare dalla difesa all'attacco. E sviluppatori e product manager avranno le stesse aspettative e obiettivi chiari. Il caso - CASE (:wink:) - è chiaro per ogni notifica.
Le notifiche basate sul motivo sono tollerabili con moderazione
A volte il nostro sistema ci lascia poca scelta in termini di notifiche basate sulla causa. E a volte chi è in servizio capisce perfettamente che un sintomo porterà sicuramente a un fallimento e quindi ha un valore pratico. Forse semplicemente non sei sicuro di cosa sta succedendo e stai impostando le notifiche per essere sicuro. Speriamo che questa azione sia temporanea finché non potremo modificare il sistema per risolvere il problema di prestazioni.
Tieni a mente gli altri componenti di CASE quando affronti queste situazioni. Solo perché è temporaneo non significa che puoi smettere di pensare con la tua testa.
Valutato - valutazione
Qualsiasi modifica al sistema (nuovo codice, nuova infrastruttura, qualsiasi cosa nuova) amplia la gamma di fallimenti (Cook, 3). Questa notifica funziona ancora come previsto? Modelli mentali chiari e attuali di sistemi ed esperienza che rispondono ad alcune notifiche di supporto - queste sono le caratteristiche principali . I difetti nei sistemi sono in continua evoluzione e dobbiamo stare al passo con loro.
È necessario valutare costantemente la qualità di ciascuna notifica per garantire che funzionino come previsto. Cari leader! Sarà molto più semplice per i tuoi team se li aiuti a stabilire questo processo! Ecco alcuni spunti di valutazione:
- Utilizzare , o altri metodi di test delle notifiche. Il team può farlo da solo senza dover fare affidamento su un pesante sistema di gestione degli incidenti!
- Incorpora la raccolta di tutte le notifiche relative agli incidenti nel tuo programma di gestione degli incidenti. Contrassegna utile, dannoso, inappropriato, poco chiaro, ecc. Usali come feedback.
- Le notifiche giuste vengono attivate raramente e vengono testate attentamente. Assicurati che tutti i collegamenti funzionino, puntino al contesto giusto, ecc.
- Se una notifica non viene mai attivata o viene attivata troppo spesso, c'è qualcosa che non va. Risolvilo o rimuovilo. Attenzione alla passività o attività eccessiva!
- Imposta i timestamp delle notifiche con le date di scadenza. Se la data di scadenza è scaduta, valutare la notifica utilizzando il metodo CASE e aggiornare il timestamp. Proprio come il cibo, controlla regolarmente la data di scadenza.
- Semplifica il processo di miglioramento delle notifiche. Utilizza il monitoraggio come codice e archivia le notifiche in un repository Git. Le richieste pull aiutano a coinvolgere il team e forniscono una cronologia delle notifiche passate. E non avrai più paura di modificare le notifiche o di chiedere il permesso a chi ne è responsabile.
- Imposta il feedback per le notifiche, anche se è semplice , in modo che gli agenti di turno contrassegnino le notifiche come inutili o invadenti. Incorpora un collegamento o un invito all'azione nella notifica stessa e rivedi regolarmente il tuo feedback.
- Stabilisci una regola nella squadra: lascia che chi è in servizio lavori per semplificare il compito quando c'è poco lavoro. Possa tutto dopo di te essere un po' migliore di prima.
conclusione
Credo che il metodo CASE aiuti gli sviluppatori e le organizzazioni a discutere la configurazione e l'invio di notifiche automatizzate. Uno sviluppatore può iniziare a valutare le notifiche utilizzando il metodo CASE, quindi l'intera organizzazione si unirà ad altri sviluppatori, dirigenti e programmi di gestione degli incidenti per mantenere le notifiche in buone condizioni. Ciò non richiede strumenti speciali o processi complessi.
L'intero settore deve pensare al fattore umano durante il servizio senza sacrificare un servizio clienti di prim'ordine. Tutti questi strumenti e pratiche possono e devono essere migliorati. Spero che il metodo CASE possa aiutare in questo.
Goditi le notifiche migliorate!
Fonte: habr.com