Amit Shingala, 共同創設者兼CEO、モタデータ Amit Shingala 共同創設者兼CEO、モタデータ

ITオペレーションは自分自身のブレーキを自動化してしまっている

現在、ITの2つの分野が同じ葬儀を発表しており、どちらも他方の存在に気付いていない。可観測性の分野では、人間の読者は終わりであると主張されている。過去1年間で繰り返し述べられてきた議論は、可観測性の歴史全体が、膨大な量のテレメトリーデータを人間が一目で把握できるものに圧縮するための努力であったというものであり、AIはその圧縮の必要性を除去するというものである。コメンテーターは現在、可観測性は人間のために構築されたものであり、AIエージェントは別のものが必要であると主張している。Corey Quinnは、O11yConという可観測性に特化したカンファレンスで、テレメトリーデータの主な読者は今や椅子に座っていないと述べた。サービスマネジメントの分野では、チケットは終わりであると主張されている。2026年の業界予測によると、チケットレスオペレーションはチケット自動化を上回り、区別ははっきりとされている。チケット自動化は人間の労力を削減するが、チケットレスオペレーションはそれを完全に除去することを目的としている。サービスデスクベンダーは、問題が検出、診断、修正される前に誰もがインシデントを報告する前にサービスデスクを構築することを約束している。両方の分野は、自分たちが殺すものについては正しい。しかし、どちらも気付いていないのは、自分たちが同じ構造の反対側の半分を解体していることであり、一部のものは重量を支えていたということである。2つの分野、1つの制約可観測性が実際に構成されているものを考えてみよう。サンプリングは、誰もがすべてのトレースを読むことができないため存在する。集約は、誰もがすべてのメトリクスを読むことができないため存在する。ダッシュボードは、システムを一目で把握するために必要である。アラートしきい値は、連続した状態のストリームを二値信号に変換するため存在し、人間は必要なときのみ中断される。これらすべては圧縮メカニズムである。可観測性は、構造的には、情報を1人が頭に保持できるものに制限する練習である。サービスマネジメントについて考えてみよう。重大度レベルは、誰にまず注意を向けるかを決定するために存在する。キューは、誰もがまだ自由でない作業を保持するために存在する。エスカレーション階層は、専門知識が希少で高価であるため存在する。変更諮問委員会は、すべてをレビューすることができないため存在する。サービスレベル合意は、基本的に、限られた数の人々がどのくらいの速さで対応するかについての約束である。これらすべては割り当てメカニズムである。ITサービスマネジメントは、構造的には、人間の注意を必要以上の要求にわたすための練習である。したがって、2つの分野は同じ制約を解決しようとしているが、反対側からアプローチしている。可観測性は、人間に入ってくる情報を制限する。サービスマネジメントは、人間から出てくる注意を制限する。中間にいる人間が、両方の分野に形を与えている。どちらの分野も、自分たちが何を犠牲にしてきたかを認識していない。それが、どちらも自分たちが何を手放そうとしているかを見逃している理由である。業界は制約がなくなったと判断している人間を中から除去するための議論は、批判者が認めるよりも強いものであるし、公平に述べたい。サンプリングは実際に妥協である。機械が使用できるデータを捨てて、人間が耐えられる量を生み出すための妥協である。機械はダッシュボードを必要としない。システムのより多くの部分をワーキングメモリに保持できるし、3時に疲れることもない。パスワードのリセットはキューを必要としない。APIコールが必要である。サービスデスクのほとんどのボリュームが、ルーチンワークのリクエストタイプで構成されている場合、サービスデスクをルーティングしてトライアージュするためのモニュメントは、もう必要ない問題への解決策である。これらすべては真実であり、ほとんどが遅れていた。しかし、業界が行っている動きは、制約が人間の遅さによって形作られた両方の分野で、すべての遅さが人間の遅さのためであると結論付けたものである。それは論理的に導かれない。制約がすべての設計決定に影響を与えた分野で、制約を除去した場合、すべての設計決定が制約のみのためであったと仮定することはできない。いくつかの決定は別のものについてであったが、遅さは偶発的なものであった。すべての遅さがボトルネックではなかったこれらの分野の中には、ボトルネックであるものがある。人間の遅さのためだけに存在し、遅さ以外の何も生み出さず、除去されるべきものである。サンプリングはボトルネックである。3つのツールを2時に手動で相関させることはボトルネックである。インシデントの手動分類はボトルネックである。ルーティングはボトルネックである。最初のトライアージュはボトルネックである。これらのステップは何も生み出さない。税金である。しかし、これらの分野の中には、ブレーキであるものもある。ブレーキはまったく別のものである。重大度分類は遅さではない。強制関数である。重大度分類は、ビジネスへの影響について、名前のある人物が公に述べることを強制する。出力はラベルではない。出力はコミットメントである。変更諮問委員会は、人が遅いから遅いわけではない。慎重な検討が必要だから遅い。ミーティングは決定に付随するものではない。ミーティングは決定そのものである。事後分析は故意に遅い。反省は待ち時間ではない。4秒で失敗から学んだ組織は、実際には何も学んでいない。これらはブレーキである。故意に摩擦を生み出すために存在する。速さが必要な時ではない、正確に摩擦を生み出すために存在する。外から見ると、ブレーキとボトルネックは区別がつかない。プロセス図では同じように見え、調査では同じ不満を生み出す。両方とも、起こり得た時と起こった時との間のギャップとして現れる。両方とも待ち時間のように見える。ブレーキを除去することの実際のコストここで議論は、好みの問題を超えて、証拠の問題になる。GoogleのDORAリサーチは、AIの採用が増えるにつれて、ソフトウェアデリバリーに何が起こるかを2年間測定してきた。2024年の調査結果は、AIの採用の増加とデリバリーの安定性の低下との間に約7パーセントの相関関係があることを示した。翌年、スループットの絵は改善されたが、安定性との負の関係は続いた。Google自身のまとめは、AIが開発を加速し、その加速が下流の弱点を露呈するというものであった。明らかな反論は、速さが被害を補償するというものである。速く出荷し、多く壊し、速く修正し、先に立つ。DORAはそれをテストした。研究者は、AIのスループットの利点が不安定性の被害を相殺するかどうかを確認し、データはその仮説を支持しなかった。不安定性は速さによって補償されなかった。単にどこか別の場所で吸収された。現在、エージェント市場で最も鋭い予測を見てみよう。2025年6月、ガートナーは、2027年末までに、エージェントAIプロジェクトの40パーセント以上がキャンセルされるだろうと予測した。数字はどこでも引用されており、通常は日付なしで、テクノロジーに対する判決として引用される。数字は面白い部分ではない。原因が面白い。ガートナーは3つの原因を挙げている。コストの増加、ビジネス価値の不明確さ、リスク管理の不十分さ。モデル能力はリストにない。不足しているモデルの機能で修正できる失敗モードはない。それを運用の診断として読み解くと、はるかに鋭くなる。ガートナーは、AIが十分でなかった組織について述べていない。ブレーキを外した組織について述べている。誰も実行していない整理作業議論が成立する場合、次の数年のITオペレーションの仕事は、速さではない。整理である。両方の分野のすべての遅いステップを取り出して、1つの質問をする。人間が遅いから遅いのか、判断が時間を必要とするから遅いのか。最初のカテゴリは、感情を抱かずに自動化されるべきである。誰もが手動のチケット分類を擁護するべきではない。誰もがサンプリングを擁護するべきではない。サンプリングの経済的必要性がなくなった場合。这些ステップは神聖なものではない。常に希少性の税金であり、希少性は解消されている。2番目のカテゴリは、除去よりも慎重なアプローチが必要である。目的は、ループ内に人間を保持することではなく、人間に求めるものを変更することである。作業を実行するよう人間に求めるのをやめよう。代わりに、記録上で決定するよう求めよう。「変更をレビューする」のではなく、「爆発半径が何であると思っているか」を尋ねよう。「インシデントをトライアージュする」のではなく、「重大度の呼び出しに名前を付ける」ことを尋ねよう。機械は調査を実行し、証拠を集め、行動を提案し、実行することができる。機械ができないのは、行動に責任を負うことであり、責任は、遅いものの速いバージョンではない。別のものである。チケットはブレーキだったそれで、私は葬儀に戻る。業界はチケットが死にゆくことを決めた。私は、実際にはその逆が近いと考えている。チケットの周囲にあるすべてのもの、つまりボトルネックを取り除こう。ルーティング、分類、キュー、階層、手動トライアージュ、待ち時間を取り除こう。すべてが、遅い人間の周りに構築された足場であり、すべて除去できる。残っているのは、チケットの1つの不可欠な機能である。名前のある人物が結果に対する責任を負うことを記録したアーティファクトである。ワークフローのステップではない。決定の記録であり、機械が速くなるにつれて速くならない唯一のものである。サービスデスクは自動化される。ダッシュボードはオプションになる。キューは消える。そして、誰もが速く埋葬しようとしたものが、実際には速度について全く心配していなかった唯一のコンポーネントであることがわかる。したがって、私が運用を改善しようとしているチームに質問するのは、単純なものである。遅いステップの種類を知っているかどうかである。