Charity Majors, CTO & Co-Founder at Honeycomb – Interview Series

Charity je ops inženýr a náhodný zakladatel společnosti Honeycomb. Předtím pracovala ve firmách Parse, Facebook a Linden Lab na infrastruktuře a nástrojích pro vývojáře a vždy se zdálo, že skončí jako správce databází. Je spoluautorkou knihy O’Reilly’s Database Reliability Engineering a miluje svobodný projev, svobodný software a skotskou whisky.

Vous byli Production Engineering Manager ve společnosti Facebook (nyní Meta) více než 2 roky, co byly některé z vašich nejvýznamnějších zkušeností z tohoto období a co jsou některé z vašich klíčových poznatků z této zkušenosti?

Pracovala jsem na Parse, což byla backendová služba pro mobilní aplikace, podobná Heroku pro mobilní zařízení. Nikdy mě nezajímalo pracovat ve velké společnosti, ale byli jsme koupeni Facebookem. Jedna z mých klíčových poznatků je, že akvizice jsou opravdu, opravdu těžké, i v těch nejlepších okolnostech. Rada, kterou vždy dávám ostatním zakladatelům, je tato: pokud budete akvizicí, zajistěte, abyste měli výkonného sponzora a důkladně zvažte, zda máte strategickou shodu. Facebook získal Instagram krátce předtím, než získal Parse, a akvizice Instagramu nebyla exactly slavná, ale nakonec byla velmi úspěšná, protože měli strategickou shodu a silného sponzora.

Neměla jsem lehkou dobu na Facebooku, ale jsem velmi vděčná za čas, který jsem tam strávila; nevím, zda bych mohla založit společnost bez урокů, které jsem se naučila o organizační struktuře, řízení, strategii atd. Také mi to dalo určitou prestiž, která mě učinila atraktivní pro venture kapitálové firmy, které mě předtím ani nevzaly na vědomí. Jsem trochu naštvaná kvůli tomu, ale přesto to beru.

Můžete sdílet příběh o vzniku společnosti Honeycomb?

Určitě. Z architektonického hlediska byl Parse před svým časem — používali jsme mikroslužby, než existoval termín “mikroslužby”, měli jsme obrovsky shardovanou datovou vrstvu a jako platforma pro více než milion mobilních aplikací jsme měli spoustu komplikovaných problémů s multi-tenancy. Naši zákazníci byli vývojáři a neustále psali a nahrávali libovolné kódy a nové dotazy, které měly, řekněme, “různou kvalitu” — a my prostě museli všechno přijmout a udělat to fungovat, nějakým způsobem.

Byli jsme na špici změn, které se od té doby staly mainstreamem. Dříve byly architektury většinou poměrně jednoduché a selhávaly opakovaně předvídatelným způsobem. Obvykle jste měli webovou vrstvu, aplikaci a databázi a většina složitosti byla vázána na váš kód aplikace. Proto jste psali monitorovací kontroly, abyste sledovali selhání, a konstruovali statické dashboardy pro vaše metriky a monitorovací data.

Tento průmysl zažil explozi architektonické složitosti za posledních 10 let. Rozbili jsme monolit, takže nyní máte k dispozici od několika služeb až po tisíce mikroslužeb. Polyglot persistence je normou; místo “databáze” je normální mít mnoho různých typů úložišť, jakož i horizontální shardování, vrstvy cachingu, db-per-microservice, queueing a další. Navíc máte server-side hostované kontejnery, třetí strany a platformy, serverless kód, block storage a další.

Dříve byl tvrdý problém ladění vašeho kódu; nyní je tvrdý problém zjistit, kde v systému je kód, který potřebujete ladit. Místo opakovaného selhání předvídatelným způsobem je pravděpodobnější, že každý jednotlivý případ, kdy vás někdo upozorní, je o něčem, co jste nikdy předtím neviděli a možná nikdy neuvidíte.

To byl stav, ve kterém jsme byli na Parse, na Facebooku. Každý den celá platforma padala a každý den to byla něco jiného a nového; jiná aplikace, která se dostala do top 10 na iTunes, jiný vývojář, který nahrál špatný dotaz.

