- ブラウザURL入力
- DNS名前→IP
- ルータ経路選択
- ロードバランサ振り分け
- Nginx受け口
- アプリ処理今ここ
- DB保存
前回、SLA を作るのは事業と法務だと原典が名指ししていることを見ました。今回は SLO から機械的に出る量が、何を許可する道具として書かれているかを読みます。
まず結論
エラーバジェットは「ここまで失敗してよい」という残量だと説明されがちですが、公開されている例示ポリシーはこれを罰ではなく、信頼性に専念してよい許可をチームに与えるものだと書いています。
同じ文書は、計算や行動で揉めた場合の手続きも定めています。数字そのものより、その数字に付いてくる手続きが運用を左右します。
公開されている例示のエラーバジェット・ポリシーは、この仕組みの目的を何と説明しているでしょうか。
当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。
残量の計算と、それに付いてくる手続き
前回、SLA を作るのは事業と法務であって技術者ではない、と原典が名指ししているのを見ました。では社内で完結する数字なら、技術者が決められるのでしょうか。
SLO が決まれば残量は算術で出ます(An error budget is 1 minus the SLO of the service.)。議論の余地が無いように見えます。
ところが、その量が何を許可するのかは算術では決まりません。
This policy is not intended to serve as a punishment for missing SLOs. Halting change is undesirable; this policy gives teams permission to focus exclusively on reliability when data indicates that reliability is more important than other product features.
罰ではない、と先に否定しています。permission(許可)が向く先は、失敗ではなく、信頼性の作業だけに専念することです。
文書が釣り合わせているもの
同じ文書は、何を釣り合わせているかも書いています。
Error budgets are the tool SRE uses to balance service reliability with the pace of innovation. Changes are a major source of instability, representing roughly 70% of our outages, and development work for features competes with development work for stability.
競合しているのは development work for features と development work for stability、つまり機能のための開発作業と、安定性のための開発作業です。人でも部署でもありません。
この構図を「開発部門 vs 運用部門」と言い換えると、原典に無い主体が入ります。1人のチームで両方を抱えていても競合は成立します。 争点は人手の向け先であって、立場の違いではありません。
Workbook 第2章は比較の手続きを示します。
By calculating the estimated impact on our error budget, we can determine which project is most beneficial to our users.
2つの案をバジェットへの影響で比べる書き方です。別々の言い分を同じ単位の1つの量に変換して並べられる——ここまでは原典の主張です。
「使い切ったら開発を止められる、つまり罰である」という理解を、この例示ポリシーはどう扱っていますか。
では、残量で揉めたら誰が決めるのか
1つの量に変換できるなら議論は終わるはずです。しかし同じ文書に Escalation Policy という節があります。
In the event of a disagreement between parties regarding the calculation of the error budget or the specific actions it defines, the issue should be escalated to the CTO to make a decision.
計算そのものについて意見が割れることを、文書自身が前提にしています。 最後は CTO の判断へ持ち上げる、と定めています。
前回見た SLA は事業と法務が作るものでした。社内で完結するはずの数字も、揉めれば経営の判断に行き着きます。数字は議論を消していません。持ち込み先を1箇所に決めているだけです。
この見方を採ると、Workbook 第2章が前提として並べる4つが読めます。
逐語 何を要求しているかall stakeholders ... have approved SLO を関係者全員が承認The people responsible ... have agreed 通常時に達成可能だと責任者が同意The organization has committed 意思決定に使うと組織が約束There is a process ... refining the SLO SLO を見直す手続きがある
4つとも計測の精度や道具の話ではありません。承認・同意・約束・見直しの手続きという、人の取り決めです。 同じ計算式でも、これらが無ければ前提を満たしません。
- ・線は SLO だが、代償を誰がどう払うかはポリシー文書の側にある
- ・公開されている例示ポリシーは、揉めたときの決定者を CTO と定める
数字が無い状態と、数字に歯が無い状態
Workbook 第2章は、システムの成熟度として3つの類型を挙げます。後ろの2つが対照的です。
2番目は A system in production with some monitoring to notify you when things go awry, but no formal objectives, no concept of an error budget, and an unspoken goal of 100% uptime。正式な目標もバジェットも無く、100% 稼働が暗黙の目標の状態。
3番目は A running deployment with an SLO below 100%, but without a common understanding about its importance or how to leverage it to make continuous improvement choices—in other words, an SLO without teeth。SLO はあるのに重要性も使い道も共有されていない——原文は an SLO without teeth(歯のない SLO) と呼びます。
2番目と3番目の差が、この回の要点です。3番目には数字があります。それでも歯が無い。 足りないのは計測でも計算でもなく、その数字を何に使うかの共通理解——先ほどの4つの前提が埋める部分です。
「バジェットがあれば、機能と安定性のどちらを優先すべきかが客観的に決まる」という理解は妥当ですか。
エラーバジェットの残量
残量は SLO から算術で出ます。しかし使い切ったときの行動はポリシー文書の側にあり、揉めた場合の決定者も文書が定めます。計算精度は関係しません。
決まること 決めているもの残量の値 SLO からの算術使い切ったときの行動 ポリシー文書解釈が割れたとき 文書が指名した決定者
SLA の未達(前回)
未達かどうかは測定で判定できます。しかし未達に伴う結果は契約文書の側にあり、その文書を作るのは事業と法務だと原典が名指しします。測定精度は関係しません。
決まること 決めているもの未達かどうか SLI の測定未達に伴う結果 契約文書その文書を作る人 事業と法務のチーム
社内の数字と、社外との約束。決まり方は違うように見えますが、共通する構造は何でしょうか。
「値が出たあと、次に何が起きるか」を決めているのが何なのかを、両方で探してみてください。
この章のまとめ
- 例示ポリシーの
permissionは「失敗してよい」ではなく 「信頼性に専念してよい」。向きが逆。 not intended to serve as a punishmentと明記し、Halting change is undesirableとも書く。凍結は前提ではない。- 釣り合うのは 機能の作業と安定性の作業。「開発 vs 運用」は原典に無い主体。
- 影響で案を比べられる、までが原典。揉めたら上位者の判断へ と同じ文書が定める。
- 前提は計測精度ではなく 承認・同意・約束・見直しの手続き。共通理解が無ければ
an SLO without teeth。 - 「使い残しも機会損失」は一次ソースに無い。原典が挙げる過剰達成の害は、利用者が実際の性能に依存すること。
自分の現場で確かめる
読んだだけでは身につきません。手元の環境で実際に見てみてください。
理解度チェック
読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。
公開されている例示エラーバジェット・ポリシーの `permission`(許可)は、何を許可するものとして書かれていますか。
用語集(4語)
- エラーバジェット
- SLO の裏側にあたる、許容される不達成の量。例示ポリシーは `An error budget is 1 minus the SLO of the service.` と定義する。量より、結び付いた行動の取り決めが運用を決める。
- エラーバジェット・ポリシー
- 残量に応じて何をするかを定めた文書。SRE Workbook は `Appendix B. Example Error Budget Policy` として一例を公開。標準規格ではなく例示。
- エスカレーション
- 判断を上位者へ持ち上げる手続き。例示ポリシーでは、計算や行動で当事者が対立した場合に CTO の判断へ委ねると定めている。
- 過剰達成 (overachieving)
- SLO を大きく上回る性能を出し続ける状態。SRE Book 第4章は、利用者が公称値ではなく実際の性能に依存する点を挙げる。