イノベーションの風に吹かれて

山下技術開発事務所 (YAMASHITA Technology & Engineering Office, LLC)

田舎に住みますか、都会に住みますか

都会に住みますか、田舎に住みますか

あるプロジェクトの意思決定において。「クラウドへの移行を費用視点で詳細に分析した結果、今までのサーバーと同じ性能容量を確保する場合、クラウドに移行するよりも中古機を買って運用した方が安いので、クラウドへの移行は致しません。」と言われ反論する気が無くなった。新しい取組みに反対する人はいつもコストでしか反論しない、本心はやりたくないから規定通り工夫もなくコストを積んでるだけなのに。新しいテクノロジーがもたらしてくれる価値の増分には目を向けず、これまでと同じことを安くできることしか考えないという姿勢を崩さない。進歩が止まる瞬間だ。

こういうのって移動の基本が公共交通機関の都会に住むか、一時間に数本のバスも運行できないような中古の軽自動車だらけの田舎に住むかの判断だ。都会に住むのは共有のサービスが充実していて、自分で持ってなくてもサービスを買うことで便利な生活をしたいからだ。単位距離あたりの移動コストの比較じゃない、ライフスタイルの問題だ。ダウンタウンに出かけて飲んで電車で帰りたいから都会に住むんだよ、田舎にしか住んだことの無い人にはわからないよ。ICカードでさっと電車に乗り、利便性のためにみんなでコストを負担して電車やバスをシェアする。それに大規模な工場の引き込み線でもない限り電車に乗りたいからって言って電車作る人も居ないでしょ。

もういい加減にコスト比較しかできない能力の人にIT投資判断させるのやめよう。

Service Level Agreementとか

可用性なんてサービスの品質を向上させる上であまり役に立たない。契約、約款におけるSLAはサービス提供時間に対する保証契約の時間割合を示していることを正しく理解したい。サービスの見える化やサイドレターの撲滅には役立つがシステムの信頼性設計は別の対処が必要だと思う。

 

 

単体のハードウェアの信頼性でサービスの可用性を論じちゃいけないけど、可用性が契約した時間に対するサービスされている時間の割合であってシステムが故障しない確率じゃないということを説明するために、単純な例を一つ。MTBF平均故障間隔)35年の化け物みたいなマシンがあってMTTR平均修理時間)を8時間としたら可用性は99.997%です。満足ですか?このマシンを5年運用したときに故障する故障率はどのくらいかというと、だいたい15%です(詳細は信頼性計算とかの基礎的な算数をググってみてね)もちろん0.003%なんかじゃありません。導入した翌日に15%の確率で8時間停止するマシンの可用性は99.997%です。SLAで99.99%を求めてもこけるときはこけるんです。

それよりサービスプロバイダーの情報公開に基づいてして即時に対応できるFailure Based Designを徹底するほうがいいと思うんです。「サービスプロバイダーなんだからSLA99.99%でやってよ」って言っていても落ちるときには落ちる。それより責任ある情報公開に基づいて、自ら自信の持てる運用を作るほうが「自分の責任で努力できて」いいんじゃないの?
それにどんなにシステムが障害起こしてもサービスが止まらないような運用設計してたらさ、SLA高くて単価の高いインスタンスなんてナンセンスなんだよね。止まったら即座に他で動かす様にしたらいい。

フロントエンドのアプリケーションとバックエンドの障害を切り分けて、動くところを探して運用できるステートレスなアプリケーションデザインを採用したり、ダッシュボードとモニタリングの絶え間ない改善とか、サービスプロバイダーのSLA交渉とかしてる前にやること一杯あるでしょ。