インタビュー
Kristin Isaac, CEO and Co-Founder at Strudel – Interview Series
Kristin Isaac, CEO and Co-Founder at Strudelは、LinkedIn、Udemy、ESPN、Disneyでのシニア役職を歴任したベテランのエンタープライズテクノロジーリーダーです。Strudelを立ち上げる前に、彼女はカスタマーサポートとエンジニアリングの間にある大きな摩擦点である問題に取り組んでいます。Strudelでは、AI駆動のプラットフォームを構築しており、サポートリクエストをエンジニアリングインテリジェンスに直接接続することで、テクニカルサポートチームが複雑な問題をより迅速に解決できるようにしています。彼女のチームのスケーリング、ゴー・トゥ・マーケット戦略の構築、グローバル組織での成長の推進に関する経験は、Strudelの急速な初期トラクションとエンタープライズAIおよびデベロッパーツール市場における強いポジショニングに役立っています。
Strudelは、ログ、プロダクションデータ、コードリポジトリ、過去のサポート履歴を分析して根本原因を特定し、解決策を提案することで、先進的なテクニカルサポートを自動化するために構築されたAIプラットフォームです。難しいサポートケース、特にシニアテクニカルリソースを消費するエスカレーションの種類を解決するために必要な時間とエンジニアリング努力を削減することを目的としています。サポートを根本的なテクニカル問題に直接接続することで、Strudelは、エンタープライズサポート運用をより迅速、効率的、スケーラブルにできるツールとして自己を位置付けます。
LinkedIn、Udemy、Disneyなどの組織でのリーダーシップ役職を歴任した後、2025年にStrudelを共同設立しました。どのような経験がエンジニアリングチームに新しい種類のAI駆動の「エンジニアリングインテリジェンス」プラットフォームが必要であることを最終的に確信させ、どのようにしてStrudelの設立に影響しましたか?
私が働いたすべての会社には、同じ問題の異なるバージョンがありました。Disneyでは、賭けが大きかったです。ストリーミングプラットフォームがメジャーな立ち上げ中にダウンした場合、それは単に収益へのヒットではなかった。ブランドの瞬間だったからです。LinkedInでは、スケールが激しかったです。何千ものサービスがすべてノイズを生み出しており、最も優れたチームでもそれを追跡するのに苦労していました。Udemyでは、限られたツールで英雄的なことを成し遂げているスリムなチームを見ました。
これらすべてを結びつけたのは、エンジニアが問題を解決するよりもコンテキストを再構築することに多くの時間を費やしているということです。誰かが午前2時に呼び出され、診断を開始する前に、Slackスレッド、ダッシュボード、Jiraチケット、デプロイログを調べて、変更された内容と時刻を理解しようとしているからです。彼らは、実際の仕事をする前に、探偵のような仕事をしています。那は、非常に才能のある人々の浪費です。
私は、重要なものを表面化するためのより賢い方法があるはずだと思い続けました。Strudelの種は実際にそこにあります。
多くの会社は、ダウンタイムの財務への影響を失われた収益またはSLAペナルティの観点から測定します。貴方の経験では、組織が一貫して過小評価している、見えにくいダウンタイムのコストは何ですか?
収益番号はボードデッキに表示されますが、即時の収益への影響はダウンタイムの実際のコストの小さな部分にすぎません。見落とされるものは次のカテゴリに分類されます。
最初は顧客の信頼です。SLAペナルティは法的構成です。顧客が静かに解約したり、エンタープライズプロスペクトが間違った瞬間にステータスページを見て競合他社を選択したりすることを捉えていません。そのような損害は、返金チェックではありません。遅い、見えにくい、永久的なものです。
2番目はエンジニアの離職とバーンアウトです。オンコールの疲労は実際です。エンジニアが繰り返し、高ストレスのインシデント、特に予防可能なものに引き込まれると、彼らは自分のキャリアを築くのに適切な場所であるかどうか疑問視し始めます。シニアエンジニアを交代することは、採用、オンボーディング、失われた機関知識を考慮すると、年間給与の1〜2倍のコストがかかります。誰もがポストモーテムにそれを記載していません。
3番目は機会費用です。エンジニアリングチームが消防活動に費やすすべての時間は、製品を構築する時間ではありません。那はスプレッドシートに乗りませんが、数ヶ月にわたって蓄積し、ロードマップを静かに吹き飛ばします。
エンジニアは、新しい機能を構築するのではなく、プロダクションインシデントに応答するために頻繁に引き出されます。このような消防活動は、製品のイノベーションと長期的な開発ロードマップにどのような影響を与えますか?
それはエンジニアリングチームの製品を構築する能力に課税を課します。すべてのチームには有限のバンド幅があり、多くのバンド幅がインシデントに常にリダイレクトされる場合、製品開発への影響は深刻です。ロードマップのコミットメントが失われ、テクニカルデットが支払われません。機能は、失われた時間を取り戻す圧力のために、より厳格に出荷されます。
特に有害なのは、その予測不可能性です。チームはスプリントを良い意図で計画できますが、重大なインシデントが火曜日に発生し、すべての他のものが二次的なものになります。那種の持続的な予測不可能性は、深い作業の文化を構築することをほぼ不可能にします。深い作業は、最終的に最良のエンジニアリング成果を駆り立てます。
また、自己強化サイクルを作成します。投資の遅れは、さらに多くのインシデントを意味し、さらに多くの消防活動を意味し、根本的な問題に投資する時間はさらに少なくなります。Strudelでは、毎日それを生きているSREチームのために構築することに重点を置いています。
Strudelは、顧客サポートデータ、ログ、プロダクションシステム、コードリポジトリを接続して根本原因をより迅速に特定します。従来の監視ツールができないように、AIはこれらのさまざまなテクニカルシグナルをどのように統合しますか?
従来の監視ツールは基本的にアラートシステムです。何かがしきい値を超えたことを伝えるには優れています。遅延スパイク、エラーレートの増加、ポッドのクラッシュなどですが、それらはドメイン間で推論することはできません。
デプロイ後の依存関係へのデプロイがエラーレートのスパイクの4分後に発生し、同時に顧客サポートチケットがチェックアウトの失敗について言及し、同じパターンが6か月前にログに表示されたことがあることを知ることができません。
ドメイン間の相関関係は、AIが可能にするものです。Zendeskチケット、GitHubコミット、Datadogトレース、CloudWatchログを、分離されたデータポイントではなく、1つの統一された物語の部分として扱うことができます。AIは、実際に動作するエビデンスに基づいて、どこに、どこで、そしてなぜ壊れたのかを表面化します。ブラックボックスを信頼するようにチームに頼むのではなく、人間のエンジニアが実際に検証して行動できる、よく根拠のある仮説と先行を提供します。
Strudelを「エンジニアリングインテリジェンス」を提供するものと説明します。実践ではその概念とは何ですか?従来の可観測性またはAIOpsプラットフォームとはどのように異なりますか?
Kristin: 可観測性は基本的にインストルメンテーションと可視性についてです。テレメトリが存在し、チームがそれを照会できることを確認することです。AIOpsは、ほとんどの実装では、MLベースの相関と異常検出を介したアラートノイズの削減についてです。両方とも真正に有益ですが、私たちが統合しています。
しかし、エンジニアリングインテリジェンスは1つ上の層です。私たちは、AIOpsが何をしているかを取り、それを拡張しています。AIOpsが何かが間違っていることを伝える場合、エンジニアリングインテリジェンスは、それがなぜ間違っているのか、どこから始まったのか、そして何をすべきかを理解するのに役立ちます。従来のAIOpsツールが見ないソース、たとえば顧客サポートチケットやコード変更を含む、スタック全体のシグナルを取ります。目標はノイズを減らすことだけではありません。チームに、問題をより迅速に解決できるように、完全で行動可能な画像を提供することです。
それを、煙検知器と火災調査官の違いとして考えてみましょう。可観測性とAIOpsは煙検知器です。必須ですが、アラームで止まります。エンジニアリングインテリジェンスはそれ以降に来ます。何が起こったのか、どこで起こったのか、そこで何が起こったのか。
AIエージェントは、複雑なテクニカルワークフローを自動化するために増えていくようになっています。次の5年間で、ソフトウェアインシデントの診断と解決においてAIエージェントが果たす役割をどのように見ていますか?
私は、エージェントが何をやるかということよりも、エンジニアが何をやめるかということの方が面白いと思います。最も優れたエンジニアがこの分野に入った理由は、夜の間にアラートをトリアージしたり、金曜日の午後に誰かが行った構成変更をログを調べて探したりすることではありません。そうする必要はないからです。
次の5年間で、エージェントがそのようなグラインドを多く引き受けると思います。繰り返し、パターンマッチング、コンテキストアセンブリの作業は重要ですが、シニアエンジニアリングタレントが時間を費やすべきではありません。エンジニアは、複雑な問題、建築上の決定、人間の判断が必要なものに集中できるようになります。
何が興奮するかというと、それは将来の状態だけではありません。私たちが今見ていることです。Strudelのロードマップは、エンジニアのプレートから管理とメンテナンスの作業を除去することに向けられています。私たちが発見したのは、実際に、チームの何が可能かを変えているということです。より多くを構築できます。より速く動きます。より少ない人で行うことができます。持っている人々は、繰り返しのものではなく、戦略と複雑さに集中しているからです。那は、チームが構築され、構成される方法に意味のあるシフトのように感じます。
AIシステムがプロダクションデータ、コードベース、運用ログを分析し始めると、エンジニアリングチームはこれらのツールの展開時にどのようなガバナンスまたはセキュリティの考慮事項を念頭に置く必要がありますか?
私は、人間がまだプロダクションに投入されるコードをレビューしている必要があると強く感じています。
私は多くのエンジニアとこの件について話しましたが、1つのことが繰り返し聞かれます。AIは、非常に賢い方法でバグを効率的に書きます。実際には、コードを慎重にレビューしているシニアエンジニアでも、簡単に気付かないバグです。
AIがプロダクションコードに書き込まれるコードの量が増えるにつれて、私はこれらの微妙で、検出が難しい問題が増えると考えています。人間のレビューでは簡単に検出できないバグです。そうする必要はないからです。
それが、Strudelが行っていることのケースがさらに強化される理由の1つです。バグがプロダクションに侵入することが多くなると、より迅速にそれらを見つけて解決する能力がより重要になります。ガバナンスの問題は、データへのアクセス制御や権限だけではありません。AIシステムにデータを提供することについて、チームは慎重に考えなければなりません。最も優れたAIは、ガベージインプットの場合、ガベージアウトプットになります。
多くのアウトエージは、小さなバグや構成変更によって発生し、テストを通過します。AIシステムは、コード、ログ、またはインフラシグナル内の微妙なパターンをどのようにして、主要なインシデントを防ぐのに十分な早さに検出できますか?
うまく作られたAIにはここで実際の利点があります。それは、AIが人間よりも賢いということではなく、AIは忘れずに、眠らずにいるということです。人間は、今日の微妙なログパターンを6か月前にシステムの別の部分で発生したことと関連付けることができないかもしれません。AIはできます。
ただし、1つさらに言及することは、防止は、基になるデータの質だけに良いということです。ログが一貫性がなく、不完全、または話をしない12のツールに分散している場合、AIは断片化された画像で作業しています。ガベージインプット、ガベージアウトプットは、まだ当てはまります。私たちは、データの品質とインストルメンテーションについてよく考えるべきです。最も優れたAIは、キャプチャされていないシグナルを表面化することはできません。
企業は、検出ツールに多くを投資していますが、まだ平均解決時間に苦労しています。インシデントの検出と実際の根本原因の解決の間のギャップを埋めることを妨げている最大の障壁は何ですか?
検出は基本的に解決された問題です。ほとんどのチームにはアラートがあります。何かが間違っていることを知っています。ギャップは、次に何が起こるかです。
エンジニアが呼び出されたとき、彼らは明確な状況に直面するのではなく、メスを歩きます。何が変更されたか、いつ変更されたか、どのシステムに影響したか、顧客への影響はあるか、先週に起こったことと関連しているかを判断するために、Slackスレッド、ダッシュボード、Jiraチケット、デプロイログを調べます。コンテキストアセンブリの作業を手動で行います。プレッシャーのかかる中、多くの場合、深夜に。
コンテキストアセンブリがボトルネックです。エンジニアやテクニカルサポートチームは問題を解決することを知っています。ただし、実際に何を見ているのかを理解するのに最初の30〜60分を費やします。Strudelのテーゼは、エンジニアに、証拠に基づいた、根本原因と理由のある画像を、必要なときに提供することで、ギャップを劇的に圧縮できるということです。解決作業はまだ彼らのものです。私たちが彼らをスターティングラインに早く到達させるだけです。
将来、信頼性エンジニアリングの将来は、AIファーストインフラストラクチャーに向かってシフトするでしょうか。そこでは、自律システムが監視、診断、そして人間が気付く前に問題を解決します。そうであれば、エンジニアのワークフローはどうなりますか?
私は、その方向に進んでいると思いますが、タイムラインについては現実的です。完全に自律的なシステムが、人間の関与なしにプロダクションインシデントを解決するということ、それは今ではありません。次の数年でもないと思います。私は、それが大きな問題ではないと思います。
私が楽しみな将来は、ループがより緊密で、より少ない痛みを伴うものです。将来、私が楽しみなのは、人間がプロセスから除外されるのではなく、人間がプロセスに組み込まれたときに時間を費やす部分が、実際に人間が必要な部分であるというものです。判断、ノベルな状況、前に見たことがないインシデント。AIはパターンマッチング、コンテキストアセンブリ、ルーチンワークのトリアージを処理します。エンジニアは、決定を下します。
エンジニア自身の場合、私は、夜の間に起こるものではなく、システムが最初から壊れないように構築する時間が増える将来を想像しています。消防活動は完全に消え去るわけではありませんが、デフォルトの状態ではなく、例外になります。深い作業の文化を構築することは、最終的に最良のエンジニアリング成果を促進します。
素晴らしいインタビュー、詳しく知りたい読者はStrudelを訪問してください。
