Timee Product Team Blog

タイミー開発者ブログ

タイミーでSLOを導入してみた

SRE SLO

こんにちは、サーバサイドエンジニアの@Juju_62qです。 今回は年末から仕込んでいたタイミーのSLOについてと、その時に得た学びを紹介したいと思います。

概略

結論としてタイミーのSLOで大事にしているのは以下の3つです。

  • プロダクトの緩やかな品質低下を検知できるものであること
  • プロダクトの健全性を大局的に把握できるものであること
  • 罰則はSLOを消費する行為に相反する行動を取ること

また、組織で新たなものをやる時は熱量/知識/経験のいずれか2つ以上が必要になることも学びとなりました。

SLO（Service Level Objective）とは

運用サービスが守るべきと考えられる品質と解釈しています。 SLOはサービスが健全に動いていることを知るための基準であり、これを破るとユーザの期待に応えられてないということを意味します。 また、SLOは観測可能な指標から定量判断可能な基準であり、SLOを利用した健全性判断では定性観点が入りません。

なぜSLOを作ったのか

サービスが一定の品質を保てないのであれば開発者はサービスの品質を高めることに注力すべきです。 一方で、品質が市場要求に対して過多なのであればもう少し攻めたリリースをしても良いでしょう（質とスピードの話はここでは置いておくことにします）。 この辺りの匙加減は一般に開発者のよしな力に依存しています。

その辺りの記述がSRE本にあるため引用して紹介します。

通常、リスクと労力の線引きが必要な部分について、既存チームは非公式になんらかのバランスを見出しているものです。ただし残念ながらそういったバランスが最適なものであるかは自明ではなく、関わりのあるエンジニアの交渉スキルだけで下された決定だったりします。

中略

それに対して私たちのゴールは、交渉を生産的な方向へ導くために利用できる客観的なメトリクスを定義し、両者に合意してもらうことです。判断はデータに基づくほど良いのです

品質をチームが意識しやすい形に落とし込み、攻めたリリースを許容しつつ高い品質を維持するためにタイミーではSLOを導入しました。

SLO導入前の状態

良くも悪くもPdMを主導に無邪気に開発をしていたという側面は否めません。 例えば「パフォーマンスは早い方がいいよね」という話をみんなが意識しつつも、それと機能開発で一体どっちが大きなROI（Return on investment）なのか説明するのは簡単ではありませんでした。 サーバのエラーレート、モバイルアプリのフラッシュフリーレートなども同様です。利用者にとっては一定以上待たなくていいこと、エラーが起きないことは当たり前なのにも関わらず機能の追加・改修を差し置いてそれを改善する改善することが妥当であると説明するのは困難です。

この辺りはみんなが暗黙的にやりたいと思いつつも実行に落とすのは少し困難な状態でした。改善に関しても意識が高い人の隙間時間に依存しており、組織としてはかなり脆弱な状態だったと思います。また、パフォーマンスやエラーレートって改善するのが基本的に正義という状況ではあるのでA/Bテストをするという話にもなりませんでした。

SLOの役割

タイミーにおけるSLOの役割はなんでしょう？ タイミーではSLOではサービスの当たり前品質を定量的に観測するためのものであり、基準として扱っています。

ここで"当たり前品質とは何か？"という話ですが例えば以下のようなものを扱っています（いますべて扱っているか？と言われるとそうではありません）。

  • モバイルアプリが落ちない
  • お仕事を探す上で、くりかえしお仕事画面と検索画面を行き来してもストレスがない
  • サーバが理不尽なエラーを返さない
  • ユーザが期待する動作をする

これらに該当する内容をSLIとして観測しつつ、初動ではチームを締めすぎない範囲で数値を設定、少しずつ絞めていきました。 タイミーのSLOの役割は 当たり前品質と攻めたリリースのバランスを取る、 当たり前品質の低下をいち早く検知する というものになります。

導入のために行ったこと

SLOを導入する下準備以下のようなことをやっています

  1. PdM、CSM、カスタマーサポートに話を聞いてビジネス的に守って欲しい部分、品質のヒアリングをする
  2. SLI, SLOを作ってPdMとすり合わせる
  3. SLOを一覧可能にする
  4. SLOについて説明する資料を作り、チームに共有する
  5. SLOを改善していく会議体をとりあえず設計する

大きく区別すると

  • ビジネス的に間違ってなさそうなSLOを設計する
  • 運用に携わる人にSLOの説明をする
  • SLOをとりあえず運用・改善可能にする

