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

Второй – текучесть кадров и выгорание инженеров. Усталость от дежурства реальна. Когда ваши лучшие инженеры повторно вовлекаются в высоко-стрессовые инциденты – особенно те, которые могли быть предотвращены – они начинают сомневаться, является ли это правильным местом для построения своей карьеры. Замена старшего инженера стоит где-то от одного до двух раз его годовой зарплаты, когда вы учитываете расходы на набор персонала, обучение и потерю институциональных знаний. Никто не включает это в пост-мортем.

Третий – альтернативная стоимость. Каждый час, который инженерная команда тратит на борьбу с пожарами, – это час, который не тратится на построение продукта. Это трудно отразить в таблице, но в течение месяцев это тихо взрывает вашу дорожную карту.

Инженеры часто отвлекаются от построения новых функций для реагирования на инциденты в производстве. Как это постоянное тушение пожаров влияет на инновации продукта и долгосрочное развитие?

Это создает налог на способность инженерной команды строить. Каждая команда имеет конечную емкость, и когда значительная часть этой емкости постоянно перенаправляется на инциденты, эффект от этого на развитие продукта очень серьезный. Обязательства по дорожной карте пропускаются. Технический долг не погашается. Функции доставляются с меньшей тщательностью, потому что есть давление, чтобы наверстать потерянное время.

Особенно вредно непредсказуемость этого. Команда может спланировать свой спринт с хорошими намерениями, и затем крупный инцидент происходит во вторник, и все остальное становится второстепенным. Такая устойчивая непредсказуемость делает практически невозможным построение культуры глубокой работы – которая в конечном итоге стимулирует лучшие инженерные результаты.

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

Strudel соединяет данные поддержки клиентов, журналы, системы производства и репозитории кода для выявления коренных причин быстрее. Как искусственный интеллект объединяет эти различные технические сигналы таким образом, который традиционные инструменты мониторинга не могут?

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

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

Такая корреляция через области – это то, что позволяет искусственный интеллект. Мы можем рассматривать тикет Zendesk, коммит GitHub, трассировку Datadog (DDOG ) и журнал CloudWatch как часть одной объединенной истории, а не изолированных точек данных. Искусственный интеллект выносит на поверхность не только то, что сломано, но и вероятную причину и где – и он основывает это на доказательствах, которые человеческий инженер может фактически проверить и действовать. Мы не просим команды доверять черной коробке. Мы даем им хорошо обоснованную гипотезу и фору.

Вы описываете Strudel как доставляющий “инженерную разведку”. Что означает эта концепция на практике, и как она отличается от традиционных платформ наблюдаемости или AIOps?

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

Но инженерная разведка – это слой выше. Мы берем то, что делает AIOps, и расширяем на это. Где AIOps говорит вам, что что-то не так, инженерная разведка помогает вам понять, почему это не так, откуда оно началось и что с этим делать – вынимая сигналы из всей вашей стека, включая источники, которые традиционные инструменты AIOps даже не рассматривают, такие как тикеты поддержки клиентов или изменения кода. Цель не только в снижении шума. Это дать вашей команде полную, действенную картину, чтобы они могли решить проблему быстрее и вернуться к построению.

Подумайте об этом как о разнице между детектором дыма и следователем пожаров. Наблюдаемость и AIOps – это детектор дыма – необходимые, но они останавливаются на сигнале тревоги. Инженерная разведка – это то, что происходит после: вот что произошло, вот почему, вот откуда оно началось.

Агенты искусственного интеллекта все чаще развертываются для автоматизации сложных технических рабочих процессов. Какую роль, по вашему мнению, агенты искусственного интеллекта будут играть в диагностике и решении инцидентов программного обеспечения в течение следующих пяти лет?

Я думаю, что более интересный вопрос не в том, что будут делать агенты, а в том, что инженеры перестанут делать. Лучшие инженеры, с которыми я работала, не стали заниматься этой областью, чтобы тратить свои ночи на оповещения или поиск в журналах изменения конфигурации, которое кто-то сделал в пятницу afternoon. Это не то, для чего они стали хорошими в своей работе. Но это то, что большая часть их времени съедается.

В течение следующих пяти лет я думаю, что агенты берут на себя много этой рутины – повторяющуюся, сопоставляющую закономерности, сбор контекста – важную, но не то, где должно тратиться время старших инженеров. То, что интересно мне, – это то, что это не только будущее состояние – мы видим это прямо сейчас, включая в Strudel. Наш весь план развития ориентирован на удаление административной и поддерживающей работы из тарелок инженеров. И то, что мы находим, честно говоря, – это то, что это меняет то, что возможно для команды. Вы можете строить больше, двигаться быстрее и делать это с меньшим количеством людей – потому что люди, которых у вас есть, сосредоточены на стратегии и сложности, а не на выполнении повторяющихся задач. Это кажется значительным сдвигом в том, как команды строятся и структурируются в будущем.

Многие простой происходят из-за небольших ошибок или изменений конфигурации, которые проскользнули через тестирование. Как системы искусственного интеллекта могут выявить тонкие закономерности в коде, журналах или сигналах инфраструктуры достаточно рано, чтобы предотвратить крупные инциденты?

