Dev Study
← 運用の土台
レッスン 10 / 10·約 9 分·第15期 運用の土台

観測はできる。引き受けることはできない

リクエストがアプリケーションに届くまで
  1. ブラウザURL入力
  2. DNS名前→IP
  3. ルータ経路選択
  4. ロードバランサ振り分け
  5. Nginx受け口
  6. アプリ処理今ここ
  7. DB保存

運用の数字はすべて誰かが引いた線であることを見てきました。最終回は、その線の帰結を誰が負担するのかを見ます。

まず結論

この期で扱った代償は、何と何が引き換えかではなく「決めた結果を誰が負担するか」という主体の話です。誰が負担したかは、当番表と呼び出しの記録から後で観測できます。

観測できるのに人の側に残るのは、その負担を引き受ける行為のほうです。エージェントは当番表を読めますが、その表に載る主体にはなれません。

? 読む前に予測

「深夜2時に誰が呼び出されたか」は、記録から後で確かめられるでしょうか。

当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。

抽象原理

この期がずっと扱ってきた「代償」の意味

先に語を切ります。既存の教材やクイズにも代償という語は出てきますが、多くは「速さを取れば容量を使う」のような何と何が引き換えかの話です。本期が扱ったのは、引き換えを決めた結果を誰が負担するかでした。

9本を並べ直すと同じ形が出てきます。運用の数字は測って出てくるものと、誰かが選んだものが混ざっている。選ばれた側が運用の線です。線を引くと負担が発生し、消えずに誰かのところへ移ります。

9本が示した「線」と「移り先」表
本 引かれた線 負担の移り先
1 SLO の目標値 約束を外したときの結果
2 バジェットの手続き 揉めたときの上位者の判断
3 警報の閾値と手の本数 管理すべきパラメータの多さ
4 警報を1本足すか 当番に入っている人の夜
6 CVSS のどの群まで入れるか 入力しなかった既定値
8 何を書き残すか 後から集計する側

見るべきは右の列です。**どの行でも負担は消えていません。**別の場所へ移っているだけで、3本目の移り先は原典自身が挙げた管理すべきパラメータの多さ、4本目の移り先は原典が pager budget と呼ぶ人の夜でした。

具体実物

当番表は、読めば分かる

ではその「誰が」は、後から確かめられるでしょうか。**確かめられます。**当番表には氏名と時間帯が、呼び出しの記録には発火時刻と宛先が残ります。数えれば、誰が何回呼ばれたかは事実として出てきます。

架空の当番記録を集計した形(実在の値ではありません)表
担当 夜間の呼び出し回数 うち対応が30分超
A 11 4
B 9 3
C 2 0

この偏りも観測できます。AI に読ませて「Aに偏っています」と返させるところまでは、観測の内側の作業です。

では何が残るのか。「次の当番はCに回す」と決め、Cが起きる夜を自分たちのものとして引き受けることです。集計は観測ですが、引き受けは観測ではありません。

✓ ここまでの確認

本期でいう「代償」は、既存の教材に出てくる代償と何が違いますか。

抽象原理

観測できることと、引き受けられることは別の問い

序章『エージェントに任せられること — 観測できないものは検証できない』が置いた判定は「観測窓の内か外か」でした。第14期『ではどこに線を引くか — 引き返せる線と、引き返せない線』も、線の帰結は観測に現れないという形でこの判定を使っています。

**本期が足すのは別の問いです。**当番表は観測窓の内側にあります。それでも人の側に残る理由は、検証できないからではなく、引き受けるという行為が観測ではないからです。

2つの問いは別々に立つ
観測できるか序章の判定
窓の内なら検証できる
引き受けられるか本期の問い
窓の内外と独立
当番表を当てはめると
観測できる氏名と時刻が残る
集計も可能
引き受けられない表に載る主体になれない
ここが残る
  • ・「観測に現れないから人に残る」は第14期の理由づけ。本期の理由づけは別
  • ・観測できるものでも、負担する主体が要る限り人に残る
具体実物

署名の側から見ても同じ形になる

1本目で見たとおり、原典が作り手を名指ししているのは SLA だけで、作り手として business and legal teams を挙げ、技術者の役割は達成の見込みについての助言だとしていました。

