「この障害は一部利用者だけなのか、全体に広がっているのか分からない」
「画面は復旧したが、データや後続処理への影響が心配だ」
システム障害では、原因調査と同じくらい影響範囲の把握が重要です。影響が限定的か広範囲かによって、復旧優先度、連絡先、利用者案内、データ補正の要否が変わります。
影響調査を「同じ画面でエラーが出るか」だけで終えると、共通部品、データベース、バッチ、外部連携に残った影響を見落とすことがあります。
金融システムの保守では、画面上はエラーでも更新が完了しているケースや、正常終了に見えて後続処理が止まっているケースがあります。そのため、利用者から見える事象と、システム内部の処理結果を分けて確認します。
この記事では、障害の影響範囲を5つの軸で整理し、数字で報告できる状態にする方法を解説します。
影響範囲は「誰に・何が・いつ・どこまで」を具体化する
影響調査のゴールは、原因を説明することではなく、業務上の影響と必要な対応を判断できる情報をそろえることです。「一部で発生」という表現だけでは、優先度を決められません。
現時点の確認範囲を明示し、件数、対象期間、対象機能を更新し続けます。未確定の情報は、確定情報と分けて扱います。
| 軸 | 主な確認内容 | 参照する情報 |
|---|---|---|
| 利用者 | 全体か、特定の権限・拠点・端末か | 問い合わせ、認証情報、アクセスログ |
| 機能 | 単一機能か、共通API利用機能にも及ぶか | 機能一覧、構成図、アプリログ |
| データ | 未更新、二重更新、不整合、欠損がないか | DB、トランザクション、処理結果 |
| 時間 | 開始・終了時刻と対象期間はいつか | 監視、ログ、取引時刻 |
| 外部連携 | 後続バッチ、帳票、通知、他システムへの影響 | IF一覧、ジョブネット、送受信履歴 |
影響範囲を特定する4ステップ
1．最小単位から対象を特定する
まず、事象が確認された利用者、取引、機能、時刻を特定します。取引番号やリクエストIDなど、一件を追える識別子があると、ログとデータをつなぎやすくなります。
対象一件の処理経路をたどり、「どこまでは正常で、どこから異常か」を明確にします。
- 利用者ID・権限・所属
- 取引番号・受付番号
- 対象画面・API・バッチ
- 発生時刻・処理時刻
- 実行ノード・接続先
2．横方向に同条件の対象を探す
次に、同じ条件に当てはまる取引や利用者を抽出します。特定権限、特定ブラウザ、特定ノード、特定データ条件など、再現条件を一つずつ切り分けます。
正常例と異常例を比較すると、条件差が見えやすくなります。比較時は、入力値だけでなくサーバ、時刻、リリース版、接続先も確認します。
3．縦方向に前後・連携先をたどる
画面処理だけでなく、データ更新、メッセージ送信、夜間バッチ、帳票、通知まで処理の前後を確認します。システム構成図、インターフェース一覧、ジョブネットが有効です。
特に非同期処理は、画面が正常でも後から失敗することがあります。キュー滞留、未送信、リトライ中の状態も確認します。
- 前段の入力・受付は正常か
- DBコミットは完了したか
- メッセージやファイルは送信済みか
- 後続バッチの抽出対象になっているか
- 再処理で二重実行にならないか
4．件数・期間・確度を付けて報告する
報告では「全120件中8件」「10時15分から10時27分」「東日本2拠点」のように数字で示します。全件確認が終わっていない場合は、「現時点で確認できた範囲」と確度を添えます。
【影響範囲報告】 確認時刻：10時30分 利用者：東日本2拠点、8利用者 機能：振込受付のみ。照会機能は正常 データ：対象12件中8件が未更新、二重更新なし 時間：10時15分～10時27分 外部連携：後続送信は保留中 未確認：他拠点の対象件数を継続調査
影響調査で使える確認マトリクス
調査対象が多いときは、条件別に正常・異常・未確認を並べます。頭の中だけで管理せず、確認状況をチームで共有します。
対象条件 正常 異常 未確認 確認根拠 一般利用者 ○ - - アクセスログ 承認者 - ○ - 再現試験・APログ 東日本拠点 - ○ - 問い合わせ8件 西日本拠点 - - ○ 確認依頼中 後続バッチ - - ○ 次回起動前に確認
「未確認」を残すことは悪いことではありません。未確認である事実と、誰がいつまでに確認するかが共有されていれば、判断材料になります。
よくある失敗と改善方法
| 失敗 | 起こる問題 | 改善方法 |
|---|---|---|
| 画面だけを確認する | DBや後続処理の不整合を見落とす | 処理経路を前後へたどる |
| 『一部』とだけ報告する | 業務影響と優先度を判断できない | 件数・期間・対象条件を示す |
| 異常例だけを見る | 再現条件を絞れない | 正常例と環境・入力条件を比較する |
若手SE向けチェックリスト
- 対象一件を識別子で追跡した
- 利用者・機能・データ・時間・連携の5軸で確認した
- 正常例と異常例を比較した
- 共通部品を利用する他機能を確認した
- 画面結果とDB更新結果を突き合わせた
- 非同期処理と後続バッチを確認した
- 件数・期間・確度を付けて報告した
まとめ：影響範囲は5つの軸と数字で説明する
障害の影響調査は、同じエラーが出る範囲を探すだけではありません。利用者、機能、データ、時間、外部連携を横断して確認する必要があります。
最初から全体像が分からなくても、確認済みと未確認を分け、情報を更新し続ければ、責任者は段階的に判断できます。
- 一件の処理経路から調査を始める
- 横方向と縦方向へ影響を広げて確認する
- 件数・期間・確度を付けて報告する
コメント