Charity Majors, CTO & Co-Founder at Honeycomb – Intervista della serie

Charity è un ingegnere di operazioni e fondatore di startup accidentale presso Honeycomb. Prima di questo, ha lavorato presso Parse, Facebook e Linden Lab su infrastrutture e strumenti per sviluppatori, e ha sempre finito per gestire i database. È coautrice di Database Reliability Engineering di O’Reilly, e ama la libertà di parola, il software libero e il whisky single malt.

Eravate il Production Engineering Manager di Facebook (ora Meta) per oltre 2 anni, quali sono stati alcuni dei punti salienti di questo periodo e quali sono alcune delle vostre considerazioni chiave su questa esperienza?

Ho lavorato su Parse, che era un backend per app mobili, un po’ come Heroku per mobile. Non avevo mai avuto interesse a lavorare in una grande azienda, ma siamo stati acquisiti da Facebook. Una delle mie considerazioni chiave è stata che le acquisizioni sono veramente, veramente difficili, anche nelle circostanze migliori. Il consiglio che do sempre ad altri fondatori è questo: se siete sul punto di essere acquisiti, assicuratevi di avere un sponsor esecutivo e pensate attentamente se avete un allineamento strategico. Facebook ha acquisito Instagram poco prima di acquisire Parse, e l’acquisizione di Instagram non è stata affatto facile, ma alla fine è stata molto efficace perché avevano un allineamento strategico e un forte sponsor.

Non ho avuto un periodo facile a Facebook, ma sono molto grata per il tempo che ho trascorso lì; non so se avrei potuto fondare una società senza le lezioni che ho imparato sulla struttura organizzativa, la gestione, la strategia, ecc. Mi ha anche dato una reputazione che mi ha reso attraente per i venture capitalist, nessuno dei quali mi aveva dato il tempo di giorno fino a quel momento. Sono un po’ seccata per questo, ma lo accetterò comunque.

Potreste condividere la storia della genesi dietro il lancio di Honeycomb?

Certo. Da un punto di vista architettonico, Parse era avanti per il suo tempo – stavamo utilizzando microservizi prima che esistessero i microservizi, avevamo un livello di dati massicciamente sharded e, in quanto piattaforma che serviva oltre un milione di app mobili, avevamo molti problemi di multi-tenancy molto complicati. I nostri clienti erano sviluppatori, e stavano costantemente scrivendo e caricando snippet di codice arbitrari e nuove query di, diciamo, “qualità variabile” – e dovevamo semplicemente accettarle e farle funzionare in qualche modo.

Eravamo all’avanguardia di una serie di cambiamenti che sono diventati mainstream. Un tempo, la maggior parte delle architetture era abbastanza semplice e falliva ripetutamente in modi prevedibili. Avevi generalmente un livello web, un’applicazione e un database, e la maggior parte della complessità era legata al codice dell’applicazione. Quindi scrivevi controlli di monitoraggio per cercare quei fallimenti e costruivi dashboard statiche per le tue metriche e i dati di monitoraggio.

Quest’industria ha visto un’esplosione di complessità architettonica negli ultimi 10 anni. Abbiamo fatto esplodere il monolite, quindi adesso hai da qualche servizio a migliaia di microservizi di applicazioni. La persistenza poliglotta è la norma; invece di “il database” è normale avere molti tipi di archiviazione diversi, nonché sharding orizzontale, livelli di caching, db-per-microservizio, code, e altro. In aggiunta a questo, hai container hostati lato server, servizi e piattaforme di terze parti, codice serverless, archiviazione a blocchi e altro.

La parte difficile un tempo era il debug del codice; adesso, la parte difficile è capire dove nel sistema si trova il codice che devi debuggare. Invece di fallire ripetutamente in modi prevedibili, è più probabile che ogni volta che ricevi una pagina, si tratti di qualcosa che non hai mai visto prima e potresti non vedere mai più.

Era lo stato in cui eravamo a Parse, su Facebook. Ogni giorno l’intera piattaforma andava giù, e ogni volta era qualcosa di diverso e nuovo; un’app diversa che raggiungeva la top 10 su iTunes, uno sviluppatore che caricava una query scadente.

