障害管理の効率化に向けたSlackのリスト機能活用法

こんにちは、ウィルゲート開発室PMO(プロジェクトマネジメントオフィス)の大嶋です。

今回は2024年6月にリリースされたSlackのリスト機能を活用してシステムの障害管理の仕組みを構築したのでご紹介します。

slack.com

Slack上に作成した障害管理用リスト

はじめに

ウィルゲートでは10年以上前からJIRAのプロジェクト管理機能とワークフローをもとにした障害管理の仕組みを運用してきました。 長く運用を続けられている一方で、近年では以下のような問題が目立ってきていました。

  • 開発部門全体で共通運用しているルールではあるが、チーム体制の変遷や人員の入れ替わりなどを経て実態として形骸化している部分がある
  • 障害チケットに記載するべき項目の多さや正確さなど現場の負荷が高い反面、生産性指標*1のモニタリングには活用しきれていない
  • プロジェクト管理の環境が当時は主流だったJIRAから移り変わってきており、障害管理など一部の仕組みだけが残っている

今回はこういった状況を受けて、開発本部として障害管理の仕組みの見直しにあたりました。またちょうどSlackのリスト機能が公開されたタイミングに近かったことから、これをうまく運用に組み込めないかを模索してみました。

運用の省力化

まず管理環境など仕組みの前に、現場の運用負荷が高いということと運用が一部形骸化しているということに注目し、運用ルールを見直すことを考えました。

従来のフローでは、障害事案に対してインシデントの解消後に障害の原因や再発防止策などを開発組織の全リーダーの確認を経た後にクローズするというルールになっていました。 この主な目的としては、情報の横展開による組織としてのリスク対策*2になります。

ただし、導入時と異なる点として、

  • 当初は3~4名程度だった確認者(チームリーダーなどの数)が、現状は2倍以上に規模が増えていること
  • 事業やプロダクトの拡大や変化とともに前提となるドメイン知識や技術スタック、開発手法などもまちまちになっていること

などがあり、チーム横断で共有するべきナレッジを適切に抽出したり、またそれを理解し担当チームに還元するのは現実的に難しくなっていました。 従って、必要なナレッジ共有は別の形で行う位置づけとして、このタイミングでこれを直属の管理責任者による確認をもってクローズする形へと変更しました。

運用フローの設定とリスト機能の使用

Slackのリスト機能を中心として、担当者と管理者で分担してSlack内で完結する管理フローを設計しました。 ポイントとなるのは以下2点です。

  • 障害事案1つに対して1つのリストアイテムを作成して、対応開始からクローズまでの状態と管理情報を記録する
  • 障害に関するやり取りは専用の一時チャンネルを作成してその中で行い、完了後はアーカイブして整理する

障害対応全体のフロー

ワークフローによる補完

作成した障害管理フローがよりスムーズに運用できるように各工程をSlackのワークフローを使用して接続しました(※ここではワークフローの作成方法などの詳細は割愛します)。

  1. 障害の発生検知と対応開始

    発生した障害に関連するメッセージに「障害検知」というスタンプのリアクションをつけることで、これを起点にSlackのワークフローが開始するようにしました。ワークフローは以下のような設定にしています。

    • フォームを表示し必要な情報を入力してもらう
      障害対応開始時の入力フォーム
    • 障害管理用のSlackリスト内にアイテムを生成する
      作成されたアイテム
    • 命名規則にしたがって専用の一時チャンネルを作成し関係者を招待
  2. 障害の記録とクローズ

    リストのアイテムに障害に関する情報を簡潔に記載したうえで、完了の処理をします。ここではアイテムのステータスを解決済(Done)に変更するとこれを検知し、ワークフローが起動されるようにしました。

    • 管理者に設定されているメンバーへクローズ依頼の通知がされる
    • 管理者は記載内容を確認して、メッセージに付いているクローズのボタンを押す
    • 一時チャンネルがアーカイブされるとともに、リストのアイテムのステータスがクローズとなる
      障害の完了処理

仕組みとしての問題点

今回の仕組みは割と簡単に構築できてかつSlack内で完結できるというメリットは大きいものの、従来の仕組みと比較していくつか問題点も残りました。

  • 細かい権限設定が行えないため、本来は管理者だけが操作できるようにしたいステータス遷移や入力項目設定が制御できず、善意での運用に委ねられる
  • リストのアイテムごとに時間や期間を起点にした通知(リマインドなど)が行えないため、例えばステータスが止まったままのものを検知するといったことが難しい
  • 現時点ではWebAPIからリストへアクセスする機能の提供がされていないため、GoogleAppScriptなど外部のツールと連携した複雑な制御ができない

このような問題はあるものの、運用をするうえではそこまでクリティカルなものではないと判断し、前向きに取り入れることにしました!

今後の展望

現在まだ検証中で試験運用段階を出ていませんが、今後以下のようなブラッシュアップをしていきたいと考えています。

  • 実績管理

    障害対応の一時チャンネル作成からクローズまでの時間をもとに、障害クローズまでの期間を定量的に計測するなど、モニタリング環境を整えて改善活動につなげられるようにする。

  • 運用の改善、省力化

    障害のクローズ処理時点でのリストアイテムへの必須項目への入力チェックや定期的なリマインドの仕組み化。

まだまだ発展途上な部分はあるものの、リスト機能自体が散らばってしまいがちなチャットをタスクとして管理できるなかなか便利なものだと感じています。 もしもっと効果的な使い方などがあれば、ぜひコメントなどで教えていただければ幸いです!

*1:「MTTR(平均復旧時間)」や「変更失敗率」などが対象

*2:他のチームやプロダクトで発生した問題を把握し、担当チームへの改善課題を設定