LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

夜中に監視の画面へエラーが出た。待機系に切り替わったように見えるが、確信は持てない。障害発生の直後は、こうした曖昧な状況から始まることが少なくありません。開発要員の初動とは、異常に気づいてから、状況を判断できる人へ伝え、記録を残して回復の作業に入り、利用者への知らせを始めるまでの最初の対応を指します。

本記事では、IPA（情報処理推進機構）が公開している「情報処理システム高信頼化教訓集（ITサービス編）」の3つの事例をもとに、社内と外部の開発要員が初動で何をし、誰が何を決めるかを整理します。復旧までの時間を約束するための手順ではありません。報告が遅れる、記録が消える、社外から状況が見えない、という3つのつまずきを避けるための決めごとです。

障害発生時の初動とは

初動に含まれるのは、異常に気づくこと、状況を判断できる人へ伝えて協議すること、回復の作業の前に記録を取ること、回復の作業そのもの、そして機能を止めている間の知らせの5つです。開発要員は、システムの構成やログを知っている人として、目の前の症状が何を意味するのかを読み解きます。一方で、業務を止めるか、上の役職へ報告するか、社外に何を伝えるかは、社内の判断する立場の人が決めます。

手がかりにするIPAの教訓集は、社会に影響を与えたシステムの障害事例を分析し、そこから導いた教訓をまとめたものです。IPAによると、この事業は2013〜2019年度に実施され、教訓集は2019年3月15日に公開されました。^*4 各教訓は、問題、原因、対策、効果、教訓の順に書かれています。初動の決めごとを考える材料になります。

取り上げるのは3つの教訓です。教訓G4は気づいたことの報告、教訓T25は回復の前に取る記録、教訓T24は機能を止めている間の知らせを扱っています。順に見ていきます。

報告が遅れた事例（G4）

教訓G4のA社では、オンラインサービスのシステムが現用と待機の2つのノードで二重化されていました。運用は子会社に委託されており、子会社の担当者が異常を見つけると、保守ベンダーに解析を頼み、その結果を本社の運用部門に伝え、本社の運用部門は重大な場合にだけ経営層（CIO）に報告する手順がマニュアルに書かれていました。^*1

ある日の夜間のバッチ処理中に、1台の現用ノードでメモリコントローラの障害が起きました。子会社の担当者は診断レポートを出し、保守ベンダーのSEに電話と電子メールで伝えました。SEは待機ノードが正常に動いていると判断し、切り替えは成功しているとの見解を返しました。運用部門の統括責任者は当日の業務への影響はないと判断して対応を終え、経営陣には報告しませんでした。翌日の未明に一部の情報が配信できないことが分かり、CIOに連絡が取れたのは翌日の朝で、午前中のオンラインサービスは止まりました。^*1

原因として教訓集が挙げているのは、まず保守ベンダーのSEによる診断レポートの誤認です。ただ、子会社の担当者は、待機ノードに処理が引き継がれていないらしい状況に気づいていました。それをSEに伝えなかったことが、判断を誤らせました。運用部門も自分でシステムの状態を確かめず、報告をもとに問題なしと判断しています。

開発の現場でも同じことが起こり得ます。外部から加わっている開発要員が、ログの出方がいつもと違うと気づいても、手順書に書かれていない連絡はしにくいものです。

誰が状況を判断するのか

A社が再発防止策として最も重く見たのは、運用の担当者が現場で異常に気づいたら、状況を判断できる運用部門の社員にその情報を伝えて協議する態勢を作り、それをオペレーションのマニュアルに書くことでした。^*1 あわせて、障害と断定できなくても可能性があれば早めに上の役職者へ報告するルールを作り、判断できる社員がセンターに24時間いる体制にし、確認の項目や、エスカレーション（上位への報告）を管理する台帳も整えています。

このうち初動の決めごととして生かしやすいのは、報告の基準を「断定できたら」から「可能性があれば」へ下げることです。断定を待つと、判断の材料を持っている人ほど黙ってしまいます。下の表は、事例をもとに初動での役割を分けてみたものです。

