こんにちは。
UniProjectでインフラ担当をしているSibainu_uwuです。
先日、青森県東方沖発生したM7.6の地震により発生したトラブルを記事にしました。
本記事のトラブル対応は周囲の安全確認後行っております。
記事を執筆している最中にも余震を感じています。
皆さんも身の危険が生じた場合はサーバーのトラブル対応はやめ避難を優先してください。
概要
2025/12/08 23:15 発生の地震の影響により、オンプレミス環境でサービス停止が発生しました。本稿は発生から復旧までの時系列と振り返り、今後の対策をまとめたものです。
地震情報(気象庁): https://www.data.jma.go.jp/multi/quake/quake_detail.html?eventID=20251208232600&lang=jp
発生から被害確認(時系列)
-
2025/12/08 23:15 地震発生。
-
2025/12/08 23:19 リーダーがサービスをセーフモードへ移行。
-
2025/12/08 23:20 停電が発生していないことを確認したため、電源側の障害はないと暫定判断。
-
2025/12/08 23:25 コミュニティ内の全サービスがダウンしている旨の報告あり。
-
2025/12/08 23:27
物理サーバはファン動作などで外観上は問題なし。Proxmox ダッシュボード確認の結果、2ノード中1ノードがダウンしていることを確認。SSH/Ping に応答がなく、リモート操作ができなかったため、当該ノードを一旦強制停止し再起動を実施。 -
2025/12/08 23:33 落ちていた Proxmox ノードが復旧。
-
2025/12/08 23:53 k8s 上の VM が順次起動し、サービスの復旧が始まる。
-
2025/12/08 23:56 サークル運用の Wiki が復旧しないことを確認。k8s の node12 の挙動が不安定だったため、当該 VM を再起動。
-
2025/12/09 00:00 全サービスの復旧を確認。
反省点
-
強制停止の判断根拠:SSH/Ping のみで強制停止を判断してしまった。コンソール(仮想コンソール/物理コンソール)での画面確認を最低限行うべきだった。誤ったシャットダウンやファイルシステムの破損につながる可能性があるため、今後はコンソール確認を必須とする。
-
ログ収集の遅れ:初動で取得したログが不足している可能性があるため、今後は自動で主要ログ(Proxmox, kernel, systemd, k8s, VM のシリアルログなど)を中央収集する仕組みを整える。
今後の対策(短期・中長期)
-
ログの収集・保存:今回取得できたログを保存し、欠落がないか確認。必要に応じて追加でログ回収(ノードのシリアルログ、VM のコンソールログ、k8s イベント)を行う。
-
バックアップ整合性確認:最新バックアップが問題なく復元できるか検証。
-
運用手順の追記:緊急時のチェックリストに「コンソール確認」を明確に追記。
結び
私は趣味でオンプレ環境を運用しています。本業で同様の分野に携わっている方や、経験者の方がいらっしゃれば今回の対応についてご意見・改善案をいただけると助かります。特に以下の点についてフィードバックいただけると幸いです。
-
物理サーバの緊急再起動時のベストプラクティス
-
ログ収集・復旧手順のテンプレートや参考資料