DevOpsにおいて、コード変更の速度が人のレビューについていけなくなった場合、AIOpsはどのような問題を解決するのか？
これが適切な出発点だ。なぜなら、現代のデリバリーパイプラインは、小さく目立たない形で失敗することがあるからである。新しいライブラリのバージョン、不適切な設定ファイル、脆弱な依存関係などが、通常のチェックを通り抜け、後にビルドの遅延、リリースの破綻、あるいはセキュリティホールとして表面化することがある。
AIOpsは、このフローに機械学習を持ち込む。パイプラインが既に生成する兆候を観察し、過去のパターンと比較して、問題が拡大する前に不審な点を警告する。
なぜDevOpsにはより賢明な監視が必要なのか
DevOpsチームはすでにテスト、ログ、アラート、デプロイスクリプトを使用している。問題は「量」にある。サービスが増え、コードパスが増え、変更が増え、シグナルも増えているため、人間が手で十分に検査できる数を遥かに超えている。
そこへAIOpsが適応する。それはパイプラインを置き換えるものではない。パイプラインを大規模に読み取り、ノイズだらけのダッシュボードでは見つけにくいパターンを探すのである。
AIOpsは、基本的な自動化が見逃しがちな、欠落したコード、奇妙なコード、脆弱な依存関係、不良な設定、その他の欠陥を検出できる。また、リスクを高める書き方で行われた不要なコードにも注目を促すことができる。
その価値は検知の速さである。問題が早期に見つかるほど、それが本番システム、ログ、顧客、またはセキュリティコントロールに影響を与える時間が少なくて済む。
パターンがどのように機能するか
ツール自体は複雑であっても、パターンの形状は単純である。
コードはソースリポジトリに存在する。ビルドとテストはCI/CDパイプラインを通じて実行される。ログやイベントはその過程で収集される。AIOpsツールはそのストリームを研究し、正常な状態がどのようなものであるかを学習する。
その後、それらは新しい変更と古い挙動を比較する。コミットによってコード構造、ランタイム動作、またはデプロイメントパターンが不審な方法で変更された場合、システムは警告を発したりアクションをトリガーしたりすることができる。
そのため、データがこれほど重要なのである。AIOpsは有用な履歴に依存する。ソースコード、パイプラインイベント、テスト出力、デプロイメントログ、および過去のインシデントから学習する。そのようなデータがなければ、比較対象となるものがほとんどない。
このパターンのエンタープライズ版には、制御も必要である。チームはリポジトリへのアクセス、モデルトレーニング用のデータレイヤー、そして適切な段階でAIチェックを呼び出せるパイプラインへのアクセスを必要とする。目標は巧妙なサイドツールを作ることではない。目標は、AIを通常のフローの一部として使用するパイプラインを作ることである。
小さな例
新しい決済サービスを追加し、コンテナイメージを更新するリリースを考えてみよう。コードはレビューでは問題なく見え、ユニットテストも通過する。しかし、新しいサービスは予期せぬ依存関係を使用しており、1つの設定値がコンテナの起動方法を changing している。
AIOpsは、いくつかの方法でこの不一致を特定できる。依存関係のギャップに気づくかもしれない。起動動作が既知のパターンと一致しなくなったことを観察するかもしれない。過去に類似したコードがテストやステージング環境で失敗を引き起こしたため、この変更を警告するかもしれない。
その警告は、リリースが本番環境に到達する前にチームが注目すべき場所を提供する。修正は、欠落したパッケージの復元や設定ファイルの修正のように小さいものでよい。重要な点は、変更がまだ修正コストが低い間に問題が早期に現れることである。
安全な修正には同じパイプライン規律が必要
AIOpsはしばしば運用ツールとして議論されるが、セキュリティは同じ物語の一部である。脆弱なライブラリ、危険なコードパターン、または不良なデプロイメント設定は、すぐにセキュリティ問題へと発展し得る。
一部のツールはコードレビューに焦点を当てる。他はランタイム動作を見る。一部はログとメトリクスを通じてインフラストラクチャの健全性を監視するために構築されている。これらを組み合わせることで、チームは欠陥と曝露の両方を捕捉するのに役立つ。
実務的には、これはパイプラインがリスクのためのフィルターになることを意味する。レビューステップは安全でないコードパターンを警告できる。ランタイムステップは非効率性や異常な動作を捕捉できる。インフラストラクチャステップは、表面上は健全に見えるが、間違った方向に進んでいるシステムにおける異常を検出できる。
これは頻繁に変更を行うチームにとっての実用的な利益である。高速なリリースサイクルでは、事後の遅い人間による検査の余地はほとんど残されない。
エンタープライズデリバリーにおいてAIOpsが変化させるもの
AIOpsは、スタックの他の部分がそれに備えている場合に最も効果を発揮する。クラウドネイティブシステムは、コンテナとKubernetesがアプリケーションフローの他の部分と一緒にモデルをテスト、パッケージ化、デプロイすることを容易にするため、これを助ける。
これはまた、チームがデータをどう捉えるかを変化させる。ログ、テスト、デプロイメント記録は単なるお飾りではなくなる。それらはトレーニング資料となり、運用上の証拠となる。データがサイロ間で分割されていたり、分類が不適切だったりすると、モデルが学習できる内容や信頼できる内容が減ってしまう。
そのため、エンタープライズでの準備状況が重要なのである。データチーム、DevOpsエンジニア、アプリケーション所有者全員が役割を持っている。あるグループはシグナルの所在を知っている。別のグループはパイプラインの動作を知っている。別のグループは実際の失敗がどのようなものであるかを知っている。
ビジネスのサービス側も変化する。インシデント管理および変更管理チームは、なぜアラートが発生したのか、そしてどのような自動レスポンスが許可されているのかを理解する必要がある。ここで安心感の錯覚は危険である。要点は、モデルに対する盲目的な信頼ではなく、より良い可視性と迅速なレビューである。
実用的な教訓
AIOpsは、別レイヤーではなくDevOpsシステムの一部分として扱われるときに、最大の成果を上げる。それはリポジトリデータ、パイプラインイベント、ログ、および過去のインシデントから学習する。それは欠落したコード、不良な設定、脆弱な依存関係、および異常な動作をチェックする。その後、チームが検知から修正へより早く移行できるように支援できる。
EuroOp LLCは、これを明確なビジネス形状を持つ1つの適用されたR&Dパターンと見なしている：仕事がすでに行われている場所でパイプラインをより賢くすること。これが、EuroOpの製品背後にあるパイプラインからの1つの実用的な示唆を反映するように構築された、EuroOp Insightsが体現するエンジニアリング規律の種類である。