Strudel’in CEO ve Kurucu Ortağı Kristin Isaac ile Röportaj Serisi

Kristin Isaac, Strudel’in CEO ve Kurucu Ortağı, LinkedIn, Udemy, ESPN ve Disney’de üst düzey rollerde bulunan bir entreprise teknoloji lideridir. Şimdi, Strudel’de, müşteri destek ve mühendislik arasındaki en büyük sürtünme noktalarından birini çözmeye odaklanıyor: teknik destek ekiplerinin karmaşık sorunları daha hızlı çözmelerine yardımcı olan bir AI destekli platform oluşturuyor. Ekibini ölçeklendirme, pazara girme stratejileri oluşturma ve küresel organizasyonlar genelinde büyümeyi sağlama konusundaki deneyimi, Strudel’in hızlı erken ivmesini ve entreprise AI ve geliştirme araçları pazarındaki güçlü konumunu şekillendirmesine yardımcı oldu.

Strudel, günlükleri, üretim verilerini, kod depolarını ve geçmiş destek geçmişini analiz ederek kök nedenleri tanımlamak ve çözümler önermek için tasarlanmış bir AI platformudur. Zor destek vakalarını çözmek için gereken zamanı ve mühendislik çabasını azaltma amacını taşıyor. Destek taleplerini doğrudan mühendislik zekasına bağlayarak, Strudel, entreprise destek operasyonlarının daha hızlı, daha verimli ve daha ölçeklenebilir olmasını hedefliyor.

LinkedIn, Udemy ve Disney gibi organizasyonlarda liderlik rolleri üstlendikten sonra 2025 yılında Strudel’i kurdunuz. Bu rollerdeki deneyimler, mühendislik ekiplerine yeni bir AI destekli “mühendislik zekası” platformuna ihtiyaç duyulduğunu size nasıl gösterdi ve bu görüş, Strudel’in kurulmasına nasıl şekil verdi?

Her şirketin bu sorunların farklı bir versiyonu vardı. Disney’de, riskler çok büyüktü – bir yayın platformu büyük bir lansman sırasında çökerse, bu sadece bir gelir kaybı değil, aynı zamanda bir marka anı oluyordu. LinkedIn’de, ölçek dayanıklıydı. Binlerce hizmet tüm gürültüyü üretiyordu ve hatta en iyi ekipler bile takip etmekte zorlanıyordu. Udemy’de, sınırlı araçlarla kahramanca şeyler yapan ince bir ekibi gördüm.

Her üçünü ve ortak kurucularım Shai Rubin ve Brian Kaufman’ın mühendislik ekiplerini yönetme deneyimlerini bağlayan şey, mühendislerin sorunları çözmek için harcayacakları zamanın çoğunu bağlamı yeniden inşa etmek için harcadıkları gerçeğiydi. Birisi 02:00’de sayfa alır ve önce teşhis etmeye başlamadan önce, Slack threads, paneller, Jira biletleri, dağıtım günlükleri – sadece ne değişti ve ne zaman değiştiğini anlamaya çalışmak için – tüm bunları doingüzeltmeye çalışıyor. Aslında, işlerini yapmadan önce dedektif gibi davranıyorlar. Bu, inanılmaz yetenekli insanların boşa harcanması.

Sürekli düşünüyordum: daha akıllı bir yol olmalı, neyin önemli olduğunu, ne zaman önemli olduğunu ortaya çıkarmak için. Bu, Strudel’in tohumu.

Çok sayıda şirket, downtime’ın mali etkisini kaybedilen gelir veya SLA cezaları olarak ölçer. Deneyiminizde, organizasyonların sürekli olarak düşük tahmin ettiği, görünmeyen maliyetler nelerdir?

Gelir rakamı yönetim kuruluna girer, ancak immediate gelir etkisi, arızanın gerçek maliyetinin sadece bir kısmıdır. Gördüğüm organizasyonların sürekli olarak kaçırdıkları şeyler birkaç kategoriye girer.

İlki müşteri güvenidir. SLA cezaları yasal bir yapıttır – müşterinin sessizce ayrılmasını veya bir entreprise adayının yanlış anda durum sayfasını gördüğü ve bir rakibe tercih ettiği durumu yakalamaz. Bu zarar, yavaş, görünmez ve bir iade çekinin olmadığı şekilde kalıcıdır.

İkincisi, mühendis ayrılması ve yanmasıdır. Çağrı yorgunluğu gerçektir. En iyi mühendisleriniz tekrar tekrar yüksek stresli olaylara çekildiğinde – özellikle önlenmesi mümkün olan olaylar olduğunda – kariyerlerini başka bir yerde inşa etmek için doğru yer olup olmadığını sorgulamaya başlarlar. Bir senior mühendisi değiştirmek, kurumun bilgi ve deneyim kaybını da hesaba katarak, yıllık maaşlarının bir ila iki katı tutarında bir maliyet olabilir. Hiç kimse bu maliyeti post-mortem’de dahil etmez.

