レジリアのイチ推し！自動化によって誰でも参加できるインシデント対応フローのご紹介 | Resilire Tech Blog
はじめに
サプライチェーンリスク管理クラウドサービスResilire（レジリア）でPdM/PjMをしている@seohyangです！Resilire（レジリア）ではPdMとして、プロダクトの課題を管理しながら、製品リリースの管理やエンジニアリング、セールス、カスタマーサポートなど複数の部署と連携しながらプロダクト開発を推進しています
経歴としては、ソーシャルゲーム開発→Fintech→HR SaaS→Resilireと様々な業界で開発をしたり海外展開したり事業を推進してきました。詳しいプロフィールはこちら
本ブログでは、様々な業態・規模・職種で開発に関わってきた私が、弊社でのインシデント対応のプロセスを推しポイントに合わせて紹介します！
ここがレジリアの推しポイント！
- フローが決まっていて対応も自動化されているので、誰でもインシデント対応に参加できる！
- 振り返りまでを一つのプロセスにしているので、インシデントの暫定対応だけで終わらない・長引かない
- まずはいいところからみんなで賞賛するので険悪なムードにならず建設的な再発防止が議論できる
ポイント① フローが決まっていて対応も自動化されているので、誰でもインシデント対応に参加できる！
インシデントの報告は社内の誰もが簡単に行えるようになっていて、それをトリガーとして一連の自動化された対応フローが開始されます。
こちらがSlack上で[不具合対応フォーム]のブックマークを押すと出てくるフォーマット（一部）です。最低限の情報を入れるだけで報告者と開発チームでのやり取りができます。
Asanaで作られた不具合報告フォーム
自動化されたインシデント対応フロー
特に本番環境に影響のあるインシデントが発生すると、以下の要素が自動生成されます。
- 情報と対応を集約するためのSlackチャネル
- インシデント対応を型化したAsanaプロジェクト（タスク含む）
- ポストモーテムを型化したNotionテンプレート
不具合報告後の対応フロー
そして、入社時に全員が受けるインシデント研修に基づいて、各自の役割が決定され、インシデント対応が進められます。
インシデントを管理するための登場人物（社内notionから引用）
インシデント報告後はこれらの役割を速やかに分担して対応を開始します。
| 登場人物 | 役割と責任 |
|---|---|
| 報告者 | これを読んでいるあなたです。 報告することに責任を持ちます。 |
| インシデントコマンダー | インシデントの管理をスムースにするためのファシリテーターです。 通常、インシデントに対して一人です。 インシデントのスムースな対応に責任を持ちます。 |
| 顧客対応担当者 | 顧客の窓口になる担当者です。 通常、顧客に対して一人です。 顧客との調整に責任を持ちます。 |
| サービス影響確認担当者 | サービスの調査を行う担当者です。 サービスの調査に責任を持ちます。 |
| サービス対応担当者 | サービスの暫定復旧を行う担当者です。 サービスの暫定復旧に責任を持ちます。 影響確認を優先する前提で、サービス影響確認担当者を兼任することが可能です。 |
誰でもインシデントコマンダーを務められる仕組み
インシデント報告によって自動生成されたAsanaには初期対応の手順がタスクとしてはじめから登録されています。
自動で作られたAsanaプロジェクトがコマンダーの対応手順を教えてくれる
コマンダーになった人はこれらのタスクに従って障害対応の確認を進めるだけなので、経験値や職種に関係なく誰でも対応が可能です。
やります！
ポイント② 振り返りまでを一つのプロセスにしているので、インシデントの暫定対応だけで終わらない・長引かない
過去に、障害対応と通常開発のリソースが競合し、振り返りが後回しになることがありました。（遠い記憶）
しかし、Resilireでは「ポストモーテム（振り返り）」の実施と、インシデント対応用のSlackチャネルを完了することが、障害対応のタスクに含まれています。このため、大抵の場合、障害発生から1～2週間以内に対応が完了します。
こちらは先ほどのAsanaの続き、状況の終了に向けたタスクも教えてくれる
ポイント③ まずはみんなで対応を労い、実績を確認するので、険悪なムードにならず建設的な再発防止が議論できる
インシデントが発生したときの雰囲気こそ、開発チームの真の姿だと考えていますが、Resilireのポストモーテムは以下の流れで進行します。
[事前準備]インシデントコマンダーやインシデント対応エンジニアは、以下を事前に記載します。
- 対応の整理
- インシデントに対してどのような対応をしたか
- タイムライン
- インシデント発生から誰がいつ何をしたのかの記載（Slackチャネルを参考にする）
ポストモーテムの当日には、インシデントの関係者を集めて（必要があればCSやセールスなどプロダクトチーム以外も参加）、該当のNotionに沿って会を進行します。
まず最初に行うのは、お互いの対応を労うことです。
社内Notionのポストモーテムと振り返りについての説明
インシデントが発生した際、開発を担当したエンジニアを責めたり、クライアント対応が遅れたCSを非難したりするのではなく、全員が最善を尽くしたことを労うところから始めます。
こうすることで、個人の過失ではなく、仕組みで解決できる改善点を見つけ出す建設的な議論に繋がります。
最後に
新卒で入社した会社のCTOが、「不具合を起こしたくないなら、ソースコードを書かなければいい」と言っていたことがあります。それくらい、開発とインシデントは切っても切れない関係です。
だからこそ、インシデントが発生したときに、どんなマインドでどう対応するかが、プロダクトチームの真価を問われる瞬間だと思います。
弊社のチャレンジ「モノづくりを止めないために、世界のサプライチェーンをアップデート」に果敢に挑戦できるよう、プロダクト開発も日々アップデートしていきたいと思います！
我々と一緒にチャレンジしてくれる方を絶賛募集中です！
Discussion