法人サイトのサーバー障害対策で重要なのは、「絶対に止めないこと」だけではありません。実際には、障害が起きたときにどれだけ早く気づき、どこまでデータを戻し、何分・何時間で復旧できるかまで決めておくことが重要です。
会社案内サイト、問い合わせサイト、予約サイト、ECサイトでは、停止したときの損失が異なります。そのため、すべての法人サイトに同じ対策を入れるのではなく、事業への影響に応じて監視・バックアップ・復旧体制を決めます。
30秒でわかる結論
- 法人サイトでは「障害を防ぐ」だけでなく「何分で気づき、何時間で戻すか」まで決める
- 最初にRTO（復旧まで許容できる時間）とRPO（どこまでのデータ損失を許容するか）を決める
- バックアップは「あるか」ではなく「復元できるか」を確認する
- 監視は24時間の死活監視だけでなく、SSL期限・容量・応答速度なども対象にする
- 障害時の連絡先・担当者・判断権限を平常時に決めておく
- 問い合わせや予約が止まる場合は、電話・SNS・別フォームなど代替手段を用意する
- 重要な法人サイトほど、月額料金より復旧時間と事業損失でサーバーを選ぶ
法人サイトのサーバー障害対策で最初に考えること
サーバー障害対策というと、バックアップや高性能サーバーを先に考えがちです。しかし、最初に決めるべきなのは「このサイトが止まったら、会社にどれだけ影響があるか」です。
たとえば、会社案内だけのサイトと、売上が発生するECサイトでは、1時間停止したときの影響が違います。
| サイト用途 | 停止時の主な影響 | 対策優先度 |
|---|---|---|
| 会社案内 | 信用低下、情報閲覧不可 | 中 |
| 問い合わせ獲得 | 見込み客の取りこぼし | 高 |
| 予約サイト | 予約停止、電話対応増加 | 高 |
| ECサイト | 売上停止、注文機会損失 | 非常に高い |
| 会員・業務システム | 業務停止、顧客対応遅延 | 非常に高い |
ここで伝えたいポイント
障害対策の予算は「サーバーにいくらかけられるか」ではなく、「サイトが止まると1時間あたりどれだけ困るか」から逆算すると判断しやすくなります。
RTOとRPOを決めると障害対策が具体化する
法人サイトの障害対策では、RTOとRPOという2つの考え方を使うと、必要な対策を整理しやすくなります。
| 用語 | 意味 | 例 |
|---|---|---|
| RTO | 何時間以内に復旧したいか | 4時間以内に復旧 |
| RPO | どこまでのデータ損失を許容できるか | 直近1時間分まで |
問い合わせサイトの例
「4時間以内に復旧できれば業務への影響を許容できる」「問い合わせデータは最大1時間分までなら再確認で対応できる」と決めた場合、RTOは4時間、RPOは1時間がひとつの目安になります。
この条件が決まると、必要なバックアップ頻度や監視方法が見えてきます。
「毎日バックアップ」で十分かはRPOで決める
1日分のデータを失っても問題が小さい会社案内サイトなら日次バックアップでも判断しやすいですが、注文や予約が頻繁に入るサイトでは24時間分のデータ損失は大きすぎます。バックアップ頻度はサイトの更新頻度と事業損失で決めます。
バックアップは「保存」より「復元できること」が重要
バックアップ機能が付いていても、障害時に復元できなければ対策として不十分です。
法人サイトでは、最低でも次の3点を確認します。
バックアップ確認項目
- 何日前まで保存されているか
- ファイルとデータベースの両方を戻せるか
- 復元は自分でできるか、サポート依頼が必要か
- 復元に料金がかかるか
- サーバー外にもバックアップを持てるか
同じサーバー内だけに保存しない
バックアップを同じサーバー内だけに保存していると、サーバー全体の障害や操作ミスの影響を同時に受ける可能性があります。
重要な法人サイトでは、別ストレージや別環境にもバックアップを持つと復旧手段を増やせます。
年に1回でも復元テストをする
「バックアップがあります」と「実際に戻せます」は別です。
少なくとも定期的に、テスト環境へ復元できるか確認すると、障害時に初めて復元方法を調べる事態を避けやすくなります。
注意
バックアップが自動でも、保持期間を過ぎると古いデータは消えます。改ざんや誤操作に気づくのが遅れる可能性があるサイトでは、保存世代数も確認してください。
監視を入れて「障害に気づくまでの時間」を短くする
サーバーが停止しても、誰も気づかなければ復旧は始まりません。
そのため、法人サイトでは「復旧時間」だけでなく、「障害発生から検知までの時間」も重要です。
| 監視項目 | 分かること |
|---|---|
| HTTP/HTTPS監視 | サイトが表示できるか |
| 応答速度 | 極端に遅くなっていないか |
| SSL期限 | 証明書切れの予防 |
| ディスク使用量 | 容量不足の予防 |
| CPU・メモリ | 高負荷状態の確認 |
| エラーログ | 異常の兆候を確認 |
検知時間の差
営業時間に担当者が目視で確認するだけなら、夜間の障害に翌朝まで気づかないことがあります。5分間隔の外形監視なら、最短数分で異常を把握できる可能性があります。
障害時間 ＝ 検知までの時間 ＋ 判断時間 ＋ 復旧作業時間
高価なサーバーを契約しても、検知が遅ければ停止時間は長くなります。監視は障害対策の基本です。
障害時の連絡体制を決めておく
法人サイトでは、「誰が直すか」だけでなく「誰が判断し、誰に連絡するか」を決めておくことが重要です。
| 役割 | 主な担当 |
|---|---|
| 障害検知 | 監視サービス・担当者 |
| 一次確認 | Web担当・保守会社 |
| 技術対応 | サーバー管理者・制作会社 |
| 事業判断 | 責任者・管理職 |
| 顧客案内 | 広報・営業・CS |
障害時連絡票に入れる項目
- サーバー会社のサポート窓口
- 制作会社・保守会社の連絡先
- 社内Web担当者
- 責任者・承認者
- ドメイン管理会社
- DNS・CDNなど外部サービスの管理先
深夜・休日も考える
「担当者の会社メールに連絡する」だけでは、サイト障害でメールまで受け取れない可能性があります。緊急時は電話や別ドメインの連絡手段も用意しておくと安全です。
障害時の復旧手順を事前に作っておく
障害が起きてから復旧方法を考えると、判断に時間がかかります。
法人サイトでは、最低限の復旧手順を平常時に文書化しておきます。
- サイトが本当に停止しているか確認する
- サーバー会社の障害情報を確認する
- DNS・SSL・WordPress・サーバーのどこに原因があるか切り分ける
- 直前の変更作業を確認する
- 必要ならバックアップから復元する
- 復旧後に表示・フォーム・注文などを確認する
- 原因と対応内容を記録する
- 再発防止策を決める
焦って変更を重ねない
障害時に設定を次々変更すると、元の原因が分からなくなり、復旧を遅らせることがあります。変更前に現状を記録し、ひとつずつ切り分けて対応します。
停止中の代替手段も用意する
サイトを完全に無停止にするには大きなコストがかかる場合があります。
そこで、障害時でも最低限の顧客対応を続けられる代替手段を用意しておくと、事業への影響を小さくできます。
電話番号、SNS、別フォームなどを案内できるようにしておきます。
電話予約や外部予約サービスなど、サイト停止中でも受付できる方法を用意します。
注文再開見込みや問い合わせ先をSNSなどで告知できる体制を作ります。
会社概要・電話番号など最低限の情報を別ページやSNSで案内できると安心です。
障害による損失を数字に置き換える
法人サイトの障害対策は、サーバー料金だけで判断すると過剰・不足の両方が起こります。
たとえば、サイト経由の売上が1時間あたり5万円ある場合、8時間停止すると単純計算では40万円分の販売機会があります。
停止損失の簡易計算
5万円 × 8時間 ＝ 40万円
このほか、問い合わせ対応、信用低下、復旧作業、人件費なども加わる可能性があります。
一方、会社案内サイトで売上への直接影響が小さければ、数分以内の自動切り替えに高額な費用をかける必要性は低い場合もあります。
障害対策費は「1時間止まった損失」と比較する
1時間の停止で数十万円以上の損失が出るサイトなら、監視・冗長化・高速復旧へ費用をかける意味があります。反対に、停止の事業影響が小さいサイトでは、バックアップと数時間以内の復旧体制を優先する方が費用対効果を取りやすくなります。
法人サイトの重要度別・障害対策の目安
| 重要度 | サイト例 | 対策の目安 |
|---|---|---|
| 低〜中 | 会社案内・採用情報 | 日次バックアップ、外形監視、復旧手順 |
| 中〜高 | 問い合わせ獲得サイト | 短い監視間隔、複数世代バックアップ、代替連絡先 |
| 高 | 予約・会員サイト | 高頻度バックアップ、監視、復旧担当、代替受付 |
| 非常に高い | EC・基幹連携サイト | 冗長化、短いRTO/RPO、24時間体制、復旧テスト |
表はあくまで考え方の目安
同じECサイトでも売上規模や注文数によって必要な対策は変わります。最終的には、自社の停止損失・契約要件・顧客影響からRTOとRPOを決めてください。
サーバーを選ぶときに障害対策で確認する項目
チェックリスト
- SLAや稼働率の考え方
- 自動バックアップの保存期間
- バックアップからの復元方法
- 障害情報の公開方法
- 電話・メールなどサポート窓口
- サポート受付時間
- 冗長化構成の有無
- 上位プランや別環境へ移行できるか
- 監視機能の有無
ただし、SLAの数字だけでサーバーを選ぶのはおすすめしません。
SLAはサービス品質の判断材料のひとつですが、実際の復旧方法、バックアップ、サポート体制、自社側の対応手順まで含めて障害対策になります。
障害対策でよくある失敗
バックアップがあるから安心する
復元方法を知らなければ、障害時に時間がかかります。保存期間と復元手順まで確認してください。
サーバー会社に全部任せられると思う
サーバー設備の障害はサーバー会社が対応しても、WordPressの設定ミス、プラグイン不具合、誤操作などは利用者側の対応になる場合があります。
担当者が1人しかいない
担当者が休暇中・退職後・連絡不能の場合に対応できなくなるため、アカウント情報や手順を属人化させないことが重要です。
復旧後に原因を記録しない
復旧した時点で終わりにすると、同じ障害を繰り返す可能性があります。原因・対応・所要時間・改善策を記録してください。
法人サイトの障害対策フロー
影響額と業務停止範囲を整理する。
RTOを決める。
RPOを決める。
不足している部分を追加する。
教科書判定｜法人サイトはどこまで障害対策すべき？
最低限「監視・バックアップ・復旧手順・連絡体制」の4点を用意する
一般的な法人サイトでも、障害に気づく仕組み、復元できるバックアップ、誰が何をするかという復旧手順、連絡先一覧の4点は用意しておきたいところです。
さらに、予約・EC・会員サイトなど停止が売上や業務へ直接影響するサイトでは、短いRTO/RPO、冗長化、24時間監視、代替受付まで段階的に追加します。
初心者はこれでOK
最初から高度な冗長化を組む必要はありません。まず「5〜10分程度の外形監視」「複数世代の自動バックアップ」「復元方法の確認」「緊急連絡先一覧」の4つを整え、その後に事業影響に応じて対策を強化してください。
よくある質問
サーバー会社の自動バックアップだけで十分ですか？
サイトの重要度によります。一般的な会社案内サイトなら有力な対策ですが、重要なデータを扱う場合は、保存期間・復元方法・別環境への保管まで確認すると安全です。
SLAが高ければ障害対策は不要ですか？
不要にはなりません。SLAはサービス品質の目安のひとつです。WordPressの不具合、設定ミス、改ざん、データ消失など、SLAだけでは防げない問題もあります。
監視は何分間隔がよいですか？
停止による影響が大きいほど短い間隔が向いています。一般的な法人サイトでは5〜10分程度から検討し、売上や業務への影響が大きいサイトではさらに短くする判断があります。
障害対策の担当者は社内に必要ですか？
必ずしも社内だけで対応する必要はありません。制作会社や保守会社へ委託できます。ただし、誰に連絡するか、どこまで委託範囲か、社内で誰が判断するかは明確にしておく必要があります。
専用サーバーにすれば障害は減りますか？
物理リソースを専有できるメリットはありますが、専用サーバーでもハードウェア故障や設定ミスは起こり得ます。重要なのはサーバー種類だけでなく、冗長化・監視・バックアップ・復旧体制まで含めることです。
まとめ｜法人サイトは「止まらない」より「止まっても戻せる」を作る
この記事の結論
- 法人サイトではRTOとRPOを決めて障害対策を具体化する
- バックアップは保存だけでなく復元できるか確認する
- 監視で障害検知までの時間を短くする
- 担当者・連絡先・判断権限を平常時に決める
- 問い合わせや予約には代替手段を用意する
- 重要サイトほど停止損失を数字にして対策費と比較する
- 最低限、監視・バックアップ・復旧手順・連絡体制を用意する
結局、法人サイトの障害対策で大切なのは、「高いサーバーを選ぶこと」ではありません。何分で異常を検知し、何時間で復旧し、どこまでデータを戻せるかを決め、その条件を満たす運用体制を作ることです。
次に読むなら
サーバー選定そのものを見直すなら「法人向けレンタルサーバーの選び方」、データ復旧を詳しく確認したいなら「Webサイトのバックアップ・保守完全ガイド」や「Webサイトを復元する方法」を読むと、障害対策を具体化しやすくなります。