Kristin Isaac, CEO ja Co-Founder Strudelilla – Haastattelusarja

Kristin Isaac, Strudelin CEO ja Co-Founder, on kokenut yritysten teknologian johtaja, joka on toiminut johtavissa rooleissa LinkedInissä, Udemyssä, ESPN:ssä ja Disneyssä ennen Strudelin perustamista. Hän keskittyy nyt ratkaisemaan yhteen suurimista kitkakohdista ohjelmistoyrityksissä: kuiluun asiakastuen ja insinöörien välillä. Strudelilla hän rakentaa tekoälypohjaista alustaa, joka auttaa teknistä tukea tarjoavia tiimejä ratkaisemaan monimutkaisia ongelmia nopeammin liittämällä tukipyynnöt suoraan insinöörien älykkyyteen. Taustansa joukkueiden kasvattamisessa, markkinointistrategioiden luomisessa ja kasvun ajaminassa globaaleissa organisaatioissa on auttanut muotoilemaan Strudelin nopean alkuvaiheen ja vahvan aseman yritysten tekoäly- ja kehittäjätyökalumarkkinoilla.

Strudel on tekoälyalusta, joka on rakennettu automatisoimaan edistyneen teknisen tuen analysoimalla lokit, tuotantodataa, koodirepositorioita ja aiempaa tukihistoriaa tunnistamaan juurisyyt ja suosittelemaan ratkaisuja. Sen tavoitteena on vähentää aikaa ja insinöörien työtä, jotka vaaditaan hankalien tukitapausten ratkaisemiseen, erityisesti sellaisiin eskaloitumisiin, jotka yleensä kuluttavat senioriteknisten resurssien aikaa. Liittämällä tuen suoraan perustuvien teknisten ongelmien kanssa, Strudel asettaa itsensä työkaluksi, joka voi tehdä yritysten tukitoiminnot nopeammaksi, tehokkaammaksi ja skaalautuvammaksi.

Olet toiminut johtavissa rooleissa yrityksissä kuten LinkedIn, Udemy ja Disney ennen Strudelin perustamista vuonna 2025. Mitkä kokemukset näistä rooleista lopulta vakuuttivat sinut siitä, että insinööritiimien tarvitsi uudenlaisen tekoälypohjaisen “insinöörien älykkyyden” alustan, ja miten tämä oivallus muotoili Strudelin perustamista?

Jokainen yritys, jossa olen työskennellyt, on ollut erilainen versio samasta ongelmasta. Disneyssä panokset olivat valtavat – jos striimauspalvelu menee pois päältä suuren julkaisun aikana, se ei ole vain tuloisku, vaan brändikokemus. LinkedInissä mittakaava oli armoton. Tuhannet palvelut tuottivat melua, ja jopa parhaat tiimit kamppailivat pysymään mukana. Udemyssä näin lean-tiimin tekevän sankareita asioita rajoitetulla työkalulla.

Mitä yhdisti kaikki kolme ja minun co-perustajieni, Shai Rubinin ja Brian Kaufmanin, kokemukseen johtaa insinööritiimejä, oli se, että insinöörit käyttivät enemmän aikaa kontekstin jälleenrakentamiseen kuin itse ongelmien ratkaisemiseen. Joku herätetään kello 2 aamuyöllä, ja ennen kuin he voivat edes aloittaa diagnosoinnin, he ovat kahlittelemassa Slack-keskusteluja, dashboardeja, Jira-lippuja, käyttölokeja – yrittäen ymmärtää, mitä muutettiin ja milloin. He pelaavat etsivää ennen kuin he voivat tehdä oikeaa työtään. Se on hävikkiä erittäin lahjakkailta ihmisiltä.

Ajattelin jatkuvasti: on oltava järkevämpi tapa saada selville, mitä todella on asiaa, kun se on asiaa. Se on Strudelin siemen.

Monet yritykset mittaavat pysähdysten taloudellista vaikutusta menetetyn liikevaihdon tai SLA-rangaistusten kautta. Kokemuksestasi, mitkä ovat joitain vähemmän näkyviä kustannuksia pysähdysajoista, joita organisaatiot jatkuvasti aliarvioivat?

