Charity Majors, CTO & Co-Founder hos Honeycomb – Interview Serie

Charity er en ops-ingeniør og tilfældig startup-stifter hos Honeycomb. Før dette arbejdede hun hos Parse, Facebook (META ) og Linden Lab med infrastruktur og udvikler-værktøjer, og hun endte altid med at køre databaserne. Hun er medforfatter til O’Reilly’s Database Reliability Engineering, og elsker fri tale, fri software og single malt skotsk whisky.

Du var Production Engineering Manager hos Facebook (nu Meta) i over 2 år, hvad var nogle af dine højdepunkter fra denne periode, og hvad er nogle af dine vigtigste erfaringer fra denne oplevelse?

Jeg arbejdede på Parse, som var en backend til mobile apps, lidt ligesom Heroku til mobile. Jeg havde aldrig været interesseret i at arbejde i en stor virksomhed, men vi blev opkøbt af Facebook. En af mine vigtigste erfaringer var, at opkøb er rigtig, rigtig svært, selv i de bedste omstændigheder. Rådet, jeg altid giver andre grundlæggere nu, er dette: hvis du skal opkøbes, skal du have en executive sponsor, og du skal tænke rigtig hårdt over, om du har strategisk alignment. Facebook opkøbte Instagram ikke længe før, de opkøbte Parse, og Instagram-opkøbet var ikke ligefrem klokkeklart, men det var til sidst rigtig succesfuldt, fordi de havde strategisk alignment og en stærk sponsor.

Jeg havde ikke en let tid hos Facebook, men jeg er meget taknemlig for tiden, jeg tilbragte der; jeg tror ikke, jeg kunne have startet en virksomhed uden de erfaringer, jeg lærte om organisationsstruktur, ledelse, strategi osv. Det gav mig også en pedigree, der gjorde mig attraktiv for venturekapital-investorer, som ikke havde givet mig tid af dagen før da. Jeg er lidt sur over det, men jeg vil alligevel tage det.

Kan du dele historien bag lanceringen af Honeycomb?

Bestemt. Fra et arkitektonisk perspektiv var Parse forud for sin tid – vi brugte mikrotjenester, før der var mikrotjenester, vi havde et massivt shardet datalag og som en platform, der betjente over en million mobile apps, havde vi mange rigtig komplicerede multi-tenancy-problemer. Vore kunder var udviklere, og de skrev og uploaded konstant nye kode-snippets og nye forespørgsler af, skal vi sige, “varierende kvalitet” – og vi skulle bare tage det hele ind og gøre det til at fungere på en eller anden måde.

Vi var på forkanten af en masse ændringer, der siden er gået mainstream. Det var tidligere sådan, at de fleste arkitekturer var ret simple, og de ville fejle gentagne gange på forudsigelige måder. Du havde typisk et web-lag, en applikation og en database, og det meste af kompleksiteten var bundet op i din applikationskode. Så du skrev overvågningskontroller for at holde øje med disse fejl, og konstruerede statiske dashboards til dine metrikker og overvågningsdata.

Dette erhverv har set en eksplosion i arkitektonisk kompleksitet over de sidste 10 år. Vi sprængte monolitten, så nu har du mellem flere tjenester og tusindvis af applikations-mikrotjenester. Polyglot-persistens er normen; i stedet for “databasen” er det normalt at have mange forskellige lagrings-typer samt vandret sharding, lag af caching, db-per-mikrotjeneste, køende, og mere. Oveni det har du server-side-hostede containere, tredjeparts-tjenester og -platforme, serverless-kode, block-lagring og mere.

Det svære var tidligere at fejlfinde din kode; nu er det svært at finde ud af, hvor i systemet koden er, som du skal fejlfinde. I stedet for at fejle gentagne gange på forudsigelige måder er det mere sandsynligt, at hver enkelt gang du bliver kontaktet, handler det om noget, du aldrig har set før, og som du måske aldrig kommer til at se igen.

At fejlfinde disse problemer fra scratch er vanvittigt svært. Med logs og metrikker skal du grundlæggende vide, hvad du leder efter, før du kan finde det. Men vi begyndte at føde nogle datasæt ind i en FB-værktøj kaldet Scuba, som tillod os at skære og dice på arbitrære dimensioner og høj-kardinalitetsdata i realtid, og den tid det tog os at identificere og løse disse problemer fra scratch faldt som en sten, fra timer til … minutter? sekunder? Det var ikke længere et ingeniør-problem, men et support-problem. Du kunne bare følge spor af brødcrumbs til svaret hver gang, klik-klik-klik.

