9.8 オンコールと運用準備

概要と動機

今この瞬間、あなたのシステムがポケベルを鳴らすかもしれないために、誰かが起きています。オンコールとは、どの時間でも、有資格の人が本番の問題に手の届く所にいるようにする人間の取り決めで、運用準備とは、その人に勝ち目があるように事前に行う仕事です。この章は、その準備と人間のシステムについてです。何年も続けられるローテーションをどう設計するか、誰かを起こす価値があるものをどう決めるか、サービスが本物のトラフィックを運ぶのを許す前に、運用する準備が本当にできていることをどう確かめるか。

これを二つの隣接する章と区別してください。9.3章は、インシデント管理、つまり何かが実際に壊れた後の対応のプロセスを扱います。指揮の役割、深刻度のレベル、調整、ポストモーテム。9.1章は、サイトリライアビリティエンジニアリング(SRE)、サービスレベル目標とエラーバジェットで信頼性をエンジニアリングする、より広い規律を扱います。この章は、インシデントの上流で、その規律の傍らに位置します。より狭く、より個人的な問いを立てます。サービスは運用する準備ができているか、そしてポケベルを持つ人は、苦しむのではなく成功できるよう整えられているか。組織は優れたインシデントのプロセスを持ちながら、エンジニアを燃え尽きさせることがありえます。オンコールの痛みは、アラートの質、ランブックの状態、スケジュールの人道性によって、あらゆるインシデントのずっと前に決まるからです。

大きなチームにとって、オンコールは、非公式な好意でなくなり、インフラストラクチャになります。数百のサービスと数十のチームのプラットフォームは、たまたますべてがどう動くかを知っている一人の人に頼れません。元の作者が去ったときにも持ちこたえる、ローテーション、エスカレーションの経路、準備の標準が必要です。企業と政府の設定では、賭け金はさらに上がります。規制対象のサービスは、可用性の約束と、それを運用する職員への注意義務を負います。市民向けの給付や医療のシステムは、それを理解していた唯一の人が休暇中だったために、一晩中暗くなることは許されません。運用準備は、ローンチのパーティが終わった後、組織が約束を守る方法であり、人道的なオンコールは、それらの約束を守る人々を引き留める方法です。

主要原則

緊急で、対処可能で、本物の問題にだけ人間を呼び出す。
常時利用可能な機械のためではなく、生活のある人のためにローテーションを設計する。
本番のトラフィックを運ぶ前に、サービスが運用する準備ができていることを証明する。
すべての内部の原因ではなく、ユーザーに見える症状とSLOでアラートする。
ランブックと準備のレビューを、保管されるのではなく使われる、生きた文書として扱う。
サービスを築いた人は、人道的でサポートされた限界の中で、その運用を助けるべきである。
オンコールの健全性を測定して苦役を削り、負荷が上向きではなく下向きの傾向になるようにする。

推奨事項

人道的で持続可能なローテーションを設計する

スケジュールの形から始めてください。それがどのツールよりも持続可能性を決めるからです。一般的なパターンは、最初にページングを受ける一次の対応者と、一次が確認しない、あるいは助けを必要とするときのバックアップとして働く二次の対応者を伴う、週ごとのローテーションです。どのエンジニアも4週に1回以下しかオンコールにならないよう、プールを十分大きく保ち、理想的には6週に1回かそれ以下にします。4人以下のローテーションは警告の印です。病気、休暇、離職が、それを同じ二人の疲れ果てた英雄に崩壊させます。

時間帯をまたいで運用する所では、異なるリージョンのチームがそれぞれ自分の日中をカバーし、誰も日常的に午前3時にページングされない、フォロー・ザ・サンのモデルを好みます。これは概日リズム、体の内部の睡眠と覚醒の周期を尊重するもので、その乱れは軽微な不便ではなく、直接の健康コストです。フォロー・ザ・サンが不可能なときは、痛みを圧縮します。より短い夜間シフトのブロック、悪い夜の後の保証された回復時間、夜通し頻繁にページングされたエンジニアは、翌朝丸一日の機能の仕事を負わない、という明示的なルール。

