オンコール対応の3回目です。
オンコール対応の最後の回になります。最後は、オンコール対応の負荷が増え過ぎた場合についてを見ていきます。
不適切な運用負荷の回避
SREは作業の50%をエンジニアリングに当て、残りの50%で運用を行います。
運用作業の過負荷を避ける目標を数値化するために、過負荷の兆候を計測できる形にしておくことが重要です。（日々のチケット数を5以下に抑えるやシフトごとのページ発生イベントを2以下にするなど）
システムのアラートは、SLOを脅かす症状に対して、行うべきです。
細かいアラートは、それを対応するエンジニアの生産性を下げたり、より重要なアラートへの注意を散漫にします。
また、一つのインシデントに対して、複数のアラートが発行されることがありますが、これはできるだけインシデントとアラートの関係が1対1になるように調整すべきです。
この理由は、関連のあるアラートが複数発行されると、そのアラートの切り分けに時間が費やされたりしてしまい、インシデントへ集中しづらくなるからです。
アラートを関連性によって、まとめて、必要のないアラートは発行されないようにすべきです。
運用の過負荷は、モニタリングの設定によるものだけではなく、開発チームにより、信頼性の低下をもたらすような修正がなされたときにもおきます。
運用の負荷がかかり過ぎている場合、極端なケースでは、SREチームにおいて、運用が行えるレベルになるまで、開発チームへオンコールの対応を行ってもらえるように交渉することもできます。
油断ならない敵：低すぎる運用負荷
運用チームへのアラートが少なく、長期間プロダクトとのかかわりがないと、自信に関する問題が生じます。それは自信過剰か自信喪失どちらもあり得ますが、いずれにしてもインシデント対応が起きたときはじめて、知識のギャップを知ることになります。
四半期に1回か2回はオンコール対応をして、プロダクトに触れる機会を作るべきです。
また、Googleでは年に一回DiRT（Disaster Recovery Training）を全社規模で行っています。
まとめ
- 無用な負荷を増やさないためにアラートの設定は適切（SLOに影響を与えるもの）に設定する。
- プロダクトに触れる機会を四半期に1回か2回は最低でも作る
参考文献
- Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 136-138