Det var sindssygt. Denne massive kilde til usikkerhed og slid og utilfredse kunder og 2-timers-pager … forsvandt bare. Det var ikke før Christine og jeg forlod Facebook, at det gik op for os, hvor meget det havde forandret vores måde at interagere med software på. Tanken om at gå tilbage til de gamle dage med overvågningskontroller og dashboards var bare utænkelig.

Men på det tidspunkt troede vi ærligt, at dette ville være en niche-løsning – at det løste et problem, som andre massive multitenant-platforme måske havde. Det var ikke før, vi havde bygget i næsten et år, at vi begyndte at forstå, at wow, dette bliver faktisk et problem for alle.

For læsere, der ikke er bekendt med det, hvad er specifikt en overvågnings-platform, og hvordan adskiller den sig fra traditionel overvågning og metrikker?

Traditionel overvågning har tre søjler: metrikker, logs og spor. Du skal normalt købe mange værktøjer for at få dine behov mødt: logning, sporing, APM, RUM, dashboarding, visualisering osv. Hver af disse er optimeret til en anden brugssag i en anden format. Som ingeniør sidder du i midten af disse, og prøver at få mening i alt dette. Du skimrer gennem dashboards og søger efter visuelle mønstre, du kopierer og indsætter ID’er fra logs til spor og tilbage. Det er meget reaktivt og stykkevis, og normalt henviser du til disse værktøjer, når du har et problem – de er designet til at hjælpe dig med at operere din kode og finde fejl og fejl.

Moderne overvågning har en enkelt sandhedskilde; arbitrært brede strukturerede log-hændelser. Fra disse hændelser kan du aflede dine metrikker, dashboards og logs. Du kan visualisere dem over tid som et spor, du kan skære og dice, du kan zoome ind til enkeltstående anmodninger og ud til det lange overblik. Fordi alt er forbundet, behøver du ikke at springe rundt fra værktøj til værktøj, gætte eller stole på intuition. Moderne overvågning handler ikke kun om, hvordan du opererer dine systemer, men også om, hvordan du udvikler din kode. Det er substratet, der tillader dig at hook op kraftfulde, tætte feedback-løkker, der hjælper dig med at levere mange værdier til brugerne hurtigt, med tillid, og finde problemer, før dine brugere gør.

Du er kendt for at tro, at overvågning tilbyder en enkelt sandhedskilde i ingeniørmiljøer. Hvordan integrerer AI i denne vision, og hvad er dens fordele og udfordringer i denne sammenhæng?

Overvågning er som at sætte briller på, før du kører ned ad motorvejen. Test-dreven udvikling (TDD) revolutionerede software i begyndelsen af 2000’erne, men TDD har tabt effektivitet, jo mere kompleksitet der er placeret i vores systemer i stedet for kun i vores software. Jo mere kompleksitet der er i systemerne, jo mere har du brug for at instrumentere din kode og udføre noget, der ligner overvågnings-dreven udvikling, eller ODD, hvor du instrumenterer, mens du går, deployer hurtigt, og så kigger på din kode i produktion gennem linserne på instrumentationen, du lige har skrevet, og spørger dig selv: “gør den, hvad jeg forventer, den skal gøre, og ser noget andet … underligt ud?”

Tests alene er ikke nok til at bekræfte, at din kode gør, hvad den skal. Du ved ikke, det, før du har set det bage i produktion, med rigtige brugere på rigtig infrastruktur.

Denne type udvikling – der inkluderer produktion i hurtige feedback-løkker – er (lidt modsat, hvad man kunne forvente) meget hurtigere, lettere og enklere end at stole på tests og langsommere deploy-cykler. Når udviklere har prøvet at arbejde på den måde, er de berømt for at være uvillige til at gå tilbage til den langsomme, gamle måde at gøre tingene på.

Hvad der begejstrer mig ved AI er, at når du udvikler med LLM’er, skal du udvikle i produktion. Den eneste måde, du kan aflede en sæt tests, er ved først at validere din kode i produktion og arbejde baglæns. Jeg tror, at skrivning af software, der er backet af LLM’er, vil blive en så almindelig færdighed som skrivning af software, der er backet af MySQL eller Postgres, om få år, og mit håb er, at dette trækker ingeniører sparkende og skrigende ind i en bedre måde at leve på.

