Charity Majors, CTO e Co-Foundatrice di Honeycomb – Intervista

Charity è un ingegnere di operazioni e fondatrice accidentale di Honeycomb. Prima di questo, ha lavorato a Parse, Facebook (META ) e Linden Lab su infrastrutture e strumenti per sviluppatori, e sembrava sempre finire a 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.

Eri il Production Engineering Manager di Facebook (ora Meta) per oltre 2 anni, quali sono stati alcuni dei tuoi momenti salienti di questo periodo e quali sono alcune delle tue principali considerazioni su questa esperienza?

Ho lavorato su Parse, che era un backend per app mobili, un po’ come Heroku per mobile. Non avevo mai voluto lavorare in una grande azienda, ma siamo stati acquisiti da Facebook. Una delle mie principali considerazioni è stata che le acquisizioni sono molto, molto difficili, anche nelle migliori circostanze. Il consiglio che do sempre ad altri fondatori è questo: se stai per essere acquisito, assicurati di avere un sponsor esecutivo e pensa molto attentamente se hai 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 un’azienda senza le lezioni che ho imparato sulla struttura organizzativa, la gestione, la strategia, ecc. Mi ha anche dato un pedigree che mi ha reso attraente per i venture capitalist, nessuno dei quali mi aveva dato il tempo di giorno fino a quel punto. Sono un po’ irritata da questo, ma lo accetterò comunque.

Puoi condividere la storia di come hai lanciato Honeycomb?

Certo. Da un punto di vista architettonico, Parse era avanti rispetto ai tempi – stavamo utilizzando microservizi prima che ci fossero i microservizi, avevamo un livello di dati massicciamente suddiviso e, in quanto piattaforma che serviva oltre un milione di app mobili, avevamo molti problemi di multi-tenancy molto complessi. 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 accettarli e farli funzionare in qualche modo.

Eravamo all’avanguardia di una serie di cambiamenti che sono diventati mainstream. Una volta, 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 questi fallimenti e costruivi dashboard statiche per i tuoi metriche e 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 molto altro. Inoltre, hai contenitori 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 rivedere mai più.

Il debug di questi problemi da zero è incredibilmente difficile. Con i log e le metriche, devi fondamentalmente 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 è voluto 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, cliccando e cliccando.

È 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 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 conoscono, cosa è esattamente una piattaforma di osservabilità e come si differenzia dal monitoraggio e dalle metriche tradizionali?

Il monitoraggio tradizionale ha 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 trovi al centro di questi, cercando di capire tutto. Scorri le dashboard cercando pattern visivi, copi e incolla ID da log a tracce e viceversa. È molto reattivo e a pezzi, e di solito si fa riferimento a questi strumenti quando si ha un problema – sono progettati per aiutarti a operare il tuo codice e trovare bug e 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 allontanarti per la lunga vista. Perché tutto è connesso, non devi saltare da uno strumento all’altro, indovinare o affidarti all’intuizione. L’osservabilità moderna non è solo su come operi i tuoi sistemi, è su come sviluppi il tuo codice. È il substrato che consente di collegare potenti anelli di feedback che ti aiutano a spedire molti valori agli utenti velocemente, con fiducia, e trovare problemi prima che gli utenti li trovino.

Sei 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 mettere gli occhiali prima di scendere in autostrada. Lo sviluppo guidato da test (TDD) ha rivoluzionato il software all’inizio degli anni 2000, ma il TDD ha perso efficacia man mano che la complessità si è spostata dai nostri sistemi al nostro software. Sempre più spesso, se vuoi ottenere i benefici associati al TDD, devi effettivamente strumentare il tuo codice e eseguire qualcosa di simile all’osservabilità guidata, o ODD, dove strumenti mentre vai, deploy rapidamente, 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 lo 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 rapidi – è (in qualche modo controintuitivamente) molto più veloce, facile e 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.

Cosa mi entusiasma dell’AI è che quando sviluppi con LLM, devi sviluppare in produzione. L’unico modo per derivare un set di test è prima convalidare il tuo codice in produzione e lavorare a ritroso. Penso che scrivere software supportato da LLM sarà una skill comune come scrivere software supportato da MySQL o Postgres in pochi anni, e spero che questo trascini gli ingegneri a calci nel miglior modo di vita.

Hai sollevato preoccupazioni sulla crescente indebitamento tecnico a causa della rivoluzione dell’AI. Puoi spiegare i tipi di indebitamento tecnico che l’AI può introdurre e come Honeycomb aiuta a gestire o mitigare questi debiti?

