Dziiiiiin! È l'1 di notte, stai sognando magnificamente e all'improvviso - il telefono squilla. Questa settimana sei di turno, e evidentemente è successo qualcosa. Il sistema automatizzato ti chiama a capire di cosa si tratta. Questo è un momento importante nella gestione dei moderni sistemi informatici, ma vediamo come rendere le notifiche più comode per le persone.
Incontra la filosofia del monitoraggio, nata da decenni delle mie turnazioni in diverse squadre di monitoraggio. È stata influenzata in gran parte dalla vera bibbia di Rob Evasiuk. (My Philosophy on Alerting), inclusa nel libro su , e dal libro di John Olspaugh (Considerations for Alert Design).
, e — grazie per l'aiuto nella revisione del post.
Che cos'è CASE?
Ho deciso di inventare un bel acronimo, proprio come quello di o Lo chiamo metodo CASE.Descrive quattro aspetti da considerare quando si lavora con il monitoraggio automatizzato:
- (focalizzazione al contesto)
- (valore pratico)
- (focus sui sintomi)
- (valutazione).
Se usi CASE, ti approcci alle notifiche con una sana indifferenza e non svegli le persone di notte. È necessario valutare regolarmente il monitoraggio per l'utilità e l'efficacia. Quando una persona riceve una notifica, avrà migliori modelli mentali e maggiore fiducia.
Per facilitarne il ricordo, immagina che hai bisogno di un CASE [cioè un caso, motivo — note del traduttore] per giustificare ogni notifica. :sunglasses:
E perché tutto questo?
Per molte ragioni. E CASE non risolverà tutto. Ma con esso, la notte ti sveglierai da notifiche di migliore qualità. Questo metodo abbraccia vari processi organizzativi che aiuteranno anche in questo.
La bellezza dei metodi RED e USE è che ci permette non solo di sapere come lavorare, ma anche di comunicare tra di noi nella stessa lingua. Spero che con il metodo CASE sarà più facile discutere le notifiche che proteggono i nostri sistemi, senza dare fastidio ai colleghi.
La questione è creare all'interno dell'organizzazione una cultura in cui le notifiche siano trattate con un sano disinteresse. Le notifiche possono essere create per motivi validi, ma non è detto che successivamente non perdano valore. Perché abbiamo impostato questa notifica? Quando sono stati rivisti i suoi criteri? Con il CASE possiamo trovare risposte a queste domande.
Legato al contesto
Le 3 di notte non sono il momento migliore per leggere messaggi pieni di parole difficili. Per rispondere in modo efficace, è necessaria informazione. Idealmente, si trattarebbe di informazioni su un problema specifico, per cui il contesto è immediatamente chiaro, e le notifiche dovrebbero essere configurate in modo da permettere ciò. È l'«osservazione» e l'«orientamento» del . Non vale la pena risparmiare tempo su questa configurazione, perché distrarre una persona continuamente costa anche di più. Dobbiamo rispettarci a vicenda.
Un problema ha molte origini. Soprattutto fantasmi.
Come aiutare il turno? In primis, il turno vede la notifica, quindi tutte le ipotesi vengono costruite su quella base. Poi guardano le istruzioni e i dashboard, ma ci sono sempre dati specifici su quella notifica, anziché solo informazioni generali? Olspo consiglia di «pensare a come interpretare la notifica o rispondere ad essa» (slide 29). Una buona notifica è focalizzata sul turno, non è solo impostata in base a un valore soglia.
Ecco quindi alcune idee per migliorare il contesto delle notifiche:
- Mostrate all'utente qualcosa di utile e creato su misura, non solo istruzioni generiche o un dashboard. In passato, noi ragazzi utilizzavamo dashboard per indagini, configurate per notifiche specifiche. Questo aiuta se il problema è noto, ma può confondere in altri casi. Qui bisogna trovare un equilibrio.
- Raccontate la storia della notifica: è nuova? Si verifica spesso? È stagionale?
- Mostrate recenti cambiamenti nello stato del sistema. È cambiato qualcosa di recente? (Ad esempio, un deploy o l'attivazione/disattivazione di una funzionalità.)
- Mostrate le relazioni e fornire informazioni per un modello mentale: le dipendenze del sistema devono essere chiaramente visibili, preferibilmente con indicazioni sulla funzionalità.
- Collegate rapidamente l'utente al team: vede gli incidenti attuali o può sapere chi altro in azienda ha ricevuto la notifica? Il programma attivata?
Idealmente, il programma di gestione degli incidenti fornisce suggerimenti su come migliorare il contesto delle notifiche durante l'indagine sugli incidenti. C'è sempre margine di miglioramento!
Actionable — valore pratico
Il turno deve fare qualcosa in risposta alla notifica? Se non è necessario fare nulla o non è chiaro cosa fare, perché disturbare? Bisogna evitare avvisi che infastidiscono il turno e non richiedono azioni.
Cosa fare allora? Di cosa c'è bisogno?
In passato, quando i sistemi erano semplici e i team piccoli, configuravamo il monitoraggio solo per rimanere informati. Una notifica riguardante l'aumento del carico su un cluster ci fornirà contesto se poi il servizio presenta malfunzionamenti. In larga scala, tali notifiche creano solo confusione, poiché i nostri sistemi operano sempre in uno stato di degrado di varia gravità. Questo porta rapidamente a e, naturalmente, a perdita di sensibilità. Pertanto, il turno ignora o addirittura filtra tali notifiche, non sempre reagendo come dovrebbe. Non cadere in questa trappola! Non configurare tutte le notifiche in modo da spedirle poi in una cartella trascurata della posta.
Ecco come appare una notifica con valore pratico:
- La notifica richiede un'azione, non comunica solo notizie.
- Questa azione è difficile o rischiosa da automatizzare. Se l'azione può essere automatizzata, allora automatizzala, smettila di disturbare le persone!
- La notifica contiene raccomandazioni urgenti sotto forma di (SLA) oppure (RTO). Allora il turno può attivare il programma di gestione degli incidenti dell'organizzazione.
Voglio chiarire: non dico che le notifiche devono arrivare solo per i più importanti SLO (service-level objectives, obiettivi di livello di servizio) per API. Il monitoraggio degli SLO è costantemente suddiviso e richiede lo stesso approccio per tutti i servizi. È chiaro che monitorerai i SLO più importanti per i clienti che ti pagano. Ma anche gli SLO dell'infrastruttura, come quelli dei database, devono essere monitorati. Presto dovrai occuparti di clienti interni e supportarli. E così all'infinito.
Symptom-based — focus sui sintomi
Che ti piaccia o no, lavori in un sistema distribuito (Kavadj). Di conseguenza, utilizzi diverse tattiche per isolare i servizi e proteggerli da guasti (Treynor et al.) E sebbene una garbage collection prolungata o una query al database che si blocca indichino problemi, non è necessario affrettarsi a risolverli se gli utenti non stanno riscontrando problemi nel prossimo futuro.
Questi sono segnali importanti e possono avere un valore pratico, ma se non ostacolano gli utenti, non è così urgente da distrarre il custode. Le notifiche basate sulle cause sono istantanee dei nostri modelli mentali riguardo al guasto del sistema. È meglio monitorare sintomi importanti piuttosto che cercare di elencare tutte le possibili cause di un guasto.
Affinché le notifiche abbiano un valore pratico, concentrati su , importanti 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 parte profonda dell'infrastruttura, il team appropriato si occuperà di essi. La protezione dei sistemi da tali guasti è una questione completamente separata (Treynor et al., sezione sulle strategie per ridurre le dipendenze critiche).
I sintomi non sono così variabili
Richard Cook ricorda che nei sistemi complessi ci sono un sacco di difetti, mancanze e problemi. Cercare di elencare tutte le possibili cause è un lavoro di Sisifo. Stai cercando di descrivere i problemi, ma questi cambiano continuamente. Cindy Shridharan ritiene che «i sistemi non devono necessariamente trovarsi in uno stato ideale ogni secondo» e sarebbe meglio adottare un approccio più umano ( («Distributed Systems Observability»), 7).
Evita le notifiche in caso di incidente
Di solito, vengono impostate notifiche per le cause per risolvere gli incidenti. E queste limitate notifiche sull'accaduto creano un falso senso di sicurezza, poiché il sistema trova continuamente nuovi modi per rompersi.
Non ingannarti con le notifiche sulle cause. Pensa piuttosto a:
- Perché la notifica basata sui sintomi non ha individuato il problema?
- Sarebbe utile migliorare il contesto per l'utente?
- Come migliorare gli strumenti di monitoraggio per diagnosticare più rapidamente anziché accumulare avvisi sugli eventi accaduti?
Gli strumenti di monitoraggio per la diagnosi sono utili solo se li si considera come un modo per passare dai sintomi alla soluzione. Senza questo feedback, sarete semplicemente sommersi da notifiche tardive e grafici sui guasti passati—e né una parola sui futuri. Per le organizzazioni, è un'ottima opportunità per passare dalla difesa all'attacco. E per gli sviluppatori e i product manager ci saranno aspettative comuni e obiettivi chiari. Il caso—CASE (:wink:)—è chiaro per ogni notifica.
Le notifiche basate su cause sono tollerabili in un numero moderato.
A volte il nostro sistema ci lascia quasi senza scelta in termini di notifiche basate su cause. Altre volte, i turnisti comprendono perfettamente che un sintomo porterà necessariamente a un guasto, quindi ha un valore pratico. Forse non siete sicuri di cosa stia accadendo e impostate le notifiche per precauzione. Speriamo che questa azione sia temporanea, fino a quando non modificheremo il sistema per affrontare la questione delle prestazioni.
Ricordate gli altri componenti di CASE quando affrontate situazioni del genere. Se è temporaneo, non significa che si possa non pensare.
Evaluated — valutato
Qualsiasi modifica al sistema (nuovo codice, nuova infrastruttura, qualsiasi cosa nuova) espande il repertorio dei guasti (Cook, 3). Questa notifica funziona ancora come previsto? Modelli mentali chiari e pertinenti dei sistemi e l'esperienza nella risposta a determinate notifiche supportano — sono tratti chiave . I difetti nei sistemi si evolvono costantemente e dobbiamo star loro dietro.
È necessario valutare costantemente la qualità di ogni notifica affinché funzioni come previsto. Cari dirigenti! Per i vostri team sarà molto più facile se li aiutate a impostare questo processo! Ecco alcune idee per la valutazione:
- Usa , o altri metodi di test delle notifiche. Il team può farlo autonomamente, senza ricorrere a un pesante sistema di gestione degli incidenti!
- Attiva la raccolta dati su tutte le notifiche relative agli incidenti nel programma di gestione degli incidenti. Segna quelle utili, dannose, inopportune, poco chiare, ecc. Usale come feedback.
- Le notifiche corrette si attivano raramente e sono state accuratamente verificate. Assicurati che tutti i link funzionino e puntino al contesto giusto, ecc.
- Se una notifica non si attiva mai o si attiva troppo spesso, c'è qualcosa che non va. Riparala o rimuovila. Fai attenzione a non essere eccessivamente passivo o attivo!
- Imposta timbri temporali per le notifiche con una data di scadenza. Se la data di scadenza è superata, valuta la notifica con il metodo CASE e aggiorna il timbro temporale. Controlla regolarmente le scadenze, come faresti con il cibo.
- Semplifica il processo di miglioramento delle notifiche. Utilizza il monitoraggio basato su codice e conserva le notifiche in un repository Git. Le pull request aiutano a coinvolgere il team e avrai una cronologia delle notifiche passate. E smetterai di avere paura di modificare le notifiche o di chiedere permesso a chi se ne occupa.
- Stabilisci un feedback per le notifiche, anche se si tratta solo di una , affinché i turnisti possano contrassegnare le notifiche come inutili o invadenti. Incorpora nel messaggio stesso un link o una call to action e controlla regolarmente il feedback.
- Stabilisci una regola nel team: lascia che i turnisti lavorino per semplificare il turno quando c'è poco lavoro. Fai in modo che dopo di te tutto diventi un po' migliore rispetto a prima.
Conclusione
Ritengo che il metodo CASE aiuti gli sviluppatori e le organizzazioni a discutere la configurazione e l'invio delle notifiche automatiche. Un singolo sviluppatore può iniziare a valutare le notifiche secondo il metodo CASE e poi unirsi a lui l'intera organizzazione, con altri sviluppatori, la direzione e i programmi di gestione degli incidenti, per mantenere le notifiche in buone condizioni. Non sono necessari strumenti speciali o processi complessi.
L'intero settore dovrebbe riflettere sul fattore umano durante i turni, senza compromettere un servizio clienti di prima classe. Tutti questi strumenti e pratiche possono e devono essere migliorati. Spero che il metodo CASE possa aiutare in questo.
Goditi notifiche migliorate!
Fonte: habr.com