Du har rejst bekymringer om stigende teknisk gæld på grund af AI-revolutionen. Kan du forklare, hvilke typer teknisk gæld AI kan introducere, og hvordan Honeycomb hjælper med at håndtere eller mindske disse gæld?

Jeg er bekymret for både teknisk gæld og, måske endnu vigtigere, organisations-gæld. En af de værste typer teknisk gæld er, når du har software, der ikke er godt forstået af nogen. Det betyder, at hver gang du har brug for at udvide eller ændre den kode, eller fejlfinde eller reparere den, skal nogen gøre det hårde arbejde med at lære den.

Og hvis du sætter kode i produktion, som ingen forstår, er der en rigtig god chance for, at den ikke er skrevet til at være forståelig. God kode er skrevet til at være let at læse og forstå og udvide. Den bruger konventioner og mønstre, den bruger konsekvent navngivning og modularisering, den finder en balance mellem DRY og andre overvejelser. Kvaliteten af kode er uadskillelig fra, hvor let det er for mennesker at interagere med den. Hvis vi bare begynder at smide kode i produktion, fordi den compiler eller passerer tests, skaber vi en massiv iceberg af fremtidige tekniske problemer for os selv.

Hvis du har besluttet at sende kode i produktion, som ingen forstår, kan Honeycomb ikke hjælpe med det. Men hvis du godt kan lide at sende ren, iterativ software, er instrumentation og overvågning absolut essentiel for den indsats. Instrumentation er som dokumentation plus real-time-tilstands-rapportering. Instrumentation er den eneste måde, du kan virkelig bekræfte, at din software gør, hvad du forventer, den skal gøre, og opfører sig, som dine brugere forventer, den skal.

Hvordan udnytter Honeycomb AI til at forbedre effektiviteten og effekten af ingeniør-hold?

Vore ingeniører bruger AI meget internt, især CoPilot. Vore mere junior-ingeniører rapporterer, at de bruger ChatGPT hver dag til at besvare spørgsmål og hjælpe dem med at forstå den software, de bygger. Vore mere senior-ingeniører siger, det er fantastisk til at generere software, der ville være meget kedelige eller irriterende at skrive, som når du har en kæmpe YAML-fil at udfylde. Det er også nyttigt til at generere kode-snippets på sprog, du ikke normalt bruger, eller fra API-dokumentation. Du kan generere rigtig gode, brugbare eksempler på ting ved hjælp af AWS SDK’erne og API’erne, da det blev trænet på repos, der har rigtig brug af den kode.

Men hver gang du lader AI generere din kode, skal du gå igennem den linje for linje for at sikre, at den gør det rigtige, fordi den absolut vil hallucinere noget på den regelmæssige.

Kan du give eksempler på, hvordan AI-drevne funktioner som din forespørgsels-assistent eller Slack-integration forbedrer hold-samarbejde?

Ja, bestemt. Vores forespørgsels-assistent er et fantastisk eksempel. At bruge forespørgsels-byggere er kompliceret og svært, selv for power-brugere. Hvis du har hundredvis eller tusindvis af dimensioner i din telemetri, kan du ikke altid huske, hvad de mest værdifulde er kaldt. Og selv power-brugere glemmer detaljerne om, hvordan man genererer bestemte typer grafer.

Så vores forespørgsels-assistent lader dig stille spørgsmål ved hjælp af naturligt sprog. Som “hvad er de langsommeste endepunkter?” eller “hvad skete efter min sidste deploy?” og den genererer en forespørgsel og dropper dig ind i den. De fleste mennesker finder det svært at komponere en ny forespørgsel fra scratch og let at justere en eksisterende, så den giver dig en fordel.

Honeycomb lover hurtigere løsning af incidents. Kan du beskrive, hvordan integrationen af logs, metrikker og spor i en samlet datatyp hjælper med hurtigere fejlfinde og problemløsning?

Alt er forbundet. Du behøver ikke at gætte. I stedet for at kigge på, at dette dashboard ligner det samme som dette dashboard, eller gætte, at denne spike i dine metrikker må være den samme som denne spike i dine logs baseret på tidsstempel … i stedet er dataene alle forbundet. Du behøver ikke at gætte, du kan bare spørge.

