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

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

Transcript

1. 2023/7/25　岡野兼也
   ボトムアップでSLOを導入
   2年半運用して分かった失敗と変化
   @Juju_62q
   

   View Slide

2. 岡野兼也 / @Juju_62q
   株式会社タイミー
   プロダクト本部
   ワーキングリレーションチーム
   （Stream Aligned Team）
   Backend Engineer
   

   View Slide

3. 本日の目標
   

   View Slide

4. この問題、
   タイミーの発表で聞いたやつだ！
   

   View Slide

5. ここで聞いたことを糧にして問題を防いで欲しいとは言いません。
   時にわざと問題に直面させて解決することで、
   組織の練度を高めるという手法は有効です。
   一方で問題にぶつかるのは辛いこともあるでしょう。
   転んだ時にきちんと受け身を取る準備をしましょう。
   

   View Slide

6. 目次
   ● タイミーについて
   ● タイミーのSLOについて
   ● 教訓: 特に同僚に影響を与える意識を持つ
   ● 教訓: 変化しやすいものに依存させない
   ● 教訓: 重要すぎる指標をSLIにしない
   ● 教訓: とにかく続ける
   ● まとめ
   

   View Slide

7. 1 タイミーについて
   

   View Slide

8. タイミーとは
   8
   ｢働きたい時間｣と｢働いてほしい時間｣を
   マッチングするスキマバイトサービス
   従来の「求人サイト」でも「派遣」でもない
   

   View Slide

9. タイミーの使われ方
   働き手と雇い手がいるBtoCプラットフォームを提供しています。外からは見えづらいですが、スポットワークを実現するための雇い手
   の手続きや課題は多く、そのプロセスのほとんどをシステム化しています。
   9
   

   View Slide

10. 募集人数の推移
    10
    ※1：2022年4Qと2021年4Qの比較
    コロナ禍においても、
    過去に例を見ない程の
    加速的高成長を実現。
    

    View Slide

11. 2 タイミーのSLOについて
    

    View Slide

12. タイミーの開発組織とSLOの歴史 from ちいとぽStudy
    Phase3
    マッチングチームを影響範囲としてSLOを運用
    開発にFBをかけるためスクラムイベントを使い始め
    る
    Phase2
    Workerチームを影響範囲としてSLOの
    運用を開始
    運用に関しては様々な実験を実施
    スクラムチームとは少し距離があった
    Phase1
    負荷対策やアラートが本格導入
    SLOの下準備を行う
    解散直前に導入準備が整う
    

    View Slide

13. 今のSLO
    Phase4（現在）
    マッチング領域でSLOの運用責任を持つ（持たせたい）
    スポットワークシステム領域の1つのチームがSLOの運用を開始（今日の話は対象外）
    

    View Slide

14. タイミーの開発組織とSLOの歴史
    Phase3
    マッチングチームを影響範囲としてSLOを運用
    開発にFBをかけるためスクラムイベントを使い始め
    る
    Phase2
    Workerチームを影響範囲としてSLOの
    運用を開始
    運用に関しては様々な実験を実施
    スクラムチームとは少し距離があった
    Phase1
    負荷対策やアラートが本格導入
    SLOの下準備を行う
    解散直前に導入準備が整う
    

    View Slide

15. なぜ導入したか
    元々5xxエラーは全て対応可能という前提が体制が敷
    かれていた。1度のエラーでオンコール対応をすること
    もあった。
    しかし、急成長する中で運用が困難になっていった。機
    能開発と5xx修正とのバランスが取れず、 5xxエラーの
    修正が後回しにされることがあった。
    コロナ禍においても、
    過去に例を見ない程の
    加速的高成長を実現。
    

    View Slide

16. なぜ導入したか
    100%を目指すことによって、少ないエラーが割れ窓
    となっていた。結果として 99.99%を目指すよりも信頼
    性が下がってしまっていると感じた。
    そこで適切な高さの目標（ = SLO）を導入することにし
    た。
    コロナ禍においても、
    過去に例を見ない程の
    加速的高成長を実現。
    

    View Slide

17. その後いろんなことを経て...
    （進行上必要な部分に必要な時に触れます）
    

    View Slide

