Charity Majors, CTO och medgrundare på Honeycomb – Intervju-serie

Charity är en ops-engineer och oavsiktlig startup-grundare på Honeycomb. Innan detta jobbade hon på Parse, Facebook (META ) och Linden Lab med infrastruktur och utvecklarverktyg, och hon hamnade alltid i slutändan med att köra databaserna. Hon är medförfattare till O’Reilly’s Database Reliability Engineering, och älskar yttrandefrihet, fri programvara och single malt scotch.

Du var Produktionsingenjörchef på Facebook (nu Meta) i över 2 år, vad var några av dina höjdpunkter under denna period och vad är några av dina viktigaste lärdomar från denna erfarenhet?

Jag arbetade med Parse, som var en backend för mobilappar, lite som Heroku för mobil. Jag hade aldrig varit intresserad av att arbeta på ett stort företag, men vi förvärvades av Facebook. En av mina viktigaste lärdomar var att förvärv är väldigt, väldigt svåra, även under de bästa omständigheterna. Rådet jag alltid ger till andra grundare nu är detta: om du ska förvärvas, se till att du har en verkställande sponsor, och tänk noga på om du har strategisk samstämmighet. Facebook förvärvade Instagram inte långt före att de förvärvade Parse, och Instagram-förvärvet var knappast klockrent, men det var till slut mycket framgångsrikt eftersom de hade strategisk samstämmighet och en stark sponsor.

Jag hade inte en lätt tid på Facebook, men jag är mycket tacksam för den tid jag tillbringade där; jag vet inte om jag kunde ha startat ett företag utan de lärdomar jag lärde mig om organisationsstruktur, ledning, strategi etc. Det gav mig också en merit som gjorde mig attraktiv för riskkapitalister, som inte hade gett mig tid på dagen före dess. Jag är lite sur på det, men jag tar det ändå.

Kan du dela berättelsen bakom lanseringen av Honeycomb?

Definitivt. Från ett arkitekturperspektiv var Parse före sin tid – vi använde mikrotjänster innan det fanns mikrotjänster, vi hade ett massivt shardsystem för data och som en plattform som serverade över en miljon mobilappar, hade vi många komplicerade problem med flera hyresgäster. Våra kunder var utvecklare, och de skrev och laddade upp godtyckliga kodsnuttar och nya frågor av, ska vi säga, “varierande kvalitet” – och vi bara måste ta emot allt och göra det fungera, någonstans.

Vi var i framkanten av en massa förändringar som har blivit mainstream. Det var tidigare så att de flesta arkitekturer var ganska enkla, och de misslyckades upprepade gånger på förutsägbara sätt. Du hade vanligtvis en webblager, ett program och en databas, och det mesta av komplexiteten var bundet till ditt programkod. Så du skrev övervakningskontroller för att leta efter dessa misslyckanden, och konstruerade statiska instrumentpaneler för dina mått och övervakningsdata.

Den här branschen har sett en explosion i arkitekturkomplexitet under de senaste 10 åren. Vi sprängde monoliten, så nu har du allt från flera tjänster till tusentals programvarumikrotjänster. Polyglot persistence är normen; istället för “databasen” är det vanligt att ha många olika lagringsTYper samt horisontell sharding, lager av cachelagring, db-per-mikrotjänst, köande och mer. Dessutom har du server-side-värdcontainrar, tredjepartstjänster och plattformar, serverless kod, blocklagring och mer.

Det svåra var tidigare att felsöka din kod; nu är det svåra att ta reda på var i systemet koden är som du behöver felsöka. Istället för att misslyckas upprepade gånger på förutsägbara sätt, är det mer troligt att varje gång du blir uppringd, är det något du aldrig har sett förut och kanske aldrig kommer att se igen.

Att felsöka dessa problem från scratch är vansinnigt svårt. Med loggar och mått måste du i princip veta vad du letar efter innan du kan hitta det. Men vi började mata in vissa datamängder i ett FB-verktyg som heter Scuba, som tillät oss att skära och skiva på godtyckliga dimensioner och högkardinalitetsdata i realtid, och den tid det tog oss att identifiera och lösa dessa problem från scratch minskade som en sten, från timmar till… minuter? sekunder? Det var inte ens ett tekniskt problem längre, det var ett supportproblem. Du kunde bara följa spåret av brödsmulor till svaret varje gång, klicka, klicka, klicka.

