Charity Majors, CTO og medgrunnlegger i Honeycomb – Intervju-serie

Charity er en ops-ingeniør og tilfeldig startup-grunnlegger i Honeycomb. Før dette jobbet hun i Parse, Facebook (META ) og Linden Lab med infrastruktur og utviklerverktøy, og havnet alltid med å kjøre databasene. Hun er medforfatter av O’Reillys Database Reliability Engineering, og elsker ytringsfrihet, fri programvare og single malt skotsk whiskey.

Du var produksjonsingeniør-sjef i Facebook (nå Meta) i over 2 år, hva var noen av dine høydepunkter fra denne perioden og hva er noen av dine viktigste erfaringer fra denne opplevelsen?

Jeg jobbet med Parse, som var en backend for mobile apper, litt som Heroku for mobile. Jeg hadde aldri vært interessert i å jobbe i et stort selskap, men vi ble kjøpt opp av Facebook. En av mine viktigste erfaringer var at oppkjøp er veldig, veldig vanskelige, selv i de beste omstendighetene. Rådet jeg alltid gir andre grunnleggere nå er dette: hvis du skal bli kjøpt opp, sikre deg at du har en eksekutiv sponsor, og tenk hardt på om du har strategisk sammenfall. Facebook kjøpte Instagram ikke lenge før de kjøpte Parse, og Instagram-oppkjøpet var ikke uten problemer, men det var til slutt veldig suksessfullt fordi de hadde strategisk sammenfall og en sterk sponsor.

Jeg hadde ikke det lett på Facebook, men jeg er veldig takknemlig for tiden jeg tilbrakte der; jeg vet ikke om jeg kunne ha startet et selskap uten læreguttene jeg lærte om organisasjonsstruktur, ledelse, strategi osv. Det ga meg også en bakgrunn som gjorde meg attraktiv for venturekapitalister, som ikke hadde gitt meg noen oppmerksomhet før den tid. Jeg er litt sur på dette, men jeg tar det likevel.

Kunne du dele historien bak lanseringen av Honeycomb?

Definitivt. Fra et arkitekturperspektiv var Parse foran sin tid — vi brukte mikrotjenester før det var mikrotjenester, vi hadde et massivt shardet datalag og, som en plattform som betjente over en million mobile apper, hadde vi mange kompliserte multi-tenancy-problemer. Våre kunder var utviklere, og de skrev og lastet opp vilkårlige kodefragmenter og nye forespørsler av, skal vi si, “varierende kvalitet” — og vi bare måtte ta det hele inn og få det til å fungere, på noen måte.

Vi var på forkant av en rekke endringer som har gått mainstream siden. Det var vanlig at de fleste arkitekturer var ganske enkle, og de ville feile gjentakende på forutsigelige måter. Du hadde vanligvis en web-lag, en applikasjon og en database, og det meste av kompleksiteten var bundet opp i din applikasjonskode. Så skrev du overvåkingskontroller for å se etter disse feilene, og konstruerte statiske dashboards for dine metrikker og overvåkingsdata.

Dette industrien har sett en eksplosjon i arkitekturkompleksitet over de siste 10 årene. Vi sprengte monolitten, så nå har du fra noen få tjenester til tusenvis av applikasjonsmikrotjenester. Polyglot-persistens er normen; istedenfor “databasen” er det vanlig å ha mange forskjellige lagringsTYper samt horisontal sharding, lag med caching, db-per-mikrotjeneste, køer og mer. I tillegg har du server-side hostede containere, tredjeparts-tjenester og -plattformer, serverless-kode, blokk-lagring og mer.

Det harde var tidligere å feilsøke din kode; nå er det harde å finne ut hvor i systemet koden er som du må feilsøke. Istedenfor å feile gjentakende på forutsigelige måter, er det mer sannsynlig at hver enkelt gang du blir varslet, er det om noe du aldri har sett før og kanskje aldri kommer til å se igjen.

Det var tilstanden vi var i på Parse, på Facebook. Hver dag gikk hele plattformen ned, og hver gang var det noe annet og nytt; en annen app som traff topp 10 på iTunes, en annen utvikler som lastet opp en dårlig forespørsel.

