Kristin Isaac, CEO i współzałożycielka Strudel – seria wywiadów

Kristin Isaac, CEO i współzałożycielka Strudel, jest doświadczonym liderem technologii przedsiębiorstw, który pełnił stanowiska kierownicze w LinkedIn, Udemy, ESPN i Disney, zanim założył Strudel. Obecnie skupia się na rozwiązywaniu jednego z największych punktów tarcia w organizacjach oprogramowania: przepaści między obsługą klienta a inżynierią. W Strudel buduje platformę napędzaną przez sztuczną inteligencję, która pomaga zespołom wsparcia technicznego rozwiązywać skomplikowane problemy szybciej, łącząc prośby o wsparcie bezpośrednio z inteligencją inżynierską. Jej doświadczenie w skalowaniu zespołów, tworzeniu strategii wejścia na rynek i napędzaniu wzrostu w organizacjach globalnych pomogło ukształtować szybki wczesny popyt i silną pozycję Strudel na rynku przedsiębiorstw AI i narzędzi programistycznych.

Strudel to platforma AI zaprojektowana do automatyzacji zaawansowanego wsparcia technicznego poprzez analizę logów, danych produkcyjnych, repozytoriów kodu i historii poprzednich przypadków wsparcia w celu identyfikacji przyczyn pierwotnych i zalecenia rozwiązań. Jej celem jest zmniejszenie czasu i wysiłku inżynierskiego niezbędnego do rozwiązania trudnych przypadków wsparcia, zwłaszcza tych, które zwykle pochłaniają seniorów zasobów technicznych. Łącząc wsparcie bezpośrednio z podstawowymi problemami technicznymi, Strudel pozycjonuje się jako narzędzie, które może uczynić operacje wsparcia przedsiębiorstw szybszymi, bardziej wydajnymi i znacznie bardziej skalowalnymi.

Pełniłeś role kierownicze w organizacjach takich jak LinkedIn, Udemy i Disney, zanim założyłeś Strudel w 2025 roku. Jakie doświadczenia z tych ról ostatecznie przekonały Cię, że zespoły inżynierskie potrzebują nowego rodzaju platformy „inteligencji inżynierskiej” napędzanej przez AI, i jak to spostrzeżenie ukształtowało założenie Strudel?

Każda firma, w której pracowałem, miała inną wersję tego samego problemu. W Disney, stawki były ogromne – jeśli platforma streamingowa uległa awarii podczas dużego wydania, nie było to tylko uderzenie w przychody, ale także moment marki. W LinkedIn, skala była nieustanna. Było tysiące usług generujących hałas, a nawet najlepsze zespoły miały trudności z nadążaniem. W Udemy zobaczyłem zespół lean robiący heroiczną robotę z ograniczonymi narzędziami.

To, co połączyło wszystkie trzy i doświadczenie moich współzałożycieli, Shai Rubin i Briana Kaufmana, prowadzących zespoły inżynierskie, polegało na tym, że inżynierowie spędzali więcej czasu na odtwarzaniu kontekstu niż na rzeczywistym rozwiązywaniu problemów. Ktoś dostaje wezwanie o godz. 2 nad ranem, a zanim może nawet zacząć diagnozować, przeszukuje wątki Slack, pulpity, bilety Jira, logi wdrożenia – po prostu próbując zrozumieć, co się zmieniło i kiedy. Grają tak naprawdę w detektywa, zanim będą mogli wykonać swoją rzeczywistą pracę. To marnowanie niesamowicie utalentowanych ludzi.

Ciągle myślałem: musi być mądrzejszy sposób, aby wyłonić to, co naprawdę się liczy, kiedy się liczy. To jest tak naprawdę ziarno Strudel.

Wiele firm mierzy wpływ przestojów na przychody w postaci utraconych przychodów lub kar umownych. Twoim doświadczeniu, jakie są mniej widoczne koszty przestojów, których organizacje systematycznie zaniżają?