Det var tankeväckande. Denna enorma källa till osäkerhet och slit och olyckliga kunder och 2-timmars-samtal … försvann. Det var inte förrän Christine och jag lämnade Facebook som det gick upp för oss hur mycket det hade förändrat sättet vi interagerade med programvara. Tanken på att gå tillbaka till de gamla dåliga dagarna med övervakningskontroller och instrumentpaneler var otänkbar.

Men vid den tiden trodde vi ärligt att detta skulle vara en nischlösning – att det löste ett problem som andra stora multitenanta plattformar kanske hade. Det var inte förrän vi hade byggt i nästan ett år som vi började inse att, wow, detta blir faktiskt ett problem för alla.

För läsare som är ovana, vad är en observabilitetsplattform och hur skiljer den sig från traditionell övervakning och mått?

Traditionell övervakning har tre pelare: mått, loggar och spår. Du behöver vanligtvis köpa många verktyg för att tillgodose dina behov: loggning, spårning, APM, RUM, instrumentpaneler, visualisering etc. Var och en av dessa är optimerad för ett annat användningsfall i ett annat format. Som utvecklare sitter du mitt i allt detta, försöker förstå allt. Du bläddrar igenom instrumentpaneler och letar efter visuella mönster, du kopierar och klistrar in ID:n från loggar till spår och tillbaka. Det är väldigt reaktivt och styckevis, och vanligtvis hänvisar du till dessa verktyg när du har ett problem – de är utformade för att hjälpa dig att köra din kod och hitta buggar och fel.

Modern observabilitet har en enda sanningkälla; godtyckligt breda strukturerade logghändelser. Från dessa händelser kan du härleda dina mått, instrumentpaneler och loggar. Du kan visualisera dem över tid som ett spår, du kan skära och skiva, du kan zooma in på enskilda förfrågningar och ut till den långa vyn. Eftersom allt är kopplat behöver du inte hoppa runt från verktyg till verktyg, gissa eller lita på intuition. Modern observabilitet handlar inte bara om hur du kör dina system, det handlar om hur du utvecklar din kod. Det är underlaget som möjliggör att du kan koppla upp kraftfulla, tajta återkopplingsloopar som hjälper dig att leverera mycket värde till användare snabbt, med tillförsikt, och hitta problem innan dina användare gör det.

Du är känd för att tro att observabilitet erbjuder en enda sanningkälla i ingenjörsmiljöer. Hur integreras AI i denna vision, och vad är dess fördelar och utmaningar i detta sammanhang?

Observabilitet är som att sätta på dig glasögon innan du kör nerför motorvägen. Test-driven utveckling (TDD) revolutionerade programvara i början av 2000-talet, men TDD har tappat effektivitet ju mer komplexitet som finns i våra system istället för bara i vår programvara. Alltmer, om du vill få fördelarna som är förknippade med TDD, behöver du faktiskt instrumentera din kod och utföra något som liknar observabilitetsdriven utveckling, eller ODD, där du instrumenterar medan du går, distribuerar snabbt, sedan tittar på din kod i produktion genom instrumenteringen du just skrev och frågar dig själv: “gör den vad jag förväntade mig att den skulle göra, och ser något annat ut… konstigt?”

Tester ensamma räcker inte för att bekräfta att din kod gör vad den ska. Du vet inte det förrän du har tittat på den i produktion, med riktiga användare på riktiga system.

Den här typen av utveckling – som inkluderar produktion i snabba återkopplingsloopar – är (något motsägelsefullt) mycket snabbare, enklare och enklare än att lita på tester och långsammare distributionscykler. När utvecklare har provat att arbeta på det sättet, är de ökänt ovilliga att gå tillbaka till det långsamma, gamla sättet att göra saker.

Vad som exciterar mig om AI är att när du utvecklar med LLM, måste du utveckla i produktion. Det enda sättet du kan härleda en uppsättning tester är genom att först validera din kod i produktion och arbeta bakåt. Jag tror att att skriva programvara som backas upp av LLM kommer att vara en så vanlig färdighet som att skriva programvara som backas upp av MySQL eller Postgres om några år, och min förhoppning är att detta drar ingenjörer sparkande och skrikande in i ett bättre liv.

