サーバー電源トラブルシューティング実例編

※本記事は、サーバー電源トラブルに関する一般的な技術情報であり、特定のメーカー・製品・案件を断定的に評価するものではありません。実際のシステム設計・保守・障害対応では、ご利用中の機器マニュアルや契約条件を必ず確認し、必要に応じて専門家と協議した上で判断してください。

『たまに落ちるサーバー』というバグ報告から始まった電源トラブル調査

プログラマーの視点から見ると、「たまに落ちるサーバー」という報告ほど扱いに困るものはありません。再現条件が分からず、ログにも決定的な証拠が残らないためです。多くの場合、最初はアプリケーションやミドルウェアのバグとして疑われますが、実際には「電源まわり」が根本原因になっているケースが少なくありません。

ここでいう「サーバーが落ちる」とは、次のような現象を指します。

• OSごと突然再起動する（イベントログには「予期しないシャットダウン」とだけ残る）
• 一部のノードだけがクラスタから離脱し、その直前のアプリログには異常が見当たらない
• ストレージやネットワークにはエラーが残っておらず、ハードウェア自己診断も「正常」と報告する

アプリケーションバグであれば、通常は次のような痕跡が残ります。

• 例外スタックトレース
• メモリ不足やハンドル不足の警告
• 異常終了時に出力されるダンプファイル

しかし電源起因のトラブルでは、OSやアプリケーションにログを書き出す時間的余裕がないまま、ハードウェアレベルで電源が遮断されることがあります。その結果として、プログラマーから見ると「何もログが出ていないのに再起動している」不可解な状態になります。

ここで重要なのは、「ログがない = 何も起きていない」ではない、ということです。特に電源系の異常は、OSより下のレイヤーで完結してしまうため、アプリケーションのログだけを眺めていても原因にたどり着けないことが多くあります。

本記事では、典型的な電源トラブルの実例パターンをもとに、「プログラマーが納得できる説明」を軸に、原因の洗い出し方・再現条件の整理・設計へのフィードバック方法を整理していきます。最初の章では、あくまで症状の見え方をプログラマー視点で共有し、「これはアプリのバグではないかもしれない」という違和感を読者とそろえるところまでをゴールとします。

以降の章では、この違和感を手がかりに、ログ・監視・電源イベントをどう関連付けていくか、どのようにモデル化すれば論理的に説明できるか、段階的に掘り下げていきます。

ログにも監視にも「異常なし」──プログラマー視点で違和感を覚えた条件分岐

電源トラブルの厄介な点は、「監視システムも含めて『異常なし』と報告してしまうケースがある」ということです。典型的には、次のような状況が発生します。

• アプリケーションログ：直前のリクエスト処理まで正常に完了している
• OSログ：突然の再起動として記録されるが、明確な原因イベントが残っていない
• 監視システム：CPU・メモリ・ディスク・ネットワークなどのメトリクスは閾値内で推移

プログラマーの頭の中では、自然と次のような「条件分岐」が走ります。

• 例外ログがない → アプリケーションは意図的に落ちていない
• OSのシャットダウンログがない → OSも正常終了していない
• 監視アラートがない → リソース逼迫やプロセス死亡ではなさそうだ

この条件分岐をすべて満たすと、「では何がトリガーなのか？」という強い違和感が残ります。この違和感自体が、電源トラブルを疑う重要なサインです。

電源系トラブルが疑われるとき、着目すべき情報源は次のレイヤーにまたがります。

多くのシステムでは、アプリケーション〜OSレイヤーのログには敏感でも、BMCやUPS・PDUのログには日常的にアクセスしていないことが少なくありません。そのため、プログラマーの視界に入る情報だけを見ていると、「何も起こっていないのにサーバーが落ちている」という矛盾した印象が強まります。

ここでのポイントは、「観測しているレイヤーに合わせて、暗黙の前提条件が組み込まれている」という事実です。アプリケーション側のコードには、「電源は常に安定している」「OSは動作し続けている」という前提が暗黙の仕様として埋め込まれていることが多く、その前提が崩れると、コード上では説明できない現象に見えてしまいます。

この章では、「ログにも監視にも異常がないのにサーバーだけが落ちている」という違和感を、プログラマー視点の条件分岐として整理しました。次の章では、この違和感を一歩進めて、「再現条件」をアプリのテストケースではなく「電源イベント」として整理し直すアプローチについて解説します。