Liczba przychodu trafia do prezentacji zarządu, ale natychmiastowy wpływ przychodu stanowi tylko ułamek tego, co przestoje naprawdę kosztują. Te, które widziałem, organizacje systematycznie pomijają, mieszczą się w kilku kategoriach.

Pierwsza to zaufanie klienta. Kary umowne są konstrukcją prawną – nie ujmują klienta, który cicho odchodzi, lub przedsiębiorstwa, które zobaczyło Twoją stronę statusu w złym momencie i wybrało konkurenta. Ten uszczerbek jest powolny, niewidzialny i trwały w sposób, w jaki czek refundacyjny po prostu nie jest.

Druga to utrata inżynierów i wypalenie. Zmęczenie dyżurne jest realne. Kiedy Twoi najlepsi inżynierowie są wielokrotnie wciągani do incydentów o wysokim stresie – zwłaszcza tych, które mogłyby zostać zapobiegane – zaczynają kwestionować, czy to jest odpowiednie miejsce do budowania swojej kariery. Zamiana starszego inżyniera kosztuje gdzieś między jednym a dwoma razy jego roczne wynagrodzenie, gdy weźmie się pod uwagę koszty rekrutacji, wdrożenia i utraconej wiedzy instytucjonalnej. Nikt nie umieszcza tego w postmortem.

Trzecia to koszt okazji. Każda godzina, którą zespół inżynierski spędza na gaszeniu pożarów, to godzina, którą nie spędza na budowaniu produktu. To trudno umieścić w arkuszu, ale skumulowane w miesiącach, to cicho wybucha Twój plan drogi.

Inżynierowie są często odrywani od budowy nowych funkcji, aby odpowiedzieć na incydenty produkcyjne. Jak to ciągłe gaszenie pożarów wpływa na innowacje produktowe i długoterminowy rozwój?

Tworzy to podatek od możliwości zespołu inżynierskiego do budowy. Każdy zespół ma skończoną ilość pasma, a gdy znacząca część tego ciągle jest przekierowywana do incydentów, efekt kumulatywny na rozwój produktu jest poważny. Zobowiązania dotyczące planu drogi są pomijane. Dług techniczny nie jest spłacany. Funkcje są wysyłane z mniej rygorystycznie, ponieważ jest presja, aby nadrobić stracony czas.

To, co jest szczególnie szkodliwe, to nieprzewidywalność. Zespół może zaplanować swój sprint z dobrymi intencjami, a potem duży incydent wybucha we wtorek, a wszystko inne staje się wtórne. Tego rodzaju utrzymująca się nieprzewidywalność sprawia, że jest prawie niemożliwe zbudowanie kultury głębokiej pracy – co ostatecznie napędza najlepsze wyniki inżynierskie.

To również tworzy samowzmacniającą się pętlę. Odroczona inwestycja oznacza więcej incydentów, co oznacza więcej gaszenia pożarów, co oznacza jeszcze mniej czasu na inwestowanie w podstawowe problemy. W Strudel, duża część tego, co budujemy, jest specjalnie dla zespołów SRE, którzy doświadczają tego każdego dnia.

Strudel łączy dane wsparcia klienta, logi, systemy produkcyjne i repozytoria kodu, aby szybciej identyfikować przyczyny pierwotne. Jak AI łączy te różne sygnały techniczne w sposób, w jaki tradycyjne narzędzia monitorowania nie mogą?

Tradycyjne narzędzia monitorowania są fundamentalnie systemami alertów. Są wspaniałe w informowaniu, że coś przekroczyło próg – spięcie opóźnienia, wzrost stawki błędów, awaria pod. Co nie mogą zrobić, to rozumowanie w domenach.

