Slide 1

Slide 1 text

株式会社タイミー 岡野兼也 SLOを活用した技術的改善 @Juju_62q

Slide 2

Slide 2 text

まずは伝えたいこと

Slide 3

Slide 3 text

継続的な技術的改善、 どうやったらいいの?

Slide 4

Slide 4 text

すぐに気づいてすぐに実行

Slide 5

Slide 5 text

いや...そんなこといわれても...

Slide 6

Slide 6 text

今日は技術的改善を 「すぐに気づいてすぐに実行」 する方法を紹介します

Slide 7

Slide 7 text

目次 ● 技術的改善の流れ ● 技術的改善の問題点 ● 指標を使おう ● 事例紹介 ● 一歩先の未来とまとめ

Slide 8

Slide 8 text

岡野兼也 / @Juju_62q 株式会社タイミー プロダクト本部 ワーカーチーム Backend Engineer

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

目次 ● 技術的改善の流れ ● 技術的改善の問題点 ● 指標を使おう ● 事例紹介 ● 一歩先の未来とまとめ

Slide 12

Slide 12 text

よくある?技術的改善

Slide 13

Slide 13 text

技術的改善のながれ パフォーマンスちょっとやばい...? よく気づくエンジニア

Slide 14

Slide 14 text

技術的改善のながれ なんかパフォーマンス遅そうで、直し たほうが良さそうです おっ、ちょっと考えたいから 起きる問題と時期、予想工数ほしいです よく気づくエンジニア PM

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

技術的改善のながれ これならhoge機能開発よりも 先にやったほうが良さそうですね。 資料作りました!よろしくおねがいします!

Slide 17

Slide 17 text

技術的改善のながれ

Slide 18

Slide 18 text

技術的改善のながれ 1. 誰かが唐突に気づく 2. PMが判断可能な材料を作る 3. 優先度判断 4. 技術的改善の実行 5. 効果測定

Slide 19

Slide 19 text

目次 ● 技術的改善の流れ ● 技術的改善の問題点 ● 指標を使おう ● 事例紹介 ● 一歩先の未来とまとめ

Slide 20

Slide 20 text

歯車が狂うと...? パフォーマンスちょっとやばい...?

Slide 21

Slide 21 text

歯車が狂うと...? でも伝えるとなんかやりたくない仕事めっ ちゃ増えちゃうしな〜

Slide 22

Slide 22 text

歯車が狂うと...? 今週はhoge機能とfuga機能を作ろう 来週はfoo機能とbar機能を作ろう

Slide 23

Slide 23 text

歯車が狂うと...? なんかアプリ全然開かないんだけど...?

Slide 24

Slide 24 text

歯車が狂うと...? やばいやばい!早くなんとかしないと!! 開発全部止めてなんとかするぞ!!

Slide 25

Slide 25 text

歯車が狂うと...? 問題が絡まってて解決できない

Slide 26

Slide 26 text

どうしてこうなった?

Slide 27

Slide 27 text

よくある技術的改善のつらいところ - 問題に気づくと作業が増える - やりたいことに対してやらなきゃいけないことが多い - 技術的改善が気づく人に属人化している - 問題が起きてから解消が遅い - 時間がたつと往々にして問題は大きくなる - 大きな問題は解決が難しい

Slide 28

Slide 28 text

炎上と鎮火を繰り返す

Slide 29

Slide 29 text

遅く気づいて遅く実行

Slide 30

Slide 30 text

技術的改善のながれ(再掲) 1. 誰かが唐突に気づく 2. PMが判断可能な材料を作る 3. 優先度判断 4. 技術的改善の実行 5. 効果測定

Slide 31

Slide 31 text

エンジニアの立場で見てみる

Slide 32

Slide 32 text

エンジニアのやりたいこと 1. 誰かが唐突に気づく 2. PMが判断可能な材料を作る 3. 優先度判断 4. 技術的改善の実行 5. 効果測定

Slide 33

Slide 33 text

エンジニアの立場 - システムに近いので気づきやすい - 実行権限はない - 技術的改善をしたい - プログラミング(エンジニアリング)をしたい - 技術的改善をやるために頑張りたく ない - 局所最適に陥りやすい

Slide 34

Slide 34 text

PMの立場で見てみる

Slide 35

Slide 35 text

PMのやりたいこと 1. 誰かが唐突に気づく 2. PMが判断可能な材料を作る 3. 優先度判断 4. 技術的改善の実行 5. 効果測定

Slide 36

Slide 36 text

PMの立場 - はじめの気付きは遅い - 意見通したい人に説明責任を担って ほしい - 実行権限がある - 全体最適を考えるのが仕事

Slide 37

Slide 37 text

二人に問題はあった?

Slide 38

Slide 38 text