エスカレーションは、ローテーションの下の安全網です。一次が決まった窓の中でページングを確認しない場合に何が起こるかを、書面で定義します。二次に回り、次にチームリードあるいはマネージャー、次により広いグループへ。自動的でよく理解されたいエスカレーションの方針は、どのページングも静かに床に落ちず、疲れた一人の人が唯一の防衛線にならないことを意味します。

ページングの方針を、対処可能で緊急で本物の問題についてのものにする

オンコールのローテーションを破壊する最速の方法は、対処できない、あるいは対処する必要のないことで人をページングすることです。一つのルールを採用し、猛烈に守ってください。ページングとは、人間が今何かをしなければならないという主張です。アラートが三つのテストのすべてを満たさないなら、緊急で、対処可能で、本物のユーザーに見える問題を記述していないなら、ページングに値しません。代わりにチケット、ダッシュボード、日次のダイジェストに回します。

ここでの敵はアラーム疲れで、頻繁なアラームにさらされた人々が鈍感になり、重要なものを含めて無視し始める、よく記録された現象です。それは病院の患者安全の概念で、ソフトウェアにそのまま移ります。すべてのシフトが20のページングを運び、19が雑音なら、対応者は半分眠ったままそれらを払いのけることを学び、20番目の、本物だったものも、同じ反射的な却下を受けます。容認するうるさいアラートはすべて、他のすべてのアラートの信頼性への小さな税です。

アラートの質を、第一級のエンジニアリングの成果物として扱います。確認から行動への比率を追跡します。発火したページングのうち、人間が重要な何かをするに至ったのはいくつか。四半期に一度も行動を要さなかったアラートは、削除あるいは格下げの候補です。アラートを定期的な周期でレビューし、どのエンジニアにも、うるさいものに異議を唱える立場を与えます。目標は、ページングが十分まれで、依然として意味を持つローテーションです。

原因ではなく症状とSLOでアラートする

雑音を減らす最も効果的な方法は、何にアラートするかを変えることです。高いCPU、満杯のディスク、一つの再起動したプロセスのような原因へのアラートは、ユーザーに影響しないかもしれず、システムがしばしば自己修復する状態についてのページングの洪水を生みます。代わりに症状でアラートします。サービスはユーザーが必要とすることをしているか。ページングのアラートを、9.1章で定義された数値の信頼性の目標であるサービスレベル目標(SLO)に結びつけ、目標を外すほど速くエラーバジェットを燃やしているとき、あるいはレイテンシや成功率のようなユーザー向けの指標が、人々が実際に感じる線を越えたときにページングします。

この症状ベースでSLO駆動のアプローチは、9.2章のオブザーバビリティとテレメトリに依存します。バーンレートのアラートは、メトリクス、ログ、トレースが構造化されて信頼できる場合にだけ機能するからです。見返りは劇的です。少数の意味のある症状のアラートが数百の原因のアラートに取って代わり、ページングは再び、起こす価値のある問題と相関します。原因は依然として重要ですが、ページングの経路ではなく、症状のアラートが発火した後に対応者が参照する診断用のダッシュボードに属します。

ローンチの前に運用準備を要求する

サービスは、本番に入る権利を勝ち取るべきです。本物のトラフィックを運ぶ前に、本番稼働準備のレビューを通してください。理想的には築いたチームの外の誰かによる、サービスが実際に運用できることの構造化されたチェックです。レビューを、チーム間で共有される標準になるチェックリストとして体系化します。強い一覧は、監視とSLO、ページングの方針を満たすアラート、ダッシュボード、起こりうる失敗のためのランブック、定義された所有とオンコールのローテーション、容量と負荷の期待、依存関係と失敗様式の分析、バックアップと復旧、セキュリティとアクセス制御、ロールバックの計画をカバーします。

レビューは、ゲームにされるゲートではなく、会話です。その価値は、築いたチームが文脈を持っているうちに運用可能性に向き合わざるを得なくなり、6か月後の午前2時に、誰もランブックを書かずアラートを設定しなかったことを発見するのを防ぐことです。準備を9.6章のレジリエンステストに結びつけてください。ローンチ前に依存関係の障害を注入したことのないサービスは、自分がどう失敗するかについて、テストされていない約束をしています。高い賭け金の企業と政府のローンチでは、準備のレビューを必須で文書化されたステップにしてください。準備のできていない市民向けサービスが公に失敗するコストは、お金と同じくらい信頼で測られるからです。

