Kristin Isaac, CEO dan Co-Founder di Strudel – Seri Wawancara

Kristin Isaac, CEO dan Co-Founder di Strudel adalah seorang pemimpin teknologi perusahaan yang berpengalaman yang telah menjabat posisi senior di LinkedIn, Udemy, ESPN, dan Disney sebelum meluncurkan Strudel. Ia sekarang fokus untuk mengatasi salah satu titik gesekan terbesar dalam organisasi perangkat lunak: kesenjangan antara dukungan pelanggan dan teknik. Di Strudel, ia membangun platform yang didorong oleh AI yang membantu tim dukungan teknis untuk memecahkan masalah kompleks lebih cepat dengan menghubungkan permintaan dukungan langsung ke intelijen teknik.

Strudel adalah platform AI yang dibangun untuk mengotomatisasi dukungan teknis lanjutan dengan menganalisis log, data produksi, repositori kode, dan riwayat dukungan sebelumnya untuk mengidentifikasi penyebab akar dan merekomendasikan solusi. Tujuannya adalah untuk mengurangi waktu dan upaya teknik yang diperlukan untuk memecahkan kasus dukungan yang sulit, terutama eskalasi yang biasanya menghabiskan sumber daya teknis senior. Dengan menghubungkan dukungan langsung ke masalah teknis yang mendasarinya, Strudel memposisikan diri sebagai alat yang dapat membuat operasi dukungan perusahaan lebih cepat, lebih efisien, dan lebih scalable.

Anda telah menjabat posisi kepemimpinan di perusahaan seperti LinkedIn, Udemy, dan Disney sebelum mendirikan Strudel pada 2025. Pengalaman apa dari posisi tersebut yang akhirnya meyakinkan Anda bahwa tim teknik membutuhkan platform “intelijen teknik” yang didorong oleh AI, dan bagaimana wawasan itu membentuk pendirian Strudel?

Setiap perusahaan yang saya kerjakan memiliki versi yang berbeda dari masalah yang sama. Di Disney, taruhannya sangat besar – jika platform streaming turun selama peluncuran besar, itu tidak hanya mengenai pendapatan, tetapi juga momen merek. Di LinkedIn, skala sangat besar. Ada ribuan layanan yang semua menghasilkan kebisingan, dan bahkan tim terbaik berjuang untuk mengikuti.

Apa yang menghubungkan ketiganya dan pengalaman saya dengan co-founder, Shai Rubin dan Brian Kaufman, yang memimpin tim teknik, adalah bahwa insinyur menghabiskan lebih banyak waktu untuk merekonstruksi konteks daripada memecahkan masalah. Seseorang dipanggil pada pukul 2 pagi, dan sebelum mereka dapat memulai diagnosis, mereka harus mencari melalui thread Slack, dashboard, tiket Jira, log deploy – hanya untuk memahami apa yang berubah dan kapan. Mereka pada dasarnya bermain detektif sebelum mereka dapat melakukan pekerjaan mereka. Itu adalah pemborosan bakat yang luar biasa.

Saya terus berpikir: harus ada cara yang lebih cerdas untuk menyajikan apa yang sebenarnya penting, ketika itu penting. Itulah benih Strudel.

Banyak perusahaan mengukur dampak keuangan dari downtime dalam bentuk pendapatan yang hilang atau penalti SLA. Dalam pengalaman Anda, apa saja biaya tidak terlihat dari gangguan yang konsisten diremehkan oleh organisasi?

Angka pendapatan membuatnya masuk ke dalam deck dewan, tetapi dampak pendapatan langsung hanya sebagian kecil dari apa yang sebenarnya biayanya. Yang saya lihat organisasi sering melewatkan jatuh ke dalam beberapa kategori.

Pertama adalah kepercayaan pelanggan. Penalti SLA adalah konstruksi hukum – mereka tidak menangkap pelanggan yang diam-diam berhenti berlangganan, atau prospek perusahaan yang melihat halaman status Anda pada saat yang salah dan memilih pesaing. Kerusakan itu lambat, tidak terlihat, dan permanen dengan cara yang cek pembayaran tidak.