Feilsøking av disse problemene fra scratch er vanvittig vanskelig. Med logger og metrikker må du vanligvis vite hva du leter etter før du kan finne det. Men vi begynte å mata noen datasett inn i en FB-verktøy kalt Scuba, som lot oss skjære og dice på vilkårlige dimensjoner og høy-kardinalitetsdata i sanntid, og tiden det tok oss å identifisere og løse disse problemene fra scratch falt som en stein, fra timer til … minutter? sekunder? Det var ikke lenger et ingeniørproblem, det var et støtteproblem. Du kunne bare følge spor av brødsmuler til svaret hver gang, klikk-klikk-klikk.

Det var tankevekkende. Denne massive kilde til usikkerhet og slit og sure kunder og 2-tiders varslinger … forsvant. Det var ikke før Christine og jeg forlot Facebook at det gikk opp for oss hvor mye det hadde forandret måten vi samarbeidet med programvare. Tanken på å gå tilbake til de gamle dagene med overvåkingskontroller og dashboards var ubærlig.

Men på den tiden trodde vi ærlig at dette skulle være en nisjeløsning — at det løste et problem som andre massive multitenant-plattformer måtte ha. Det var ikke før vi hadde bygget i nesten ett år at vi begynte å innse at, øh, dette blir faktisk et problem for alle.

For lesere som ikke er kjent med dette, hva er spesifikt en overvåkbarhetsplattform og hvordan forskjeller det seg fra tradisjonell overvåking og metrikker?

Tradisjonell overvåking har tre søyler: metrikker, logger og spor. Du må vanligvis kjøpe mange verktøy for å møte dine behov: logging, sporing, APM, RUM, dashboarding, visualisering osv. Hver av disse er optimalisert for en annen brukssak i en annen format. Som ingeniør sitter du i midten av disse, og prøver å gjøre mening av alle disse. Du skimrer gjennom dashboards og ser etter visuelle mønster, du kopierer og lim inn ID-er fra logger til spor og tilbake. Det er veldig reaktivt og stykkevis, og vanligvis henviser du til disse verktøyene når du har et problem — de er designet for å hjelpe deg å kjøre din kode og finne feil og feil.

Moderne overvåkbarhet har en enkelt sannhetskilde; vilkårlig brede strukturerte loggevents. Fra disse hendelsene kan du avlede dine metrikker, dashboards og logger. Du kan visualisere dem over tid som et spor, du kan skjære og dice, du kan zoome inn på enkeltforespørsler og utover til det lange bildet. Fordi alt er koblet sammen, trenger du ikke å hoppe rundt fra verktøy til verktøy, gjetting eller pålitende intuition. Moderne overvåkbarhet handler ikke bare om hvordan du kjører dine systemer, det handler om hvordan du utvikler din kode. Det er substratet som tillater deg å koble opp kraftfulle, tette tilbakemeldingsløkker som hjelper deg å levere mange verdier til brukerne raskt, med tillit, og finne problemer før dine brukere gjør.

Du er kjent for å tro at overvåkbarhet tilbyr en enkelt sannhetskilde i ingeniørmiljøer. Hvordan integrerer AI i denne visjonen, og hva er dens fordeler og utfordringer i denne sammenhengen?

Overvåkbarhet er som å sette på briller før du kjører nedover motorveien. Test-drevet utvikling (TDD) revolusjonerte programvare tidlig på 2000-tallet, men TDD har tapt effektivitet jo mer kompleksitet som er lokalisert i våre systemer istedenfor bare i vår programvare. Jo mer kompleksitet som er lokalisert i systemene, desto mer trenger du å instrumentere din kode og utføre noe som ligner på overvåkbarhets-drevet utvikling, eller ODD, der du instrumenterer mens du går, deployer raskt, og så ser på din kode i produksjon gjennom linsen av instrumenteringen du nettopp skrev og spør deg selv: “gjør den det jeg forventet den skulle gjøre, og ser noe annet … rart ut?”

Tester alene er ikke nok til å bekrefte at din kode gjør det det skal. Du vet ikke det før du har sett det bake i produksjon, med ekte brukere på ekte infrastruktur.

Dette type utvikling — som inkluderer produksjon i raske tilbakemeldingsløkker — er (noe motsigende) mye raskere, enklere og enklere enn å pålitende tester og langsommere deploy-sykluser. Når utviklere har prøvd å arbeide på denne måten, er de berømt uvillige til å gå tilbake til den gamle, langsommere måten å gjøre ting på.

