【レポート】タップルとエムスリーのSREの話を聞いてきました

SRE Lounge #9という勉強会に行ってきました。

タップルSREの軌跡と描く未来

https://www.slideshare.net/HakamataRui/sre-lounge9-sre-148130990

面白かった話としては、SREの世界ではSLOという概念は浸透していると思いますが、タップルでは足元のタスクをリスクスコアという指標で全てスコア化して、それをSLOで管理しているということでした。また、それとは別に中期的な組織の理想状態を考えてロードマップを作成しているそうです。

足元のタスクというのは障害の報告書であるポストモーテムの再発防止策をインパクトによって分類してスコア化しているようです。その合計スコアが100を切らないというSLOにし、100を切らないうちは中期的な組織のタスクに時間を使っていうタイムマネジメントをしているそうです。

中期的な組織というのは3年後の理想状態を検討して、SLO、マイクロサービス、不具合発生率の極小化、不具合影響の極小化、アーキテクチャの標準化などを目標としていました。日々のタスクをSLOにして管理しているという話はとてもおもしろかったです。

リスクスコア管理のやり方としてはdatadogを使用していて、イシューをgithubで管理、Lambdaで取得しdatadogへ送るというようなやり方だそうです。

緊急度が低いが重要度の高いタスクはマネジメントしないと絶対やらないという言葉が印象的でした。

エムスリーはどのようにしてSREを始めたか

https://speakerdeck.com/tshohe/sre-lounge-number-9-emusurihadofalseyounisitesrewoshi-metaka

エムスリーではSLIを

  1. 稼働率
  2.  ヘルスチェックURLを外形監視
  3. レスポンスタイム

と定めているそうです。

計測方法としてはFluenntdで収集してElasticSearchとDatadog(SLOの設定ができる)を使っていました。 SLOの設定としては全社的な要件が決まっていたのでそれに従ったそうですが、

  1. 月間稼働率99.9%
  2. 月間レスポンスタイムの99%タイル値が1000ms未満

と定めているそうです。 決め方としては、SREworkbookに書いてる決め方が参考になったそうで、

  1. SLOの監視の通知は1日1回、超えてたらアラート
  2. <li>月間のSLOを超過したらJIRAのチケット作成</li>
    
    <li>SLOを超過したらSLOを緩めるか改善施策を検討</li></ol>
    

    というサイクルで回しているそうで、プロダクションミーティングでSLOの定期的な見直しを行っているそうです。 いまは割と主観で決まっているので顧客満足度を測定して決めたりしたいらしいですが、顧客満足度の測定というのは難しいので、ここはまだ進んでいないようです。

    アラートがオオカミ少年化しないように注意する必要があるというのはあるあるですね。