実際に使われるランブックとプレイブックを書く

ランブックは、段階的な運用の文書です。このサービスをどう再起動するか、この資格情報をどうローテーションするか、このキューをどう空にするか、このアラートをどう解釈するか。プレイブックは、ある種類の状況へのより広い対応の手引きです。どちらも誰も読まなければ無価値で、ほとんどのランブックは、古い、曖昧、あるいは午前3時に見つけられないために読まれません。失敗の様式を直接直します。ランブックをアラート自体からリンクし、対応者がページングから1クリックでそこに着くようにします。2.7章のドキュメントの実践が勧めるように、ランブックをコードの隣のバージョン管理に保ち、他の成果物と同様にレビューされ更新されるようにします。ストレスを受け眠い見知らぬ人のために、作者の文脈を前提とする散文ではなく、具体的なコマンドと期待される出力を伴って書きます。

ランブックのテストは、作者以外の誰かが、圧力のもとで成功裏に従えるかです。オンボーディングとゲームデーの間にそれを検証し、インシデントがランブックの誤りを明らかにした瞬間に更新します。嘘をつくランブックは、ないよりも悪いです。疲れた対応者を自信たっぷりに間違った方向へ送るからです。

築いたものを、人道的な限界の中で所有する

DevOpsの運動は、「築いた者が動かす」を広めました。サービスを書いたチームが、そのポケベルも担う。その利点は本物で、守る価値があります。築く人が自分のページングを感じるとき、フィードバックのループが、根本原因を直せない別の運用チームに落ちるのではなく、彼ら自身に届くので、信頼性に投資し、うるさいアラートを直し、運用可能性のために設計します。

このモデルには、尊重すべき限界があります。1.10章のエンジニアリングの有効性と1.4章の働き方がどちらも求めるように、チームがサービスを動かすための装備を本当に与えられていることを要求します。ツール、プラットフォーム、訓練、運用をうまく行うための時間。ローテーションを配置するには小さすぎるチームに、あるいはオンコールを耐えられるものにするプラットフォームの支援なしに課される完全な所有は、残酷です。一部の組織はハイブリッドを運営します。中央のSREあるいはプラットフォームチームが、最も難しい層を共同所有する、あるいは高い信頼性の基準を満たすサービスに営業時間外のカバレッジを提供し、プロダクトチームを日常の夜間のページングから解放します。保つべき原則はフィードバックのループで、形は、チームの規模、成熟度、負荷の人道性に合わせて柔軟に変えられます。

オンコールのエンジニアを意図してオンボードし、ゲームデーを行う

誰も、一人で準備なしに初めてポケベルを持つべきではありません。オンボーディングの経路を築きます。1ローテーションの間、経験豊富な対応者のシャドーイング、新人がメンターに見守られて先導するリバースシャドーイング、ダッシュボードとランブックの案内、誰にエスカレーションするかの明確な地図。オンコールの準備ができたことを、想定ではなく明示的なマイルストーンにします。

ゲームデーは、オンコールを現実にするリハーサルです。ゲームデーでは、意図的に失敗を演習し、理想的には現実的な環境で、オンコールのエンジニアに、本物のインシデントで持つツールとランブックだけを使って対応させます。ここで、ランブックが古い、ダッシュボードにシグナルが欠けている、アラートが決して発火しない、といったことを発見します。ゲームデーは、最初の本物のページングを、パニックから手順に変える筋肉の記憶と自信を築き、9.6章のカオスエンジニアリングに自然につながります。

きれいな引き継ぎを行い、オンコールの健全性を測定する

シフト間の引き継ぎは、文脈が漏れる所です。短く構造化された引き継ぎを制度化します。現在何が縮退しているか、どのアラートが発火して抑制されたか、どの変更が進行中か、何を見るべきか。それを基本的なオンコールの衛生と組み合わせます。退出する対応者が次の人に散らかしを残さない、半端に修正されたものは書き留める、という方針を含めて。