Nie wiedzą, że skok stawki błędów w Twojej usłudze płatności wystąpił cztery minuty po wdrożeniu zależności, i że bilet wsparcia klienta, w którym wymieniono awarie podczas kasowania, przychodzi wokół tego samego czasu, i że ostatni raz, kiedy ten wzorzec pojawił się w Twoich logach, był sześć miesięcy temu podczas migracji bazy danych.

To przekroczenie domen jest tym, co umożliwia AI. Możemy traktować bilet Zendesk, commit GitHub, ślad Datadog (DDOG ) i log CloudWatch jako część jednej spójnej historii, a nie izolowanych punktów danych. AI wyłania nie tylko to, co jest złamane, ale także prawdopodobne dlaczego i gdzie – i opiera się to na dowodach, które rzeczywisty inżynier może rzeczywiście zweryfikować i podjąć działanie. Nie prosimy zespołów o zaufanie czarnej skrzynce. Dajemy im dobrze uzasadnioną hipotezę i przewagę.

Opisujesz Strudel jako dostarczający „inteligencję inżynierską”. Co oznacza ta koncepcja w praktyce, i jak różni się od konwencjonalnych platform obserwacyjnych lub AIOps?

Kristin: Obserwowalność jest fundamentalnie o instrumentacji i widoczności – upewnieniu się, że telemetria jest tam i że zespoły mogą ją zapytać. AIOps, w większości jego bieżących implementacji, jest o redukowaniu hałasu alertów za pomocą korelacji i wykrywania anomalii opartych na ML. Oba są prawdziwie wartościowe, i integrujemy się z nimi.

Ale inteligencja inżynierska jest warstwą powyżej. Robimy to, co robi AIOps, i rozwijamy to. Gdzie AIOps mówi Ci, że coś jest nie tak, inteligencja inżynierska pomaga Ci zrozumieć, dlaczego jest nie tak, skąd się zaczęło i co z tym zrobić – ściągając sygnały z całego Twojego stosu, w tym źródeł, które tradycyjne narzędzia AIOps nawet nie oglądają, takich jak bilety wsparcia klienta lub zmiany kodu. Celem nie jest tylko zmniejszenie hałasu. Jest to dać Twojemu zespołowi pełen, działający obraz, aby mogli rozwiązać problem szybciej i wrócić do budowy.

Rozważ to jako różnicę między czujnikiem dymu a śledczym pożarów. Obserwowalność i AIOps to czujnik dymu – niezastąpiony, ale zatrzymują się na alarmie. Inteligencja inżynierska to to, co przychodzi po: oto, co się stało, oto, dlaczego, oto, skąd się zaczęło.

Agenci AI są coraz częściej wdrażani do automatyzacji złożonych przepływów technicznych. Jaką rolę widzisz agenci AI odgrywając w diagnozowaniu i rozwiązywaniu incydentów oprogramowania w ciągu najbliższych pięciu lat?

Myślę, że bardziej interesujące pytanie nie jest tym, co agenci będą robić – jest to, czego inżynierowie przestaną robić. Najlepsi inżynierowie, z którymi pracowałem, nie weszli do tego pola, aby spędzać noce na triażu alertów lub przeszukiwaniu logów w poszukiwaniu zmiany konfiguracyjnej, którą ktoś wykonał w piątek popołudniu. To nie jest powód, dla którego są dobrzy w swojej pracy. Ale to jest to, na co spędzają ogromną część swojego czasu.

W ciągu najbliższych pięciu lat myślę, że agenci przejmą dużo tego szarpania – powtarzalnej, dopasowującej wzorce, montażu kontekstu pracy, która jest ważna, ale nie tam, gdzie seniorzy talentów inżynierskich powinni spędzać swój czas. To uwolni ludzi, aby skoncentrować się na złożonych problemach, decyzjach architektonicznych, rzeczach, które wymagają naprawdę ludzkiej oceny.

