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

Katsushi Yamashita, IBM Distinguished Engineer, Member of TEC-J - IBM Academy of Technology

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交渉とかしてる前にやること一杯あるでしょ。