18. 2023年6月のSLO
    1. ALBのエラーレート
    2. 検索API（ファーストビュー）のレスポンスタイムのp95
    3. iOSアプリのクラッシュフリーレート
    4. Androidアプリのクラッシュフリーレート
    

    View Slide

19. SLO導入の効果（なるべく昔の同じ指標との比較）
    99.97% -> 99.99%
    基準が3[s] -> 700[ms]
    Android: 99.8% -> 99.9%
    

    View Slide

20. もちろん様々なエンジニアの不断の努力の賜物ですが、
    サービスを成長させながら信頼性を向上させることに成功🎉
    

    View Slide

21. 100%を目指さないことによる信頼性の上昇を実現🎉
    

    View Slide

22. と、成果の話はこれくらいにします。
    ここからは失敗の話をしていきます。
    

    View Slide

23. 3 特に同僚に影響を与える
    意識を持つ
    

    View Slide

24. タイミーの開発組織とSLOの歴史
    Phase3
    マッチングチームを影響範囲としてSLOを運用
    開発にFBをかけるためスクラムイベントを使い始め
    る
    Phase2
    Workerチームを影響範囲としてSLOの
    運用を開始
    運用に関しては様々な実験を実施
    スクラムチームとは少し距離があった
    Phase1
    負荷対策やアラートが本格導入
    SLOの下準備を行う
    解散直前に導入準備が整う
    

    View Slide

25. SLO作成時にやったこと
    CTO
    PdM
    Customer Support
    営業
    こんなことやりたいんですけど
    過去エラーで困ったりしましたか？
    重要にしたい機能はありますか？ etc.
    あんまり問題ないですよ〜
    ぜひやってみましょう！ by CTO
    CTO, PdMとお金を産む最小限どの機能を話したりしながら合意をとった。
    また、エンジニアリング部署以外にもやろうとしていることを説明し、理解を得た。
    ※当時は全社で100-200人くらいの規模であり、今よりかなり小さい
    

    View Slide

26. SLO作成時にやったこと
    エンジニア
    SLOというものの運用を始めようと思います
    こんな感じのものです
    こんな感じにやっていく予定です
    なるほど（理解した）。
    やりたいことを説明し、理解を得た。
    

    View Slide

27. 結果としてはスムーズな行動変容は起きなかった
    

    View Slide

28. なぜか？
    

    View Slide

29. マネージャーの承認を得ているだけで、
    実際に行動をする人の文化を変えるに至らなかったから
    

    View Slide

30. 文化文化って言ってるけど技術の話じゃないの？
    

    View Slide

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/
    

    View Slide

32. 上長との1on1にて
    チームの文化や考え方に影響を与えるにはどうすればい
    いでしょうか？
    文化を変えるには集団の中で 3割の人の行動を変えるの
    が有効です。
    

    View Slide

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.
    

    View Slide

34. 組織文化とSLO
    SLOはツールである
    - 基準を明確にすることで行動につながりやすくなる
    - 目に見えるようにすることで開発の中で信頼性を大事にしやすい
    最終的には信頼性をうまく扱う文化を作りたい
    - 「信頼性と機能開発のバランスを取ろうね！」と伝えて信頼性を意識する
    文化ができるのであればSLOはなくても良い
    - ただし、難しい。そのためSLOというツールを利用して3割の行動を変え、
    組織文化に影響を与える
    

    View Slide

35. やるべきだったこと
    前準備
    - やりたいことに対して興味を持ってくれそうな少数を探す
    - 興味を持ってくれそうな人に相談してみる
    実行
    - 上長や他部署の方より前に、同僚の行動を1人ずつ変えていく
    - 行動を変える上での足枷を排除する
    

    View Slide

36. なぜ事前に人を探すのか
    人の関心は物事の蹴り始めが最も強いのでその段階で30%の行動を変えられているとすご
    くやりやすい。
    信頼性にへの関心の強さは様々なので少しでも興味が強い人に仲間になってもらう。
    

    View Slide

37. なぜ相談をするのか
    指示よりも、相談の方が強いオーナーシップを持ってくれる気がする（要出典）。
    自分で考えたものには愛着が湧くのでその状況をなるべく作る（要出典）。
    

    View Slide

