AS400本番障害の初動対応チェックリスト｜環境確認・影響範囲・ジョブログ調査の順番

AS400 / IBM i の本番障害で一番大事なのは、最初の数分で焦って変な作業をしないことです。本番で障害が起きると、早く直したい気持ちが先に出ます。ですが、環境を見ずにコマンドを打つ、ジョブログを見ずにジョブを止める、MSGWにDやGを返す、SQLで対象ライブラリを間違える、といった初動ミスは二次災害につながります。

このページでは、AS400の本番障害が起きた時に、まず何を確認し、どの順番で調査するかをチェックリスト形式で整理します。販売管理システムのように、受注、出荷、在庫、売上、請求、店舗連携、物流連携がつながっている現場では、技術的なエラーだけでなく業務影響を見ながら判断する必要があります。

本番障害の初動で見る順番

自分が本番対応で最初に確認する順番は、作業者、バックアップ、環境です。誰が何をするかを明確にして、必要なバックアップや戻し方を考え、最後にライブラリリストや対象ファイルなどの環境を確認します。ここを飛ばす人は危ないです。

順番	確認項目	見る理由	関連記事
1	作業者	誰が何を実行するかを明確にする	本番対応の注意点
2	バックアップ	失敗時に戻せる状態か確認する	データリカバリー確認手順
3	環境	本番/テスト、ライブラリリスト、対象ファイルを間違えない	ライブラリ確認
4	影響範囲	受注、出荷、在庫、外部I/Fなど業務影響を見る	夜間バッチ障害対応
5	ジョブログ	原因メッセージと結果メッセージを分けて読む	ジョブログ確認手順
6	MSGW	D/Gなど危険な返答を勝手に返さない	MSGW返答判断表

1. まず作業者を決める

本番障害では、複数人が同時に触ると危険です。誰が画面を見るのか、誰がジョブログを確認するのか、誰が顧客や現場へ連絡するのか、誰が実行担当なのかを決めます。作業者が曖昧なまま進めると、同じジョブを二重に再実行したり、別の人が先にメッセージを返したりすることがあります。

若手に任せる場合でも、最初から単独で本番を触らせるのは避けた方が安全です。画面右上のマシン名を見ていない、本番とテストを勘違いする、F4で入力内容を確認しない、といったミスは実際に起こります。まずは上長やメンバーと作業範囲を合わせます。

2. 本番環境とテスト環境を間違えない

本番対応で一番怖いのは、環境を間違えることです。テスト環境だと思って本番でCLRPFMを実行する、逆に本番だと思ってテスト環境を見て「データがない」と判断する、といったミスは致命的です。画面右上のシステム名、ジョブ情報、ライブラリリスト、対象ファイルを確認します。

確認例:
DSPLIBL
WRKOBJ OBJ(TESTLIB/TEST001R) OBJTYPE(*PGM)
DSPFD FILE(TESTLIB/TESTFILE)
DSPFFD FILE(TESTLIB/TESTFILE)

特にSQLでデータ修正する時は、指定するライブラリ名が一番怖いです。目視確認しかない場面もありますが、だからこそ実行前にメンバーと手順をレビューします。自分だけで「たぶん合っている」と判断しない方が安全です。

3. 影響範囲を先に見る

本番障害では、技術的な原因調査と同時に、業務影響を見ます。販売管理システムなら、まず受注系、発注系、出荷系が動くかを確認します。バックオフィス系は後回しにできることもありますが、商品がお客様に届くところ、外部連携が止まるところは優先度が高いです。

業務領域	止まると怖いこと	初動で見ること
受注	注文処理や出荷指示に影響する	受注データ作成、後続バッチ、I/F
出荷	物流側へデータが渡らない	出荷指示、帳票、物流連携
在庫	引当や在庫数に差異が出る	在庫引当、更新件数、対象ファイル
売上・請求	計上や請求に影響する	二重計上、未計上、会計連携
外部I/F	相手先や店舗に影響する	送受信履歴、再送可否、連携ファイル