Sono preoccupata sia per l’indebitamento tecnico che per l’indebitamento 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 capisce, c’è una buona probabilità che non sia stato scritto per essere comprensibile. Il buon codice è scritto per essere facile da leggere e capire e estendere. Utilizza convenzioni e pattern, utilizza nomi e moduli coerenti, colpisce un equilibrio tra DRY e altre considerazioni. La qualità del codice è inseparabile da quanto è facile per le persone interagire con esso. Se inizi a lanciare codice in produzione perché compila o supera i test, stai creando un enorme iceberg di problemi tecnici futuri per te stesso.

Se hai deciso di spedire codice che nessuno capisce, Honeycomb non può aiutare con quello. Ma se ti importa di 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 stia comportando 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, specialmente CoPilot. I nostri ingegneri più junior riferiscono di utilizzare ChatGPT ogni giorno per rispondere a domande e aiutarli a capire 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. Come, puoi generare esempi di codice molto 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 passarlo riga per riga per assicurarti che stia facendo la cosa giusta, perché assolutamente si immaginerà spazzatura regolarmente.

Puoi fornire esempi di come le funzionalità alimentate da AI come il tuo assistente di query o l’integrazione con Slack migliorano la collaborazione di squadra?

Sì, certo. Il nostro assistente di query è un ottimo esempio. Utilizzare i builder 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ù preziosi. E anche gli utenti potenti dimenticano i dettagli di come generare certi tipi di grafici.

Quindi il nostro assistente di query ti consente di fare 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 ci fa cadere dentro. La maggior parte delle persone trova difficile comporre una nuova query da zero e facile da modificare una esistente, quindi ti dà un vantaggio.

Honeycomb promette una risoluzione più rapida degli incidenti. Puoi 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 questo dashboard sembra avere la stessa forma di quel 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. L’ultima generazione di strumenti funzionava cancellando 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. Non è vero dell’osservabilità moderna. Non devi sapere nulla, o cercare nulla.

Quando archivihi questi dati ricchi e contestuali, puoi farci cose che sembrano magia. Abbiamo uno strumento chiamato BubbleUp, dove puoi disegnare una bolla intorno a qualcosa che pensi sia strano o potrebbe essere interessante, e calcoliamo tutte le dimensioni all’interno della bolla rispetto all’esterno della bolla, il baseline, e le ordiniamo e le differenziamo. Quindi sei come “questa bolla è strana” e ti diciamo immediatamente, “è diverso in xyz modi”. Molto del debug si riduce a “questa cosa mi interessa, ma perché mi interessa?” 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 questo ID dell’app, con un grande payload… a questo punto probabilmente sai già esattamente cosa c’è che non va e perché.

Non si tratta solo dei dati unificati, ma anche di come gestiamo senza sforzo i dati ad alta cardinalità, come ID univoci, ID del carrello della spesa, ID dell’app, nomi e cognomi, ecc. L’ultima generazione 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 il miglioramento dell’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. Questo è assurdo – ogni domanda interessante che vuoi fare sui sistemi moderni ha elementi di tutti e tre.

L’osservabilità non è solo sui bug, o il downtime, o gli outage. È su assicurarsi che stiamo lavorando sulle cose giuste, che gli utenti stanno avendo una grande esperienza, che stiamo raggiungendo gli esiti aziendali che stiamo puntando. È su costruire valore, non solo operare. Se non puoi vedere dove stai andando, non puoi muoverti molto velocemente e non puoi correggere la rotta molto velocemente. Maggiore è la visibilità che hai su cosa stanno facendo gli utenti con il tuo codice, migliore e più forte sarà l’ingegnere che puoi essere.

Dove vedi il futuro dell’osservabilità diretto, specialmente riguardo agli sviluppi dell’AI?

L’osservabilità è sempre più su abilitare i team a collegare anelli di feedback stretti e veloci, in modo che possano sviluppare rapidamente, con fiducia, in produzione, e sprecare meno tempo e energia.

È su collegare i punti tra gli esiti aziendali e i metodi tecnologici.

E su assicurarsi che capiamo il software che stiamo mettendo nel mondo. Mentre il software e i sistemi diventano sempre più complessi, e specialmente mentre l’AI è sempre più nel 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 più possibile dettagli 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 capire il tuo software meglio di te, o come possano elaborare i dati e dire ai tuoi umani cosa fare. Da tutto ciò che ho visto, questo è un sogno a occhi aperti costoso. I falsi positivi sono incredibilmente costosi. Non c’è sostituto per capire i tuoi sistemi e i 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.