「あの人に聞かないと分からない」が、開発ライフサイクル全体を止めていた
周氏はDMM.com ITインフラ本部SRE部に所属するSREで、後述するAIエージェント「DMM DevOps Copilot」の開発・運用を担当している。題材のDMMブックスは電子書籍を販売するサービスで、本番環境はAurora MySQL、ECS Fargate、CloudFront、ALB、ElastiCacheといった多数のAWSリソースで構成され、大量のJenkinsのバッチが動く。オブザーバビリティにはNew Relicを使っている。
この規模のサービスを運用していると、何か問題が起きた際に、判断に必要な情報があちこちに散らばる。周氏が挙げたのは「あるAPIのレスポンスが遅くなった」という、どの開発現場にもありそうな例だ。New RelicのAPM（アプリケーションパフォーマンス監視）でトランザクションの内訳を見る。Jenkinsで重いジョブが走っていないかを確認する。オンプレの基盤やDMM全体の共通基盤に障害が出ていないかを当たる。ソースコードを読んで処理のフローを理解し、最後にGitの変更履歴を追って原因になり得るリリースを確認する。確認すべき先は6か所に及ぶ。
「これら一つひとつは特に難しくはないです。ただし、横断的にすべてを確認して、整理して因果関係を明らかにするためには、それなりの時間と経験が必要になります」（周氏）
そしてこの「時間と経験」は、そのまま属人性に転化する。
「結果として何が起きたかというと、あの人に聞かないと分からない、その人でないと分からないという問題が時々出てきます」
特定の開発者やSREへの確認待ちが、開発ライフサイクル全体のボトルネックになっていた。押さえておきたいのは、これが監視ツールの不足を嘆く話ではない点だ。New Relicは導入済みで、データもある。それでも滞るのは、散らばったデータを因果関係の形に組み上げる作業が人の経験に依存していたからである。
AIに判断を任せない──「伴走者」というエージェントの置き方
そこでDMM.comが目指したのは、ツールの追加ではなく、コミュニケーションそのものの流れの変化だった。従来は「人に聞く→人が調べる→回答を待つ」。これを「エージェントに聞く→エージェントが横断的に調べる→人がその回答根拠を見て判断する」に置き換える。
ここで効いてくるのが、周氏がセッションの冒頭に置いた「伴走者」の定義である。
「AIに判断を任せるというわけではなく、開発者あるいはSREがより良い判断をするための材料を一緒に揃えてくれる存在、そういう意味で使っていきます」
エージェントは最終的な判断者ではない。開発者が質問を投げると、エージェントが複数のデータソースを横断的に確認し、根拠付きで回答する。開発者はその根拠を見て自分で判断する。判断が難しければ、根拠を持った状態でSREや他のチームに相談しに行く。
「この根拠を持った状態で相談するというのがかなり重要でして、ゼロから直接調べてもらう場合とは全然違います。議論の質も上がりますし、SRE側の対応も圧倒的に速くなっていきます」
縮めようとしているのは、調査そのものの所要時間だけではない。相談が成立するまでの距離である。