Du har uttryckt bekymmer över den ökande tekniska skulden på grund av AI-revolutionen. Kan du förklara de typer av tekniska skulder som AI kan införa och hur Honeycomb hjälper till att hantera eller mildra dessa skulder?

Jag är bekymrad över både teknisk skuld och, kanske viktigare, organisatorisk skuld. En av de värsta typerna av teknisk skuld är när du har programvara som inte är väl förstådd av någon. Vilket innebär att varje gång du måste utöka eller ändra den koden, eller felsöka eller fixa den, måste någon göra det hårda arbetet med att lära sig den.

Och om du släpper kod i produktion som ingen förstår, finns det en mycket stor chans att den inte skrevs för att vara förståelig. Bra kod skrivs för att vara lätt att läsa och förstå och utöka. Den använder konventioner och mönster, den använder konsekventa namn och modularisering, den balanserar DRY och andra överväganden. Kvaliteten på koden är oskiljaktig från hur lätt det är för människor att interagera med den. Om vi bara börjar släppa kod i produktion för att den kompilerar eller passerar tester, skapar vi en enorm isberg av framtida tekniska problem för oss själva.

Om du har bestämt dig för att släppa kod som ingen förstår, kan Honeycomb inte hjälpa till med det. Men om du bryr dig om att släppa ren, itererbar programvara, är instrumentering och observabilitet absolut nödvändiga för den ansträngningen. Instrumentering är som dokumentation plus realtidsstatistik. Instrumentering är det enda sättet du kan bekräfta att din programvara gör vad du förväntar dig att den ska göra, och beter sig som dina användare förväntar sig att den ska bete sig.

Hur använder Honeycomb AI för att förbättra effektiviteten och effektiven hos ingenjörsteam?

Våra ingenjörer använder AI mycket internt, särskilt CoPilot. Våra yngre ingenjörer rapporterar att de använder ChatGPT varje dag för att besvara frågor och hjälpa dem att förstå programvaran de bygger. Våra mer seniora ingenjörer säger att det är bra för att generera programvara som skulle vara mycket tråkig eller irriterande att skriva, som när du har en jättestor YAML-fil att fylla i. Det är också användbart för att generera kodsnuttar på språk du inte vanligtvis använder, eller från API-dokumentation. Till exempel kan du generera riktigt bra, användbara exempel på saker med hjälp av AWS SDK:er och API:er, eftersom det tränades på repos som har riktigt användning av den koden.

Men varje gång du låter AI generera din kod, måste du gå igenom den rad för rad för att säkerställa att den gör rätt sak, eftersom den absolut kommer att hallucinera skräp med jämna mellanrum.

Kan du ge exempel på hur AI-drivna funktioner som din frågeassistent eller Slack-integration förbättrar samarbete i team?

Ja, definitivt. Vår frågeassistent är ett bra exempel. Att använda frågebyggare är komplicerat och svårt, även för poweranvändare. Om du har hundratals eller tusentals dimensioner i din telemetri, kan du inte alltid komma ihåg vad de mest värdefulla är kallade. Och även poweranvändare glömmer detaljerna om hur man genererar vissa typer av grafer.

Så vår frågeassistent låter dig ställa frågor med hjälp av naturligt språk. Till exempel “vilka är de långsammaste slutpunkterna?” eller “vad hände efter min senaste distribution?” och den genererar en fråga och släpper dig in i den. De flesta människor tycker att det är svårt att komponera en ny fråga från scratch och lätt att justera en befintlig, så den ger dig en fördel.

Honeycomb lovar snabbare lösning av incidenter. Kan du beskriva hur integrationen av loggar, mått och spår i en enhetlig datatyp bidrar till snabbare felsökning och problemlösning?

Allt är kopplat. Du behöver inte gissa. Istället för att titta på att den här instrumentpanelen ser ut som den där instrumentpanelen, eller gissa att den här toppen i dina mått måste vara densamma som den där toppen i dina loggar baserat på tidsstämplar… istället är data allt kopplat. Du behöver inte gissa, du kan bara fråga.

