Kristin Isaac, CEO și Co-Fondator la Strudel – Seria de Interviuri

Kristin Isaac, CEO și Co-Fondator la Strudel, este un lider veteran în tehnologia enterprise, care a ocupat funcții de conducere la LinkedIn, Udemy, ESPN și Disney, înainte de a lansa Strudel. Acum, se concentrează pe rezolvarea uneia dintre cele mai mari probleme de fricțiune din organizațiile de software: decalajul dintre suportul clienților și inginerie. La Strudel, ea construiește o platformă bazată pe inteligență artificială care ajută echipele de suport tehnic să rezolve probleme complexe mai rapid, conectând direct solicitările de suport la inteligența ingineriei. Experiența sa în scalarea echipelor, crearea de strategii de piață și stimularea creșterii în organizații globale a ajutat la crearea unei tracțiuni rapide și poziționării puternice a Strudel în piața de inteligență artificială și instrumente pentru dezvoltatori.

Strudel este o platformă de inteligență artificială concepută pentru a automatiza suportul tehnic avansat, analizând jurnalele, datele de producție, depozitele de cod și istoricul suportului pentru a identifica cauzele rădăcină și a recomanda soluții. Scopul său este de a reduce timpul și efortul de inginerie necesar pentru a rezolva cazurile de suport dificile, în special escaladările care consumă în mod normal resurse tehnice senior. Prin conectarea directă a suportului la problemele tehnice subiacente, Strudel se poziționează ca un instrument care poate face operațiunile de suport enterprise mai rapide, mai eficiente și mai scalabile.

Ați ocupat funcții de conducere în organizații precum LinkedIn, Udemy și Disney, înainte de a fonda Strudel în 2025. Care au fost experiențele din aceste roluri care v-au convins că echipele de inginerie au nevoie de o nouă platformă de “inteligență ingineriei” bazată pe inteligență artificială și cum a influențat această perspectivă fondarea Strudel?

Fiecare companie la care am lucrat avea o versiune diferită a aceleiași probleme. La Disney, mizele erau enorme – dacă o platformă de streaming se închidea în timpul unui lansări majore, nu era doar o lovitură financiară, ci și o problemă de imagine a brandului. La LinkedIn, scala era nemiloasă. Existau mii de servicii care generau zgomot, iar chiar și cele mai bune echipe se luptau să țină pasul. La Udemy, am văzut o echipă mică care făcea lucruri eroice cu unelte limitate.

Ceea ce le-a unit pe toți și experiența mea, precum și cea a co-fondatorilor mei, Shai Rubin și Brian Kaufman, care au condus echipe de ingineri, a fost că inginerii petrec mai mult timp reconstruind contextul decât rezolvând problemele în sine. Cineva este anunțat la 2 dimineața, și înainte de a putea începe să diagnosticheze, trebuie să caute prin firele de discuții Slack, panouri de control, bilete Jira, jurnale de implementare – doar pentru a înțelege ce s-a schimbat și când. Ei joacă, în esență, rolul detectivului înainte de a-și putea face propriul lor job. Acesta este un irosire a unor oameni incredibil de talentați.

M-am întrebat mereu: trebuie să existe o modalitate mai inteligentă de a aduce la suprafață ceea ce contează cu adevărat, atunci când contează. Acesta este, în esență, sămânța Strudel.

Multe companii măsoară impactul financiar al timpului de închidere în termeni de venituri pierdute sau penalități SLA. În experiența dvs., care sunt unele dintre costurile mai puțin vizibile ale închiderilor pe care organizațiile le subestimează în mod constant?

Numărul de venituri face parte din prezentarea consiliului de administrație, dar impactul imediat asupra veniturilor reprezintă doar o fracțiune din ceea ce închiderea efectiv costă. Cele pe care le-am văzut organizațiile să le rateze în mod constant se încadrează în câteva categorii.

Prima dintre ele este încrederea clienților. Penalitățile SLA sunt o construcție juridică – ele nu captează clientul care se desparte în mod discret sau prospectul de enterprise care a văzut pagina de stare la momentul nepotrivit și a ales un concurent. Această deteriorare este lentă, invizibilă și permanentă într-un mod în care o compensație nu este.

A doua este atragerea și arderea inginerilor. Oboseala de a fi de gardă este reală. Când cei mai buni ingineri ai dvs. sunt trași în mod repetat în incidente de stres ridicat – în special cele care ar fi putut fi prevenite – ei încep să se întrebe dacă acesta este locul potrivit pentru a-și construi cariera. Înlocuirea unui inginer senior costă undeva între una și două ori salariul lor anual, atunci când se iau în considerare recrutarea, integrarea și cunoștințele instituționale pierdute. Nimeni nu pune asta în post-mortem.

