Charity Majors, CTO & spoluzakladatel Honeycomb – Interview Series

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

Byla jste manažerem produkční inženýrství ve Facebooku (nyní Meta) po dobu více než 2 let, co byly některé z vašich úspěchů 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 záloha pro mobilní aplikace, něco jako Heroku pro mobilní zařízení. Nikdy jsem nebyla intéressována pracovat v velké společnosti, ale byli jsme koupeni Facebookem. Jedním z mých klíčových poznatků bylo, že akvizice jsou opravdu, opravdu těžké, i v nejlepším případě. Rada, kterou vždy dávám jiným zakladatelům, je tato: pokud budete koupeni, zajistěte si, abyste měli výkonného sponzora a důkladně zvažte, zda máte strategickou shodu. Facebook (META ) koupil Instagram nedlouho předtím, než koupil Parse, a akvizice Instagramu nebyla vůbec jednoduchá, ale nakonec byla velmi úspěšná, protože měli strategickou shodu a silného sponzora.

Neměla jsem snadný čas na Facebooku, ale jsem velmi vděčná za čas, který jsem tam strávila; nemyslím, že bych mohla založit společnost bez lekcí, které jsem se naučila o organizační struktuře, managementu, strategii atd. Také mi to dalo určitou prestiž, která mě učinila atraktivní pro venture kapitálové firmy, žádné z nich mi předtím nedaly žádný čas. Jsem trochu naštvaná na to, ale přesto to beru.

Můžete sdílet příběh o spuštění Honeycomb?

Určitě. Z architektonického hlediska byl Parse před svým časem – používali jsme mikroslužby, než existovaly mikroslužby, měli jsme obrovsky šardovaný datový vrstva a jako platforma sloužící více než milionu mobilních aplikací, jsme měli spoustu opravdu složitý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, řekněme, “různé kvality” – a my jsme museli všechnu tuto práci udělat, nějak.

Byli jsme na špici změn, které se od té doby staly mainstreamem. Dříve byly architektury většinou jednoduché a selhávaly opakovaně předvídatelným způsobem. Měli jste vrstvu webu, aplikaci a databázi a většina složitosti byla vázána na aplikaci. Takže 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 službu 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í šardování, vrstvy cache, db-per-microservice, queueing a další. Navíc máte server-side hostované kontejnery, third-party služby a platformy, serverless kód, block storage a další.

Nejtěžší částí bylo dříve ladění kódu; nyní je nejtěžší částí zjištění, kde v systému je kód, který potřebujete ladit. Místo toho, aby opakovaně selhávaly předvídatelným způsobem, je nyní pravděpodobnější, že každý případ, kdy vás stránka označí, je o něčem, co jste nikdy neviděli předtím a možná nikdy neuvidíte znovu.

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 my jsme začali krmit některé datové sady do nástroje Facebooku zvaného Scuba, který nám umožnil řezat a krájet na libovolné rozměry a vysoké kardinalitě dat v reálném čase a doba, kterou jsme potřebovali k identifikaci a řešení těchto problémů od začátku, klesla jako kámen, z hodin na … minuty? sekundy? Nebyla to už ani inženýrský problém, ale problém podpory. Mohli jste prostě následovat stopu chleba až k odpovědi každý čas, kliky kliky.

Bylo to ohromující. Tento obrovský zdroj nejistoty a dřiny a nespokojených zákazníků a 2 hodiny ráno se prostě … zmizel. Nebylo to až do té doby, kdy Christine a já opustili Facebook, že jsme si uvědomili, jak moc to změnilo způsob, jakým jsme interagovali se softwarem. Myšlenka na návrat ke starým špatným dnům monitorovacích kontrol a dashboardů byla prostě nemyslitelná.

Ale v té době jsme upřímně mysleli, že to bude řešení pro niklovou část – že to řeší problém, který mohou mít jiné obrovské multitenantní platformy. Nebylo to až do té doby, kdy jsme stavěli téměř rok, že jsme začali chápat, že ó, wow, to se vlastně stává problémem pro každého.

