Costruire un sistema resiliente: il nostro viaggio verso l'osservabilità in Intercom

In Intercom ci concentriamo soprattutto sull'esperienza del cliente: la disponibilità e le prestazioni del nostro servizio sono la nostra massima priorità. Ciò richiede una forte cultura dell'osservabilità in tutti i nostri team e sistemi.

Di conseguenza, investiamo molto nell'affidabilità della nostra applicazione. Ma i fallimenti imprevedibili sono inevitabili e quando accadono sono gli esseri umani a risolverli.

Operiamo un sistema socio-tecnico e la sua capacità di riprendersi di fronte alle avversità si chiama resilienza. Una delle componenti cruciali della resilienza è l'osservabilità, i passi che adottiamo per consentire agli esseri umani di "guardare" all'interno dei sistemi che gestiscono.

Questo post esplorerà la strada per costruire una cultura più forte dell'osservabilità e le lezioni che abbiamo imparato lungo il percorso.

Cosa intendiamo per osservabilità in Intercom?

A Intercom, spediamo per imparare. Il nostro ambiente di produzione è il luogo in cui il nostro codice, l'infrastruttura, le dipendenze di terze parti ei nostri clienti si uniscono per creare una realtà oggettiva: è l'unico luogo in cui apprendere e convalidare l'impatto del nostro lavoro. Definiamo osservabilità come un processo continuo in cui gli esseri umani pongono domande sulla produzione e ottengono risposte*.

Analizziamolo un po' di più:

• Processo continuo: un'osservabilità riuscita significa che le persone osservano il più frequentemente possibile.
• Domande sulla produzione: volevamo che la nostra definizione fosse ampia, generica e rappresentativa dell'ampia portata dei flussi di lavoro di cui ci occupiamo.
• Risposte*: Nota l'asterisco. Nessuno strumento ti darà risposte, offri solo lead che puoi seguire per trovare le risposte reali. Devi usare i tuoi modelli mentali e la comprensione dei sistemi che gestisci.

Fase 1: problema e soluzione

Armati della nostra stessa definizione di osservabilità, abbiamo valutato le nostre pratiche esistenti e formulato una dichiarazione del problema. Fino a poco tempo, i nostri strumenti di osservabilità si basavano principalmente su metriche. Un flusso di lavoro tipico prevedeva l'esame di una dashboard piena di grafici con metriche suddivise e tagliate a dadini in base a varie combinazioni di attributi. La gente cercherebbe correlazioni, ma spesso se ne va senza soddisfare le intuizioni.

"Le metriche sono facili da aggiungere e comprendere, ma mancano attributi ad alta cardinalità (ad es. ID cliente), rendendo difficile il completamento di un'indagine"

Le metriche sono facili da aggiungere e comprendere, ma mancano di attributi ad alta cardinalità (ad es. ID cliente), rendendo difficile il completamento di un'indagine. In precedenza, una manciata di campioni dell'osservabilità continuava il flusso di lavoro utilizzando strumenti secondari (ad es. log, eccezioni, ecc.), cercando di accedere alle informazioni ad alta cardinalità e creare un quadro più completo. Quella capacità richiedeva una pratica costante: una richiesta irrealistica per la maggior parte degli ingegneri di prodotto che sono impegnati a fornire il prodotto.

Abbiamo identificato questa mancanza di consolidata esperienza di osservabilità come un problema da risolvere. Volevamo che fosse facile per chiunque porre una domanda arbitraria sulla produzione e ottenere informazioni dettagliate senza dover padroneggiare una serie di strumenti disconnessi, sottoconfigurati e costosi. Per mitigare il problema abbiamo deciso di raddoppiare la telemetria di traccia.

Un tipico dashboard operativo che abbiamo utilizzato prima di raddoppiare le tracce

Perché tracce?

Qualsiasi strumento di osservabilità è solo uno strumento con un essere umano dietro e gli esseri umani hanno bisogno di buone visualizzazioni. Non importa quale tipo di dati alimenta la visualizzazione, solo che lo strumento consente di passare senza problemi tra visualizzazioni diverse e ottenere prospettive alternative sul problema.

Le tracce hanno un enorme vantaggio rispetto ad altri dati di telemetria: codificano informazioni sufficienti sulle transazioni per alimentare praticamente qualsiasi visualizzazione. La creazione di flussi di lavoro di osservabilità sulle tracce garantisce un'esperienza consolidata e fluida senza la necessità di cambiare i dati sottostanti o lo strumento.

Alcuni dei tipi di visualizzazioni che possono essere alimentati da tracce

Fase 2: implementazione delle tracce

In Intercom iniziamo in piccolo, decidendo che aspetto ha il successo e monitorando i progressi lungo il percorso. Il nostro obiettivo principale era confermare che le tracce avrebbero reso più efficienti i flussi di lavoro di osservabilità. Per questo, dovevamo portare le tracce nelle mani degli ingegneri il prima possibile.

"Invece di strumentare la nostra applicazione con tracce da zero, abbiamo utilizzato una libreria di tracciatura esistente che si trovava già nelle dipendenze"