Kedua adalah turnover dan kelelahan insinyur. Kecelakaan on-call adalah nyata. Ketika insinyur terbaik Anda secara berulang-ulang ditarik ke dalam insiden yang penuh tekanan – terutama yang bisa dicegah – mereka mulai mempertanyakan apakah ini tempat yang tepat untuk membangun karir mereka. Menggantikan insinyur senior membutuhkan biaya antara satu hingga dua kali gaji tahunan mereka ketika Anda mempertimbangkan perekrutan, onboarding, dan kehilangan pengetahuan institusional. Tidak ada yang memasukkannya ke dalam post-mortem.

Ketiga adalah biaya kesempatan. Setiap jam tim teknik menghabiskan waktu untuk memerangi kebakaran adalah satu jam yang tidak dihabiskan untuk membangun produk. Itu sulit untuk dimasukkan ke dalam spreadsheet, tetapi dikompilasi selama berbulan-bulan, itu diam-diam meledakkan roadmap Anda.

Insinyur sering ditarik dari membangun fitur baru untuk merespons insiden produksi. Bagaimana kebakaran konstan ini mempengaruhi inovasi produk dan pengembangan jangka panjang?

Hal itu menciptakan pajak pada kemampuan tim teknik untuk membangun. Setiap tim memiliki bandwidth yang terbatas, dan ketika sebagian besar bandwidth itu terus diarahkan ke insiden, efeknya pada pengembangan produk sangat parah. Komitmen roadmap terlewat. Utang teknis tidak dibayar. Fitur dikirim dengan kurang ketat karena ada tekanan untuk mengganti waktu yang hilang.

Apa yang sangat merusak adalah ketidakpastian. Tim dapat merencanakan sprint dengan niat baik, dan kemudian insiden besar meledak pada hari Selasa dan semua yang lain menjadi sekunder. Ketidakpastian yang berkelanjutan seperti itu membuat hampir mustahil untuk membangun budaya kerja dalam – yang pada akhirnya menghasilkan hasil teknik terbaik.

Hal itu juga menciptakan siklus yang memperkuat diri sendiri. Investasi yang ditunda berarti lebih banyak insiden, yang berarti lebih banyak kebakaran, yang berarti lebih sedikit waktu untuk berinvestasi pada masalah yang mendasarinya. Di Strudel, bagian besar dari apa yang kami bangun khusus untuk tim SRE yang hidup ini setiap hari.

Strudel menghubungkan data dukungan pelanggan, log, sistem produksi, dan repositori kode untuk mengidentifikasi penyebab akar lebih cepat. Bagaimana AI menghubungkan sinyal teknis yang berbeda ini dengan cara yang tidak dapat dilakukan oleh alat pemantauan tradisional?

Alat pemantauan tradisional pada dasarnya adalah sistem peringatan. Mereka sangat baik dalam mengatakan bahwa sesuatu telah melewati ambang batas – lonjakan latensi, tingkat kesalahan yang meningkat, pod yang rusak. Apa yang mereka tidak bisa lakukan adalah bernalar di seluruh domain.

Mereka tidak tahu bahwa lonjakan tingkat kesalahan di layanan pembayaran Anda terjadi empat menit setelah deploy ke ketergantungan, dan bahwa tiket dukungan pelanggan yang menyebutkan kegagalan checkout datang sekitar waktu yang sama, dan bahwa pola yang sama muncul di log Anda enam bulan yang lalu selama migrasi database.

Itulah yang diaktifkan oleh AI. Kami dapat memperlakukan tiket Zendesk, komit GitHub, jejak Datadog (DDOG ), dan log CloudWatch sebagai bagian dari cerita yang terpadu daripada titik data yang terisolasi. AI menyajikan tidak hanya apa yang rusak, tetapi juga mengapa dan di mana – dan itu didasarkan pada bukti yang dapat diverifikasi dan diaktifkan oleh insinyur manusia. Kami tidak meminta tim untuk mempercayai kotak hitam. Kami memberi mereka hipotesis yang terbukti dan awal yang lebih cepat.

