アドベントカレンダー32日目:SREを読んでみた「オンコール対応」編③

  • 2021.01.07
158
NO IMAGE

オンコール対応の3回目です。
オンコール対応の最後の回になります。最後は、オンコール対応の負荷が増え過ぎた場合についてを見ていきます。

不適切な運用負荷の回避

SREは作業の50%をエンジニアリングに当て、残りの50%で運用を行います。
運用作業の過負荷を避ける目標を数値化するために、過負荷の兆候を計測できる形にしておくことが重要です。(日々のチケット数を5以下に抑えるやシフトごとのページ発生イベントを2以下にするなど)

システムのアラートは、SLOを脅かす症状に対して、行うべきです。
細かいアラートは、それを対応するエンジニアの生産性を下げたり、より重要なアラートへの注意を散漫にします。

また、一つのインシデントに対して、複数のアラートが発行されることがありますが、これはできるだけインシデントとアラートの関係が1対1になるように調整すべきです。
この理由は、関連のあるアラートが複数発行されると、そのアラートの切り分けに時間が費やされたりしてしまい、インシデントへ集中しづらくなるからです。
アラートを関連性によって、まとめて、必要のないアラートは発行されないようにすべきです。

運用の過負荷は、モニタリングの設定によるものだけではなく、開発チームにより、信頼性の低下をもたらすような修正がなされたときにもおきます。
運用の負荷がかかり過ぎている場合、極端なケースでは、SREチームにおいて、運用が行えるレベルになるまで、開発チームへオンコールの対応を行ってもらえるように交渉することもできます。

油断ならない敵:低すぎる運用負荷

運用チームへのアラートが少なく、長期間プロダクトとのかかわりがないと、自信に関する問題が生じます。それは自信過剰か自信喪失どちらもあり得ますが、いずれにしてもインシデント対応が起きたときはじめて、知識のギャップを知ることになります。
四半期に1回か2回はオンコール対応をして、プロダクトに触れる機会を作るべきです。
また、Googleでは年に一回DiRT(Disaster Recovery Training)を全社規模で行っています。

まとめ

  • 無用な負荷を増やさないためにアラートの設定は適切(SLOに影響を与えるもの)に設定する。
  • プロダクトに触れる機会を四半期に1回か2回は最低でも作る

参考文献

  1. Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 136-138