メールサーバダウン

２０２２年３月１６日２３時より会社の使っているメールサーバのうちGMOクラウドのメールサーバがダウンした。１７日出勤するとメールが受信できないとの連絡が各部署から電話で入ってきている。HPともにアクセス出来ないため、Twitterにて情報収集するとGMOのサービスが大規模に停止しており、原因は３月１６日の福島県沖地震による停電という予想どうりの展開だった。会社のメールサーバは部署別に３つに分割されており、とりあえず１７日午後まで復旧の目途についてのアナウンスを待つことにする。午後になって復旧に手間取っていて、目途を早くて１７日夕刻とのアナウンスが公式ページに出たので、稼働しているメールサーバに各部署のアカウントを作成して１７日夕方に復旧しない場合は、各部署のＰＣのアカウントを設定してまわるとのアナウンスを説明しにまわった。１７日１７時にメールは復旧したので、用意したアカウントはしばらくそのままにしておくことにする。

外部にレンタルしたメールサーバが１日以上の障害を出したのは私が会社の情報システム担当になってから１７年間で２度目となる。１度目はファーストサーバというレンタルサーバ業者で、実に１週間の間、不安定な受送信が治らず、かなり大事になった。私はファーストサーバには見切りをつけ、手間はかかるものの別の会社のレンタルサーバに乗り換えで現在に至っている。今回も２日以上続くトラブルだった場合は、迷わず代替のメールサーバを探して乗り換えたと思う。

電子メールのシステムは実にトラブルが多く古いシステムだと思う。最近ではエモテットというマルウェアが猛威を振るっており、社内や取引先になりすましたスパムメールが届いて非常にやっかいである。これらのスパムメールは毎回送信元を変化させてくるため、規制の決定打がない状態だ。昨今社内連絡にはLINEworksやSlackなどのチャットツールを使うことが主流になってきているが、社外のとのやり取りはまだ電子メールに頼ること大である。

今回の障害ではＥコマース系の利用をしていないので、業務遅延以外の被害は最小にとどまったが、通販サイトなどのサーバが停まると実損がでて大事になってしまっただろう。会社では外部のＡＳＰ業者のサービスを使って１５０拠点以上の受発注システムを運用しているが、こちらも１７年間に６回の障害「運よく」実損には至っていない。ただし、こちらの受発注システムの運用では長時間停止した時に備えて、発注が出来ない時の納品数量を曜日別に事前に物流センターに提出し、６カ月ごとに見直す「自動発注」の仕組みを最後の砦として用意している。システムである以上、止まることはありえるとしても、止まったときのダメージコントールを考えて被害を最小にすることが情報システム部門としてやらなければならないことになる。

クラウドやSaaSの利用が進む昨今、いったいサービスを実現しているサーバがどこに設置されているのかは判らないことが多い。自社にサーバを設置している場合は「ホットスタンバイ」「コールドスタンバイ」など冗長化によってサービス停止のリスクを下げる試み行うが、クラウドの場合はどうすればいいのか、これからの時代の情報システムの頭の使いどころなのだろう。