Anda menjelaskan Strudel sebagai memberikan “intelijen teknik”. Apa yang dimaksud dengan konsep ini dalam prakteknya, dan bagaimana itu berbeda dari platform observabilitas atau AIOps konvensional?

Kristin: Observabilitas pada dasarnya tentang instrumentasi dan visibilitas – memastikan bahwa telemetry ada dan tim dapat mengquerynya. AIOps, dalam sebagian besar implementasinya saat ini, adalah tentang mengurangi kebisingan peringatan melalui korelasi dan deteksi anomali berbasis ML. Keduanya sangat berharga, dan kami mengintegrasikannya.

Tapi intelijen teknik adalah lapisan di atas. Kami mengambil apa yang dilakukan AIOps dan memperluasnya. Di mana AIOps mengatakan bahwa sesuatu salah, intelijen teknik membantu Anda memahami mengapa itu salah, dari mana asalnya, dan apa yang harus dilakukan – menarik sinyal dari seluruh tumpukan, termasuk sumber yang tidak dilihat oleh alat AIOps tradisional, seperti tiket dukungan pelanggan atau perubahan kode. Tujuannya bukan hanya untuk mengurangi kebisingan. Ini untuk memberi tim Anda gambaran yang lengkap dan dapat diaktifkan sehingga mereka dapat memecahkan masalah lebih cepat dan kembali membangun.

Agen AI semakin banyak diterapkan untuk mengotomatisasi alur kerja teknis yang kompleks. Apa peran yang Anda lihat agen AI mainkan dalam mendiagnosis dan memecahkan insiden perangkat lunak selama lima tahun ke depan?

Saya pikir pertanyaan yang lebih menarik bukanlah apa yang akan dilakukan agen – tetapi apa yang akan berhenti dilakukan insinyur. Insinyur terbaik yang pernah saya kerjakan dengan tidak masuk ke dalam bidang ini untuk menghabiskan malam mereka dengan memantau peringatan atau mencari log untuk perubahan konfigurasi yang dilakukan pada hari Jumat sore. Itu bukan mengapa mereka menjadi baik dalam pekerjaan mereka.

Selama lima tahun ke depan, saya pikir agen mengambil sebagian besar pekerjaan yang berulang-ulang – pekerjaan pencocokan pola, perakitan konteks, yang penting tetapi tidak di mana bakat insinyur senior harus dihabiskan. Itu membebaskan orang untuk fokus pada masalah yang kompleks, keputusan arsitektur, hal-hal yang sebenarnya memerlukan penilaian manusia.

Banyak gangguan berasal dari bug kecil atau perubahan konfigurasi yang terlewatkan selama pengujian. Bagaimana sistem AI dapat mengidentifikasi pola halus dalam kode, log, atau sinyal infrastruktur cukup awal untuk mencegah insiden besar?

AI yang dirancang dengan baik memiliki keunggulan nyata di sini, dan itu bukan karena lebih pintar dari insinyur Anda – tetapi karena tidak pernah lupa dan tidak pernah tidur. Insinyur manusia mungkin tidak menghubungkan pola log yang halus hari ini dengan sesuatu yang terjadi enam bulan yang lalu di bagian lain sistem. AI dapat. Ini memantau semua, sepanjang waktu, dan memiliki memori yang lebih panjang dan lebih luas daripada individu mana pun di tim Anda.

Perusahaan sering menginvestasikan banyak dalam alat deteksi tetapi masih berjuang dengan waktu rata-rata untuk resolusi. Apa yang menjadi penghalang terbesar yang mencegah organisasi menutup kesenjangan antara deteksi insiden dan resolusi penyebab akar yang sebenarnya?

Deteksi pada dasarnya adalah masalah yang sudah terpecahkan. Sebagian besar tim memiliki peringatan. Mereka tahu sesuatu salah. Kesenjangan adalah segala sesuatu yang terjadi setelah itu.

Ketika insinyur dipanggil, mereka tidak memasuki situasi yang jelas dengan semua konteks yang relevan yang dirakit dengan rapi. Mereka memasuki kekacauan. Mereka harus mencari tahu apa yang berubah, kapan itu berubah, sistem mana yang terpengaruh, apakah ada dampak pelanggan, apakah itu terkait dengan sesuatu yang terjadi minggu lalu. Mereka menarik dari Slack, dari dashboard, dari log deploy, dari tiket dukungan – melakukan pekerjaan perakitan konteks secara manual, di bawah tekanan, sering di tengah malam.

