生成AIで日々のエラー調査を進めたい

Transcript

1. エラー調査を生成 AIで進めたい aboy ゆるSRE勉強会 #11 〜AI × SREの知見が聞きたい！〜： 15分用資料
2. 前段
3. 自己紹介 3 - aboy (あぼ) - コネヒト株式会社
4. 運用体制 4 - 2012年創立。歴史あるサービス (システム)らの開発・運用。 - Webエンジニア 9名、インフラエンジニア 1名、（ほか割愛🙏）。 - SRE専門部隊はいない。開発と運用は分かれていない。 - 特にアプリケーションの監視は Webエンジニアが行う。 - ↓継続中 https://speakerdeck.com/yuyaabo/minnateerajian-shi-surusrexi-hui-noxiao-guo-yurusremian-qiang-hui-1
5. アプリケーションエラー監視の現状と課題 5 - 現在の運用 - 異常系エラー：プロジェクトごとのルールで新規、再発、頻発で Slackに通知。 - 要即対応 - 準正常系エラー：エラーごとのルールで定量監視（例 : 10回/1h）でSlackに通知。 - 要即対応 - そのSlackチャンネルを見てエラー対応 → GitHub Issueに記録 → 共有。 - 現在の課題 - 通知への反応・調査はできているが、解決の進みが遅い（オオカミ少年化していないが実 質ノイジーなものも多い）。
6. アプリケーションエラー監視の現状と課題 6 - 事業フェーズ的に日々の機能開発が優先。 - 逆に言うと緊急性がすごく高いエラーはつど解決している。 - であるならばそれ以外のエラーアラートは、エラーの原因を修正したり監視の仕方を変えたりして 抑えることができれば、機能開発により集中できる。 - そんな中で生成AIがものすごい勢いだし便利そうだ。 - 使わないと使えるようにならない。理解が進まない。
7. 生成AIの活用例
8. 8 生成AIの活用例 前述の目線を持った Webエンジニアから、生成 AIの活用事例を3つ共有。 ※特に社内に導入されている Devin という自律型AIエージェントを使った事例 - パフォーマンスチューニング補助 - 新規エンドポイントのレイテンシ予測 - エラー調査・解決の自動化
9. 9 パフォーマンスチューニング補助 「xxx エンドポイントのレイテンシが悪い原因を調査してください。 APMにより下記SQLのパフォーマンス が悪いことが分かっています。」と Devin に指示。 - 周辺コードや類似処理をもとに原因と解決策を複数提案してくれる。
10. 10 パフォーマンスチューニング補助
11. 11 パフォーマンスチューニング補助 - ある程度触っているシステムでも知らないことがある（他チームも触る）。一般的なこともドメス ティックなことも気づきを得られ有用。 - 実際、この例では Devin が類似エンドポイントとの実装差分から提案した解決策を採用 → ボトルネック移動 → Devin と Gemini を活用して SQL 改善 ↓結果↓
12. 12 新規エンドポイントのレイテンシ予測 Datadog API から既存エンドポイントのレイテンシを取得してリスト化したもの + 新設するエンドポイン トの仕様を Devin に渡して「p95レイテンシを推測してください」と指示。 - 類似エンドポイントがあればそのレイテンシをもとに推測するなど、根拠を示しそれっぽい答えを 出す。 - DBのレコード数に左右されるような仕様や既存処理の組み合わせではないものは振れ幅 が大きくなる。 - この段階で自社基準を大幅に超えるようなら仕様や実装に工夫が必要かもなーとなるので良い 壁打ち相手に。
13. 13 新規エンドポイントのレイテンシ予測
14. 14 エラー調査・解決の自動化 Sentry bot が GitHub Issue を作成したときと、 GitHub Issue に `devin-sre` ラベルを付けたときに GitHub Actions 経由で Devin に調査・解決指示。
15. 15 エラー調査・解決の自動化 「Devin に依頼 → Slack 通知」を切り出して各リポジトリから利用。
16. 16 エラー調査・解決の自動化 「よくやる作業で対応方法も 3パターンくらいでだいたい決まってる」みたいな類のものについては手順 の文書化。 - 調査は済んでいて対応方法も分かっているイシューの対応をラクにする意図。 - Devin では Playbooks というプロンプトを流用できる機能を活用。 - しかし、特定のAIツールに限定しない情報についてはリポジトリ内に置き、どの AIツールか らも参照できるようにしたほうが良さそう。 - 弊社ではエンジニア全員 GitHub Copilot を使っているのでカスタムインストラクションか？ → 最近 Cursor のトライアルも始まったので分からないがとにかくリポジトリに置く。 - 最初は自分で書いていたが、この類のものは参考となる PullRequest があるので、それを材料 にAIツールに文書化させる方向へ。 - 人間が書くには大変な質の文書を書いてくれるのと、今後どうせ AIに更新させていくため。
17. まとめと感想
18. 18 まとめと感想 - Webエンジニア視点で、日々の運用における生成 AIの活用事例を3つ紹介。 - パフォーマンス改善、レイテンシ予測、エラー調査・解決の自動化。 - トイル削減のためのコード化は生成 AIで進めやすくなった。 - 前述した GitHub Actions も Devin が実装。 - AIツールが調査・開発しやすくするための環境整備も生成 AIで進めやすくなった(というか必須に なった)。 - APMなどの運用におけるデータを AIツールにいかに渡すか。 - 紹介したエラー調査・解決自動化の例では、 Devin と Sentry は直接繋いでない (Issueを情報源にしている )ため、より細かい1次情報にアクセスできるようにする改 善の余地あり。 - 進めるぞい