再現条件を「テストケース」ではなく「電源イベント」として書き出してみる

プログラマーは日常的にテストケースを書きます。しかし電源トラブルの再現条件は、「入力値」と「期待値」だけでは表現しきれません。そこで発想を少し変え、「電源イベントのシーケンス」として再現条件を書き出すと、原因の切り分けが進むことがあります。

まず、よくある電源関連イベントを列挙します。

• 商用電源の瞬低（数十ミリ秒〜数百ミリ秒の電圧低下）
• 完全な停電（数秒以上の給電停止）
• UPSから商用電源への切り戻し時の瞬断
• PDUやラック内ブレーカーの落ち／復帰
• 冗長電源の片系だけが抜ける・故障する

次に、これらのイベントと「サーバーの状態遷移」を紐付けて、時系列シナリオとして整理します。例えば、次のような観点です。

• どの時間帯に発生しているか（ビルの負荷変動と関連がないか）
• 特定のラック・系統に偏っていないか
• 瞬低後に必ず落ちるのか、それとも負荷が高いときだけ落ちるのか
• クラスタ構成の場合、プライマリ側だけ／セカンダリ側だけが落ちていないか

ここで、テストケース風に書くのではなく、「電源イベントシナリオ」として書き出す例を示します。

このように、電源イベント側からシナリオを組み立てていくと、「どのレイヤーで何が起きているか」が見えやすくなります。重要なのは、再現条件の表現方法をアプリケーション寄りから電源寄りにシフトさせることです。

プログラマーがこの作業に関わるメリットは、「原因がアプリ外にあると分かった瞬間に調査をやめる」のではなく、「アプリから見えている現象を、電源イベントのタイムラインにマッピングし直す」ことで、インフラ担当者や設備管理側と共通の土台で議論できる点にあります。

次の章では、この電源イベントシナリオをさらに構造化し、UPS・PDU・二重化電源などの構成要素を依存グラフとして整理する方法を解説します。これにより、「どの系統が落ちたときに、どのサーバーが影響を受けるか」を論理的に説明できるようになります。

UPS・PDU・二重化電源を依存グラフとしてモデリングする

電源トラブルをプログラマーが理解しやすい形に落とし込むためには、「ハードウェア構成図」を単なる絵として眺めるのではなく、「依存グラフ」として解釈するのが有効です。グラフのノードを電源装置・サーバー・ラックなどの要素、エッジを給電経路として考えると、どこで障害が起きたときにどのサーバーが影響を受けるかを、コードの依存関係を見る感覚で整理できます。

代表的な構成要素は次のように整理できます。

これらをプログラマー視点でモデリングする際には、「どのノードが落ちたときに、どの下流ノードが同時に落ちるか」を、依存関係として一覧化しておくと分かりやすくなります。例えば、次のような簡単な考え方です。

• UPS A が落ちると、PDU A 配下のラック 1〜3 が同時に影響を受ける
• サーバー S1 は、UPS A と UPS B の両方から給電されている（はず）
• しかし現場確認すると、実際には両方とも UPS A 系統につながっていた、などの誤配線がないか

特に注意すべきなのは、「図面どおりの冗長構成」と「実機の配線状態」が一致しているとは限らない、という点です。設計書上は二重化されていても、実際には以下のような状況が現場で発生することがあります。

• 作業時の一時対応が恒久化してしまい、片系に寄ったままになっている
• 新規機器追加時に、空いているコンセントに安易に接続してしまい、系統分離が崩れている
• ラベルや管理台帳が更新されておらず、配線の実態が把握できていない

プログラマーとして関わる場合でも、依存グラフの考え方を共有することで、「このサーバーが落ちたときに、同時に落ちるはずのサーバー群」が見えてきます。もし観測された障害範囲が、そのグラフ上の「1系統分の下流」と一致しているなら、アプリケーションのバグよりも電源系統の問題である可能性が高まります。

次の章では、この依存グラフに「時間軸」を加え、瞬低や再起動タイミングのズレを状態遷移図として捉えることで、より精度の高い原因分析につなげる方法を説明します。

瞬低と再起動タイミングのズレから電源系の状態遷移図を描く

