オンコールと運用の負担

オンコール（夜間・休日も含めて呼び出しに応じる当番）は、放っておくと一部の人に負担が集まり、燃え尽きや離職の原因になります。EM は負担を数字で測り、仕組みで減らします。

オンコールの指標

Google の SRE 本では、12時間のシフトで対応するインシデントは多くても2件程度を目安にしています。人数や交代のしかたは「ローテーションの組み方」で扱います。

アラートの質を上げる

ローテーションは、負担が偏らず、1人で抱えないように組みます。

Google の SRE 本では、主・副の2人体制・1週間交代なら、1拠点のチームで最低8人が必要としています（オンコールに使う時間を仕事の25%までに抑えるための数）。人数が足りないときは、当番の範囲を狭める・他チームと合同にする・夜間は重大なものだけにする、などを組み合わせます。

オンコールのつらさの多くは、鳴っても何もしなくてよいアラートから来ます。対応不要のアラートが多いと、慣れて無視するようになり、本当に大事なアラートを見落とします。

週1回のオンコール引き継ぎ会で、鳴ったアラートをすべて見直します。対応不要だったものは、消す・しきい値を変える・昼間に見るチケットにする、のどれかにします。「念のため」で残したアラートが増えていくのが一番の敵です。

SRE の「SREの実践」（アラート設計）

トイルとは、手作業で・くり返し発生し・自動化でき・やっても価値が残らない運用作業です（例：毎週手でディスクを掃除する、決まった問い合わせに手でデータを直す）。放っておくと、サービスの成長に合わせてトイルも増え、開発の時間がなくなります。

Google の SRE では、トイルを含む運用作業を仕事の50%以下に抑えることを目標にしています。EM は、トイルの時間をチームの数字として見えるようにし、自動化への投資を事業側に説明します。

夜中に呼ばれた人が、その場で調べ方から考える状態だと、復旧が遅れ、負担も大きくなります。引き継ぎ会と手順書（ランブック）で、知識を人から仕組みに移します。

週1回の引き継ぎ会（30分ほど）

• 先週鳴ったアラートと、対応の内容を一覧で見る。
• 対応不要だったアラートの扱いを決める。
• 手順書が足りなかった・古かったものを直すチケットを作る。
• 今週の予定（大きなリリース、キャンペーン）と注意点を共有する。

手順書に書くこと

手順書は、使った人がその場で直すのが一番よく育ちます。「古かったら直してよい」と明言しておきます。