Il debug di questi problemi da zero è incredibilmente difficile. Con i log e le metriche, devi basically sapere cosa stai cercando prima di poterlo trovare. Ma abbiamo iniziato a inserire alcuni set di dati in uno strumento di Facebook chiamato Scuba, che ci ha permesso di affettare e dividere su dimensioni arbitrarie e dati ad alta cardinalità in tempo reale, e il tempo che ci voleva per identificare e risolvere questi problemi da zero è sceso come una pietra, da ore a… minuti? secondi? Non era più un problema di ingegneria, era un problema di supporto. Potevi semplicemente seguire la traccia dei breadcrumb per arrivare alla risposta ogni volta, clic clic clic.

È stato sconvolgente. Questa enorme fonte di incertezza e fatica e clienti infelici e pagine alle 2 del mattino… è semplicemente scomparsa. Non è stato fino a quando Christine e io abbiamo lasciato Facebook che ci siamo resi conto di quanto avesse trasformato il modo in cui interagivamo con il software. L’idea di tornare ai vecchi giorni di controlli di monitoraggio e dashboard era semplicemente impensabile.

Ma all’epoca, pensavamo onestamente che si trattasse di una soluzione di nicchia – che risolvesse un problema che altre piattaforme multitenant massive potessero avere. Non è stato fino a quando non abbiamo iniziato a costruire per quasi un anno che abbiamo iniziato a renderci conto che, oh wow, questo sta diventando un problema per tutti.

Per i lettori che non sono familiari, potreste spiegare cosa è specificamente una piattaforma di osservabilità e come si differenzia dal monitoraggio tradizionale e dalle metriche?

Il monitoraggio tradizionale è famoso per i suoi tre pilastri: metriche, log e tracce. Di solito devi acquistare molti strumenti per soddisfare le tue esigenze: logging, tracing, APM, RUM, dashboarding, visualizzazione, ecc. Ognuno di questi è ottimizzato per un caso d’uso diverso in un formato diverso. Come ingegnere, ti siedi in mezzo a questi, cercando di dare un senso a tutti loro. Scorri le dashboard cercando pattern visivi, copi e incolla ID dai log alle tracce e viceversa. È molto reattivo e a pezzi, e di solito ti riferisci a questi strumenti quando hai un problema – sono progettati per aiutarti a operare il tuo codice e trovare bug ed errori.

L’osservabilità moderna ha una singola fonte di verità; eventi di log strutturati arbitrariamente ampi. Da questi eventi puoi derivare le tue metriche, dashboard e log. Puoi visualizzarli nel tempo come una traccia, puoi affettare e dividere, puoi zoomare su singole richieste e fuori dalla vista lunga. Perché tutto è connesso, non devi saltare da uno strumento all’altro, indovinare o affidarti all’intuizione. L’osservabilità moderna non riguarda solo come operi i tuoi sistemi, riguarda come sviluppi il tuo codice. È il substrato che ti consente di collegare anelli di feedback potenti e stretti che ti aiutano a spedire molti valori agli utenti in fretta, con fiducia, e trovare problemi prima che gli utenti li facciano.

Siete nota per credere che l’osservabilità offra una singola fonte di verità negli ambienti di ingegneria. Come si integra l’AI in questa visione, e quali sono i suoi benefici e sfide in questo contesto?

L’osservabilità è come mettersi gli occhiali prima di scendere sull’autostrada. Lo sviluppo guidato dai test (TDD) ha rivoluzionato il software all’inizio degli anni 2000, ma il TDD sta perdendo efficacia man mano che la complessità si trova nei nostri sistemi invece che solo nel nostro software. Sempre più, se vuoi ottenere i benefici associati al TDD, devi effettivamente strumentare il tuo codice e eseguire qualcosa di simile allo sviluppo guidato dall’osservabilità, o ODD, dove strumenti man mano che vai, deploy in fretta, poi guardi il tuo codice in produzione attraverso la lente della strumentazione che hai appena scritto e ti chiedi: “sta facendo quello che mi aspettavo che facesse, e c’è qualcos’altro che sembra… strano?”

I test da soli non sono sufficienti per confermare che il tuo codice stia facendo quello che dovrebbe fare. Non sai fino a quando non hai guardato il codice in produzione, con utenti reali su infrastrutture reali.

Questo tipo di sviluppo – che include la produzione in anelli di feedback veloci – è (un po’ controintuitivamente) molto più veloce, più facile e più semplice che affidarsi a test e cicli di deploy più lenti. Una volta che gli sviluppatori hanno provato a lavorare in questo modo, sono famosi per non voler tornare al vecchio modo lento di fare le cose.

