自分たちの作業でサイトを止めた話と、そこから決めた保守の運用ルール
こんにちは。ワクワクラボのはぜやまです。
2026年7月、私たちは保守を担当しているサイトを自分たちの作業で止めてしまい、表示が戻るまでに約16時間25分かかりました。この記事では、何が起きたのか、なぜ気づけなかったのか、そこから運用として何を決めたのかを書きます。あわせて、同じ時期に見つかったもう一つの置き忘れについても書きます。
原因は、合言葉を片方だけ変えたことでした
作業のなかで、データベースのパスワードを変更しました。ところが、wp-config.php に書かれている設定を同時に更新しなかったのです。
WordPress は、記事も設定もデータベースに保存しています。そのデータベースへ接続するための合言葉が wp-config.php というファイルに書いてあるので、片方だけ変えればつながらなくなるのは当然ですね。
結果として、サイトには「データベース接続確立エラー」という一行だけが表示される状態になり、トップページも記事も何も出なくなりました。
停止に気づいたのは、私たちではありませんでした
ここが、この件でいちばん重い部分なのですが、約16時間25分のあいだ、私たちは停止していること自体に気づいていませんでした。
発覚したのは、クライアント経由でエンドユーザーからの指摘を受けたときで、サイトを見に来てくださった方が最初の発見者だったのですね。保守を預かっている側として、これは順番が逆です。
当時、稼働監視を導入しておらず、作業のあとに自分の目で表示を確かめる、という運用に頼っていました。人の目に頼る運用は、確認を飛ばした瞬間に何も残りません。
障害報告書を作って、提出しました
対応として、正式な障害報告書を作成し、提出しました。
口頭のお詫びで済ませることもできたと思います。ただ、何が起きて、なぜ気づけず、次に何を変えるのかを文書にしないと、こちら側にも記録が残らないのですね。書いていく過程で、原因が「パスワードを変更したこと」ではなく「変更したあとに確かめる仕組みを持っていなかったこと」だと整理できました。
保守を任せる相手を見るときは、ミスが起きない会社かどうかよりも、起きたあとに何を出してくるかを見ていただくほうが現実的だと思います。依頼前に確認しておきたい点は、ホームページ制作会社の選び方。名古屋で依頼する前に確認する判断基準にまとめています。
再発防止として、3つのエンドポイントに稼働監視を入れました
最初に手をつけたのが稼働監視の導入で、監視する先は1か所ではなく、3つのエンドポイントに分けました。
エンドポイントというのは、監視ツールが定期的に見に行くURLのことですね。トップページだけを見ていると、そこが生きているあいだは正常と判定されてしまいます。見に行く先を分けておけば、どのあたりで止まっているのかが早く分かります。
今回の停止は、監視さえ入っていれば数分で検知できたはずのものでした。16時間かかった理由は、技術的に難しかったからではなく、仕組みを持っていなかったからです。
メンテナンス表示は、503を返す設計にしました
あわせて決めたのが、メンテナンス表示の返し方です。
サイトを一時的に止めて作業するとき、「ただいまメンテナンス中です」という画面を出します。このとき画面だけを差し替えると、ページとしては表示できているため、監視ツールからは正常に見えてしまうのですね。
そこで、メンテナンス表示のときは 503 というヘッダーを返す設計にしました。503 は「今は一時的に応答できません」という意味の返事です。こうしておけば監視ツールが停止としてきちんと数えてくれますし、作業で意図的に止めた時間も記録に残る形になります。
ここまで読んで、自社のサイトが止まったとき誰が最初に気づくのだろうと思われた方は、LINEから気軽に聞いてください。
LINEで相談する
稼働監視で分かるのは、サイトが表示されるかまでです
これは、導入したあとに自分たちで線を引いた部分です。
稼働監視が検知できるのは、「サイトが表示されるかどうか」までです。たとえばお問い合わせフォームが送信できなくなっていても、ページそのものは表示されますから、監視は正常と判定します。
ですから、監視を入れたのでもう大丈夫です、とは言えないのですね。フォームの動作確認は、監視とは別に人が定期的に行う必要があります。できることとできないことを先に伝えておかないと、入れたこと自体が安心の材料になってしまいます。
もう一つ、本番環境にデバッグログが残っていました
同じ時期に、別の置き忘れも見つかりました。
PHPのバージョン変更を検証するときに、エラーの内容を記録して動かない箇所を探すための WP_DEBUG という設定を有効にしました。ところが検証が終わったあと、これを無効に戻し忘れていたのです。
数ヶ月後に気づいたとき、ログファイルは4GBを超えていました。しかもそのファイルは、外部から直接アクセスできる場所に置かれていました。
デバッグログが外から読めると、何が困るのか
ファイルが大きいこと自体も問題ですが、より重いのは中身のほうです。
デバッグログには、サーバー内のファイルパスや、エラーの詳細が記録されます。どこに何が置かれていて、どの処理が失敗するのか。攻撃する側から見れば、これは手がかりになり得ます。
サイトが動いているかどうかとは別に、この種の置き忘れは静かに残り続けます。今回は数ヶ月でしたが、気づかなければもっと長く残っていました。
決めたのは、たった2つのルールです
この件から決めたルールは2つだけです。
1つは本番環境でデバッグ出力を有効にしないこと、もう1つは検証などで一時的に有効にした場合は必ず戻すことです。
ルールを増やせば守れるようになる、というものではありません。検証のたびに戻す、という当たり前の一行を、担当者の記憶ではなく手順の側に置いておく。それだけのことなのですが、置いていなかったから数ヶ月残ったのですね。
なお、PHPのバージョン変更のような作業がどれくらい必要になるかは、サイトの状態によって変わります。判断の目安はホームページをリニューアルすべきタイミング。年数ではなく状態で判断するに書きました。
自社で運用している場合も、同じ2点は確認できます
保守を外部に任せていない場合でも、ここまでの話はそのまま確認に使えます。
まず、サイトが止まったときに誰がいつ気づくのか。決まっていなければ、気づくのはサイトを見に来た方です。私たちは3つに分けましたが、まずトップページ1か所からでも、人の記憶に頼る状態からは抜けられます。
もう一方は、wp-config.php に WP_DEBUG を有効にした記述が残っていないか、そしてログファイルが溜まっていないかです。検証のために誰かが有効にしたまま、という状態は起こりやすいところですね。
保守を外注するか自力で対応するかという判断そのものは、ホームページの保守管理。外注する？自力で対応？メリットデメリットを解説。で扱っています。
よくある質問
稼働監視を入れれば、障害には気づけますか？
サイトが表示されなくなる種類の障害には気づけます。ただし、お問い合わせフォームが送信できないといった不具合は、ページが表示されている限り検知できません。監視とは別に、人が動作を確かめる必要があります。
メンテナンス中の画面は、そのまま出しておいてよいですか？
私たちは、503 のヘッダーを返す設計にしています。画面だけを差し替えると、監視ツールからは正常に表示されているように見えてしまうためです。
本番環境でデバッグ出力を有効にしてもよいですか？
私たちは、有効にしないことを運用ルールにしています。ログにはファイルパスやエラーの詳細が記録され、外部から読める場所にあると攻撃の手がかりになり得るためです。検証のために一時的に有効にした場合は、必ず戻します。
この記事の要点
- 2026年7月、データベースのパスワードを変更した際に wp-config.php を更新せず、約16時間25分サイトを停止させた
- 停止に気づいたのは自社ではなく、クライアント経由でのエンドユーザーからの指摘だった
- 対応として障害報告書を作成して提出し、再発防止に3つのエンドポイントへ稼働監視を導入した
- メンテナンス表示は 503 を返す設計にし、監視ツールが停止を検知できる状態にした
- 稼働監視で分かるのは「サイトが表示されるか」まで。フォームの不具合は検知できない
- 本番環境でデバッグ出力を有効にしない、一時的に有効にしたら必ず戻す、を運用ルールにした
ワクワクラボでは、WordPressサイトの保守と、稼働監視や障害対応の体制づくりをお受けしています。「今の運用で止まったとき、誰が気づくのか分からない」という段階でも大丈夫です。
