AIがインシデント対応を担うほど、エンジニアはシステムを見失う

著者はしっかりした考えを持っているが、SREのためにインシデントシミュレーションに時間を費やす会社は、ほとんどないだろう。

なぜか？AI以前から、バックアップの復元やディザスタリカバリの訓練、あまり使われないランブックの練習、ダウンタイムなしでシークレットを簡単にローテーションできるかどうかの確認、システムを別のベンダーのクラウドやプラットフォームに再デプロイしてみることなどを練習する会社はほとんどなかったからだ。これは存在する運用業務の中で最も地味なものだ。経営陣は誰も気にしない。運用組織は他のみんなと同じように派手な仕事を推進する。新しいプロジェクトのための新しいインフラ、かっこいいチャットボット、新しい派手なダッシュボード、チャートを右上がりにすることなどだ。

航空会社のパイロットが災害シミュレーション訓練を受けるのは、政府がその訓練を義務付けているからだ。パイロット免許の保持条件でなければ、企業はその費用を負担しないだろう。

SREに災害時の訓練に時間を費やしてほしいか？一歩下がって考えよう。専門職の資格制度を支援し、免許保持の条件にすることだ。専門職としての仕事を確立しない限り、業界全体の専門的行動は得られない。免許なしでは実現しない。なぜなら、消費者にすぐに見えないあらゆるコスト削減は追加の利益につながり、競争の激化は最終的に、競争に追いつき生き残るためにそうしたコスト削減を要求するからだ。

AIの使用は流砂のようなものだと思う。

使えば使うほど、同じシステムの変更や修正をAIに頼らざるを得なくなる。結局、虚しさだけが残り、「私が」構築したり修正したりしたシステムに対する直感的な理解が得られない。

コードレビューは重要だが、AIなしでソフトウェア開発のすべてのステップを手動で行うときに構築できるメンタルモデルの代わりにはならない。

コードが自律的に書かれれば書かれるほど、人間の所有者はそのコードに対する直感を失う。直感の喪失は、時間とともに成長する技術的負債の種だ。長い時間軸で見れば、自分のコードベースを見ることが、初日の仕事のように感じられるようになる（時には自分が始めた会社で）。

幸いなことに、これを軽減し、コードベースが「あるべき」姿についての人間の直感を、エージェントのためのガードレールに変換する方法がある。しかし、それがなければ、それぞれの波が前の波とはまったく似ていない確率的な海に帆を張っているようなものだ。

航空業界の意見が時々持ち出されるのを見る。航空では失敗は壊滅的であり、操作するシステムは飛行中に変わらない（しゃれだ）。

おそらくSREをそのように訓練することはできるが、彼らに教えているのは効率的に「反応」する方法だけであって、これらの障害のユニークな根本原因を「修正」する方法ではない。航空の例えで言えば、飛行中のエンジン故障とエンジンのデバッグ/再設計の両方を同時に訓練しようとする航空エンジニアのようなものだ。

ソフトウェアエンジニアリングではそれはこれまで意味をなさなかったし、これからも意味をなさないだろう。訓練に費やす1分は、将来のインシデントの可能性を減らすためにコードベースを作り直すことに費やすほうがよい。この投稿は非常にSRE中心だ。

つまり、AIにインシデント解決を任せてお金を払い、その後エンジニアに合成インシデント解決のトレーニングを受けるためにお金と時間を払うということか。

パイロットとの比較は少し的外れだ。なぜなら、ドメインは会社や製品ごとに大きく異なるからだ。すべてのドメインで合成シミュレーションを考案するのは、同じことにお金を二重に払うようなものだ。そもそもエンジニアに実際のインシデントを最初から処理させればいいではないか。実際、より良いシステムを構築することにもっと考えを巡らせてはどうか。

コードも同様だ。

私はプログラマーと働いているが、彼らが過去に書いたコードを驚くべき詳細さで覚えていることは珍しくない。

誰かが発生した問題に言及すると、彼らはしばらく虚空を見つめ、実際にその問題がコードのどこから来ているかを思い出す。なぜなら、約8か月前にそれを書いたことを覚えているからだ。

このスキルは、AIがすべてのコードを生成するようになると失われるだろう。私たちは、AIがコードを拡張・維持するためにコードの状態を追跡し続けるという永久ループに陥るだろう。

私はこの変種を見たことがある。ランダムなエンジニアが本番インシデントの電話会議に引きずり出され、エンジニアがシステムに精通していることを期待されないというものだ。

彼らは「ただAIを使って」コンポーネントを理解し、問題をトリアージし、修正を構築するように求められた。エンジニアは、AIが提案した潜在的に平凡な修正を受け入れるか、AIを活用する方法を知らない無能なリソースとして見られるリスクを冒すかの選択を迫られた。

エンジニアが何を選んだかは想像がつくだろう。修正は悪くなかったが、いくつかのエッジケースには最適ではなかった。後で修正しなければならなかった。このような状況が十分にあれば、エンジニアは最終的にシステムを詳細に理解することを確実に諦めるだろう。

能力の向上がこのまま続くなら、AIが解決できないインシデントは、どんな訓練をしても人間には手に負えないだろう。

記事の飛行機の例は好きだが、実際にはコードと同じようになると思う。1.5年前、エンジニアはスキルを磨くためにここかしこで手書きのコードをまだ書いていると日常的に言っていたが、今ではそんな話はほとんど聞かない。

SREがAIが解決できない状況に直面した場合、そのSREはAIシステムを使ってさらにトリアージし、別の場所を指し示すなどするだろう。

これはAI以前の経験と直感を持つSREには有効だが、AI以後に入社した新人にはあまり有効ではないかもしれない。これに対する解決策が何かはわからない。訓練ドリルかもしれないが、この分野全体が他の多くの工学分野と同様に取り込まれるだろうという予感がある。

味覚と判断力の必要性には限りがあり、やがてそれもモデルに組み込まれてしまう。

興味深い力学もある。たとえエンジニアがAIの出力を読み、問題の根本原因とインシデントの診断方法を理解しても、どういうわけか学習を内面化して次の新しいインシデントに適用することが難しい。その結果、エンジニアは結局システムとのつながりを失う。

どうやら私たちの脳は、診断中に失敗を経験し、一般的にこの種の経路探索を自分自身で行うことで初めてシステムを真に理解する必要があるようだ。これが私たちの脳の実際の学習方法と関係があるかどうかはわからない。