Liikevaihtoluku pääsee hallitukseen, mutta välittömän liikevaihdon vaikutus on vain murto-osa siitä, mitä pysähdys todella maksaa. Ne, joita olen nähnyt organisaatioiden jatkuvasti yliarvioivan, jakautuvat muutamiin ryhmiin.

Ensimmäinen on asiakastuki. SLA-rangaistukset ovat oikeudellinen konstruktio – ne eivät kata asiakasta, joka hiljaisesti poistuu, tai yrityksen, joka näki tilapäivityssivun väärän hetken ja valitsi kilpailijan. Tuo vahinko on hidas, näkymätön ja pysyvä tapa, jolla korvauscheque ei ole.

Toinen on insinöörien käynti ja polttaminen. On-call-uupumus on todellista. Kun parhaat insinöörit joutuvat toistuvasti mukaan korkeapaineisiin tapahtumiin – erityisesti sellaisiin, jotka olisi voitu ehkäistä – he alkavat kyseenalaistaa, onko tämä oikea paikka uransa rakentamiseen. Seniori-insinöörin korvaaminen maksaa missä tahansa yhden tai kaksi kertaa heidän vuosipalkkansa, kun otetaan huomioon rekrytointi, koulutus ja menetetty instituutio. Kukaan ei laita sitä post-mortem-raporttiin.

Kolmas on mahdollisuuden kustannus. Jokainen tunti, jonka insinööritiimi käyttää tulipalojen sammuttamiseen, on tunti, joka ei ole käytetty tuotteen rakentamiseen. Se on vaikea laittaa taulukolle, mutta kertyy kuukausien mittaan se hiljaisesti räjäyttää tiennäkymän.

Insinöörit usein vedetään pois uusien ominaisuuksien rakentamisesta vastaamaan tuotantotapahtumiin. Miten tämä jatkuva sammutus vaikuttaa tuote-innovaatioon ja pitkän aikavälin kehityssuunnitelmiin?

Se luo veron insinööritiimin kyvystä rakentaa. Jokaisella tiimillä on äärettömän paljon kapasiteettia, ja kun merkittävä osa siitä joutuu jatkuvasti ohjattavaksi hälytysten suuntaan, vaikutus tuotteen kehitykseen on vakava. Tiennäkymäsitoumukset menetetään. Tekninen velka ei makseta. Ominaisuudet toimitetaan vähemmän tarkkuudella, koska on paine tehdä korvaus menetetystä ajasta.

Se on erityisen vahingollista, että se on ennakoiden vaikeaa. Tiimi voi suunnitella sprintin hyvin tarkoituksella, ja sitten suuri tapahtuma räjähtää tiistaina ja kaikki muu tulee toissijaiseksi. Tuo jatkuva ennakoiden vaikeus tekee lähes mahdottomaksi rakentaa kulttuuria syvää työtä – joka lopulta ajaa parhaimmat insinöörien tulokset.

Se myös luo itseään vahvistavan kierron. Lykätty investointi tarkoittaa enemmän tapahtumia, jotka tarkoittavat enemmän sammutusta, mikä tarkoittaa vielä vähemmän aikaa ratkaista perusongelmia. Strudelilla suuri osa siitä, mitä rakennamme, on nimenomaan SRE-tiimille, jotka elävät tätä joka päivä.

Strudel liittää asiakastukidata, lokit, tuotantojärjestelmät ja koodirepositoriot tunnistamaan juurisyyt nopeammin. Miten tekoäly yhdistää nämä erilaiset tekniset signaalit tavalla, jota perinteiset valvontatyökalut eivät voi?

Perinteiset valvontatyökalut ovat perustavalla tasolla hälytysjärjestelmiä. Ne ovat hyviä kertomaan, että jokin ylitti kynnyksen – viivepiikki, virheen määrä nousee, podin romahdus. Mitä ne eivät voi tehdä, on päättely eri alueilla.

Ne eivät tiedä, että virheen määrän piikki maksamispalvelussa tapahtui neljä minuuttia riippuvuuden käyttöönoton jälkeen, ja että asiakastukilippu, jossa mainittiin maksamisepäonnistumisia, tuli noin samoihin aikoihin, ja että sama kuva ilmestyi lokissa kuusi kuukautta sitten tietokantasiirrossa.