外部の開発要員は、ログや構成から見立てを出し、その根拠を添えて伝えます。影響なしとして閉じる判断は、社内の判断する担当者が持ちます。判断を外部の人に預けると、A社のように、伝えられた結論だけで対応が終わってしまいます。なお、24時間の常駐はA社が選んだ対策で、どのシステムにも同じ体制が要るとは限りません。夜間や休日に誰へ連絡するかを決めておくことが先です。

回復の前に残す記録（T25）

教訓T25のA社は、社内向けと顧客向けの情報公開などを担う社内共通の基盤システムを持っていました。業務の性格から、銀行のオンラインのような高い水準の即時の回復は求められていなかったシステムです。ある朝、業務の画面から応答がなくなり、仮想化したPCはすべて動かなくなり、社外とのメールも送受信できなくなりました。社内のシステム管理者はスイッチなどの基盤の装置を疑い、各層のスイッチを調べてコマンドで再起動しましたが、17時になって当日の業務の再開をあきらめました。^*2

その後の全面的な再調査で、午前中に再起動したはずの集約スイッチの状態を示すLEDの点き方が、ふだんと違うことが分かりました。電源コードを抜いて物理的に再起動したところ通信が戻り、当日の22時ごろにシステムは正常に動き始めました。

ところが原因は確定しませんでした。教訓集は特定できない理由として、障害が起きたときの通信の内容を取れていないこと、前後の時間帯に障害を示すログが出ていないこと、機器の開発元でも過去の事例から類推するのが限度であることを挙げています。^*2 回復を急いだ結果、原因を確かめる材料が残らなかった形です。

A社は対策の一つとして、再発したときに原因の調査用に最低限取るログを選び、回復の処置をする前に短時間で取れる手順を作りました。教訓集は、障害が起きたときの対応では「即時復旧と再発防止のバランスの考慮が必要」としています。^*2 何を取るかは、システムの中身を知っている開発要員に選んでもらうのが近道です。取る時間を短くしておけば、回復を長く待たせずに済みます。取った記録をもとに原因の調査を頼む流れは外部エンジニアに不具合の原因調査を頼む手順で扱っています。

切り分けの基準を文書にする

T25のA社は、記録の手順のほかにも、再発したときの備えを文書にしています。同じ事象が起きたときに、スイッチのLEDが異常かどうかの判断が対応する人によって変わらないよう、正常に動いているときの点き方を書き残しました。異常と判断できた場合の電源の切断から再起動、正常に戻ったかの確認、戻らなかったときの機器の切り離しまでを、間違えずに進められるよう手順にしています。^*2

これらは既存の障害対応のマニュアルに加え、印刷して設備の近くに置きました。その際、基準に当てはまらない場合や手順どおりでも戻らない場合の対応、機器の製造元への連絡といったルールも足しています。

開発要員に頼むなら、「正常なときはどう見えるか」を書いてもらうのが効きます。画面やログやメトリクスの平常の姿が分かっていれば、初めて対応する人でも異常かどうかを同じ物差しで判断できます。手順書に書く項目の全体は運用保守の障害対応手順整備にまとめました。

教訓集はまた、稼働への要求はシステムごとに異なり、再発の危険が残っても直ちに業務を戻す必要があるシステムもあれば、原因の調査を綿密にして再発させないことが最優先のシステムもあるとしています。^*2 初動で記録にどこまで時間をかけるかは、障害発生の前に、社内でシステムごとに決めておくことです。

縮退中に社外へ知らせること（T24）

教訓T24のA社の統合システムでは、3台で組んだデータベースのサーバーが順に止まり、全台が停止しました。原因が分からないまま1台だけ動かすと、性能に問題はあるもののサービスを続けられました。そこで情報提供の業務を止め、基幹の業務だけを続けました。窓口はシステム部門と状況を確かめながら業務を進められましたが、データ連携先の会社は情報を受け取れず自社の業務を進められませんでした。インターネットから使う顧客も、電話で窓口に聞くしかありませんでした。窓口は社外からの対応に追われ、混乱は終日続きました。^*3

