私がデザインドキュメントに書いたすべてのレイテンシバジェットは、静かにwikiの 片隅で腐っていった。生き残ったものは巧妙ではなかった — 一つのエンドポイントに 固定された、一人のチームが所有する、誰も静かに削除できない単一のダッシュボードで 強制された、単一のp99の数字だった。この記事は他のものが生き残らなかったときに これが生き残った理由の話だ。
生き残らなかったもの
参加したすべてのチームには、どこかにレイテンシバジェットがあった。大抵、18ヶ月前、 三人前のオーナーの、Performance SLOs, v2というタイトルのデザインドキュメントに。 それは通常こんなものを持っていた：
- 40のエンドポイントのテーブル、それぞれにp50/p95/p99/p99.9の目標。
- サービスごとの「サービスレベルオブジェクティブ」行。
- 「プロダクトレベルの体験」メトリクスのロールアップ。
- 下部の「これらはターゲットであり、保証ではない」というメモ。
すべての行は合理的だった。個々の数字に誰も異論を唱えられなかった。それでも、 本番の実際の数字に対してクエリを実行するたびに、半数を静かに違反していた — アラートなし、フォローアップなし、会話なし。バジェットは装飾だった。
障害モードは数字が間違っていたことではない。障害モードは誰もそれらのどれかを 十分大声で所有しなかったことだ。誰の問題でもない数字は誰の問題でもない。
生き残ったもの
ある特定のプラットフォーム — マルチスクワッドチームと行ったイベント駆動モダナイゼーション の一つ — で、「適切なSLOドキュメント」を書こうとし続けた。スプリントを生き残ることは なかった。最終的に諦めて、小さすぎて機能しないように感じるものをやった。
一つのエンドポイントを選んだ。誰もが意見を持っていたもの — リアルタイムゲーム バックエンドのマッチ参加フロー。ホワイトボードに一つの数字を書いた：p99 < 250ms。 一人の人の名前をその隣に置いた。一つのダッシュボードURLを作成した。 チームのSlackチャンネルにダッシュボードURLをピン止めし、オンコール引き継ぎ テンプレートに追加した。
それがバジェット全体だった。一つの数字。一つのエンドポイント。一人のオーナー。 一つのダッシュボード。
三年間生き続けた。違反して、回復して、また違反して、また修正した。数字は動いた （最初は180msに下がり、それからコストに値する機能を追加したとき220msに戻った）。 しかし常にアジェンダにあった — 一つしかなく、誰をピングすべきかを全員が 知っていたから。
シンプルなバージョンが勝った理由
私が過小評価していた頻度の順に四つの理由：
1. 認知負荷。 四十の数字は機械にとっては思ったより少なく、人間が注意を持続 できるよりは多い。一つの数字は誰かのラップトップのステッカーにある。四十の数字は wikiのフォルダのドキュメントのテーブルにある。
2. オーナーシップの明確さ。 「プラットフォームチームがそれを所有する」は オーナーシップではない。コンプライアンス層を持つ傍観者効果だ。「Juliaがjoin-a-matchの p99を所有する」はJuliaがピングされることを意味する。Juliaは修正するか、 明示的に渡すかのどちらかだ。数字に顔がある。
3. アラーティングの適合。 一つの数字のための良いアラートを設定できる。四十の 相関した数字のための良いアラートは設定できない — 過剰に発火するか過小に発火するかで、 どちらかわからないのはポケベルがすでに民衆税になった後だ。（それがオンコールの ローテーションを殺す理由についての前回の記事を見よ。）
4. 違反時のソーシャルプルーフ。 数字が違反するとき、人々はその数字を認識する。 「join-a-matchのp99がたった今380にポップした」は人々がうなずく文だ。「プラットフォーム レイテンシSLOがgrafanaダッシュボードのquadrant 3でyellowになっている」は隠れる文だ。 隠れる文の周りで動員することはできない。
ミーティング衛生を修正した質問
ワンナンバーアプローチを採用した後、毎週のミーティングに一つの繰り返し質問を 保ち続けた：「数字はred、yellow、greenのどれか？」
- Green： スキップ。ステータスシアターはなし。
- Yellow： オーナーが自分がやっていることについて一文言う。
- Red： アジェンダを落として計画を立てる。
これで毎週「パフォーマンスステータスのアップデート」約30分が60秒のチェックインに 置き換わった。実際に悪いとき、四半期ではなく一週間以内に気づいた。
一つの数字ではないもの
- 全体像ではない。まだ気にする他の数十のメトリクスがある。それらはダッシュボード、 アラート、ポストモーテムに住む。一つの数字は背骨で、他はすべて筋肉だ。
- すべてのエンドポイントへの目標ではない。90%のエンドポイントはバジェットに値しない。 バジェットは維持が高くつく — プロダクトに実際に重要なものに与えて、それから エラーログに現れるまで残りを忘れろ。
- 静的ではない。上げたり下げたりする。どちらも構わない。動かないバジェットは 誰も見ていないバジェットだ。
始め方
今ちゃんとしたパフォーマンスSLOドキュメントを書くことを検討しているなら：やめろ。 代わりに、今夜、忘れる前に：
- プロダクトで最もユーザー可視の単一のエンドポイントを選べ。
- 過去30日のp99を引き出せ。
- 切り上げろ。それが開始番号だ。
- 一人の名前を隣に置け。多分君の名前だ。
- チームの最も使われているチャンネルにダッシュボードURLをピン止めしろ。
- 週次ミーティングに「数字は？」を追加しろ。
それが第一週だ。第二週、数字が間違っていることに気づくか、問題ないことに気づく。 どちらにしても、今それを所有している。ほとんどのSLOドキュメントが到達しないところまで 来ている。
自慢
静かな部分を言おう：このアプローチも私を非常に速く非常に良く見せた。「Moは私たちの p99を63%削減した」はマネージャーがパフォーマンスレビューで大声で言える見出しだ。 「MoはSLOドキュメントを維持した」はそうではない。定量化された数字を選んで、 定量化された改善を主張しろ。マネージャーはドキュメントを昇進させることはできない。