Kristin Isaac, CEO a spoluzakladatelka Strudel – rozhovor

Kristin Isaac, CEO a spoluzakladatelka Strudel, je zkušená lídryně v oblasti podnikového technologického vedení, která zastávala seniorní role ve společnostech LinkedIn, Udemy, ESPN a Disney, než založila Strudel. Nyní se zaměřuje na řešení jednoho z největších tření v softwarových organizacích: mezery mezi zákaznickou podporou a inženýrstvím. Ve Strudel buduje platformu poháněnou umělou inteligencí, která pomáhá technickým podpůrným týmům řešit složitá problémem rychleji tím, že spojuje žádosti o podporu přímo s inženýrskou inteligencí. Její zkušenosti se škálováním týmů, budováním strategií pro vstup na trh a řízením růstu v globálních organizacích pomohly vytvořit Strudelovu rychlou počáteční trakci a silné postavení na trhu podnikového AI a vývojářských nástrojů.

Strudel je platforma AI, která je navržena pro automatizaci pokročilé technické podpory analýzou logů, produkčních dat, repozitářů kódu a historie podpory, aby identifikovala kořenové příčiny a doporučovala řešení. Cílem je snížit čas a inženýrské úsilí potřebné k řešení složitých případů podpory, zejména těch, které obvykle spotřebují seniorní technické zdroje. Propojením podpory přímo s technickými problémy se Strudel prezentuje jako nástroj, který může učinit podnikovou podporu rychlejší, efektivnější a škálovatelnější.

Měli jste vedení rolí ve společnostech jako LinkedIn, Udemy a Disney, než jste založili Strudel v roce 2025. Jaké zkušenosti z těchto rolí vás nakonec přesvědčily, že inženýrské týmy potřebují novou formu platformy „inženýrské inteligence“ poháněné umělou inteligencí, a jak tato myšlenka formovala založení Strudel?

Každá společnost, ve které jsem pracoval, měla jinou verzi stejného problému. V Disney byly sázky enormní – pokud se streamingová platforma vypnula během velké premiéry, nebylo to jen ztráta příjmů, ale také značkový okamžik. Na LinkedIn byla škála neúprosná. Bylo tam tisíce služeb, které všechny generovaly hluk, a dokonce i nejlepší týmy měly problémy s udržením kroků. Na Udemy jsem viděl štíhlý tým, který dělal hrdinské věci s omezeným nástrojem.

To, co spojilo všechny tři a zkušenosti mých spoluzakladatelů, Shai Rubina a Briana Kaufmana, kteří vedli inženýrské týmy, bylo, že inženýři trávili více času rekonstrukcí kontextu než skutečným řešením problémů. Někdo je v 2 hodiny ráno povolán a předtím, než může začít diagnostikovat, musí procházet Slackové vlákna, dashboardy, Jira tikety, deployment logy – jen aby pochopil, co se změnilo a kdy. Hraje vlastně detektiva, než může dělat svou skutečnou práci. To je plýtvání neuvěřitelně talentovanými lidmi.

Celou dobu jsem si myslel: musí existovat chytřejší způsob, jak povrchovat to, co skutečně záleží, když to záleží. To je vlastně semeno Strudel.

Mnohé společnosti měří finanční dopad výpadku ve formě ztráty příjmů nebo pokut za SLA. Z vašich zkušeností, jaké jsou některé z méně viditelných nákladů výpadků, které organizace systematicky podceňují?

Číslo výnosů se dostane do prezentace pro představenstvo, ale okamžitý dopad na výnosy je pouze zlomek toho, co výpadek skutečně stojí. Ty, které jsem viděl organizace systematicky přehlížet, spadají do několika kategorií.

První je důvěra zákazníků. Pokuty za SLA jsou právní konstrukcí – nezachycují zákazníka, který se tiše stáhne, nebo podnikový prospekt, který viděl vaši stránku stavu ve špatný okamžik a zvolil konkurenta. Ta škoda je pomalá, neviditelná a trvalá způsobem, který refundační šek prostě není.