38. 教訓: 特に同僚に影響を与える意識を持つ
    

    View Slide

39. 4 変化しやすいものに依存さ
    せない
    

    View Slide

40. タイミーの開発組織の歴史とSLO
    Phase3
    節理面を探して
    マッチングチームは1チームでLeSSだった
    マッチングチームを影響範囲としてSLOを運用
    開発にFBをかけるためスクラムイベントを使い始める
    Phase4（現在）
    マッチング領域内に複数のチームがある
    マッチング領域を対象としてSLOの運用責任を持つ（持たせたい）
    スポットワークシステム領域の1つのチームがSLOの運用を開始（今日の話は対象外）
    

    View Slide

41. Q. タイミーにおいてチームの運用は安定しているか？
    

    View Slide

42. Q. タイミーにおいてチームの運用は安定しているか？
    A. No
    

    View Slide

43. なぜか
    

    View Slide

44. タイミーは複雑
    働き手と雇い手がいるBtoCプラットフォームを提供しています。外からは見えづらいですが、スポットワークを実現するための雇い手
    の手続きや課題は多く、そのプロセスのほとんどをシステム化しています。
    

    View Slide

45. タイミーは複雑 from 開発生産性Conference
    バリューチェーン
    ユーザー
    ペルソナ
    ユーザーペルソナやバリューチェーンでソリューションが綺麗に分かれないため、自然な節理面が見いだせていない
    

    View Slide

46. タイミーは複雑 from 開発生産性Conference
    マッチングプラットフォームゆえの両サイドのユーザーペルソナ
    ソリューションの多くがワーカー/事業者(法人・店舗など)の双方に影響を及ぼすものが多い。(求人出稿など)
    従ってユーザーペルソナを節理面にしづらい
    バリューチェーン上の川上にあるプロセスが川下のプロセスに密接に関わる
    勤怠管理が給与計算のベースとなるなど、プロセス間の依存関係が強く存在するため、バリューチェーン上のプ
    ロセスというビジネスドメインで摂理面を設定する事が難しい
    結果としてモノリスとしている
    節理面をうまく探索出来ていないため、結果として意図的に Ruby on Rails のモノリスのままにしている
    ユーザージャーニーをストリームとして扱っていることの難しさ
    

    View Slide

47. チームのミッションは
    解像度が上がったタイミングで整理される
    （!= メンバーが不安定、不安定なチーム）
    

    View Slide

48. ミッションが変わると最適な手段が変わる
    スクラムイベント等も型を残しつつ整理を行う
    

    View Slide

49. タイミーの開発組織の歴史とSLO
    Phase3
    節理面を探して
    マッチングチームは1チームでLeSSだった
    マッチングチームを影響範囲としてSLOを運用
    開発にFBをかけるためスクラムイベントを使い始める
    Phase4（現在）
    マッチング領域内に複数のチームがある
    マッチング領域を対象としてSLOの運用責任を持つ（持たせたい）
    スポットワークシステム領域の1つのチームがSLOの運用を開始（今日の話は対象外）
    

    View Slide

50. チームに合わせてSLOの運用が整理され、
    運用を考え直すことになった
    

    View Slide

51. タイミーの開発組織の歴史とSLO
    「マッチング領域」に関しては存在がある程度安定したように見えたので、1つのチームではなく「マッチング領域」に運用を持たせることを考えた。
    一方でプロダクトマネジメントの単位はチームである。結果としてエンジニアがチームに対して干渉しにいく必要がありそこまでうまく回せている自覚がない。
    この運用に関しては模索中です。良い方法があれば教えてください。
    

    View Slide

52. 教訓: 変化しやすいものに依存させない
    

    View Slide

53. 5 重要すぎる指標をSLIにし
    ない
    

    View Slide

54. 昔あったSLO
    重要だと捉えていたAPIのWriteアクセス成功率をSLIとしていた。
    ※「QRコード」はデンソーウェーブの登録商標です
    

    View Slide

55. 起きたこと
    マッチングや給与振込、出退勤に関して少数のエラー発生が許容できなかった。
    結果としてSLOに関わらずオンコール対応や改善を行う必要があり、
    実質的にSLOが機能しない状態となった。
    やばい。なんとかしないと。
    

    View Slide

