Gestione degli incidenti per più di 10 team interfunzionali

Questo articolo ha avuto origine sul blog di Mews Blog degli sviluppatori.

Durante la scalata della nostra organizzazione tecnologica, il più grande turno di paradigma è avvenuto intorno ai 20 sviluppatori. Prima di allora avevamo un unico team tecnico che si occupava di tutto. Le uniche distinzioni in questo team erano per funzione: sviluppatori backend, sviluppatori frontend, ecc. Le diverse funzioni avevano metodi distinti di registro, report degli errori e monitoraggio delle prestazioni. Alcuni strumenti erano condivisi, altri erano specializzati. Tuttavia, la gestione di questa pila era piuttosto semplice a causa della sua natura finita e fissa. Con la trasformazione in più team interfunzionali (attualmente 13), non si tratta più solo di costruire la "macchina" (il prodotto) ma di costruire una "macchina" che costruisce "macchine" (team che costruiscono prodotti).

Una parte importante di questa "macchina" di ordine superiore è il quadro di gestione degli incidenti. Per me è uno degli indicatori della maturità dell'organizzazione tecnica ed è una delle mie domande preferite ai colloqui. Per incidenti intendo tutte le eccezioni non gestite, gli errori, le interruzioni, i problemi di prestazioni, i problemi di sicurezza e qualsiasi altra cosa ti venga in mente. Non solo direttamente nel prodotto, ma anche nell'attrezzatura circostante. Abbiamo dovuto affrontare diversi problemi tipici di molte altre compagnie:

• Non catturare tutti gli incidenti, non vederli e aspettare che siano i clienti a segnalarli.
• Cattura gli incidenti ma li ignora per vari motivi.
• Non intervenire tempestivamente sugli incidenti in base alla loro gravità.
• Generando molti falsi positivi.
• Avere più strumenti per cercare gli incidenti.
• Non disponendo di dati e informazioni sufficienti per capire quanto sia grande il problema di un incidente.

In questo articolo descriverò come abbiamo progettato il nostro nuovo processo di gestione degli incidenti, affrontato tutti questi problemi e implementato la soluzione tecnica.

Requisiti

Quando abbiamo progettato il nuovo flusso di lavoro, abbiamo definito diversi requisiti e vincoli basati sulla nostra precedente esperienza e sui problemi che abbiamo affrontato. Il nostro primo obiettivo era che la consegna degli incidenti fosse estremamente mirata, ovvero che i problemi venissero consegnati al gruppo di persone che con ogni probabilità ne sono responsabili e che hanno il potere e le conoscenze per risolverli. Se ciò non accadesse, entrerebbe in gioco l'effetto passante. Pertanto, per ogni incidente è necessario specificare il team di appartenenza e la sua funzione all'interno del team. Questo ha ristretto i destinatari da tutta l'organizzazione a poche persone.

Ogni squadra dovrebbe avere un unico luogo dove cercare tutti gli incidenti.

Il secondo requisito importante per noi era la tracciabilità e l'azione. In parole povere, non volevamo che gli incidenti fossero solo voci in una piattaforma di registro, notifiche Slack o email di notifica, perché non c'è alcuna garanzia che qualcuno li guardi o agisca. Non è facile fare un report sul loro numero, sui tempi di risoluzione o su altri fattori, se alcuni di essi rimangono irrisolti più a lungo del dovuto, ecc.

Essere il responsabile tecnico di un team è uno dei ruoli più difficili, quindi abbiamo voluto rendere il flusso di lavoro degli incidenti molto dipendente da loro. Alla fine, i responsabili tecnici sono responsabili della risoluzione degli incidenti all'interno dei loro team. E dato che i nostri team sono interfunzionali, non volevamo che i responsabili tecnici dovessero utilizzare molti strumenti diversi solo per avere un quadro generale di ciò che accade nei loro team.

Immagazzinamento

