SRE: Reaching Beyond Your Walls
GoogleでSREの実践を始めて14年経過
最初のSRE本を出してからのこの2年間は興味深かった
SREを実践する人や企業が想像以上に増えた
Google以外のエコシステムの拡大とSREの将来の予測の難しさ
この章ではこれまでに見てきたことと結論づけたことを記載
「あらゆるシステムにおいて、信頼性はもっとも重要な機能である」と言っても誰も反対しない
論点はシンプル
システムに信頼性がないと、ユーザーはそれを信用しません
ユーザーがシステムを信用しないなら、もし使用できる選択肢が与えられてもそれを使用しません
すべてのソフトウェア・システムはネットワークによって成り立つため、もしシステムにユーザーがいなければそれは無価値です
You are what you measure(?), 測定基準を慎重に選ぶこと
モニタリングシステムではなく、ユーザーが信頼性を決定づける
信頼性の尺度は、ユーザーが信頼性をどのように体験するか
「モニタリングシステムは問題ありません。あなた側に問題があるはずです。」といってもユーザーは嬉しくない
安定性の無いシステムとして体験しており、競争相手と選択を迷った際に覚えているのはこのときの体験
ピーク・エンドの法則
監視、ログ、アラート
これらはユーザーが問題を気づく前に問題を教えてくれる場合のみ価値がある
プラットフォームを運用している場合、信頼性はパートナーシップとなる
システムが視覚的（例: Webページ）でユーザーが人間のみの場合は、SREの仕事がユーザーが体験する信頼性に結びつく
しかしAPI追加をして「ユーザー」の一部がマシンになる場合は、プラットフォームを運用することになりルールが変わる
信頼性はパートナーシップとなる
99.999%の可用性でシステムを運用していても、ユーザーのシステムが99%以上の可用性を達成できなければ98.9901%が最大
たとえ「あなたのせい」でなくても体験したことについて責任があると考える
システムの価値はユーザー数とともに増加する
あなたは他の大きなユーザープールを求める
他のソフトウェアシステムもあなたのユーザープールを求める
他社のマシンが自社のマシンとAPI使って通信を開始するのはこの時
たとえマシン用のAPIを作らないと決めていても避けられない未来となる
他の人々があなたのシステムのUIをラップ してマシン向けAPIとして利用するかもしれない
唯一の違いは結果を管理できないことだけ
システムが多数のユーザーへのゲートウェイになると、価値が高まる
公式、または非公式のAPIが将来的に作られることになる
顧客が苦労している時、その不満はあなたに向かってくる
チケット、メール、電話
StackOverfrow、Twitter、Facebook、その他SNSへの回答
顧客の支援にエネルギーと投入しても、システムが良くなるわけではない
「やった！ 社内プラットフォームチームに所属しているからこれは当てはまらないぞ」と考えるかもしれない
あなたのプラットフォームを用いて信頼できるシステムを設計・運用してほしい場合
その方法を教える必要がある
もちろん社内の顧客も含まれる
仮に完璧に設計・抽出できたとしても、どんなコンテンツやトレーニングを含めるか把握する方法が必要
プラットフォームの成長と改善とともに、これらの教えは変わる
これらのリソースが古くならないように防ぐ方法が必要になる
これら教えを学ぶ最良の方法は顧客と「SREをする」こと
必ずしも顧客のページャを引き受けるという意味ではない
少なくとも代表的なサンプルユーザーに関して、ページャの引き継ぎにかかる作業のほとんどを引き受ける必要がある
システムが最小の信頼性の要件を満たしているということを意味している
顧客とともにSREをするのは難しく思えるかもしれない
そもそも自身だけでもどうするかわからないからこの本を読んでいる
それでも両方を同時に行うことは可能
一緒にすることで、自分だけですることもうまくなる
顧客がSLIを測定しSLOに対してアラートを設定していて、さらに測定値があなたと共有されているなら、とても良い
そうではない場合、以下のような会話に多くのエネルギーを消費してしまう
[顧客]
XというAPIの呼び出しには通常T時間かかります。しかし、今はU時間かかっています。何か問題があるんじゃないでしょうか。今すぐ調査して結果を教えてください。
[あなた]
そのパフォーマンスは想定内で、私たちのシステムは全てが正常で問題ありません。もしXというAPIの呼び出しにそのくらい時間がかかると何か問題がありますか？
[顧客]
わかりません。通常はこれほど時間がかからず、明らかに何かが変わっているので心配しています。
会話がループし、満足のいく回答に達することはない
問題はないと顧客に納得させるために時間を費やす
または根本原因のために多くの時間を費やし、顧客を納得させるか
どちらにせよ、多くの労力を割く必要がある
根本的な原因は、パフォーマンスを判断する指標としてSLOを使用していないこと
もし明示的なSLOがない場合、顧客がそれを作ってしまい、その基準を満たさなくなるまで言うことはない
[顧客]
アプリケーションFOOのSLOをとても早く消費してしまって、アプリケーションが危ない状態にあります。
SLIのYとZが急落しています。YとZは両方ともあなたのAPIのXに依存しています。
[あなた]
わかりました。私たちのシステム上でAPI Xの性能がどうなっているか、そしてお客様への性能がどうなっているか調べてみます。
はるかに生産的な会話になっている
(a) SLOが脅かされている場合のみ発生
(b) お互いに理解しているメトリクス（SLI）とターゲット（SLO）を使っている
SREの実践によってシステムを運用している場合、社内でSLOを使って話す
もし顧客もSLOを使って話してくれるなら、お互いにとって楽になる
顧客とよりよい関係性を築くために、シンプルなエクササイズをおすすめしている
顧客と一緒に話し合うこと
SLO、SLI、エラーバジェットについて説明する
特にあなたがチームでそれらを実践している方法について
そして、あなたのプラットフォーム上に構築した重要なアプリケーションについて、それらの用語を用いて説明することを手助けする
ステップ2: モニタリングの監査と共有ダッシュボードの構築
顧客が基本的なSLOを選んだら、次は目標を満たしているかどうかを決定するための正しいものを測定している かどうか
その特定値が適切かどうか、顧客が把握することを助ける
経験上、顧客が測定しているものの内、最大半分はSLOに対して全く意味がないもの
それらを指摘して、顧客が不快なアラートを切ることによって人生が良くなる
顧客のオンコールアラートが減り、あなたのも減る
残った測定値はSLIの有力な候補値となる
最後に、顧客と共有のSLOダッシュボードを構築する
顧客のアプリケーションのSLOを見ることができるべき
そしてあなたのシステムパフォーマンスについて、顧客が体験していることに関する情報を共有すべき
顧客からSLOの浪費に関する問い合わせがあった際に、追加の情報交換が必要ないようにすべき
共有のモニタリングにすべてその情報が含まれているべき
計測値を整理した後、1,2ヶ月間データを収集する
顧客が 99.999% の可用性で運用できると思っていても、新たなSLOの元では99.5~99.9% しか達成できないかもしれない。
顧客のサービスのユーザーがその状態でもずっと怒っているわけではない
99.999%が本当に必要ではなかった
重要なことはユーザーがそのパフォーマンスにどの程度満足しているのか
もう少し改善の必要があると顧客が考えている場合は次のステップへ
顧客と話し、顧客のアプリケーションがどのように設計され、運用されているか理解する
隠されたSPOFがあるかどうか
ロールアウト・ロールアウトは手動なのかどうか
自身の社内アプリケーションに対して行うのと同じ演習をする
次に、消費するエラーバジェットによってイシューをランク付けする
これらのレビューから学べること
顧客がプラットフォームをどのように利用するか
顧客が信頼性に関するどんなミスを犯したのか
トレードオフとして顧客が何を選ぶのか
信頼性について、顧客が現実的な期待値を設定するのに役立つ
最後のステップは顧客と運用上の困難を作り出すこと
緊急時に効率的にコミュニケーションする方法を体で覚える
お互いへの信頼
MTTRの減少
エッジケースへの学び
インシデント発生時
上記ステップの実行はすぐに不可能になる
数%の顧客だけ
全員に対して行ってはいけない
どのように選択するか
収益カバレッジ
収益のXX%を占める少数の顧客を選択する
収益の大部分が少数の大手顧客によって占められているなら正しい選択となるかも
機能カバレッジ
プラットフォームの機能のXX%以上をカバーしている少数の顧客を選択する
多種多様なプラットフォームを展開しており、様々な顧客がロングテール担っている場合は良い選択かもしれない
ワークロード・カバレッジ
プラットフォームがいくつか少数の使われ方・タイプになっている場合
顧客1人1人はそれほどでもない
グループをコホート化し、各コホートから1,2つの顧客をサンプリングする
プラットフォームのカバレッジと、ユースケースによる運用上の違いを発見することができる
どのアプローチを選択しても、それに執着してはいけない
SREはGoogle以外にも大きく広がった
原則がGoogle内でどのように発展していくかもあるが、それより外部で発展していくことに対してワクワクしている
SREの原則を組織に適用すると...
多くの変曲点が交差する
Googleも同じ
自身と顧客との境界線をぼかす必要性もでてくる
深い業務レベルで顧客と関わることは、価値のある新しいフロンティア
