あとで読む
前回まで、サーバー障害によるサービス停止リスクをなるべく下げるため、良いサーバー会社を選ぶ方法などをお伝えしました。
しかしそうはいっても、「障害は発生するもの」というのも、お伝えした通り。
最終回の今回は、万が一障害が発生してしまった時の対応手順についてご説明します。
そもそもですが、サーバー障害が発生した場合、あなたの会社にとって“何”が問題になるのでしょうか？ 言われてみると考えたことがない、という人が多いのではないではないかと思います。
万が一の時、素早くサービスを復旧するために最初に知るべきことは、「誰に何の影響があるのか？」を事前に考えておくことです。やったことがない人は、せっかくなので今から一緒に考えてみましょう。
とはいえ、難しいことはありません。基本として抑えたいのは下記の３つ。
ぜひ事前に想定し、「なんとなくの損失額」まで想定しておくことがオススメです。
以下、上記を検討済みという前提で、サーバー障害時に時系列でどのように対応するかをお伝えします。
まず、障害に備えて事前準備をしましょう。 このとき、どこまで準備をすべきかは組織によって違います。
先にお伝えしたようにサービス停止時の損失見込額でとるべき対応も変わり、 基本的にはWeb用のスタンバイ機と、メール用のスタンバイ機の2つを考えておきます。
サービスを停止させないための代替機（スタンバイ機）を用意することが多いでしょう。
一般的には同じサーバーを２台契約し、データベースサーバーを共通化し、ロードバランサーで負荷分散をします。また、サーバーの冗長化や、ディザスタリカバリといった対応をとります。
この作業は、上記の言葉がわかるインフラエンジニアや企業と契約して進めましょう。1時間あたり数十万円からの損失がでるようなサービスであれば、万が一の時に相談できるインフラエンジニアがいないのは非常に危険です。
サポートできる企業を探したい場合は、「AWS 運用保守 大阪」などと検索すれば出てきます。
安くても他のサーバーの間借りでもよいので、できればスタンバイ機を用意しましょう。 一番の目的は、障害発生時に切り替えて「障害が発生し、サービスが停止している」ことを外部に正しく伝えるためです。また今回のZenlogicのように万が一障害が長引く場合は、キャンペーンページだけHTMLで自作するなど臨機応変な対応が可能です。
スタンバイ機の用意は下記手順で進めます。（以下、webtan-tsushin.comのスタンバイ機を作るという想定でお伝えします）
以上で準備は完了です。
せっかくスタンバイ機が用意できるなら、503暫定ページではなく、本番と同様のセットアップをした方がよいのではないか？と考える人もいるでしょう。
しかし、サイトのタイプにもよりますが、それは労力の割に合わないことが多いです。それはなぜか。そもそもサーバーが1日以上停止する可能性がとても低いからです。仮に３日間停止するとして損失額を計算すると面白いことがわかります。実際にやってみましょう。
例) サービス停止1日の最大損失額20万円 x 3日停止する発生確率0.002% x 3日間 = 1200円
1200円のために、スタンバイ機を本番状態にする（つまりシステムや情報を最新状態に保つ）ための大変な作業をすべきか？というと、ほとんどの人がNOだと思います。
ですから、シンプルで手間がかからないなら別ですが、それ以外は「今サーバー障害中です」という暫定告知でよいと割り切った方が割にあいますし、そもそも3日以上停止しそうなサーバー会社からは、さっさと乗り換える投資をした方が一番の対策になります。
スタンバイ機の用意にかかわらず、本番データのバックアップは必ず定期的（できれば毎日）に取得しましょう。
スタンバイ機で暫定告知をするにしても何にしても、最新データを失ってしまうと、復旧作業は大変時間がかかることが多いのです。最悪、人の記憶に頼るしかなくなります。
WordPressであればバックアップ専門プラグインもありますし、サーバーによってバックアップサービスがついているものも多いです。またFTPによる手動バックアップでも良いでしょう。とにかく定期的に取得しましょう。
メールサーバーとは、メールの送受信ソフトがインストールされたマシンのことを指します。
レンタルサーバー会社によってウェブサーバーと同じマシンにインストールされていることもあれば、別マシンにインストールされていることもあります。
同じマシンにインストールされているかどうかは、以下のサイトでドメイン名をいれてみるとわかります。
seo.atompro.net/webtoolfree_mxrchk_.html
別ドメイン名が表示されれば別マシン、そうじゃなければ同じマシンにインストールされています。
さくらサーバーなど、メールサーバーとウェブサーバーを分けることができるレンタルサーバー屋さんもあります。
こういった場合、メールサーバーに関するマニュアルがしっかりしているかが一つのポイントになります。なぜなら、万が一障害が発生した場合、メールサーバーをなおすのはエンジニアでないと難しいからです。
私自身は、メールサーバーはあまり深く考えず、レンタルサーバー会社が標準で用意しているものか、有料にはなりますが障害に強いGoogleのGSuiteを使うのがよいのではないかと考えます。
なぜなら、先にも記載しましたが「メールサーバーの独自セットアップはエンジニアでないと難しいし、データー同期の問題があるので運用後に変更することも難しい」からです。
インフラエンジニアがいない場合にメールサーバーを分けたいならば、情報がたくさん出ていて安心できるサービス≒GSuiteを最初から活用した方がわかりやすいでしょう。
もしくは標準のメールサービスを使っておいて、後述するGmailなどのバックアップ手段をもつ方がはるかにコストも安くすみます。
メールのスタンバイ機の用意はほぼ不可能だと考えましょう。スタンバイ状態では受信ボックスやアカウントのデータ同期ができないので、スタンバイの役目を果たさないからです。
そもそも本番やスタンバイのメールサーバーの用意が難しい以上、考え方をかえる必要があります。
障害がおこった時、一番よくないのは「メールを送ったのに返事がない」とお客様が感じてしまうことです。最悪「メールが消えてしまう」という問題も発生しますが、その場合も再送をお願いすればよいので、やはり大切なのは「障害時はそもそもお客さんにメールを送らせない」ということです。
したがって、ウェブ担当者が一番に考えるべきは「どのように障害をお客様に告知すべきか？」という点です。
障害が発生した場合も、下記が動いていれば様々に障害告知が可能です。
特にTwitterは連絡窓口として侮れないので活用しましょう。
またメール送信サーバーも、会社のセキュリティポリシーが許せばGmailの送信サーバーを使えるようにしておくと便利です。普段からGmailでも受信しておくと、万が一の時にもデータが消えずにすみます。
Gmailで会社のメールをセットアップする方法はこちらが詳しいです。
▼意外と知らないGmail！外部メールをGmailで送受信する方法 – tanweb.net
tanweb.net/2016/05/07/8229/
会社の代表的なアカウントを１つだけGmailで作成しておき、万が一の時はシステムからのメール送信をそちらに切り替える方法もあります。万が一返信されてもそのGmailアドレスであれば受信もできますので、一石二鳥です。ECサイトなどを提供している時には便利だと思います。
問い合わせ対応が必須であれば、専用のメール問い合わせ管理サービスを使っても良いでしょう。
本番サーバーにも503ページだけ用意しておきましょう。万が一の時はそちらのページが表示されます。
例）Web サイトのメンテナンス中画面の出し方 -dogmap.jp
dogmap.jp/2014/03/28/web-maintenance/
事前準備が終わったところで、ここからは、サービス停止の検知から対応策までの手順をお伝えします。
サービス停止を知る経路は様々だと思いますが、できればユーザーからのクレーム連絡で知るのは避けたいところです。
大企業でIT部門を保有している会社ではモニタリング（監視）という業務があり、監視ソフトウェアなどに費用を投じていますが、一般的な中小企業であれば、ウェブ担当者がその役割を兼任していることが多いと思います。
予算が潤沢ではない中小企業のウェブ担当者にオススメなのは、Googleアナリティクスをフル活用することです。
下記のようにすることで、障害発生時に気づける確率がぐっと上がるでしょう。
Googleアナリティクスのリアルタイムレポートを余っているパソコンで常時表示しておく。
Googleアナリティクスのカスタムアラートで、アクセス数が20%以上変動したらメールを飛ばすようにする。
▼カスタムアラート
support.google.com/analytics/answer/1033021?hl=ja
社内システムの障害については、社内の誰かが気づくパターンが大半です。
あまり神経質にならず連絡が来てから対処を考えるので良いでしょう。
障害がどこで発生しているのか調査をしていきます。障害発生箇所を知れば、そちらの会社に問い合わせることや復旧方法や告知内容を検討することができるからです。
なお、サーバー調査に慣れている方は、下記以外の項目も調査して障害の原因を探りましょう。
ウェブサイト閲覧者への影響範囲を調べます。
運営しているサイトごとに以下の観点で調べると良いでしょう。
社内システムのトラブル時は、特に社外の人へのアナウンスがポイントになります。
個別には電話やメールで連絡をとり、公にはウェブサイトで障害を告知することがほとんどでしょう。
従って、まずメールが稼働するかどうかを調べましょう。
レンタルサーバー障害が発生すると、メールが停止することも多いからです。
特に広告を出しているかどうかを確認しましょう。出稿している場合は停止すべきか判断します。
障害が1時間程度で終わりそうか、本番環境でFTPが稼働していて正しく503ページが表示されそうであれば、わざわざスタンバイ機に切り替える必要はないことがほとんどです。
サーバー会社に問い合わせても、まったく状況がわからず障害が長引きそうであれば、スタンバイ機に切り替える用意をします。
ドメインを管理しているお名前ドットコムなどにログインし、ドメインのネームサーバーをスタンバイ機のネームサーバーに切り替えます。
ネームサーバーセッティング
上記はXserverのネームサーバーが設定されている画面ですが、こちらをさくらサーバーに切り替えるのであればns1.dns.ne.jpとns2.dns.ne.jpに切り替えます。ネームサーバーのドメイン名は、スタンバイ機を借りているレンタルサーバー会社のヘルプに必ず記載してあります。復旧後は元に戻せるよう、現在の設定は覚えておきましょう。
ネームサーバーを切り替えると、いろいろな端末からのアクセスが順次スタンバイ機に切り替わるはずです。（最大３日程度かかることもあります）
スタンバイ機で、現状や復旧見込に関してHTMLに書き込み、アップロードしましょう。
またキャンペーンを実施している最中であれば、そのキャンペーンページだけ本番のバックアップから作成し、サービスとして提供してもよいでしょう。
サーバー障害が完了したら、また先ほどのネーム-サーバーを元に戻します。
ネームサーバーセッティング
しばらくすると本番に切り替わります。
無事、復旧が完了し一段落したら、最後に、今回の障害の影響を調べておきましょう。
Googleアナリティクスにはスタンバイ機で動いていたときのデータがたまっているはずです。そこから影響範囲を調べて、今後の対応を考えましょう。
今回は、万が一の時にWeb担当者が行うべき具体的な準備や作業についてお伝えしました。
とはいえ文中にも記載しましたが、やはりこのような状態を招かないよう、信頼が高い会社のサービスを使うのが一番の対策です。
手間を考えると、サーバーに対する投資額は、毎月数千円程度しか違わないということも多いです。
つまりアルバイトさんの数時間よりも安いのです。サーバーに対しては、少し高めでもよいので、ぜひ信頼度の高いサービスを利用されることをお勧めします。
「ムダな情報で頭脳を消耗することなく考える時間を確保する」
ウェブのノウハウだけに限らず、広告やマーケティング全般の知識、時には組織論や時事に至るまで、最先端や未来予測などみなさんにとって本当に必要な情報だけをお届けします。