To, co jest ekscytujące, to to, że to nie jest tylko stan przyszłości – widzimy to już teraz, w tym w Strudel. Cały nasz plan drogi jest zorientowany na usuwanie administracyjnej i konserwacyjnej pracy z talerzy inżynierów. I to, co znajdujemy, szczerze, to to, że zmienia to, co jest możliwe dla zespołu. Możesz zbudować więcej, poruszać się szybciej i robić to z mniej ludzi – ponieważ ludzie, których masz, koncentrują się na strategii i złożoności, a nie na płaceniu swoich podatków na powtarzalne rzeczy. To wydaje się znaczącą zmianą w tym, jak zespoły są budowane i strukturyzowane w przyszłości.

Wiele przestojów pochodzi z małych błędów lub zmian konfiguracyjnych, które przemykają przez testy. Jak systemy AI mogą identyfikować subtelne wzorce w kodzie, logach lub sygnałach infrastruktury wystarczająco wcześnie, aby zapobiec dużym incydentom?

Dobrze zaprojektowana AI ma tutaj prawdziwą przewagę, i nie jest to tak, że jest mądrzejsza od Twoich inżynierów – jest to tak, że nigdy nie zapomina i nigdy nie śpi. Człowiek może nie połączyć subtelnych wzorców logów dzisiaj z czymś, co wydarzyło się sześć miesięcy temu w zupełnie innej części systemu. AI może. Obserwuje wszystko, cały czas, i ma znacznie dłuższą i szerszą pamięć niż jakikolwiek członek Twojego zespołu.

Powiedzmy jednak, że jest coś innego, co słyszałem od klientów wiele razy: zapobieganie jest tylko tak dobre, jak dane pod spodem. Jeśli Twoje logi są niespójne, niepełne lub rozproszone w tuzinie narzędzi, które nie rozmawiają ze sobą, AI pracuje z fragmentarycznym obrazem. Śmieci na wejściu, śmieci na wyjściu – to nadal prawda. Spędzamy dużo czasu z klientami, pomagając im myśleć o jakości danych i instrumentacji, ponieważ najlepsza AI na świecie nie może wyłonić sygnału, który nie został wcześniej przechwycony.

Więc odpowiedź brzmi: tak, AI może złapać rzeczy wcześniej i połączyć kropki, których ludzie byliby pomijali. Ale zespoły, które uzyskują największą wartość z niej, są tymi, które również zrobili pracę, aby upewnić się, że ich dane są naprawdę warte rozumnego.

Firmy często inwestują dużo w narzędzia wykrywania, ale nadal mają trudności z czasem rozwiązania. Jakie są największe bariery, które uniemożliwiają organizacjom zamknięcie przepaści między wykryciem incydentu a rzeczywistym rozwiązaniem przyczyny?

Wykrywanie jest w dużej mierze rozwiązane. Większość zespołów ma alerty. Wiedzą, że coś jest nie tak. Przepaść jest wszystkim, co dzieje się następnie.

Gdy inżynier dostaje wezwanie, nie wchodzi w jasną sytuację z wszystkimi istotnymi kontekstami starannie zebranymi. Wchodzi w bałagan. Musi się dowiedzieć, co się zmieniło, kiedy to się zmieniło, jaki system to dotknęło, czy jest wpływ na klienta, czy jest to związane z czymś, co wydarzyło się w zeszłym tygodniu. Ciągnie to z Slack, z pulpitu, z logów wdrożenia, z biletów wsparcia – robiąc tę pracę montażu ręcznie, pod presją, często w środku nocy.

Praca montażu kontekstu jest wąskim gardłem. Nie jest to tak, że inżynierowie i zespoły techniczne nie wiedzą, jak rozwiązać problemy – jest to tak, że spędzają pierwsze 30 do 60 minut każdego incydentu, próbując po prostu zrozumieć, na co patrzą. To jest tam, gdzie Strudel żyje. Cała nasza teza polega na tym, że jeśli możesz dać inżynierowi spójny, poparty dowodami obraz tego, co się stało i dlaczego – właśnie wtedy, kiedy tego potrzebuje – dramatycznie kompresujesz tę przepaść. Praca rozwiązania jest nadal ich. Po prostu dostają ich do linii startowej znacznie szybciej.

