はじめに
現在ソーシャルデータバンクでは、SLOを取り入れることで品質の管理をしていこうとしています。
しかしながら、私の方はSLOという用語は知っていても、どのように取り入れて管理していくのか知識が不足していました。
そのため、今回の記事ではSLOにとって重要な要素である「SLI、SLA、エラーバジェット」について調べたことを解説していきたいと思います。
（次回以降に実際の導入方法を記載したいと思います。）
また、今回は参考資料として以下の本を利用しました。
SLO、SLA、SLIとは？
ここではSLOと、SLOを構成する要素であるSLI、SLAについて解説していきます。
SLOとは
SLOとはサービスレベルの目標のことです。
わかりやすくまとめると、
- サービスを1年間に1回も止まらないようにする！！！（でも2年に1回くらいは...）
- お客様から問い合わせがあれば、10分以内に返信する！
- ファイルをアップロードすると、必ず1分以内で終わる！
など、自社のサービスが満たすべき具体的な目標を指します。これらを満たすことで、自社のサービス品質を保証できます。
SLAとは
SLAとはサービスの合意のことです。わかりやすく言うと、上記で記載したSLOを他の人たちと合意すること、です。
つまり、
- サービスを1年間に1回も止まらないことをお客様と合意する。
- お客様から問い合わせがあれば、10分以内に返信するとサービス資料に記載する。
- ファイルをアップロードすると、必ず1分以内で終わることマニュアルに明記する。
と言うことになります。こちらは法的な拘束力を持つこともあるので、SLAに記載する内容は吟味する必要があります。
（例えば単純にシステムが〇〇時間止まらないこと、としても他社システムの影響で満たせないこともある）
場合によってはSLOだけ定義し、SLAまで作成しないこともあるようです。
SLIとは
SLIとはサービスレベルの指標のことです。SLOやSLAを作成するために、実際に取得する指標のことを指します。
これまでの例から言うと、
| SLO | SLI |
|---|---|
| サービスを1年間に1回も止まらないようにする！！！ | サービスが停止した回数 |
| お客様から問い合わせがあれば、10分以内に返信する！ | お客様が問い合わせた時刻、最初の返信をした時刻 |
| ファイルをアップロードすると、必ず1分以内で終わる！ | ファイルのアップロード時間 |
となります。
まとめ
これまで説明したSLO、SLA、SLIをまとめると以下の図のようになります。
SLO、SLA、SLIの関係
実践する場合は、収集できる意味あるSLIを定義します。その後、SLIをもとにSLOを設定していきます。
また、顧客と合意する事項があればSLIをもとにSLAを定義していきます。
個人的には自社のサービスが目指すべき目標（SLO）を最初に決め、その後、SLOから収集すべき指標（SLI）を決めていくと思っていました。
が、先に意味あるSLIを決めるのが基本のようです。
（おそらく測定できなければ意味がないので、測定できることを確認してから目標を決めると言う流れと思いました）
エラーバジェットとは？
そしてここでは新たにエラーバジェットという概念が出てきます。
エラーバジェットとは、
信頼性を損失してもいいという予算のこと
です。
エラーバジェットが豊富にある、ということはSLIがSLOを上回っていると言うことです。つまり、先ほどの例をもとに説明すると、
- サービスを1年間に1回も止まらないようにする！！！
- ５年間一度も止まらなかった！！！
- お客様から問い合わせがあれば、10分以内に返信する！
- 平均の返信時間が5分以内！
- ファイルをアップロードすると、必ず1分以内で終わる！
- 実際は全て30秒以内で終わっている！
と言うことになります。大変品質の良い状況ですね😇
エラーバジェットを管理すると何がいいの？
ここでは、エラーバジェットを管理すると何がいいのかをまとめていきます。
まず、SLOの管理をすると必ず起きるのが、めんどくさいという発想です。
- 数値を計測しないといけないけど、数値を計測してどんな意味があるの？
- 目標を下回ったらあれこれ言われるので、数値をとりたくない。
- これをする時間があれば開発したい。
などなど...
SLOを導入することでサービスを可視化できます。
しかし、可視化できると言うことは、今まで見えていなかった悪い面も見えるようになる、ということです。
そのため、
- そのようなものを見たくない
- 見せてモチベーションが下がるくらいなら導入をやめては
という発想になり、うまくいかないことが多々あります。
そこを緩和する仕組みが、エラーバジェットとなります！
エラーバジェットは予算であるので、お金に例えるとわかりやすいと思います。
エラーバジェットがたくさんあると、お金がたくさんあるという状況になります。そしてお金があるなら使っていい！というのがエラーバジェットの本質です。
以下図の例から詳しく説明していきます。
SLO、SLI、エラーバジェットの関係
縦軸がSLI、横軸が時間を表しています。そしてSLIの指標の中に目標となるSLOが存在します。また、SLOとその時のSLIとの差がエラーバジェットとなります（赤線）。
エラーバジェットが高いと使える予算がいっぱい
今現在以下のような状況にあるとします。この時、エラーバジェットがたくさんあるので、予算がいっぱいあります。
エラーバジェットがいっぱいある
予算があるのでまずは使ってみましょう！
現在の開発体制が以下となっていたとします。
開発体制（簡易版）
では早速予算を使ってみましょう！
2回目のコードレビュアーに予算（賄賂）を持って行きます。すると、受け取った予算が良かったのか、2回目のコードレビュアーはレビューを受けずに工程を通してくれることになりました！！！
これにより、1つ工程をスルーしてリリースすることが可能となります。
予算を利用
少し時間が経つとまだ予算がありました。予算がある＝使って行きましょう！
予算がまだある
次はテスト工程の人に予算を持って行きます。すると、ここでも受け取った予算が良かったのか、テストを受けずに工程を通してくれることになりました！！！
予算がまだある
すると開発工程は、コーディング→コードレビュー（1回目）だけでリリースできるようになっています！
何が良くなった？
まとめると現在の開発工程はコーディング→コードレビュー（1回目）だけになっています。
これをさらに厳密にいうと、以下のような開発が現在行われていることになります。
皆様お分かりになったでしょうか？
コードレビュー（2回目）と検証担当者も開発に回ることで、単純に開発スピードが2倍になっていることがわかると思います！
つまりエラーバジェットを使うとは、
過剰になっている品質の予算を削り、開発スピードを高める取り組みを行う
ということです。
単純にSLOを導入しようとすると、前述に述べたような批判が集まります。しかし、そこにエラーバジェットを導入することで過剰な品質をやめて開発に集中できますよ、というメリットを提示でき結果として開発効率が良くなります。
個人的に思うSLOの導入メリットはここにあると思っています。
逆にエラーバジェットが低いと？
最後に「エラーバジェットが低い＝予算がない」とどうなるかを説明して行きます。
「エラーバジェットが低い＝予算がない」ので、予算を渡すことができなくなります。つまり、素通りしていた工程が復活することになります。
エラーバジェットがないので元に戻る
また、それでも予算が低い場合は、予算を高めるための活動をしなくてはなりません。例えば、コードの作成をぺプログラミングで実施し、予算を確保できるようにします。
エラーバジェットがないのでペアプログラミング実施
まとめ
今回SLO、SLA、SLI、エラーバジェットの関係を説明いたしました。単純に数値を取るだけではなく、エラーバジェットのような開発に還元できる取り組みを行うことで、開発体制の効率化が実施できると思います。
とはいえ複雑なSLIを導入しても管理が大変ですし、意味のないSLOを導入しても品質は上がらないでしょう。
次回から、実際にSLO、SLA、SLI、エラーバジェットをどうやって決めれば良いのか、を学んでいきたいと思います。
ある程度まとまりましたら、次回は導入編を書きたいと思います。
Discussion