シャリニ・スダルサン氏は、Kindercare Learning Companies社のDevOpsエンジニアリングマネージャーとして、AIの導入を中核的なビジネス戦略として推進している。
長年にわたり、DevOpsは配信速度、自動化、フィードバックループを改善してきたが、それらは機能しなくなるまでは効果的だった。スタックがマイクロサービスやマルチクラウド環境へと拡大するにつれ、アラートの流れは制御不能なほど増大した。追加のダッシュボードやより厳格なしきい値によってチームはより迅速に対応できるようになったが、繰り返し発生する問題を止めたり、全体的なノイズを減らしたりすることはできなかった。解決策は「より多くのツール」ではなく、プレイブックの更新だった。
その更新は、クリーンなデータ、一貫したタグ付け、信頼性の高いテレメトリー、明確な所有権、実質的なSLOという基本から始まる。基盤が整ったら、AIOpsをその得意分野に適用する。
これは「AIが運用を救う」というものではない。DevOpsのスピードからAIOpsのインテリジェンスへと、信頼を損なったり予算をオーバーしたりすることなく移行することだ。機能するもの（CI/CDの規律、非難のない学習）は維持し、機能しないもの（重複アラートの手動トリアージ）は削減する。欠けているもの（SLOとビジネス成果に紐づいたクローズドループ自動化）を追加する。
消火活動で限界に達し、先見性に欠けている場合、これはデータを意思決定に変え、運用を競争力に変える実用的な道筋だ。アナリストの勢いもこの変化を支持している：ガートナーによると、「2026年までに、企業の30%がネットワーク活動の半分以上を自動化するだろう」。
DevOpsの基盤—そして限界点
DevOpsは開発者と運用担当者を結びつけ、自動化を標準とし、長いリリースを安定した信頼性の高い更新に変えた。しかし、規模が拡大するにつれてゲームのルールが変わった。単一の製品が、地域、サーバーレス機能、データパイプライン、サードパーティAPIにわたって数千のサービスを実行し、すべてが同時に変化する。各層はログ、メトリクス、トレース、チケットを生成し、毎分数百万の信号を発する。静的なダッシュボードではこれらすべてのドットをつなぐことができない。
結果に表れている：MTTRは停滞する。チームはアラートからアラートへと飛び回り、ブリッジコールを組織し、顧客が影響を感じた後でようやく何が起きたかを知る。良いランブックでさえ、障害が一つの明白な根本原因ではなく、多くの動く部品間の相互作用から生じる場合には苦戦する。DevOpsはスピードと一貫性をもたらしたが、今日の信号の複雑さを予測していなかった。対応型から予測型へ移行するには、自動化とインテリジェンスを組み合わせる必要がある。
AIOpsの定義
AIOpsは機械学習と分析を運用データに適用することで、チームが問題をより早く発見し、原因をより速く特定し、問題を自動的に修正（または防止）できるようにする。簡単に言えば：信号を取り込み、関連するものを相関付け、異常なパターンを特定し、トラブルを予測し、安全なアクションをトリガーする。これはガートナーのAIOpsの定義に沿っており、GoogleのSREワークブックからのSLO駆動型プラクティスと互換性がある。
5つのステップのフローを考えてみよう：
1. ログ、メトリクス、トレース、デプロイマーカー、チケットを取り込む。
2. 信号を相関付けて、多くのアラートが文脈を持つ1つのインシデントに集約されるようにする。
3. 脆弱なしきい値ではなく、学習したパターンに基づいて異常を検出する。
4. 顧客からの苦情が来る前に、容量とレイテンシの問題を予測する。
5. 再起動、キャッシュのクリア、カナリアのロールバックなどの低リスクの修正を、監査証跡とポリシーを伴って自動化する。
AIOpsはエンジニアを強化するものであり、彼らに取って代わるものではない。重大な影響範囲を持つアクションについては、人間による監視を維持する。
ビジネスへの影響：対応型から予測型へ
相関関係が確立されると、チームは複数の別々のインシデントではなく、単一の明確なインシデントを認識できるようになる。アラートの量は劇的に減少することが多く、検出時間が短縮され、オンコール体制への信頼が回復する。異常検出は問題を早期に警告し、予測は容量を平準化する。つまり、障害が少なく、回復が速く、製品改善により多くの時間を割けるようになる。
コスト面でも効果がある。プラットフォームが需要を理解すると、リソースを適正化し、アイドル状態のコンピュートをシャットダウンするために表面化させることができる。スパイク時にはパフォーマンスを維持し、低迷時には請求額が減少する。財務部門はより明確なユニットエコノミクスを得られ、エンジニアリングは無駄なく必要なヘッドルームを維持できる。
ユースケースは明確だ。小売業では、大きな日にトラフィックが急増する。AIOpsは予防的にスケールし、依存関係が遅くなったときに重要でない作業を削減し、悪いカナリアが広がる前にロールバックする。ダウンタイムが許容できないヘルスケアでは、AIOpsがエンドツーエンドを監視し、データドリフトを検出し、更新がシステムをリスクにさらさないようにガードレールを強制する。
AIOpsの実装：シンプルなロードマップ
統合された可観測性から始める。ログ、メトリクス、トレースを1つのプラットフォームに配置し、サービスカタログを整合させ、SLOを設定する。見えないものを自動化することはできない。
相関関係と異常検出を追加する。依存関係をマッピングし、重複するアラートを集約し、正常な状態を定義する。ノイズを削減することで文化が変わる。
実際のインシデントで訓練する。過去の障害、季節性、デプロイマーカーをシステムに供給し、可能性の高い原因を提案し、新たなパターンを警告できるようにする。信頼を構築するために、人間によるレビューを含めて始める。
ガードレールを備えた低リスクの修正を自動化する。サービスを再起動し、キャッシュをクリアし、階層をスケールするか、ポリシー、監査可能性、簡単なロールバックを備えた焦点を絞ったチケットを開く。高影響のアクションには人間の承認を残す。
ループを閉じる。繰り返し発生する障害のシグネチャをテストに取り込み、CI/CDにプレフライトチェックを追加し、予測を使用してリリースを計画する。時間の経過とともに、システムは既知の問題に対して自己修復し、未知の問題をより早く発見するようになる。自動化されたアクションのガバナンスについては、NIST AI リスク管理フレームワークが堅実なベンダー中立のリファレンスである。
文化の変化
難しい部分はマインドセットだ。信頼性を顧客と目標を持つ製品のように扱う。SLOを定期的にレビューし、エラーバジェットに基づいて決定を下す。SRE、プラットフォーム、データ、製品チームをサービスの一元的な見方とインシデント分類法に合わせる。
メトリクスを「稼働時間」を超えて、顧客が感じるタスクの成功、P95/P99レイテンシ、安全なリリース頻度に更新する。スキルと透明性に投資し、自動化されたアクションを説明可能で監査可能にし、設計を変更する報告書を称え、作業の削減を報いる。
将来を見据えて：AIOps、MLOps、FinOpsの収束
MLが日常的な製品の一部になるにつれ、AIOpsとMLOpsは実践的に出会うだろう。障害が発生しているサービスを検出するのと同じインテリジェンスが、データドリフト、機能の障害、歪み、推論の遅さについてモデルの健全性も監視し、安全な是正措置を講じる。
FinOpsは信頼性と同じビューに位置し、リーダーはSLOとユニットエコノミクスを比較検討し、最も安価で安全な場所に容量を配置できる。目的地は自律的な運用センターであり、人間がルールを設定し、システムが日常的なタスクを処理する。
最後に
AIOpsはエンジニアに取って代わるものではなく、チームに超能力を与えるものだ。小さく始め、信号を統一し、明確なSLOを設定し、ノイズを削減し、最も安全な修正をガードレール付きで自動化する。スキル、透明性、測定されたガバナンスにより、運用はより落ち着き、より速く、より信頼性が高くなる。