何よりも、測定してください。見えない負荷は管理できません。シフトごとのページング、時間外(夕方、夜、週末)に着くページングの割合、確認までの時間、二次とエスカレーションの層が起動される頻度を追跡します。数字だけでなく傾向を見ます。時間外のページングが四半期ごとに増えるローテーションは、現在の絶対数にかかわらず、燃え尽きに向かっています。これらの指標を定期的な運用のレビューにフィードし、チームが、どの苦役を自動化して消すか、どのアラートを殺すか、準備がどこで不足したかを決めます。苦役、つまりトラフィックとともに増え、一度で固定されるのではない反復的な手作業の運用の仕事を減らすことが、システムが育つ間オンコールの負荷を平坦に保つ方法です。

トレードオフ: 長所と短所

選択	長所	短所
築いた者が動かす	緊密な信頼性のフィードバックのループ。所有者が根本原因を直す	資源の足りない、あるいは小さなチームには残酷。夜間の負荷が不均等
中央のSREあるいはプラットフォームのオンコール	プロダクトチームを日常の夜間のページングから守る。深い運用技能	築く者のフィードバックのループを弱める。捨て場になりうる
フォロー・ザ・サンのローテーション	夜間にページングされない。人道的で健全	複数のリージョンの職員が必要。引き継ぎのオーバーヘッドが重い
小さなローカルのローテーション	単純。全員がシステムを知っている	病気や離職で崩壊。速い燃え尽き
症状とSLOのアラート	少なく意味のあるページング。低い疲労	成熟したテレメトリが必要。ゆっくり育つ原因を見逃しうる
原因ベースのアラート	問題を早期に具体的に捉える	対応者を溢れさせる。アラーム疲れを駆動する
厳格な準備のレビュー	本番での厄介な驚きが少ない	ローンチを遅くする。ゲームにされると官僚的に感じられる

中心的な緊張は、カバレッジと人間性の間にあります。最大のカバレッジを押せば、大きなローテーション、積極的なアラート、どこでも完全な所有が得られ、システムは守られますが、人々をすり減らします。純粋に対応者の快適さのために最適化すれば、本物の問題が放置されて待つ隙間のリスクがあります。それを妥協で解決するのではなく、質を引き上げることで解決します。優れたアラート、動くランブック、準備のできたサービスが、より小さく落ち着いたローテーションに、より多くを安全にカバーさせます。最もよく運用する組織は、通常、対応者が最もページングされない組織です。耐久力ではなく準備に投資したからです。うるさいアラートを取り除く、あるいはランブックを直すのに費やすすべての時間は、人間の注意の複数の時間を買い戻し、システム全体の信頼性を守ります。

チームで議論すべき問い