瞬低や停電が発生したとき、サーバー群は一斉に同じ動きをするわけではありません。電源ユニットごとの保持時間、マザーボードの設計、BIOS/UEFI の設定値、ストレージのスピンアップ時間など、さまざまな要素が絡み合うため、「ほぼ同じ構成のサーバーなのに、落ちるものと落ちないものが混在する」という現象が起きます。

この「バラつき」を、プログラマーが理解しやすい形にするには、サーバーを状態遷移マシンとして捉えると分かりやすくなります。典型的には、次のような状態を想定します。

• 状態 S0：通常運転中（商用電源＋UPS 経由で安定給電）
• 状態 S1：瞬低検知（UPS が入力電圧低下を検知し、バッテリー動作に移行するか判断中）
• 状態 S2：保護動作中（電圧が下がるが、電源ユニットの保持時間内で OS はまだ動き続けている）
• 状態 S3：電源喪失（保持時間を超えたサーバーが電源断）
• 状態 S4：再投入・再起動（電源復帰後、BIOS/UEFI の設定に従って自動起動）

重要なのは、「どの状態にどれくらいの時間とどまるか」が、機種ごと・構成ごとに微妙に異なる点です。あるサーバーは S2 から S3 に一気に落ちる一方、別のサーバーは S2 のまま踏みとどまり、瞬低が終わるとそのまま S0 に戻ることがあります。結果として、クラスタや分散システム全体で見ると、次のような現象が発生します。

• 片方のノードだけが S3（電源断）→S4（再起動）に入る
• もう片方のノードは S2 から S0 に戻り続行する
• ストレージだけが一瞬 S3 に落ち、ファイルシステムがジャーナルリプレイを開始する

このようなズレを分析するには、ログの時間を「アプリケーションイベント」だけでなく「電源イベント」とも突き合わせる必要があります。例えば、次のようなテーブルを作ることで、状態遷移を視覚化できます。

このテーブルから分かるのは、「同じ電源イベントに対して、サーバーごとに状態遷移が異なる」という事実です。これは、電源ユニットの設計やコンデンサの容量、BIOS/UEFI の「電源復帰時の動作」設定など、ハードウェア側の仕様差によるものです。

プログラマーとしては、「なぜ A だけ落ちたのか」ではなく、「A と B の状態遷移がどこで分岐したのか」を考えることで、原因をコードではなく電源系にフォーカスしやすくなります。次の章では、この状態遷移に「冗長電源の片系死」や「ファームウェア更新」の要素が絡んだときに、どのような組み合わせで障害が顕在化しやすいかを整理します。

冗長電源の片系死とファーム更新という見落とされがちな組み合わせバグ

多くのサーバーは、電源ユニットを二重化することで、片系の障害に耐えられるように設計されています。しかし、実運用の現場では「冗長電源があるはずなのに、瞬低のたびに特定のサーバーだけが落ちる」というケースが繰り返し報告されています。この背景には、いくつか典型的なパターンがあります。

• 片系の電源ユニットがすでに故障しており、冗長性が失われている
• 両方の電源ユニットが同一系統の PDU に接続されており、系統分離ができていない
• ファームウェア更新のタイミングで片系のみ仕様が変わり、負荷の偏りや挙動差が生じている

特に見落とされがちなのが、「ファームウェア更新による動作差」です。電源ユニットや UPS、PDU のファームウェアは、安定性向上やバグ修正のために更新されることがありますが、次のような状況が起こり得ます。

• 電源ユニット A：旧ファームウェアのまま
• 電源ユニット B：新ファームウェアに更新済み

この状態で瞬低や負荷変動が発生すると、旧ファームと新ファームで保護動作の閾値や応答時間が微妙に異なり、「片系だけが先に保護動作に入る」「片系だけが負荷を過大に背負う」といった状況が生まれます。その結果、表面的には次のように見えることがあります。

• 軽い瞬低のはずなのに、特定のサーバーだけが電源断 → 再起動している
• ログ上は「電源ユニット故障」「過電流保護」などのイベントが片側に偏って出ている

この種の問題を防ぐためには、次のような確認と運用ルールが重要です。

