2012年12月アーカイブ

先日、クラウドサービスの階層型アドレス帳(Address look)が使えなくなった。

いくら正しいIDとパスワードを通してもログインができない。

開発元へ連絡をすると...

相手先の環境に不具合が生じた、と。後で連絡しますとのこと。

年末の慌ただしい時期だというのに...

しばらくしてから返答が来る。

どうやら「昨日より復旧しがたい問題が発生し、設定を初期化しなくてはならなくなった」とのこと。

「まずは復旧を最優先して参ります」とのこと。

ぉぃぉぃ...

ある程度バックアップデータを取っていたけど、完全なバックアップ取ってないよ...

NHKがこの日の朝に"最近はクラウドが人気だが、トラブルも続出している"という内容の放送をしていた。

ファーストサーバ事件(名前は伏せていたが、約5700もの企業が多大な影響を受けたと表現していた)の1件を受けてだと思うが

損害を受けながら返金が微々たるものであることに疑問を投げかけていた内容とも受け取れた。

それと識者が"クラウドサービスを信用しきってはならない"とも言っていた。

まさにそれが今日、起きた。

クラウドを信用しきってはならない。

午後になって簡易的な報告書が届く。

「テスト環境に行うべきオペレーションを謝って本番環境で実行してしまい、全てデータを削除してしまった。そのために設定内容が全て初期化されてしまった」とのこと。

まず...

・テスト環境を本番環境として行っていたこと(人為的ミス)

人だからミスを起こすのはしょうがない。

...が、ここはしょうがない、で済む問題ではない。

テスト環境を本番環境を間違えてしまう重大ミスを起こすほど開発環境に構造的な問題が潜んでいる。

この開発環境はテスト環境だ!という表記を誰でもわかるように表示しておけば済む話のはず。

運用は"誰でもできるように"しておかなくてはならない。例えそれが仕事ができない人だとしても。

それと、ミスを起こしそうになった際にフェールセーフ機能があってもよかったのではないか。

(データを全削除するのであればパスワードを求めるようにするとか)

・オンラインサービスを提供している会社がバックアップデータを取っていないこと(保守性リスクがリスクヘッジできていない)

この会社はファーストサーバの1件をこの会社はどう受け止めていたのだろうか。

対岸の火事程度に思っていたのだろうか。

同じミスをこの会社はやってしまっている。

CSOの人がそこまで考えてなかった(もしくはそもそもセキュリティ担当の人がいなかった)可能性がある。

・大規模な障害発生にも関わらず、ホームページで掲載していなかった

通信業界では障害が発生した場合、すぐに障害情報を出すようにしている。

これは電波法で定められているからこその運用になっているが

この企業では一切そのようなページがない。

障害が起きている場合の問い合わせ先がメールしかなかった。(私達は導入して頂いた方の名刺を持っていたので連絡ができたが)

オンラインサービスを提供している企業なのだから、24時間対応にして頂かないと困る。

・大規模障害を発生させておきながら9連休を取ろうとした

バックアップデータを渡したところ、サービス復旧対応は年明けの最初の営業日になる、と回答してきた。

障害発生日から11日後としている。

オンラインサービス提供は24時間年中無休で行っていなければならない。

自分の企業は年中無休24時間営業(年末年始も休みはない)だ。この実態を把握しているのだろうか。

1日単位とすると稼働が354/365となり、サービス信頼性が97%となる。こんなサービスがあるだろうか...

メンテナンスがあるのはわかるがこれでは不信感が高まるのは自ずとわかると思うのだが。

交渉の結果、年内の早い内に復旧してくれるようにしてもらったが...

これからの運用方法の見直しで、不信感を払拭できるくらいの対応策を出してくれることを期待する。

このアーカイブについて

このページには、2012年12月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2012年11月です。

次のアーカイブは2013年10月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

Powered by Movable Type 5.2