2012 年に LinkedIn の SRE だったとき、私は自動的に修復し、過去の出来事から学習できるシステムを設計しました。 AI の機能は今日のものには遠く及ばず、プロトタイプのままでしたが、今では現実のものになりました。

これらのツールは、アラートの確認、仮説の策定、テレメトリのクエリ、最近の展開の照合、さらには修正自体の実装など、すべてを実行します。私はそれを見るのが大好きですが、深刻な懸念が 1 つあります。それは、私たちがシステムとのつながりを失いつつあるということです。

これらのツールが日常的なインシデントの処理に優れるほど、人間の対応者の経験は少なくなります。そして、自動化では対応できない不確実で極端なイベントが発生すると、対応エンジニアは困難に直面することになります。

これらの AI インシデント対応ツールは、一般的に「AI SRE」と呼ばれます。 私はこの用語が特に好きではありません – 多くの点で素晴​​らしいです。夜によくある出来事を解決するとき、彼らは特に魔法のように感じます。能力の問題のために起きる必要はありません。

問題は、通常のインシデントは、対応者が「安全な」行動をとっているという感覚やシステムの障害を培う方法でもあるということです。 AI が解決できない困難かつ前例のない出来事に遭遇したとき、エンジニアは以前よりも少ない経験で引き継ぐことを余儀なくされます。

ヒューマンファクター研究者のリザンヌ・ベインブリッジは、1983 年の有名な論文「自動化の皮肉」でこの矛盾について説明しました。同氏は、自動化によりオペレーターが日常業務を実践する機会が減り、新たな異常な状況に対する責任がオペレーターに残ることになると説明した。したがって、オペレーターは自動化前よりも熟練し、より多くのトレーニングを受ける必要がある、と同氏は主張する。

今後数年間で、インシデント対応 AI のおかげで、ほとんどのインシデントの平均 MTTR は低下すると私は予測していますが、インシデント対応担当者がシステムとの接触を失い、調査に苦労するため、複雑なインシデントのインシデント解決時間は増加すると予想しています。

インスピレーションを得るために航空業界に目を向けることができます。

航空機の自動化はほとんどの飛行を行いますが、エンジンの故障、信頼性の低い計器、拒否された飛行、失速、その他の異常な状況など、自動化では対処できない状況についてはパイロットが責任を負います。

このような事件は非常にまれです。たとえば、今日のタービン エンジンが停止するのは、エンジン飛行時間 100,000 時間に 1 回未満です。言い換えれば、民間パイロットがシミュレータ以外の経験をまったく持たずにキャリア全体を完了できることは十分にまれです。

しかし、故障が発生した場合、パイロットは迅速かつ適切に行動しなければなりません。たとえば、 トランスアジア航空 235 便右エンジンの右プロペラが離陸直後に自己放電した。そして、飛行機は左側のエンジンで飛行を続けるように設計されていましたが、乗組員は問題を誤って診断しました。飛行機は動作を停止し、最初の警告からわずか117秒後に墜落した。

航空会社のパイロットは定期的にシミュレーターに戻り、まれな緊急事態に備えて訓練します。米国連邦航空局の規制により、機長は離陸時のエンジン故障などのシナリオを含め、半年ごとに再訓練または熟練度検査を完了する必要がある。

ほとんどのソフトウェア インシデントは生命を脅かすものではありませんが、だからといって技術を向上させない理由にはなりません。問題を引き起こしたテクノロジーが問題の解決にも役立つことが判明しました。

私が働いている Rootly では、Uptime Labs と提携して、リアルタイム イベント シミュレーションを通じてこのアイデアを実装しました。エンジニアは、電子商取引シミュレーションのシャットダウン中に指揮官の座につき、観察ツールを使用しながら、Slack で LLM 関係者と調整します。

結果は本物のように感じられます。 CEOやカスタマーサポートへの対応や対応をきちんと行いながら、何が問題だったのかを確認する必要があります。インシデント発生時に重要となるスキル、つまり不完全な情報の理解、明確なコミュニケーション、人々の調整、行動への対応を活用します。

では、AI をトレーナーとして使用する場合はどうでしょうか?対応者はエージェントに、自分がとった手順、チェックした信号、診断の背後にある根拠の説明を求めることができます。

しかし、説明と観察は実践の代わりにはなりません。セリーナ・ウィリアムズのプレーを見ることでいくつかのことを学ぶことができますが、テニスを学ぶのはコートに立って初めてであり、起こったことに反応することも例外ではありません。

私は 5 年以上のキャリアを費やして、実践による学習という進歩的な教育を中心としたソフトウェア エンジニアリングの学校を設立してきました。それは個人的なことでしたが、私たちには教師がいませんでした。学生たちは講義を聞く代わりにプロジェクトに取り組みました。 Dropbox が採用した卒業生はまだトラブルシューティングの経験が浅いと Dropbox から言われたとき、私は学生に壊れたインフラストラクチャを提供し、診断して修正するよう要求するプロジェクトを作成しました。ほとんどの実践的なスキルについては、受動的なトレーニングよりも実践的なトレーニングの方がはるかに重要であると私は考えています。

LLM が私たちの仕事を担当することが増えるにつれ、エンジニアリング チームは理解の負債を蓄積するリスクがあります。つまり、システムがどの程度うまく機能するか、対応者がどの程度理解しているかの間でギャップが増大するということです。

エンジニアは、監督するシステムと定期的に対話し、未知の障害のトラブルシューティングを行い、プレッシャーの下で作業する練習をし、SEV0 中に必要な調整とコミュニケーションを練習する必要があります。デスクトップ演習や面倒なエンジニアリングは新しいことではありませんが、LLM では演習がより重要になります。

研究者のベインブリッジ氏は、オペレーターのスキルの低下を防ぐために、オペレーターに定期的な実践的な監督とシミュレーションの使用を提供することを推奨しました。これは自動化の皮肉であり、自動化が成功すればするほど、人々は自動化が失敗することに対する備えが強くなります。