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

警報を1本足すのは、誰かの夜を使うこと

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

前回、適合率と再現率を両立させる代償は「管理の複雑さ」へ移ると見ました。今回はもう一つの移り先です。代償は、人の夜にも移ります。

まず結論

警報を1本足す操作は、設定の1行の変更ではありません。SRE Workbook 第8章は「新しい警報は新しいコードと同じく入念に審査されるべきだ」と書き、追加をチームの承認事項として扱います。

背景に「ページ予算(pager budget)」があります。1シフトに鳴ってよい本数に上限を置き、新しい警報はそれを消費するものとして事前に見積もる。本期2本目のエラーバジェットと同じ形の道具が、人の時間についても作られています。

? 読む前に予測

ある警報のしきい値を下げて鳴りやすくしたい。この変更は誰の承認を要する作業でしょうか。

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

抽象原理

しきい値の1行が、承認事項になる理由

前回、適合率と再現率を両立させても代償は消えず「管理の複雑さ」へ移ると見ました。移り先はそれだけではありません。警報は、鳴った先に必ず人がいます。SRE Workbook 第8章はこう書きます。

Receiving a page creates a negative psychological impact. To minimize that impact, only introduce new paging alerts when you really need them.

呼び出し自体が負の心理的影響を生むので、本当に必要なときだけ入れる。同章は手順も定めます。

Just like new code, new alerts should be thoroughly and thoughtfully reviewed.

Anyone on the team can write a new alert, but the whole team reviews proposed alert additions and can suggest alternatives.

誰でも書けるが、入れるかはチームが決める。 しきい値を 0.5 から 0.3 へ変えるのはテキスト上1文字の編集ですが、決定としては「当番の全員の夜を少しずつ使う」ことへの合意にあたります。

具体実物

ページ予算 — 本数に上限を置く

同章は本数を有限の資源として扱う語を使います。pager budget(ページ予算)。

SRE Workbook 第8章が記述する仮想の事例(数値は原典より)表
項目 値
定めたページ予算 1シフト 2 本
実際に受けていた本数 1シフト 5 本(過去1年間)
予算を超えたシフト 全体の 3 分の 1
起きたこと 一部の技術者がチームを離れた

原典は The (hypothetical) Connection SRE Team と仮想のチームとして描きます。メンバーは殺到する警報に英雄的に応じたが追いつけず、Some engineers left the team to join less operationally burdened teams. に至ります。

この予算が事後の集計ではない点に注目してください。

Finally, use the alert’s trigger rate during the testing period to predict the expected consumption of your pager budget as a result of the new alert. Explicitly approve or disallow the new alert as a team.

本期2本目のエラーバジェットと同じ形です。あちらは「あといくら失敗できるか」で変更の可否を決めました。こちらは「あと何本鳴らせるか」で警報の可否を決めます。

✓ ここまでの確認

「ページ予算(pager budget)」が、鳴った本数を後から数えるだけの指標ではないのはなぜですか。

抽象原理

決めた人と、払う人

警報を入れると決める人と、鳴ったときに起きる人は同じとは限りません。SRE Book 第11章の Operational Overload 節はこの分離を正面から書いています。

Sometimes the changes that cause operational overload are not under the control of the SRE teams. For example, the application developers might introduce changes that cause the system to be more noisy, less reliable, or both.

そして極端な場合の是正手段を挙げます。

In extreme cases, SRE teams may have the option to "give back the pager"—SRE can ask the developer team to be exclusively on-call for the system until it meets the standards of the SRE team in question.

ページを返す。 呼び出しの宛先を、負荷を生んだ側へ戻す手段です。是正が「負荷を減らす」ではなく「払う先を変える」形で書かれている点が、この回の芯です。

なお同章は夜勤を避ける体制に触れる際、理由を外部の研究に帰属させます。Night shifts have detrimental effects on people’s health [Dur05]。自説として断じていない点も、引用ごと写す価値があります。

警報を1本足したとき、代償がどこへ移るか
しきい値を下げるテキスト上は1文字の編集
鳴る本数が増える
検知は増える再現率の側は上がりうる
ページ予算を消費上限に近づく
受け取る側で起きること
警報疲れ重大な警報の扱いが軽くなる
夜勤の負荷原典は健康への影響を文献に帰属
  • 代償は消えず、決めた人ではない誰かに出ることがある
  • 是正手段の一つが「ページを返す」= 払う先を戻すこと