Quello che mi entusiasma dell’AI è che quando sviluppi con LLM, devi sviluppare in produzione. L’unico modo per derivare un set di test è validare il tuo codice in produzione e lavorare a ritroso. Penso che scrivere software supportato da LLM sarà una competenza così comune come scrivere software supportato da MySQL o Postgres in pochi anni, e la mia speranza è che questo trascini gli ingegneri a calci e pugni in una vita migliore.

Avevate sollevato preoccupazioni riguardo al debito tecnico crescente a causa della rivoluzione dell’AI. Potreste elaborare sui tipi di debito tecnico che l’AI può introdurre e su come Honeycomb aiuta a gestire o mitigare questi debiti?

Sono preoccupata sia per il debito tecnico che, forse più importante, per il debito organizzativo. Uno dei peggiori tipi di debito tecnico è quando hai software che non è ben compreso da nessuno. Il che significa che ogni volta che devi estendere o modificare quel codice, o debuggarlo o correggerlo, qualcuno deve fare il lavoro difficile di impararlo.

E se metti in produzione codice che nessuno comprende, c’è una buona possibilità che non sia stato scritto per essere comprensibile. Il buon codice è scritto per essere facile da leggere e comprendere e estendere. Utilizza convenzioni e pattern, utilizza denominazioni e modularizzazione coerenti, colpisce un equilibrio tra DRY e altre considerazioni. La qualità del codice è inseparabile da quanto è facile per le persone interagirci. Se si inizia a lanciare codice in produzione perché compila o supera i test, si sta creando un enorme iceberg di problemi tecnici futuri per se stessi.

Se hai deciso di spedire codice che nessuno comprende, Honeycomb non può aiutare con questo. Ma se ti importa spedire software pulito e iterabile, la strumentazione e l’osservabilità sono assolutamente essenziali per questo sforzo. La strumentazione è come la documentazione più la segnalazione dello stato in tempo reale. La strumentazione è l’unico modo per confermare veramente che il tuo software stia facendo quello che ti aspetti che faccia, e si comporti nel modo in cui gli utenti si aspettano che si comporti.

Come Honeycomb utilizza l’AI per migliorare l’efficienza e l’efficacia dei team di ingegneria?

I nostri ingegneri utilizzano l’AI molto internamente, soprattutto CoPilot. I nostri ingegneri più junior riferiscono di utilizzare ChatGPT ogni giorno per rispondere a domande e aiutarli a comprendere il software che stanno costruendo. I nostri ingegneri più senior dicono che è grande per generare software che sarebbe molto tedioso o fastidioso scrivere, come quando hai un enorme file YAML da compilare. È anche utile per generare snippet di codice in linguaggi che non si utilizzano normalmente, o da documentazione API. Ad esempio, puoi generare alcuni esempi di codice veramente grandi e utilizzabili utilizzando gli SDK e le API di AWS, poiché è stato addestrato su repository che hanno un uso reale di quel codice.

Tuttavia, ogni volta che lasci all’AI generare il tuo codice, devi eseguire il codice riga per riga per assicurarti che stia facendo la cosa giusta, perché assolutamente genererà spazzatura a caso.

Potreste fornire esempi di come le funzionalità AI come il vostro assistente di query o l’integrazione con Slack migliorano la collaborazione di squadra?

Sì, certo. Il nostro assistente di query è un grande esempio. Utilizzare i generatori di query è complicato e difficile, anche per gli utenti potenti. Se hai centinaia o migliaia di dimensioni nella tua telemetria, non puoi sempre ricordare a memoria quali sono i più valuable. E anche gli utenti potenti dimenticano i dettagli di come generare certi tipi di grafici.

Quindi il nostro assistente di query ti consente di porre domande utilizzando il linguaggio naturale. Come, “quali sono gli endpoint più lenti?”, o “cosa è successo dopo il mio ultimo deploy?” e genera una query e ti fa cadere dentro. La maggior parte delle persone trova difficile comporre una nuova query da zero e facile modificare una query esistente, quindi ti dà un vantaggio.

Honeycomb promette una risoluzione più rapida degli incidenti. Potreste descrivere come l’integrazione dei log, delle metriche e delle tracce in un tipo di dati unificato aiuta nella risoluzione più rapida dei problemi e nella risoluzione dei problemi?

Tutto è connesso. Non devi indovinare. Invece di guardare che questa dashboard sembra avere la stessa forma di quella dashboard, o indovinare che questo picco nelle tue metriche debba essere lo stesso di questo picco nei tuoi log in base ai timestamp…. invece, i dati sono tutti connessi. Non devi indovinare, puoi semplicemente chiedere.