A treia este costul oportunității. Fiecare oră pe care o petrec o echipă de ingineri luptându-se cu incendii este o oră în care nu se construiește un produs. Acest lucru este greu de pus pe o foaie de calcul, dar, în timp, o face să explodeze planul dvs. de drum.

Inginerii sunt adesea trași departe de la construirea de noi funcții pentru a răspunde la incidente de producție. Cum afectează această luptă constantă inovația produsului și planurile de dezvoltare pe termen lung?

Aceasta creează o taxă pe capacitatea echipei dvs. de a construi. Fiecare echipă are o cantitate finită de lățime de bandă, și atunci când o parte semnificativă din aceasta este redirecționată către incidente, efectul de compunere asupra dezvoltării produsului este sever. Angajamentele de drumaj se pierd. Datoria tehnică nu este plătită. Funcțiile sunt expediate cu mai puțină rigurozitate, deoarece există presiunea de a recupera timpul pierdut.

Ceea ce este deosebit de dăunător este imprevizibilitatea. O echipă poate planifica sprintul cu intenții bune, și apoi un incident major izbucnește marți și totul devine secundar. Acest tip de imprevizibilitate susținută face aproape imposibilă construirea unei culturi a muncii profunde – care este, în cele din urmă, ceea ce conduce cele mai bune rezultate ale ingineriei.

Acesta creează, de asemenea, un ciclu autoîntreținător. Investițiile amânate înseamnă mai multe incidente, ceea ce înseamnă mai multă luptă cu incendii, ceea ce înseamnă și mai puțin timp pentru a investi în problemele subiacente. La Strudel, o parte importantă a ceea ce construim este destinată în special echipelor SRE care trăiesc aceasta în fiecare zi.

Strudel conectează datele de suport clienți, jurnalele, sistemele de producție și depozitele de cod pentru a identifica cauzele rădăcină mai rapid. Cum adună inteligența artificială aceste semnale tehnice diferite într-un mod în care instrumentele de monitorizare tradiționale nu pot?

Instrumentele de monitorizare tradiționale sunt, în esență, sisteme de alertă. Sunt excelente la a vă spune că ceva a depășit un prag – o creștere a latenței, o rată de eroare în creștere, un pod care se prăbușește. Ceea ce nu pot face este să raționeze între domenii.

Ele nu știu că o creștere a ratei de eroare în serviciul dvs. de plată a apărut la patru minute după o implementare a unei dependențe și că un bilet de suport clienți care menționează eșecuri la checkout a fost trimis în jurul aceleiași ore, și că ultima dată când acest model a apărut în jurnalele noastre a fost cu șase luni în urmă, în timpul unei migrări a bazei de date.

Această corelare între domenii este ceea ce permite inteligența artificială. Putem trata un bilet de suport Zendesk, un angajament GitHub, o urmă Datadog și un jurnal CloudWatch ca parte a unei povești unificate, mai degrabă decât puncte de date izolate. Inteligența artificială aduce la suprafață nu doar ce este defect, ci și probabilul de ce și unde – și se bazează pe dovezi pe care un inginer uman le poate verifica și acționa. Nu cerem echipelor să aibă încredere într-o cutie neagră. Le oferim o ipoteză bine motivată și un avans.

Descrieți Strudel ca oferind “inteligență ingineriei”. Ce înseamnă acest concept în practică și cum se diferențiază de platformele convenționale de observabilitate sau AIOps?

Kristin: Observabilitatea este fundamental despre instrumentare și vizibilitate – asigurându-vă că telemetria este acolo și că echipele pot interoga-o. AIOps, în majoritatea implementărilor sale actuale, este despre reducerea zgomotului de alertă prin corelare și detectare a anomaliilor bazate pe ML. Ambele sunt cu adevărat valoroase, și ne integrăm cu ele.

Dar inteligența ingineriei este un strat deasupra. Luăm ceea ce face AIOps și extindem. Unde AIOps vă spune că ceva este în neregulă, inteligența ingineriei vă ajută să înțelegeți de ce este în neregulă, de unde a început și ce să faceți în legătură cu acesta – extrăgând semnale de pe întregul stivuit, inclusiv surse pe care uneltele AIOps tradiționale nu le examinează, cum ar fi bilețele de suport clienți sau modificările codului. Scopul nu este doar să reducă zgomotul. Este să oferiți echipei dvs. o imagine completă și acționabilă, astfel încât să poată rezolva problema mai rapid și să se întoarcă la construire.