Per risparmiare tempo, abbiamo utilizzato il nostro fornitore esistente, Honeycomb, per il nostro proof-of-concept. Avevamo già costruito un ottimo rapporto con loro mentre utilizzavamo il loro strumento per eventi strutturati in passato.

Invece di strumentare la nostra applicazione con tracce da zero, abbiamo utilizzato una libreria di tracce esistente che si trovava già nelle dipendenze ed eseguito una piccola regolazione per convertire i dati di traccia nel formato nativo Honeycomb. Abbiamo iniziato con un semplice campionamento deterministico, conservando circa l'1% di tutte le transazioni che abbiamo elaborato.

Consentire ai compagni di squadra di adottare le tracce

Spostare un'organizzazione verso le tracce non è un'impresa da poco. Le tracce sono più complesse delle metriche o dei log e hanno una curva di apprendimento ripida. Strumentazione, pipeline di dati e strumenti sono tutti importanti, ma la sfida più grande è consentire ai tuoi compagni di squadra di massimizzare l'uso delle tracce. Con il nostro proof-of-concept in produzione, abbiamo immediatamente iniziato a concentrarci sulla costruzione di una cultura dell'osservabilità.

"Non ci siamo concentrati solo sugli ingegneri: abbiamo parlato con direttori, responsabili del programma tecnico, membri del team di sicurezza e rappresentanti dell'assistenza clienti per sottolineare come le tracce potrebbero aiutarli a risolvere i loro problemi specifici"

Trovare alleati è stata la chiave del successo. Abbiamo riunito un gruppo di campioni che erano già abili nell'osservabilità. Hanno contribuito a confermare le nostre ipotesi e a spargere la voce sulle tracce all'interno dei loro team. Ma non ci siamo concentrati solo sugli ingegneri: abbiamo parlato con direttori, responsabili del programma tecnico, membri del team di sicurezza e rappresentanti dell'assistenza clienti per sottolineare come le tracce potrebbero aiutarli a risolvere i loro problemi specifici.

Personalizzare il nostro messaggio ha aiutato a bloccare il supporto. L'introduzione di nuovi strumenti comporta sempre un certo rischio: dimostrando il potenziale e suscitando l'entusiasmo delle persone, abbiamo aumentato le nostre possibilità di successo.

Fase 3: Decidere il fornitore giusto

Con l'avvio del programma di abilitazione, abbiamo iniziato a esaminare i moderni fornitori incentrati sulla traccia e formulato una serie di criteri in base ai quali valutare i potenziali candidati.

Flussi di lavoro: abbiamo identificato il flusso di lavoro esplorativo come il più importante: consentirebbe agli ingegneri di suddividere arbitrariamente i dati di produzione e ottenere informazioni dettagliate tramite visualizzazioni e attributi ad alta cardinalità. Una parte importante della diagnosi di un problema è essere in grado di individuarlo, e ciò significa capire che aspetto ha "normale". Volevamo consentire agli ingegneri di esplorare facilmente la produzione ponendo domande il più frequentemente possibile, non solo quando sorgono problemi.

"Volevamo il pieno controllo sul modo in cui i dati sarebbero stati campionati e conservati"

Controlli di campionamento e conservazione : volevamo il pieno controllo sul modo in cui i dati sarebbero stati campionati e conservati. Il campionamento deterministico ci ha aiutato a essere operativi rapidamente, ma volevamo essere più selettivi e conservare più tracce "interessanti" (ad es. errori, richieste lente) utilizzando il campionamento dinamico intelligente rimanendo al di sotto del limite del contratto.

Visualizzazioni accurate dei dati : volevamo assicurarci che, qualunque sia la tecnica di campionamento utilizzata, gli strumenti di osservabilità la gestissero in modo trasparente esponendo i numeri approssimati "veri" nelle visualizzazioni. Ogni fornitore ha affrontato questo problema in modo diverso: alcuni richiedono l'invio di tutti i dati a un aggregatore globale per dedurre le metriche per indicatori chiave come tasso di errore, volume, ecc. Questa non era un'opzione per noi dato l'enorme volume di dati generato dalla nostra ricca strumentazione.

Prezzi : volevamo uno schema di prezzi semplice e prevedibile che fosse correlato al valore che otterremmo dallo strumento. L'addebito per la quantità di dati conservati ed esposti sembrava equo.

Metriche di coinvolgimento: volevamo che il fornitore fosse un buon partner e ci aiutasse a monitorare l'adozione e l'efficacia dello strumento esponendo le metriche di utilizzo chiave ei livelli di coinvolgimento.

Non esiste un fornitore perfetto, quindi preparati a scendere a compromessi. Alla fine, abbiamo concluso che Honeycomb non solo ha funzionato meglio per il flusso di lavoro principale che avevamo identificato, ma ha anche spuntato le caselle su campionamento, prezzi e metriche di utilizzo, quindi abbiamo evitato la costosa migrazione del fornitore.

Dopo un anno di lavoro impegnativo, avevamo completato la parte tecnica del programma di osservabilità. Questo è ciò che abbiamo ottenuto:

• La nostra principale applicazione monolitica era stata auto-strumentata con tracce ricche di attributi di alta qualità.
• Gli ingegneri disponevano di una piccola serie di metodi convenienti per aggiungere strumentazione personalizzata al loro codice.
• Abbiamo implementato Honeycomb Refinery per campionare i dati in modo dinamico e conservare più tracce "interessanti". Abbiamo incoraggiato gli ingegneri a configurare regole di conservazione personalizzate per un controllo più granulare. Per le transazioni di maggior valore, e quando economicamente fattibile, abbiamo offerto una conservazione del 100% per fornire alle persone i dati di cui avevano bisogno.

Fase 4: aumentare l'adozione

Dopo aver scelto Honeycomb e aver completato il lavoro sulla pipeline di dati, abbiamo spostato la nostra attenzione sull'abilitazione. Per costruire una cultura dell'osservabilità, devi rendere facile per le persone salire a bordo. Ecco alcuni dei modi in cui abbiamo aiutato i team ad adottare nuovi strumenti di osservabilità:

Tracciamento nell'ambiente di sviluppo

Per familiarizzare gli ingegneri con la strumentazione di tracciamento e incoraggiarli ad aggiungerla al loro codice, abbiamo offerto la traccia opzionale dall'ambiente di sviluppo locale con le tracce esposte in Honeycomb. Ciò ha aiutato le persone a visualizzare la nuova strumentazione personalizzata esattamente nello stesso modo in cui la vedrebbero quando il codice raggiungesse la produzione.

I log possono essere difficili da leggere e interpretare, mentre le viste di traccia sono molto più strutturate e organizzate

Scorciatoie per le query di Slackbot

Quando la produzione è in difficoltà, l'ultima cosa che vuoi è dover cercare la query giusta. Abbiamo aggiunto una reazione personalizzata del bot a un messaggio "mostrami prestazioni web". Seguendo il collegamento Slackbot si aprono le prestazioni degli endpoint Web suddivise per servizio.

Semplifichiamo il nostro flusso di lavoro di osservabilità con uno Slackbot che fornisce una scorciatoia a una query popolare all'interno dei nostri strumenti di osservabilità

Fase 5: Riflessioni e passi successivi

Misurare l'adozione

Misurare il ritorno dell'investimento (ROI) sugli strumenti di osservabilità è impegnativo. Il monitoraggio del numero di utenti attivi è un buon indicatore della frequenza con cui gli ingegneri interagiscono con gli strumenti e abbiamo beneficiato molto delle metriche di utilizzo di Honeycomb.

Questo grafico mostra l'aumento del numero di utenti Honeycomb attivi dall'inizio dell'abilitazione dell'osservabilità

Siamo andati oltre e abbiamo misurato l'utilità di quegli impegni. Abbiamo postulato che se le informazioni acquisite dagli strumenti di osservabilità fossero state preziose, le persone le avrebbero condivise con i loro colleghi. I nostri flussi di lavoro di progettazione dipendono fortemente dai problemi di Github, quindi abbiamo deciso di contare il numero di problemi o di richieste pull in cui Honeycomb è stato menzionato o collegato (traccia, risultato della query, ecc.) come proxy per una metrica di adozione. Poiché abbiamo raddoppiato l'abilitazione verso la fine del 2021, abbiamo osservato un'esplosione nel numero di problemi che menzionavano Honeycomb, dimostrando che eravamo sulla strada giusta.

Grafico a barre che mostra il numero di problemi GitHub in cui Honeycomb è menzionato nel titolo o nella descrizione

Flussi di lavoro inaspettati

Costruire una solida base di osservabilità ha consentito flussi di lavoro che non avremmo potuto immaginare prima. Ecco alcuni dei nostri preferiti:

Programma di costo informativo : poiché tracciamo tutto il traffico e disponiamo di intervalli per query SQL, richieste Elasticsearch, ecc., possiamo esaminare i picchi nell'utilizzo di parti condivise separate della nostra infrastruttura (ad es. cluster di database) e attribuirli a un singolo cliente. Abbinando questi dati al costo dei singoli componenti dell'infrastruttura, possiamo inserire un prezzo approssimativo su ogni transazione che serviamo. L'osservabilità è diventata inaspettatamente una componente integrante del nostro programma sui costi delle infrastrutture.

Miglioramento dell'audit di sicurezza : essere in grado di conservare il 100% delle transazioni selezionate ci ha permesso di preservare tutte le interazioni con la nostra console dei dati di produzione, aiutando la sicurezza a stabilire una migliore visibilità sull'accesso ai dati dei nostri clienti.

Qual è il prossimo?

Costruire una cultura dell'osservabilità continuerà a far parte del nostro programma tecnico: ci concentreremo sul miglioramento del nostro materiale di bordo, sull'ulteriore tessitura dell'osservabilità tramite tracce nelle nostre operazioni di ricerca e sviluppo e sull'esplorazione della strumentazione front-end.

Interessato a far parte del nostro team? Dai un'occhiata ai nostri ruoli di ingegneria aperti qui.