PR

 二つ目のダウンタイムの最小化とは、システムダウン時の復旧作業をシンプルにしたことだ。具体的には「予備のサーバーをあらかじめ複数作成しておき、障害発生時は1秒でも早く丸ごと入れ替える」(山本氏)といったものだ。一般的な障害対応である、異常が発生したサーバーにSSH(セキュアシェル)接続し、原因を探って、再起動などの対応作業をする――といった手順はすべて飛ばす。

 こうした復旧策が取れるのは、同社がパブリッククラウドを基盤に使っているからだ。システムはAmazon Web Servicesの仮想マシン「EC2」を中心に構成している。予備機となるサーバーを作成して「STOP」(電源オフ)しておく。占有するストレージ分の料金は掛かるが、EC2の料金は掛からない。

 特に有効なのは容量不足でダウンした場合だ。「AWSはスケールアウトは素早くできるが、スケールアップには時間が掛かる」(山本氏)。サーバーの性能を上げるには、サーバーをいったん止めて作り直さなければならないからだ。そこで、性能が高い予備サーバーを作って、待機させておく。

 三つ目の連絡体制の整備は、コールセンターによる電話サポートを用意するといったものだ。飲食店や小売店は営業時間中にパソコンを見る機会が少ない。Webサイトで「お知らせ」を出しても見てもらえないのだ。メールによる配信は、システムダウンの通知に使うにはタイムラグが大きすぎる。山本氏は「どうしても電話対応が必要になる。初期にはそこまで考えが及ばず、ユーザーから叱られた経験もあり、今の体制に落ち着いた」と言う。

 システムを止めないのではなく、障害を全体に波及させないことを考える。システムダウンしても1秒でも早く復旧できる方法を用意しておく。ユーザーの利用実態に即した連絡方法を用意しておく――。プラグラムの取り組みは示唆に富む。現場によって使っているITインフラやユーザーの特性が異なる。そのまま使えるものではないかもしれないが、参考にすべきアプローチだ。