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

サイトが開かないとき、全員が同時に設定を触り始めると原因と変更履歴が分からなくなります。最初に必要なのは高度な診断ではなく、影響を言葉にして指揮系統を一本にすることです。技術対応と連絡対応を分けると、復旧作業を止めずに事業側へ状況を伝えられます。

障害を宣言して指揮担当を一人決める

発見者は発生時刻、見えている症状、確認した場所を記録します。売上・問い合わせ・メール・社内業務のどこに影響するかを暫定で整理し、通常の問い合わせではなく障害として扱うかを決めます。確証が揃うまで宣言を待つと、初動の連絡が遅れます。

障害対応の責任者は、情報を集約して担当を割り当てる役目です。自分ですべての技術作業を行わず、調査・顧客連絡・ベンダー連絡を分担します。時刻付きの記録場所と次回報告時刻を決め、口頭だけの指示を避けます。

長時間対応に備えて指揮担当の代行者も決めます。交代時は未完了の作業と次の判断時刻を記録上で渡し、指示の空白を作りません。

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

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

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

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

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

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

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

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

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

障害対応計画は一度作って保管する文書ではありません。連絡先や契約先が変われば更新し、計画メンテナンスや机上演習で実際に使えるかを試します。次回の初動で迷う時間を減らせることが、振り返りを残す価値です。

改善項目は実施しただけで閉じず、監視や手順が期待どおり働くかを再確認します。確認結果まで障害記録へ結び付けると、次回の判断に使える根拠になります。