AIがインシデントを処理し、エンジニアはシステムとのつながりを失う

ブログに戻る2012年、LinkedInでSREをしていた頃、自己修復し、過去のインシデントから学習できるシステムを設計しました。当時のAI能力は今日のレベルには遠く及ばず、それはプロトタイプのままでしたが、今やそれは現実となっています。これらのツールは、アラートの検査、仮説の形成、テレメトリのクエリ、最近のデプロイとの相関付け、さらには修正の実装まで、すべてを行います。それが実現するのを見るのは素晴らしいことですが、私には大きな懸念があります。それは、私たちがシステムとのつながりを失いつつあるということです。これらのツールが日常的なインシデントを解決するのに長けるほど、人間の対応者が得る実践の機会は減ります。そして、自動化が解決できない曖昧で重大なインシデントが発生した場合、対応するエンジニアは苦境に立たされるでしょう。自動化は人間により困難なインシデントを残す「AI SRE」と呼ばれることが多いこれらのAI支援インシデント対応ツールは、多くの点で素晴らしいです。特に夜間に日常的なインシデントを処理し、容量の問題で呼び出される必要がないときは、魔法のように感じられます。問題は、日常的なインシデントが、対応者がシステムの挙動や障害に対する直感を「安全に」養う方法でもあるということです。AIが解決できない、困難で前例のないインシデントに遭遇した場合、エンジニアは以前よりも少ない実践経験で対応しなければならなくなります。人間要因の研究者であるLisanne Bainbridgeは、1983年の有名な論文「Automationの皮肉」でこのパラドックスを説明しました。彼女は、自動化はオペレーターが日常業務を実践する機会を減らす一方で、新しい異常な状況に対して責任を持たせることになると説明しました。そのため、オペレーターは自動化以前よりもさらに高いスキルと、より多くのトレーニングを必要とすると彼女は主張します。今後数年間で、AI支援インシデント対応のおかげで、ほとんどのインシデントの平均MTTR（平均復旧時間）は低下するでしょう。しかし、インシデント対応者がシステムとのつながりを失い、調査に苦労するため、複雑なインシデントの解決時間は急上昇すると予想されます。航空業界はパイロットに稀な障害の訓練を行う航空業界からインスピレーションを得ることができます。航空機の自動化は飛行の大部分を担いますが、パイロットは自動化が管理できない状況、つまりエンジンの故障、信頼性の低い計器、離陸中止、失速、その他の異常な状態に対して責任を負います。これらのイベントは非常に稀です。例えば、現代のタービンエンジンは、10万エンジン飛行時間あたり1件未満の飛行中シャットダウンしか発生しません。つまり、商業パイロットがシミュレーター以外でそれに遭遇することなく、キャリア全体を終えることができるほど稀なのです。しかし、障害が発生した場合、パイロットは迅速かつ正確に反応する必要があります。例えば、トランスアジア航空235便では、離陸直後に右エンジンのプロペラが自動的にフェザーリングしました。そして、航空機は左エンジンで飛行を継続できるように設計されていましたが、乗組員は問題を誤認しました。航空機は失速し、最初の警告からわずか117秒後に墜落しました。航空会社のパイロットは、稀な緊急事態をリハーサルするために定期的にシミュレーターに戻ります。米国FAAの規則では、機長は6ヶ月ごとに、離陸中のエンジン故障などのシナリオを含む、定期的な訓練または習熟度チェックを完了する必要があります。ほとんどのソフトウェアインシデントは命を脅かすものではありませんが、それは私たちの技術を完璧にしない理由にはなりません。問題を引き起こした技術が、それを解決するためにも役立つことが判明しました。ソフトウェア業界にはインシデントシミュレーターが必要Rootly、私が勤務している会社では、Uptime Labsと提携して、このアイデアを現実的なインシデントシミュレーションを通じて適用しています。エンジニアは、シミュレートされたeコマースの障害中にインシデントコマンダーの席につき、オブザーバビリティツールを使用しながら、SlackでLLM搭載のステークホルダーと調整します。結果はリアルに感じられます。何が問題なのかを調査しながら、対応を整理し、CEOやカスタマーサポートとやり取りする必要があります。インシデント中に重要なスキル、つまり不完全な情報から意味を理解すること、明確にコミュニケーションすること、人々を調整すること、そして実際に対応を実行することなどを実践できます。AIはこれらのスキルを維持するためにも役立つ可能性がありますが、AIをトレーナーとして使用することについてはどうでしょうか。対応者は、エージェントに、それが取った手順、調査したシグナル、診断の根拠を説明するように依頼できます。しかし、説明と観察は実践の代わりにはなりません。セリーナ・ウィリアムズのプレーを見ることからいくつか学ぶことはあるかもしれませんが、テニスはコートに出て初めて習得するものであり、インシデント対応も同様です。私はキャリアの半分以上を、プログレッシブ教育、つまり「やって学ぶ」という教育を中心にソフトウェアエンジニアリングスクールを構築することに費やしました。それは対面でしたが、教師はいませんでした。学生は講義を聞く代わりにプロジェクトに取り組みました。Dropboxが、採用した卒業生がまだトラブルシューティングの経験が不足していると言ったとき、私は学生に壊れたインフラストラクチャを与え、それを診断して修理することを要求するプロジェクトを作成しました。ほとんどのハンズオンスキルについて、私はハンズオン教育が受動的な指示をはるかに上回ると信じています。インシデントシミュレーションはオンコール準備の一部となるべきですLLMが私たちの仕事の多くを行うようになるにつれて、エンジニアリングチームは理解の負債を蓄積するリスクを負います。これは、システムがどのように機能するかと、対応者がそれをどれだけ理解しているかとの間のギャップが拡大することです。エンジニアは、監視しているシステムと定期的に対話し、慣れない障害に対処し、プレッシャーの下で作業する練習をし、SEV0中に必要な調整とコミュニケーションをリハーサルする必要があります。テーブルトップ演習やカオスエンジニアリングは新しいものではありませんが、LLM時代には実践がさらに重要になっています。研究者のBainbridgeは、オペレーターに定期的なハンズオンコントロールを与え、スキルが低下するのを防ぐためにシミュレーションを使用することを推奨しました。それが自動化の皮肉です。成功すればするほど、人間はそれが失敗した瞬間に備えられなくなる可能性があります。Sylvain KalacheAI Labsリード兼DevRel at Rootly。元LinkedIn SRE、Holberton School共同創設者。関連する記事LLMs Broke the SRE Runbook. Now What?Is AI-assisted coding an incident magnet?Vibe Coding Is Here — But Are You Ready for Incident Vibing?