Itulah botol leher. Bukan karena insinyur dan tim dukungan teknis tidak tahu cara memecahkan masalah – tetapi karena mereka menghabiskan 30 hingga 60 menit pertama dari setiap insiden hanya mencoba memahami apa yang mereka lihat. Itulah di mana Strudel hidup. Tesis kami adalah bahwa jika Anda dapat memberi insinyur gambaran yang koheren, didukung oleh bukti, tentang apa yang terjadi dan mengapa – tepat ketika mereka membutuhkannya – Anda secara dramatis mengompresi kesenjangan itu. Pekerjaan resolusi masih milik mereka. Kami hanya mendapatkan mereka ke garis start lebih cepat.

Saat sistem AI mulai menganalisis data produksi, kodebasis, dan log operasional, apa pertimbangan tata kelola atau keamanan yang harus tim teknik pertimbangkan saat menerapkan alat tersebut?

Hal yang paling saya rasakan kuat di sini adalah ini: manusia masih harus meninjau kode yang masuk ke produksi.

Saya telah berbicara dengan banyak insinyur tentang ini, dan satu hal yang saya dengar berulang-ulang adalah bahwa AI menulis bug dengan efisien dan cerdas. Sangat cerdas, sebenarnya. Dengan cara yang dapat benar-benar sulit untuk ditangkap – bahkan oleh insinyur senior yang meninjau kode dengan hati-hati. Bug tidak selalu jelas. Mereka dapat terlihat sangat masuk akal pada pandangan pertama.

Jadi saat AI menulis lebih banyak kode yang masuk ke produksi, saya pikir kita akan melihat lebih banyak masalah halus yang terlewatkan – tidak karena siapa pun yang ceroboh, tetapi karena sifat bug AI yang dihasilkan berbeda. Lebih sulit untuk ditemukan dalam tinjauan. Lebih sulit untuk ditangkap dalam pengujian.

Menghadap ke depan, apakah Anda pikir masa depan teknik keandalan akan bergeser ke arah infrastruktur AI-pertama, di mana sistem otonom memantau, mendiagnosis, dan bahkan memperbaiki masalah sebelum manusia menyadarinya? Jika ya, apa yang terlihat seperti alur kerja untuk insinyur?

Saya pikir kita menuju ke arah itu, tetapi saya pragmatis tentang timeline. Sistem otonom yang sepenuhnya menyelesaikan insiden produksi tanpa kesadaran manusia – itu bukan di mana kita sekarang, dan saya tidak pikir itu di mana kita akan berada dalam beberapa tahun ke depan. Dan saya pikir itu tidak apa-apa.

Apa yang saya percayai adalah bahwa loop menjadi lebih ketat dan kurang menyakitkan. Masa depan yang saya eksitasi bukanlah di mana manusia dihilangkan dari persamaan – itu adalah di mana manusia yang terintegrasi ke dalam proses menghabiskan waktu mereka pada bagian yang sebenarnya memerlukan mereka. Keputusan yang memerlukan penilaian. Situasi yang tidak biasa. Insiden yang belum pernah terjadi sebelumnya. AI menangani pencocokan pola, perakitan konteks, triase rutin. Insinyur menangani keputusan.

Bagi insinyur itu sendiri, saya pikir itu terlihat seperti: lebih sedikit waktu on-call di tengah malam untuk hal-hal yang tidak perlu membangunkan mereka, dan lebih banyak waktu untuk membangun sistem yang tidak rusak dari awal. Kebakaran tidak menghilang sepenuhnya. Tetapi itu menjadi pengecualian daripada keadaan default menjadi insinyur di perusahaan yang menjalankan perangkat lunak skala besar. Itu adalah masa depan yang patut dibangun.

Terima kasih atas wawancara yang luar biasa, pembaca yang ingin mempelajari lebih lanjut harus mengunjungi Strudel.