具体実物

対比 — 鳴り終わった後も鳴り続ける警報

同じ構造が別の表層で現れる例です。前回の4属性のうち未見の Reset time(復旧後も鳴り続ける時間)。SRE Workbook 第5章の説明はこうです。

How long alerts fire after an issue is resolved. Long reset times can lead to confusion or to issues being ignored.

挙がる害は混乱と問題が無視されるようになることの2つ。この「無視される」が前節の警報疲れと同じ場所に着地します。

Low-priority alerts that bother the on-call engineer every hour (or more frequently) disrupt productivity, and the fatigue such alerts induce can also cause serious alerts to be treated with less attention than necessary.

鳴り続ける警報の代償は、その警報自身ではなくまだ鳴っていない別の警報の価値として現れます。1本の良し悪しだけを見ていると、この費用は帳簿に載りません。

✓ ここまでの確認

負荷を生む側と払う側が別でありうる。この構造について、SRE Book 第11章が実際に書いているのはどこまでですか。

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

エラーバジェット(前回までに扱った量)

許容される失敗の量を先に置き、変更がどれだけ消費するかを見積もる。SRE Workbook の付録は、算定や具体的な行動で意見が割れた場合、判断のために CTO へエスカレーションすると明記している。

何が有限の量として置かれているか表
置かれる量 許容される失敗の量
消費するもの 変更・障害
見積もる時点 変更を入れる前
揉めたときの宛先 文書が明記している
具体例 B

ページ予算(この回の量)

1シフトに鳴ってよい本数を先に置き、新しい警報がどれだけ消費するかを試験期間中に見積もる。承認または却下はチームとして明示的に行う、と原典が手順を書いている。

何が有限の量として置かれているか表
置かれる量 鳴ってよい呼び出しの本数
消費するもの 新しい警報
見積もる時点 試験運用の期間中
承認する主体 チーム全体

エラーバジェットとページ予算。守る対象は片方が利用者、もう片方が自分たちですが、道具の形は同じです。共通する構造は何か。

どちらも「先に量を置く」ことで、何が起きなくなったかを考えてみてください。

この章のまとめ

  • 警報の追加は設定変更ではなく承認事項。 新しいコードと同じく審査を要し、チームとして明示的に承認または却下する。
  • ページ予算という語が原典にある。 本数に上限を置き、消費を事前に見積もる。本期2本目のエラーバジェットと同じ形。
  • 鳴りすぎる警報の代償は、別の警報に現れる。 Reset time の害も「問題が無視されるようになる」こと。
  • 負荷を生む側と払う側は別でありうる。 原典はこれを認め是正手段に「ページを返す」を挙げる。「だから代償は見えにくくなる」は本教材の整理。
  • 量に翻訳しても、上限を誰が決めたかが空欄なら決定の主体は移らない。

自分の現場で確かめる

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

理解度チェック

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

問題 1 / 4正解: 0

SRE Workbook 第8章が、新しい警報の追加を「新しいコード」になぞらえているのはどういう意味ですか。

用語集(5語)
ページ(page)/ 呼び出し
当番中の担当者を直ちに呼び出す通知。記録だけ残る通知と区別される。SRE Workbook 第8章は、これが負の心理的影響を生むとする。
ページ予算(pager budget)
1シフトに鳴ってよい呼び出しの本数の上限。SRE Workbook 第8章の仮想の事例では2本。新しい警報はこれを消費するものとして事前に見積もる。
オンコール(on-call)
決められた期間、系の呼び出しを受ける当番に入っていること。SRE Workbook 第8章は時間外作業を伴うため報酬の対象であるべきだとする。
警報疲れ(alert fatigue)
頻繁な警報によって、受け取る側の注意が減っていく状態。SRE Book 第11章は疲労が重大な警報を軽く扱わせることがあるとする。
ページを返す(give back the pager)
SRE Book 第11章が極端な場合に挙げる是正手段。系が基準を満たすまで開発チームに呼び出しを引き受けてもらうこと。