Druhá je odchod inženýrů a vyhoření. Únavu z nočních služeb lze skutečně cítit. Když jsou vaši nejlepší inženýři opakovaně vtahováni do vysokého stresu – zejména těch, které mohli být zabráněny – začínají zpochybňovat, zda je toto správné místo pro budování své kariéry. Nahrazení seniorního inženýra stojí kdekoliv mezi jednou a dvěma jeho ročními platy, když vezmete v úvahu náklady na nábor, zaškolení a ztracené institucionální znalosti. Nikdo to neuvádí v post-mortem.

Třetí je náklad na ztracené příležitosti. Každá hodina, kterou inženýrský tým tráví hašením požárů, je hodina, kterou stráví bojováním místo budování produktu. To je těžké uvést do tabulky, ale kumulované přes měsíce to tiše rozmetá váš roadmap.

Inženýři jsou často odvoláni od budování nových funkcí, aby reagovali na incidenty ve výrobě. Jak toto neustálé hašení požárů ovlivňuje inovaci produktu a dlouhodobý rozvoj?

Vytvoří to daň na schopnost inženýrského týmu budovat. Každý tým má konečnou částku šířky pásma, a když významná část z toho neustále přesměruje incidenty, je kumulativní efekt na produktový vývoj závažný. Závazky roadmap se promeškají. Technický dluh se neplatí. Funkce se dodávají s menší pečlivostí, protože je tlak na dohánění ztraceného času.

To, co je zvláště škodlivé, je nepředvídatelnost. Tým může naplánovat sprint s dobrými úmysly, a pak majoritní incident vybuchne v úterý a všechno ostatní se stane sekundárním. Taková udržitelná nepředvídatelnost dělá téměř nemožným budovat kulturu hluboké práce – která je nakonec tím, co pohání nejlepší inženýrské výsledky.

Také vytváří sebenaplněný cyklus. Odkládané investice znamenají více incidentů, což znamená více hašení požárů, což znamená ještě méně času na investice do základních problémů. Ve Strudel se velkou částí toho, co budujeme, zabýváme zejména týmy SRE, kteří žijí tímto každodenním životem.

Strudel spojuje data zákaznické podpory, logy, produkční systémy a repozitáře kódu, aby identifikoval kořenové příčiny rychleji. Jak umělá inteligence spojuje tyto různé technické signály způsobem, který tradiční monitorovací nástroje nemohou?

Tradiční monitorovací nástroje jsou fundamentálně systémy upozornění. Jsou skvělé pro oznamování, že něco překročilo práh – latenci, chybovou sazbu, padající pod. Co nemohou udělat, je rozumět napříč doménami.

Neví, že vzestup chybové sazby ve vaší platební službě nastal čtyři minuty po nasazení do závislosti, a že zákaznická podpora tiketu zmínka o selhání při odběru přišla přibližně ve stejnou dobu, a že poslední případ, kdy tento vzorec se objevil ve vašich logech, byl před šesti měsíci během migrace databáze.

Tato korelace napříč doménami je to, co umožňuje umělá inteligence. Můžeme zacházet se Zendesk tiketem, GitHub commit, Datadog (DDOG ) stopou a CloudWatch logem jako s částí jednoho sjednoceného příběhu, spíše než izolovanými datovými body. Umělá inteligence povrchuje nejen to, co je rozbité, ale také pravděpodobné proč a kde – a zakládá to v důkazech, které lidský inženýr může skutečně ověřit a jednat. Neptáme se týmů, aby důvěřovaly černé skříňce. Dáváme jim dobře odůvodněnou hypotézu a náskok.

Popisujete Strudel jako dodavatele „inženýrské inteligence“. Co tento koncept znamená v praxi a jak se liší od konvenčních platforem observability nebo AIOps?

Kristin: Observability je fundamentálně o instrumentaci a viditelnosti – zajištění toho, že je k dispozici telemetrie a že týmy ji mohou dotazovat. AIOps, ve většině svých současných implementací, je o snížení hluku upozornění prostřednictvím ML-založené korelace a detekce anomálií. Oba jsou skutečně cenné a integrujeme se s nimi.