という感じになります。

タイミーで定義しているSLOについて

現在タイミーのワーカーチームでは以下の4つのSLOが運用されています。

  1. 全体のアクセスのうちA%が正常なレスポンスを返す（2xx, 3xx, 4xx）
  2. 検索API（ファーストビューの95%ile）がB[msec]を切っている期間がC%以上
  3. モバイルアプリケーションのクラッシュフリーレートがD%以上
  4. 定めたAPIの書き込みアクセスのバリデーションエラーに対する成功率がE%以上

ルールとして、チームが意識するSLOは最大5つとしています。 過去にはタイミーのビジネスロジックとして特に重要なAPIのエラーレート等も扱っていましたが、その部分が壊れると即障害として扱われるためやめることにしました。 今残っているSLOは 定めたAPIの書き込みアクセスのバリデーションエラーに対する成功率がE%以上 のようにアプリケーションの品質の緩やかな低下を検知できるようになっています。

利用チームについて

前述の通りタイミーのSLOは現在ワーカーに価値を提供するワーカーチームでのみ運用されています。

タイミーはRuby on Railsで書かれたモノリシックなWebアプリケーションを中心としつつ、Reactで書かれた店舗向け画面、iOS, Androidで提供されるモバイルアプリケーションでサービスを展開しています。 チームについては価値の提供先で分かれています。現在は就労先となる店舗の体験を改善するクライアントチーム、働き手となるワーカーの体験を改善するワーカーチームが存在します。

初めは（構想時点でのチーム分割技術スタックに依存していたこともあり）、サーバサイドエンジニア全体をSLOの影響下に置いていました。 しかしながら、そうした場合に価値提供を意識したSLOの策定が困難だったため自分が所属しているワーカーチームのみを対象としました。 結果としてクラッシュフリーレートの導入が決まったり、サーバサイドのレスポンスタイムでなくレンダリング速度でパフォーマンスを見ていこうというような価値の対象を強く意識したアグレッシブな意思決定がスムーズにできるようになりました。 まだまだ運用が安定しないので展開はしていませんが、プラクティスがまとまってきた際にはクライアントチームにもSLOを展開できればと思っています。

SLOでどの範囲を扱うかについて

1つのSLOのもつ影響範囲が大きくなるほど、そこに対するアクションは非自明になります。 例えば 検索API（ファーストビューの95%ile）がB[msec]を切っている期間がC%以上 と 全体のアクセスのうちA%が正常なレスポンスを返す（2xx, 3xx, 4xx） で比較した時にその差は明らかです。 前者であれば、検索APIのパフォーマンスのボトルネックをボトルネックをあされば良いのに対して、後者はどこで問題が起きているのか？から始める必要があります。 結果としてSLOに違反した、ないししそうなりそうな場合に何をやっていいかがわかりにくくなります。

一方で細かく全ての領域にSLOを用意するとチームにわかりやすいかというとそうではありません。SLOの数が増えると管理するのも意識するのも対応するのも難しくなります。 このトレードオフにはいろんな考えがあるかと思いますが、タイミーではSLOを大局的な情報を知るためのツールとして扱い、問題が起きているという事実を示唆するために利用しています（調査に時間がかかっても良いという判断）。

違反時について

違反時のアクションはそれほど正確には定めていません。 基本的な決まり事としてはエラーバジェットの消費と相反する行動をしましょうという話をしています。

例えば「A/Bテストを検索部分に入れた結果検索APIのパフォーマンスが低下した。」という事象が過去に発生しました。 この際にした意思決定は、「A/Bテストの期間を十分なデータを貯めるための最小の期間として決めてしまいバジェットの消耗を最小限に抑える。」というものでした。

SLO違反時の振る舞いについてはデプロイを止めるというようなことがよく語られる印象がありますが、デプロイを止めるだけだと悪化の一途を辿るものも多いです。よって基本的に違反時については具体的な行動を定めず、場合によって機能開発や仮説検証を止めて改善に向かうということだけを共通認識として持っています。

違反時の決まり事をふわっとしたものを動きにした結果

定めたAPIの書き込みアクセスのバリデーションエラーに対する成功率がE%以上

のような短期間では改善できなさそうな項目もSLOに取り込むことができました。 これについては違反時には次の3,4ヶ月でPdMに改善の筋道を立ててもらうということで合意しています。

SLOの見直しについて