問題...? - エンジニアの仕事は資料作りではない ので面倒臭がるのも自然 - PMがエンジニアリング起因の問題に 気づかないのも不自然でない - 問題を評価してから実行するのは当然

Slide 39

Slide 39 text

あれ?

Slide 40

Slide 40 text

人は最善の行動をしてる...?

Slide 41

Slide 41 text

改めて問題を探す

Slide 42

Slide 42 text

誰もやりたくない 1. 誰かが唐突に気づく 2. PMが判断可能な材料を作る 3. 優先度判断 4. 技術的改善の実行 5. 効果測定

Slide 43

Slide 43 text

仕組みの問題 - 気づく人に負荷が偏ってしまう - やりたくないけどやらないといけない仕事がある - やりたくない仕事は頑張れない - やれる人・気づく人がやって疲弊する - 判断ポイントが介在している - 作業者から見た不確実性 - 実行が遅れる可能性

Slide 44

Slide 44 text

解決策1: よく気づく社員しか採用しない - メリット - 気づいて実行する人が分散される - デメリット - 採用が大変そう - 気づく人ってなんやねん

Slide 45

Slide 45 text

解決策1: よく気づく社員しか採用しない - メリット - 気づいて実行する人が分散される - デメリット - 採用が大変そう - そもそもよくわからない

Slide 46

Slide 46 text

解決策2: 現場の意見はすべて即実行する - メリット - よく気づく社員が疲弊しない - 問題が深化する前に解決できる - デメリット - 適切な優先度判断がなされない - 全エンジニアがPM的な視点を持たなければならない - 妥当な説明が社内に残りにくい

Slide 47

Slide 47 text

解決策2: 現場の意見はすべて即実行する - メリット - よく気づく社員が疲弊しない - 問題が深化する前に解決できる - デメリット - 適切な優先度判断がなされない - 全エンジニアがPdM/PjM的な視点を持たなければなら ない - 妥当な説明が社内に残りにくい

Slide 48

Slide 48 text

じゃあどうするか...?

Slide 49

Slide 49 text

目次 ● 技術的改善の流れ ● 技術的改善の問題点 ● 指標を使おう ● 事例紹介 ● 一歩先の未来とまとめ

Slide 50

Slide 50 text

技術的改善のながれ(改良版) 1. SLOをチームで見る 2. エラーバジェットの減少を認知 3. 技術的改善の実行 4. SLOの改善をチェック

Slide 51

Slide 51 text

SLO/Error Budget SLO (Service Level Objective) サービスを運用する上で守るべき基準値 ex. /hoge APIは99.95%で正常なレスポンスを返却する Error Budget 事実とSLOの間にある余裕 ex. SLOが99.95%に対して事実99.97%であれば40%(0.02%分)の エラーバジェットがある

Slide 52

Slide 52 text

どうしてSLOを使うか?

Slide 53

Slide 53 text

技術的改善のながれ(再掲) 1. 誰かが唐突に気づく 2. PMが判断可能な材料を作る 3. 優先度判断 4. 技術的改善の実行 5. 効果測定

Slide 54

Slide 54 text

技術的改善のながれ(再掲) 1. 誰かが唐突に気づく 2. PMが判断可能な材料を作る 3. 優先度判断 4. 技術的改善の実行 5. 効果測定 属人的 面倒くさい

Slide 55

Slide 55 text

Why SLO…? 属人性排除 SLOはシステム/チームに所属するので個人の所作に非依存 面倒臭さの解消 SLOを作成した段階で観測可能で合意形成が完了している エンジニアは原因究明や改善に注力することができる

Slide 56

Slide 56 text

技術的改善のながれ(改良版・再掲) 1. SLOをチームで見る 2. エラーバジェットの減少を認知 3. 技術的改善の実行 4. SLOの改善をチェック

Slide 57

Slide 57 text

すぐに気づいてすぐに実行

Slide 58

Slide 58 text

従来との違い(属人性) よく気づくエンジニアが、たまたま観測できた 結果として技術的改善につながっていた 問題の発生にチームで速やかに気づくことができる もっと言えば、問題の予兆に対応ができるようになる

Slide 59

Slide 59 text

従来との違い(面倒くささ) PMが問題を適切に評価するために資料を作る必要があった また、これはあまりやりたい仕事ではなかった SLOを眺めて閾値を超えているかをチェックすれば良くなった 運用フェーズで疲弊せず、最速で実行に移すことができる

Slide 60

Slide 60 text

なぜそうなっているのか SLOを策定する場合以下について事前に考える - 対象に問題が起きたときのビジネスインパクト - 問題が顕在化するしきい値 コストを事前に支払うことで、運用の再現性を高め、 技術的改善の実行を容易にできる

Slide 61

Slide 61 text

