エンジニア界隈で「SRE本」と呼ばれる、Googleでのサーバー管理に関する考え方などが紹介されている本がある。「SREサイトリライアビリティエンジニアリング」というこの本は500ページ以上あり、かつB5サイズというので気が乗らなかった。
直近仕事でSLAについて会話する機会があり、読んでみたところ「なるほどな」と思ったことがあったので、備忘録も兼ねてSRE本で紹介されているSLAの考え方についてブログに記載しようと思う。
SLAは「顧客と同意したサービス提供レベル」だが、なぜ顧客と合意しなくてはならないのだろうか
IT業界に従事している方であれば「SLA」という単語は聞いたことがあるかもしれない。SLAとは「サービスレベルアグリーメント」のことで、サービス中断時間が１ヶ月にXX時間を超えたら返金しますよ、という類の契約のことである。Biz系や通信系のサービスに設定されていることが多い。
https://line-works.com/terms/line-works
https://www.anpikakunin.com/sla
SLAなどとWEBで検索すると「ビジネスの改善に役立ちます」といった記載もあり、「我々もSLAを導入しなくては」であったり「自社のサービス運用監視のSLAは。なければ定めよう」という動きがあったりするケースは往々にしてある。
SLAは、サービス提供者と利用者の間で透明性と信頼性を確保し、サービスの品質向上や問題解決を促進する役割を果たします。適切なSLAの策定と遵守は、ビジネスの効率性や顧客満足度の向上に貢献します。
SLAには具体的な目標や基準が含まれるため、定量的な評価や監視が可能となり、サービス提供の透明性や効率性を高めることができます。
ただ、果たしてSLAは必要なのだろうか。
社内改善の目的なら、SLAではなく、SLOを定めよう
SRE本では、SLAではなくSLO（サービスレベル目標）を定めましょう、という指摘があった。
これは顧客と合意するのではなく、内部的にXX％の可用性を担保しますよ、というのをチームの目標として動くというもので、違反したからといって何かがあるわけではない。
何がいいかというと、SLAだと顧客だったり営業だったりと「約束」するが、SLOは破ったところで金銭面での損害を会社に与えないということだ（もっとも、障害が多ければ顧客が離反することはもちろんあるとは思うが）。
99.9%の可用性をSLAで認めるとそれを実現するために多くのハードウェアが必要になるケースがあるが、目標なのであればハードウェアを無駄に導入せずとも運用でその数値を達成できるように頑張りましょう、となる。SLAは破れないので実際には99.99%の可用性を担保する方向に動く（＝過剰投資）が、そのリスクを大幅に軽減することができるのだ。
そもそも論、何を測定するかをSLIとして決める
SLAというと「XX%の可用性」という表現が目につくが、そもそもこの「XX％」が「サービス稼働時間」の全体に対する割合であると決まっているわけではない。実際にGoogleのとあるチームでは稼働時間の割合ではなく、成功するリクエスト数の割合で定義している（この「基準として見る指標」のことをSLI（サービスレベル指標）と呼ぶ）、という話があった。
そう言われればそちらの方がいいかもしれない。平日の朝に非常に使われその後は少ししかトラフィックのない（かつ深夜にはリクエストがない）システムでも、稼働時間を確保するためにたくさんマシンを準備しなくてはいけないのだろうか。極端な話、夜間はリクエストがあったら起動するようなシステムでもいいのではないだろうか。
稼働時間、という単語に引きづられて、無駄に高い目標であったり場違いなものを指標にすることがないようにしたい。
コメント