ボトムアップでSLOを導入 2年半運用して分かった失敗と変化

タイミーでは2020年12月にSLOを取り入れました。SLOを実際に導入してみると、当初の想定と異なる部分が出てきます。また、組織やシステムの変化によって対応を迫られる場面も生まれます。時には定義やアプローチの失敗から運用がうまくいかない場面もあります。
これらの事柄に機能開発を担当しているエンジニアとしてどのように対応し、乗り越えてきたのかをお話しします。その過程で分かった失敗や教訓を言葉として伝えながら、結果としてどのようにSLOを運用しているのかを紹介します。

Transcript

1. 2023/7/25　岡野兼也 ボトムアップでSLOを導入 2年半運用して分かった失敗と変化 @Juju_62q
2. 岡野兼也 / @Juju_62q 株式会社タイミー プロダクト本部 ワーキングリレーションチーム （Stream Aligned Team） Backend Engineer
3. 本日の目標
4. この問題、 タイミーの発表で聞いたやつだ！
5. ここで聞いたことを糧にして問題を防いで欲しいとは言いません。 時にわざと問題に直面させて解決することで、 組織の練度を高めるという手法は有効です。 一方で問題にぶつかるのは辛いこともあるでしょう。 転んだ時にきちんと受け身を取る準備をしましょう。
6. 目次 • タイミーについて • タイミーのSLOについて • 教訓: 特に同僚に影響を与える意識を持つ • 教訓: 変化しやすいものに依存させない • 教訓: 重要すぎる指標をSLIにしない • 教訓: とにかく続ける • まとめ
7. 1 タイミーについて
8. タイミーとは 8 ｢働きたい時間｣と｢働いてほしい時間｣を マッチングするスキマバイトサービス 従来の「求人サイト」でも「派遣」でもない
9. タイミーの使われ方 働き手と雇い手がいるBtoCプラットフォームを提供しています。外からは見えづらいですが、スポットワークを実現するための雇い手 の手続きや課題は多く、そのプロセスのほとんどをシステム化しています。 9
10. 募集人数の推移 10 ※1：2022年4Qと2021年4Qの比較 コロナ禍においても、 過去に例を見ない程の 加速的高成長を実現。
11. 2 タイミーのSLOについて
12. タイミーの開発組織とSLOの歴史 from ちいとぽStudy Phase3 マッチングチームを影響範囲としてSLOを運用 開発にFBをかけるためスクラムイベントを使い始め る Phase2 Workerチームを影響範囲としてSLOの 運用を開始 運用に関しては様々な実験を実施 スクラムチームとは少し距離があった Phase1 負荷対策やアラートが本格導入 SLOの下準備を行う 解散直前に導入準備が整う
13. 今のSLO Phase4（現在） マッチング領域でSLOの運用責任を持つ（持たせたい） スポットワークシステム領域の1つのチームがSLOの運用を開始（今日の話は対象外）
14. タイミーの開発組織とSLOの歴史 Phase3 マッチングチームを影響範囲としてSLOを運用 開発にFBをかけるためスクラムイベントを使い始め る Phase2 Workerチームを影響範囲としてSLOの 運用を開始 運用に関しては様々な実験を実施 スクラムチームとは少し距離があった Phase1 負荷対策やアラートが本格導入 SLOの下準備を行う 解散直前に導入準備が整う
15. なぜ導入したか 元々5xxエラーは全て対応可能という前提が体制が敷 かれていた。1度のエラーでオンコール対応をすること もあった。 しかし、急成長する中で運用が困難になっていった。機 能開発と5xx修正とのバランスが取れず、 5xxエラーの 修正が後回しにされることがあった。 コロナ禍においても、 過去に例を見ない程の 加速的高成長を実現。
16. なぜ導入したか 100%を目指すことによって、少ないエラーが割れ窓 となっていた。結果として 99.99%を目指すよりも信頼 性が下がってしまっていると感じた。 そこで適切な高さの目標（ = SLO）を導入することにし た。 コロナ禍においても、 過去に例を見ない程の 加速的高成長を実現。
17. その後いろんなことを経て... （進行上必要な部分に必要な時に触れます）
18. 2023年6月のSLO 1. ALBのエラーレート 2. 検索API（ファーストビュー）のレスポンスタイムのp95 3. iOSアプリのクラッシュフリーレート 4. Androidアプリのクラッシュフリーレート
19. SLO導入の効果（なるべく昔の同じ指標との比較） 99.97% -> 99.99% 基準が3[s] -> 700[ms] Android: 99.8% -> 99.9%
20. もちろん様々なエンジニアの不断の努力の賜物ですが、 サービスを成長させながら信頼性を向上させることに成功🎉
21. 100%を目指さないことによる信頼性の上昇を実現🎉
22. と、成果の話はこれくらいにします。 ここからは失敗の話をしていきます。
23. 3 特に同僚に影響を与える 意識を持つ
24. タイミーの開発組織とSLOの歴史 Phase3 マッチングチームを影響範囲としてSLOを運用 開発にFBをかけるためスクラムイベントを使い始め る Phase2 Workerチームを影響範囲としてSLOの 運用を開始 運用に関しては様々な実験を実施 スクラムチームとは少し距離があった Phase1 負荷対策やアラートが本格導入 SLOの下準備を行う 解散直前に導入準備が整う
25. SLO作成時にやったこと CTO PdM Customer Support 営業 こんなことやりたいんですけど 過去エラーで困ったりしましたか？ 重要にしたい機能はありますか？ etc. あんまり問題ないですよ〜 ぜひやってみましょう！ by CTO CTO, PdMとお金を産む最小限どの機能を話したりしながら合意をとった。 また、エンジニアリング部署以外にもやろうとしていることを説明し、理解を得た。 ※当時は全社で100-200人くらいの規模であり、今よりかなり小さい
26. SLO作成時にやったこと エンジニア SLOというものの運用を始めようと思います こんな感じのものです こんな感じにやっていく予定です なるほど（理解した）。 やりたいことを説明し、理解を得た。
27. 結果としてはスムーズな行動変容は起きなかった
28. なぜか？
29. マネージャーの承認を得ているだけで、 実際に行動をする人の文化を変えるに至らなかったから
30. 文化文化って言ってるけど技術の話じゃないの？
31. “culture eats strategy for breakfast, technology for lunch, and products for dinner, and soon thereafter everything else too.” 文化は戦略を朝食として食べ、技術を 昼食に、プロダクトを夕食に、その後全 てを飲み込んでしまいます。 – Bill Aulet TechCrunch, Culture Eats Strategy For Breakfast, 2023/07/24, https://techcrunch.com/2014/04/12/culture-eats-strategy-for-breakfast/
32. 上長との1on1にて チームの文化や考え方に影響を与えるにはどうすればい いでしょうか？ 文化を変えるには集団の中で 3割の人の行動を変えるの が有効です。
33. ハーバード大学の社会学者であるロザベス・モス・カンターは、「黄金の 3割」理論を提唱した。 これは、組織のなかでマイノリティの割合が3割となったときに、組織全 体の文化が傾くという理論である。 マイノリティグループとマジョリティグループの割合が35:65となったとき に、マイノリティグループが連帯を組み、組織文化に変化をもたらす。 –Kanter, R. M. 公益財団法人日本オリンピック委員会 , 黄金の3割とは？, 2023/07/24, https://www.joc.or.jp/about/women-leader/words/06.html Kanter, R. M. (1977) Men and Women of the Corporation. Basic Books: New York.
34. 組織文化とSLO SLOはツールである - 基準を明確にすることで行動につながりやすくなる - 目に見えるようにすることで開発の中で信頼性を大事にしやすい 最終的には信頼性をうまく扱う文化を作りたい - 「信頼性と機能開発のバランスを取ろうね！」と伝えて信頼性を意識する 文化ができるのであればSLOはなくても良い - ただし、難しい。そのためSLOというツールを利用して3割の行動を変え、 組織文化に影響を与える
35. やるべきだったこと 前準備 - やりたいことに対して興味を持ってくれそうな少数を探す - 興味を持ってくれそうな人に相談してみる 実行 - 上長や他部署の方より前に、同僚の行動を1人ずつ変えていく - 行動を変える上での足枷を排除する
36. なぜ事前に人を探すのか 人の関心は物事の蹴り始めが最も強いのでその段階で30%の行動を変えられているとすご くやりやすい。 信頼性にへの関心の強さは様々なので少しでも興味が強い人に仲間になってもらう。
37. なぜ相談をするのか 指示よりも、相談の方が強いオーナーシップを持ってくれる気がする（要出典）。 自分で考えたものには愛着が湧くのでその状況をなるべく作る（要出典）。
38. 教訓: 特に同僚に影響を与える意識を持つ
39. 4 変化しやすいものに依存さ せない
40. タイミーの開発組織の歴史とSLO Phase3 節理面を探して マッチングチームは1チームでLeSSだった マッチングチームを影響範囲としてSLOを運用 開発にFBをかけるためスクラムイベントを使い始める Phase4（現在） マッチング領域内に複数のチームがある マッチング領域を対象としてSLOの運用責任を持つ（持たせたい） スポットワークシステム領域の1つのチームがSLOの運用を開始（今日の話は対象外）
41. Q. タイミーにおいてチームの運用は安定しているか？
42. Q. タイミーにおいてチームの運用は安定しているか？ A. No
43. なぜか
44. タイミーは複雑 働き手と雇い手がいるBtoCプラットフォームを提供しています。外からは見えづらいですが、スポットワークを実現するための雇い手 の手続きや課題は多く、そのプロセスのほとんどをシステム化しています。
45. タイミーは複雑 from 開発生産性Conference バリューチェーン ユーザー ペルソナ ユーザーペルソナやバリューチェーンでソリューションが綺麗に分かれないため、自然な節理面が見いだせていない
46. タイミーは複雑 from 開発生産性Conference マッチングプラットフォームゆえの両サイドのユーザーペルソナ ソリューションの多くがワーカー/事業者(法人・店舗など)の双方に影響を及ぼすものが多い。(求人出稿など) 従ってユーザーペルソナを節理面にしづらい バリューチェーン上の川上にあるプロセスが川下のプロセスに密接に関わる 勤怠管理が給与計算のベースとなるなど、プロセス間の依存関係が強く存在するため、バリューチェーン上のプ ロセスというビジネスドメインで摂理面を設定する事が難しい 結果としてモノリスとしている 節理面をうまく探索出来ていないため、結果として意図的に Ruby on Rails のモノリスのままにしている ユーザージャーニーをストリームとして扱っていることの難しさ
47. チームのミッションは 解像度が上がったタイミングで整理される （!= メンバーが不安定、不安定なチーム）
48. ミッションが変わると最適な手段が変わる スクラムイベント等も型を残しつつ整理を行う
49. タイミーの開発組織の歴史とSLO Phase3 節理面を探して マッチングチームは1チームでLeSSだった マッチングチームを影響範囲としてSLOを運用 開発にFBをかけるためスクラムイベントを使い始める Phase4（現在） マッチング領域内に複数のチームがある マッチング領域を対象としてSLOの運用責任を持つ（持たせたい） スポットワークシステム領域の1つのチームがSLOの運用を開始（今日の話は対象外）
50. チームに合わせてSLOの運用が整理され、 運用を考え直すことになった
51. タイミーの開発組織の歴史とSLO 「マッチング領域」に関しては存在がある程度安定したように見えたので、1つのチームではなく「マッチング領域」に運用を持たせることを考えた。 一方でプロダクトマネジメントの単位はチームである。結果としてエンジニアがチームに対して干渉しにいく必要がありそこまでうまく回せている自覚がない。 この運用に関しては模索中です。良い方法があれば教えてください。
52. 教訓: 変化しやすいものに依存させない
53. 5 重要すぎる指標をSLIにし ない
54. 昔あったSLO 重要だと捉えていたAPIのWriteアクセス成功率をSLIとしていた。 ※「QRコード」はデンソーウェーブの登録商標です
55. 起きたこと マッチングや給与振込、出退勤に関して少数のエラー発生が許容できなかった。 結果としてSLOに関わらずオンコール対応や改善を行う必要があり、 実質的にSLOが機能しない状態となった。 やばい。なんとかしないと。
56. 問題かどうか プロダクトの信頼性の高さという観点では問題はない 一方で信頼性と機能開発のバランスを取るというSLOの目論見は失敗している 不要と判断して削除しました
57. なぜ起きたか 重要すぎるAPIに対して割合でエラーを許容するSLOを作ってしまった - マッチング - 給与振込 - 出退勤等 特に給与振込や出退勤に関してはカスタマーサポートの問い合わせが増えやすい この場合30daysのSLOというより短期間のエラー数に基づいて活動した方が良い。 結果としてアラートを作って対応している。
58. SLOの目的を適応させる ※クリティカルユーザージャーニーを考える SREのプラクティスからは外れているかもしれません 現時点でマッチング領域では重要なAPIを対象としたSLOは運用していない。 また、この反省を踏まえて以下をSLOの目的の一つとした。 「非機能要件の緩やかな低下を防ぐ」 重要なAPIはアラートを設定して信頼性を担保することを目指す。 もし、SLOを作るのであればAPI1つずつにSLOを設定していきます。
59. 教訓: 重要すぎる指標をSLIにしない
60. 6 とにかく続ける
61. 取り組みを行う上で、推進者の心が折れたら終わりです。 続けられるように気持ちや仲間を作っていきましょう。
62. 1人でやらない 1人で推進をしようとすると、1人で課題提起をしてアクションを作り、アクションを実施する というようなことがしばしば発生する 運用しているエンジニアが主に1人の場合 こんな課題があります 話し合いの結果できた NextAction （CTOやPdMは忙しいし、そんなにやってもらうのもな） Action担当しますね！
63. 1人でやらない CTOやEM, PdMはエンジニアと職責が異なる。うまくいかない時のアクションは 自分がやるのが役割として正しかった 運用しているエンジニアが主に1人の場合 最近SLOのここがうまくいかないんですよね。 こうやるとうまくいきそうなんですが いいですね。やってみましょう！ うまくいっていないと思っている時は気持ち的にも実行が大変なことがあった。 アクションがうまくできなかったので継続のため運用のクオリティを落とした。 CTOやEM
64. 結果として過去の資産を活かして運用をした この時の推進力は今考えると弱かったと思う
65. そもそもこうならない方が良い どうするか？
66. 2人以上でやる 同じ立場の人が2人いると、同じ目線でものを見ることができる。 組織の30%にも近づくし、仲間を増やす仲間ができる。 運用しているエンジニアが主に2人の場合 最近SLOのここがうまくいかないんですよね。 それよいですね。僕はこっちをなんとかします。 わかります。ここをこう変えようと思っていたんですよ。 単純に手数が多いし、自分以外の手によって物事が推進されるとすごく嬉しい 改善が回って成果が出て気持ちが乗ると続けられる エンジニア
67. とはいえ...
68. 1人でも続けた方が良い 時間が解決することもある - 時に取り組みをきちんと理解するために時間を要することがある - 言い続けることによってSLOという概念の存在に対する認知度が向上した タイミーではAndroidエンジニアの話し合いの場でクラッシュフリーレートなどが定点観測 されるようになった🎉
69. 教訓: とにかく続ける
70. 7 まとめ
71. 教訓 1. 一緒に働く同僚の納得を大事にする 2. 変化しやすいものに依存させない 3. 重要すぎる指標をSLIにしない 4. とにかく続ける
72. かっこいいこと言っていますが サービスの成長がとても早く、検索のSLOが真っ赤になっています。 現在細かい対策アクションを実行中ですが、 近い未来で根本的な対策が必要です。助けてください。
73. We Are Hiring! カジュアル面談はこちらから
74. Thank you