目次 ● 技術的改善の流れ ● 技術的改善の問題点 ● 指標を使おう ● 事例紹介 ● 一歩先の未来とまとめ

Slide 62

Slide 62 text

ここからタイミーの話

Slide 63

Slide 63 text

岡野兼也 / @Juju_62q 株式会社タイミー プロダクト本部 ワーカーチーム Backend Engineer 今日の話はtoC側の話です

Slide 64

Slide 64 text

SLO導入前の技術的改善 - 良くも悪くも熱意ベース - やりたい人がやるべきという材料を揃えられるかが実行に対す る強い変数となる - ファーストビューの高速化とかは実施されなかった - やったほうが良さそう - やると確実に良いと説明しにくい - 限界がどこにあるのか誰も知らない - 何なら問題に気づかない

Slide 65

Slide 65 text

SLOを作ってどう変わったか

Slide 66

Slide 66 text

タイミーで運用中のSLO CS, PdMなどにヒアリングを重ね、重要な機能がなにかを 調査し以下のSLOを作成した(一部抜粋) 1. API全体のx%が正常なレスポンスを返却する 2. ファーストビューがy%以上の期間でz秒以内に開く

Slide 67

Slide 67 text

技術的改善のながれ(改良版・再掲) 1. SLOをチームで見る 2. エラーバジェットの減少を認知 3. 技術的改善の実行 4. SLOの改善をチェック

Slide 68

Slide 68 text

SLOをチームで見る - 毎日SlackでSLOを画像として投稿 - 開発スプリントごとにSLOの傾向をチェック

Slide 69

Slide 69 text

エラーバジェットの減少を認知 開発スプリント末に傾向をチェックする - 問題が発生しそうな時期の推定 - いつ作業を入れるかを話す

Slide 70

Slide 70 text

エラーバジェットの減少を認知 違反した場合Slack内やデイリーMTGで話す

Slide 71

Slide 71 text

技術的改善の実行(SLO違反) デイリーMTGで以下を周知する - 違反している事実 - チームの対応 - 基本的に他の作業に作業に割り込む※ ただし、現状はエラーバジェットの減少を検知できているのであまり 発生していない ※事実として発生し、計測期間内の改善困難となった場合再発防止策をたてる

Slide 72

Slide 72 text

技術的改善の実行(例) 過去にTV露出でアクセスがスパイクし、コンテナが 落ちてしまい、DBも処理できない状態となった 結果としてALB -> ECSのアクセスが通らなくなり5xxエラーが大 量に発生し、エラーレートのSLO違反となった これを受けてRDSのRead Replicaを増やし、重要なAPIに関してECS Serviceを分けることでインフラの独立性を高めた

Slide 73

Slide 73 text

技術的改善の実行(例) サービス成長や繁忙期により、x月あたりに現状のロジックでは ファーストビューのSLOを満たせないことがわかった ファーストビューにページングを入れることで処理対象を 制限することにした

Slide 74

Slide 74 text

SLOの改善をチェック 実行した改善がSLOにきちんと響いているかを翌日等にチェック

Slide 75

Slide 75 text

すぐに気づいてすぐに実行

Slide 76

Slide 76 text

できるようになった 

Slide 77

Slide 77 text

5 一歩先の未来とまとめ

Slide 78

Slide 78 text

できるようになったこととできてないこと - できるようになったこと - システムの振る舞いが伴う技術的な改善 - 長期的なシステム品質低下の抑止 - できていないこと - システムの振る舞いが伴わない技術的な改善 - リファクタリング - インフラの刷新

Slide 79

Slide 79 text

今後やっていきたいこと エンジニアの生産性の測定 エンジニアの生産性を測定することで、コードの可読性などシステ ムの振る舞い以外の負債の大きさを明らかにする 挑戦に対する環境圧の形成 エンジニアが挑戦しやすい、したほうがうまくいきやすい 環境を作り負債になる前の改善をサポートする

Slide 80

Slide 80 text

まだわからないこと - 測定や効果測定は大切であることに対して測定/観測可能に する行為ROIをどう示すのが良いか - 現状は定性的に判断している - 本当にコスパが良かったのかは不明 - 根拠のない満足感が高い - SLO違反時の行動 - 原因が常に異なるため都度都度判断している - 現状エラーバジェット消費の逆の行動をしている

Slide 81

Slide 81 text

まとめ - 技術的改善の問題はエンジニアリングじゃないところにありが ち - 合意形成 - 放置するとよく気づく人が疲弊する - 技術的改善にはSLOを使うと便利 - 意思決定コストを前払いしているので、エンジニアにとって は気が楽 - 責任をチームに持たせるので属人性も撤廃

Slide 82

Slide 82 text

もしこの発表を見てタイミーに興味を持った方がいればこちらご覧ください!

Slide 83

Slide 83 text

Thank you