Интервью
Кристин Айзек, генеральный директор и сооснователь Strudel – Интервью
Кристин Айзек, генеральный директор и сооснователь Strudel, является ветераном лидером предприятия технологий, который занимал старшие роли в LinkedIn, Udemy, ESPN и Disney до запуска Strudel. Теперь она сосредоточена на решении одной из самых больших точек трения в организациях программного обеспечения: разрыва между поддержкой клиентов и инжинирингом. В Strudel она строит платформу, управляемую ИИ, которая помогает техническим командам поддержки решать сложные проблемы быстрее, соединяя запросы поддержки напрямую с инженерной интеллектом. Ее опыт в масштабировании команд, построении стратегий выхода на рынок и стимулировании роста на глобальных организациях помог сформировать быстрый ранний успех и сильную позицию Strudel на рынке корпоративного ИИ и инструментов разработки.
Strudel – это платформа ИИ, построенная для автоматизацииadvanced технической поддержки путем анализа журналов, производственных данных, кодовых репозиториев и истории поддержки для определения коренных причин и рекомендации решений. Ее цель – уменьшить время и инженерные усилия, необходимые для решения сложных случаев поддержки, особенно тех, которые обычно потребляют старшие технические ресурсы. Соединяя поддержку напрямую с основными техническими проблемами, Strudel позиционирует себя как инструмент, который может сделать операции поддержки корпоративного уровня быстрее, более эффективными и намного более масштабируемыми.
Вы занимали руководящие должности в организациях, таких как LinkedIn, Udemy и Disney, прежде чем основать Strudel в 2025 году. Какой опыт из этих ролей в конечном итоге убедил вас, что инженерные команды нуждаются в новом виде платформы “инженерной интеллекта” с поддержкой ИИ, и как это понимание сформировало основание Strudel?
Каждая компания, в которой я работала, имела разную версию одной и той же проблемы. В Disney ставки были огромными – если платформа потокового вещания вышла из строя во время крупного запуска, это не было просто ударом по доходу, это был момент бренда. В LinkedIn масштаб был безжалостным. Там были тысячи сервисов, все генерирующих шум, и даже лучшие команды боролись за то, чтобы поспевать. В Udemy я увидела, как команда из нескольких человек делала героические вещи с ограниченным инструментарием.
Что соединяло все три и опыт моих сооснователей, Шая Рубина и Брайана Кауфмана, в руководстве инженерными командами, было то, что инженеры тратили больше времени на реконструкцию контекста, чем на решение проблем. Кто-то получает сигнал в 2 часа ночи, и прежде чем он даже сможет начать диагностику, он просматривает Slack-threads, панели, Jira-записи, журналы развертывания – просто пытаясь понять, что изменилось и когда. Они по сути играют в детектива, прежде чем смогут сделать свою фактическую работу. Это расточительство невероятно талантливых людей.
Я постоянно думала: должно быть, есть более умный способ представить то, что действительно важно, когда это важно. Это действительно семя Strudel.
Многие компании измеряют финансовое воздействие простоя в терминах потерянного дохода или штрафов SLA. В вашем опыте, какие из менее заметных затрат простоя организации постоянно недооценивают?
Число дохода попадает в презентацию совета директоров, но непосредственное финансовое воздействие простоя составляет только часть того, что простой фактически стоит. Те, которых я видела организации постоянно упускают из виду, делятся на несколько категорий.
Первая – доверие клиентов. Штрафы SLA – это юридическая конструкция – они не отражают клиента, который тихо отменяет подписку или корпоративного клиента, который увидел вашу страницу статуса в неправильный момент и выбрал конкурента. Этот ущерб медленный, невидимый и постоянный так, что возврат денег просто не является.
Вторая – это текучесть и выгорание инженеров. Усталость от дежурства реальна. Когда ваши лучшие инженеры повторно привлекаются к высоко-стрессовым инцидентам – особенно тем, которые могли быть предотвращены – они начинают сомневаться, является ли это правильным местом для построения своей карьеры. Замена старшего инженера стоит от одного до двух раз его годовой зарплаты, когда вы учитываете расходы на набор персонала, обучение и потерю институциональных знаний. Никто не включает это в пост-мортем.
Третья – это стоимость упущенных возможностей. Каждый час, который инженерная команда тратит на борьбу с инцидентами, – это час, который не тратится на построение продукта. Это трудно поставить на таблицу, но в совокупности за месяцы это тихо взрывает вашу дорожную карту.
Инженеры часто отвлекаются от построения новых функций для реагирования на инциденты в производстве. Как это постоянное тушение пожаров влияет на инновации продукта и долгосрочное развитие дорожных карт?
Это создает налог на способность инженерной команды строить. Каждая команда имеет конечное количество полосы пропускания, и когда значительная часть этого постоянно перенаправляется на инциденты, эффект от компаундинга на разработку продукта является тяжелым. Обязательства по дорожной карте пропускаются. Технический долг не оплачивается. Функции отправляются с меньшей тщательностью, потому что есть давление, чтобы наверстать потерянное время.
Что особенно вредно, так это непредсказуемость этого. Команда может спланировать свой спринт с хорошими намерениями, и затем крупный инцидент взрывается в вторник, и все остальное становится второстепенным. Этот вид устойчивой непредсказуемости делает практически невозможным построение культуры глубокой работы – что в конечном итоге стимулирует лучшие инженерные результаты.
Это также создает самоподдерживающийся цикл. Отсроченный инвестиции означают больше инцидентов, которые означают больше тушения пожаров, что означает еще меньше времени для инвестирования в основные проблемы. В Strudel большая часть того, что мы строим, предназначена специально для команд SRE, которые живут этим каждый день.
Strudel соединяет данные поддержки клиентов, журналы, производственные системы и кодовые репозитории для определения коренных причин быстрее. Как ИИ объединяет эти различные технические сигналы таким образом, что традиционные инструменты мониторинга не могут?
Традиционные инструменты мониторинга являются фундаментально системами оповещения. Они отлично подходят для того, чтобы сказать вам, что что-то перешло порог – скачок задержки, растущая скорость ошибок, падение пода. Что они не могут сделать, так это рассуждать через домены.
Они не знают, что скачок скорости ошибок в вашем платежном сервисе произошел четыре минуты после развертывания зависимости, и что тикет поддержки клиентов, упоминающий неудачи при оформлении заказа, пришел примерно в то же время, и что последний раз эта закономерность появилась в ваших журналах шесть месяцев назад во время миграции базы данных.
Эта междоменная корреляция – это то, что позволяет ИИ. Мы можем рассматривать тикет Zendesk, коммит GitHub, трассировку Datadog и журнал CloudWatch как часть одной объединенной истории, а не изолированные данные. ИИ представляет не только то, что сломано, но и вероятную причину и где – и это основано на доказательствах, которые человеческий инженер может фактически проверить и действовать. Мы не просим команд доверять черному ящику. Мы даем им хорошо обоснованную гипотезу и фору.
Вы описываете Strudel как доставляющий “инженерную интеллект”. Что означает эта концепция на практике, и как она отличается от конвенциональной наблюдаемости или платформ AIOps?
Kristin: Наблюдаемость фундаментально связана с инструментарием и видимостью – обеспечивая, чтобы телеметрия была там и что команды могли запросить ее. AIOps, в большинстве его текущих реализаций, связано с уменьшением шума оповещений через ML-корреляцию и обнаружение аномалий. Оба действительно ценны, и мы интегрируемся с ними.
Но инженерная интеллект – это слой выше. Мы берем то, что делает AIOps, и расширяем на это. Где AIOps говорит вам, что что-то не так, инженерная интеллект помогает вам понять, почему это не так, где оно началось и что с этим делать – вытягивая сигналы из всего вашего стека, включая источники, которые традиционные инструменты AIOps даже не рассматривают, такие как тикеты поддержки клиентов или изменения кода. Цель не только уменьшить шум. Это дать вашей команде полную, действенную картину, чтобы они могли решить проблему быстрее и вернуться к построению.
Подумайте об этом как о разнице между детектором дыма и следователем пожара. Наблюдаемость и AIOps – это детектор дыма – необходимы, но они останавливаются на сигнале. Инженерная интеллект – это то, что происходит после: вот что произошло, вот почему, вот где оно началось.
Агенты ИИ все чаще развертываются для автоматизации сложных технических рабочих процессов. Какую роль, по вашему мнению, агенты ИИ будут играть в диагностике и решении инцидентов программного обеспечения в течение следующих пяти лет?
Я думаю, что более интересный вопрос не то, что агенты будут делать – это то, что инженеры перестанут делать. Лучшие инженеры, с которыми я работала, не вступили в эту область, чтобы тратить свои ночи на трассировку оповещений или поиск в журналах изменений конфигурации, которые кто-то сделал в пятницу днем. Это не то, почему они стали хорошими в своей работе. Но это то, на что тратится огромная часть их времени.
В течение следующих пяти лет я думаю, что агенты берут на себя много этой рутины – повторяющуюся, сопоставляющую с образцом, сбор контекста работу, которая важна, но не то, где должно тратиться время старших инженеров. Это освобождает людей, чтобы сосредоточиться на сложных проблемах, архитектурных решениях, вещах, которые действительно требуют человеческого суждения.
Что волнительно для меня, так это то, что это не только будущее состояние – мы видим это разворачивающимся прямо сейчас, включая в Strudel. Наш весь дорожная карта ориентирован на удаление административной и поддерживающей работы с тарелок инженеров. И то, что мы находим, честно, это то, что оно меняет то, что возможно для команды. Вы можете строить больше, двигаться быстрее и делать это с меньшим количеством людей – потому что люди, которых у вас есть, сосредоточены на стратегии и сложности, а не на оплате своих долгов на повторяющихся вещах. Это кажется значительным сдвигом в том, как команды строятся и структурируются в будущем.
Многие простой происходят от небольших ошибок или изменений конфигурации, которые проскользнули через тестирование. Как системы ИИ могут выявить тонкие закономерности в коде, журналах или сигналах инфраструктуры достаточно рано, чтобы предотвратить крупные инциденты?
Хорошо сконструированный ИИ имеет реальное преимущество здесь, и это не то, что он умнее ваших инженеров – это то, что он никогда не забывает и никогда не спит. Человек может не связать тонкую закономерность журналов сегодня с чем-то, что произошло шесть месяцев назад в совершенно другой части системы. ИИ может. Он наблюдает за всем, все время, и у него есть гораздо более длинная и широкая память, чем у любого человека в вашей команде.
Тем не менее, есть что-то еще, о чем я слышала от клиентов много: предотвращение является только таким хорошим, как данные под ним. Если ваши журналы непоследовательны, неполны или разрознены по десятку инструментов, которые не говорят друг с другом, ИИ работает с фрагментированной картиной. Мусор в, мусор из – это все еще правда. Мы тратим много времени с клиентами, помогая им думать о качестве данных и инструментарии, потому что лучший ИИ в мире не может выявить сигнал, который никогда не был захвачен в первую очередь.
Компании часто инвестируют много в инструменты обнаружения, но все еще борются со средним временем до решения. Какие являются самыми большими барьерами, которые предотвращают организацию от закрытия разрыва между обнаружением инцидента и фактическим решением коренной причины?
Обнаружение в основном является решенной проблемой на данный момент. Большинство команд имеют оповещения. Они знают, что что-то не так. Разрыв – это все, что происходит после.
Когда инженер получает сигнал, он не входит в ясную ситуацию со всем соответствующим контекстом, аккуратно собранным. Он входит в беспорядок. Ему приходится выяснить, что изменилось, когда оно изменилось, какая система оно затронуло, есть ли влияние на клиента, связано ли оно с чем-то, что произошло на прошлой неделе. Он тянет из Slack, из панелей, из Jira-записей, из тикетов поддержки – делая эту сборку контекста вручную, под давлением, часто в середине ночи.
Эта сборка контекста – это узкое место. Это не то, что инженеры и команды поддержки не знают, как решать проблемы – это то, что они тратят первые 30-60 минут каждого инцидента, просто пытаясь понять, на что они смотрят. Это то, где живет Strudel. Наша целая теза заключается в том, что если вы можете передать инженеру связную, основанную на доказательствах картину того, что произошло и почему – прямо когда им это нужно – вы значительно сжимаете этот разрыв. Работа по решению все еще принадлежит им. Мы просто получаем их к стартовой линии намного быстрее.
Когда системы ИИ начинают анализировать производственные данные, кодовые базы и операционные журналы, какие соображения по управлению или безопасности должны иметь в виду инженерные команды при развертывании этих инструментов?
Та вещь, о которой я чувствую себя наиболее сильно, – это то, что люди должны все еще просматривать код, который попадает в производство.
Я говорила с многими инженерами об этом, и одна вещь, которую я слышу снова и снова, – это то, что ИИ пишет ошибки эффективно и巧妙но. На самом деле очень巧ательно, так, что может быть действительно трудно поймать – даже для старших инженеров, которые тщательно просматривают код. Ошибки не всегда очевидны. Они могут выглядеть совершенно разумно на первый взгляд.
Итак, когда ИИ пишет все больше и больше кода, который попадает в производство, я думаю, что мы увидим больше этих тонких, трудно-находимых проблем, которые проскальзывают – не потому, что кто-то был беззаботным, а потому, что природа ошибок ИИ другой. Труднее заметить при просмотре. Труднее поймать при тестировании.
Честно говоря, это одна из причин, почему я думаю, что случай для того, что делает Strudel, становится только сильнее со временем. Если больше ошибок попадает в производство, способность найти и решить их быстрее становится более важной, а не менее. Вопрос управления не только о контролях доступа и разрешениях – хотя эти вещи важны и команды должны быть вдумчивыми о том, к каким данным они дают ИИ-системам доступ. Это также о том, чтобы держать людей на правильных контрольных точках, особенно вокруг всего, что касается производства.
Оглядываясь вперед, думаете ли вы, что будущее инженерии надежности сместится в сторону инфраструктуры ИИ, где автономные системы мониторят, диагностируют и даже исправляют проблемы до того, как люди осознают их? Если да, то какой рабочий процесс будет у инженеров в этом будущем?
Я думаю, что мы движемся в этом направлении, но я прагматична относительно сроков. Полностью автономные системы, решающие инциденты в производстве без какого-либо человеческого осознания – это не то, где мы находимся, и я не думаю, что мы будем там в течение следующих нескольких лет. И я думаю, что это нормально.
Что я действительно верю, так это то, что петля становится намного плотнее и менее болезненной. Будущее, которое меня волнует, – это не то, где люди удаляются из уравнения – это то, где люди, интегрированные в процесс, тратят свое время на части, которые действительно требуют их. Суждения. Новый ситуации. Инцидент, который вы никогда не видели раньше. ИИ обрабатывает сопоставление с образцом, сбор контекста, рутинную трассировку. Инженеры обрабатывают решения.
Для самих инженеров я думаю, что это выглядит как: меньше времени на дежурстве в середине ночи для вещей, которые не должны были их будить, и больше времени на построение систем, которые не ломаются в первую очередь. Пожарная охрана не исчезает полностью. Но она становится исключением, а не нормальным состоянием быть инженером в компании, запускающей программное обеспечение в масштабе. Это будущее, которое стоит строить.
