# SRE Book - Chapter 11: Being On-Call ## 要約 本章は Google SRE におけるオンコール業務の設計原則と運用指針を体系的に論じる。オンコールエンジニアは本番システムの「守護者」として障害対応と変更管理を担うが、その負荷は量(オンコール時間比率)と質(インシデント頻度)の両面で均衡を保つ必要がある。Google ではエンジニアリング業務に最低50%の時間を確保し、オンコールを最大25%に制限する方針を採用している。心理的安全性の観点では、ストレスが熟慮的思考を阻害するため、明確なエスカレーションパス・インシデント管理手順・非難なきポストモーテム文化が不可欠である。運用過負荷時にはページャー返却という手段があり、逆に運用過少負荷時には Wheel of Misfortune 演習や DiRT による習熟維持が求められる。 ## 主要概念 - **オンコールの量的均衡**: SRE の時間配分を厳格に管理し、エンジニアリング50%以上・オンコール最大25%・その他運用最大25%とする。この制約がチームの最小人数(単一拠点で8名、複数拠点で各6名)を決定する。 - **オンコールの質的均衡**: 12時間シフトあたりのインシデント上限を2件とし、1件あたり根本原因分析・修復・ポストモーテム執筆を含め平均6時間を見込む。ページングイベントの分布は極めて平坦であるべきで、中央値は日次0件が望ましい。 - **フォロー・ザ・サン**: 複数拠点チームによる昼間のみのオンコールローテーション。夜間シフトの健康被害を排除し、ローテーション規模の縮小による本番習熟低下も防ぐ。 - **心理的安全性と認知モード**: ストレスホルモン(コルチゾール、副腎皮質刺激ホルモン放出ホルモン)は熟慮的認知を阻害し、直感的だが根拠に乏しい判断を助長する。確証バイアスなどのヒューリスティック濫用を防ぐには、意図的にペースを落とした対応が有効である。 - **ページャー返却**: 運用負荷が持続的に過大な場合、SRE チームは開発チームにオンコール責任を返却できる。SRE と開発の間の健全な緊張関係を体現する仕組みである。 - **運用過少負荷の危険**: 静穏すぎるシステムのオンコールは過信と知識不足を招く。Wheel of Misfortune 演習や年次の DiRT(災害復旧訓練)で本番対応力を維持する。 ## 実践的指針 - ユーザー向けサービスでは5分以内、低緊急度システムでは30分以内の応答時間を設定し、SLO と整合させる。 - プライマリとセカンダリのオンコールローテーションを設け、責務を分離する。セカンダリはページのフォールバックまたは非緊急運用に充てる。 - ページングアラートは SLO を脅かす症状にのみ紐づけ、すべてアクション可能(actionable)とする。アラートとインシデントの比率を1:1に近づける。 - インシデント対応後には非難なきポストモーテムを実施し、個人ではなくイベントに焦点を当てて自動化の機会を抽出する。 - 運用過負荷の兆候は定量的に計測する(「日次チケット5件未満」「シフトあたりページ2件未満」など)。 - オンコール報酬(代休または現金)を適切に設計し、参加を奨励しつつ偏りを防止する。 - 四半期に最低1回は全エンジニアがオンコールに入る規模にチームを設計し、本番との接点を確保する。 ## 関連 - [[@2016__OReilly__SRE Book - Chapter 1 Introduction]] - [[SRE Book]] - [[SRE]] ## 出典 Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (Eds.). *Site Reliability Engineering: How Google Runs Production Systems*. O'Reilly Media, 2016. Chapter 11: Being On-Call (Written by Andrea Spadaccini, Edited by Kavita Guliani).