106
41

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

システム再起動で起動しなくなった話

Last updated at Posted at 2025-12-03

はじめに

この記事は 本番環境などでやらかしちゃった人 Advent Calendar 2025 4 日目の記事です。

過去に経験した本番環境でのやらかしです。

システム再起動で起動しなくなった

どういう状況?

お客さんのシステムの運用保守を担当してました。
そのシステムはオンプレのサーバの上にパッケージ製品のアプリが構築されています。

ある時、お客さんの環境でネットワークの切り替え作業が計画されており、一時的にシステム(アプリ)との通信断が発生することがわかりました。
安全サイドに倒すため、ネットワークの切り替え作業日はシステム(アプリ)を停止することになりました。

全体の流れは以下となります。
システム(アプリ)停止 → ネットワーク切り替え → システム(アプリ)起動
これだけです。

一つ厄介なのは、パッケージ製品のアプリは簡単に停止・起動できるものではなく、手順に沿ってターミナルからコマンドを実行する必要がありました。
アプリといっても複数のパッケージ製品の集合体で構成されており、順番にアプリのサービスを停止・起動する手順があったのです。
手順についてはパッケージ製品のベンダーから提供いただき、私たち運用保守メンバーが対応することになりました。

もう一つ厄介なのは、システム(アプリ)の停止・起動に時間がかかることでした。
過去にもシステム(アプリ)の停止・起動を実施したことがあったのですが、停止に1時間、起動に30分かかります。それだけ複数のパッケージ製品のサービスがあったのです。
特にシステム(アプリ)の停止に時間がかかる件については、パッケージ製品のベンダーも認識しており、サービスのプロセスが完全に停止するのを待機し続けているから、とのこと。
そのため、停止時に強制的にサービスのプロセスをkillして対処することになりました。

さらに起動に時間がかかる件についても、改善するための対処方法をパッケージ製品のベンダーから連携いただきました。
起動時に、停止直前の状態のログを読み取って、システム(アプリ)の状態の整合性を確認した上で起動している、とのこと。
実際はログを読み取る必要はないとのことで、ログを削除すればすぐに起動できることがわかり、起動前にログを削除して対処することになりました。

結局、全体の流れは以下となりました。
システム(アプリ)停止 → サービスのプロセスkill → ネットワーク切り替え → ログ削除 → システム(アプリ)起動

いざ、システム再起動です。

何をした?

システム(アプリ)停止 OK
サービスのプロセスkill OK
ネットワーク切り替え OK
ログ削除 O...あれ?ログだけじゃなくいろんなものが削除されてる?

何が起こった?

どうやらログ削除の対象が間違っており、ログだけでなくアプリも削除してしまいました。

パッケージ製品のベンダーからはメールにて「このディレクトリのログを削除してから起動してください」と連携されており、(とても素直な)私は「このディレクトリを削除すれば良いのだな」と勘違いしてしまいました。

[親ディレクトリ]
    |_[子1ディレクトリ]        # 勘違いしてここから削除...
        |_[アプリのディレクトリ]
        |_[ログのディレクトリ]   # パッケージ製品のベンダーが削除して欲しかったログがあるディレクトリ
    |_[子2ディレクトリ]
    ・・・

パッケージ製品のベンダーは、[ログのディレクトリ]の中のログを削除して欲しかった。
(とても素直な)私は、[子1ディレクトリ]の中を削除した。

削除コマンドをstopさせましたが、時すでに遅し。アプリの一部は削除されてしまいました。そのままシステムを起動しようとすると、あるはずのアプリがないため、順番通りに起動できず、システムは起動しなくなりました。

結局どうした?

バックアップから復元...できません。
削除の作業前にバックアップを取得しておこうと思い、[子1ディレクトリ]をコピーしようとしたのですが、[子1ディレクトリ]のサイズが大きすぎてコピーするだけで時間がかかると判断し、バックアップは取得しませんでした。
(今思えば、コピーがダメなら、せめてrenameしてとっておくべきでした。)

パッケージ製品のベンダーがすぐに対応...できません。
業務影響がない時間ということで週末に作業となったため、パッケージ製品のベンダーはもちろんお休みです。連絡しようにもなかなかつながらず、すぐにリカバリができませんでした。
(今思えば、リカバリ体制はとっておくべきでした。)

ようやくパッケージ製品のベンダーと連絡が取れ、状況を説明し、対応を仰いだところ、システム(アプリ)構築時のバックアップがあることがわかりました。
構築時のバックアップであり、運用中のバックアップではなかったのですが、幸いに該当のアプリは構築時から使われておらず、バックアップとしての状態は同じでした。

システム(アプリ)構築時のバックアップから復元して起動したところ、無事、システムは起動しました。

これからどうする?

メールにて「このディレクトリのログを削除してから起動してください」と連携

曖昧さを残すことなく明確にするため、手順はコマンドレベルで記載して、チームで手順のレビューを実施します。
さらに、1人で作業せず、必ずダブルチェックで手順を実行します。

バックアップから復元...できません。

削除作業や更新作業では必ずバックアップを取得してから作業します。
これも手順に入れます。

パッケージ製品のベンダーがすぐに対応...できません。

パッケージ製品のベンダーと連携してリカバリ体制をとっておきます。
作業する日が週末ならなおさら、事前に何かあった時の対応を相談しておきます。

おわりに

実は単純にシステムが起動しなくなったという話ではなく、お客さんのアプリを削除してしまった上にシステムが起動しなくなったというやらかしの話でした。
大変反省しております。お客さんにもかなり厳しい説明しかできず、気を引き締めて取り組むべきでした。

バックアップは大事。みなさんもどうかお気をつけてください。

106
41
3

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
106
41

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?