Data bliver værdifuld ved kontekst. Den sidste generation af værktøjer fungerede ved at fjerne al kontekst på skrive-tidspunktet; når du har smidt konteksten væk, kan du aldrig få den tilbage igen.

Også: med logs og metrikker skal du vide, hvad du leder efter, før du kan finde det. Det er ikke sandt for moderne overvågning. Du behøver ikke at vide noget, eller søge efter noget.

Når du lagrer denne rige kontekstuelle data, kan du gøre ting med den, der føles som magi. Vi har et værktøj kaldet BubbleUp, hvor du kan tegne en boble rundt om noget, du synes er underligt eller måske interessant, og vi beregner alle dimensionerne inde i boblen vs udenfor boblen, baseline, og sorter og diff’er dem. Så du er som “denne boble er underlig” og vi fortæller dig straks, “den er anderledes på xyz-måder”. Så meget af fejlfinde handler om “her er noget, jeg bekymrer mig om, men hvorfor bekymrer jeg mig om det?” Når du kan straks identificere, at det er anderledes, fordi disse anmodninger kommer fra Android-enheder, med denne bestemte build-id, der bruger denne sprog-pakke, i denne region, med denne app-id, med en stor payload … ved dette tidspunkt ved du sandsynligvis allerede, hvad der er galt og hvorfor.

Det er ikke kun om den samlede data, men også om, hvordan vi håndterer høj-kardinalitetsdata, som unikke id’er, shopping-cart-id’er, app-id’er, første/sidste navne osv. Den sidste generation af værktøjer kan ikke håndtere rig data som den, hvilket er ret utroligt, når du tænker på det, fordi rig, høj-kardinalitetsdata er den mest værdifulde og identificerende data af alle.

Hvordan oversætter forbedring af overvågning til bedre forretnings-resultater?

Dette er en af de andre store skift fra den sidste generation til den nye generation af overvågnings-værktøjer. I fortiden var systemer, applikations- og forretningsdata alle adskilt fra hinanden i forskellige værktøjer. Dette er latterligt – hver interessant spørgsmål du vil stille om moderne systemer har elementer af alle tre.

Overvågning handler ikke kun om fejl, eller downtime, eller nedbrud. Det handler om at sikre, at vi arbejder på de rigtige ting, at vores brugere har en god oplevelse, at vi opnår de forretnings-resultater, vi sigter mod. Det handler om at bygge værdi, ikke kun om at operere. Hvis du ikke kan se, hvor du er på vej, kan du ikke bevæge dig ret hurtigt, og du kan ikke justere ret hurtigt. Jo mere overblik, du har over, hvad dine brugere gør med din kode, jo bedre og stærkere en ingeniør kan du være.

Hvor ser du fremtiden for overvågning gående, især med hensyn til AI-udviklinger?

Overvågning handler mere og mere om at enable-hold til at hook op tætte, hurtige feedback-løkker, så de kan udvikle hurtigt, med tillid, i produktion, og spilde mindre tid og energi.

Det handler om at forbinde punkterne mellem forretnings-resultater og tekniske metoder.

Og det handler om at sikre, at vi forstår den software, vi sætter ud i verden. Jo mere komplekse software og systemer bliver, og især når AI er mere og mere i blandingen, jo vigtigere er det, at vi holder os selv ansvarlige for en menneskelig standard for forståelse og håndterbarhed.

Fra et overvågnings-perspektiv vil vi se en øget niveau af sofistikation i data-pipeline – ved hjælp af maskinlæring og avancerede sampling-teknikker til at balancere værdi vs omkostninger, til at holde så meget detalje som muligt om outlier- begivenheder og vigtige begivenheder og gemme sammenfattelser af resten så billigt som muligt.

AI-værktøjer laver mange overophedede krav om, at de kan forstå din software bedre end du kan, eller hvordan de kan behandle data og fortælle dine mennesker, hvad de skal gøre. Fra alt, hvad jeg har set, er dette en dyr drøm. Falske positive er utroligt dyre. Der er ingen erstatning for at forstå dine systemer og din data. AI kan hjælpe dine ingeniører med det! Men det kan ikke erstatte dine ingeniører.

Tak for det gode interview, læsere, der ønsker at lære mere, skal besøge Honeycomb.