Data görs värdefull av kontext. Den senaste generationen verktyg fungerade genom att ta bort all kontext vid skrivning; när du har slängt kontexten, kan du aldrig få tillbaka den igen.

Dessutom: med loggar och mått måste du veta vad du letar efter innan du kan hitta det. Det är inte sant för modern observabilitet. Du behöver inte veta någonting, eller leta efter någonting.

När du lagrar denna rika kontextuella data, kan du göra saker med den som känns som magi. Vi har ett verktyg som heter BubbleUp, där du kan rita en bubbla runt allt du tycker är konstigt eller kan vara intressant, och vi beräknar alla dimensioner inuti bubblan jämfört med utsidan, baslinjen, sorterar och differentierar dem. Så du är som “den här bubblan är konstig” och vi berättar omedelbart för dig, “den är annorlunda på xyz sätt”. Så mycket av felsökning handlar om “här är något jag bryr mig om, men varför bryr jag mig om det?” När du kan omedelbart identifiera att det är annorlunda eftersom dessa förfrågningar kommer från Android-enheter, med den här specifika build-id, som använder den här språkpaketet, i den här regionen, med den här app-id, med en stor nyttolast… nu vet du förmodligen exakt vad som är fel och varför.

Det är inte bara den enhetliga datatypen som är viktig – även om det är en stor del av det. Det handlar också om hur lätt vi hanterar högkardinalitetsdata, som unika ID:n, shoppingvagns-ID:n, app-ID:n, förnamn och efternamn etc. Den senaste generationen verktyg kan inte hantera rik data som den, vilket är ganska otroligt när du tänker på det, eftersom rik, högkardinalitetsdata är den mest värdefulla och identifierbara datan av alla.

Hur översätter förbättrad observabilitet till bättre affärsresultat?

Detta är en av de stora skiftningarna från den tidigare generationen till den nya generationen av observabilitetsverktyg. I det förflutna var system, applikation och affärsdata alla isolerade från varandra i olika verktyg. Detta är absurt – varje intressant fråga du vill ställa om moderna system har element av alla tre.

Observabilitet handlar inte bara om buggar, eller driftstopp, eller avbrott. Det handlar om att säkerställa att vi arbetar med rätt saker, att våra användare har en bra upplevelse, att vi uppnår de affärsresultat vi siktar på. Det handlar om att bygga värde, inte bara att köra. Om du inte kan se vart du är på väg, kan du inte flytta mycket snabbt och du kan inte korrigera kursen snabbt. Ju mer synlighet du har i vad dina användare gör med din kod, desto bättre och starkare ingenjör kan du vara.

Vart ser du att framtiden för observabilitet är på väg, särskilt med tanke på AI-utvecklingarna?

Observabilitet handlar alltmer om att möjliggöra för team att koppla upp tajta, snabba återkopplingsloopar, så att de kan utveckla snabbt, med tillförsikt, i produktion, och slösa mindre tid och energi.

Det handlar om att koppla ihop punkterna mellan affärsresultat och tekniska metoder.

Och det handlar om att säkerställa att vi förstår den programvara vi släpper ut i världen. När programvara och system blir alltmer komplexa, och särskilt när AI är alltmer inblandat, är det viktigare än någonsin att vi håller oss ansvariga för en mänsklig standard för förståelse och hanterbarhet.

Från ett observabilitetsperspektiv kommer vi att se ökande nivåer av sofistikering i datapipelinen – med hjälp av maskinlärning och avancerade samplingstekniker för att balansera värde mot kostnad, för att behålla så mycket detalj som möjligt om outlier-händelser och viktiga händelser och lagra sammanfattningar av resten så billigt som möjligt.

AI-leverantörer gör många överhettade påståenden om hur de kan förstå din programvara bättre än du kan, eller hur de kan bearbeta data och berätta för dina människor vilka åtgärder de ska vidta. Från allt jag har sett, är detta en dyr dröm. Falska positiva är otroligt dyra. Det finns ingen ersättning för att förstå dina system och din data. AI kan hjälpa dina ingenjörer med det! Men det kan inte ersätta dina ingenjörer.

Tack för den underbara intervjun, läsare som vill lära sig mer bör besöka Honeycomb.