事実(判明していること)と推測、不明点は整理されているか	何が分かっていて、何が分かっていないのか、何が分かれば問題解決するのか整理できていないと調査を実施できない
5W1Hを把握しているか	発生期間、発生件数、発生場所など報告書記載時に正確な数値が必要
チーム内に共有されているか	障害が発生したことをチーム内のメンバに報告しているか、打ち合わせに出たメンバーにしか周知されていないといったことがないか等
チーム内で話し合いはしているか	共有だけでなく、チーム内でミーティングを実施し、障害の状況の整理、対策案の立案を話し合っているか
チーム外の有識者から助言を得ているか	チーム外のメンバが類似の障害を経験しているかもしれない
障害の再現は試みたか	障害の再現が実施できれば、何が障害の引き金になっているか分かる
障害発生時の証跡(ログファイルなど)のバックアップはできているか	後々、揉めることになるので、不要だと感じるログもバックアップした方がいい
ソフトウェアの設定値を把握しているか	上限値、リトライ間隔など、設定値を把握していないとソフトウェアの挙動が把握できない
デバッグモードへの変更を実施したか	ログをデバッグモードにするとソフトウェアの挙動を詳細に把握できる
別の場所、時間帯で同じ障害は発生していないか	2次災害を避けるため、把握の確認の必要あり
障害時と、非障害時の違い(差分)は把握しているか	比較して出た差分が障害の引き金になっている可能性がある。比較すべき点は以下のようなものがある。時間帯発生場所稼働時間ハードウェア (CPU、メモリ、ストレージなどのスペック) ソフトウェア (バージョンや、設定値など) ハッシュ値
過去の障害実績に類似事象はないか	Redmineのチケットなどに類似の障害対応記録がないか
OSSのバグフィックスやフォーラムなどに類似事象がないか	OSSの公式サイトや、Stack Overflow、teratailなど
原因を判明させる必要があるのか	障害の内容よっては、原因究明をする必要がない場合もある、そもそも調査をする必要があるのかどうか確認が必要がある