In ordine all'azione e alla tracciabilità, abbiamo deciso fin dall'inizio che tutti gli incidenti devono essere archiviati nel nostro sistema di tracciamento dei problemi, YouTrack. La maggior parte degli incidenti sono problemi che non sono ancora stati segnalati da un dipendente finale, quindi non ha senso tenerli separati dagli errori segnalati. Inoltre, disponiamo di flussi di lavoro, avvisi e report piuttosto potenti costruiti sulla base di YouTrack, quindi volevamo riutilizzarli. Tenendo traccia degli incidenti, otteniamo dati più precisi su ciò che i team dedicano al tempo. Inoltre, su Slack nulla va perso nello spam o viene trascurato e gli sviluppatori hanno un unico posto dove cercare i loro prodotti. Inoltrare tutti gli incidenti in un software di tracciamento dei problemi può spaventare all'inizio, soprattutto se sono molti, quindi consigliamo un rollout morbido, dando ai team un po' di tempo per prepararsi all'afflusso.

Inviare tutti gli incidenti direttamente al software di tracciamento delle emissioni non sarebbe comunque una mossa intelligente, dato che non ci sono limiti di tariffa, ad esempio. Ecco perché impieghiamo Sentry come un "lavandino" per tutti gli incidenti che si trova di fronte a YouTrack e lo protegge dalle inondazioni. Stiamo sfruttando soprattutto la deduplicazione, la limitazione della tariffa e le regole di avviso. Non ha senso segnalare ogni singola occorrenza dello stesso errore, né ha senso segnalare la prima occorrenza di un avviso. Questo viene controllato da regole di avviso basate sul tipo di incidente (errore, avviso, fatale), sull'ambiente (produzione, staging, sviluppo), sul numero di eventi e su altri criteri.

Archiviazione degli incidenti in Sentry ed escalation al tracker dei problemi.

Per ogni combinazione di team, funzione e, opzionalmente, prodotto, esiste un progetto Sentry. Puoi facilmente scegliere i progetti a cui sei interessato, in modo da poterli suddividere in base a queste dimensioni e creare "viste" per il team lead (selezionando tutti i progetti che coinvolgono il team) o per il function lead (selezionando tutti i progetti che includono, ad esempio, il frontend). Il motivo di questa granularità è che teniamo traccia anche delle distribuzioni e delle versioni dei prodotti per individuare quando uno sviluppo causa un'ondata di errori. Sentry lo consente su base individuale, il che ci costringe a segregarlo, anche se questo introduce un certo sovraccarico operativo.

Collezione

Le origini principali degli incidenti sono due: le nostre applicazioni e gli altri strumenti e sistemi. Raccogliere gli incidenti dalle nostre applicazioni è piuttosto semplice. Sentry fornisce SDK per la maggior parte delle piattaforme. Il nostro lavoro consiste nel determinare il team, la funzione e il prodotto di un incidente. La funzione e il prodotto sono semplici poiché è chiaro in quale app ha avuto origine l'incidente e quale funzione ne è responsabile.

Raccolta di incidenti da varie origini.

Il team è più complicato, soprattutto quando più team gestiscono un'unica applicazione. Abbiamo un'applicazione di backend monolitica con la maggior parte dei team che contribuiscono, quindi questo è un problema che abbiamo dovuto affrontare :) La nostra soluzione è stata quella di annotare tutte le transazioni nel sistema con il team proprietario a livello di codice. Così, ogni volta che il codice viene eseguito, è chiaro quale sia il team proprietario. Il team proprietario può essere definito su ambiti più ampi, ad esempio moduli o intere API, il che aiuta nella distribuzione iniziale dei proprietari. I team continuano a modificare le assegnazioni nel tempo, in modo che la proprietà converga verso uno stato stabile. Finché la squadra non viene divisa di nuovo, ovviamente.

Deviazione 1: le nostre applicazioni monolitiche sono in realtà piuttosto modulari, con una chiara proprietà di ogni singola riga di codice eseguibile. Cerchiamo di adottare gli aspetti migliori di entrambi gli approcci: la semplicità e le prestazioni dei monoliti con la chiara proprietà e l'isolamento dei microservizi.. La proprietà transazionale viene utilizzata non solo per gli incidenti, ma anche per la proprietà delle prestazioni o per iniziative di refactoring più ampie, quando ci chiediamo: "Chi deve refactorizzare questo endpoint?".