Хорошо сконструированный искусственный интеллект имеет реальное преимущество здесь, и это не то, что он умнее ваших инженеров – это то, что он никогда не забывает и никогда не спит. Человек может не связать тонкую закономерность журнала сегодня с чем-то, что произошло шесть месяцев назад в совершенно другой части системы. Искусственный интеллект может. Он наблюдает за всем, все время, и имеет гораздо более длинную и широкую память, чем любой человек в вашей команде.

Однако также есть то, о чем я слышала от клиентов много: предотвращение только так хорошо, как данные, лежащие в его основе. Если ваши журналы непоследовательны, неполны или разрознены по десятку инструментов, которые не разговаривают друг с другом, искусственный интеллект работает с фрагментированной картиной. Мусор на входе, мусор на выходе – это все еще правда. Мы тратим много времени с клиентами, помогая им думать о качестве данных и инструментировании, потому что лучший искусственный интеллект в мире не может вынести на поверхность сигнал, который никогда не был захвачен в первую очередь.

Итак, ответ – да, искусственный интеллект может поймать вещи раньше и соединить точки, которые люди пропустят. Но команды, которые получают от этого наибольшую пользу, – это те, кто также сделал работу, чтобы убедиться, что их данные фактически стоят рассуждения.

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

Обнаружение в основном является решенной проблемой на данный момент. Большинство команд имеют оповещения. Они знают, что что-то не так. Разрыв – это все, что происходит после.

Когда инженер получает сигнал, он не входит в ясную ситуацию со всем соответствующим контекстом, аккуратно собранным. Он входит в беспорядок. Ему приходится выяснить, что изменилось, когда оно изменилось, какая система оно затронуло, есть ли влияние на клиента, связано ли оно с чем-то, что произошло на прошлой неделе. Он тянет из Slack, из панелей управления, из журналов развертывания, из тикетов поддержки – делая эту сборку контекста вручную, под давлением, часто посреди ночи.

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

Когда системы искусственного интеллекта начинают анализировать данные производства, кодовые базы и операционные журналы, какие соображения по управлению или безопасности должны иметь в виду инженерные команды при развертывании этих инструментов?

Та вещь, о которой я чувствую себя наиболее сильно, – это то, что люди все еще должны просматривать код, который попадает в производство.

Я говорила с многими инженерами об этом, и одна вещь, которую я слышу снова и снова, – это то, что искусственный интеллект пишет ошибки эффективно и умно. Действительно умно, на самом деле. Таким образом, который может быть действительно трудно поймать – даже для старших инженеров, которые тщательно просматривают код. Ошибки не всегда очевидны. Они могут выглядеть совершенно разумно на первый взгляд.

Итак, когда искусственный интеллект пишет больше и больше кода, который попадает в производство, я думаю, что мы увидим больше этих тонких, трудно обнаруживаемых проблем, которые проскальзывают – не потому, что кто-то был беззаботным, а потому, что природа ошибок, сгенерированных искусственным интеллектом, отличается. Труднее обнаружить при просмотре. Труднее обнаружить при тестировании.

Честно говоря, это одна из причин, почему я думаю, что случай для того, что делает Strudel, становится только сильнее со временем. Если больше ошибок попадает в производство, способность находить и решать их быстрее становится более важной, а не менее. Вопрос управления не только в контролях доступа к данным и разрешениях – хотя они имеют значение, и команды должны быть вдумчивыми о том, какие данные они дают любому системе искусственного интеллекта. Это также о том, чтобы держать людей на правильных контрольных точках, особенно вокруг всего, что касается производства.

Глядя вперед, думаете ли вы, что будущее инженерии надежности сдвинется в сторону инфраструктуры, основанной на искусственном интеллекте, где автономные системы мониторят, диагностируют и даже исправляют проблемы до того, как люди осознают их? Если да, то какой рабочий процесс будет у инженеров в этом будущем?

Я думаю, что мы движемся в этом направлении, но я прагматична относительно сроков. Полностью автономные системы, решающие инциденты в производстве без какого-либо осознания людей – это не то, где мы находимся, и я не думаю, что мы будем там в течение следующих нескольких лет. И я думаю, что это нормально.

Что я действительно верю, – это то, что петля становится намного плотнее и менее болезненной. Будущее, которое меня волнует, – это не то, где люди удаляются из уравнения – это то, где люди, интегрированные в процесс, тратят свое время на части, которые действительно требуют их. Суждения. Новые ситуации. Инцидент, который вы никогда не видели раньше. Искусственный интеллект занимается сопоставлением закономерностей, сбором контекста, рутинной триажей. Инженеры занимаются решениями.

Для самих инженеров я думаю, что это выглядит так: меньше времени на дежурстве посреди ночи за вещи, которые не должны их будить, и больше времени на построение систем, которые не ломаются в первую очередь. Тушение пожаров не исчезает полностью. Но оно становится исключением, а не нормальным состоянием быть инженером в компании, которая запускает программное обеспечение в масштабе. Это будущее, которое стоит строить.

Спасибо за отличное интервью, читателям, которые хотят узнать больше, следует посетить Strudel.