Charity Majors, CTO & Co-Founder på Honeycomb – Intervjuerien

Charity är en ops-engineer och oavsiktlig startup-grundare på Honeycomb. Innan detta arbetade hon på Parse, Facebook och Linden Lab med infrastruktur och utvecklarverktyg, och hon hamnade alltid i att köra databaserna. Hon är medförfattare till O’Reillys 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 på 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 riktigt, riktigt svårt, även under de bästa omständigheterna. Rådet jag alltid ger andra grundare nu är detta: om du ska förvärvas, se till att du har en verkställande sponsor, och tänk riktigt noga på om du har strategisk samstämmighet. Facebook förvärvade Instagram inte långt innan de förvärvade Parse, och Instagram-förvärvet var knappast klockrent, men det var slutligen 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 meritlista som gjorde mig attraktiv för riskkapitalister, som inte hade gett mig tid på dagen före dess. Jag är lite sur över detta, men jag tar det ändå.

Kan du dela berättelsen om hur Honeycomb startades?

Definitivt. Ur ett arkitekturperspektiv var Parse före sin tid — vi använde mikrotjänster innan det fanns mikrotjänster, vi hade ett massivt shardat datalager, och som en plattform som serverade över en miljon mobilappar, hade vi många riktigt komplicerade multi-tenancyproblem. 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 allt och göra det fungera, någonstans.

Vi var i framkanten av en massa förändringar som har gått mainstream sedan dess. Det var vanligt att arkitekturerna var ganska enkla, och de skulle misslyckas upprepade gånger på förutsägbara sätt. Du hade vanligtvis ett webblager, ett program och en databas, och de flesta komplexiteten var bunden till din programkod. Så du skrev övervakningskontroller för att titta 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 var som helst från flera tjänster till tusentals program-mikrotjä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öer och mer. Utöver detta har du server-sidan värd-containrar, tredjeparts-tjänster och plattformar, serverlös kod, blocklagring och mer.

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

Det var den situation vi var i på Parse, på Facebook. Varje dag gick hela plattformen ner, och varje gång var det något annat och nytt; en annan app som nådde topp 10 på iTunes, en annan utvecklare som laddade upp en dålig fråga.

Att debugga 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 lät oss skära och skiva på godtyckliga dimensioner och hög kardinalitet data 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 längre ett ingenjörsproblem, det var ett supportproblem. Du kunde bara följa spåren till svaret varje gång, klicka klicka.

Det var tankestoppande. Den här enorma källan till osäkerhet och slit och olyckliga kunder och 2-tiden varningar … 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 förstå att, oh wow, detta faktiskt blir ett problem för alla.

För läsare som inte är bekanta, vad är specifikt en observationsplattform och hur skiljer den sig från traditionell övervakning och mått?

Traditionell övervakning är berömd för att ha 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 osv. Var och en av dessa är optimerad för ett annat användningsfall i ett annat format. Som ingenjör sitter du i mitten av allt detta, försöker göra mening av allt.

Modern observationsförmåga 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 vy. Eftersom allt är kopplat, behöver du inte hoppa runt från verktyg till verktyg, gissa eller lita på intuition. Modern observationsförmåga handlar inte bara om hur du opererar dina system, det handlar om hur du utvecklar din kod. Det är substratet som tillåter dig att 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 observationsförmåga erbjuder en enda sanning i ingenjörs-miljöer. Hur integrerar AI i denna vision, och vad är dess fördelar och utmaningar i detta sammanhang?

Observationsförmåga är som att sätta på dig glasögonen innan du åker 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 observationsdriven utveckling, eller ODD, där du instrumenterar medan du går, distribuerar snabbt, sedan tittar på din kod i produktion genom linsen av 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?”

Testerna 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 sett den i produktion, med riktiga användare på riktiga system.

Denna typ av utveckling — som inkluderar produktion i snabba återkopplingsloopar — är (något motsägelsefullt) mycket snabbare, enklare och enklare än att lita på test 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 test ä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 tekniska skulden som ökar 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 betyder 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 sätter 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 konsekvent namngivning och modularisering, den slår en balans mellan 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änga kod i produktion för att den kompilerar eller passerar test, skapar vi en enorm isberg av framtida tekniska problem för oss själva.

Om du har bestämt dig för att leverera kod som ingen förstår, kan Honeycomb inte hjälpa till med det. Men om du bryr dig om att leverera ren, itererbar programvara, är instrumentering och observationsförmåga 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äntade dig att den skulle 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 effektiheten hos ingenjörs-team?

Våra ingenjörer använder AI mycket internt, särskilt CoPilot. Våra mer juniora ingenjörer rapporterar att de använder ChatGPT varje dag för att besvara frågor och hjälpa dem att förstå den programvara 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 och API, 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 regelbundet.

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 “vad ä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 en snabbare lösning av incidenter. Kan du beskriva hur integrationen av loggar, mått och spår i en enhetlig datatyp underlättar 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 datat allt kopplat. Du behöver inte gissa, du kan bara fråga.

Data görs värdefulla av sammanhang. Den senaste generationens verktyg fungerade genom att strippa bort allt sammanhang vid skrivning; när du har slängt bort sammanhanget, kan du aldrig få tillbaka det igen.

Även: 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 observationsförmåga. Du behöver inte veta någonting, eller söka efter någonting.

När du lagrar denna rika sammanhangsdata, 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 kanske är intressant, och vi beräknar alla dimensioner inuti bubblan jämfört med utanför bubblan, baslinjen och sorterar och differenserar 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 kokar ner till “här är en sak jag bryr mig om, men varför bryr jag mig om den?” När du kan omedelbart identifiera att den är annorlunda för att dessa förfrågningar kommer från Android-enheter, med den här specifika build-iden, som använder det här språkpaketet, i den här regionen, med den här app-iden, med en stor payload … vid det här laget vet du förmodligen exakt vad som är fel och varför.

Det handlar inte bara om den enhetliga datatypen — även om det är en stor del av det. Det handlar också om hur lätt vi hanterar hög kardinalitet data, som unika ID, shoppingvagns-ID, app-ID, första/sista namn osv. Den senaste generationens verktyg kan inte hantera rik data som den, vilket är ganska otroligt när du tänker på det, eftersom rik, hög kardinalitet data är den mest värdefulla och identifierande datan av allt.

Hur översätter förbättrad observationsförmåga till bättre affärsresultat?

Detta är en av de andra stora förändringarna från den tidigare generationen till den nya generationen av observationsverktyg. 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.

Observationsförmåga handlar inte bara om buggar, eller nedtid, eller driftstopp. 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 operera. Om du inte kan se vart du är på väg, kan du inte flytta mycket snabbt och du kan inte korrigera kursen mycket 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 observationsförmåga är på väg, särskilt med tanke på AI-utvecklingarna?

Observationsförmåga handlar alltmer om att möjliggöra för team att koppla upp tajta, snabba återkopplingsloopar, så att de kan utvecklas 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. Ju mer komplex programvara och system blir, och särskilt när AI är alltmer inblandat, desto viktigare är det att vi håller oss ansvariga för en mänsklig standard för förståelse och hanterbarhet.

Från ett observationsperspektiv kommer vi att se en ökning av sofistikeringen i datapipelinen — med hjälp av maskinlärning och avancerad sampelteknik 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 att 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 barndrö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.>