現状SLOの評価期間を月次にし、見直しも毎月話して行っています。参加者はCTO, PdM, 希望者としています。 月次の会についてはまだ話すことがたくさんあるので引き続き行う予定です。 もう少し枯れてきた場合、頻度を減らしていくかもしれません。

現在具体的には、以下のような内容を話しています。

  • 先月のSLOについて
    • 数値のおさらい
    • SLOに対するアクションのおさらいと振り返り
  • SLOの過不足について
  • 違反時のアクションについて
  • 話し合い自体のの反省

時間としては1hかけています。また、チーム全体としてはレトロスペクティブ等でSLOの扱い方をチューニングしています。

SLOを導入してよかったこと

SLO導入による明らかな変化として"チームが数字の変化に反応して勝手に改善をするようになった"というものがあります。 SLOを定義したことによって、正常、危険、異常というラインが明示され、チーム内での数値的な危機感も同期することができました。 また、SLOをある程度みやすく管理することによって日々の数値の変化にも敏感になりました。 結果として、エラーバジェット減少の兆候を早く汲み取り、自律的にプロダクトの当たり前品質が改善できるようになりました。

失敗と学び

SLOをやる中で幾らかの学びがありました。SLOに直接関わる学びについては幾らか前述してきました。 一方でSLOをやっていく中で感じた組織的な学びについて記していこうと思います。

小さく始める

散々言われていますが、小さく始めることは重要です。 ちらっと話しましたが今回僕がした失敗として、チーム分割が行われた時にそれに合わせてスコープを変更しなかったというものがあります。

SLOを元々作り始めた時はタイミーではモバイルアプリを開発するチームとサーバサイドを開発するチームがありました。現在は価値の提供対象で割っていてワーカーチームとクライアントチームとなっています。SLOはチーム分割のすぐ後くらいに実運用を開始しました。 元々サーバサイドチームを見ながら作ったものだったので疑問を持たずにワーカーチームとクライアントチームの2チームを影響範囲にして運用しようとしました。結果として以下のようなデメリットが発生していました。

  • SLO運用、改善のオーナーシップが曖昧
  • サービス全体が対象なので何かに特化したSLOを採用しづらい
  • 関係者が多く合意形成が少し煩雑（当時エンジニア20人程度で大したことないにせよ）

もちろん一定の強制力を持って推し進めるという手法を使えば、全社に対して一度に適用することができるかもしれません。 しかしながら個人的に自律性を大事にしてSLOを導入していきたかったためその方法を取りませんでした。 最終的には自分の所属するワーカーチームのみをSLOの影響範囲とすることにし、ワーカーに特化したSLOを策定するに至りました。

やっていきするときに必要なもの

ここでいうやっていきは以下のようなものです。

やっていき = 枯れていない何かの考え方・技術を導入すること

弊社にとってSLOという概念はこの"やっていき"にあたるものであったと思います。 SLOについて社内では確立された知見はありません。また、SLOはサービス特性や会社のカルチャーによってその形がかなり異なるため、他社の事例も100%踏襲することができません。 ゆえに、会社やチームには経験がありません。

また、導入時は自分が引っ張って諸々の設計等をしていたため、全員に大きな熱量があるわけではありませんでした。 自分がやっていくぞ！！となっている一方、良い感じの方向に倒れるなら乗っかりたいと思う人もいたわけです（これは自然なことだと思います）。 やった方がいいという意識があってもそこに今自分の時間を使うことが妥当でないという方もいました（優先順位の問題）。ゆえに全員に熱量があったわけでもありません。

知識についてはある程度勉強していたり、資料を作ったりしていたのである程度あったのですが、経験=プラクティスが固まっていない以上熱量をかけないと物事が進んでいきません。そこで熱量のある自分がボールを持ちやすいように自身のチームに持たせるという選択をしました。

ただし、全社的なスケールをもくろむという意味で試した結果を経験としておき、必要なタイミングで他のチームが時間をかけずとも始められる準備をしようと話をしています。知識と経験があり、労力が小さいのであれば大きな熱量がなくともSLOを導入できます。 "やっていき"を自律的に進めるためには熱量/知識/経験のいずれか2つ以上が必要になることを今回の件から学びました。

終わりに

今回はSLOの導入に伴った学びや、タイミーでのSLO活用事例を紹介しました。 今後もSLOだけでなくプロダクトやチームの数値を定量、定性的に観測し、事実に基づいた改善を素早く行えるように頑張っていきたいと思います。 プロダクトや組織状況の継続的な観測や改善に興味がある人はぜひ声をかけてください！