Üçüncüsü, fırsatın maliyetidir. Bir mühendislik ekibinin yangınla mücadele için harcadığı her saat, ürün geliştirmek için harcanmayan bir saattir. Bu, bir spreadsheete koyulması zor bir şeydir, ancak aylar boyunca biriken effect, yol haritasını sessizce patlatır.

Mühendisler genellikle yeni özellikler geliştirmek yerine üretim olaylarına cevap vermek için uzaklaştırılmaktadır. Bu sürekli yangınla mücadele, ürün inovasyonu ve uzun vadeli geliştirme yol haritası üzerinde nasıl bir etkiye sahiptir?

Bu, ekibin ürün geliştirmek için sahip olduğu sınırlı bant genişliğini yaratır. Her takımın sınırlı bir bant genişliği vardır ve bu bant genişliğinin önemli bir kısmı sürekli olarak olaylara yönlendirildiğinde, ürün geliştirmesi üzerinde biriken effect şiddetlidir. Yol haritası taahhütleri kaçırılır. Teknik borç ödenmez. Özellikler, zaman baskısı nedeniyle daha az titizlikle gönderilir.

Özellikle zarar verici olan şey, bunun öngörülemezliğidir. Bir ekip sprintlerini iyi niyetle planlayabilir, ancak sonra bir major olay salı günü patlak verir ve her şey ikincil hale gelir. Bu tür sürekli öngörülemezlik, derin çalışma kültürü oluşturmayı neredeyse imkansız kılar – bu da sonunda en iyi mühendislik sonuçlarını sağlayan şeydir.

Bu ayrıca self-reinforcing bir döngü yaratır. Ertelemiş yatırım, daha fazla olaya yol açar, daha fazla yangınla mücadele anlamına gelir, bu da temel sorunlara yatırım yapma zamanının daha da azalmasına neden olur. Strudel’de, SRE ekiplerinin her gün yaşadığı şeyi inşa etmek için büyük bir çaba sarf ediyoruz.

Strudel, müşteri destek verilerini, günlükleri, üretim sistemlerini ve kod depolarını kök nedenleri daha hızlı tanımlamak için bağlar. AI, geleneksel izleme araçlarının yapamadığı şekilde bu farklı teknik sinyalleri nasıl bir araya getirir?

Geleneksel izleme araçları temel olarak uyarı sistemleridir. Bir eşik değerini aşan bir şey olduğunu söylemekte iyidirler – bir gecikme artışı, hata oranının yükselmesi, bir pod’un çökmesi. Ancak bunlar alanlar arasında neden-sonuç ilişkisi kuramazlar.

Bir ödemeler servisinde hata oranı artışı, bir bağımlılığa yapılan bir dağıtımın dört dakika sonrasında meydana geldiğini ve bir müşteri destek bileti hakkında ödeme başarısızlıklarını içeren bir thingin aynı zamanda geldiğini ve bu patternin altı ay önce bir veritabanı geçişi sırasında günlüklerde görüldüğünü bilmezler.

AI, bu alanlar arası korelasyonu sağlar. Bir Zendesk bileti, bir GitHub taahhüdü, bir Datadog (DDOG ) izi ve bir CloudWatch günlüğü, izole edilmiş veri noktaları yerine birleşik bir hikaye olarak ele alınabilir. AI, sadece neyin bozuk olduğunu değil, muhtemel nedenini ve nerede olduğunu da ortaya koyar – ve bunu bir insan mühendisin gerçekten doğrulayabileceği ve üzerine harekete geçebileceği kanıtlara dayandırır. Ekiplere siyah bir kutuya güvenmelerini istemiyoruz. Onlara iyi düşünülmüş bir hipotez ve başlangıç noktası veriyoruz.

Strudel’i “mühendislik zekası” olarak tanımlıyorsunuz. Bu kavram, uygulamada ne anlama geliyor ve geleneksel observability veya AIOps platformlarından nasıl farklı?

Gözlemlenebilirlik, temel olarak enstrümantasyon ve görünürlük ile ilgili – telemetrinin orada olduğundan ve ekiplerin sorgulayabileceğinden emin olmak. AIOps, çoğu güncel uygulamasında, ML tabanlı korelasyon ve anormalık tespiti yoluyla uyarı gürültüsünü azaltmakla ilgili. Her ikisi de gerçekten değerli ve onlarla entegre çalışıyoruz.