1〜2本目で確認した、主体が書かれている箇所表
対象 原典が書いている主体 負う結果
SLA business and legal teams 契約上の結果
バジェットの争点 CTO(揉めた場合の決定者) どちらの案を採るか
SLO 決定主体の明示は弱い 未達の扱いは組織次第
SLI SREが定義を手伝う、まで 記述なし

なぜ SLA だけか。外した場合の結果が付いているのが SLA だからです。結果が付くとき、それを負う主体を書かずに済ませられません。**この表を埋めるのは AI にもできます。**原典のどこに主体が書かれているかを抜き出すのは観測の内側だからです。できないのは、空欄に自分の名前を入れることです。

✓ ここまでの確認

第14期『ではどこに線を引くか — 引き返せる線と、引き返せない線』の軸と、本期の軸の違いはどこですか。

⇄ 2つを見比べる
具体例 A

警報を1本足すとき(本期4本目)

追加は設定の1行ですが、発火すれば誰かの当番が動きます。原典は新しい警報を新しいコードと同じく審査すべきものとし、承認事項として扱います。

自動化できる範囲表
作業 観測の内か外か
閾値の妥当性を調べる 内(データから出る)
発火頻度を見積もる 内(過去の記録から)
誰が呼ばれるかを引く 内(当番表を読む)
その夜を使うと決める 外(記録ではない)
具体例 B

直す順番を決めるとき(本期6〜7本目)

スコアは外から来ます。仕様自身が、優先順位付けに関して有用性は使ったメトリクスに正比例すると書き、公開される多くが Base だけだと名指しします。

自動化できる範囲表
作業 観測の内か外か
スコアを集めて並べる 内(公開値を読む)
自分の環境の値を入れる 内(構成から出る)
影響する範囲を列挙 内(依存関係から)
この順で直すと決める 外(記録ではない)

警報の追加と、修正の順番決め。扱う対象は違いますが、自動化できる範囲の切れ目が同じ場所に来ています。何がこの切れ目を決めているでしょうか。

各表の最終行だけが「外」です。そこだけが他の行と違う点を探してください。

抽象原理

運用の側から序章へ戻る

序章『生成されたコードの読み方 — 「動く」と「正しい」の差』は、「動いた」をある1回の実行で観測された結果、「正しい」を実行しない場合も含めて成り立つ性質と定義しました。

運用の数字は、この定義でいうと前者の側にあります。**測れば出てきます。**しかし本期の9本が見たのは、その数字の隣に必ず「誰が選んだか」「誰が負担するか」の欄が付いていることでした。

だから最終回の結論は、観測の外に何があるかではありません。観測できるものについても、結果を引き受ける欄は残るということです。エージェントが速く正確になるほど上の行は自動で埋まり、空いたままなのは最終行になります。

この章のまとめ

  • 本期でいう代償は、何と何が引き換えかではなく決めた結果を誰が負担するかの話。
  • 負担は消えず移る。3本目では管理すべきパラメータの多さへ、4本目では人の夜へ。
  • 「誰の夜を使うか」は観測できる。当番表と記録に残り、集計も自動化できる。
  • 残るのは引き受ける行為。第14期の「取り消せるか」とは別の軸で、片方が他方を含まない。
  • 「引き受けるのは人」は一次ソースの無い規範の主張。原典に帰属させないこと。

自分の現場で確かめる

読んだだけでは身につきません。手元の環境で実際に見てみてください。

環境:

理解度チェック

読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。

問題 1 / 3正解: 0

本期1本目で見たとおり、原典が作り手を名指ししているのは3つの語のうちどれですか。

用語集(4語)
代償(本期の用法)
決めた結果として発生する負担のうち、誰が負担するかを問題にしたもの。速度と容量のような引き換えの用法とは区別。
運用の線
SLO の目標値・警報の閾値・直す順番のように、測定からは出てこないが運用のために引かれた値。
pager budget
1シフトに鳴ってよい呼び出しの本数に上限を置く考え方。SRE Workbook 第8章の語彙。
観測窓
序章の語。ツールが返す観測(終了コード・テスト出力・HTTPの応答)が届く範囲。外側には誤りの信号が生じない。