概要

SLI/SLO導入後の運用で手こずる組織の共通課題について、実体験をもとに分析した連載企画の導入記事。

主要な問題提起

SLI/SLOは導入自体は簡単だが、運用段階で多くの組織が困難に直面することがある
「一筋縄ではいかない」現実：設定しても消滅、なんとなく運用、ただあるだけの状態

根本原因の仮説

立場によるSLOへの認識の違いが運用を複雑化させている

認識ギャップの具体例

SRE: とりあえず設定が必要
開発責任者: KPIとして99.x%を死守すべき
開発者: SREの手伝いをすればよい

結論

SLOがあってもサービスが自動的に安定するわけではない。数字が勝手に何かをしてくれるわけでもない。合意形成の範囲内で正しい共通認識が取れていないことが、運用失敗の出発点。

連載の方向性

今後、SLOの適切な導入・運用方法について考えをまとめていく予定。yuuk1氏監修のもと、実践的な解決策を段階的に展開。

詳しくは Re:ゼロからもう一度考えるSLI/SLO | 連載第0回：運用課題の正体 - Topotal Blog をチェック

完璧である必要はない

SLO サービスレベル目標の「はじめに」の章では、面白い例が載っています。

この著者が同書を執筆に同意したあとすぐ、ニューヨークで散髪していたそうです。そこのスタイリストと仲良くなったので、髪を切ってもらいながら同書の話の主旨を話したようです。

「あなたは完璧であることはできませんし、いずれにしても誰もあなたが完璧であることを必要としていません。完璧であろうとすることはコストが掛かりすぎます。このことを受け入れれば、最終的には誰もが満足できるようになります」

すると、そのスタイリストが本人が駆け出しだった頃の逸話を話してくれたといいます。

すべてのことを何もかも完璧にしようと集中するあまり、普通なら30分程度で済むはずの男性の単純な散髪に、1時間もかけることがありました。
（中略）
完璧を目指そうとすると、散髪するのに時間がかかりすぎてしまい、次の予定があるお客さんを怒らせてしまいました。彼女のはキャリアを重ねるに従って、完璧を目指すことは、誰のためにもならないことを学びました。
（中略）
ある程度の完璧さ（言い換えれば、一定の割合の完璧さ）を目指すだけで充分であることを学習しました。各顧客にかける時間を短くすると、頭髪が左右対称でなかったり、均整が取れていなかったりすることがありました。
（中略）
ここでの教訓は、彼女が目指す目標や結果を変えたとしても、顧客たちは誰も気にとめていないことです。もともと、彼女の散髪は驚くほど素晴らしかったのです。
（中略）
彼女は怠けるために、アプローチを変えたのではありません。彼女が変えたのは自分の厳格さであり、そのほうが顧客により良いサービスを提供できるとわかったからでした

このスタイリストは、自身が完璧を目指すよりも一定基準以上のクオリティであれば許容するように目標を変えました。結果的に、短い時間での素晴らしい散髪は顧客は満足度を上げ、店の回転率にも貢献しています。

完璧を目指さないことで、すべての関係者がより満足できる形になったという例です。

このお話は「ある意味、この話は本書の主題の要約」と書かれています。

理想的な状態をすべて叶えるのは、コストが高すぎる
提供側が完璧を目指そうと目指してなかろうと、顧客には一切関係がないし、気付かない
完璧よりも一定のクオリティを維持しつつ、顧客が必要としていることを考える

この例は実にシンプルでわかりやすい例だと思っています。

また、身近な例で言えば車の自動ブレーキ（衝突被害軽減ブレーキ）も、ユーザの操作ミスを前提としたシステムです。ヒューマンエラーを許容（人は完璧であることはできないため）しているが、実際にその事故は未然に防ぎたいのでブレーキシステムが組み込まれています。

参照: xiiページ www.oreilly.co.jp

完璧を目指さない。では、何を許容しますか？

私たちが運用しているサービスにも同じことが言えます。完璧である必要はないのです。

では、その中で何をどこまで許容しますか？

SLI/SLOを導入・運用する上で、これは重要な問いです。

100万リクエスト中100万リクエストが完璧に応答できることを目指すことはできません。どれだけ努力しても、ユーザ側のネットワークの問題や操作の問題をカバーすることはできないからです。また、パブリッククラウド上にあるサービスの場合、そのクラウドベンダーよりも堅牢なサービスを構築するのが容易でないことは明白です。

今回のポイント:　SLI/SLOを導入する際、まずは「何を許容するのか」を認識合わせしておこう

跋文

VTRyoがSREを始めた頃、Googleが提唱した SRE サイトリライアビリティエンジニアリングを読んで、「いやーこれ全部やるの？無理じゃない？」と、率直に思ったことをよく覚えています。

2017年から18年頃、まだ私は駆け出しのエンジニアでその内容量と難解な概念を見て悲鳴を上げただけとも言えます。しかし、今もう一度見ても「やっぱり、この教科書通りにすべてをやるのは難しい」と思っています。なぜなら「私たちはGoogleと同じ環境、人、カネといったリソースを持っていないから」です。

理論やアプローチは、その人が置かれている環境や条件によって変えなければ意味がないでしょう。つまり、サイトリライアビリティエンジニアリング一つとっても、教科書通りの完璧である必要はないのです。

現在の私が意識しているのは、「信頼性を必要としている対象が必要としていることは何か」をよくよく理解し、関係者とすり合わせることです。Googleの例に囚われすぎないことで、多くのことに応用できるはずです。

散髪や車のケースから見ても、SLOの先にいるのは「人」であることを考えさせられます。私たちの生活を豊かにするために存在している以上、最終地点は人であることを忘れないようにしたいですね。