• 冗長電源ユニットのファームウェアバージョンをそろえること
• UPS・PDU 側のファームウェア更新も含め、系統ごとに挙動差が出ていないか検証すること
• 定期点検時に、片系を意図的に遮断しても継続運転できるかを確認すること（計画停止の範囲内で実施）

プログラマー視点では、「どちらかの電源が死んでも落ちないはず」という前提で設計していても、実際には冗長性が失われている場合があります。その結果として、「たまたま瞬低のタイミングで落ちた」ように見える現象が繰り返されることになります。

次の章では、こうした電源ノイズや瞬断が、アプリケーションのタイムアウト設計と組み合わさったときに、どのようにして「単発の電源イベント」が「大規模障害」に発展するのかを、具体的なタイムアウト設定の観点から整理します。

アプリのタイムアウト設計が電源ノイズを大規模障害に変えていた

ここまで見てきたように、電源トラブルそのものは「瞬低」「片系死」「再起動タイミングのズレ」といった物理イベントとして発生します。しかし、最終的にユーザーや業務システムにとって重大な影響となるかどうかは、アプリケーション側のタイムアウト設計やリトライ設計に大きく依存します。

典型的なパターンとして、次のようなシナリオが挙げられます。

1. 瞬低により、バックエンド DB サーバーの一部ノードが再起動に入る
2. アプリケーションサーバーからの接続がタイムアウトし、例外が多数発生する
3. 適切なバックオフなしにリトライを実装していたため、復旧途中の DB ノードにリクエストが殺到する
4. 結果として、瞬低が終わった後も負荷が収束せず、全ノードで性能劣化やスローダウンが連鎖する

ここでは、電源イベント自体は数秒〜数十秒で終わっているにもかかわらず、アプリケーションレベルでは数十分以上のサービス低下が続くことがあります。このような場合、外形的には「アプリケーションの性能劣化」に見えるため、原因分析の初期段階で電源イベントが見落とされることも少なくありません。

タイムアウト設計を見直す際の観点としては、次のようなポイントがあります。

• 接続タイムアウトと処理タイムアウトを適切に分離し、それぞれに意味のある値を設定しているか
• 電源イベントや再起動時に想定されるダウン時間に対して、リトライ・バックオフ戦略が現実的か
• フェイルオーバ時に、一斉にトラフィックが集中しないような制御（サーキットブレーカー等）を導入しているか
• インフラ側の復旧手順と、アプリケーション側の再接続ポリシーが整合しているか

プログラマーとして意識しておきたいのは、「電源は常に安定している」という前提をやめ、「一定の頻度で瞬断やノイズが発生する環境でも、システム全体として破綻しない設計」にシフトすることです。そのためには、タイムアウト値やリトライ回数を「なんとなく安全そうな値」にするのではなく、「電源イベントを含む障害シナリオ」を前提に設計・検証する必要があります。

次の章では、ここまでの原因特定プロセスをそのままテストコードや検証シナリオとして再利用し、「電源イベントを含む障害再現テスト」を仕組み化するアプローチについて解説します。これにより、「たまに落ちるサーバー」の再発を防ぐだけでなく、新しいシステム導入時にも同種のリスクを事前に洗い出せるようになります。

原因特定のシナリオをそのまま障害再現テストコードに落とし込む

ここまでで、「瞬低が起きる」「特定系統の電源が落ちる」「冗長電源の片系が死んでいる」といった電源イベントを、シナリオとして整理してきました。次のステップは、そのシナリオを一度きりの調査メモで終わらせず、「テストコード」や「検証手順」として残すことです。プログラマーが得意とするのは、まさにこの「再現性のある形に落とし込む」作業です。

電源イベントそのものはソフトウェアから直接は制御できませんが、次のような観点でテストケース化・疑似再現が可能です。

• バックエンドサービスや DB を意図的に停止・再起動し、瞬断に相当する状況を作る
• ネットワークレベルで一時的な切断（パケットロス、タイムアウト）を挿入する
• クラスタ構成の一部ノードだけを落とし、フェイルオーバ時の挙動を確認する

これらは、電源トラブルそのものではなく、電源トラブルによって引き起こされる「見かけ上の症状」を再現するテストと言えます。たとえば、次のような表現に落とし込むことができます。

