Крістін Айзек, генеральний директор і співзасновник Strudel – Серія інтерв’ю

Крістін Айзек, генеральний директор і співзасновник 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 – це юридична конструкція – вони не відображають клієнта, який тихо припиняє співробітництво, або корпоративного клієнта, який побачив сторінку статусу в неправильний момент і вибрав конкурента. Ця шкода повільна, невидима і постійна у спосіб, який простий чек на повернення коштів просто не є.

Друга – відхід інженерів і вихід з lựcового стану. Втома від чергової зміни реальна. Коли ваші найкращі інженери повторно залучаються до інцидентів високого рівня напруженості – особливо тих, які могли бути попереджені – вони починають сумніватися, чи це правильне місце для побудови своєї кар’єри. Заміна старшого інженера коштує будь-яку суму від одного до двох років його річної зарплати, коли ви берете до уваги витрати на набір персоналу, адаптацію та втрачені знання інституту. Ніхто не включає це в пост-мортем.

Третя – витрати на втрачені можливості. Кожна година, яку інженерна команда витрачає на боротьбу з пожежами, – це година, не витрачена на побудову продукту. Це важко поставити в таблицю, але в підсумку над місяцями це тихо знищує вашу дорожню карту.

Інженерів часто відводять від побудови нових функцій для реагування на інциденти виробництва. Як це постійне гасіння пожеж впливає на інновації продукту і довгострокові плани розвитку?

Це створює податок на здатність інженерної команди будувати. Кожна команда має скінченну кількість смуги пропускання, і коли значна частина цього постійно перенаправляється на інциденти, складовий ефект на розвиток продукту є серйозним. Зобов’язання дорожньої карти пропускаються. Технічний борг не сплачується. Функції відправляються з меншою ретельністю, оскільки є тиск, щоб компенсувати втрачений час.

Що особливо шкідливо, так це непередбачуваність цього. Команда може спланувати свій спринт з хорошими намірами, а потім великий інцидент вибухає у вівторок, і все інше стає вторинним. Така тривала непередбачуваність робить майже неможливим побудувати культуру глибокої роботи – яка в кінцевому підсумку приводить до найкращих інженерних результатів.

Це також створює самопідтримуючий цикл. Відкладений інвестиційний внесок означає більше інцидентів, які означають більше гасіння пожеж, яке означає ще менше часу для інвестицій у основні проблеми. В Strudel велика частина того, над чим ми працюємо, призначена конкретно для команд SRE, які живуть цим кожен день.

Strudel зв’язує дані підтримки клієнтів, журнали, системи виробництва і репозиторії коду для визначення кореневих причин швидше. Як штучний інтелект поєднує ці різні технічні сигнали таким чином, яким традиційні інструменти моніторингу не можуть?

Традиційні інструменти моніторингу фундаментально є системами оповіщення. Вони відмінно підходять для повідомлення про те, що щось перетнуло поріг – сплеск затримки, зростання рівня помилок, падіння поду. Що вони не можуть зробити, так це розібратися у доменах.

Вони не знають, що сплеск рівня помилок у вашій службі оплат відбулося через чотири хвилини після розгортання залежності, і що квиток підтримки клієнта, який згадує про проблеми з оплатою, надійшов приблизно в той самий час, і що останній раз ця модель з’явилася у ваших журналах шість місяців тому під час міграції бази даних.

Ця кореляція між доменами – це те, що дозволяє штучний інтелект. Ми можемо розглядати квиток Zendesk, коміт GitHub, трейс Datadog (DDOG ) і журнал CloudWatch як частину однієї єдиної історії, а не ізольованих даних. Штучний інтелект поверхнево не тільки те, що пошкоджено, а й ймовірна причина і місце – і він базується на доказах, які людина-інженер може фактично перевірити і діяти. Ми не просимо команди довіряти чорній скриньці. Ми даємо їм добре обґрунтовану гіпотезу і головний старт.

Ви описуєте Strudel як платформу, яка доставляє “інженерні знання”. Що означає ця концепція на практиці, і як вона відрізняється від традиційних платформ спостережливості або AIOps?

