SLI/SLOをちゃんと運用しようと準備している話

7644 ワード
SRE devops devops テキストリンク

こんにちは、READYFORでソフトウェアエンジニアをしている@shmokmtです。
本記事は「READYFOR Advent Calendar 2021」の22日目の記事です。
21日目は　@kotarella1110 さんによるフロントエンドのログ周りを改善する過程で OSS (Datadog Browser SDK) にコントリビュートした話でした。自ら積極的に手を動かし、OSSの不具合を修正しようとする姿勢は見習いたいものです。

READYFORではスクワッド体制[1]という組織体制が組まれており、私はシステム&データ基盤スクワッド（以下、本スクワッド）に所属しています。
本スクワッドでは、インフラ領域を中心とした開発効率の向上や堅牢なシステムに繋がる施策を中心に取り組んでおり、来年からはSLI/SLOを本格的に運用しようと考えています。
現在はその準備をしている段階です。
今回は、このような取り組みに至った経緯やチームでの取り組みについて紹介します。

2021年はたくさんの新機能をリリース

2021年は多くの機能をリリースすることができた年でした。
プロダクトとしては以下のような主要な改善/機能追加がされています。

インフラ面も含めると、EC2で稼働していたモノリシックなRailsアプリケーションをECS/Fargateに移行し、再現性のあるデプロイを今までよりも高い頻度で実施できるようになりました。[2, 3]

上記のようにEMの熊谷さんがデプロイ頻度をRedashで可視化できるように整えてくださりました。[4]

溜まっていくお問い合わせ/不具合報告

ユーザーに多くの機能を提供できた&高頻度でデプロイできるようになった一方で
社内のお問い合わせ/不具合報告のSlackチャンネルでは
以前よりも多くのお問い合わせ/不具合報告が届くようになりました。

お問い合わせ/不具合報告はPdM（PMMまたは、TPM）が一次受けをし、
不具合修正を優先するか機能開発を優先するか都度判断し、エンジニアに依頼をする形を取っています。ですが、エンジニアおよびPdMが不具合修正の優先度をどうするか定量的に意思決定できる材料がないため、エンジニアリング組織として疲弊しやすい状態となっているのが課題となっています。
そして、それを解決する優先度も高くなってきました。
イメージとしては以下のタイミーさんの資料のような状況に近いです。[5]

ユーザーやビジネスに対する影響度合いを示す何か、つまりSLI/SLOがあればそれを意思決定の材料とすることができるはずです。

準備していること

小さく始めて細かく改善していけばいいものの、SLI/SLOを本格的に運用するためには
ある程度準備が必要です。現在は以下のような項目を検討しています。

  • READYFORのスクワッド体制と親和性の高い体制

現時点では、スクワッド組織がOKRと強く紐付いていること、SREがマネージャー含めて3人しかいないこと、各メンバーのスキルセットなどを考慮し、メルカリさんの資料内に出てくる「Movable Emmbedded SREs」[6]が
READYFORの組織と親和性が高いのではないかという仮説をチームで持っています。

  • エラーバジェットが枯渇したときの対応

一般的にエラーバジェットはリリースの頻度を下げるなどの一定の強制力を持ちますが、どこまで許容するか等は議論のポイントです。
ビズリーチさんのように意思決定しやすいような枠組みを事前に取り決めておくのが良さそうであると考えています。[7]

  • 可観測性の向上

Rob Pike氏1の

Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.

という言葉があるように一般的には計測できるものをした上で議論するのが定石といえます2。
READYFORのインフラ基盤は整ってきたもののまだ可観測性（ログ、トレーシング）が不十分である箇所が多々あります。
システム全体を俯瞰して議論するためにも可観測性を上げる必要があります。

  • issue管理

READYFORではスクワッドごとにissue/チケットを管理している場所が違います。
SREが機能開発をするスクワッドに参加した場合、どこでどのようにissueを管理した方が良いのか等も検討する必要があります。

  • SREに関する書籍/ドキュメントの輪読会

これを機にREADYFORにおけるSREの在り方を模索しようと、チームでSREに関する書籍/ドキュメントの輪読会をはじめました。

輪読会はローテーションで担当者を回しており、会の流れは概ね以下のようなものです。

  1. 当番の人が対象のドキュメントを事前に簡単に要約し、社内Wikiにアップロードする
  2. 要約の読み上げ、共有（30分）
  3. 議論（30分）

抽象的で難しい話が多いですが、なんとか噛み砕いて自分たちの組織に適用できそうなノウハウを模索しています。

おわりに

今回はREADYFORでSLI/SLOを本格的に運用するに至った経緯と現在やっている準備の内容を紹介しました。まだ準備段階ですが、これから運用することで得られたアンチパターンやノウハウを貯めていけたら良いなと考えています。来年からはこれらの指標を活用し、組織として定量的に意思決定をすることで信頼性/ユーザー体験の向上に寄与したいと考えています。明日はTPM（テクニカルプロダクトマネージャー）である@kecyさんの番です。お楽しみに。

参考

[1]: "エンジニアリングマネージャーとしての開発力向上の取り組みついて - Qiita", https://qiita.com/KUMAN/items/8cee8e33628850fd4e29#1-1-%E3%82%B9%E3%82%AF%E3%83%AF%E3%83%83%E3%83%89%E4%BD%93%E5%88%B6%E3%81%A8%E3%81%AF

[2]: "READYFOR における ECS 導入とエンジニアへの ECS 環境・機能提供の話 - READYFOR Tech Blog", https://tech.readyfor.jp/entry/2021/10/01/100820

[3]: READYFOR SREチームが支えるインフラ構成と変遷 - READYFOR Tech Blog, https://tech.readyfor.jp/entry/2021/07/21/105320

[4]: "エンジニアリングマネージャーとしての開発力向上の取り組みついて - Qiita", https://qiita.com/KUMAN/items/8cee8e33628850fd4e29#%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4%E5%9B%9E%E6%95%B0%E3%81%A8%E3%83%AA%E3%83%BC%E3%83%89%E3%82%BF%E3%82%A4%E3%83%A0%E3%81%AE%E5%8F%AF%E8%A6%96%E5%8C%96

[5]: SLOを活用した技術的改善, https://speakerdeck.com/juju62q/slowohuo-yong-sitaji-shu-de-gai-shan

[6]: サービスと組織の拡大を支えるEmbedded SREs, https://speakerdeck.com/0gm/sabisutozu-zhi-falsekuo-da-wozhi-eruembedded-sres

[7]: エラーバジェットどう運用してますか？, https://speakerdeck.com/shonansurvivors/error-budget-practice

  1. プログラミング言語GoやUTF-8の開発者です ↩

  2. 原文: Basics of the Unix Philosophy
    Chapter1.Philosophy     ↩