あなた自身がこのローテーションを1年担う意思がありますか。そうでないなら、何を変えますか。 この問いは、負荷を個人的なものにすることで抽象を切り崩します。本物の数字を会話に持ち込んでください。先月何件のページングが発火し、いくつが真夜中過ぎあるいは週末に着き、平均の確認にどれだけかかったか。ローテーションの各人に、現在の形が、オンコールの週を恐れずに持続できるものかを尋ね、大きな声と同じくらい静かな答えに耳を傾けてください。誠実な答えが、ローテーションが、数人の英雄が最悪を吸収するからこそ生き延びられる、というものなら、そのうちの一人が去った最初の瞬間に壊れる脆さを見つけたのです。欲しい成果は、変更の具体的な一覧です。より大きなプール、フォロー・ザ・サンの分割、夜間のページングの削減、アラートの整理のいずれであれ、それぞれに所有者と日付を付けて。
人間をページングしうるすべてのアラートについて、対応者が取ることが期待される行動を名指しできますか。 ほとんどのローテーションはこれを監査したことがなく、その演習は啓発的です。ページングのアラートの全一覧を取り出し、それぞれについて、発火したとき対応者が何をすべきか、先四半期に実際の行動に至らずに何度発火したかを尋ねてください。テストに失敗するアラート、誰も行動を結びつけられない、あるいは誰かが触れる前に一貫して自己解決するものは、他のすべてのアラートへの信頼を侵食する雑音です。確認から行動のデータがあれば持ち込み、積極的に削除あるいは格下げする用意をしてください。目標は、すべてのアラートが人間の助けへの本物の要請であるページングの経路で、会議は、始まったときより短く鋭いアラートの一覧で終わるべきです。
新しいエンジニアがこのローテーションに加わるとき、何が正確に彼らを準備させ、それが機能すると試しましたか。 オンコールへのオンボーディングは、設計されるのではなく想定されることが多く、その隙間は、新人が一人で、見たことのない失敗にページングされる最初の時に現れます。新しい対応者が取る実際の経路を歩いてください。何をシャドーイングし、どのランブックを読み、それらのランブックにまだ機能することを確認するために最近誰かが従ったか、行き詰まったとき誰にエスカレーションするか。最近の本物のインシデントを選び、現在のランブックとダッシュボードだけを持つ新人が、それを解決できたかを尋ねてみてください。誠実な答えは通常、古い文書と欠けたシグナルを露呈し、それはまさに、本物のインシデントがそうする前に、ゲームデーが表面化させるものです。オンコールの定義された準備のマイルストーンと、それを誠実に保つゲームデーの予定を持って帰ってください。
時間外のページングは実際にどこに着き、人々の睡眠を守るために人員やカバレッジを変える意思がありますか。 夜間と週末のページングは、生の件数が隠す健康コストを負うので、平均では耐えられそうに見えるローテーションも、たまたま午前3時の失敗を引き当てる数人を静かに壊しえます。時間と曜日ごとのページングの内訳を、サービス別と対応者別に分けて持ち込み、平均ではなく集中を探してください。相反する考慮は本物です。フォロー・ザ・サンのカバレッジは複数のリージョンの職員を必要とし、引き継ぎのオーバーヘッドを加えますが、小さなローカルのローテーションはより単純ですが、誰かに夜を所有させます。修正が、二つ目のリージョンのローテーションか、時間外の層を引き取る中央のプラットフォームチームか、保証された回復時間を伴うより短い夜間のブロックか、夜間の雑音を源で取り除くアラートの整理かを、意図して決めてください。企業と政府の運用者にとって、オンコールの職員への注意義務を、ウェルビーイングのスローガンではなく、所有者と報告される指標を持つ正式な義務として扱ってください。規制当局や労働者評議会がいずれ、それを示すよう求めるかもしれないからです。
私たちの本番稼働準備のレビューは、サービスがどう失敗するかについての本物の会話ですか。それとも、ゲートを通すためにゲームにされたチェックリストですか。準備のレビューは、出荷されるものを変える場合にだけ元を取り、失敗の様式は、誰も信じていないプロセスを満たすためにローンチの前の午後に埋められる書式です。最近の完了したレビューをいくつか持ち込み、それぞれが実際に何を捉えたかを尋ねてください。欠けたランブック、テストされていないロールバック、決して発火しなかったアラート、あるいは何もなし。緊張は、ローンチの速度と運用の厳密さの間にあり、官僚主義に感じられるレビューはゲームにされ、本物の失敗の様式を表面化させるレビューは、誰かの夜を救う最初の時まで憤られます。誰がレビューを運営するか、築いたチームの外の誰かか、そしてどんな証拠、たとえば注入された依存関係の障害や、見知らぬ人が従ったランブックが、合格に数えられるかを決めてください。企業と政府のローンチでは、完了したレビューを監査の成果物として保ち、9.6章のレジリエンステストに結びつけてください。準備のできていない市民向けサービスが公に失敗することは、どのロールバックも回復できない信頼を失わせるからです。
「築いた者が動かす」は、どこで私たちに本当に役立ち、サービスを動かす資源を与えていないチームに、どこで静かに残酷ですか。 完全な所有は、築く人がうるさいアラートを直して運用可能性のために設計するフィードバックのループを作りますが、人道的なローテーションを配置するには小さすぎるチームに課されると、説明責任を装った、緩やかな燃え尽きのエンジンになります。どのチームがどのポケベルを所有するかの地図、決して難しいページングを取らない人々を除いたとき、各ローテーションが実際にどれだけ大きいか、各チームが運用をうまく行うために持つプラットフォーム、ツール、訓練を持ち込んでください。相反する引力は、普遍的な所有というきれいな原則と、一部の層は、最も難しい信頼性の仕事を共同所有する、あるいは営業時間外のカバレッジを提供する中央のSREまたはプラットフォームチームを必要とするという、散らかった現実の間にあります。欲しい成果は、各サービスを、完全所有、共同所有、中央カバーのいずれかに誠実に分類したもので、持続できないものを動かすよう求めているチームには、資源の隙間を名指しします。大きなあるいは公的な組織では、人道的な所有が前提とするプラットフォームの支援と人員の調達と採用のリードタイムを加えてください。関連する窓で配置できないチームは、失敗に向けて整えているチームだからです。

