AS400障害報告書テンプレート｜原因・影響・対応・再発防止を現場目線で整理する

AS400 / IBM i の障害対応後は、復旧して終わりではありません。なぜ起きたのか、どこに影響したのか、何をしたのか、再発防止として何を変えるのかを残すことで、次の障害を減らせます。

障害報告書に入れる項目

障害報告では、ジョブがMSGWで止まった、CPFエラーが出た、ロック待ちになったという技術原因だけでなく、なぜ検知が遅れたのか、なぜ手順がなかったのか、なぜ担当者しか分からなかったのかも整理します。

「注意する」だけでは再発防止になりません。MSGW監視を追加する、再実行手順を作る、問い合わせテンプレートを変える、月次点検に入れる、若手へ教育するなど、実行できる項目にします。

Codexには、匿名化した発生時刻、対象業務、確認項目、対応履歴を渡すと、報告書のたたき台を作りやすくなります。実データや顧客名は入れず、最終確認は人が行います。

関連: AS400在庫差異の調べ方｜在庫照会・入出庫履歴・締め処理から原因を見るもあわせて確認してください。

関連: AS400請求金額不一致の調べ方｜請求締め・売上・消費税・再計算で見ることもあわせて確認してください。

関連: AS400出荷データ二重送信・未送信の調べ方｜出荷確定・EDI・FTP連携を確認するもあわせて確認してください。

障害直後は原因を急いで断定せず、時系列と確認済みの事実を先に固定します。次のように分けると、途中報告でも誤解を減らせます。

復旧後は、応急対応で変えた設定やデータ、戻しの要否、再発防止の担当と期限を追記します。最終報告でも、確認できなかった事項は未確認のまま明示します。

途中報告を更新するたびに、更新時刻、追記者、変更した項目を残します。復旧見込みは判明した事実と前提条件を添え、確定時刻のように書きません。関係部署への次回連絡時刻も明記します。原因が変わった場合は前の記述を消さず、訂正理由を残します。

障害報告書は、原因を責めるためではなく、再発防止と引き継ぎのために残します。AS400の障害では、発生時刻、影響業務、対象ジョブ、メッセージID、一次対応、復旧確認を分けて書くと、後から読み返しやすくなります。