SLO設定/超過監視にまつわる活動の振り返り

※ この記事は SRE Advent Calendar 16日目の記事です。

皆さんこんにちは。エムスリーという会社でSREをしている高橋です。

早いもので、今年ももう終わりですね... ！ そこで本記事ではエムスリーのSREチームがこの1年の間に実施してきたSLO設定及びSLO超過監視活動を反省とともにご紹介していきたいと思います！！

エムスリーにおけるSREチームの成り立ち

かつてはSREがインフラチーム配下のポジションとして存在しているような状況でしたが、肩書は違えど作業内容はほとんど同じだったので、2018年7月からインフラチームがまるっとSREチームへと改称されました。

www.m3tech.blog

SLI/SLO設定/監視

SREとしての活動を考えたときに、まずはサービスレベル目標（SLO）を決めてサービスの品質を改善していきたいと思いました。そこで、まずはサービスレベル指標（SLI）を決定する必要がありますが、広げすぎてもしょうが無いので最初は稼働率/HTTPレスポンスタイムのみに絞って設定を開始しました。

下記がざっくりとしたエムスリーの監視構成になりますが、（New）となっているものをSLI/SLO監視のために追加しました。

• サービスの稼働率監視はNagios, NodePing
  • サーバではなくサービスの稼働率を計測するためにサービス毎にURL外形監視を網羅的に追加（New）
• ログ監視はFluentd + Elasticsearch（オンプレ）
  • レスポンスタイムは主にアクセスログから取得
  • Elasticsearchのデータ保持期間は1月
• その他詳細な監視は各種Expoter + Prometheusで実施
• 可視化はKibana, Grafana, Datadog
  • 各サービス毎のサービスレベル監視用ダッシュボードを整備（New）
• アラート通知はNagios, Grafana（主なデータソースはCloudWatchLogs, Prometheus, PostgreSQL）, Datadog, Pythonスクリプト
  • サーバ停止などは即時通知
  • 日時で過去5日間の値を集計してSLOを超過していればSlack通知（New）
• 長期的な値を残すために各月ごとに集約した値をElasticsearchのSLIメトリクス用インデックスに登録（New）
  • 月次で集計してSLOを超過していた場合はSlackに通知（対応必須の通知）

※ 詳細は下記記事にまとめています www.m3tech.blog

そしてSLOを設定する上でまず困るのが、「最初にどんな値を設定するか」ということだと思いますが、エムスリーでは暫定的な値を仮設定して、定期的なミーティングで調整していきました。
また調整の際には、現在のパフォーマンスに基づいた決め方をせずに、ビジネス的にどの程度重要かという点に注視するように気をつけました。
※ 私がSREとして活動を始めたあたりにちょうど投稿されていたGoogle Cloud Platform Japan Blogの記事が非常に参考になりました...感謝！
Google Cloud Platform Japan 公式ブログ: 優れた SLO を策定するには : CRE が現場で学んだこと

この取り組みの良かったことと反省点は下記のとおりです。

良かったこと:

• 各サービスのダッシュボードを（ある程度）統一できた
• 通知により改善を促すことが出来るようになった
  • これまで検知できていなかったものが検知できるようになった

反省点:

• 長期的な値を残す間隔を月ごとにしてしまったこと
  • ケチりすぎて100年くらい放置しても問題無さそうなサイズに
  • 流石に粗すぎるので、過去のデータを見返すときに「この月の値悪いけど一体どの日の何が原因だっけ？」と思うことも（サマりすぎには注意...）
• ElasticsearchのストレージをケチってHDDにしてしまったこと
  • 遅すぎてちょっとレンジを広げて見ようと思うとTimeoutになるのでストレスがマッハ
  • とっととAWS ESに移行するつもりです
• SLO超過監視ツールを自作してしまったこと
  • Elasticsearchにクエリ投げて結果によってSlack通知するだけならelastalertでよかった説（最近存在を知りました）
  • 新たな負債を作ってしまった可能性...

SLO超過時のポリシーの策定/共有

SLOを設定してしばらくの間は超過した際の対応については明確に決めておらず、その時々で気になったらJIRAチケット化して対応お願いするような運用にしていました。 しかしそれだとSLO超過をスルーしがちになってしまうので下記を実施しました。

• 月間のSLOを超過時したらJIRAチケットを自動作成するように設定
• 下記ポリシーを定めて全体に周知


SLO超過時ポリシー

• 実際にSLO超過が起きた時は、SRE → Dev（ → ビジネスサイド）と、順次エスカレーション
  • SREからビジネスサイドにいきなり連絡したりはしない
• 対応は、Devが中心となり、SREやビジネスサイドと協力しつつ行う

具体的には、以下の手順は下記の通り。

1. JIRAに対応チケットを作成

   • SREチームがJIRAにチケットを作成し、サービス担当Dev（の適当な誰か）をアサイン（チケット一覧）

2. 対応検討

   • チケットをアサインされたEngはSLO超過を解消するための施策を検討する
     • 適宜チケットに施策や状況を追記したり、別施策をサブチケットとして作成する
   • アプリ起因の不具合の場合
     • 新機能リリースよりもSLI改善を優先する
       • ビジネス都合もあるため「強制」ではなく「推奨」
       • 実際の優先度はビジネスサイドとの相談し各Dev側が検討する
     • SLI改善施策についてDev-SRE間でミーティングしアクションを決定

   • インフラ起因の不具合の場合
     • SLI改善施策についてSRE内でミーティングしアクションを決定

   • SLOが適当ではないと思われる場合
     • Dev-SREでSLOの変更を協議する
     • 変更する際は明確な根拠を示し、担当チームのチームリーダー以上の承認を得る
     • 変更は表に記録


3. 進捗確認

   • 改善施策の実施状況はJIRAのチケットに追記し、Eng・ビジネス・SREの間で共有
   • 進捗確認ミーティングを適宜実施


4. 解消

   • 下記のいずれかを満たしたとき、超過が解消したとみなし、チケットをクローズする。
     • 5日間の集計値がSLOを下回る
     • SLO変更ミーティングにてSLOを緩める
   • あるいは長期的なSLI改善施策を検討することで対応を延期することも可能（対応期限は1年以内とする）

この取り組みの良かったことと反省点は下記のとおりです。

良かったこと:

• JIRAチケットが確実に作成されることによって対処漏れが減った（気がする）
• 改善施策も決めずに放置というのは無くなった

反省点:

• 月ごとのチケット作成だと対応が遅れてしまう
  • 月初に爆発しても翌月からポリシー適用 -> 直近の5日間の集計値は問題ないから結局何もしなかった、とか起きそう
  • 30日のスライディングウィンドウで毎日判定とかのほうが良さそう（各所で言われていることではありますが）

まとめ

これらの活動を続けてみて、少しづつではありますがサービスの品質を効率的に保つための環境が出来てきているように感じています。ただ検討が不十分なまま拙速に進めてしまった感もあり、改善ポイントはまだまだ色々とありそうです。

We are hiring !

そんなわけで......SRE絶賛募集中です！！

jobs.m3.com