Pro čtenáře, kteří nejsou obeznámeni, co je přesně observability platforma 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 potřebujete 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šem. Prohlížíte dashboardy a hledáte vizuální vzorce, kopírujete a vkládáte ID z logů do stop a zpět. Je to velmi reaktivní a kusové, a obvykle se na tyto nástroje odkazujete, když máte problém – jsou navrženy tak, aby vám pomohly provozovat váš kód a najít chyby a chyby.

Moderní observability má jediný zdroj pravdy; libovolně široké strukturované logové události. Z těchto událostí můžete odvodit vaše metriky, dashboardy a logy. Můžete je vizualizovat v čase jako stopu, můžete je krájet a rozšiřovat, můžete se přiblížit k jednotlivým požadavkům a vzdálit se k dlouhé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í observability není jen o tom, jak provozujete vaše systémy, ale také o tom, jak vyvíjíte váš kód. Je to substrát, který umožňuje připojit silné, těsné smyčky zpětné vazby, které vám pomáhají dodávat mnoho hodnoty uživatelům rychle, s důvěrou a najít problémy, než je váš uživatel.

Jste známá tím, že věříte, že observability 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?

Observability je jako nasazení brýlí, než vyrazíte na dálnici. Test-driven development (TDD) revolucionalizoval software na počátku roku 2000, ale TDD ztrácí účinnost, jak je více složitosti umístěno v našich systémech místo pouze v našem softwaru. Čím více chcete získat výhody spojené s TDD, tím více potřebujete instrumentovat váš kód a provést něco podobného jako observability-driven development, nebo ODD, kde instrumentujete, jak jdete, nasazujete rychle a pak se díváte na váš kód v produkci prostřednictvím čoček instrumentace, kterou jste právě napsali, a ptáte se sami sebe: “dělá to, co jsem očekával, a je něco jiného… divného?”

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 smyček zpětné vazby – je (něco counterintuitivního) mnohem rychlejší, jednodušší a snadnější než spoléhání se na testy a pomalejší nasazovací cykly. Jakmile vývojáři vyzkouší práci tímto způsobem, jsou slavně neochotni vrátit se k pomalému, starému způsobu dělání věcí.

Co mě vzrušuje na AI je to, že když vyvíjíte s LLM, musíte vyvíjet v produkci. Jediný způsob, jak odvodit sadu testů, je nejprve ověřit váš kód v produkci a pracovat zpět. Myslím, ž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 bude táhnout inženýry do lepšího života.

Máte obavy z rostoucí technické dluhy kvůli revoluci AI. Můžete vysvětlit, jaké typy technických dluhů může AI zavést a jak Honeycomb pomáhá při správě nebo zmírnění těchto dluhů?

Mám obavy jak o technickou dluh, tak o organizační dluh. Jedním z nejhorších typů technické dluhy je, když máte software, který není dobře pochopený nikým. To znamená, že kdykoli musíte software prodloužit nebo změnit, nebo jej odstranit nebo opravit, někdo musí udělat těžkou práci učení se mu.

A pokud umístíte kód do produkce, který nikdo nerozumí, je velmi dobrá šance, že nebyl napsán tak, aby byl srozumitelný. Dobrý kód je napsán tak, aby byl snadno čitelný a srozumitelný a rozšiřitelný. Používá konvence a vzory, používá konzistentní názvy a modularizaci, nachází rovnováhu mezi DRY a jinými úvahami. Kvalita kódu je neslučitelná s tím, jak snadno lze s ním 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 s tím pomoci. Ale pokud se vám záleží na dodání čistého, iterovatelného softwaru, instrumentace a observability jsou absolutně nezbytné pro tuto snahu. Instrumentace je jako dokumentace plus reporting stavu 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í softwaru, který by byl velmi nudný nebo otravný psát, jako když máte obrovský YAML soubor, který musíte vyplnit. Je to také užitečné pro generování kousků kódu v jazycích, které běžně nepoužíváte, nebo z dokumentace API. Jako například, můžete 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.