セクター別の視点

スタートアップ。 少数のエンジニアでは、全員がオンコールで、英雄のローテーションが隠れる余地はありません。最も速く元を取る二つの変更に乏しい時間を使ってください。原因ベースのアラートを削除し、核となる流れを追う二つほどのSLOでだけページングし、残る各アラートから1ページのランブックをリンクする。手の込んだツールとフォロー・ザ・サンは飛ばしてください。共有のスプレッドシート、一次から二次への自動エスカレーション、悪い夜が翌朝の休みを買うという厳格なルールは、どんなプラットフォームの購入よりも遠くまで連れて行ってくれます。

小規模事業者。 おそらく専任のSREはおらず、夜間のローテーションを配置できないので、築くものより買うものに頼ってください。深いインフラストラクチャのページングをプロバイダーが担うマネージドなサービスとホスティングを好み、自前のエスカレーションを作るのではなく、ホスト型のページングツールを使います。準備を、短いチェックリストと、顧客が気づくことに結びついた少数の意味のあるアラートとして枠づけ、朝のチケットで足りるときに、一部のサービスは単に夜間に人間をページングすべきでないと、正直になってください。

大企業。 問題は、多くのチームにわたる一貫性です。共有の本番稼働準備のレビュー、共通のページングの方針、バージョン管理のランブックのリポジトリにより、チーム間を移るエンジニアが、すぐにオンコールのシステムを理解できます。オンコールの健全性を、レビューを引き起こす時間外のページングの閾値を持つ、統治された指標にし、エスカレーションと引き継ぎを標準化して、どのページングも静かに落ちないようにし、中央のプラットフォームチームに最も難しい層を共同所有させます。ローテーションのポートフォリオを、サービスのポートフォリオを管理するように管理し、苦役、ページングの負荷、燃え尽きのリスクのデータを、定期的な運用のレビューに供給します。

政府。 調達規則、透明性、注意義務がこの取り決めを形づくります。オンコールの職員の健康を正式で監査可能な要件として扱い、夜間の人員配置が限られる所では、公務員が日常的に午前3時にページングされないよう、フォロー・ザ・サンの運用パートナーと契約します。完了した各準備のレビューを監査の成果物として保持し、5年後にそれを運用する人々は作者ではないので、システムを築かなかった対応者が実行できるようにランブックを書き、市民が本番でそれに出会う前に、ゲームデーで季節的なピークをリハーサルします。

事例

スタートアップ。 12人のスタートアップは、最初の有料プロダクトをローンチし、6人のエンジニア全員を、一次と二次を伴う週ごとのローテーションに置きます。最初の月、ポケベルは毎晩、ほとんどが自己解決するCPUとディスクのアラートで鳴り、二人のエンジニアが静かに転職活動を始めます。チームは止まって作り直します。原因ベースのアラートをすべて削除し、チェックアウトと検索の二つのSLOを定義し、エラーバジェットのバーンだけでページングします。ページングは週におよそ40件から3件に下がります。すべての新しいサービスが通らなければならない1ページの準備のチェックリストを加え、各ランブックをそのアラートから直接リンクします。オンコールは、人が去る理由から、仕事の管理可能な一部になり、それを高価なツールではなく、スプレッドシートと規律でやり遂げました。

大企業。 世界的な決済企業は、「築いた者が動かす」のモデルで数百のサービスを動かし、ページングシステム、準備のレビューのプロセス、バージョン管理の共有ランブックのリポジトリを提供する中央のプラットフォームチームに支えられています。すべてのサービスは、ローンチ前に、SLO、アラート、ランブック、容量、ロールバックをカバーする文書化された本番稼働準備のレビューを通ります。オンコールの健全性は追跡される指標です。時間外のページングが閾値を超えるチームは自動的なレビューを引き起こし、プラットフォームチームは、負荷が下がるまで信頼性の仕事の共同所有を申し出ます。ゲームデーは、現実的な障害注入に対して四半期ごとに行われます。標準が一様でツールが共有されているので、エンジニアはチーム間を移ってもすぐにオンコールのシステムを理解でき、リーダーシップはチームごとに、人間の負荷が持続可能かを見られます。

