Slack Platform（Deno）を活用したインシデント対応標準化の取り組み

はじめに

株式会社モニクルでSREを担当しているbeaverjrです。

弊社SREチームではSlack次世代プラットフォーム（next generation Slack platform）を活用して、インシデント対応の標準化を目指すSlackbotを作成しました。今回はその取り組みについてご紹介します。

背景と課題

弊社では、インシデント対応においていくつかの課題に直面していました。特に、インシデントレベル（SEV＝深刻度）やエスカレーションフロー（SEV別の報告先、役割分担、対応フロー）が定まっていないことが大きな問題でした。そのため、まずはこれらの定義を行いました。

この取り組みにより、複数のチーム間で共通の言語ができ、インシデント対応が少しずつ改善されてきたとのフィードバックも得られました。しかし、以下のような課題が残っていました。

• 復旧作業に夢中で関係者への連絡やフローに沿った対応を忘れてしまう
  インシデント発生時に迅速に復旧作業を行うことに集中するあまり、関係者への連絡や定められた対応フローを忘れてしまうことがありました。
• ふりかえり用のポストモーテム作成の負荷が高い
  ふりかえりに重点をおきたいのに、事実をまとめるのに時間が取られることが多くありました。

これらの課題に直面していた時に、Slackでのインシデント対応Botの事例を見かけ、私たちも同様の支援Botを整備することにしました。Slack次世代プラットフォーム（next generation Slack platform）を活用し、この支援Botを開発しました。
https://speakerdeck.com/hiboma/incident-management-and-engineering

Slack次世代プラットフォームを選んだ理由

Slackの次世代プラットフォームを選んだ主な理由は、別途クラウド環境をセットアップする必要がなく、Slack自体でホスティングできる点です。これにより、迅速にシステムを立ち上げ、運用コストを抑えることができます。また、新たな技術に挑戦してみたいという思いが大きかったです。

従来のSlack App開発との違い

	Bolt（従来）	Slack automation platform
対応言語	JavaScript (Node.js), Python, Java	TypeScript(Deno)
ホスティング環境	任意のクラウドベンダー等で自前で用意	Slack が管理するホスティング環境
開発体験	構成設定などは基本的にGUIから行う	Slack CLIでアプリのローカル実行、設定変更、デプロイなど全ての操作を実行可能 (GUIでの変更は不可)
コスト	ホスティング環境の維持コスト	アプリの実行回数による課金 (無料分を超過した場合にコストが発生)

開発してみて

よかった点

• 低コスト
  • 追加のクラウド環境を用意する必要がなく、リソース自体のコストに加えて、運用コストも低く抑えられました。
• Slack CLIでの開発体験
  • Slackの管理画面にほとんど触れずに開発が進められ、特にコマンドラインベースでの開発がスムーズでした。
  • CI/CDパイプラインとの連携が非常に良く、開発の自動化を実現できた点が効率的でした。
• SREチームメンバーの知的好奇心を満たすことができた
  • 新しい技術に触れることができ、メンバー全員にとって学びが多く、モチベーションも高まりました。

苦労した点

• プラットフォームの理解に時間がかかった
  • 各要素を理解して実装するまでに、少し苦労しました。
• 他組織のメンバーとの連携
  • GUIでのワークフロー設定に比べ、他組織のメンバーの招待の設定が複雑でした。

インシデント対応支援Botの概要

私たちが開発したインシデント対応支援Botは、現在以下の機能を提供しています：

• War Room（インシデント対応チャンネル）の作成

  • botをリンクトリガーで呼び出し、対象のプロダクト、SEV、概要を入力すると、War Roomを作成します。また、botを呼び出した元のチャンネルにもWar Roomの案内とインシデント情報を提供することで幅広く周知することを目指します。
    
    

• War Roomへの参加者自動招待

  • SEVごとに定義された参加者を自動的にWar Roomに招待します。関係者の呼び出しをbotがしてくれることで、インシデント対応時の心理的負荷の軽減を目指します。

• インシデント対応手順の案内

  • War Room内で、対象プロダクトのSEV表へのリンクを提供し、インシデント対応手順を案内します。インシデントコマンダー・オペレーションリーダの役割は対応する人がボタンを押すフローを入れたことで、より役割が明確になるようにします。
    

• 復旧後のフォローアップ：

  • TODOの案内
    • 復旧後に必要なフォローアップ作業をリストアップし、担当者に案内します。
  • インシデントタイムラインのまとめ機能
    • インシデント対応中の活動ログをまとめ、タイムライン形式で提供します。これにより、ポストモーテム（ふりかえり）の作成や後続の分析に役立てることができます。
      

導入後の成果

インシデント対応支援Botは現在3ヶ月程度継続して使用しています。

• 好評だった点
  タイムライン出力機能：
  インシデント対応中の活動ログを自動でまとめ、タイムライン形式で提供する機能が非常に好評でした。これにより、ポストモーテムや振り返りが効率的に行えるようになりました。

• 残された課題
  War Room作成のタイミングが難しい：
  War Room自体の作成は容易になったものの、「いつ作成するべきか」というタイミングの判断は依然として難しく、対話やチーム内での合意形成が必要な場面が多いです。

今後の展望

今後は、実際にbotを使用するエンジニアからのフィードバックを得てさらなる機能追加と改善を行い、ツールの効果を最大化していきたいと考えています。
直近ではdatastoreの機能を使って、SEVの変更やインシデント収束にかかった時間の計測を行なっていきたいと考えています。

参考

https://qiita.com/seratch/items/ecc16b845483c9d6f9e1