Ale kdykoli dovolíte AI generovat váš kód, musíte projít jím řádek po řádku, abyste se ujistili, že dělá správnou věc, protože bude absolutně halucinovat odpadky pravidelně.

Můžete poskytnout příklady toho, jak funkce AI, jako je váš query asistent nebo integrace Slacku, zlepšují spolupráci 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 vždycky si vzpomenout, co jsou nejvýznamnější z nich. A dokonce i power uživatelé zapomínají detaily o tom, jak generovat určité typy grafů.

Takže náš query asistent vám umožňuje klást otázky pomocí přirozeného jazyka. Jako “co jsou nejpomalejší koncové body?” nebo “co se stalo po mé poslední nasazení?” a generuje dotaz a umístí vás do něj. Most lidí najde obtížné složit nový dotaz od začátku a snadné upravit existující jeden, 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 se dívali, zda tento dashboard vypadá stejně jako ten dashboard, nebo hádali, zda tento špička v metrikách musí být stejná jako tato špička v logách na základě časových razítek… místo toho je data všechna propojena. Nemusíte hádat, můžete prostě zeptat.

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

Kromě toho: s logy a metrikami musíte vědět, co hledáte, než můžete najít. To není pravda moderní observability. 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 kouzlo. Máme nástroj zvaný BubbleUp, kde můžete nakreslit bublinu kolem čehokoli, co si myslíte, že je divné nebo mohlo by být zajímavé, a my spočítáme všechny rozměry uvnitř bubliny vs vně bubliny, základní a seřadíme a porovnáme je. Takže jste jako “tato bublina je divná” a my vám okamžitě řekneme, “je jiná v xyz způsobech”. Tak tolik ladění se sníží na “tady je věc, kterou se mi líbí, ale proč se mi líbí?” 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 tímto ID aplikace, s velkým payloade … do té doby pravděpodobně víte přesně, co je špatně a proč.

To není jen o jednotném datovém typu – i když to je obrovská část toho. Je to také o tom, jak snadno zpracovává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. Poslední generace nástrojů nedokáže zpracovat bohatá data taková, což je když se o tom думá, neuvěřitelné, protože bohatá, vysoká kardinalita dat je nejvýznamnější a identifikační data ze všech.

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

To je jedna z dalších velkých posunů od předchozí generace observability nástrojů. V minulosti byly systémy, aplikace a obchodní data semua oddělena od sebe 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ří.

Observability není jen o chybách, nebo výpadcích, nebo odstávkách. Je to o zajištění, ž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 jsme cílem. Je to o budování hodnoty, ne jen provozování. Pokud nemůžete vidět, kam jdete, nemůžete se pohybovat velmi rychle a nemůžete korigovat velmi rychle. Čím více viditelnosti máte do toho, 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 observability směřovat, zejména s ohledem na vývoj AI?

Observability je stále více o umožnění týmům připojit těsné, rychlé smyčky zpětné vazby, aby mohli vyvíjet rychle, s důvěrou, v produkci a plýtvat 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í, že rozumíme softwaru, který vydáváme do světa. Jak software a systémy rostou stále složitější, a zejména jak AI je stále více ve hře, je více než kdy jindy důležité, abychom se sami drželi lidského standardu srozumitelnosti a spravovali.

Z hlediska observability budeme vidět rostoucí úroveň sofistikovanosti v datové trubici – použití strojového učení a sofistikovaných vzorkovacích technik pro vyvážení hodnoty vs nákladů, aby se uchovala co nejvíce detailů o výjimečných událostech a důležitých událostech a uložila souhrny ostatních co nejlevněji.

AI dodavatelé činí spoustu přehřátých tvrzení o tom, jak mohou rozumět vašemu softwaru lépe 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ě nákladné. 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í se více dozvědět, by měli navštívit Honeycomb.