Ladění těchto problémů od začátku je šíleně těžké. S logy a metrikami musíte基本ně vědět, co hledáte, než můžete najít. Ale začali jsme krmit一些 datové sady do nástroje Facebooku zvaného Scuba, který nám umožnil rozřezat a rozdělit na libovolné rozměry a data s vysokou kardinalitou v reálném čase a doba, po kterou jsme identifikovali a vyřešili tyto problémy od začátku, klesla jako kámen, z hodiny na … minuty? sekundy? Nebyla to už žádná inženýrská práce, ale spíše problém podpory. Mohli jste prostě následovat stopu chleba k odpovědi pokaždé, klik, klik.

Byla to ohromující věc. Tento obrovský zdroj nejistoty a dřiny a nespokojených zákazníků a 2 hodiny v noci … prostě zmizel. Nebylo to až do té doby, než Christine a já opustili Facebook, že jsme si uvědomili, jak moc to změnilo způsob, jakým jsme interagovali se softwarem. Představa návratu ke starému způsobu monitorovacích kontrol a dashboardů byla prostě nemyslitelná.

Pro čtenáře, kteří nejsou obeznámeni, můžete vysvětlit, co přesně je platforma pro pozorovatelnost a jak se liší od tradičního monitorování a metrik?

Tradiční monitorování má tři pilíře: metriky, logy a stopy. Obvykle musíte koupit mnoho nástrojů, aby vaše potřeby byly splněny: logování, trasování, APM, RUM, dashboarding, vizualizace atd. Každý z nich je optimalizován pro jiný případ použití v jiném formátu. Jako inženýr sedíte uprostřed nich a snažíte se dát smysl všemu.

Moderní pozorovatelnost má jediný zdroj pravdy; libovolně široké strukturované logovací události. Z těchto událostí můžete odvodit své metriky, dashboardy a logy. Můžete je vizualizovat v čase jako stopu, můžete je rozřezat a rozdělit, můžete se přiblížit k jednotlivým požadavkům a vzdálit se k dlouhodobému pohledu. Protože všechno je propojeno, nemusíte skákat z nástroje na nástroj, hádat nebo spoléhat se na intuici. Moderní pozorovatelnost není jen o tom, jak provozujete své systémy, ale také o tom, jak vyvíjíte svůj kód. Je to substrát, který umožňuje vám připojit silné, rychlé zpětné vazby, které vám pomáhají dodávat mnoho hodnoty uživatelům rychle, s jistotou a najít problémy, než je vaše uživatelé.

Jste známá tím, že věříte, že pozorovatelnost nabízí jediný zdroj pravdy v inženýrských prostředích. Jak se AI integruje do tohoto vidění a co jsou jeho výhody a výzvy v tomto kontextu?

Pozorovatelnost je jako nasazení brýlí, než vyjedete na dálnici. Test-driven development (TDD) revolucionalizoval software na počátku 2000. let, ale TDD ztrácí účinnost, jak je složitost umístěna v našich systémech místo pouze v našem softwaru. Čím více chcete získat výhody spojené s TDD, musíte vlastně instrumentovat váš kód a provést něco podobného jako pozorovatelnost řízený vývoj, nebo ODD, kde instrumentujete, zatímco jdete, nasadíte rychle a pak se podíváte na váš kód v produkci prostřednictvím čočky instrumentace, kterou jste právě napsali, a zeptejte se sami sebe: “dělá to, co jsem čekal, a vypadá něco … divně?”

Testy samotné nejsou dostatečné k potvrzení, že váš kód dělá to, co má. Nevíte, dokud nevidíte, jak funguje v produkci, s reálnými uživateli na reálné infrastruktuře.

Tento typ vývoje — který zahrnuje produkci do rychlých zpětných vazeb — je (poměrně protichůdně) mnohem rychlejší, snadnější a jednodušší než spoléhání se na testy a pomalejší nasazení. Jakmile vývojáři vyzkouší práci tímto způsobem, jsou slavně neochotni vrátit se ke starému, pomalému způsobu dělání věcí.

To, co mě vzrušuje na AI, je, že když vyvíjíte s LLM, musíte vyvíjet v produkci. Jediný způsob, jak můžete odvodit sadu testů, je nejprve ověřit váš kód v produkci a pracovat zpět. Domnívám se, že psaní softwaru podporovaného LLM bude tak běžnou dovedností jako psaní softwaru podporovaného MySQL nebo Postgres v několika letech, a moje naděje je, že to táhne inženýry kopající a křičící do lepšího života.