La seconda categoria di produttori di incidenti è costituita da altri strumenti e sistemi come New Relic, Azure Monitor, Azure DevOps, Rapid7 InsightOps, ecc. Questi strumenti di solito non supportano l'annotazione degli avvisi con metadati personalizzati e, pertanto, utilizziamo convenzioni di denominazione per distinguere il team e altri attributi. E poiché questi strumenti di solito non si integrano direttamente con Sentry, instradiamo i webhook attraverso un "middleware" di raccolta unificato costruito all'interno di Zapier che utilizziamo come semplice FaaS. A questo punto trasformiamo tutti i formati webhook proprietari in uno unificato, estraiamo team, funzione e prodotto dal nome dell'avviso e inoltriamo l'incidente a Sentry.

Notifiche

L'ultima parte, la più semplice, la più visibile (e per alcuni la più fastidiosa) è il sistema di notifiche. Quando un problema viene sollevato o escalation nel nostro software di tracciamento dei problemi, un flusso di lavoro lo rileva e invia un webhook a Zapier. In base a vari criteri, distribuiamo le notifiche a diversi canali. Sempre in un canale Slack del team responsabile, a volte in un canale più generale e, per gli incidenti più gravi, in PagerDuty.

Parte di notifica del flusso di lavoro.

Deviazione 2: avrai notato che usiamo molto Zapier. Non è una coincidenza e, anche se due dei nostri strumenti hanno un'integrazione diretta, noi inoltriamo la comunicazione attraverso Zapier. Questo ci permette di avere un unico luogo in cui indagare sulla comunicazione tra tutti i nostri sistemi, il che ci aiuta enormemente nel debugging dei flussi di lavoro più avanzati. Non tutti gli strumenti hanno una grande visibilità sui webhook in uscita, sulla loro storia o sul motivo per cui alcuni non sono andati a buon fine. Zapier lo prevede. Puoi ispezionare i payload, le trasformazioni, le risposte dei destinatari e così via. Scrivere una semplice funzione JavaScript che viene attivata da un webhook ed esegue un'azione basata sui dati in arrivo è un gioco da ragazzi. Zapier può essere inteso come un host, un IDE e un debugger per queste funzioni. Non sono sicuro che questa fosse l'intenzione originaria dei suoi autori, ma questo caso d'uso funziona molto bene per noi.

Risultati

Abbiamo già molte idee su cosa possiamo migliorare in ogni fase del flusso di lavoro. Da descrizioni dei problemi più belle e regole di avviso più intelligenti e granulari a notifiche migliori con destinatari ancora più ristretti, regole di escalation e SLO sui tempi di risoluzione. Tuttavia, anche senza questi vantaggi, il flusso di lavoro "base" per gli incidenti ha portato diversi benefici alla nostra organizzazione:

• Ora disponiamo di dati chiari, consolidati e completi sui nostri incidenti, che ci permettono di prendere decisioni basate sui dati.
• Il modo in cui segnaliamo gli errori o le eccezioni non gestite continua a migliorare, i team deduplicano gli incidenti, eliminano i falsi positivi e introducono nuovi incidenti che in precedenza venivano ignorati.
• Grazie a un'unica origine della verità, possiamo individuare rapidamente se un team è alle prese con un sovraccarico di incidenti e chiedere aiuto.
• Abbiamo una visione molto più chiara della qualità dei nostri sviluppi grazie alla correlazione con gli incidenti.
• Il flusso di lavoro è preconfigurato per tutti i team e le funzioni e viene fornito come servizio della piattaforma. Richiede circa 5 minuti quando viene presentata o rinominata una nuova squadra.
• È facilmente estensibile implementando nuovi raccoglitori di incidenti per nuovi strumenti in Zapier.
• Nessun incidente viene "perso nella traduzione", il che si traduce in un prodotto di qualità migliore e in tempi di risoluzione più rapidi, a sostegno della nostra visione di raggiungere l'eccellenza tecnica.

Una vista dall'elicottero dell'intero flusso di lavoro.

Speriamo che questa panoramica ti dia qualche spunto per migliorare il tuo processo di gestione degli incidenti. E, viceversa, ci piacerebbe sapere cosa stai facendo meglio o cosa potremmo migliorare. Oppure, se vuoi che approfondisca qualche parte dell'articolo, fammi sapere anche questo!