Upgrade to Pro — share decks privately, control downloads, hide ads and more …

SREが投資するAIOps ~ペアーズにおけるLLM for Developerへの取り組み~

ogady
November 21, 2024

SREが投資するAIOps ~ペアーズにおけるLLM for Developerへの取り組み~

2024/11/21 JAWS-UG SRE支部 #10 SREでもAI活用がしたい
https://jawsug-sre.connpass.com/event/334942/

参考資料
- AIOps とは何ですか?(https://aws.amazon.com/jp/what-is/aiops/)
- tmokmss/bedrock-pr-reviewer(https://github.com/tmokmss/bedrock-pr-reviewer)
- ペアーズにおけるAmazon Bedrockを⽤いた障害対応⽀援 ⽣成AIツールの導⼊事例(https://speakerdeck.com/fukubaka0825/peazuniokeruamazon-bedrockwo-itazhang-hai-dui-ying-yuan-cheng-aiturunodao-shi-li-at-20241115pei-xin-awsuebinadeng-tan)

ogady

November 21, 2024
Tweet

More Decks by ogady

Other Decks in Technology

Transcript

  1. About Me ogady | Takumi Ogawa(@_ogady_) • 株式会社エウレカ ◦ 2021年にSREとして入社

    ▪ 現在はSRE/Data Platform Team ◦ 最近はボルダリングしたり、HoYoverseゲーム やったり、帯状疱疹という病にかかったり
  2. AIOpsとは • IT運用効率の向上を目的としてAI技術を活用し、パフォーマンス監視、ワークロードスケジュー リング、データバックアップ等のタスクを自動化するプロセス • AIOpsのユースケース ◦ アプリケーションパフォーマンスモニタリング(APM) ◦ 根本原因解析

    ◦ 異常検出 ◦ クラウドの自動化と最適化 ◦ アプリケーション開発サポート 参考: AIOps とは何ですか?(https://aws.amazon.com/jp/what-is/aiops/) これ、SREのプラクティスをAI活用でさら によくしていこうって話なのでは??
  3. AIOps実践に向けて: LLM for Developerという考え方 SREが投資するスコープを「LLM for Developer」として定義 LLM for Developerとは

    Developerの開発/運用効率向上を目的とし、LLMを利用した開発・運用支援のツール開発を行うこと • 主にLLMの技術領域を活用する ◦ 本格的な学習を含むMLOps領域やProductのAI機能はAIチームの専門とする • ここでいうDeveloperとは ◦ アプリケーション開発者 ◦ インフラ・データ基盤開発者 ◦ データ基盤利用者(データアナリスト含)
  4. AIOps実践に向けて: SREチームプリンシパルの変更 SREチームとしてAIOpsの工数を確保するために、チームプリンシパルを変更   → チームとしてAIOpsに対して取り組む責務があることを明記し、チーム戦略として組み込む • Development Support Tools ◦

    開発生産性の向上に対する寄与。 ◦ 複数のチームにおいて存在する共通のニーズを抽出し、解決を支援するツールを提供する事で全 てのチームの生産性の向上とオペレーションの品質の向上・簡略化を目指す。 ◦ ChatOpsを中心とした、developerがself serviceでdeliveryできる領域の拡張 ◦ AIOps領域への投資・実践 ▪ 2024年現在は以下のようなテーマを中心に調査・実装を行い、実際の開発プロセスへの 組み込みについて試行/評価を行っている。 • コーディング&レビュー支援 • システム&データ仕様記述支援 • システム&データ仕様参照支援 • インシデント対応支援 • 会議効率化支援 • 技術キャッチアップ投資 New!!
  5. AIOps実践に向けて: SREチームプリンシパルの変更 SREチームとしてAIOpsの工数を確保するために、チームプリンシパルを変更   → チームとしてAIOpsに対して取り組む責務があることを明記し、チーム戦略として組み込む • Development Support Tools ◦

    開発生産性の向上に対する寄与。 ◦ 複数のチームにおいて存在する共通のニーズを抽出し、解決を支援するツールを提供する事で全 てのチームの生産性の向上とオペレーションの品質の向上・簡略化を目指す。 ◦ ChatOpsを中心とした、developerがself serviceでdeliveryできる領域の拡張 ◦ AIOps領域への投資・実践 ▪ 2024年現在は以下のようなテーマを中心に調査・実装を行い、実際の開発プロセスへの 組み込みについて試行/評価を行っている。 • コーディング&レビュー支援 • システム&データ仕様記述支援 • システム&データ仕様参照支援 • インシデント対応支援 • 会議効率化支援 • 技術キャッチアップ投資 New!! LLM for Developerの工数として - SRE 1人月 - AI 1人月 を確保することでチーム間で合意
  6. Pairsの開発、運用、機能、障害対応に関する質問を解決するQ&A LLM ChatBot(Pairs Navi)を提供 • Pairsの開発、運用、機能、障害対応に関する質問を解決するLLM ChatBotを提供 ◦ ドキュメント情報を基に構築したRAGを活用し、一般的なLLMの知識も踏まえ多言語 で質問に答える。テキストだけでなく画像やpdfのインプットにも対応

    ◦ 翻訳機能や文章校正機能も一部のユースケースのために提供 ◦ 障害対応チャンネルが作成されると、Pairs Naviも自動でInviteされ、いつでも対応 者が活用できる状態に ◦ 障害対応に不慣れな人でも簡単に障害対応プロセスをキャッチアップ可能な状態に し、プロセス認知負荷軽減を目指す 詳細はこちら: ペアーズにおけるAmazon Bedrockを⽤いた障害対応 ⽀援 ⽣成AIツールの導⼊事例
  7. LLM for Developerとして投資すべき項目を分類 LLM for Developerで投資するべき課題を6項目にカテゴライズ 1. コーディング&レビュー支援 ◦ 開発効率やレビュー精度向上を図る

    2. システム&データ仕様記述支援 ◦ ドキュメントの生成サポートや品質向上を図る 3. システム&データ仕様参照支援 ◦ ChatBot、LLM agentにより仕様の把握をサポートする 4. インシデント対応支援 ◦ インシデント対応のコマンダーサポートや原因調査の効率化を図る 5. 会議効率化支援 ◦ MTG議事録の生成や、文字起こしなどのサポート(Tool選定なども含) 6. 技術キャッチアップ投資 ◦ アップデートや新技術開発が高速なLLM領域のキャッチアップ
  8. GitHub PullRequestに対するAI Reviewの拡張 GitHub PullRequestに対するAI Reviewを拡張し、社内のコーディング規約に沿ったレビュー機 能を追加 • 社内コーディング規約のレビューが難しいという課題 ◦

    規約の量が多い ◦ 新規参入者は特に、レビューで毎回意識しないといけないので効率が悪い ◦ 自動でレビューされて自己解決できるとレビュワーもレビュイーも楽 • tmokmssさんの、bedrock-pr-reviewerを拡張 ◦ https://github.com/tmokmss/bedrock-pr-reviewer • GitHub Wiki上の社内コーディング規約を`system_message`に組込むかたちでプロンプト チューニング ◦ 社内コーディング規約の文量がそこまで多くないため、そのままコンテキストとして 渡すことが可能だった。
  9. GitHub PullRequestに対するAI Reviewの拡張: 実装 GitHub Actionsとして組み込み: 一部抜粋 name: AI review

    internal style guide jobs: Run-Bedrock-review: runs-on: ubuntu-latest steps: - name: Checkout Wiki uses: actions/checkout@v4 with: repository: ${{ github.repository }}.wiki token: ${{ secrets.GITHUB_TOKEN }} path: "wiki" - name: Load Go Style Guide id: load-go-style-guide run: | GO_STYLE_GUIDE_CONTENT=$(cat wiki/Style-Guide.md) echo 'GO_STYLE_GUIDE_CONTENT<<EOF' >> $GITHUB_ENV echo "$GO_STYLE_GUIDE_CONTENT" >> $GITHUB_ENV echo 'EOF' >> $GITHUB_ENV - name: PR review uses: tmokmss/bedrock-pr-reviewer env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} with: debug: false path_filters: | **/**.go disable_release_notes: true bedrock_heavy_model: "anthropic.claude-3-5-sonnet-20240620-v1:0" system_message: | ## この後のスライドで話します GitHub Wikiをcheckout 社内コーディング規約(スタイルガイ ド)を読み込み、$GITHUB_ENVとして 設定 tmokmss/bedrock-pr-reviewerを利用、 アプリケーションコード(*.go)のみがレ ビュー対象 リクエスト数が少ないため、性能重視で モデルはclaude-3.5 sonnet v1を利用
  10. GitHub PullRequestに対するAI Reviewの拡張: 実装 system_message: | You are `/reviewbot` (aka

    `github-actions[bot]`), a language model trained by Bedrock. Your purpose is to act as a highly experienced software engineer and provide a thorough review of the code, focusing solely on compliance with the internal Go Style Guide. For code reviews regarding Golang, review strictly based on the internal Go Style Guide included here: ${{ env.GO_STYLE_GUIDE_CONTENT }} When reviewing the code, prioritize checking the following based on the internal Go Style Guide: - Adherence to naming conventions, formatting, error handling, and documentation as specified in the guide. - Code readability and consistency according to internal policies. In your response, include the following reference URL for the Go Style Guide written in markdown : ${{ env.GO_STYLE_GUIDE_URL }} example: > ref: ${{ env.GO_STYLE_GUIDE_URL }}#<<markdown header>> Please answer this prompt in ${{ contains(steps.get_labels.outputs.result, '-en') && 'en-US' || 'ja-JP' }}. Avoid any feedback or comments that are not directly related to the internal Go Style Guide requirements. system_messageとして渡すプロンプト抜粋: 基本的にはベースとなっている デフォルトプロンプトを踏襲。 社内コーディング規約をそのま まコンテキストとして渡し、そ れを参照してレビューするよう 指示 レビュー結果に参照したコー ディング規約のURLを出力する ように指示することでレビュ イーに伝わりやすくする
  11. GitHub PullRequestに対するAI Reviewの拡張: レビュー結果 コーディング規約(例) ============================= Exists (Select) - ✅

    対象レコードの存在チェックを実行し たい場合、 SELECT 1 を使用する - ❌ レコードそのものを取得しない ============================= referenceも示した上で、社内コーディン グ規約に沿ったコードレビューが自動で行 われるように
  12. まとめ • ペアーズでは専門家であるAIチームとSREチームがちゃんと協調する座組を作り、AIOpsに取 り組んでいく ◦ 開発者のニーズをプラットフォーマーとして実現していく以上、個人プレーではなく、 組織として戦略的に取り組むためのスキームが重要 • AIチームの先行投資含め、いくつか施策を進めている状況 ◦

    特にnariによる障害対応改善の施策の評価がとても高い ◦ AIによる自動PullRequest Reviewはリリースしたばかりなのでフィードバックを取り込 みつつ運用していく • 新しい技術領域へのチャレンジの側面もあるので、技術的な楽しさがある