Tuo alueiden välinen korrelaatio on sitä, mitä tekoäly mahdollistaa. Voimme käsitellä Zendesk-lippua, GitHubin sitoutumista, Datadog-jäljitystä ja CloudWatch-lokia yhtenä yhtenäisenä tarinana erillisten tietojen pisteiden sijaan. Tekoäly pinnalla ei vain sitä, mikä on rikki, vaan myös todennäköinen syy ja missä – ja se perustuu näyttöön, jonka ihmisinsinööri voi todella vahvistaa ja toimia. Emme pyydä tiimejä luottamaan mustaan laatikkoon. Annamme heille hyvin perustellun hypoteesin ja pääsysan.

Kuvailet Strudelia toimittavan “insinöörien älykkyyttä”. Mitä tämä käsite tarkoittaa käytännössä, ja miten se eroaa perinteisistä havainnollistamis- tai AIOps-alustoista?

Havainnollistaminen on perustavalla tasolla instrumentaatiosta ja näkyvyydestä – varmistamalla, että telemetria on siellä ja että tiimit voivat kysyä sitä. AIOps, useimmissa nykyisistä toteutuksista, on ML-pohjaisen korrelaation ja poikkeamien havaitsemisen kautta hälytysmelun vähentämistä. Molemmat ovat aidosti arvokkaita, ja integroidaan niihin.

Mutta insinöörien älykkyys on kerros siitä. Otamme sen, mitä AIOps tekee, ja laajennamme sitä. Kun AIOps kertoo, että jotain on vikana, insinöörien älykkyys auttaa ymmärtämään, miksi se on vikana, mistä se alkoi ja mitä tehdä siitä – vetämällä signaaleja koko pinon yli, mukaan lukien lähteitä, joita perinteiset AIOps-työkalut eivät edes katso, kuten asiakastukilippuja tai koodimuutoksia. Tavoitteena ei ole vain vähentää melua. Se on antaa tiimille täydellinen, toimiva kuva, jotta he voivat ratkaista ongelman nopeammin ja palata rakentamiseen.

Ajattele sitä kuin eroa savuilmoittimen ja tulen tutkijan välillä. Havainnollistaminen ja AIOps ovat savuilmoitin – välttämätön, mutta se pysähtyy hälytykseen. Insinöörien älykkyys on se, mikä tulee sen jälkeen: tämä tapahtui, tämä on syy, tämä on mistä se alkoi.

Tekoälyagentit otetaan yhä enemmän käyttöön automatisoimaan monimutkaisia teknisiä työvirtoja. Mitä roolia näet tekoälyagenttien pelaavan ohjelmistotapahtumien diagnosoinnissa ja ratkaisemisessa seuraavien viiden vuoden aikana?

Ajattelen, että mielenkiintoisempi kysymys ei ole, mitä agentit tekevät – vaan mitä insinöörit lopettavat tekemästä. Parhaat insinöörit, joilla olen työskennellyt, eivät tulleet tähän alalle viettääkseen öitä hälytysten priorisoinnissa tai lokien etsimisessä jonkun viime viikon perjantai-iltapäivän konfiguraatiomuutoksesta. Se ei ole syystä, miksi heistä tuli hyviä työssään.

Seuraavien viiden vuoden aikana ajattelen, että agentit ottavat paljon siitä rutiinin – toistuvan, mallintamisen, kontekstin kokoamisen työn, joka on tärkeää, mutta ei siitä, mihin seniori-insinöörien taito pitäisi käyttää. Se vapauttaa ihmisiä keskittymään monimutkaisiin ongelmiin, arkkitehtuuriin, asioihin, jotka todella vaativat ihmisen arviointia.

