オンコールエンジニアの62％が12ヶ月以内にバーンアウトする（PagerDuty 2026）。 これは人間の問題ではない。エンジニアリング設計の問題だ。 バーンアウトしたローテーションに共通する3つの根本原因： 1. 原因ではなく症状に基づくアラート CPUの急上昇、キューの厚さ、リクエストレート——これらはすべてインシデントではない。すべてが深夜3時に人を起こす。 2. 古くなったランブック アラートが発生。ランブックには名前が変更されたサービスへのリンクが記載されている。エンジニアはアドレナリンと不眠の状態でシステムを逆エンジニアリングする。 3. 不対称な負荷に対する対称的なシフト 週末はスーパーボウル。平日はスプリント。同じローテーションが両方を同じように扱う。 最高のチームが実装する4つの改善策： 1. エラー予算 予期しないオンコール作業を週の25％までに制限する。それを超えれば、機能開発は停止する。Google SREがマニュアルを策定した。 2. SLOにリンクされたアラート ユーザーが観測可能なSLO違反と関連しないものは、ノイズである。オンコール時間の23％が誤検知である（Blameless 2026）。 3. ランブックか削除か 本番環境のすべてのアラートには、最新のランブックが添付されているか、またはアラートは削除される。アラートの半分は消えるだろう。それが目的だ。 4. 負荷に応じたローテーション ピーク時間帯には、より多くのカバレッジまたは短いシフトが必要だ。ワンサイズフィットオールは、ピークを引いた人を罰する。 あなたがエンジニアリングをリードしているなら、オンコール設計はあなたの仕事だ。HRでも、あなたのEMでもない。あなた自身だ。 今週：ダッシュボードを開き、アラートの数を数え、どれだけがプラットフォームで処理されるべきだったかを問う。 #EngineeringLeadership #OnCall #SRE