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