Спостережливість фундаментально полягає в інструментуванні і видимості – забезпечення того, що телеметрія існує і що команди можуть запитувати її. AIOps, у більшості своїх поточних реалізацій, полягає у зменшенні шуму оповіщення через кореляцію і виявлення аномалій на основі машинного навчання. Обидва ці інструменти є справжньо цінними, і ми інтегруємося з ними.

Але інженерні знання – це рівень вище. Ми беремо те, що робить AIOps, і розширюємо це. Де AIOps каже вам, що щось не так, інженерні знання допомагають вам зрозуміти, чому це не так, де воно почалося, і що з цим робити – витягуючи сигнали з усього вашого стеку, включаючи джерела, яких традиційні інструменти AIOps навіть не розглядають, наприклад квитки підтримки клієнтів або зміни коду. Метою не є просто зменшення шуму. Це дати вашій команді повну, діючу картину, щоб вони могли вирішити проблему швидше і повернутися до побудови.

Агенти штучного інтелекту все частіше розгортаються для автоматизації складних технічних робочих процесів. Яку роль, на вашу думку, агенти штучного інтелекту будуть відігравати у діагностиці та вирішенні інцидентів програмного забезпечення протягом наступних п’яти років?

Я думаю, що більш цікавим питанням не є те, що агенти будуть робити, а те, що інженери перестануть робити. Найкращі інженери, з якими я працювала, не вступили в цю галузь, щоб витрачати свої ночі на тріаж оповіщень або пошуки в журналах зміни конфігурації, яку хтось зробив у п’ятницю ввечері. Це не те, чому вони стали хорошими у своїй роботі. Але це саме те, що забирає величезну частку їхнього часу.

За наступні п’ять років я думаю, що агенти візьмуть на себе багато цієї рутинної роботи – повторюваної, узгоджувальної, контекстної роботи, яка важлива, але не там, де старші інженерні таланти повинні витрачати свій час. Це звільняє людей, щоб зосередитися на складних проблемах, архітектурних рішеннях, тих речах, які насправді вимагають людської уваги.

Що мене надихає, так це те, що це не просто майбутнє стан – ми бачимо це прямо зараз, включаючи Strudel. Наш весь дорожній карт є орієнтований на видалення адміністративної та технічної роботи з дошки інженерів. І те, що ми знаходимо, чесно кажучи, це те, що це змінює те, що можливе для команди. Ви можете будувати більше, рухатися швидше і робити це з меншою кількістю людей – тому що люди, яких у вас є, зосереджені на стратегії і складності, а не на повторюваній роботі. Це відчувається як значуща зміна у тому, як команди будуються і структуруються вперед.

Багато простоїв походять від малих помилок або змін конфігурації, які прослизають крізь тестування. Як системи штучного інтелекту можуть визначити тонкі моделі в коді, журналах або сигналах інфраструктури досить рано, щоб запобігти великим інцидентам?

Хорошо створений штучний інтелект має реальну перевагу тут, і це не те, що він розумніший за ваших інженерів – це те, що він ніколи не забуває і ніколи не спить. Людина може не пов’язати тонку модель журналу сьогодні з тим, що відбулося шість місяців тому в зовсім іншій частині системи. Штучний інтелект може. Він спостерігає за всім, весь час, і має набагато довшу і ширшу пам’ять, ніж будь-яка людина в вашій команді.

Але також є щось інше, про що я чую від клієнтів багато: профілактика так само хороша, як і дані під нею. Якщо ваші журнали несумісні, неповні або ізольовані по десятку інструментів, які не спілкуються один з одним, штучний інтелект працює з фрагментованою картиною. Сміття в, сміття out – це все ще правда. Ми витрачаємо багато часу з клієнтами, допомагаючи їм думати про якість даних і інструментування, тому що найкращий штучний інтелект у світі не може поверхнево сигнал, який ніколи не був захоплений з початку.

Компанії часто інвестують великі кошти в інструменти виявлення, але все одно борються з середнім часом до вирішення. Які найбільші бар’єри перешкоджають організаціям закрити розрив між виявленням інцидентів і фактичним вирішенням кореневої причини?

Виявлення в основному є розв’язаною проблемою на цьому етапі. Більшість команд мають оповіщення. Вони знають, що щось не так. Розрив – це все, що відбувається наступним.

