オンコール
Google SRE Book 第11章(オンコール)と第5章(トイルの撲滅)を取得して読み、 理解した内容を自分の言葉で書いたもの。本文の引用はしていない。
インシデント対応が「鳴った後どう動くか」なら、こちらは その体制を持続可能に保つ方法。
時間配分の上限
数字で線が引かれているのが要点。
エンジニアリングに 最低50%
オンコールに 最大25%
残り25% その他の運用作業
上限を決めておかないと、運用作業が際限なく膨らむ。 これは善意の問題ではなく構造の問題で、放っておけば必ずそうなる。
ローテーションの人数
24時間365日を、一次と二次の2系統で回すための最低人数。
| 体制 | 最低人数 |
|---|---|
| 単一拠点 | 8人。週交代で、月におよそ1週間の担当になる |
| 複数拠点 | 各拠点6人 |
複数拠点は夜勤をなくせるという健康面の利点がある(follow the sun)。 代わりに拠点間の調整コストがかかる。どちらを取るかはシステムの重要度と作業量で決める。
1シフトあたりのインシデント数
1件のインシデントに、根本原因分析・修正・フォローアップまで含めて平均6時間かかる。
そこから逆算して、12時間シフトあたり最大2件が上限になる。
これを恒常的に超えているなら、システム側に問題がある。 頑張りで埋める話ではなく、是正が必要というシグナル。
報酬
代休か金銭で補償する。ただし給与全体に対する一定の割合で上限を設ける。
上限があるのは、参加の動機づけと、燃え尽きの防止・エンジニアリング時間の確保を両立させるため。 青天井にすると、オンコールを引き受けすぎる方向に力が働く。
安全だと感じられること
ストレス下では、人は分析的思考ではなく直感的な判断に流れる。直感は速いが、しばしば間違う。
そうさせないために用意するもの。
明確なエスカレーション経路(開発チームへ上げられること)
プレイブックに文書化された手順
非難しないポストモーテム(個人ではなくシステムを見る)
3つ目が効くのは、「自分が責められる」という予期そのものがストレス源だから。 インシデント対応の blameless は、 事後の学習だけでなく対応中の判断の質にも効いている。
負荷が過大になったとき
ページが閾値を超えたら、順に手を打つ。
1. 四半期の測定可能な目標を置く(例: 1日あたりのチケット5件未満)
2. 監視を棚卸しする。設定ミスのアラート、行動につながらないアラートを消す
3. 重複したアラートを統合する。アラートとインシデントを 1対1 に近づける
4. 開発チームと組んで、システムの信頼性そのものを上げる
5. 最終手段として、ポケベルを開発チームへ返す
アーキテクチャが基準を満たすまで、運用を引き受けない
5番目が制度として存在していることが重要。 「引き受け続ける以外の選択肢がない」状態だと、1〜4の交渉力が生まれない。
3番目のアラートの棚卸しは、可観測性の 「アラートのルールを作る前に通す5つの問い」を、既存のアラートに遡って適用する作業。
負荷が過小になったとき
逆方向の問題もある。静かすぎると知識が失われる。
四半期に1〜2回はオンコールを経験する
不幸のルーレット(過去のインシデントの再演)
年次の災害復旧訓練
トイル
定義
本番サービスの運用に直接結びついた、手作業で、繰り返しで、自動化可能な仕事。
区別すべきものが2つある。
- オーバーヘッドではない。 会議や人事手続きのような管理業務はトイルではない
- 価値のある地道な作業でもない。 恒久的な改善を生む作業は、地味でもトイルではない
6つの特徴
これらを持つ仕事がトイル。
手作業 スクリプトを走らせるだけでも、人が手を動かすならそう
繰り返し 新しい問題を解いているのではなく、定期的に同じことをする
自動化可能 機械が同じようにできる
戦術的 割り込み駆動で受動的。戦略的でない
恒久的な価値がない やり終えてもサービスは変わっていない
O(n) で増える サービスの規模に比例して手間が増える
最後の O(n) が判定に一番効く。規模が倍になったら手間も倍になるかを問う。
どれくらいが許容範囲か
目標 各人の時間の 50%未満
実測 平均およそ 33%(ばらつきは 0%〜80%)
オンコール自体が下限を作る。 6人チームなら最低33%、8人チームなら25%が オンコールで埋まる計算になる。
なぜ減らすのか
個人と組織の両方に効く。
| 対象 | 起きること |
|---|---|
| 個人 | キャリアが停滞する(プロジェクト作業なしでは前進しない)。燃え尽きと不満が溜まる |
| 組織 | エンジニアリング組織としての自己認識が曖昧になる。機能開発の速度が落ちる。開発側からの作業の押し付けを誘発する。優秀な人から辞めていく。採用時の約束を破ることになる |
解は1つで、将来のトイルを減らすエンジニアリング作業を継続的に行うこと。 今のトイルを速くこなすことではない。