はじめに
こんにちは！SREチームの島です。普段はシステム障害によるお客様影響を減らすためにチームを横断したSRE活動をしています。
今回はSlackの会話履歴から障害報告を自動生成してくれるbotを作ったのでご紹介します。他社でも似たような事例はよく見かけますが、事例が多いということは同じような課題を抱えている人が多いということだと思うので、参考になればと思い、私の体験を書きます。
こんな人に読んでほしい
この記事は以下のような課題を抱えているエンジニアやSREの方に特に読んでほしいです。
- 障害報告を書くのに時間がかかる。情報を集めてくるのが大変
- 障害対応中に途中から入ってきた人に状況を説明するのが大変
- 障害報告を書く負担を減らしたい
作った背景
課題を把握する
障害対応って大変ですよね。私はできるだけ障害対応者の負担を減らしたいと考えていました。そこでまずは障害対応における課題を把握するためにエンジニア全員へサーベイを実施しました。
その結果、「障害報を書くのが大変・負荷が大きい」という意見が半数以上の人から挙がりました。他にもさまざまな課題や要望が挙がったのですが、「この課題になら自分でもすぐにアプローチできるのでは」と思い、今回の開発に至りました。
ニフティの障害対応フロー
ニフティでは障害が発生するとその障害の専用チャンネルを作り、チャンネル内でやりとりを行うルールとなっています。
ニフティの障害対応フローを簡単にまとめると以下のようになります。
このフローとサーベイ結果を踏まえると以下のような課題が見えてきました。
- 担当者は障害対応をしながら障害報を更新しなければならない
- 途中から障害対応に参加した人が一目で状況を理解しづらい（人に聞くか、チャンネルを読み返すか、更新中の障害報を読むしかない）
- 担当者は後日、Slackの会話を見返しながら障害報を完成させないといけない
この課題にアプローチするため、障害情報を要約するbotを作成し、障害報作成の負担軽減を試みました。
以上の背景を踏まえて、今回作成したbotについてご紹介します。
作ったもの
今回作ったbotを「障害要約bot」と名付けました。
彼はSlackチャンネル内の会話履歴を読み取って障害情報を要約してくれます。
彼は以前からニフティに存在する「myfriendGPT」という有能な友達（社内ツール）のソースをベースに作りました。1
つまり彼はmyfriendGPTの弟分です。そういった意味も込めてプロフィールの顔写真をmyfriendGPTと同じWEBサイト（ThisPersonDoesNotExist）で作成しました。
https://this-person-does-not-exist.com/en
実際に使ってみる
作った障害要約botを実際に使ってみました。
使い方は要約をしたいSlackチャンネルで障害要約botへ空メンションを送るだけです。
使い方はなるべくシンプルにして誰でも使えるようにしました。障害対応時にしか使わないため複雑な操作が必要だと使い方を忘れてしまったり、面倒で使わなくなってしまうと考えたからです。
数秒待つと障害情報の要約を返してくれます。
伏せ字が多く見づらくてすみません。
Slackの会話履歴から読み取れる情報を要約してくれます。Slackから読み取れない情報（この例では影響金額と影響ユーザー数）は「不明」と返されます。返す項目は障害報のフォーマットに合わせているので、これをそのまま障害報にコピーすることができます。もちろんAIなので情報が正しいか精査は必要ですが。
対応ログやエスカレーションフローも返してくれます。（上のキャプチャの続きです）
人力で対応ログを書くとなるとSlackを遡って何時何分に何が起きたかを調べないといけないので大変ですよね。対応ログの作成には特に障害要約botの活躍を期待しています。エスカレーションフローもmermaid形式で返してくれるので、例えばエンジニア以外の方などプログラミングの知識があまりない方でもエスカレーションフローを書きやすくなるのが嬉しいポイントです。
この要約を見ることで途中から参加した人でも素早く状況を理解できますし、Scribe（記録係）の人は要約を参考にすることで障害報を書く時間を削減できると期待しています。
myfriendGPTからの変更点
上の章で、既存ツールであるmyfriendGPTをベースに障害要約botを作成したと書きました。ここではベースとしたツールから「どこ」を「なぜ」変更したのか説明します。
1. チャンネル全体の会話を読み込むようにした
myfriendGPTは1対1の対話式で使うbotなこともあり、スレッド内の会話のみ読み取る仕様になっています。今回の障害要約botは複数人の会話を要約するという役目があったので、チャンネル全体を読み込むようにしました。
しかし読み込むデータ量が増えるとその分APIのRate Limitエラーなどのエラーが起きる確率も上がるという問題もありました。そこでエラーの発生を減らし、要約の精度を上げるために以下のポイントを工夫しました。
- 大量の添付ファイルを読み込むとエラーが発生するので、メッセージに添付された画像やファイルは読み込まないようにした
- 読み込むメッセージ数が多いとエラーになってしまうので、過去の障害対応期間やメッセージ数を参考に読み込むメッセージを直近7日間、最大1000件までに制限した
- 人間以外の発言を読み取ると要約に余計な情報が入ってしまうため、人間の発言のみ読み取るようにした。下のキャプチャがその例です。
アプリからの通知や人間の発言ではないメッセージ。これらを無視するように設定
2. 投稿日時、 投稿者を取得するようにした
メッセージの投稿日時と投稿者名をAIに渡すようにしました。そうすることでいつ、誰がという情報を読んでくれるので、より詳細な要約を作成してくれます。
なぜAI開発未経験で作成できたのか
1からこのようなbotを作るのは結構大変だと思います。自分もAIの開発経験がなかったので何もない状態から開発するのはおそらく無理でした。
では今回なぜ障害要約botを作るのことができたのか。その要因をご紹介します。
ベースとなるソースコードがインナーソース化されていた
ベースにできるソースコードが社内に存在し、そのコードが「利用できる状態になっていた」ことが要因として挙げられます。ベースにしたmyfriendGPTはインナーソース化2、つまり社内で使えるオープンソースとなっていました。そのため、
- 初見でも理解しやすいようにREADMEが充実していた
- 2次利用することが歓迎された
という後押しもあり、スムーズに利用できました。
また、ちょうどタイミングよく「コントリビュートお試し会」というお試しでインナーソースのコントリビュート3をしてみようという社内勉強会があり、それに参加していたことでこのソースが使えそうだと思いつきました。まさにインナーソースの利点を活かすことができました。
日々情報収集していた
これは好きで続けていたことなんですが、スキマ時間に他社の勉強会の資料をチェックしたり、SNSを見て気になった技術記事を日々チェックしていました。今回も過去に似たような事例を見た記憶があったので、真似してみようと思い作ることができました。日頃から情報収集をして脳に情報を溜めておくことは大事だと感じました。
今回のbotは以下の他社様の記事を参考にさせていただきました。
Amazon Bedrock を用いた障害対応報告書とポストモーテム文書自動作成
『全員インシデントコマンダー』の体制構築から 1年経った現在地
まとめ
今回はSlackの会話履歴から障害報告を自動生成するbotを作成しました。
まだ公開したばかりで利用実績が少なく実績を報告できないのが残念ですが、これから社内で障害要約botが活躍してくれることを願っています。（SREとしては活躍する機会が少ないのが理想ですが）
障害報作成の負担を軽減することで担当者が障害対応に集中でき、対応にかかる時間やコストを削減できることを今後期待しています。
※ 脚注
- myfriendGPTについてはこちらの記事を参照ください。こちらも一読いただけるとより理解を深められます。
ChatGPT APIを活用したSlackbotを作成して、30分以内に会社内に有能な友達を作る ↩︎ - インナーソースについてはこちらの記事で詳しく紹介しています。
インナーソースを導入してみた その① お試し導入編 ↩︎ - コントリビュート：自分がオーナーでないリポジトリのソースを修正してあげること ↩︎
