SLO（サービスレベル目標）の決定
モニタリングのデザインについてご紹介したところで、次はサービスレベル目標の決定に関する考え方をご紹介します。その前に、サービスレベルに関する用語の理解を皆さんと統一しておきましょう。
サービスレベルに関する用語
SLO、SLI、SLAといったサービスレベルに関する用語について、以下の表にまとめてみました。
| 用語 | 説明 |
|---|---|
| SLO（Service Level Objective） | サービスの品質に関する目標値 |
| SLI（Service Level Indicator） | サービスの品質を計測するための指標 |
| SLA（Service Level Agreement） | サービスの品質に関する顧客との合意。SLAを守れなかった時の対応（例：SLA違反月の月額利用料金の一部返金）を定めることが一般的 |
各用語のより詳細な説明は、Google Cloud Platform Japan Blogに投稿された「SLO、SLI、SLA について考える：CRE が現場で学んだこと」の一読を推奨いたします。
適切なSLOとは？
各用語の理解ができたところで、適切なSLOについて考えてみましょう。今回は、いくつかあるメトリクスのうち、稼働率（可用性）についてのみ取り扱います。
では早速、適切な稼働率を考えましょう。まず取り扱いたいのは、稼働率100%のSLOについてです。
稼働率100％のSLOの弊害
稼働率100％は、すなわち1秒たりともダウンタイムが発生しないシステムを目指すという意味です。これは一見、素晴らしい目標のように見えます。1秒もダウンタイムが許されないシステムであれば、100％の稼働率を目指すことは悪い目標ではないように思えます。
しかし、本当にそうでしょうか？ 稼働率100％を目指すとすると、最も避けるべきは、システムに新しい変更を加えることです。システムに変更を加えることは、システムの稼働に関する不確実性を加えることだからです。これまで無事に動いていたシステムも、新しい機能によって一部が壊れてしまう可能性もありますし、変更作業を加える際にオペレーションミスでシステムをダウンさせてしまうこともあるでしょう。つまり、システムの信頼性を究極に高めようとすることは、システムを更新しないことへのインセンティブが生まれます。
本連載の第1回で引用したGoogleの動画「What's the Difference Between DevOps and SRE?」でも、Agility（変更に対する機敏さ）とStability（システムの信頼性）は、トレードオフの関係であることが述べられています。100％のSLOに限らず、高すぎるSLOについても同様のことが言えるでしょう。「高すぎる」の基準は、みなさんが関わっているシステムによって異なります。
100％のSLOについて考えながら、SLOの値が高すぎることの弊害をご紹介しました。高すぎるSLOは、他の何かを犠牲にしてしまうことについてご理解いただけたでしょうか。