実際のテスト実装では、インフラ担当者との調整が不可欠です。いきなり本番環境で実行することは避け、検証環境やステージング環境で、影響範囲を明確にした上で計画的に行う必要があります。また、「こういう状況が起きると本番では困る」という観点から、インフラ側の制約や想定外の挙動も洗い出されます。

重要なのは、原因特定が終わった後に「原因が分かって良かった」で終わらせないことです。電源イベントに関するシナリオを、次のような形で資産化しておくと、将来のシステム更改やクラウド移行の際にも役立ちます。

• 障害シナリオを整理したドキュメント（タイムライン付き）
• それに対応するテスト手順書、あるいは自動テストコード（可能な範囲で）
• テスト結果と、その結果を受けた設計変更・運用ルール変更の記録

次の章では、こうしたシナリオとテスト結果を、監視・運用フロー、設計ドキュメントにどのように反映させるかを整理します。これにより、「一度解決した電源トラブルを、将来のプロジェクトでも再利用できる知見」として残すことができます。

電源トラブルを前提とした監視・運用フローを「設計ドキュメント」に昇華する

電源トラブルの実例から得られた知見は、監視設定や運用手順だけでなく、「設計ドキュメント」にも反映すべき内容を多く含んでいます。逆に言えば、「電源まわりが設計書に登場しないシステム」は、前提条件の定義が不十分である可能性が高いと言えます。

まず、監視・運用フローの観点から整理すべきポイントを挙げます。

• 電源イベント（停電・瞬低・UPS バッテリー動作）を、どのログ・監視で検知するか
• サーバー単体の再起動と、ラック・系統単位の同時障害をどう区別して扱うか
• 復旧後にどのログを収集・確認するか（BMC、UPS、PDU、ビル側監視など）
• アプリケーション側で必要な対応（再接続、キャッシュクリア、再処理可否の判断）

これらは、運用フロー図や手順書の形でまとめられることが多いですが、設計ドキュメントにも「前提条件」として明記しておくことで、プロジェクトメンバー間の認識をそろえることができます。例えば、次のような表現です。

こうした記述を設計段階で明示しておくことで、障害対応時に「そもそも前提条件が守られていなかったのか」「前提条件どおりだが、設計に不足があったのか」を切り分けやすくなります。また、新しいメンバーがプロジェクトに参加した際にも、「なぜこの監視が必要なのか」「なぜこのタイムアウト値なのか」という背景を共有しやすくなります。

プログラマーにとってのポイントは、電源トラブルを「運用の問題」と切り離してしまうのではなく、アプリケーションの仕様と前提条件として設計書に統合することです。その結果、インフラ担当者との協議も、「どこまでをアプリ側で吸収し、どこからを設備側の責任とするか」という具体的な線引きの議論に進められます。

次の最終章では、「電源もまた仕様の一部である」という観点から、コードとインフラの前提条件をそろえることで、「たまに落ちるサーバー」を減らすための考え方を整理します。そのうえで、一般論ではカバーしきれない個別案件について、どのタイミングで専門家への相談を検討すべきかを述べます。

電源もまた仕様の一部──前提条件をコードとインフラでそろえれば『たまに落ちる』は消える

ここまで見てきたように、サーバー電源トラブルは、単に「運が悪かった」「たまたま落ちた」という話ではありません。瞬低・停電・冗長電源の片系死・ファームウェア更新・タイムアウト設計・監視設定など、複数の要素が重なった結果として表面化します。

プログラマー視点で重要なのは、電源を「外部要因」として切り離すのではなく、仕様の一部として扱うという発想です。具体的には、次のような点を明文化していくことになります。

• 許容できる電源イベント（瞬低の頻度・停電の最大許容時間）
• その前提のもとで、アプリケーションが期待どおり動作するためのタイムアウト・リトライ設計
• 前提を超える事態が起きたときに、どのようなデグレードモード・フェイルセーフ動作を取るか

一方で、インフラ側・設備側の設計にも、「アプリケーションがこういう前提で動いている」という情報を反映させる必要があります。たとえば、次のようなすり合わせです。

• アプリ側の再接続までに必要な復旧時間を、UPS の保持時間や再起動時間の設計に反映する
• 計画停電・メンテナンス時には、アプリ側でのグレースフルシャットダウン手順を事前共有する
• 新しい機器・電源系統を追加する際には、冗長構成が崩れないように配線ルールを徹底する

