Інтерв’ю
Крістін Айзек, CEO та співзасновник Strudel – Серія інтерв’ю
Крістін Айзек, CEO та співзасновник Strudel є ветераном лідером підприємства технологій, який займав керівні посади в LinkedIn, Udemy, ESPN та Disney до заснування Strudel. Тепер вона зосереджена на вирішенні однієї з найбільших проблем у організаціях програмного забезпечення: розрив між підтримкою клієнтів та інженерією. В Strudel вона будує платформу, керовану штучним інтелектом, яка допомагає технічним командам підтримки вирішувати складні питання швидше, зв’язуючи запити підтримки безпосередньо з інженерними знаннями. Її досвід у масштабуванні команд, розробці стратегій виходу на ринок та стимулюванні росту в глобальних організаціях допоміг сформувати швидкий початковий успіх та сильне позиціонування Strudel на ринку корпоративного штучного інтелекту та інструментів для розробників.
Strudel – це платформа штучного інтелекту, створена для автоматизації складної технічної підтримки шляхом аналізу журналів, даних виробництва, репозиторіїв коду та історії підтримки для визначення кореневих причин та рекомендацій рішень. Її мета – скоротити час та зусилля інженерів, необхідні для вирішення складних випадків підтримки, особливо тих, які зазвичай споживають старших технічних ресурсів. Зв’язуючи підтримку безпосередньо з основними технічними проблемами, Strudel позиціонує себе як інструмент, який може зробити операції з підтримки підприємства швидшими, ефективнішими та більш масштабованими.
Ви займали керівні посади в організаціях, таких як LinkedIn, Udemy та Disney, до заснування Strudel у 2025 році. Які досвіди з цих ролей в кінцевому підсумку переконали вас, що інженерним командам потрібна нова платформа “інженерних знань”, керована штучним інтелектом, і як це розуміння сформувало заснування Strudel?
Кожна компанія, в якій я працювала, мала свою версію однієї й тієї ж проблеми. У Disney ставки були величезними – якщо платформа потокового мовлення вийшла з ладу під час великого запуску, це не було просто ударом по доходах, а ударом по бренду. У LinkedIn масштаб був безжалісним. Там були тисячі послуг, які всі генерували шум, і навіть найкращі команди боролися, щоб跟увати. У Udemy я бачила ланкуючу команду, яка робила героїчні речі з обмеженими інструментами.
Що пов’язувало всі три компанії та досвід моїх співзасновників, Шая Рубіна та Браяна Кауфмана, з керівництвом інженерними командами, було те, що інженери витрачали більше часу на реконструкцію контексту, ніж на фактичне вирішення проблем. Хтось отримує сторінку о 2 годині ночі, і до того, як вони навіть зможуть розпочати діагностику, вони повинні переглянути всі теми у Slack, панелі керування, квитки Jira, журнали розгортання – просто намагаючись зрозуміти, що змінилося і коли. Вони фактично грають у детектива, перш ніж зможуть зробити свою справжню роботу. Це марнування надзвичайно талановитих людей.
Я постійно думала: має бути розумніший спосіб подання того, що насправді важливо, коли це важливо. Це саме те, що є зерном Strudel.
Багато компаній вимірюють фінансовий вплив простою в термінах втрачених доходів або штрафів за SLA. За вашим досвідом, які менш помітні витрати на простої організації постійно недооцінюють?
Число доходу потрапляє до презентації ради директорів, але безпосередній вплив на доходи становить лише частину того, що простій фактично коштує. Ті, яких я бачила організації постійно пропускають, належать до декількох категорій.
Перша – це довіра клієнтів. Штрафи за SLA – це юридична конструкція – вони не відображають клієнта, який тихо припиняє співпрацю, або корпоративного клієнта, який побачив вашу сторінку статусу в неправильний момент і вибрав конкурента. Ця шкода повільна, невидима і постійна тим чином, яким простий чек не є.
Друга – це відхід інженерів і вихід з вигоранням. Вигорання через чергу є реальним. Коли ваші найкращі інженери повторно залучаються до інцидентів високого рівня стресу – особливо тих, які могли бути попереджені – вони починають ставити під сумнів, чи це правильне місце для будівництва своєї кар’єри. Заміна старшого інженера коштує будь-якої кількості від одного до двох разів його річної зарплати, коли ви берете до уваги витрати на набір, адаптацію та втрачені інституційні знання. Ніхто не ставить це у звіт після інциденту.
Третя – це витрати на втрачені можливості. Кожна година, яку інженерна команда витрачає на боротьбу з інцидентами, – це година, яку не витрачають на будівництво продукту. Це важко поставити у таблицю, але в підсумку над місяцями це тихо знищує вашу дорожню карту.
Інженерів часто відводять від будівництва нових функцій для реагування на інциденти виробництва. Як це постійне гасіння пожеж впливає на інновації продукту та довгострокові плани розвитку?
Це створює податок на здатність інженерної команди будувати. Кожна команда має скінченну кількість смуги пропускання, і коли значна частина цього постійно перенаправляється на інциденти, складний вплив на розвиток продукту є серйозним. Зобов’язання дорожньої карти пропускаються. Технічний борг не сплачується. Функції відправляються з меншою ретельністю, оскільки є тиск на компенсацію втраченого часу.
Що особливо шкідливо, так це непередбачуваність цього. Команда може спланувати свій спринт з добрими намірами, а потім великий інцидент вибухає у вівторок, і все інше стає вторинним. Така тривала непередбачуваність робить майже неможливим будівництво культури глибокої роботи – яка в кінцевому підсумку рухає найкращі інженерні результати.
Це також створює самопідтримуючий цикл. Відкладений інвестиційний внесок означає більше інцидентів, які означають більше гасіння пожеж, що означає ще менше часу на інвестиції в основні проблеми. В Strudel велика частина того, над чим ми будемо працювати, призначена конкретно для команд SRE, які живуть цією кожної доби.
Strudel зв’язує дані клієнтської підтримки, журнали, системи виробництва та репозиторії коду для визначення кореневих причин швидше. Як штучний інтелект поєднує ці різні технічні сигнали тим чином, яким традиційні інструменти моніторингу не можуть?
Традиційні інструменти моніторингу фундаментально є системами сповіщень. Вони чудові у повідомленні про те, що щось перетнуло поріг – сплеск затримки, зростання рівня помилок, падіння поду. Що вони не можуть зробити, так це розсудити через домени.
Вони не знають, що сплеск рівня помилок у вашій службі платежів відбувся через чотири хвилини після розгортання залежності, і що квиток клієнтської підтримки, який згадує невдачі під час оплати, надійшов приблизно в той самий час, і що останній раз ця модель з’явилася у ваших журналах шість місяців тому під час міграції бази даних.
Така кореляція через домени – це те, що дозволяє штучний інтелект. Ми можемо розглядати квиток Zendesk, коміт GitHub, трейс Datadog та журнал CloudWatch як частину однієї єдиної історії, а не ізольованих даних. Штучний інтелект поверх не тільки того, що зламано, а й ймовірної причини та місця – і він базується на доказах, які людина-інженер може фактично перевірити та діяти. Ми не просимо команди довіряти чорній скриньці. Ми даємо їм добре обґрунтовану гіпотезу та головний старт.
Ви описуєте Strudel як надання “інженерних знань”. Що означає ця концепція на практиці, і як вона відрізняється від традиційних платформ спостережуваності чи AIOps?
Kristin: Спостережуваність фундаментально полягає в інструментуванні та видимості – забезпечення того, що телеметрія є там і що команди можуть запитувати її. AIOps, у більшості своїх поточних реалізацій, полягає у зменшенні шуму сповіщень через кореляцію та виявлення аномалій на основі машинного навчання. Обидва є дійсно цінними, і ми інтегруємося з ними.
Але інженерні знання – це рівень вище. Ми беремо те, що робить AIOps, і розширюємо його. Де AIOps каже, що щось не так, інженерні знання допомагають вам зрозуміти, чому це не так, де воно почалося, і що з цим робити – витягуючи сигнали з усього вашого стеку, включаючи джерела, які традиційні інструменти AIOps навіть не розглядають, наприклад квитки клієнтської підтримки чи зміни коду. Метою не є просто зменшення шуму. Це надання вашій команді повної, дієвої картини, щоб вони могли вирішити проблему швидше і повернутися до будівництва.
Підумайте про це як про різницю між детектором диму та слідчим пожежі. Спостережуваність та AIOps – це детектор диму – необхідний, але вони зупиняються на сповіщенні. Інженерні знання – це те, що відбувається після: ось що сталося, ось чому, ось де воно почалося.
Агенти штучного інтелекту все частіше розгортаються для автоматизації складних технічних робочих процесів. Яку роль, на вашу думку, будуть відігравати агенти штучного інтелекту у діагностиці та вирішенні інцидентів програмного забезпечення протягом наступних п’яти років?
Я думаю, що більш цікавим питанням не є те, що агенти зроблять – а те, що інженери перестануть робити. Найкращі інженери, з якими я працювала, не вступили у цю галузь, щоб витрачати свої ночі на тріаж сповіщень або пошуки у журналах змін конфігурації, яких хтось зробив у п’ятницю ввечері. Це не те, чому вони стали хорошими у своїй роботі. Але це саме те, чим займає більшу частину їхнього часу.
За наступні п’ять років я думаю, що агенти беруть на себе багато цього тягаря – повторюваної, узгоджувальної, контекстно-залежної роботи, яка є важливою, але не там, де повинен витрачати свій час талановитий інженер. Це звільняє людей, щоб зосередитися на складних проблемах, архітектурних рішеннях, тих речах, які насправді вимагають людської уваги.
Що цікаво мені, так це те, що це не просто майбутній стан – ми бачимо це зараз, включаючи Strudel. Наш весь план дорожньої карти орієнтований на видалення адміністративної та технічної роботи з тарелів інженерів. І те, що ми знаходимо, чесно, це те, що це змінює те, що можливе для команди. Ви можете будувати більше, рухатися швидше і робити це з меншою кількістю людей – тому що люди, яких у вас є, зосереджені на стратегії та складності, а не на сплаті боргів за повторювану роботу. Це здається значущим зсувом у тому, як команди будуються та структуруються вперед.
Багато простоїв походять від малих багів або змін конфігурації, які прослизають крізь тестування. Як системи штучного інтелекту можуть визначити тонкі моделі у коді, журналах чи сигналах інфраструктури достатньо рано, щоб запобігти великим інцидентам?
Хорошо створений штучний інтелект має справжню перевагу тут, і це не те, що він розумніший за ваших інженерів – це те, що він ніколи не забуває і ніколи не спить. Людина може не пов’язати тонку модель журналу сьогодні з тим, що відбулося шість місяців тому в зовсім іншій частині системи. Штучний інтелект може. Він дивиться на все, весь час, і має набагато довшу та ширшу пам’ять, ніж будь-хто у вашій команді.
Це сказано, є ще одна річ, про яку ми чуємо від клієнтів багато: профілактика є лише такою хорошою, як дані під нею. Якщо ваші журнали є неконсистентними, неповними або ізольованими по десятку інструментів, які не розмовляють один з одним, штучний інтелект працює з фрагментованою картиною. Сміття у вході, сміття на виході – це все ще правда. Ми витрачаємо багато часу з клієнтами, допомагаючи їм думати про якість даних та інструментування, тому що найкращий штучний інтелект у світі не може поверхнути сигнал, який ніколи не був захоплений з самого початку.
Компанії часто інвестують великі кошти у інструменти виявлення, але все ще борються з середнім часом до вирішення. Які найбільші бар’єри перешкоджають організаціям закрити розрив між виявленням інцидентів та фактичним вирішенням кореневої причини?
Виявлення в основному є розв’язаним питанням на цьому етапі. Більшість команд мають сповіщення. Вони знають, що щось не так. Розрив – це все, що відбувається наступним.
Коли інженер отримує сторінку, він не вступає у ясну ситуацію з усіма відповідними контекстами, які є зібрані. Він вступає у хаос. Він повинен визначити, що змінилося, коли це змінилося, яку систему це торкнулося, чи є вплив на клієнта, чи це пов’язано з тим, що відбулося минулого тижня. Він тягне з Slack, з панелей керування, з квитків Jira, з журналів розгортання – роблячи цю роботу збору контексту вручну, під тиском, часто посеред ночі.
Ця збірка контексту – це瓶aggable. Це не те, що інженери та команди технічної підтримки не знають, як вирішувати проблеми – це те, що вони витрачають перші 30-60 хвилин кожного інциденту просто намагаючись зрозуміти, на що вони фактично дивляться. Це саме те, де живе Strudel. Наша вся теза полягає в тому, що якщо ви можете передати інженеру узгоджену, засновану на доказах картину того, що відбулося і чому – саме тоді, коли їм це потрібно – ви драматично стискаєте цей розрив. Робота з вирішення залишається за ними. Ми просто приводимо їх до лінії старту значно швидше.
Когда системи штучного інтелекту починають аналізувати дані виробництва, кодові бази та операційні журнали, які питання управління або безпеки слід мати на увазі інженерним командам при розгортанні цих інструментів?
Те, про що я відчуваю найсильніше тут, це те, що люди повинні все ще переглядати код, який потрапляє до виробництва.
Я розмовляла з багатьма інженерами про це, і одна річ, яку я чую знову і знову, це те, що штучний інтелект пише баги ефективно та винахідливо. Дійсно винахідливо, насправді. Тим чином, який може бути дійсно важким для виявлення – навіть для старших інженерів, які ретельно переглядають код. Баги не завжди очевидні. Вони можуть виглядати абсолютно розумно на перший погляд.
Таким чином, коли штучний інтелект пише все більше і більше коду, який потрапляє до виробництва, я думаю, що ми побачимо більше цих тонких, важких для виявлення проблем, які прослизають крізь – не тому, що хтось був недбалий, а тому, що природа багів штучного інтелекту інша. Більш важка для виявлення під час перегляду. Більш важка для виявлення під час тестування.
Чесно? Це одна з тих причин, чому я думаю, що справа за тим, що робить Strudel, тільки посилюється з часом. Якщо більше багів потрапляє до виробництва, здатність знайти та вирішити їх швидше стає ще більш важливою, а не менш. Питання управління не лише про контроль доступу до даних та дозволів – хоча ці речі мають значення, і команди повинні бути ретельними щодо того, до яких даних вони дають будь-якій системі штучного інтелекту доступ. Це також про те, щоб тримати людей на правильних контрольних точках, особливо навколо всього, що торкається виробництва.
Оглядаючи вперед, думаєте ви, що майбутнє інженерії надійності зсунеся у бік інфраструктури “перш за все штучний інтелект”, де автономні системи моніторять, діагностують та навіть виправляють проблеми до того, як люди про них дізнаються? Якщо так, то як виглядатиме майбутня робоча потока для інженерів?
Я думаю, що ми рухаємося в цьому напрямку, але я є прагматиком щодо графіка. Повністю автономні системи, які вирішують інциденти виробництва без будь-якої людської участі – це не те, де ми є зараз, і я не думаю, що ми будемо там протягом наступних кількох років. І я думаю, що це нормально.
Що я вірю, так це те, що петля стає значно тіснішою та менш болісною. Майбутнє, яке мене цікавить, не те, де люди видаляються з рівняції – це те, де люди, інтегровані у процес, витрачають свій час на частини, які насправді вимагають їх. Судження. Новітні ситуації. Інцидент, якого ви ніколи не бачили раніше. Штучний інтелект обробляє узгодження моделей, збір контексту, рутинний тріаж. Інженери обробляють рішення.
Для інженерів самих я думаю, що це виглядатиме так: менше часу на чергуванні вночі для речей, які не потребували б їхнього пробудження, і більше часу на будівництво систем, які не ламаються з самого початку. Гасіння пожеж не зникає зовсім. Але воно стає винятком, а не станом інженера за компанією, яка запускає програмне забезпечення у великому масштабі. Це майбутнє, яке варто будувати.
