Chapter 11 - Being On-Call

勤め先でSRE本を輪読している時のメモ。

### オンコール対応
オンコール対応は、サービスの信用性と可用性を保つための重要な仕事

11.1 イントロダクション
・オンコールの対応は専門の運用チームにより実施されてきた
・googleではSREチームが実施している
　→ソフトエアエンジニアリングを適用したにと大使しきれない量のため
　→ここでも運用作業の時間が50%のキャップ、チームの力をスケールさせるのがSREの仕事

11.2オンコールエンジニアの日常生活
・オンコールエンジニアの業務
　障害対応、プロダクトの変更の実施や調査
　時間制約は5－30分(厳しいいいい)
・アラート配信システムは柔軟
　メール、SMS、自動コール、アプリなど←これはNRIもそう
・レスポンスタイムはサービス可用性に依拠する
　ユーザが直接利用するようなサービスは4ナインで、その場合許されるダウンタイムは13分/四半期
・コールのローテーション
　プライマリとセカンダリのコール
　この2人のエンジニアの使い方はチームによって異なる(取り逃しを拾ったり、小さいインシデントをひき受けたり)

11.3バランスの取れたオンコール
オンコールは質と量ではかられ、固有の制約を持つ。SREマネージャーは2つの軸を持続可能な状態に保つ責任を負う。

11.3.1量におけるバランス
・時間の配分
　50%はエンジニアリング　オンコールは25％以下　他の仕事をもう25％とする
・25％オンコールルール
　24/7かつ25％コールを保つには、週替わりで回すと8人のエンジニアが必要
　2サイトでやるなら6人
・マルチサイトがよい
　夜間シフトを避ける、プロダクションシステムとの接点を増やすため、エンジニア数を制限する
　上記の観点からマルチサイトを推奨。しかしコミュニケーションのオーバーヘッドがあるのも事実。
11.3.2質におけるバランス
・オンコールの質的負荷
　1つのインシデントのフォローには平均6時間必要(フォローアップの活動まで含めて)
　とすると1日に対応可能なインシデントは2件になる
11.3.3 保障
時間外の勤務への補償
・チームで異なるが代休または給与で調整

11.4安心感
人は障害対応のときに以下の対応をする
・直感かつ反射的
・理性的かつ、集中力を球持ち、慎重な認識を働かせる
ストレスホルモンが高い環境だと全社の選択を取り勝ち
→同じアラートが4回飛んできたとき、4回目が3回目と同じ対応が適切とは限らない

・理想は...
妥当な判断が下せるだけのデータをそろえ、用意した手順を実行する
並行してその推定を批判的に検証する

・オンコールに必要なリソース
　明確なエスカレーションぱす
　しかっり規定されたインシデント管理の手順
　非難を伴わないポストモーテム

・インシデント管理方法
googleではツールが導入されており、メールや状況更新に煩わされることはない
NRIでは..?

11.5不適切な運負荷の回避
11.5.1.運用の負荷
・運用の負荷を計測できるようにすべき
・優先度の低いアラートのハンドリング
→アラートとインシデントを１：１にできるのが理想
・場合によっては障害通知をアプリに返却する
→適切な頻度になるまで協業する
→SREとDevチームのバランスが保たれているからこれができる
11.5.2低すぎる運用負荷
・プロダクトのとの接点が減るため良くない
→四半期に1回or2回は本番システムにさわれるのが目安
・不運の輪という全社規模での災対訓練を年に1度実施している
cf.カオスエンジニアリング

11.6まとめ
・オンコールにもエンジニアリングの力(SRE)を導入して、コール対応をスケーリングさせよう