SLOとエラー予算
サービス品質の定義として SLO (Service Level Objective) を整理しました。
エンジニアリングに関わる項目が多く、素早く計測できる仕組みも必要となるため、エンジニアが整理する方が良いです。ただし、SLO はシステム的な話ではなく、利用者から見た体験に影響するため、ビジネスを含む全体を視野に入れて整備が必要です。
SLO 設計
ざっくり『システム』『サポート』『データ』『セキュリティ』の4分類で整理すると概ね良いと思います。各項目を網羅するよりは、全体感を持ちつつ小さくすぐに始めやすい内容にまとめたつもりです。
契約に含めるSLA も関係するので表にして、どの指標がSLA やSLO に含まれているか明記すると良いです。
システム
サービスを快適に安定して提供する責任です。よくある評価としては『可用性』『信頼性』です。
- 可用性
- サービスが利用できる時間の割合を表し、主にサービス稼働率で評価します
- 信頼性
- 「障害の発生しにくさ」を表し、サービスが使えなくなる頻度や間隔（平均故障間隔）で評価します
サポート
サービス利用者からのお問い合わせやサービスの障害に速やかに対応する責任です。
データ
サービス継続性を確保するために、重要なデータをバックアップしリストア可能な状態を保つ責任です。
セキュリティ
サービス全体のセキュリティを担保し、様々な脅威からサービスや情報を守る責任です。社内の業務運用や内部監査も重要な観点になります。情報セキュリティマネジメントシステム（ISMS）やプライバシーマーク (Pマーク) などの第三者認証や個人情報保護士の資格などもわかりやすい基準になるので活用すると良いと思います。
用語定義
- SLI (Service Level Indicator)
- サービス品質を客観評価するための指標で、計算式が定義されたもの
- あくまでも指標なので、具体的な数値はありません
- 例: 月間稼働率、システムの応答速度、お問い合わせの平均応答時間
- SLO (Service Level Objective)
- SLI に具体的な目標数値（定義域）を定めたもの
- 下限値と上限値は片方だけでも良い
- 例: 月間稼働率99.99%以上、システムの応答速度50ms以内、お問い合わせの平均応答時間15分以内
- SLA (Service Level Agreement)
- 利用規約等の契約に明記されたSLO で、定義域を外れた場合の補填が定められているもの
- 例: 月間稼働率95.0%未満で利用料金100%減額
SLIとSLOとSLAの関係性
SLI = 指標（計算式）の定義
SLO = SLI + 目標（上限と下限の定義域）
SLA = SLO + 補填（請求金額の減額や返金の規定）
SLAは契約に関わるため、社外に公開されます。SLOは社内だけに共有される目標になりますが、一部もしくは全部を社外に公開しているサービスもあります。例えば、サイボウズは運用環境(SLO)で具体的な数値を公開しています。
社外に公開する目標と、社内の内部目標のような区別が必要であれば、SLO定義の一覧表の中でまとめて整理しておくと良いです。
目標に利用する数値の種類
具体的な目標に使う値は概ね下記の4種類あたりで最適な値を検討すると良いです。
- 数値 (任意の単位)
- 固有単位で絶対値として使う
- 例: 15分、50ms
- 割合 (%)
- 分母と分子それぞれの指標を明確にすること
- 例: 稼働率（動作した時間 / 全体の時間）
- 頻度 (1/時間)
- 例: 毎日1回、週1回、月1回、年1回
- 期間（時間）
- 例: 30日間、90日間、1年間
エラー予算 (Error Budget)
SLO は達成目標でありながら、リスクを何もとらずに現状維持すると達成する可能性が高いです。そこで『エラー予算 (Error Budget)』という考え方が重要になります。
「いつでも、どこでも、快適に使える」ということがサービスの信頼性100%だとすれば、エラー予算は下記の定義となります。
エラー予算 (Error Budget) = 1 - SLO
細かいところは、エラー・バジェットによるリスク管理を見てください。
エラー予算は、事業管理（売上やコスト）と同様に適切に消化する必要があります。予算に対して100%が最高ですが、120%の超過達成や70%の未達は歓迎されません。指標にもよりますが、概ね ±5%程度の誤差が許容範囲になるかと思います。
エラー予算をしっかり消化したのに、「サービス障害が多すぎ！」と言われたら予算の決め方が間違っています。逆に、エラー予算を残して使わなかったら「エラーが発生していないのはおかしいです。どこに問題が起きてますか？」と確認した方が良いです。
無意味にサービス停止する必要はなく、利用者が困惑するエラーを無鉄砲に発生させる必要ももちろんないです。ただ、新しい取り組みを十分に実行できていない可能性があります。 SLOを定義することは「一体どれくらいサービスの信頼性を損ねても利用者が解約しないのか？」を決めることです。
おもてなしの発想で「我々のサービスを利用者が好んで選ぶために必要なサービスの信頼性はどれくらいか？」は過剰サービスにつながります。もし利用者に「我々のサービスにはどれくらい信頼性が必要ですか？」と聞いたら、おそらく「100%」と答えるのではないでしょうか。これでは、エラー予算は0で、一切のミスが許されない状態となります。
要するに、利用者の解約理由を数値で計測できていないと適正な予算が立てられません。利用者が解約する判断材料となる事象を指標の変化として捉えることが必要です。いわゆる遅行指標（解約率）に対しての先行指標を発見しているか否か。SLOの定義は事業数値 (KPI) と密接な関係にあり、システムの稼働率やレスポンス速度など技術的な話ではありません。
一方で、最初から正確な指標や数値の予算を組み立てるのは難しいです。はじめは適当にでも決めて、達成率70%とか大幅な予実差が起きても良いです。予算設定→実績計測を繰り返すうちに予実差が徐々に少なくなり、最終的に許容範囲内の適切な予算が組み立てられるようになるまで根気強く続けましょう。
カスタマーサービス (CS) のエラー予算
顧客満足度も100%を目標にせず、80%〜90%を目標にするなど上限を決めると良いです。
利用者は人なので、一人一人の感覚が異なります。あっさりした対応でも「満足」と評価されることがあります。お客様の要望を先回りしながら丁寧に対応し、多くの人から見ても完璧なおもてなしでも「不満」と評価されることもあります。
よく考えずに顧客満足度の向上を目指すと、良かれの空回りが起きます。顧客対応するCS担当者に不必要なプレッシャーとなります。気を抜くとサービス提供者からすると多くのお問い合わせの内の1件と見てしまうこともありますが、利用者からすれば2度はない1件です。1件1件それぞれに対して適切な緊張感を持って対応することは重要ですが、適切な上限を設定することで健全なゆとりができます。
参考資料
エンジニアリングの話であれば、SRE (Site Reliability Engineering) 関連の書籍を読むと良いです。 より詳細な指標を網羅したければ、下記のドキュメント等を見ておくと良いです。