Mitä on jännittävää minulle, on se, että tämä ei ole vain tulevaisuuden tila – me näemme sen tapahtuvan jo nyt, myös Strudelilla. Koko tiemme on suunnattu poistamaan hallinnollinen ja ylläpitotyö insinöörien lautasilta. Ja mitä olemme löytäneet, rehellisesti, on se, että se muuttaa sitä, mitä on mahdollista tiimille. Voit rakentaa enemmän, liikkua nopeammin ja tehdä sen vähemmällä ihmisillä – koska ihmiset, joita sinulla on, keskittyvät strategiaan ja monimutkaisuuteen eikä toistuvaan työhön. Se tuntuu merkittävältä muutokselta siinä, miten tiimit rakennetaan ja järjestetään eteenpäin.

Monet pysähdysajat alkavat pienistä virheistä tai konfiguraatiomuutoksista, jotka pääsevät läpi testauksesta. Miten tekoälyjärjestelmät voivat tunnistaa hienot mallit koodissa, lokeissa tai infrastruktuurisignaaleissa ajoissa estääksesi suuria tapahtumia?

Hyvin suunniteltu tekoäly on oikeasti edullinen tässä. Se ei ole, että se on älykkäämpää kuin insinöörit – vaan se, että se ei unohda koskaan ja nukkuu koskaan. Ihminen ei välttämättä yhdistä hienoa lokimallia tänään johonkin, mitä tapahtui kuusi kuukautta sitten jossain toisessa järjestelmän osassa. Tekoäly voi. Se tarkkailee kaikkea, kaiken aikaa, ja sillä on paljon pidempi ja laajempi muisti kuin yksikölle tiimissä.

Sanon kuitenkin, että on myös jotain muuta, mitä kuulen asiakkailta paljon: ennaltaehkäisy on vain yhtä hyvä kuin sen alle oleva data. Jos lokit ovat epäjohdonmukaisia, puutteellisia tai eristettyinä kymmenissä työkaluissa, jotka eivät puhu toistensa kanssa, tekoäly toimii hajanaisen kuvan kanssa. Roska sisään, roska ulos – se on yhä totta. Vietämme paljon aikaa asiakkaiden kanssa pohtimassa datan laatua ja instrumentaatiota, koska parasta tekoälyä maailmassa ei voi pintaa signaalia, jota ei koskaan tallennettu.

Joten vastaus on kumpi: kyllä, tekoäly voi havaita asioita aikaisemmin ja yhdistää pisteitä, joita ihmiset eivät huomaa. Mutta tiimit, jotka saavat parhaan arvon siitä, ovat niitä, jotka ovat myös tehneet työn varmistamaan, että heidän datansa on todella arvokasta.

Yritykset usein panostavat voimakkaasti havaintotyökaluihin, mutta kamppailevat edelleen keskimääräisen ratkaisuaikaan. Mitkä ovat suurimmat esteet, jotka estävät organisaatioita sulkemasta kuilua hälytysilmoituksen ja todellisen juurisyy-ratkaisun välillä?

Hälytys on suurelta osin ratkaistu ongelma. Useimmat tiimit tietävät, kun jotain on vikana. Kuilu on kaikki se, mitä tapahtuu sen jälkeen.

Kun insinööri hälytetään, he eivät astu selkeään tilanteeseen, jossa kaikki asiaankuuluvat tiedot on kootu. He astuvat sekasortoon. Heidän on selvittävä, mitä muutettiin, milloin se muutettiin, mihin järjestelmään se vaikuttaa, onko siinä asiakasvaikutusta, onko se liittynyt johonkin, mitä tapahtui viime viikolla. He etsivät tietoa Slackista, dashboardeista, käyttölokeista, tukilipoista – tekemällä kontekstin kokoamisen manuaalisesti, paineen alla, usein keskellä yötä.

Tuo kontekstin kokoaminen on pullonkaula. Insinöörit ja teknisen tuen tiimit eivät ole sitä, etteivät he tietäisi, miten ratkaista ongelmia – vaan he käyttävät ensimmäiset 30-60 minuuttia jokaisen tapahtuman aikana yrittäen ymmärtää, mitä he todella katsovat. Se on este, jonka Strudel asettaa. Meidän koko teesimme on, että jos voimme antaa insinöörille koherentin, näyttöön perustuvan kuvan siitä, mitä tapahtui ja miksi – juuri silloin, kun he tarvitsevat sitä – voimme dramaattisesti puristaa tämän kuilun. Ratkaisutyö on edelleen heidän. Me vain saamme heidät nopeammin lähtöviivaan.

