orangeitems’s diary

クラウドではたらくエンジニアの日々の感想です。

サービスレベルアグリーメント(SLA)というまやかし

f:id:orangeitems:20181102182230j:plain

 

サービスレベルアグリーメント(SLA)

サービスレベルアグリーメント(SLA)という言葉をご存知でしょうか。データセンターやクラウドが、サービス品質についてユーザーと契約を行い、守られていない場合は減額するという仕組みです。

 

cloud.watch.impress.co.jp

ニフクラのSLAでは、対象サービスごとに月間稼働率を定め、利用IDごとの月間稼働率が規定値を下回った場合、有償オプションサービス料金を除く当月度分の利用料金の10%相当額を、翌々月以降の利用料金から減額する。

 

もちろんSLAを設定することは、問題があった時の責任の取り方を明確化するうえでいいことではあるのですが、個人的にはこのSLAはまやかしにしか過ぎないと思っています。

 

起きるときは起こるし、損害が大きいときはSLAは役に立たない

SLAに99.99999%とか、100%なんて数字があると、じゃあ天文学的なイベントがない限りは絶対に大丈夫だね、品質が高いねなんて思うユーザーもたくさんいると思います。しかし残念ながら起こるときは起きます。

そして起きた時にどうするか。サービス料金を返しますがそれでも月額の10%程度です。月100万支払っているユーザーは10万しか戻ってきません。

ユーザーは実際問題が起こると、SLAベースでは話をしません。システムがその障害を起因として止まったとして、その機会損失を含めた損害賠償額を考えます。例えばそのシステムが1時間で5万売り上げるシステムなら、5時間止まったら25万が損失額と算出します。

この損害賠償という考え方と、SLAは全く食い違う概念で、「うちのシステム停止の影響はそんなもんじゃないんだよ!!」みたいな争いになるのが日常茶飯事です。2012年に発生したファーストサーバのデータ損失の際は、その産出額はそれまでに支払った料金の合計まで、という解釈が一般的になりました。

 

japan.zdnet.com

 

ですから、SLAなんて、大規模な障害に対しては、データセンター/クラウド側も、ユーザー側も何の役にも立たないことは覚えておいた方が良いかと思います。現実は、運営側の努力目標にしかならないと思っています。

 

堅牢性はSLAではなく、システム設計や運用品質を見ないとわからない

SLAなんて文字列に過ぎません。もちろん安定運用を続けて実績を出したからSLAの条件を厳しくし、顧客に訴えるというのは見せ方でしょう。でも過去に問題がないからといって未来にも問題がないというのは、これも信用できません。結局はどのように設計されたシステムか、運用しているスタッフの技術力や統制力、企業体の資本力など、総合的に判断しないといけません。

この業界に長くいると、SLAという言葉が非常に流行った2010年くらいのころからすると、かなり色あせていると思います。SLAの高さが未来の品質の高さを保証するものではなく、かつ有事の際に保証してくれるものでもないことは心に留めておくべきと思います。

私は、少なくともSLAは無視して、インフラを評価しています。

 

クラウド&データセンター完全ガイド 2018年冬号