つまり、「コード側の仕様」と「インフラ側の仕様」を、お互いに独立した前提としてではなく、同じ前提条件の上に成り立つ一体の仕様として設計することが、サーバー電源トラブルを減らす近道です。これは、単に技術的な最適化にとどまらず、「誰がどこまで責任を負うのか」という契約・運用の話にも深く関わります。

とはいえ、実際の案件では、次のような事情が絡み合うことが少なくありません。

• 既存設備を前提とした制約（ビル側電源・既設 UPS・ラック構成など）
• 複数ベンダーが関与する契約構造（ハードウェア、ネットワーク、クラウド、アプリ開発）
• 医療・介護・公共インフラなど、止められない業務要件と法令・ガイドライン

このような状況では、「電源を含めた前提条件の整理」と「アプリケーション・インフラの責任分界」を、個別案件ごとに丁寧に設計・文書化する必要があります。一般論だけではカバーしきれない部分が多く、実際の機器構成・ログ・契約条件を踏まえたうえでの検討が欠かせません。

株式会社情報工学研究所では、データ復旧やサーバートラブル対応の実務経験をもとに、サーバー電源トラブルを含むインフラ障害の調査・原因分析・再発防止策の検討を行っています。特に、

• 医療機関・介護施設など、止められないシステムを抱える組織
• オンプレミスとクラウドが混在したハイブリッド構成
• RAID・仮想化・共有ストレージなどが絡む複雑なサーバー環境

といった現場では、「ログと構成図を見ただけでは判断が難しい」ケースが多く、一般論ベースの対応ではリスクを十分に減らせないことがあります。

もし、

• 「たまに落ちるサーバー」を抱えているが、原因がアプリか電源か切り分けられていない
• 電源トラブルをきっかけにデータ不整合やストレージ障害が発生し、復旧方針に悩んでいる
• 新規システム導入や更改にあたり、電源を含めた前提条件・責任分界を整理したい

といった課題があれば、一般論だけで抱え込まず、早めの段階で専門家に相談することをおすすめします。個別案件の機器構成・ログ・契約条件を踏まえたうえで、「どこから手を付けるべきか」「どこに本質的なリスクが潜んでいるか」を一緒に整理していくことが、結果的にダウンタイムとコストを抑える近道になります。

現在広く使われているプログラム言語ごとの注意点（電源トラブルと絡めて）

最後に、電源トラブルとアプリケーション設計の関係を考えるうえで、現在よく使われているプログラミング言語ごとの注意点を整理します。ここでは、言語そのものの優劣ではなく、「その言語で書かれたシステムが電源イベントの影響をどう受けやすいか」という観点でまとめます。

いずれの言語においても共通するポイントは、

• 電源トラブルや瞬断が発生したときに、どの層でどのような例外・エラーが発生し得るかを把握すること
• それらのエラーをアプリケーションコードがどう扱うか（再試行するのか、諦めるのか、オペレータ通知するのか）を明示的に設計すること
• ログの書き出し、トランザクションのコミット、ファイルのフラッシュなど、「いつどこまで永続化されたか」を意識すること

特に、医療・介護・公共インフラなどの止められないシステムでは、使用言語だけで安全性が決まるわけではなく、

• 言語ランタイムやフレームワークの挙動
• データベースやメッセージキューなどの周辺コンポーネント
• 電源・ネットワーク・ストレージを含むインフラ構成

を組み合わせて、「電源イベントを含む障害シナリオに耐えられるか」を総合的に評価する必要があります。

実際に、既存システムのコードベースや構成を踏まえて、「この言語＋このフレームワーク＋このインフラ構成で、どこにリスクが集中しているか」を判断するには、ログ・設計書・実環境の情報が欠かせません。そうした個別の状況に応じた評価・改善を行いたい場合には、株式会社情報工学研究所のような、インフラとアプリケーションの両面からトラブルシューティングを行っている専門家に相談することで、より現実的な対策案を短時間で導き出せる可能性があります。

本記事の内容が、「たまに落ちるサーバー」という抽象的な悩みを、「どのレイヤーで何を確認すべきか」という具体的な行動に落とし込む一助となり、必要な場面では適切な専門家への相談を検討するきっかけになれば幸いです。