Kun tekoälyjärjestelmät alkavat analyysia tuotantodataa, koodipohjaa ja operaatiolokien, mitkä hallintoon tai turvallisuuteen liittyvät huomioonpidettävät seikat insinööritiimien on pidettävä mielessä asennettaessa näitä työkaluja?

Asia, josta olen vakuuttunut, on, että ihmiset pitäisi edelleen tarkastaa koodia, joka menee tuotantoon.

Olen puhunut monien insinöörien kanssa tästä, ja yksi asia, jota kuulen heiltä toistuvasti, on, että tekoäly kirjoittaa virheitä tehokkaasti ja älykkäästi. Todella älykkäästi, oikeasti. Tapaa, joka voi olla todella haasteellista löytää – jopa seniori-insinööreiltä, jotka tarkastavat koodia huolellisesti. Virheet eivät aina ole ilmeisiä. Ne voivat näyttää täysin järkeviltä yhdellä silmäyksellä.

Niinpä kun tekoäly kirjoittaa yhä enemmän koodia, joka päätyy tuotantoon, ajattelen, että näemme enemmän näistä hienoista, haasteellisista ongelmista, jotka pääsevät läpi – ei siksi, että kukaan oli huolimaton, vaan siksi, että tekoälyvirheiden luonne on erilainen. Haasteellisempaa havaita tarkastuksessa. Haasteellisempaa löytää testauksessa. Tuo on yksi syy, miksi tapaus siitä, mitä Strudel tekee, vain vahvistuu ajan myötä. Jos enemmän virheitä pääsee tuotantoon, kyky löytää ja ratkaista ne nopeammin tulee tärkeämmäksi, ei vähemmäksi. Hallintokysymys ei ole vain datan pääsyrajoituksista ja lupauksista – vaan myös pitämistä oikeissa checkpointeissä, erityisesti kaikessa, mikä liittyy tuotantoon.

Edetäänkö luotettavuuden suunnittelun tulevaisuus kohti tekoälyensimmäistä infrastruktuuria, jossa autonomiset järjestelmät valvovat, diagnosoida ja jopa korjaavat ongelmia ennen kuin ihmiset ovat siitä tietoisia? Jos niin, miltä näyttää työnkulku insinööreille?

Ajattelen, että olemme menossa tuon suuntaan, mutta olen pragmaattinen aikataulun suhteen. Täysin autonomiset järjestelmät, jotka ratkaisevat tuotantotapahtumia ilman ihmisten tietämistä, eivät ole siellä, missä olemme, ja en usko, että ne ovat siellä seuraavien muutaman vuoden aikana. Ja ajattelen, että se on ok.

Mitä uskon, on, että silmukka tulee paljon tiukemmaksi ja vähemmän tuskalliseksi. Tulevaisuus, josta olen innoissani, ei ole sellainen, jossa ihmiset poistetaan yhtälöstä – se on sellainen, jossa ihmiset, jotka ovat mukana prosessissa, käyttävät aikaa osiin, jotka todella vaativat heitä. Arviointi. Uudet tilanteet. Tapahtuma, jota et ole koskaan nähnyt aiemmin. Tekoäly käsittelee mallintamisen, kontekstin kokoamisen, rutiinin valvonnan. Insinöörit käsittelevät päätökset.

Insinööreille se näyttää siltä: vähemmän yötä hälytysjärjestyksessä asioista, jotka eivät vaadi heidän heräämistään, ja enemmän aikaa rakentamiseen järjestelmiä, jotka eivät mene rikki ensinnäkään. Sammutus ei katoa kokonaan. Se tulee poikkeukseksi sen sijaan, että se olisi oletusarvo insinöörinä yrityksessä, joka ajaa ohjelmistoa suuressa mittakaavassa. Se on tulevaisuus, jota kannattaa rakentaa.

Kiitos hienosta haastattelusta, lukijat, jotka haluavat oppia lisää, kannattaa vierailla Strudel:lla.