Коли інженер отримує повідомлення, він не вступає в чітку ситуацію з усіма відповідними контекстами, зібраними. Він вступає в хаос. Він повинен розібратися, що змінилося, коли це змінилося, яку систему воно торкнулося, чи є вплив на клієнта, чи це пов’язано з тим, що відбулося минулого тижня. Він тягне з Slack, з панелей управління, з журналів розгортання, з квитків підтримки – роблячи цю збірку вручну, під тиском, часто в середині ночі.

Ця збірка контексту – це пляшка. Інженери і команди технічної підтримки не те що не знають, як вирішувати проблеми – це те, що вони витрачають перші 30-60 хвилин кожного інциденту, просто намагаючись зрозуміти, на що вони дивляться. Це саме те, де живе Strudel. Наша ціла теза полягає в тому, що якщо ви можете передати інженеру узгоджену, засновану на доказах картину того, що відбулося і чому – саме тоді, коли йому це потрібно – ви драматично стискаєте цей розрив. Робота з вирішення все ще залишається за ними. Ми просто приводимо їх до стартової лінії набагато швидше.

Під час початку аналізу даних виробництва, кодової бази та операційних журналів яких урядових або безпекових міркувань інженерні команди повинні мати на увазі при розгортанні цих інструментів?

Те, про що я найсильніше відчуваю тут, це те, що люди повинні все ще переглядати код, який потрапляє у виробництво.

Я розмовляла з багатьма інженерами про це, і одна річ, яку я чую знову і знову, полягає в тому, що штучний інтелект пише помилки ефективно і винахідливо. Дійсно винахідливо, насправді. У спосіб, який може бути справді важко виявити – навіть для старших інженерів, які переглядають код ретельно. Помилки не завжди очевидні. Вони можуть виглядати абсолютно розумно на перший погляд.

Отже, коли штучний інтелект пише все більше і більше коду, який потрапляє у виробництво, я думаю, що ми побачимо більше цих тонких, важко виявних проблем, які прослизають – не тому, що хтось був недбалий, а тому, що природа помилок штучного інтелекту інша. Більш важка для виявлення при перегляді. Більш важка для виявлення при тестуванні.

Чесно? Це одна з причин, чому я думаю, що справа за тим, що робить Strudel, тільки посилюється з часом. Якщо більше помилок потрапляє у виробництво, здатність знайти і вирішити їх швидше стає більш важливою, а не менш важливою. Питання урядових органів не полягає тільки в контролі доступу до даних і дозволах – хоча ці речі важливі, і команди повинні бути ретельними щодо того, які дані вони надають будь-якій системі штучного інтелекту. Це також про те, щоб тримати людей на правильних контрольних точках, особливо навколо всього, що торкається виробництва.

Оглядаючись вперед, ви думаєте, що майбутнє інженерії надійності буде рухатися до інфраструктури “перш за все штучний інтелект”, де автономні системи моніторять, діагностують і навіть виправляють проблеми до того, як люди про них дізнаються? Якщо так, то який робочий процес виглядає для інженерів?

Я думаю, що ми рухаємось в цьому напрямку, але я прагматична щодо графіка. Повністю автономні системи, які вирішують інциденти виробництва без будь-якої людської участі – це не там, де ми є, і я не думаю, що це буде протягом наступних кількох років. І я думаю, що це нормально.

Що я вірю, так це те, що петля стає набагато щільнішою і набагато менш болісною. Майбутнє, яке мене надихає, не таке, де люди видаляються з рівняння – це майбутнє, де люди, інтегровані в процес, витрачають свій час на частини, які насправді вимагають їх. Судові рішення. Новели ситуації. Інцидент, якого ви ніколи не бачили раніше. Штучний інтелект займається узгодженням моделей, збіркою контексту, рутинним тріажем. Інженери займаються рішеннями.

Для інженерів самих я думаю, що це виглядає так: менше часу на чергуванні в середині ночі для речей, які не повинні їх розбудити, і більше часу на побудову систем, які не ламаються з початку. Гасіння пожеж не зникає повністю. Але воно стає винятком, а не стандартним станом бути інженером в компанії, яка запускає програмне забезпечення у великому масштабі. Це майбутнє, яке варто будувати.

Дякую за велике інтерв’ю, читачам, які бажають дізнатися більше, слід відвідати Strudel.