エムスリーという会社でSREをしている高橋です。そこで本記事ではエムスリーのSREチームがこの1年の間に実施してきたSLO設定及びSLO超過監視活動を反省とともにご紹介していきたいと思います!!エムスリーにおけるSREチームの成り立ちかつてはSREがインフラチーム配下のポジションとして存在しているような状況でしたが、肩書は違えど作業内容はほとんど同じだったので、2018年7月からインフラチームがまるっとSREチームへと改称されました。www.m3tech.blogSLI/SLO設定/監視SREとしての活動を考えたときに、まずはサービスレベル目標(SLO)を決めてサービスの品質を改善していきたいと思いました。そこで、まずはサービスレベル指標(SLI)を決定する必要がありますが、広げすぎてもしょうが無いので最初は稼働率/HTTPレスポンスタイムのみに絞って設定を開始しました。下記がざっくりとしたエムスリーの監視構成になりますが、(New)となっているものをSLI/SLO監視のために追加しました。www.m3tech.blogそしてSLOを設定する上でまず困るのが、「最初にどんな値を設定するか」ということだと思いますが、エムスリーでは暫定的な値を仮設定して、定期的なミーティングで調整していきました。調整の際には、現在のパフォーマンスに基づいた決め方をせずに、ビジネス的にどの程度重要かという点に注視するように気をつけました。現場で学んだことこの取り組みの良かったことと反省点は下記のとおりです。ESに移行するつもりですSLO超過監視ツールを自作してしまったことElasticsearchにクエリ投げて結果によってSlack通知するだけならelastalertでよかった説(最近存在を知りました)新たな負債を作ってしまった可能性...SLO超過時のポリシーの策定/共有SLOを設定してしばらくの間は超過した際の対応については明確に決めておらず、その時々で気になったらJIRAチケット化して対応お願いするような運用にしていました。それだとSLO超過をスルーしがちになってしまうので下記を実施しました。ビジネスサイド)と、順次エスカレーションSREからビジネスサイドにいきなり連絡したりはしない対応は、Devが中心となり、SREやビジネスサイドと協力しつつ行う具体的には、以下の手順は下記の通り。いずれかを満たしたとき、超過が解消したとみなし、チケットをクローズする。5日間の集計値がSLOを下回るSLO変更ミーティングにてSLOを緩めるあるいは長期的なSLI改善施策を検討することで対応を延期することも可能(対応期限は1年以内とする)この取り組みの良かったことと反省点は下記のとおりです。直近の5日間の集計値は問題ないから結局何もしなかった、とか起きそう30日のスライディングウィンドウで毎日判定とかのほうが良さそう(各所で言われていることではありますが)まとめこれらの活動を続けてみて、少しづつではありますがサービスの品質を効率的に保つための環境が出来てきているように感じています。検討が不十分なまま拙速に進めてしまった感もあり、改善ポイントはまだまだ色々とありそうです。Overflow」を開発していますこんにちは。月別アーカイブ注目記事はてなブログをはじめよう!m3techさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。