政府。 国の税務当局は、厳しい季節的ピークと、市民に利用可能であり続ける法的な義務を持つ申告システムを運営します。職員が一つの時間帯に集中し、夜間の人員配置が限られるので、機関は運用パートナーとのフォロー・ザ・サンの取り決めを契約し、公務員が真夜中に日常的にページングされないようにし、オンコールの職員の健康と注意義務を正式な要件として扱います。システムのあらゆる変更は、デプロイの前に運用準備のレビューを通り、チェックリストは監査のために保持されます。ランブックは、システムを築かなかった対応者が実行できるように書かれます。5年後にそれを運用する人々は、それを書いた人々ではないからです。申告の季節の間、機関はピーク負荷のシナリオに対するゲームデーを行うので、対応者は本物の急増に出会う前に、リハーサルでそれに出会います。

ビジネスケース: 動機、ROI、TCO

運用準備と人道的なオンコールの見返りは、二つの帳簿に現れます。システムの信頼性と、チームの定着です。信頼性の側では、準備のレビューを通り、症状ベースのアラートを持つサービスは、ランブックが存在し、アラートが意味を持ち、対応者がリハーサルされているので、失敗が少なく、回復が速くなります。ページングが、文脈を探して混乱する人ではなく、リンクされたランブックを持つ準備のできた人に届くとき、平均確認時間と平均復旧時間の両方が下がります。人間の側では、オンコールはエンジニアの離職の主な原因で、上級エンジニアの置き換えは、ローテーションを直すのにかかったはずの投資の何倍ものコストがかかります。世界保健機関が職業上の現象として認める、慢性的な職場の疲弊の状態である職業上の燃え尽きが高くつくのは、まさにそれが、システムを理解する最も経験豊富な人々を連れ去り、追い出すからです。

採用のコストは、ほとんどが一度きりで控えめです。準備のチェックリストを書き、アラートを原因から症状に移し、ランブックをバージョン管理に置き、オンコールの健全性の指標を設定します。繰り返されるコストは、アラートをレビューし、ゲームデーを行い、人道的なスケジュールを守る規律です。怠慢のコストは静かに複合します。うるさいアラートは疲労を育み、疲労は本物のインシデントの見落としと離職を育み、すべての離職は運用の知識を持ち去り、残る人々の負荷を上げます。リーダーシップに論拠を示すには、オンコールの健全性を、彼らがすでに見ている指標に結びつけてください。インシデントの頻度と期間、確認までの時間、計画外の離職、時間外のページングの傾向。システムが育つ間に時間外のページングが減るローテーションは、信頼性への投資が機能しており、エンジニアが来年もそこにいることの直接の証拠です。

アンチパターンと落とし穴

英雄のローテーション: 二、三人が静かにすべての難しいページングを吸収するので、スケジュールは紙の上では問題なく見え、そのうちの一人が去った瞬間に崩壊すること。
原因でのページング: ユーザーに見える症状ではなくCPU、メモリ、ディスクでアラートし、人間を必要としなかったページングで対応者を溢れさせること。
容認されるアラーム疲労: 削除が危険に感じられるために、うるさいと知られているアラートが何か月もページングの経路に残り、対応者がすべてを無視するようになること。
ランブックの腐敗: ローンチ時に一度書かれ、更新されず、疲れた対応者が午前3時に従うと自信たっぷりに間違っている文書。
支援のない所有: ローテーションを配置するには小さすぎる、あるいは人道的に動かすプラットフォームとツールを欠くチームに、「築いた者が動かす」を課すこと。
準備の劇場: サービスがどう失敗するかに本当に向き合うためではなく、ゲートを通すために埋められるレビューのチェックリスト。
ローンチして放置: ローテーションもアラートもランブックもなしにサービスを出荷し、最初の停止の間に隙間を発見すること。
測定されない負荷: シフトごとのページングや時間外のページングのデータがないため、人々が辞めるまで燃え尽きが見えないこと。
最初のページングにリハーサルなし: シャドーイングもゲームデーもなしに新しいエンジニアをオンコールに置き、彼らが固まって驚いてみせること。

成熟度モデル

