サーバー障害・メンテナンス時に会社が取るべき対応

サイトが開かないときは、別の回線でも同じ症状か、サーバー会社が障害やメンテナンスを案内しているかを先に見ると、連絡先を絞りやすくなります。自社のサイトだけで起きているなら、直前の更新や契約期限も原因の候補です。

原因が分からない段階で、DNS変更や復元を重ねるのは避けてください。エラー画面と発生時刻を残して保守先へ伝えれば、社内で技術的な原因を特定できなくても調査を依頼できます。

影響を確認して対応窓口へつなぐ

発見者は発生時刻、見えている症状、確認した場所を記録します。売上・問い合わせ・メール・社内業務のどこに影響するかを暫定で整理し、通常の問い合わせではなく障害として扱うかを決めます。予約や注文が止まっている場合は、原因の確定より先に利用部門へ知らせる必要があります。

障害対応の責任者は、情報を集約して担当を割り当てる役目です。自分ですべての技術作業を行わず、調査・顧客連絡・ベンダー連絡を分担します。複数人が対応する場合は、変更内容を時刻付きで共有すると、操作の重複を避けやすくなります。

小規模な会社では、一人が社内連絡と保守窓口への連絡を兼ねても構いません。複数人が別々の指示を出して、同じ設定を何度も変える状態を防ぐことが目的です。

エラー画面と監視通知を保存します。アクセスログと直前の変更も同じ記録へ加えます。ログの時刻帯とタイムゾーンを揃え、問い合わせに使えるリクエストIDや対象アカウントも記録します。再起動や復元で証拠が消える場合があるため、実行前に何を失うかを確認します。

担当外の更新は一時停止し、変更には実施者・時刻・目的・結果を残します。同じ設定を複数人が戻したり進めたりすると、復旧した理由を判断できません。緊急変更でも切り戻し方法を決め、一つずつ結果を観測してから次へ進みます。

まず複数の端末や外部回線から現象を再確認し、単一端末の問題を分けます。次にDNSと証明書を確認します。Web応答からアプリケーションとデータベースへ進み、どの境界まで到達するかを見ます。ステータスページが正常でも、自社設定だけに問題がある可能性は残ります。

直前のリリースや契約変更があれば、時間関係と影響範囲を照合します。サーバー会社へ連絡する際は、症状だけでなく開始時刻・対象URL・エラー・試した内容を渡します。「サーバー障害」と先に断定せず、確認できた事実と仮説を分けて伝えます。

最初の案内には影響範囲と発生を確認した時刻を含めます。代替手段と次の更新予定も示します。復旧見込みが分からない段階で時刻を約束しません。問い合わせフォームが使えないなら、電話や別ドメインの窓口など実際に利用できる経路を示します。

技術担当から届いた断片を各部署が別々に発信すると説明が食い違います。対外文面の承認者と発信先を決め、更新のたびに同じ記録へ追記します。計画メンテナンスでも、停止対象と利用者側の準備を事前に明示する考え方は同じです。

HTTP応答が戻っただけで完了にせず、ログイン・検索・フォーム・決済・メールなど主要な利用経路を試します。データ欠損や重複処理がないかを、障害時間帯の記録と照合します。負荷が戻った後も安定するかを一定時間観測し、監視条件を通常へ戻します。

切り戻しやバックアップ復元を行った場合は、どの時点のデータへ戻ったかを業務側へ伝えます。再入力が必要な操作を特定し、利用者への案内を更新します。復旧宣言には確認した機能と残っている制限を含め、調査継続中の事項を隠しません。

メンテナンス案内では、停止時間だけでなく対象サービスが重要です。Webが停止してもメールは対象外という場合もあり、すべてが止まると決めつける必要はありません。予約の受付などに影響する場合は、使える代替窓口を事前に案内できます。

終了予定を過ぎても使えない場合や、対象外の機能まで止まっている場合は、通常の障害として問い合わせる理由になります。案内された作業時間と、実際に使えなかった時間を分けて伝えると状況を共有しやすくなります。

落ち着いた後に時系列を作り、検知・判断・変更・連絡の各時刻を並べます。個人の失敗を探すのではなく、障害を広げた条件や発見を遅らせた仕組みを確認します。再発防止には担当者と期限を付け、監視や手順書へ反映します。

今回連絡がつかなかった窓口や、分かりにくかった手順を直しておけば、次回は同じところで迷わずに済みます。

障害の種類によって、会社が担う範囲は異なります。事業者側の復旧を待つ場面では利用者への案内、自社の変更が原因なら保守担当との切り戻しが中心です。何でも社内で直そうとせず、確認できた症状から対応先を分けるのが基本になります。