56. 問題かどうか
    プロダクトの信頼性の高さという観点では問題はない
    一方で信頼性と機能開発のバランスを取るというSLOの目論見は失敗している
    不要と判断して削除しました
    

    View Slide

57. なぜ起きたか
    重要すぎるAPIに対して割合でエラーを許容するSLOを作ってしまった
    - マッチング
    - 給与振込
    - 出退勤等
    特に給与振込や出退勤に関してはカスタマーサポートの問い合わせが増えやすい
    この場合30daysのSLOというより短期間のエラー数に基づいて活動した方が良い。
    結果としてアラートを作って対応している。
    

    View Slide

58. SLOの目的を適応させる
    ※クリティカルユーザージャーニーを考える
    SREのプラクティスからは外れているかもしれません
    現時点でマッチング領域では重要なAPIを対象としたSLOは運用していない。
    また、この反省を踏まえて以下をSLOの目的の一つとした。
    「非機能要件の緩やかな低下を防ぐ」
    重要なAPIはアラートを設定して信頼性を担保することを目指す。
    もし、SLOを作るのであればAPI1つずつにSLOを設定していきます。
    

    View Slide

59. 教訓: 重要すぎる指標をSLIにしない
    

    View Slide

60. 6 とにかく続ける
    

    View Slide

61. 取り組みを行う上で、推進者の心が折れたら終わりです。
    続けられるように気持ちや仲間を作っていきましょう。
    

    View Slide

62. 1人でやらない
    1人で推進をしようとすると、1人で課題提起をしてアクションを作り、アクションを実施する
    というようなことがしばしば発生する
    運用しているエンジニアが主に1人の場合
    こんな課題があります
    話し合いの結果できた NextAction
    （CTOやPdMは忙しいし、そんなにやってもらうのもな）
    Action担当しますね！
    

    View Slide

63. 1人でやらない
    CTOやEM, PdMはエンジニアと職責が異なる。うまくいかない時のアクションは
    自分がやるのが役割として正しかった
    運用しているエンジニアが主に1人の場合
    最近SLOのここがうまくいかないんですよね。
    こうやるとうまくいきそうなんですが
    いいですね。やってみましょう！
    うまくいっていないと思っている時は気持ち的にも実行が大変なことがあった。
    アクションがうまくできなかったので継続のため運用のクオリティを落とした。
    CTOやEM
    

    View Slide

64. 結果として過去の資産を活かして運用をした
    この時の推進力は今考えると弱かったと思う
    

    View Slide

65. そもそもこうならない方が良い
    どうするか？
    

    View Slide

66. 2人以上でやる
    同じ立場の人が2人いると、同じ目線でものを見ることができる。
    組織の30%にも近づくし、仲間を増やす仲間ができる。
    運用しているエンジニアが主に2人の場合
    最近SLOのここがうまくいかないんですよね。
    それよいですね。僕はこっちをなんとかします。
    わかります。ここをこう変えようと思っていたんですよ。
    単純に手数が多いし、自分以外の手によって物事が推進されるとすごく嬉しい
    改善が回って成果が出て気持ちが乗ると続けられる
    エンジニア
    

    View Slide

67. とはいえ...
    

    View Slide

68. 1人でも続けた方が良い
    時間が解決することもある
    - 時に取り組みをきちんと理解するために時間を要することがある
    - 言い続けることによってSLOという概念の存在に対する認知度が向上した
    タイミーではAndroidエンジニアの話し合いの場でクラッシュフリーレートなどが定点観測
    されるようになった🎉
    

    View Slide

69. 教訓: とにかく続ける
    

    View Slide

70. 7 まとめ
    

    View Slide

71. 教訓
    1. 一緒に働く同僚の納得を大事にする
    2. 変化しやすいものに依存させない
    3. 重要すぎる指標をSLIにしない
    4. とにかく続ける
    

    View Slide

72. かっこいいこと言っていますが
    サービスの成長がとても早く、検索のSLOが真っ赤になっています。
    現在細かい対策アクションを実行中ですが、
    近い未来で根本的な対策が必要です。助けてください。
    

    View Slide

73. We Are Hiring!
    カジュアル面談はこちらから
    

    View Slide

74. Thank you

    

    View Slide