停止の直接の原因はデータベースのサーバーのソフトウェアのバグでした。教訓集は、縮退（機能を絞って動かすこと）になったとき、対外のシステムや利用者に「障害情報と復旧見込み」などを発信できなかったことが影響を大きくしたとし、根本原因を、縮退が長引くと問題が大きくなることを見逃していた点に置いています。^*3

初動に引き寄せると、機能を止めると決めるときに、その機能を使っている社外の相手を同時に書き出すことになります。止める機能に頼っている連携先や画面は、構成を知る開発要員が挙げられます。誰がどの手段で知らせるかは社内で決めます。復旧の見込みを伝えるときは、確かでない時刻を約束せず、次にいつ知らせるかを伝える形が扱いやすいでしょう（この記事の考え方）。

外部の開発要員に頼む前の確認

障害発生時の初動に外部の開発要員に加わってもらうなら、どこまで応じてもらえるかを契約と提供範囲で先に確かめます。夜間や休日の連絡を受けるか、どの時間帯に応答するか、現地に来るかどうか、本番の環境でどこまで操作してよいかといった点です。即時の復旧や駆けつけは、相手の提供範囲と契約で確かめる対象で、前提として置くものではありません。到着までの時間の決め方は開発要員の初動、保守員とSEの到着時間を分けて決めるで扱っています。

あわせて、初動で使うものを渡しておきます。気づいたことを伝える相手と連絡の手段、回復の前に取る記録の手順、正常なときの状態を書いた資料の3つです。どれも社内で持っておき、参画する人が替わっても同じものを渡せるようにします。

ここまでの決めごとが書き出せれば、初動に加わってもらう人に求める経験もはっきりします。ログや構成を読んで見立てを言葉にできることは、その中でも大事な条件の一つです。

まとめ：障害発生の初動で確かめておきたい3つの点

障害発生時の初動で、開発要員と社内の役割を決めるうえで確かめておきたい点は3つです。第一に、断定できない異常でも、気づいた人がすぐ状況を判断できる社員へ伝えて協議する決まりがあること。第二に、回復の作業の前に、原因の調査に要るログを短時間で取る手順があること。第三に、機能を止めて縮退で動かすとき、止めた機能を使う社外の相手と、知らせる役の人が決まっていることです。この3点を押さえておけば、報告が遅れる、記録が消える、社外から状況が見えない、というつまずきを避けやすくなります。初動に加わってもらう人の探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：IPA「情報処理システム高信頼化教訓集（ITサービス編）」2.4 障害発生時連絡の情報共有に関する教訓（G4）（PDF）（https://www.ipa.go.jp/archive/files/000049531.pdf）。出典：問題（A社の二重化構成・運用手順・障害の経緯）、原因（①〜④）、対策（①〜⑤）、効果、教訓を参照（確認日2026年10月2日）（2026年10月確認）
2. *2　参考：IPA「情報処理システム高信頼化教訓集（ITサービス編）」3.25 原因不明障害への対応に関する教訓（T25）（PDF）（https://www.ipa.go.jp/archive/files/000057347.pdf）。出典：問題（社内共通基盤の停止と回復の経緯）、原因（原因を特定できない理由(1)〜(3)）、対策（対策1・対策2の(1)〜(4)）、教訓(2)(3)を参照（確認日2026年10月2日）（2026年10月確認）
3. *3　参考：IPA「情報処理システム高信頼化教訓集（ITサービス編）」3.24 障害中の運用に関する教訓（T24）（PDF）（https://www.ipa.go.jp/archive/files/000056978.pdf）。出典：問題（統合システムのDBサーバーの停止と縮退運転）、原因（直接原因と根本原因）を参照（確認日2026年10月2日）（2026年10月確認）
4. *4　参考：IPA「情報処理システム高信頼化教訓のリンク集（ITサービス編）」（アーカイブ）（https://www.ipa.go.jp/archive/digital/iot-en-ci/system/lesson.html）。出典：事業の実施期間（2013〜2019年度）、教訓集（ITサービス編）の公開日（2019年3月15日）、教訓一覧を参照（確認日2026年10月2日）（2026年10月確認）

Tweet