Ale inženýrská inteligence je vrstva nad tím. Bereme to, co dělá AIOps, a rozšiřujeme to. Kde AIOps říká, že něco je špatně, inženýrská inteligence pomáhá vám pochopit, proč je to špatně, kde to začalo a co s tím dělat – tahání signálů z celého vašeho stacku, včetně zdrojů, které tradiční nástroje AIOps ani nehledají, jako jsou tikety zákaznické podpory nebo změny kódu. Cílem není jen snížit hluk. Je to dát vašemu týmu kompletní, akční obraz, aby mohli problém vyřešit rychleji a vrátit se k budování.

Přemýšlejte o tom jako o rozdílu mezi detektorem kouře a vyšetřovatelem požárů. Observability a AIOps jsou detektor kouře – jsou nezbytné, ale zastavují se na upozornění. Inženýrská inteligence je to, co přichází poté: tady je to, co se stalo, tady je proč, tady je kde to začalo.

Agenti AI jsou stále více nasazováni pro automatizaci komplexních technických workflow. Jakou roli budete hrát agenti AI v diagnostice a řešení softwarových incidentů v příštích pěti letech?

Myslím, že zajímavější otázka není to, co budou agenti dělat – je to, co inženýři přestanou dělat. Nejlepší inženýři, se kterými jsem pracoval, se do tohoto oboru nedostali, aby trávili noci triáží upozornění nebo hledáním logů pro konfigurační změnu, kterou někdo provedl v pátek odpoledne. To není důvod, proč se stali dobrými ve své práci. Ale to je to, co zabírá obrovskou část jejich času.

V příštích pěti letech si myslím, že agenti převezmou velkou část této rutiny – opakující se, shodné, kontextové montážní práce, která je důležitá, ale není to, kde by měli seniorní inženýři trávit svůj čas. To uvolní lidi, aby se soustředili na komplexní problémy, architektonická rozhodnutí, věci, které skutečně vyžadují lidský úsudek.

To, co je pro mě vzrušující, je, že to není jen budoucí stav – vidíme to již nyní, včetně ve Strudel. Naší celý roadmap je orientována na odstranění administrativní a údržbářské práce z desek inženýrů. A co jsme zjistili, upřímně, je, že to mění to, co je možné pro tým. Můžete postavit více, pohybovat se rychleji a dělat to s méně lidmi – protože lidé, které máte, se soustředí na strategii a složitost, spíše než na placení svých povinností na opakující se práci. To se cítí jako významná změna v tom, jak se týmy budují a strukturují do budoucna.

Mnohé výpadky pocházejí z malých chyb nebo konfiguračních změn, které projdou testováním. Jak mohou systémy AI identifikovat jemné vzorce v kódu, logech nebo signálech infrastruktury dostatečně brzy, aby zabránily majoritním incidentům?

Dobře vytvořená umělá inteligence má zde skutečnou výhodu, a to je: nikdy nezapomíná a nikdy nespí. Lidský může spojit jemný logový vzorec dnes s něčím, co se stalo před šesti měsíci v úplně jiné části systému. Umělá inteligence může. Sleduje to všechno, pořád, a má mnohem delší a širší paměť než kterýkoli člen vašeho týmu.

Rovněž je něco, co slyším od zákazníků často: prevence je pouze tak dobrá, jako jsou data pod ní. Pokud jsou vaše logy nekonzistentní, neúplné nebo izolované v desítkách nástrojů, které spolu nemluví, umělá inteligence pracuje s fragmentovaným obrazem. Špatný vstup, špatný výstup – to je stále pravda. Trávíme spoustu času se zákazníky, kteří myslí na kvalitu dat a instrumentaci, protože nejlepší umělá inteligence na světě nemůže povrchovat signál, který nebyl zachycen.

Takže odpověď je obě: ano, umělá inteligence může chytit věci dříve a spojit tečky, které by lidé mohli minout. Ale týmy, které z toho dostanou největší hodnotu, jsou ty, které také udělaly práci, aby zajistily, že jejich data jsou skutečně worth reasoning.

Společnosti často investují značně do nástrojů pro detekci, ale stále bojují s průměrnou dobou na řešení. Jaké jsou největší bariéry, které brání organizacím v uzavření mezery mezi detekcí incidentu a skutečným řešením kořenové příčiny?

Detekce je v podstatě vyřešený problém. Většina týmů má upozornění. Vědí, že něco je špatně. Mezera je všechno, co se děje poté.

