クラウドサービスの人災についての続編
震災には強いけど、まだまだこの世に生まれたばかりなので取り扱う人間が不慣れで、現時点でのクラウドサービスのトラブルの殆どが人災によるものである。
と前回のブログで書いた続きになるが、基本的にオペレーションのミスが多発しており、サービス開始まで苦労する話をよく聞く。
ただ、N社のクラウド障害はちょっと尋常ではない。障害が5月初旬に発生し、長い間障害が続いており現在も続いている。結果サービス停止に追い込まれ、現在では新規受付を一切停止している。再開の目処は現在も立っていない。一説によると、機器の障害発生時のオペレーションにミスがあり、一瞬で全クラウドが停止してしまった様子である。 結果すべてクラウドサービスが停止してしまったとの事。また、想像の域を出ないレベルの話として、障害復旧時におけるオペレーションが冗長化されていなかった為に、2次災害の発生している事に気づかず、復旧作業が進んでしまったようである。で、結局誤った復旧が行われ、各ユーザから接続不可になり、停止まで追い込まれてしまったらしい。
これはレアなケースとしても、新しいサービスの黎明期には、大概、想定の範囲の外に問題がある。
なので、この手のサービスをいち早く軌道に乗せる為には、どれだけ、想定の範囲外すなわちレアケースを沢山経験するかである。大手サービサーの場合はこのステップの踏み方はコンプライアンスやブランド的に難しいとは思うが、中小規模のサービサーはレアケースの経験を沢山積んで、サービス範囲を拡充していく事が必要である。過去の経験上、ASPサービスは、マニアック?前衛的?マイノリティ?なサービスを提供してく事で、生き残る事が可能であるからである。
その為に、最初は苦労の連続か続くと思うが、黎明期のまだサービスの外郭(輪郭)がはっきりしていない、(後数年ではっきりしてくる)この時期に、レアケースを沢山経験しておきたいモノである。
ただ、一方で、こういったローンチ後のビジネススキームには、想定外の事が多い為、一瞬雑多な仕事が増える。それを、一般的な今までルールで進めるには到底無理が生じる。例をあげると、既に枯れているサービスの枠に嵌めようとする、もしくはサービスの枠にはまらない事をやらない。ないがしろにする。など、今までの一般的という枠の中で処理しようとすると大概トラブルになる。すなわちこれが「人災」。
「前例がないから分からない」→当たり前である。そもそもサービス自身に前例がない。
「ユーザの言っている事が、分からない。サービスに当てはまらない」→当たり前である。ユーザだった初めて使うサービスなんだから最初から我々が用意している「辞書」の中で会話してくれる保証はない。
こういった何処かで誰かがサービスに対して「消極的」に携わる事で、想定の範囲がどんどん小さくなり、結果サービスレベルでの「オペレーションミス」すなわち「人災」が発生する。
野球で言えば、外野の守備範囲がレフト、センター、ライトのそれぞれの線引きが定まっていない中で
皆が勝手に、レフト、センター、ライトの範囲を決めてしまい、それが外野の全範囲を守備しきれてなければ、そこに落ちたボールは、エラーになってしまう。
サービスが熟成されていれば、こんなミスも発生しないだろうが、現時点では、レフトであろうと、センターであろうと、ライトであろうと、外野の守備範囲は全部俺(個人)で守ってやる!ぐらいのモチベーションでサービスに取り組むべきである。その為に、守備が被る部分に雑多な仕事が増えるかもしれない。多く動き回るので体力必要である。視野角でも、漏れてしまうよりましである。結果、想定の範囲が増やせるのである。そして気づくと、他社では提供していない(できない)サービスが誕生するのである。そこまでの道のりはとっても大変ではあるが。。。。そうでもしないと、生き残れないと思う。多分。