I dati sono resi preziosi dal contesto. La generazione precedente di strumenti funzionava rimuovendo tutto il contesto al momento della scrittura; una volta che hai scartato il contesto, non puoi più riaverlo.

Inoltre: con i log e le metriche, devi sapere cosa stai cercando prima di poterlo trovare. Ciò non è vero dell’osservabilità moderna. Non devi sapere nulla, o cercare nulla.

Quando archivi questo ricco dato contestuale, puoi fare cose con esso che sembrano magia. Abbiamo uno strumento chiamato BubbleUp, dove puoi disegnare una bolla intorno a qualsiasi cosa pensi che sia strana o potrebbe essere interessante, e calcoliamo tutte le dimensioni all’interno della bolla rispetto all’esterno della bolla, la baseline, e le ordiniamo e le differenziamo. Quindi sei come “questa bolla è strana” e noi ti diciamo immediatamente, “è diversa in xyz modi”. Molto del debug si riduce a “qui c’è una cosa di cui mi importa, ma perché mi importa?” Quando puoi identificare immediatamente che è diverso perché queste richieste provengono da dispositivi Android, con questo particolare ID di build, utilizzando questo pacchetto linguistico, in questa regione, con questa ID app, con un payload grande… a questo punto probabilmente sai esattamente cosa non va e perché.

Non si tratta solo del dato unificato, però – anche se questo è una parte enorme di esso. Si tratta anche di come gestiamo agevolmente i dati ad alta cardinalità, come ID univoci, ID del carrello della spesa, ID dell’app, nomi e cognomi, ecc. La generazione precedente di strumenti non può gestire dati ricchi come questo, il che è quasi incredibile quando ci si pensa, perché i dati ricchi e ad alta cardinalità sono i più preziosi e identificativi di tutti.

Come migliorare l’osservabilità si traduce in migliori risultati aziendali?

Questo è uno degli altri grandi passaggi dalla generazione precedente alla nuova generazione di strumenti di osservabilità. Nel passato, i sistemi, le applicazioni e i dati aziendali erano tutti isolati l’uno dall’altro in strumenti diversi. Ciò è assurdo – ogni domanda interessante che vuoi porre ai sistemi moderni ha elementi di tutti e tre.

L’osservabilità non riguarda solo bug, o downtime, o interruzioni. Riguarda assicurarsi che stiamo lavorando sulle cose giuste, che gli utenti stanno avendo una grande esperienza, che stiamo raggiungendo gli esiti aziendali che ci stiamo prefissando. Riguarda la costruzione di valore, non solo l’operazione. Se non puoi vedere dove stai andando, non puoi muoverti molto velocemente e non puoi correggere la rotta molto velocemente. Più visibilità hai su cosa stanno facendo gli utenti con il tuo codice, più forte e migliore ingegnere puoi essere.

Dove vedete il futuro dell’osservabilità diretto, in particolare per quanto riguarda gli sviluppi dell’AI?

L’osservabilità è sempre più sul collegare anelli di feedback veloci e stretti, in modo che le squadre possano sviluppare velocemente, con fiducia, in produzione, e sprecare meno tempo ed energia.

Si tratta di collegare i punti tra gli esiti aziendali e i metodi tecnologici.

E si tratta di assicurarsi che comprendiamo il software che stiamo mettendo nel mondo. Man mano che il software e i sistemi diventano sempre più complessi, e in particolare man mano che l’AI diventa sempre più parte del mix, è più importante che mai che ci teniamo responsabili di uno standard umano di comprensione e gestibilità.

Dal punto di vista dell’osservabilità, vedremo livelli crescenti di sofisticazione nel pipeline dei dati – utilizzando apprendimento automatico e tecniche di campionamento sofisticate per bilanciare valore e costo, per mantenere il massimo dettaglio possibile sugli eventi outlier e sugli eventi importanti e archiviare riassunti del resto il più economicamente possibile.

I vendor di AI stanno facendo molte affermazioni esagerate su come possano comprendere il tuo software meglio di te, o come possano elaborare i dati e dire ai tuoi umani quali azioni intraprendere. Da tutto ciò che ho visto, si tratta di un sogno a costo elevato. I falsi positivi sono incredibilmente costosi. Non c’è sostituto per la comprensione dei tuoi sistemi e dei tuoi dati. L’AI può aiutare i tuoi ingegneri con questo! Ma non può sostituire i tuoi ingegneri.

Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare Honeycomb.