Hva som begeistrer meg med AI er at når du utvikler med LLM-er, må du utvikle i produksjon. Den eneste måten du kan avlede en sett med tester er ved først å validere din kode i produksjon og arbeide bakover. Jeg tror at å skrive programvare bakket opp av LLM-er vil bli like vanlig en ferdighet som å skrive programvare bakket opp av MySQL eller Postgres om noen år, og min håp er at dette drar ingeniører sparkende og skrikende inn i en bedre måte å leve på.

Du har reist bekymringer om økende teknisk gjeld på grunn av AI-revolusjonen. Kunne du forklare hvilke typer teknisk gjeld AI kan introdusere og hvordan Honeycomb hjelper med å håndtere eller mildne disse gjeldene?

Jeg er bekymret for både teknisk gjeld og, kanskje mer viktig, organisatorisk gjeld. En av de verste typene teknisk gjeld er når du har programvare som ikke er godt forstått av noen. Hvis noen må gjøre det harde arbeidet med å lære det hver gang du må utvide eller endre den koden, eller feilsøke eller fikse den.

God kode er skrevet for å være lett å lese og forstå og utvide. Den bruker konvensjoner og mønster, den bruker konsistent navngivning og modulærisering, den slår en balanse mellom DRY og andre overveielser. Kvaliteten på koden er uatskillelig fra hvor lett det er for mennesker å samhandle med den. Hvis vi bare kaster kode i produksjon fordi den kompilerer eller passerer tester, skaper vi en massiv isfjell av fremtidige tekniske problemer for oss selv.

Hvis du har bestemt deg for å levere kode som ingen forstår, kan Honeycomb ikke hjelpe med det. Men hvis du bryr deg om å levere ren, itererbar programvare, er instrumentering og overvåkbarhet absolutt essensielle for den innsatsen. Instrumentering er som dokumentasjon pluss sanntids-tilstandsrapportering. Instrumentering er den eneste måten du kan virkelig bekrefte at din programvare gjør det du forventer den skal gjøre, og oppfører seg som dine brukere forventer den skal oppføre seg.

Hvordan bruker Honeycomb AI for å forbedre effektiviteten og effekten av ingeniørteam?

Våre ingeniører bruker AI mye internt, spesielt CoPilot. Våre yngre ingeniører rapporterer at de bruker ChatGPT hver dag for å svare på spørsmål og hjelpe dem å forstå programvaren de bygger. Våre eldre ingeniører sier det er fantastisk for å generere programvare som ville være veldig kjedelige eller irriterende å skrive, som når du har en stor YAML-fil å fylle ut. Det er også nyttig for å generere kodefragmenter på språk du ikke vanligvis bruker, eller fra API-dokumentasjon. For eksempel kan du generere noen virkelig gode, brukbare eksempler på ting ved hjelp av AWS-SDK-er og -API-er, siden det ble trent på repositorier som har ekte bruk av den koden.

Men hver gang du lar AI generere din kode, må du gå gjennom den linje for linje for å sikre at den gjør det riktige, fordi den absolutt vil hallucinere skrald på det regelmessige.

Kunne du gi eksempler på hvordan AI-drevne funksjoner som din spørringshjelper eller Slack-integrasjon forbedrer team-samarbeid?

Ja, absolutt. Vår spørringshjelper er et godt eksempel. Å bruke spørringsbyggere er komplisert og vanskelig, selv for kraftbrukere. Hvis du har hundrevis eller tusenvis av dimensjoner i din telemetri, kan du ikke alltid huske hva de mest verdifulle er kalt. Og selv kraftbrukere glemmer detaljene om hvordan du genererer bestemte typer grafikler.

Så vår spørringshjelper lar deg stille spørsmål ved hjelp av naturlig språk. For eksempel “hva er de sloweste endepunktene?” eller “hva skjedde etter min siste deploy?” og den genererer en spørring og dropper deg inn i den. De fleste mennesker finner det vanskelig å komponere en ny spørring fra scratch og enkelt å justere en eksisterende en, så den gir deg et løft.

Honeycomb lover raskere løsning av hendelser. Kan du beskrive hvordan integreringen av logger, metrikker og spor i en forent datatyp hjelper til med raskere feilsøking og problemløsning?

Alt er koblet sammen. Du trenger ikke å gjetting. Istedenfor å se på at dette dashboardet ser ut som det samme som det dashboardet, eller gjetting at denne spiken i dine metrikker må være den samme som denne spiken i dine logger basert på tidsstempel….isteden er dataene alle koblet sammen. Du trenger ikke å gjetting, du kan bare spørre.