Să considerăm diferența dintre un detector de fum și un investigator de incendiu. Observabilitatea și AIOps sunt detectorul de fum – esențial, dar se opresc la alarmă. Inteligența ingineriei este ceea ce vine după: iată ce s-a întâmplat, de ce, de unde a început.

Agenții de inteligență artificială sunt din ce în ce mai des utilizați pentru a automatiza fluxuri de lucru tehnice complexe. Care este rolul pe care îl vedeți agenții de inteligență artificială jucând în diagnosticarea și rezolvarea incidentelor de software în următorii cinci ani?

Cred că întrebarea mai interesantă nu este ce vor face agenții – ci ce vor înceta inginerii să facă. Cei mai buni ingineri cu care am lucrat nu s-au angajat în acest domeniu pentru a-și petrece nopțile triind alerte sau căutând prin jurnale pentru o modificare a configurației pe care cineva a făcut-o vineri după-amiază. Acesta nu este motivul pentru care au devenit buni în ceea ce fac.

În următorii cinci ani, cred că agenții preiau o parte din această muncă de rutină – munca de recunoaștere a modelelor, asamblarea contextului, lucrul care este important, dar nu acolo unde talentul de inginer senior ar trebui să-și petreacă timpul. Acesta eliberează oamenii pentru a se concentra pe probleme complexe, pe deciziile arhitecturale, lucrurile care necesită într-adevăr judecata umană.

Ceea ce este interesant pentru mine este că acesta nu este doar un statut viitor – îl vedem deja desfășurându-se, inclusiv la Strudel. Întregul nostru drumaj este orientat către eliminarea muncii administrative și de întreținere de pe platourile inginerilor. Și ceea ce găsim, sincer, este că acesta schimbă ceea ce este posibil pentru o echipă. Puteți construi mai mult, puteți muta mai repede și puteți face acest lucru cu mai puțini oameni – pentru că oamenii pe care îi aveți se concentrează pe strategie și complexitate, mai degrabă decât pe plata datoriilor pentru lucrurile repetitive. Acesta pare a fi un schimb semnificativ în modul în care echipele sunt construite și structurate înainte.

Multe închideri provin din bug-uri mici sau modificări de configurare care trec prin testare. Cum pot sistemele de inteligență artificială identifica modele subtile în cod, jurnale sau semnale de infrastructură suficient de devreme pentru a preveni incidente majore?

Inteligența artificială bine creată are un avantaj real aici, și nu pentru că este mai deșteaptă decât inginerii dvs. – ci pentru că nu uită niciodată și nu doarme niciodată. Un om poate să nu conecteze un model subtil de jurnal astăzi cu ceva care s-a întâmplat cu șase luni în urmă într-o parte complet diferită a sistemului. Inteligența artificială poate. Ea urmărește totul, tot timpul, și are o memorie mult mai lungă și mai largă decât orice individ din echipa dvs.

Acesta este, de asemenea, un lucru pe care îl auzim de la clienți foarte des: prevenirea este la fel de bună ca datele de sub ea. Dacă jurnalele dvs. sunt inconsistente, incomplete sau fragmentate în zeci de unelte care nu vorbesc unele cu altele, inteligența artificială lucrează cu o imagine fragmentată. Gunoi în, gunoi afară – acesta este încă adevărat. Petrecem mult timp cu clienții, ajutându-i să gândească despre calitatea datelor și instrumentare, deoarece cea mai bună inteligență artificială din lume nu poate aduce la suprafață un semnal pe care nu a fost capturat din start.

Companiile investesc adesea foarte mult în instrumente de detectare, dar totuși se luptă cu timpul mediu de rezolvare. Care sunt cele mai mari bariere care împiedică organizațiile să închidă decalajul dintre detectarea incidentelor și rezolvarea reală a cauzelor rădăcină?

Detectarea este, în mare măsură, o problemă rezolvată în acest moment. Majoritatea echipelor au alerte. Știu că ceva este în neregulă. Decalajul este tot ceea ce se întâmplă după.

Când un inginer este anunțat, el nu intră într-o situație clară, cu toate contextele relevante asamblate. El intră într-un haos. Trebuie să afle ce s-a schimbat, când s-a schimbat, care sistem a atins, dacă există un impact asupra clientului, dacă este legat de ceva care s-a întâmplat săptămâna trecută. Ei extrag din Slack, din panouri de control, din bilete Jira, din jurnale de implementare – făcând această muncă de asamblare manual, sub presiune, adesea în mijlocul nopții.

