障害に備えて、誰かがいつでも呼び出しに応じられるようにする仕組みがオンコールです。
ところが体制を組む段になると、何人で回せば一人に負担が偏らないのかという問いに、手がかりは意外と少ないものです。
夜も週末も同じ人が呼ばれ続けるチームを見て、仕組みで防げないかと考えたことはありませんか？
Google の SRE 本は、人数の下限やシフトの長さといった数字でこの問いに答えています。
SRE の実務経験がない私は、SRE 本とワークブック、PagerDuty の公開ドキュメントを読み比べました。
オンコールは「量」と「質」の二つで測る
SRE 本の Being On-Call の章は、オンコールの負担を二つの軸で捉えています。
一つ目の量は勤務時間のうちオンコールに充てる割合で、全体の 25% までが上限です。
二つ目の質は、1 回のシフトで起きるインシデントの件数です。
1 件の対応にはポストモーテムまで含めて平均 6 時間かかるため、12 時間のシフトで最大 2 件という上限が導かれていました。
呼ばれる量まで設計の対象にするという発想が、この章の出発点です。
呼ばれてから動くまでの目安は、ユーザーに見えるサービスで 5 分、急ぎでないシステムで 30 分とされています。
99.99% なら四半期の停止枠は約 13 分しかなく、応答の速さは可用性の目標から逆算されます。
ナインを停止時間に直す見方は、可用性の記事と共通です。
ローテーションは二段構え・人数・シフトの長さで組む
当番表を組むときに決めるのは、段の数・人数・シフトの長さの三つです。
プライマリとセカンダリの二段構え
SRE 本によれば、多くのチームは一次対応のプライマリと二番手のセカンダリの二段で回しています。
PagerDuty の Being On-Call も必ずバックアップを置くよう勧め、5 分で応答がなければ次の段へ回す設定を推奨していました。
バックアップをプライマリの直後のシフトに置けば、厄介な件を次のシフトへ先送りすることも起きにくいとされています。
人数は「25%」から逆算する
SRE 本は、24 時間の当番に要る人数を 25% の上限から逆算しています。
1 週間交代で常に 2 人が入るなら、1 拠点のチームは最低 8 人です。
2 拠点に分けるなら、各拠点 6 人が目安です。
SRE ワークブックの On-Call の章は、長く抜ける人が出ても回るよう、1 拠点 9 人・複数拠点なら各 6 人を示していました。
人が多すぎても本番から遠ざかるため、各自が四半期に 1〜2 回は当番に入れる規模がよいとされています。
シフトは長くて 12 時間
1 日に 1 回以上呼ばれるなら、ワークブックは休みなしの 24 時間当番を避け、シフトを 12 時間までに区切るよう勧めています。
1 拠点でも、1 週間を昼と夜の 2 人で分ければ収まります。
時差のある拠点で日中だけを受け持つ「フォロー・ザ・サン」は夜勤を無くせる反面、連絡の手間が増えると SRE 本は注意していました。
引き継ぎとエスカレーションで一人に抱えさせない
当番が一人で抱え込みやすいのは、交代のときと、手に負えないときです。
ワークブックに載る Google の新設チームは、当番の心得を三つ決めていました。
- 始めに、前のシフトからの引き継ぎを読む
- まずユーザーへの影響を抑え、そのあとで根本まで片づける
- 終わりに、次の当番へ引き継ぎのメールを送る
引き継ぎの中身は、PagerDuty の Going On-Call ガイドが具体的です。
未解決の件に加えて、上流・下流を含む主要システムの最近のデプロイや、他チームの担当者の異動まで挙げています。
一方で、呼ばれた件はシフトの残りが 1 時間でも最後まで自分で持つのが PagerDuty の作法です。
手に負えないときの支えに、SRE 本は明確なエスカレーション経路・対応手順・非難しないポストモーテムの文化を挙げていました。
PagerDuty は「迷わずエスカレーションする」を合言葉に、すべてを一人で直すことは当番の責任に含まれないと明文化しています。
負荷を測って均し、明けたら回復させる
組んだ体制を放っておくと、負荷は少しずつ偏っていきます。
件数は「インシデント」で数える
ワークブックは、1 シフトで受けたインシデントの数をページャー負荷と呼び、同じ問題から何通鳴っても 1 件と数えます。
推移は直近 21 日の移動平均で追い、警告ラインを超えたらチケットで知らせるのが同書の勧めです。
120 時間かかる改修も、4 時間かかる呼び出しが 30 件減れば元が取れるという同書の計算は、改修の説得材料になります。
人ごとの偏りを見る
全体が上限内でも、特定の人に寄れば意味がありません。
PagerDuty のマネージャー向けガイドは、一人だけが当番を多く抱える状態や、祝日の当番が毎年同じ人になる状態を避けるよう求めています。
見る指標は、当番の時間・対応件数・睡眠時間帯に呼ばれた回数です。
明けたあとの回復まで決めておく
同じガイドは、夜中に対応した人の始業を遅らせてよいことや、きついシフトのあとはプライマリから外す仕組みを勧めています。
SRE 本によると、Google は時間外の対応に代休か手当で報い、その上限が当番の量の歯止めにもなっています。
当番中はプロジェクト作業を外し、バグ修正に充てる運用もワークブックにありました。
最後に
オンコールの体制は、気合ではなく数字と手順で組み立てられます。
- 量と質：オンコールは時間の 25% まで、12 時間のシフトで 2 件まで
- ローテーション：二段構え、1 拠点なら 8〜9 人、シフトは長くて 12 時間
- 引き継ぎ：始めに読み、終わりに書き、迷ったらエスカレーションする
- 負荷：件数で数え、人ごとの偏りを見て、明けたら休ませる
ワークブックも章の冒頭で、当番の健康と引き換えに信頼性を得ることは決してしないという目標を掲げています。
当番の負担を根から減らす話は、トイルの考え方につながります。
私はまず、25% と 12 時間という二つの物差しを覚えておこうと思います。
以上です。
コメントを残す