SLOを活用した技術的改善

株式会社タイミーではスキマバイトプラットフォームを開発・運用しています。サービスもリリースして3年を超え、"負債"と呼ばれるものが増えてきました。一方でビジネス的に開発したいものは後を絶ちません。そこで開発チームでSLOを制定し、サービスの健全な状態を測定・監視することで「システムが健全にサービス提供できているか」を調べ、必要なときに必要な改修を行えるようにしました。本セッションでは弊社のSLOの解釈や利用方法を伝えるとともに、実際に感じたメリットや行われた技術的改善を紹介します。

セッション動画
https://www.youtube.com/watch?v=VburNEFcg64

Transcript

1. 株式会社タイミー　岡野兼也 SLOを活用した技術的改善 @Juju_62q
2. まずは伝えたいこと
3. 継続的な技術的改善、 どうやったらいいの？
4. すぐに気づいてすぐに実行
5. いや...そんなこといわれても...
6. 今日は技術的改善を 「すぐに気づいてすぐに実行」 する方法を紹介します
7. 目次 • 技術的改善の流れ • 技術的改善の問題点 • 指標を使おう • 事例紹介 • 一歩先の未来とまとめ
8. 岡野兼也 / @Juju_62q 株式会社タイミー プロダクト本部 ワーカーチーム Backend Engineer
11. 目次 • 技術的改善の流れ • 技術的改善の問題点 • 指標を使おう • 事例紹介 • 一歩先の未来とまとめ
12. よくある？技術的改善
13. 技術的改善のながれ パフォーマンスちょっとやばい...? よく気づくエンジニア
14. 技術的改善のながれ なんかパフォーマンス遅そうで、直し たほうが良さそうです おっ、ちょっと考えたいから 起きる問題と時期、予想工数ほしいです よく気づくエンジニア PM
16. 技術的改善のながれ これならhoge機能開発よりも 先にやったほうが良さそうですね。 資料作りました！よろしくおねがいします！
17. 技術的改善のながれ
18. 技術的改善のながれ 1. 誰かが唐突に気づく 2. PMが判断可能な材料を作る 3. 優先度判断 4. 技術的改善の実行 5. 効果測定
19. 目次 • 技術的改善の流れ • 技術的改善の問題点 • 指標を使おう • 事例紹介 • 一歩先の未来とまとめ
20. 歯車が狂うと...? パフォーマンスちょっとやばい...?
21. 歯車が狂うと...? でも伝えるとなんかやりたくない仕事めっ ちゃ増えちゃうしな〜
22. 歯車が狂うと...? 今週はhoge機能とfuga機能を作ろう 来週はfoo機能とbar機能を作ろう
23. 歯車が狂うと...? なんかアプリ全然開かないんだけど...?
24. 歯車が狂うと...? やばいやばい！早くなんとかしないと！！ 開発全部止めてなんとかするぞ！！
25. 歯車が狂うと...? 問題が絡まってて解決できない
26. どうしてこうなった？
27. よくある技術的改善のつらいところ - 問題に気づくと作業が増える - やりたいことに対してやらなきゃいけないことが多い - 技術的改善が気づく人に属人化している - 問題が起きてから解消が遅い - 時間がたつと往々にして問題は大きくなる - 大きな問題は解決が難しい
28. 炎上と鎮火を繰り返す
29. 遅く気づいて遅く実行
30. 技術的改善のながれ（再掲） 1. 誰かが唐突に気づく 2. PMが判断可能な材料を作る 3. 優先度判断 4. 技術的改善の実行 5. 効果測定
31. エンジニアの立場で見てみる
32. エンジニアのやりたいこと 1. 誰かが唐突に気づく 2. PMが判断可能な材料を作る 3. 優先度判断 4. 技術的改善の実行 5. 効果測定
33. エンジニアの立場 - システムに近いので気づきやすい - 実行権限はない - 技術的改善をしたい - プログラミング（エンジニアリング）をしたい - 技術的改善をやるために頑張りたく ない - 局所最適に陥りやすい
34. PMの立場で見てみる
35. PMのやりたいこと 1. 誰かが唐突に気づく 2. PMが判断可能な材料を作る 3. 優先度判断 4. 技術的改善の実行 5. 効果測定
36. PMの立場 - はじめの気付きは遅い - 意見通したい人に説明責任を担って ほしい - 実行権限がある - 全体最適を考えるのが仕事
37. 二人に問題はあった？
38. 問題...? - エンジニアの仕事は資料作りではない ので面倒臭がるのも自然 - PMがエンジニアリング起因の問題に 気づかないのも不自然でない - 問題を評価してから実行するのは当然
39. あれ？
40. 人は最善の行動をしてる...？
41. 改めて問題を探す
42. 誰もやりたくない 1. 誰かが唐突に気づく 2. PMが判断可能な材料を作る 3. 優先度判断 4. 技術的改善の実行 5. 効果測定
43. 仕組みの問題 - 気づく人に負荷が偏ってしまう - やりたくないけどやらないといけない仕事がある - やりたくない仕事は頑張れない - やれる人・気づく人がやって疲弊する - 判断ポイントが介在している - 作業者から見た不確実性 - 実行が遅れる可能性
44. 解決策1: よく気づく社員しか採用しない - メリット - 気づいて実行する人が分散される - デメリット - 採用が大変そう - 気づく人ってなんやねん
45. 解決策1: よく気づく社員しか採用しない - メリット - 気づいて実行する人が分散される - デメリット - 採用が大変そう - そもそもよくわからない
46. 解決策2: 現場の意見はすべて即実行する - メリット - よく気づく社員が疲弊しない - 問題が深化する前に解決できる - デメリット - 適切な優先度判断がなされない - 全エンジニアがPM的な視点を持たなければならない - 妥当な説明が社内に残りにくい
47. 解決策2: 現場の意見はすべて即実行する - メリット - よく気づく社員が疲弊しない - 問題が深化する前に解決できる - デメリット - 適切な優先度判断がなされない - 全エンジニアがPdM/PjM的な視点を持たなければなら ない - 妥当な説明が社内に残りにくい
48. じゃあどうするか...?
49. 目次 • 技術的改善の流れ • 技術的改善の問題点 • 指標を使おう • 事例紹介 • 一歩先の未来とまとめ
50. 技術的改善のながれ（改良版） 1. SLOをチームで見る 2. エラーバジェットの減少を認知 3. 技術的改善の実行 4. SLOの改善をチェック
51. SLO/Error Budget SLO (Service Level Objective) サービスを運用する上で守るべき基準値 ex. /hoge APIは99.95%で正常なレスポンスを返却する Error Budget 事実とSLOの間にある余裕 ex. SLOが99.95%に対して事実99.97%であれば40%（0.02%分）の エラーバジェットがある
52. どうしてSLOを使うか?
53. 技術的改善のながれ（再掲） 1. 誰かが唐突に気づく 2. PMが判断可能な材料を作る 3. 優先度判断 4. 技術的改善の実行 5. 効果測定
54. 技術的改善のながれ（再掲） 1. 誰かが唐突に気づく 2. PMが判断可能な材料を作る 3. 優先度判断 4. 技術的改善の実行 5. 効果測定 属人的 面倒くさい
55. Why SLO…? 属人性排除 SLOはシステム/チームに所属するので個人の所作に非依存 面倒臭さの解消 SLOを作成した段階で観測可能で合意形成が完了している エンジニアは原因究明や改善に注力することができる
56. 技術的改善のながれ（改良版・再掲） 1. SLOをチームで見る 2. エラーバジェットの減少を認知 3. 技術的改善の実行 4. SLOの改善をチェック
57. すぐに気づいてすぐに実行
58. 従来との違い（属人性） よく気づくエンジニアが、たまたま観測できた 結果として技術的改善につながっていた 問題の発生にチームで速やかに気づくことができる もっと言えば、問題の予兆に対応ができるようになる
59. 従来との違い（面倒くささ） PMが問題を適切に評価するために資料を作る必要があった また、これはあまりやりたい仕事ではなかった SLOを眺めて閾値を超えているかをチェックすれば良くなった 運用フェーズで疲弊せず、最速で実行に移すことができる
60. なぜそうなっているのか SLOを策定する場合以下について事前に考える - 対象に問題が起きたときのビジネスインパクト - 問題が顕在化するしきい値 コストを事前に支払うことで、運用の再現性を高め、 技術的改善の実行を容易にできる
61. 目次 • 技術的改善の流れ • 技術的改善の問題点 • 指標を使おう • 事例紹介 • 一歩先の未来とまとめ
62. ここからタイミーの話
63. 岡野兼也 / @Juju_62q 株式会社タイミー プロダクト本部 ワーカーチーム Backend Engineer 今日の話はtoC側の話です
64. SLO導入前の技術的改善 - 良くも悪くも熱意ベース - やりたい人がやるべきという材料を揃えられるかが実行に対す る強い変数となる - ファーストビューの高速化とかは実施されなかった - やったほうが良さそう - やると確実に良いと説明しにくい - 限界がどこにあるのか誰も知らない - 何なら問題に気づかない
65. SLOを作ってどう変わったか
66. タイミーで運用中のSLO CS, PdMなどにヒアリングを重ね、重要な機能がなにかを 調査し以下のSLOを作成した（一部抜粋） 1. API全体のx%が正常なレスポンスを返却する 2. ファーストビューがy%以上の期間でz秒以内に開く
67. 技術的改善のながれ（改良版・再掲） 1. SLOをチームで見る 2. エラーバジェットの減少を認知 3. 技術的改善の実行 4. SLOの改善をチェック
68. SLOをチームで見る - 毎日SlackでSLOを画像として投稿 - 開発スプリントごとにSLOの傾向をチェック
69. エラーバジェットの減少を認知 開発スプリント末に傾向をチェックする - 問題が発生しそうな時期の推定 - いつ作業を入れるかを話す
70. エラーバジェットの減少を認知 違反した場合Slack内やデイリーMTGで話す
71. 技術的改善の実行（SLO違反） デイリーMTGで以下を周知する - 違反している事実 - チームの対応 - 基本的に他の作業に作業に割り込む※ ただし、現状はエラーバジェットの減少を検知できているのであまり 発生していない ※事実として発生し、計測期間内の改善困難となった場合再発防止策をたてる
72. 技術的改善の実行（例） 過去にTV露出でアクセスがスパイクし、コンテナが 落ちてしまい、DBも処理できない状態となった 結果としてALB -> ECSのアクセスが通らなくなり5xxエラーが大 量に発生し、エラーレートのSLO違反となった これを受けてRDSのRead Replicaを増やし、重要なAPIに関してECS Serviceを分けることでインフラの独立性を高めた
73. 技術的改善の実行（例） サービス成長や繁忙期により、x月あたりに現状のロジックでは ファーストビューのSLOを満たせないことがわかった ファーストビューにページングを入れることで処理対象を 制限することにした
74. SLOの改善をチェック 実行した改善がSLOにきちんと響いているかを翌日等にチェック
75. すぐに気づいてすぐに実行
76. できるようになった　
77. 5 一歩先の未来とまとめ
78. できるようになったこととできてないこと - できるようになったこと - システムの振る舞いが伴う技術的な改善 - 長期的なシステム品質低下の抑止 - できていないこと - システムの振る舞いが伴わない技術的な改善 - リファクタリング - インフラの刷新
79. 今後やっていきたいこと エンジニアの生産性の測定 エンジニアの生産性を測定することで、コードの可読性などシステ ムの振る舞い以外の負債の大きさを明らかにする 挑戦に対する環境圧の形成 エンジニアが挑戦しやすい、したほうがうまくいきやすい 環境を作り負債になる前の改善をサポートする
80. まだわからないこと - 測定や効果測定は大切であることに対して測定/観測可能に する行為ROIをどう示すのが良いか - 現状は定性的に判断している - 本当にコスパが良かったのかは不明 - 根拠のない満足感が高い - SLO違反時の行動 - 原因が常に異なるため都度都度判断している - 現状エラーバジェット消費の逆の行動をしている
81. まとめ - 技術的改善の問題はエンジニアリングじゃないところにありが ち - 合意形成 - 放置するとよく気づく人が疲弊する - 技術的改善にはSLOを使うと便利 - 意思決定コストを前払いしているので、エンジニアにとって は気が楽 - 責任をチームに持たせるので属人性も撤廃
82. もしこの発表を見てタイミーに興味を持った方がいればこちらご覧ください！
83. Thank you