障害時にできるPMは、まず状況を確認して、止血を暫定対応で止め、後で本格対応へ持っていきます。だめな対応は、その場しのぎで変な処置をして、あとで二次災害につなげることです。

4. ジョブログで原因を追う

障害調査では、ジョブログを見ます。最後に出ているエラーだけで判断せず、重大度、メッセージID、プログラム名、ファイル名、ライブラリ名、エラー前後の流れを確認します。CPF、RNX、MCHなどの種類を見て、どこで落ちたのか、なぜ落ちたのかを追います。

見るポイント:
・ジョブ名 / ユーザー / 番号
・メッセージID
・重大度
・プログラム名
・対象ファイルとライブラリ
・エラー直前の処理

原因メッセージと結果メッセージを分けることが大切です。最後に出ているエラーが本当の原因ではなく、その前に出ているファイルオープンエラー、数値エラー、権限エラー、ロックなどが原因になっていることがあります。

ジョブログの具体的な読み方は、AS400のジョブログ確認手順 と AS400ジョブログ実例集 にまとめています。

5. MSGWは勝手に返さない

本番障害でMSGWが出ている時は、返答がその後のリカバリーに影響します。Cはキャンセル、Iは無視、Rはリトライ、Dはダンプを取ってキャンセル、Gは後続へ進める系の危険な返答です。特にDやGは、リトライで復旧できた可能性を消したり、落ちた処理を強引に進めたりすることがあります。

MSGWを見つけた若手には、まず上長に報告させます。焦って勝手にDを返す、4番でジョブを強制終了する、といった対応は避けます。メッセージをどう返すかは、ジョブログ、業務影響、再実行可否を見たうえで判断します。

6. データリカバリーが必要か判断する

本番トラブルでは、データリカバリーが必要になることがあります。まず見るのは影響範囲です。対象ファイルは何か、どこまでデータが作られたか、後続処理が動いたか、再実行できるか、SQL修正が必要かを考えます。

リカバリー作業では、手順を箇条書きにしてメンバーに見てもらいます。全部重要です。SQLで修正するなら、更新先のライブラリを絶対に確認します。ファイル丸ごとバックアップを取る場合もあれば、リハーサル済みでバックアップを取らない場合もありますが、いずれにしても「戻せるか」「二重処理にならないか」を確認します。

本番障害の初動チェックリスト

チェック	確認内容
作業者	誰が画面操作し、誰が確認し、誰が連絡するか決めたか
環境	本番/テスト、システム名、ライブラリリストを確認したか
対象	対象プログラム、対象ファイル、対象ライブラリを確認したか
影響範囲	受注、出荷、在庫、外部I/F、翌日業務への影響を見たか
ジョブログ	最後のエラーだけでなく、前後の流れを見たか
MSGW	D/Gを勝手に返していないか
再実行	再投入して二重処理にならないか確認したか
リカバリー	更新内容、戻し方、レビュー担当を決めたか
共有	ジョブ名、ユーザー、番号、メッセージID、判断内容を共有したか

若手に伝えたいこと

本番対応で若手に伝えたいのは、「焦るな。落ち着け」です。手が滑って変なことをしそうな時ほど危ないです。単体テストを怠るな、納品先は上司ではなくエンドユーザーを意識しろ、運用を意識した作りにしろ、という話と同じで、本番対応も最終的には業務を止めないために行います。

AS400は古臭い画面に見えるかもしれませんが、基幹システムの心臓部として動いていることがあります。だからこそ、本番障害では派手な対応よりも、環境確認、影響範囲確認、ジョブログ確認、レビュー、落ち着いた実行が大切です。

関連して読む記事

• AS400本番対応の注意点
• AS400夜間バッチ障害対応フロー
• AS400のデータリカバリー確認手順
• AS400のジョブログ確認手順
• AS400 MSGW返答判断表
• AS400メッセージID・エラーコード一覧