サーバートラブル時の緊急連絡先リストを作る方法

サーバートラブル時の連絡先は、保守を頼んでいる会社、サーバーやメールの契約先、社内で停止や費用を判断する人をまとめれば、基本の一覧になります。電話番号だけでなく、受付時間と契約IDがあると問い合わせが進みやすくなります。

小規模な会社サイトなら、次の表を連絡先リストのひな型にできます。パスワードや回復コードは記載せず、安全な別の保管先で管理します。

一覧は、障害が起きたサーバーやメールを使えなくても開ける場所に保存します。

技術対応と社内の判断を分けておく

最初に社内の役割を分けます。事象を受け付ける人、技術的な事実を確認する人、業務停止を判断する人が必要です。小規模な会社では一人が兼任しても、どの立場で判断するかを明記します。

NIST SP 800-61r3では、経営層・インシデント対応者・法務・広報などの役割を平時から整理する考え方が示されています。経営層には、重要サービスの停止や再構築を決める役割があります。技術担当者だけへ公表や事業継続の判断まで背負わせません。

主担当へ連絡できない場合の連絡先もあると役立ちます。費用やサービス停止の判断が必要なとき、誰へ相談するかが分かる形にします。

サイトが表示されない場合は、サーバー会社と制作会社のどちらが最初に切り分けるかを決めます。メール停止ならメール事業者やDNS管理者が関係します。契約失効なら技術会社ではなく、契約窓口や経理への確認が先になることがあります。

不正アクセスや情報漏えいの疑いでは、保守会社・セキュリティ支援会社・法務担当者へ連絡します。サイバー保険へ加入している場合は、調査を始める前に必要な連絡条件を確認します。警察や監督機関への報告要否は、事案と現行ルールに基づいて専門家と判断します。

IPAのサイバーセキュリティ相談・届出窓口には、企業向け相談先と中小企業向け対応資料が案内されています。ただし法的解釈や個別のログ調査など、受け付けない内容もあります。一つの公的窓口がすべてを代行すると考えません。

外部窓口ごとに、電話・メール・管理画面などの連絡方法を記録します。受付時間と契約プランの対応範囲も確認します。24時間受付と、24時間以内の復旧を同じ意味で扱いません。

問い合わせに必要な契約ID、対象ドメイン、サーバー名を添えます。本人確認に登録電話番号や契約者の操作が必要なら、その担当者も示します。パスワード・秘密鍵・回復コードを連絡先リストへ直接書きません。

制作会社には契約外の緊急対応を依頼できるか確認します。追加費用がかかる場合の相談先も、社内で共有しておくと進めやすくなります。連絡がつかない場合に別の会社へ依頼できるよう、データと管理権限の所在を社内で把握します。

障害を見つけた人は、発見時刻と確認したURLを記録します。表示内容、影響する利用者、直前の変更も分かる範囲で残します。推測した原因ではなく、観察した事実を先に伝えます。

すでに行った操作も必要です。再起動や設定変更を繰り返すと、原因の手掛かりが失われる場合があります。証拠を保全する必要がある事象では、承認を得ずにログや不審ファイルを削除しません。

連絡後は受付番号・回答時刻・次の確認時刻を記録します。「調査中」という返答だけで待ち続けず、次に連絡する条件を決めます。同じ内容を複数窓口へ伝える場合も、最新の事実と決定を一つの記録へ集めます。

会社のメールが停止したとき、同じメールボックスに連絡先があっても読めません。サーバーへ入れないときに、サーバー内の共有フォルダーだけへ保存する構成も避けます。会社管理の別経路と、必要に応じて紙の控えを用意します。

代替連絡手段には個人情報が含まれるため、全社員へ無制限に公開しません。緊急対応者だけが読める場所を選びます。持ち出した紙や端末を紛失した場合の回収・失効方法も決めます。

連絡先リストと復旧用の秘密情報は分けます。リストには安全な保管先と利用承認者を示します。緊急時だから全員がすべての資格情報を見られるという運用にしません。

担当者の異動・制作会社の変更・契約プランの変更があれば、その時点でリストを更新します。年一回の日付だけを待ちません。各連絡先には最終確認日を記録します。

訓練では、架空のサイト停止から連絡順をたどります。主担当が不在でもリストを開けるか、契約IDを見つけられるかを確かめます。実際の緊急窓口へ無断で試験連絡せず、事前に許可された方法を使います。

連絡先が変わったときに更新でき、担当者が不在でも必要な情報を探せれば、小さな一覧でも役に立ちます。細かな復旧手順まで一枚に詰め込むより、最初に相談する相手がすぐ分かる形が使いやすいです。