Když je inženýr povolán, nechodí do jasně definované situace s veškerým relevantním kontextem sestaveným. Chodí do chaosu. Musí zjistit, co se změnilo, kdy se to změnilo, který systém to dotkl, zda je to zákaznický dopad, zda je to související s něčím, co se stalo minulý týden. Tahají z Slacku, z dashboardů, z deployment logů, z podpůrných tiketů – dělají tu montážní práci ručně, pod tlakem, často uprostřed noci.

Tato montáž kontextu je úzké místo. Není to, že inženýři a týmy technické podpory nevědí, jak řešit problémy – je to, že tráví první 30 až 60 minut každého incidentu pouze tím, že se snaží pochopit, na co se dívají. To je úzké místo. To je tam, kde Strudel žije. Naší celou tezi je, že pokud můžete dát inženýrovi koherentní, důkazem podložený obraz toho, co se stalo a proč – právě když to potřebuje – dramaticky zkracujete tu mezeru. Práce na řešení je stále jejich. My jim pouze dáváme rychlejší start.

Jakmile systémy AI začnou analyzovat produkční data, kódy a provozní logy, jaké úvahy o správě nebo zabezpečení by inženýrské týmy měly mít na paměti při nasazování těchto nástrojů?

Ještě jednu věc, o které jsem velmi přesvědčen: lidé by měli stále kontrolovat kód, který jde do produkce.

Mluvím s mnoha inženýry o tomto a jedna věc, kterou slyším opakovaně, je, že AI píše chyby efektivně a chytrým způsobem. Skutečně chytrým způsobem. Takovým způsobem, který může být skutečně obtížné chytit – i pro seniorní inženýry, kteří kontrolují kód pečlivě. Chyby nejsou vždy zjevné. Mohou vypadat dokonale rozumně na první pohled.

Takže když AI píše více a více kódu, který končí v produkci, si myslím, že uvidíme více těchto jemných, obtížně detekovatelných problémů, které projdou – ne proto, že by někdo byl nedbalý, ale protože povaha chyb AI je jiná. Těžší na rozpoznání při kontrole. Těžší na odhalení během testování.

Upřímně? To je jeden z důvodů, proč si myslím, že případ pro to, co Strudel dělá, bude pouze silnější s časem. Pokud více chyb končí v produkci, schopnost je najít a vyřešit rychleji se stává důležitější, ne méně. Otázka správy není pouze o kontrole přístupu k datům a oprávněních – i když tyto věci záleží a týmy by měly být ohledně nich uvážlivé. Je to také o udržování lidí na správných kontrolních bodech, zejména kolem všeho, co se dotýká produkce.

Při pohledu do budoucnosti si myslíte, že budoucnost inženýrské spolehlivosti bude směřovat k infrastruktuře „první AI“, kde autonomní systémy monitorují, diagnostikují a dokonce opravují problémy, než si jich lidé všimnou? Pokud ano, jak vypadá tato budoucnost pro inženýry?

Myslím, že směřujeme tímto směrem, ale jsem pragmatičtí ohledně časového rámce. Plně autonomní systémy, které řeší produkční incidenty bez lidského vědomí – to není tam, kde jsme, a nemyslím si, že to bude v příštích několika letech. A myslím, že to je v pořádku.

To, čemu věřím, je, že smyčka se stane mnohem užší a méně bolestivou. Budoucnost, na kterou se těším, není taková, kde jsou lidé odstraněni z rovnice – je to taková, kde lidé integrovaní do procesu tráví svůj čas na částech, které skutečně vyžadují lidský úsudek. Rozhodnutí. Nové situace. Incident, který jste nikdy neviděli dříve. AI řeší shodné vzorce, kontextové montáže, rutinní triáž. Inženýři řeší rozhodnutí.

Pro inženýry samotné si myslím, že to vypadá tak, že stráví méně času na volání uprostřed noci pro věci, které je nemusely probudit, a více času budováním systémů, které se nezhroutí. Hašení požárů nezmizí úplně. Ale stane se výjimkou, spíše než výchozím stavem pro inženýry v společnosti, která běží software ve velkém měřítku. To je budoucnost, kterou stojí za to budovat.

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