はじめに
インシデント対応、管理の見直しをしていく中で、
入社後、インシデントを 100 件以上対応していたことに気づきました。
少しずつ学びが蓄積されてきたかなと思い、、
復旧対応までに意識していることをまとめてみました。
プロダクトの規模やインシデント対応フローごとに変わってくる部分もあるかと思いますが
少しでも参考になれば幸いです。
大まかなフロー
インシデントの大まかなフローは以下の通りです。
※各フローでの具体で何をしているかは省略。基本は復旧を最優先に動きます。
- 検知
- 対応優先度の判定
- 復旧策の検討
- 復旧策の実行
- インシデントの close
インシデントや close の定義は各社によって異なるかと思いますが
ここでは下記の定義としています。
インシデントの定義（今回は 1 の対応時のお話がメインになっています）
- サービスの想定外の中断、品質の低下
- 将来的にサービスに影響がある可能性があるもの
close の定義
上記インシデントが解決されたことを確認できた状態
では、各フローにおいて意識していることをまとめていきます。
検知
1. 事実を正確に把握する
ユーザーや社内メンバーなど、人からの報告は
推測が混ざっているという前提の方が良さそうです。
- 事象の発生時刻、環境を確認（利用ユーザー、使用ブラウザなども分かるとなおよし）
- 優先度の判定に必要な情報を収集しやすくなったり、復旧策の検討時に要因の切り分けがしやすくなったりするため
- 画面上で見えるインシデントの場合：どの画面の何ができないのかを把握する
- できればスクリーンショットや動画なども残しておく
- 復旧後の確認や、問題管理にも有効になるため
- できればスクリーンショットや動画なども残しておく
2. 期待した結果との差分が分かるようにしておく
期待した結果はどのようなものかを明確にしておくことで、事象を把握しやすくなり、
また close 時も判断しやすくなります。
例）✗：登録しようとしたらエラーになった
例）◯：登録ボタンを押したら、「登録が完了しました」と表示されるはずが、「エラーが発生しました」と表示されている
対応優先度の判定
優先度の定義は決まっているので、判定ができるような情報を集めていきます。
1. 影響範囲はできるだけ正確に
発生しているユーザーが少ない場合はどこに影響があるかまで詳細に記載しておく
例）△：複数社に影響あり
例）◯：△△ 条件にあてはまる、A 社、B 社、C 社に影響あり。
2. 調査ログを残しておく
- 対応後の振り返りに活用するため
- 属人化を防ぐため
- 同様の事象が起きたときに、他の人も対応できるようになる
復旧策の検討
調査しすぎない
ついつい根本原因を調査したくなるのですが、、
復旧に必要な情報までに留めるよう意識しています
復旧策の実施
1. 作業ログを残しておくこと
復旧策の検討と同様に振り返りに活用するのと
今後、同様のインシデントが発生したときにワークアラウンドとして有効になるため
2. 作業中に想定外の事象が発生した場合は即時ストップする
二次被害を防ぐため。復旧策の検討からやり直します。
インシデント close
close の定義に一致した状態となっているか確認すること
当たり前ですが、復旧策を実行して安心してしまったりするので、
復旧したこと（≒close の定義に一致した状態）を確認します。
終わりに
各フローにおいて意識していることをまとめてみました。
改めて言語化していくと、事実を把握すること、記録を残しておくことが重要なのかなと。
当たり前に感じることが多いような気もしますが、
インシデント発生時、多少なりとも冷静さが欠けてしまいがちな時に意識できるようにしておきたいです。
対応フローの整備どうやったの？や、インシデント管理についても記事にしていますので
また見ていただければと思います！
インシデント管理とは？
フロー整備について
会社で Musubite というサービスを使い始めました！
気軽にお話できればと思いますので、もし興味ある方いらっしゃれば
下記リンク見てみていただければと思います！
LiB Consultingに所属するエンジニア・デザイナーの個人記事を集めています。 記事内容はあくまでも個人の見解であり、会社としてレビュー等はしておりません。あらかじめご了承ください。
Discussion