レベル1: 開始: オンコールは非公式で反応的です。何かが壊れると少数の人が電話され、アラートは原因で発火してほとんどが雑音で、ランブックは欠けているか古く、サービスは準備のチェックなしにローンチし、誰かが燃え尽きるか辞めるまで、誰も人間の負荷を測定しません。
レベル2: 発展: 基本的な実践が現れますが、チームごとに異なります。一部のローテーションは定義された一次、二次、エスカレーションを持ち、一部のアラートは調整されて一部のランブックは書かれ、準備のチェックリストは存在するが一貫せずに適用されます。ページングは、気にかけるチームでは数えられているかもしれず、夜間のページングは一般的で、オンコールへのオンボーディングは設計されたものではなく即興です。
レベル3: 標準化: 準備のレビューは、ローンチ前の文書化されたステップで、チーム間で徹底されます。ページングは共通の方針に従う症状とSLOに基づき、ランブックはバージョン管理に住んでアラートからリンクされ、オンボーディングにはシャドーイングとゲームデーが含まれ、引き継ぎは構造化された形式に従い、エスカレーションはチーム間を移るエンジニアがすぐにシステムを認識できるほど一様です。
レベル4: 管理: オンコールが、ベースラインに対して測定され制御されます。シフトごとのページング、時間外の割合、確認までの時間、エスカレーションの頻度、確認から行動の比率がチームごとに追跡されて目標と比較されるので、燃え尽きに向かって流れるローテーションは、人々が辞めた後ではなく前に見えます。閾値はレビューを引き起こし、アラートの質は、どのページングが本物の行動に至ったかの証拠で監査され、人員配置と所有の決定は、逸話ではなくデータに駆動されます。
レベル5: オーケストレーション: オンコールの健全性は、継続的に改善され、組織全体に統合された成果です。システムが育つにつれてページングと時間外の傾向は下がり、苦役は体系的に自動化されて消え、フォロー・ザ・サンあるいは同等のものが睡眠を守り、ゲームデーと障害注入は日常で、組織は、すべてのシフトから学ぶにつれて所有、カバレッジ、準備の標準を適応させ、リスクの状況が移るにつれてチームとリージョンにわたって負荷を再均衡させます。

議論のためのアイデア

本物の行動に至ったページングと、自己解決したページングの現在の比率は何で、それを測定するには何が必要ですか。
最も知識のある対応者が明日去ったら、どのサービスが運用するのに安全でなくなり、なぜですか。
「築いた者が動かす」は、どこでうまく機能し、資源の足りないチームにとって、どこで静かに残酷ですか。
新しいエンジニアが現実的な条件でランブックの一つに従うのを最後に見たのはいつで、何が壊れましたか。
時間外のページングは過去4四半期で上向きですか下向きですか。そして誰かがその数字を所有していますか。
厳格に徹底していたら、最近の悪いローンチを防いだはずの準備のレビューの項目はどれですか。

要点

オンコールの準備は、停止の間の英雄的行為ではなく、アラート、ランブック、ローテーションの質によって、あらゆるインシデントの前に決まります。
緊急で、対処可能で、ユーザーに見える問題にだけ人間をページングします。症状とSLOでアラートし、それ以外はチケットとダッシュボードに回します。
生活のある人のためにローテーションを設計します。十分に大きなプール、可能ならフォロー・ザ・サン、自動エスカレーション、守られる回復時間。
本番稼働準備のレビューでローンチ前にサービスの準備を証明し、ランブックをバージョン管理に保ってアラートからリンクし、ゲームデーでリハーサルします。
オンコールの健全性、特に時間外のページングと確認までの時間を測定し、人々にもっと耐えるよう頼むのではなく、苦役と雑音を削ることで負荷を下げます。

参考文献とさらなる読み物

Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering: How Google Runs Production Systems
Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, and Stephen Thorne (eds.), The Site Reliability Workbook: Practical Ways to Implement SRE
Rob Ewaschuk, “My Philosophy on Alerting,” in Site Reliability Engineering appendix
John Allspaw and Jesse Robbins (eds.), Web Operations: Keeping the Data on Time
Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps
Gene Kim, Jez Humble, Patrick Debois, and John Willis, The DevOps Handbook
Michael T. Nygard, Release It! Design and Deploy Production-Ready Software
World Health Organisation, ICD-11, entry on burn-out as an occupational phenomenon