Jakie powinny być rozważania dotyczące zarządzania lub bezpieczeństwa, które zespoły inżynierskie powinny mieć na uwadze podczas wdrażania tych narzędzi, gdy AI zaczyna analizować dane produkcyjne, kodowe i operacyjne?

Rzecz, o której najbardziej się martwię, to: ludzie powinni nadal przeglądać kod, który trafia do produkcji.

Porozmawiałem z wieloma inżynierami o tym, i jedna rzecz, o której słyszałem wielokrotnie, to: AI pisze błędy wydajnie i sprytnie. Bardzo sprytnie, tak naprawdę. W sposób, który może być naprawdę trudny do złapania – nawet dla seniorów inżynierów, którzy przeglądają kod starannie. Błędy nie są zawsze oczywiste. Mogą wyglądać idealnie na pierwszy rzut oka.

Więc gdy AI pisze coraz więcej kodu, który trafia do produkcji, myślę, że zobaczymy więcej tych subtelnym, trudnych do wykrycia problemów, które przemykają – nie dlatego, że ktokolwiek był nieostrożny, ale dlatego, że natura błędów AI jest inna. Trudniejsza do wykrycia w przeglądzie. Trudniejsza do złapania w teście.

Szczerze? To jeden z powodów, dla którego myślę, że przypadek Strudel tylko się umacnia. Jeśli więcej błędów trafia do produkcji, zdolność do ich znalezienia i rozwiązania szybciej staje się jeszcze ważniejsza, a nie mniej. Kwestia zarządzania nie dotyczy tylko kontroli dostępu do danych i uprawnień – chociaż te sprawy są ważne, i zespoły powinny być nimi ostrożne. To również o utrzymaniu ludzi w odpowiednich punktach kontrolnych, zwłaszcza wokół wszystkiego, co dotyka produkcji.

Spójrzając w przyszłość, czy myślisz, że przyszłość inżynierii niezawodności będzie się przesuwać w kierunku infrastruktury AI-pierwszej, gdzie autonomiczne systemy monitorują, diagnozują i nawet naprawiają problemy, zanim ludzie będą o nich wiedzieć?

Myślę, że idziemy w tym kierunku, ale jestem pragmatyczny, jeśli chodzi o harmonogram. W pełni autonomiczne systemy rozwiązujące incydenty produkcyjne bez żadnej świadomości ludzi – to nie jest tam, gdzie jesteśmy, i nie myślę, że będziemy tam w ciągu najbliższych kilku lat. I myślę, że to w porządku.

To, w co wierzę, to to, że pętla staje się znacznie ciaśniejsza i mniej bolesna. Przyszłość, której się ekscytuję, nie jest taka, w której ludzie są usuwani z równania – jest to taka, w której ludzie wbudowani w proces spędzają swój czas na częściach, które naprawdę wymagają ich. Rozstrzygnięcia. Nowe sytuacje. Incydent, którego nigdy nie widzieli. AI zajmuje się dopasowaniem wzorców, montażem kontekstu, rutynowym triażem. Inżynierowie zajmują się decyzjami.

Dla inżynierów samych myślę, że wygląda to tak: mniej czasu na dyżurze w środku nocy z powodu rzeczy, które nie musiały ich budzić, i więcej czasu na budowanie systemów, które nie psują się od samego początku. Gaszenie pożarów nie znika całkowicie. Ale staje się wyjątkiem, a nie domyślnym stanem bycia inżynierem w firmie, która prowadzi oprogramowanie na dużą skalę. To jest przyszłość, w kierunku której warto budować.

Dziękuję za wspaniały wywiad, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić Strudel.