Dzin! Sono le 3 del mattino, stai sognando meravigliosamente e all'improvviso - squilla il telefono. Questa settimana sei in turno, e chiaramente qualcosa è successo. Il sistema automatizzato ti chiama per capire cosa stia accadendo. Questo è un momento cruciale nella gestione dei moderni sistemi informatici, ma vediamo come rendere le notifiche più accessibili per le persone.
Scopri la filosofia del monitoraggio, sviluppata in decenni di turni in vari team di monitoraggio. È stata in gran parte influenzata dalla vera Bibbia di Rob Evanchik. , inclusa nel libro di , e dal libro di John Olspow .
, e — grazie per l'aiuto nella revisione del post.
Cos'è il CASE?
Ho deciso di creare un acronimo accattivante, come quello del o Lo chiamo metodo CASE.Descrive quattro aspetti da considerare quando si lavora con il monitoraggio automatico:
- (legato al contesto)
- (valore pratico)
- (focus sui sintomi)
- (valutazione)
Se stai usando CASE, ti approcci alle notifiche con una sana indifferenza e non svegli le persone di notte. È importante rivalutare regolarmente il monitoraggio per garantirne l'utilità e l'efficacia. Quando una persona riceve una notifica, avrà migliori modelli mentali e maggior fiducia.
Per facilitare il ricordo, immagina di aver bisogno di un CASE [cioè un caso, una motivazione — traduzione del curatore], per giustificare ogni avviso. :sunglasses:
E perché tutto questo?
. Per molte ragioni. E CASE non risolverà tutti i problemi. Ma con esso, di notte, ti sveglierai con notifiche di miglior qualità. Questo metodo copre vari processi organizzativi che contribuiranno anch'essi a questo scopo.
Il bello dei metodi RED e USE è che ci permettono non solo di sapere come lavorare, ma anche di comunicare tra di noi in un linguaggio comune. Spero che con il metodo CASE sarà più semplice discutere delle notifiche che proteggono i nostri sistemi, ma che non danno pace ai colleghi.
La questione è che bisogna creare un ambiente nell'organizzazione dove le notifiche siano ricevute con una sana indifferenza. Le notifiche possono essere create per ragioni valide, ma non è detto che in seguito perdano valore. Perché abbiamo impostato questa notifica? Quando sono stati rivisti i suoi criteri? Con CASE è possibile trovare risposte a queste domande.
Contestualizzato — legato al contesto
Le 3 del mattino non sono il momento migliore per leggere messaggi pieni di parole complesse. Per rispondere in modo efficace, occorre avere informazioni. Idealmente, queste dovrebbero riguardare un problema specifico, in modo che il contesto sia immediatamente chiaro, e le notifiche dovrebbero essere impostate in modo da consentirlo. Questo è 'osservazione' e 'orientamento' da . Non è tempo sprecato per questa impostazione, perché distrarre una persona continuamente costa ancor di più. Rispettiamo reciproca mente.
I problemi hanno molte origini. Specialmente gli spettri.
Come può aiutare il personale in turno? Innanzitutto, il personale in turno vede una notifica, quindi tutte le sue ipotesi si basano su di essa. Poi guarda le istruzioni e i dashboard, ma ci sono sempre dati relativi a quella notifica specifica, e non solo informazioni generali? Olspo consiglia di "pensare a come interpretare o reagire alla notifica" (slide 29). Una buona notifica è orientata verso il personale in turno, non è solo impostata su un valore soglia.
Ecco quindi alcune idee per migliorare il contesto delle notifiche:
- Mostra all'utente qualcosa di utile e creato appositamente, non solo istruzioni generiche o un dashboard. In passato abbiamo utilizzato dashboard per indagini, impostate su notifiche specifiche. Questo aiuterà se il problema è noto, ma confonderà in altri casi. Qui bisogna trovare un equilibrio.
- Racconta la storia della notifica: è nuova? Si attiva spesso? È stagionale?
- Mostra le recenti modifiche nello stato del sistema. È cambiato qualcosa di recente? (Ad esempio, un deployment o l'attivazione/disattivazione di una funzionalità.)
- Mostra relazioni e fornisci informazioni per il modello mentale: le dipendenze del sistema devono essere chiaramente visibili, preferibilmente con indicazione della funzionalità.
- Collega rapidamente l'utente al team: può vedere gli incidenti attuali o scoprire chi altro in azienda ha ricevuto una notifica? È attivato il programma In ideale, il programma di gestione degli incidenti fornisce suggerimenti su come migliorare il contesto della notifica durante l'indagine sugli incidenti. C'è sempre spazio per migliorare!
Actionable — valore pratico
Il turno deve fare qualcosa in risposta alla notifica? Se non è necessario fare niente o non è chiaro cosa fare, perché svegliare qualcuno? È necessario evitare notifiche che disturbano i turni senza richiedere azioni.
Дежурный должен что-то сделать в ответ на уведомление? Если ничего не нужно делать или непонятно, что делать, зачем разбудили? Нужно избегать уведомлений, которые достают дежурных и не требуют действий.
Cosa si deve fare? Cosa serve?
Una volta, quando i sistemi erano semplici e i team piccoli, impostavamo il monitoraggio semplicemente per tenere traccia delle cose. Una notifica che l'uso della memoria è aumentato ci darà contesto se successivamente il servizio presenterà dei problemi. Su larga scala, tali notifiche confondono solo, poiché i nostri sistemi funzionano sempre in uno stato di degrado a vari livelli di severità. Questo porta rapidamente a e, ovviamente, alla perdita di sensibilità. Pertanto, il personale in servizio ignora o addirittura filtra tali notifiche e non risponde sempre come dovrebbe. Non cadere in questa trappola! Non impostare tutte le notifiche alla rinfusa, per poi inviarle via email in qualche cartella dimenticata da Dio.
Ecco come appare una notifica con valore pratico:
- La notifica richiede azione, non è solo un'informazione.
- Questa azione è difficile o rischiosa da automatizzare. Se l'azione può essere automatizzata, allora automatizzala e smettila di disturbare le persone!
- La notifica contiene raccomandazioni urgenti sotto forma di (SLA) o (RTO). In questo modo, il personale in servizio può attivare il programma di gestione degli incidenti nell'organizzazione.
Vorrei chiarire: non sto dicendo che le notifiche debbano arrivare solo per i SLO (service-level objectives, obiettivi di livello di servizio) più importanti per l'API. Il monitoraggio degli SLO è continuamente frammentato e distribuito e richiede un approccio uniforme per tutti i servizi. È evidente che monitorerete gli SLO più importanti per i clienti che vi pagano. Ma anche gli SLO dell'infrastruttura, come i database, devono essere monitorati. Presto vi troverete a gestire clienti interni e a supportarli. E così all'infinito.
Basato sui sintomi — focus sui sintomi
Che vi piaccia o no, state lavorando in un sistema distribuito (Kavadj). Di conseguenza, utilizzate diverse tattiche per isolare i servizi e proteggerli da guasti (Treynor et al.)3. E sebbene un garbage collection prolungato o una query al database in attesa indichino problemi, non è necessario precipitarsi a risolverli se non ci sono problemi per gli utenti nel prossimo futuro.
Questi sono segnali importanti e possono avere un valore pratico, ma se non disturbano gli utenti, non è così urgente da distrarre il personale in servizio. Le notifiche basate su cause sono istantanee dei nostri modelli mentali su un guasto di sistema. È meglio monitorare i sintomi rilevanti piuttosto che cercare di elencare tutte le possibili cause di un guasto.
Perché le notifiche abbiano un valore pratico, concentrati su , che sono importanti per gli utenti. Evashchuk chiama questo "monitoraggio per gli utenti". Ricorda che questa filosofia deve essere applicata in tutta l'organizzazione. Se si verificano problemi urgenti da qualche parte in profondità nell'infrastruttura di un servizio, verranno gestiti dal team appropriato. La protezione dei sistemi da tali guasti è una questione completamente separata (Trainer et al., sezione sulle strategie per minimizzare le dipendenze critiche).
I sintomi non sono così variabili
Richard Cook ricorda che nei sistemi complessi ci sono molte imperfezioni, difetti e problemi.. Cercare di elencare tutte le possibili cause è un lavoro di Sisifo. Stai cercando di descrivere problemi, ma cambiano continuamente. Cindy Shridharan crede che "i sistemi non debbano necessariamente essere in uno stato perfetto ogni secondo" e suggerisce di adottare un approccio più umano ( ("Osservabilità dei sistemi distribuiti"), 7).
Evita le notifiche per il semplice fatto che si è verificato un incidente
Di solito, vengono impostate notifiche per le cause per risolvere gli incidenti. Queste notifiche limitate sull’accaduto creano un falso senso di sicurezza, poiché il sistema trova continuamente nuovi modi per rompersi.
Non ingannarti con notifiche sulle cause. Pensa invece a:
- Perché la notifica basata sui sintomi non ha rilevato il problema?
- Sarebbe utile migliorare il contesto per l’utente?
- Come migliorare gli strumenti di monitoraggio per diagnosticare più rapidamente, anziché accumulare notifiche su quanto accaduto?
Gli strumenti di monitoraggio per la diagnosi sono utili solo se li considerate come un modo per passare dai sintomi alla soluzione. Senza questo feedback, vi troverete sommersi da notifiche tardive e grafici su guasti passati, senza alcun riferimento al futuro. Per un'organizzazione, questa è un'eccellente opportunità per passare dalla difesa all'attacco. E i developer e i product manager avranno aspettative chiare e obiettivi comprensibili. Il caso — CASE (:wink:) — per ogni notifica è chiaro.
Le notifiche basate su cause sono tollerabili in quantità moderata.
A volte il nostro sistema ci lascia quasi senza opzioni per quanto riguarda le notifiche basate su cause. Altre volte, i responsabili capiscono perfettamente che un sintomo porterà inevitabilmente a un guasto, e quindi ha un valore pratico. Potreste semplicemente non essere sicuri di cosa stia succedendo e impostare notifiche per sicurezza. Speriamo che questa azione sia temporanea, finché non modifichiamo il sistema per risolvere il problema delle prestazioni.
Ricordate gli altri componenti CASE quando affrontate situazioni del genere. Se è temporaneo, non significa che potete smettere di pensare.
Valutato — valutazione
Qualsiasi modifica nel sistema (nuovo codice, nuova infrastruttura, qualsiasi novità) amplia la gamma di guasti (Cook, 3). Questa notifica funziona ancora come previsto? Modelli mentali chiari e aggiornati dei sistemi e l'esperienza nella gestione di alcune notifiche di supporto sono caratteristiche chiave . I difetti nei sistemi si evolvono continuamente e dobbiamo tenerci al passo.
È fondamentale valutare costantemente la qualità di ogni notifica affinché funzioni come previsto. Cari dirigenti! Sarà molto più facile per i vostri team se li aiutate a stabilire 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!
- Includere la raccolta di dati su tutte le notifiche relative agli incidenti nel programma di gestione degli incidenti. Segnala quelle utili, dannose, inappropriate, poco chiare, ecc. Utilizzale come feedback.
- Le notifiche appropriate si attivano raramente e sono state attentamente verificate. Assicurati che tutti i link funzionino, puntino al contesto corretto, 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 né troppo passivo né troppo attivo!
- Imposta per le notifiche delle etichette temporali con una scadenza. Se la scadenza è scaduta, valuta la notifica con il metodo CASE e aggiorna l'etichetta temporale. Controlla regolarmente la scadenza, proprio come si fa con il cibo.
- Semplifica il processo di miglioramento delle notifiche. Usa il monitoraggio tramite 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 il permesso a chi ne è responsabile.
- Crea un feedback per le notifiche, anche se si tratta solo di , in modo che i turnisti possano contrassegnare le notifiche come inutili o invadenti. Inserisci nel messaggio stesso un link o una call to action e rivedi regolarmente il feedback.
- Stabilisci nella tua squadra una regola: lascia che i turnisti lavorino per semplificare i turni quando ci sono poche attività. Fai in modo che dopo di te tutto diventi un po' migliore rispetto a prima.
Conclusione
Credo che il metodo CASE aiuti sviluppatori e organizzazioni a discutere la configurazione e l'invio di notifiche automatiche. Un singolo sviluppatore può iniziare a valutare le notifiche utilizzando il metodo CASE, e poi tutta l'organizzazione, con altri sviluppatori, la direzione e i programmi di gestione degli incidenti, si unirà per mantenere le notifiche in buone condizioni. Non sono necessari strumenti speciali o processi complicati per questo.
L'intera industria dovrebbe riflettere sul fattore umano durante i turni, senza compromettere il servizio clienti di alta qualità. 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