Această asamblare a contextului este blocajul. Nu este că inginerii și echipele de suport tehnic nu știu cum să rezolve probleme – ci că petrec primii 30-60 de minute din fiecare incident doar încercând să înțeleagă ce se uită. Acesta este punctul în care trăiește Strudel. Teza noastră întreagă este că, dacă puteți oferi un inginer o imagine coerentă, bazată pe dovezi, a ceea ce s-a întâmplat și de ce – exact atunci când are nevoie – comprimați dramatic acest decalaj. Lucrul de rezolvare este încă al lor. Noi doar îi aducem la linia de start mult mai repede.

Pe măsură ce sistemele de inteligență artificială încep să analizeze datele de producție, codul sursă și jurnalele de operare, care ar trebui să fie considerațiile de guvernanță sau securitate pe care echipele de ingineri ar trebui să îi țină minte atunci când implementează aceste instrumente?

Lucrul despre care simt cel mai puternic aici este acesta: oamenii ar trebui să revizuiască în continuare codul care intră în producție.

Am discutat cu mulți ingineri despre acest lucru, și un lucru pe care îl auzi mereu este că inteligența artificială scrie bug-uri eficient și inteligent. Foarte inteligent, de fapt. Într-un mod care poate fi cu adevărat greu de detectat – chiar și pentru ingineri senior care examinează codul cu atenție. Bug-urile nu sunt întotdeauna evidente. Pot arăta perfect reasonable la o privire.

Deci, pe măsură ce inteligența artificială scrie mai mult cod care ajunge în producție, cred că vom vedea mai multe dintre aceste probleme subtile, greu de detectat, care trec prin revizuire – nu pentru că cineva a fost neglijent, ci pentru că natura bug-urilor generate de inteligența artificială este diferită. Mai greu de detectat în revizuire. Mai greu de prins în testare.

Sincer? Acesta este unul dintre motivele pentru care cred că cazul pentru ceea ce face Strudel devine și mai puternic cu timpul. Dacă mai multe bug-uri ajung în producție, capacitatea de a le găsi și rezolva mai rapid devine și mai importantă, nu mai puțin importantă. Întrebarea de guvernanță nu este doar despre controale de acces la date și permisiuni – deși acestea contează, și echipele ar trebui să fie atente la ce date oferă oricărui sistem de inteligență artificială. Este, de asemenea, despre a păstra oamenii la punctele de control corecte, în special în jurul a oricărui lucru care atinge producția.

Privind înainte, credeți că viitorul ingineriei de fiabilitate se va îndrepta către infrastructuri “inteligență artificială în primul rând”, unde sistemele autonome monitorizează, diagnosticează și chiar repară problemele înainte ca oamenii să fie conștienți de ele? Dacă da, cum arată fluxul de lucru pentru ingineri în acest viitor?

Cred că ne îndreptăm în acea direcție, dar sunt pragmatic în ceea ce privește cronologia. Sisteme autonome care rezolvă incidente de producție fără nicio conștientizare umană – aceasta nu este unde suntem, și nu cred că vom fi acolo în următorii câțiva ani. Și cred că acesta este în regulă.

Ceea ce cred este că bucla devine mult mai strânsă și mai puțin dureroasă. Viitorul pe care îl sunt entuziasmat nu este unul în care oamenii sunt eliminați din ecuație – ci unul în care oamenii integrați în procesul petrec timpul lor pe părțile care cu adevărat necesită oameni. Apeluri de judecată. Situații noi. Un incident pe care nu l-ați văzut niciodată înainte. Inteligența artificială se ocupă de recunoașterea modelelor, asamblarea contextului, triajul de rutină. Inginerii se ocupă de decizii.

Pentru ingineri înșiși, cred că arată astfel: mai puțin timp de gardă în mijlocul nopții pentru lucruri care nu ar fi trebuit să-i trezească, și mai mult timp pentru a construi sisteme care nu se defectează din start. Lupta cu incendii nu dispare cu totul. Dar devine excepția, mai degrabă decât starea implicită a fi inginer la o companie care rulează software la scară. Acesta este un viitor pe care merită să-l construim.

Mulțumim pentru acest interviu minunat, cititorilor care doresc să afle mai multe, vă rugăm să vizitați Strudel.