Můžete vysvětlit, jak Honeycomb pomáhá při správě nebo zmírnění technických dluhů, které mohou být způsobeny AI revolucí?

Jsem znepokojena jak technickým dluhem, tak organizačním dluhem. Jedním z nejhorších typů technického dluhu je, když máte software, který není dobře pochopený nikým. To znamená, že kdykoli musíte prodloužit nebo změnit kód, nebo jej ladit nebo opravit, někdo musí udělat těžkou práci učení se mu.

A pokud dáte do produkce kód, který nikdo nerozumí, je velmi dobrá šance, že nebyl napsán tak, aby byl pochopitelný. Dobrý kód je napsán tak, aby byl snadno čitelný a pochopitelný a rozšiřitelný. Používá konvence a vzory, používá konzistentní názvosloví a modularizaci, nachází rovnováhu mezi DRY a dalšími úvahami. Kvalita kódu je neoddělitelná od toho, jak snadno s ním lze pracovat. Pokud prostě začnete házet kód do produkce, protože se kompiluje nebo projde testy, vytváříte obrovský ledovec budoucích technických problémů pro sebe.

Pokud jste se rozhodli dodat kód, který nikdo nerozumí, Honeycomb nemůže pomoci s tím. Ale pokud se vám záleží na tom, aby byl váš software čistý a iterovatelný, instrumentace a pozorovatelnost jsou absolutně nezbytné pro tuto snahu. Instrumentace je jako dokumentace plus reporting v reálném čase. Instrumentace je jediný způsob, jak můžete skutečně potvrdit, že váš software dělá to, co očekáváte, a chová se tak, jak očekávají vaši uživatelé.

Jak Honeycomb využívá AI ke zlepšení efektivity a efektivnosti inženýrských týmů?

Naši inženýři používají AI hodně interně, zejména CoPilot. Naši méně zkušení inženýři uvádějí, že používají ChatGPT každý den, aby odpověděli na otázky a pomohli jim pochopit software, který staví. Naši zkušenější inženýři říkají, že je skvělé pro generování kódu, který by byl velmi únavný nebo otravný psát, jako když máte obrovský YAML soubor, který musíte vyplnit. Je také užitečné pro generování snímků kódu v jazycích, které běžně nepoužíváte, nebo z dokumentace API. Můžete například generovat některé skvělé, použitelné příklady věcí pomocí AWS SDK a API, protože byly trénovány na repozitářích, které mají skutečné použití tohoto kódu.

Nicméně, kdykoli dovolíte AI generovat váš kód, musíte projít jím řádek po řádku, abyste zajistili, že dělá správnou věc, protože určitě bude halucinovat nesmysly pravidelně.

Můžete poskytnout příklady toho, jak AI poháněné funkce, jako je váš query asistent nebo integrace se Slackem, zlepšují spolupráci v týmu?

Ano, určitě. Náš query asistent je skvělým příkladem. Používání query builderů je složité a těžké, i pro power uživatele. Pokud máte stovky nebo tisíce rozměrů ve vaší telemetrii, nemůžete si vždycky vzpomenout, jak se jmenují ty nejvýznamnější. A dokonce i power uživatelé zapomínají detaily o tom, jak generovat určitý typ grafů.

Takže náš query asistent umožňuje vám klást otázky pomocí přirozeného jazyka. Jako “jaké jsou nejpomalejší koncové body?” nebo “co se stalo po mé poslední nasazení?” a generuje dotaz a umístí vás do něj. Většina lidí najde obtížné složit nový dotaz od začátku a snadné upravit stávající, takže vám dává výhodu.

Honeycomb slibuje rychlejší řešení incidentů. Můžete popsat, jak integrace logů, metrik a stop do jednotného datového typu pomáhá při rychlejším ladění a řešení problémů?

Vše je propojeno. Nemusíte hádat. Místo toho, abyste sledovali, zda vypadá jeden dashboard stejně jako druhý, nebo hádali, zda musí být tento špička v metrikách stejná jako tato špička v logách na základě časových razítek … místo toho je data vše propojena. Nemusíte hádat, můžete prostě zeptat.