Ancak mühendislik zekası, bunun üzerinde bir katman. AIOps’un yaptığı şeyi genişletiyoruz. AIOps size bir şeyin yanlış olduğunu söyler, mühendislik zekası size neden yanlış olduğunu, nerede başladığını ve ne yapmanız gerektiğini söyler – tüm yığınınızdan, geleneksel AIOps araçlarının bakmadığı müşteri destek biletleri veya kod değişiklikleri gibi sinyalleri alarak. Hedef, sadece gürültüyü azaltmak değil. Ekiplere, sorunu daha hızlı çözmeleri ve ürün geliştirmeye geri dönmeleri için tam, eyleme geçirilebilir bir resim vermek.

AI ajanları, karmaşık teknik iş akışlarını otomatikleştirmek için giderek daha fazla kullanılıyor. AI ajanlarının, yazılım olaylarını teşhis etme ve çözme konusundaki rollerini önümüzdeki beş yıl içinde nasıl görüyorsunuz?

Sanırım daha intéressan soru, ajanların ne yapacakları değil, mühendislerin ne yapmayı bırakacaklarıdır. En iyi mühendislerle çalıştım, onlar bu alana, geceyarısı uyarılarını triaj etmek veya bir Cuma öğleden sonra yapılan bir yapılandırma değişikliği için günlükleri aramak için harcamak için girmediler. Bu, onların iyi oldukları şey değil.

Önümüzdeki beş yıl içinde, ajanların bu tür işleri üstleneceğini düşünüyorum – tekrar eden, desen eşleştiren, bağlam oluşturan işler. Bu, senior mühendislik yeteneğinin gerçekten harcandığı yer değil. Ajanlar, mühendislerin kompleks sorunlara, mimari kararlara, gerçekten insan yargısına ihtiyaç duyulan şeylere odaklanmalarını sağlayarak, bu tür işleri üstlenecek.

AI sistemleri üretim verilerini, kod tabanlarını ve operasyonel günlükleri analiz etmeye başladığında, mühendislik ekiplerinin bu araçları dağıtırken hangi yönetim veya güvenlik dikkate almak lerini dikkate alması gerekir?

Bu konuda en çok önem verdiğim şey, insanların üretimde kullanılan kodu hala gözden geçirmesidir.

Çok sayıda mühendisle konuştuğum için, duyduğum şeylerden biri, AI’nin verimli ve akıllıca hatalar yazabilmesidir. Gerçekten akıllıca, aslında. Bir bakışta gerçekten akıllıca görünebilen bir şekilde. Bu tür hatalar her zaman açık değildir. Dikkatlice incelediğinizde bile gerçekten zor olabilir.

AI’nin daha fazla kodu üretimde yazmaya başladığını göreceğiz ve bu, gerçekten zor tespit edilebilen, insanların gözden kaçırdığı hataların ortaya çıkmasına neden olacaktır. Bu, ekiplerin üretim kodunu gözden geçirmeye devam etmeleri gerektiği anlamına gelir. Strudel’in yaptığı şeyin önemi, daha da artacaktır. Daha fazla hata üretimde ortaya çıkarsa, bunları daha hızlı bulup çözmek daha da önemli hale gelecektir.

Gelecek, AI-öncelikli altyapılara doğru mu gidecek, burada otomatik sistemler, sorunları insanlardan önce tespit edip, teşhis edip ve çözebilecekler mi? Eğer öyleyse, mühendisler için bu gelecek iş akışı nasıl görünüyor?

Bu yönde gittiğimize inanıyorum, ancak zaman çizelgesi konusunda gerçekçiyim. Tamamen otomatik sistemlerin, insan müdahalesi olmadan üretim olaylarını çözeceği bir gelecek, önümüzdeki birkaç yıl içinde olmayacak. Ve sanırım bu sorun değil.

Inanıyorum ki, döngü çok daha dar ve çok daha az ağrılı hale gelecek. Geleceğim, insanların denklemden çıkarıldığı bir gelecek değil, insanların gerçekten gerekli olan kısımlarda zaman geçirdiği bir gelecek. AI, desen eşleştirmeyi, bağlam oluşturmayı, rutin triajı yapacak. Mühendisler, kararları verecek.

Mühendisler için, bu, geceyarısı çağrıları için daha az zaman harcayacakları, daha fazla zamanı, sistemlerin bozulmaması için harcayacakları anlamına geliyor. Yangınla mücadele tamamen ortadan kalkmayacak, ancak mühendislerin default durumu değil, istisnai bir durum haline gelecek. Bu, inşa etmeye değer bir gelecek.

Harika röportaj için teşekkür ederiz, daha fazla bilgi edinmek isteyen okuyucular Strudel‘i ziyaret edebilir.