私個人の障害対応の経験と
一昨日参加したIncident Response Meetup vol.1での学びから
障害対応において大切だと感じていることをまとめる。
障害とは
リリース後のシステムにおいてシステムの不具合やユーザーの操作ミスによってユーザー業務に影響が出ているもしくは出る恐れがあるもの。
障害対応の目的
システムを直すことではなく、ユーザー影響の回避・低減・早期回復をすること。
障害対応に対する心構え
- システムの信頼性の要である
- 障害への対応の仕方でユーザー影響が大きく変わる
- いつ発生するかわからないため特定の人が常に障害対応をするということは不可能である
- 素早く適切に行動するための備えが重要である
役割分担
障害対応では復旧対応、原因調査、ユーザーへの説明、社内調整などたくさんのことをやる必要がある。
またそれぞれの作業の難易度が高いことも多い。
一人の人間にできることは限られている。
そのため役割分担をする必要がある。
特に以下が重要であると考える。
- 作業者が一つの作業に集中できていること
並行で進めなければいけない作業がある場合は分担できるだけの人を集めるべき - 専任のインシデントコマンダーが存在すること
インシデントコマンダーの役割
- 障害対応に必要な人員を集め体制の構築と維持をする
- すべての情報を集め、判断をする
情報が自分に集約されるように行動をする必要がある - インシデントコマンダーは直接作業を行ってはいけない
情報集約
情報はフロー型とストック型でまとめるのが良い。
情報集約はやり方によって一長一短がある。
障害対応では後から対応者が増えることがある。
障害対応は長期化することがあり、メンバーが入れ替わることがある。
その際に新しいメンバーが状況をすぐに把握できる必要がある。
また再発防止のための振り返りでは整理された情報が必要である。
ユーザーへの説明にも整理された情報が必要である。
そのため2種類の方法を組み合わせてまとめ、
対応メンバーは誰でもすぐにアクセスできるようにする。
フロー型
タイムライン、経緯。
いつ何が起きたのかを時系列で記録する。
ストック型
システムとタスクの最新状況を整理してまとめたもの。
障害対応メンバーが一目で最新状況を理解できるようにする。
- 現在のシステム影響の状況
- 実施している作業、目的、作業者、完了予定
- 現在の体制（だれが何の役割を担っているのか）
事前に所定のフォーマットを用意しておくことで作成時間が短縮できる。
コミュニケーション
- WarRoomの準備
WarRoomとは障害対応中のメンバーが同期コミュニケーションを取れる場所。
方法はなんでも良いが使い慣れた方法が良い。
事前にWarRoom設置をどのように行うかを決めておくと迷子が発生しづらい。 - コミュニケーション時に意識した方が良いこと
情報は簡潔に伝える
事実と推測は分けて考える
インシデントコマンダーに情報を集約する
調査作業者としての心得
- 推測をしない（ログを見る）
- ユーザーの発言を鵜呑みにしない（ログを見る）
- ユーザーの発言を必要以上に疑わない（推測で捻じ曲げない）
振り返り
- 必ず振り返りを実施する
- できるだけ早く実施する
- 振り返りのフォーマットを決めておく
事前の備え
事前に備えておくことで障害対応時にすばやく落ち着いて行動ができる。
障害復旧までの時間は直接的な復旧活動以外の時間も含めたかかった時間の総和である。
そのため簡単なことでも取り決めておくことが重要。
- インシデントコマンダーを機械的に決定できるようにしておく
- 障害のレベルを決めておく
- 障害のレベルに応じた体制の構築手順を決めておく
機械的に実施できるようにしておき、人を集める心理的ハードルを下げておく - 障害のレベルに応じた復旧プロセスを用意しておく
- セキュリティインシデントの場合
データ保護を最優先に行動できるようにする - コア機能に障害が起きている場合
コア機能の復旧を最優先に行動できるようにする
- セキュリティインシデントの場合
- 情報集約のフォーマットを用意しておく
- WarRoomの設定方法を決めておく
- 障害解消とする条件を決めておく