Data jsou cenná kontextem. Předchozí generace nástrojů fungovala tak, že odstranila veškerý kontext při zápisu; jednou jste odstranili kontext, nemůžete jej již získat zpět.

Také: s logy a metrikami musíte vědět, co hledáte, než můžete najít. To není pravda pro moderní pozorovatelnost. Nemusíte vědět nic, nebo hledat nic.

Když ukládáte tato bohatá kontextová data, můžete s nimi dělat věci, které se zdají jako magie. Máme nástroj zvaný BubbleUp, kde můžete nakreslit bublinu kolem čehokoli, co si myslíte, že je divné nebo by mohlo být zajímavé, a my spočítáme všechny rozměry uvnitř bubliny vs. vně bubliny, základny a seřadíme a rozdíly. Takže jste jako “tato bublina je divná” a my vám okamžitě řekneme, “je to jiné v xyz způsoby”. Takže tolik ladění se sníží na “tady je věc, kterou se mi záleží, ale proč se mi to záleží?” Když můžete okamžitě identifikovat, že je to jiné, protože tyto požadavky pocházejí z Android zařízení, s tímto konkrétním ID sestavení, používající tento jazykový balíček, v tomto regionu, s touto aplikací ID, s velkou payloade … do té doby pravděpodobně víte přesně, co je špatně a proč.

Není to jen o jednotném datu, ale také o tom, jak snadno zvládáme data s vysokou kardinalitou, jako jsou jedinečné ID, ID nákupního košíku, ID aplikací, křestní jména, příjmení, atd. Předchozí generace nástrojů nemůže zvládnout bohatá data, jako je tato, což je vlastně neuvěřitelné, když si uvědomíte, že bohatá data s vysokou kardinalitou jsou nejcennější a identifikující data ze všech.

Jak zlepšení pozorovatelnosti překládá do lepších obchodních výsledků?

To je jedna z dalších velkých změn od předchozí generace k nové generaci nástrojů pro pozorovatelnost. V minulosti byly systémy, aplikace a obchodní data semua odděleny do různých nástrojů. To je absurdní — každá zajímavá otázka, kterou chcete položit o moderních systémech, má prvky všech tří.

Pozorovatelnost není jen o chybách, nebo výpadcích, nebo odstávkách. Je to o zajištění toho, že pracujeme na správných věcech, že naši uživatelé mají skvělou zkušenost, že dosahujeme obchodních výsledků, kterých chceme dosáhnout. Je to o budování hodnoty, ne jen o provozu. Pokud nemůžete vidět, kam jdete, nemůžete se pohybovat příliš rychle a nemůžete rychle měnit směr. Čím více vidíte, co dělají vaši uživatelé s vaším kódem, tím lepší a silnější inženýr můžete být.

Kam vidíte budoucnost pozorovatelnosti, zejména s ohledem na vývoj AI?

Pozorovatelnost je stále více o tom, aby týmy mohly připojit silné, rychlé zpětné vazby, aby mohly vyvíjet rychle, s jistotou, v produkci a plýtvaly méně časem a energií.

Je to o propojení teček mezi obchodními výsledky a technologickými metodami.

A je to o zajištění toho, aby jsme rozuměli softwaru, který vydáváme do světa. Čím složitější je software a systémy, a zejména s rostoucí účastí AI, je ještě důležitější, aby jsme se drželi lidského standardu porozumění a spravovatelnosti.

Z pohledu pozorovatelnosti budeme svědky rostoucí sofistikovanosti v datové pipeline — použití strojového učení a sofistikovaných vzorkovacích technik pro vyvážení hodnoty vs. nákladů, aby se uchovalo co nejvíce detailů o odlehlých událostech a důležitých událostech a uložilo souhrny zbytku co nejlevněji.

Dodavatelé AI činí mnoho přehřátých tvrzení o tom, jak mohou lépe pochopit váš software než vy, nebo jak mohou zpracovat data a říci vašim lidem, jaké akce podniknout. Z všeho, co jsem viděla, je to drahý sen. Falešné pozitivy jsou neuvěřitelně drahé. Není žádná náhrada za pochopení vašich systémů a vašich dat. AI může pomoci vašim inženýrům s tím! Ale nemůže nahradit vaše inženýry.

Děkuji za skvělý rozhovor, čtenáři, kteří chtějí dozvědět se více, by měli navštívit Honeycomb.