「障害が起きた。まず原因を探さなければ」
「ログにエラーがあったので、すぐ設定を直したほうがよいだろうか」
システム障害が発生すると、早く復旧させたい気持ちから、すぐに原因調査や修正へ進みたくなります。しかし、現場で最初に必要なのは、慌てて手を動かすことではありません。状況を正確に把握し、影響の拡大を防ぎ、チームで判断できる状態をつくることです。
私も銀行システムの開発・保守に25年以上携わるなかで、障害対応の難しさを何度も経験してきました。障害の規模が大きいほど、技術力だけでなく、事実を整理する力、関係者へ共有する力、変更を慎重に管理する力が重要になります。
この記事では、システム障害対応の基本を次の3段階に分けて解説します。
- 初動で事実を押さえ、影響の拡大を防ぐ
- 影響範囲を軸に分けて確認する
- 再発防止を原因分析だけで終わらせない
障害対応で大切なのは「復旧の速さ」と「判断の安全性」
障害対応では速さが求められますが、確認せずに設定変更やデータ更新を行うと、別の障害を発生させるおそれがあります。特に本番環境では、一つの操作が利用者や後続処理へ広く影響する可能性があります。
そのため、対応中は次の4つを意識します。
| 観点 | 確認すること | 目的 |
|---|---|---|
| 事実 | いつ、どこで、何が起きたか | 推測による誤判断を防ぐ |
| 影響 | 誰に、どこまで影響しているか | 対応の優先度を決める |
| 変更 | 直前に何が変わったか | 原因候補を絞る |
| 記録 | 誰が、何を、いつ実施したか | 引き継ぎと振り返りに使う |
原因が分からない段階でも、確認できた事実は共有できます。「原因不明なので報告できない」ではなく、分かっていることと分かっていないことを分けて伝えるのが基本です。
1．初動で事実を押さえ、影響の拡大を防ぐ
障害発生直後は情報が少なく、状況が変化しやすい時間帯です。最初から原因を断定せず、発生事象、時刻、対象、再現性を確認します。
最初に確認する5つの項目
- 発生時刻：いつから発生し、現在も継続しているか
- 発生箇所：どの画面、処理、サーバ、ジョブで起きたか
- 事象：利用者から何が見え、ログに何が記録されたか
- 再現性：毎回発生するか、特定条件だけで発生するか
- 直前の変更：リリース、設定変更、データ更新、外部環境の変化があったか
利用者の申告内容は重要ですが、そのまま技術的な事実と決めつけないことも大切です。「画面が固まった」という申告でも、実際には通信タイムアウト、処理遅延、ブラウザ側の問題など複数の可能性があります。申告内容とシステムで確認した事実を分けて記録します。
証拠を残してから変更する
再起動や設定変更で一時的に復旧しても、変更前の状態を残していなければ原因を追えなくなることがあります。可能な範囲で、対象時刻のログ、監視情報、プロセス状態、接続数、エラーメッセージなどを保存します。
ただし、サービス停止が続き、事前に定めた復旧手順をすぐ実施すべきケースもあります。証拠保全と復旧のどちらを優先するかは、影響度や運用ルールに従い、責任者と判断します。
初回報告は短く、事実中心にする
「10時15分から、振込受付画面でエラーが発生しています。3件で同じ事象を確認し、現在も継続中です。対象ログを保全し、他画面への影響を確認しています。次回は10時30分に状況を共有します」
原因を無理に付け加える必要はありません。発生事象、現在の影響、実施中の対応、次回報告時刻が分かれば、関係者は次の行動を考えられます。
2．影響範囲を軸に分けて確認する
障害対応では、原因調査と同じくらい影響範囲の確認が重要です。影響が限定的なのか、他の利用者や後続処理へ広がっているのかによって、連絡先や復旧の優先順位が変わります。
利用者・機能・データ・時間・連携の5軸で見る
| 確認軸 | 確認例 |
|---|---|
| 利用者 | 全利用者か、一部の利用者・権限・拠点だけか |
| 機能 | 対象機能だけか、共通部品を使う他機能にも及ぶか |
| データ | 参照不可か、未更新・二重更新・不整合があるか |
| 時間 | いつからいつまでの処理や取引が対象か |
| 外部連携 | 連携先、バッチ、帳票、通知、後続システムへ影響するか |
一つの画面だけで発生しているように見えても、共通APIやデータベースを利用する別機能にも影響している場合があります。システム構成図、設計書、ジョブネット、インターフェース一覧などを使い、つながりを確認します。
件数と対象を数字で示す
「一部で発生しています」だけでは、影響の大きさを判断できません。可能な範囲で「全120件中8件」「10時15分から10時27分まで」「東日本の2拠点」と具体化します。まだ確定していない場合は、「現時点で確認できた範囲」と添えます。
特にデータ更新を伴う処理では、画面上のエラーだけで判断せず、データベースで処理結果を確認します。エラー表示があっても更新済みの場合や、正常終了に見えても後続処理が失敗している場合があるためです。
3．再発防止を原因分析だけで終わらせない
復旧すると障害対応は一段落しますが、そこで終わりではありません。なぜ起きたのか、なぜ事前に防げなかったのか、なぜ影響が広がったのかを振り返り、実行可能な対策へつなげます。
直接原因と背景要因を分ける
直接原因が「設定値の誤り」だったとしても、再発防止を「次から注意する」だけにすると、同じ種類のミスが起きやすくなります。なぜ誤りを検出できなかったのかまで掘り下げます。
- 設定値の定義が設計書と手順書で一致していたか
- レビュー観点に環境差分の確認が含まれていたか
- 本番相当条件のテストを実施できていたか
- 監視で異常を早期検知できたか
- 復旧手順と連絡ルートが明確だったか
予防・検知・影響軽減の3方向で考える
| 対策の方向 | 目的 | 例 |
|---|---|---|
| 予防 | 同じ問題を発生させない | 入力チェック、自動化、レビュー観点追加 |
| 検知 | 発生後すぐに気付く | 監視追加、閾値見直し、アラート改善 |
| 影響軽減 | 発生時の影響を小さくする | 切り戻し手順、縮退運転、リトライ制御 |
対策には、担当者、期限、確認方法を設定します。「監視を強化する」ではなく、「対象エラーを検知する監視を追加し、テスト環境で通知を確認する」と具体化すると、完了を判断できます。
障害対応で避けたい3つの失敗
1．原因を早く決めつける
最初に見つけたエラーが原因とは限りません。別処理の結果として出力されたエラーの場合もあります。事実、仮説、未確認事項を分け、仮説はログやデータで検証します。
2．記録せずに複数人が操作する
誰が何を変更したか分からなくなると、状態の把握が難しくなります。作業責任者と記録担当を決め、実施時刻、操作、結果を時系列で残します。
3．復旧と解決を同じだと考える
再起動などでサービスが戻っても、原因が残っていれば再発する可能性があります。「暫定復旧」「原因特定」「恒久対応」を分けて管理します。
障害対応の記録テンプレート
【発生事象】 発生時刻： 対象機能・環境： 利用者から見える事象： 【確認した事実】 ログ・監視： 再現性： 直前の変更： 【影響範囲】 利用者・件数： 機能・データ： 外部連携・後続処理： 【対応状況】 実施した操作と時刻： 結果： 次回報告時刻： 【未確認・判断依頼】 未確認事項： 責任者に判断してほしいこと：
若手SE向け障害対応チェックリスト
- 発生時刻、対象、事象、再現性を確認した
- 原因を断定せず、事実と仮説を分けた
- 変更前にログや監視情報を保全した
- 利用者、機能、データ、時間、連携の各軸で影響を確認した
- 操作内容と結果を時系列で記録した
- 暫定復旧と恒久対応を分けて管理した
- 再発防止策に担当者、期限、確認方法を設定した
まとめ：障害対応は事実をつないで安全に前へ進める
システム障害対応では、原因を早く当てることよりも、確認できた事実を積み上げ、影響を見極めながら安全に判断することが大切です。
- 初動では事実確認、証拠保全、早期共有を行う
- 影響範囲は利用者、機能、データ、時間、連携の軸で確認する
- 再発防止は予防、検知、影響軽減の3方向で具体化する
若手のうちは、一人で復旧方針を決める必要はありません。分かったこと、分からないこと、判断してほしいことを整理し、責任者と連携して進めましょう。
コメント