Data blir verdifullt av kontekst. Den siste generasjonen av verktøy arbeidet ved å fjerne all kontekst på skriv-tid; en gang du har fjernet konteksten, kan du aldri få den tilbake igjen.

Også: med logger og metrikker må du vite hva du leter etter før du kan finne det. Det er ikke sant for moderne overvåkbarhet. Du trenger ikke å vite noe, eller søke etter noe.

Når du lagrer denne rike kontekstuelle dataen, kan du gjøre ting med den som føles som magi. Vi har et verktøy kalt BubbleUp, hvor du kan tegne en boble rundt noe du tror er rart eller kanskje interessant, og vi beregner alle dimensjonene inne i boblen vs utenfor boblen, baseline, og sorter og diff-er dem. Så du er som “denne boblen er rart” og vi forteller deg umiddelbart, “den er forskjellig på xyz måter”. Så mye av feilsøking brenner ned til “her er en ting jeg bryr meg om, men hvorfor bryr jeg meg om det?” Når du kan umiddelbart identifisere at det er forskjellig fordi disse forespørslene kommer fra Android-enheter, med denne bestemte bygge-ID-en, som bruker denne språk-pakken, i denne regionen, med denne app-ID-en, med en stor nyttelast … nå vet du sannsynligvis nøyaktig hva som er galt og hvorfor.

Det er ikke bare om den forente dataen, heller — selv om det er en stor del av det. Det er også om hvordan vi håndterer høy-kardinalitetsdata, som unike ID-er, handlekurv-ID-er, app-ID-er, fornavn/etternavn osv. Den siste generasjonen av verktøy kan ikke håndtere rik data som den, som er ganske utrolig når du tenker på det, fordi rik, høy-kardinalitetsdata er den mest verdifulle og identifiserende dataen av alle.

Hvordan oversetter forbedring av overvåkbarhet til bedre forretningsresultater?

Dette er en av de andre store skiftene fra den siste generasjonen til den nye generasjonen av overvåkbarhetsverktøy. I fortiden var systemer, applikasjons- og forretningsdata alle isolert fra hverandre i forskjellige verktøy. Dette er absurd — hver interessant spørsmål du ønsker å stille om moderne systemer har elementer av alle tre.

Overvåkbarhet handler ikke bare om feil, eller nedtid, eller nedtider. Det handler om å sikre at vi jobber med de riktige tingene, at våre brukere har en god opplevelse, at vi oppnår de forretningsresultatene vi sikter mot. Det handler om å bygge verdi, ikke bare å operere. Hvis du ikke kan se hvor du er på vei, er du ikke i stand til å flytte deg raskt og du kan ikke korrigere kursen din raskt. Jo mer synlighet du har inn i hva dine brukere gjør med din kode, jo bedre og sterkere ingeniør kan du være.

Hvor ser du fremtiden for overvåkbarhet gående, spesielt med tanke på AI-utviklinger?

Overvåkbarhet handler stadig mer om å muliggjøre team å koble opp tette, raske tilbakemeldingsløkker, så de kan utvikle raskt, med tillit, i produksjon, og spille mindre tid og energi.

Det handler om å koble punktene mellom forretningsresultater og tekniske metoder.

Og det handler om å sikre at vi forstår programvaren vi setter ut i verden. Ettersom programvare og systemer blir stadig mer komplekse, og spesielt når AI er stadig mer i blandingen, er det viktigere enn noen gang at vi holder oss selv ansvarlige for et menneskelig standard for forståelse og håndterbarhet.

Fra et overvåkbarhetsperspektiv vil vi se økende nivåer av sofistikasjon i datapipen — ved hjelp av maskinlæring og sofistikerte stikprøve-teknikker for å balansere verdi mot kostnad, for å holde så mye detalj som mulig om outlier-hendelser og viktige hendelser og lagre summeringer av resten så billig som mulig.

AI-leverandører gjør mange overopphetede krav om at de kan forstå din programvare bedre enn du kan, eller hvordan de kan prosessere dataene og fortelle dine mennesker hva handlinger de skal utføre. Fra alt jeg har sett, er dette en dyr drøm. Falske positiver er usedvanlig dyre. Det er ingen erstatning for å forstå dine systemer og dine data. AI kan hjelpe dine ingeniører med dette! Men det kan ikke erstatte dine ingeniører.

Takk for det flotte intervjuet, lesere som ønsker å lære mer kan besøke Honeycomb.