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

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

beaverjr
August 04, 2024
18

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

Road to SRE NEXT@仙台での登壇資料です。

beaverjr

August 04, 2024
Tweet

Transcript

  1. 自己紹介 • Erika Takada / @beaverjr_50 • 株式会社モニクル SRE •

    岩手県奥州市出身・在住 ◦ リモート勤務 • JAWS-UG いわて支部
  2. これまでの取り組み 組織全体での基準やフローが明確で ない🔥 障害対応に慣れている人が全て対応 をし、負荷が高い🔥 インシデント対応後のふりかえりが行 われていない🔥 インシデント対応の共通認識、共通言 語ができた👌 ロールの分離ができた👌

    対応後にはふりかえり会が行われるよ うになり、記録が残され対応プロセス やプロダクトの改善に繋げられるよう になった👌 2023.7- SREチーム立ち上げ後 ・SEV(Severity Level)、ロール(インシデントコマンダー /オペレーションリーダー)、対応フローを定義し、  インシデント管理表を整備 ・ポストモーテム Templateの整備、インシデント後のふりかえり会の開始 Before After
  3. 対応方針:初動対応の標準化 • War room(インシデント対応用Slackチャンネル)作成の改善 ◦ インシデント発生時にはできるだけシンプルに War roomを作成できるようにする ◦ プロダクトごとのインシデント管理表を元に役割や

    War roomへ呼び出す人を定義しておき、インシ デント発生時には管理表を確認しなくても呼び出せるようにする • 情報共有 ◦ インシデント対応中の役割と責務がその場にいる人全員で認識できている状態にする ◦ 管理表とは別にWar room内で簡潔なインシデントフローを確認可能にする
  4. 対応方針:実現方法 インシデントマネジメントとエンジニアリングのかけ算 - Speaker Deck • 勉強会で紹介されていたSlackBotに 感銘を受け、前述の課題解決にもつな がりそうだったので作成してみることに •

    インシデントマネジメントSaaSも気に なったが、現時点でのインシデント発 生頻度等踏まえて今回はSlackBotで の改善に決定 https://waroom.com/
  5. 従来のSlack App開発との違い Bolt(従来) Slack automation platform 対応言語 JavaScript (Node.js),Python,Java TypeScript(Deno)

    ホスティング環境 任意のクラウドベンダー等で自前で用意 Slack が管理するホスティング環境 開発体験 構成設定などは基本的に GUIから行う Slack CLIでアプリのローカル実行、設定変更、 デプロイなど全ての操作を実行可能 GUIでの変更は不可 コスト ホスティング環境の維持コスト アプリの実行回数による課金 ワークスペースごと一定回数の無料分が含まれ ており、無料分を超過した場合にのみコストが 発生
  6. Slack Automation Platformの要素 名称 説明 ワークフロー(Workflow) FunctionをStepとして組み合わせてやりたいことを実装する もの Triggerから入力を受け取る ファンクション(Function)

    Workflowの中の一つ一つの処理。 Slack 内でのよくある操作を提供する 組み込みFunctionは、 Workflow定義の中で inputs を適切に設定するだけで利用 することができる トリガー(Trigger) 何かしらのタイミングでWorkflowを呼び出す データストア(Datastore) キーバリューストアのテーブルを n 個定義して、CLI のコマン ドやファンクションからデータを登録したり、クエリを実行する ことができる DynamoDBが使われている
  7. Slack Automation Platformで開発してみて • 低コスト ◦ ホスティングを気にしなくていいので、 リソース自体のコストに加え運用コスト も低く抑えられる •

    Slack CLIでの開発体験 ◦ Slackの管理画面を触らなくて済む
 ◦ CI/CDとの相性がいい • SREチームメンバーの知的好奇心を 満たす よかった点 苦労した点 • 要素を理解した上で実装するまで少 し苦労した • 他組織のメンバーとの連携がGUIで のワークフロー設定に比べて複雑 だった
  8. Botの概要 • 前述の課題を解決するために開発した内製のSlack Bot • Irisという名前 • 初動対応の支援機能 ◦ War

    Roomの作成 ◦ War Roomへの参加者自動招待 ◦ インシデント対応フローの案内 • 復旧後のフォローアップ機能 ◦ Todoの作成 ◦ タイムラインの出力
  9. War roomへの参加者自動招待 • フォームで選択したプロダクト、SEVに応じ て参加者がWar roomに自動招待される ◦ botが自動で呼び出しを行うことで、コミュニ ケーションコスト及び心理的負荷を軽減 •

    Botを呼び出した元のチャンネルにもイ ンシデント情報を記載 ◦ 報告者や該当プロダクトの担当以外にも幅 広く情報を共有することが可能
  10. インシデント対応手順の案内 • War room作成後に対応メンバー全員 で認識を揃えられるようにフローを案内 ◦ プロダクトごとのインシデント管理表の Link 提供 ◦

    作成者からの状況共有 ◦ ロールを決定するフローを入れることでメン バーの認識を揃えて対応を進めやすくする
  11. Next Action • Botを使った障害対応訓練の実施 ◦ インシデント対応に慣れることが最重要 • フィードバックの収集と機能拡充 ◦ Google

    Forms等で実際にBotを使用するエンジニアからのフィードバックを積極的に収集 ◦ まずはどんどん使ってもらい、使用状況や改善点を見極める • Datastoreの活用 ◦ Datastoreの機能を活用し、Botの使用データやインシデント対応データを収集・分析 • 定期的な評価とふりかえり ◦ フェーズに応じて最適な取り組みをできるようにするため、取り組み自体のふりかえりを定期的に実 施