株式会社タイミーではスキマバイトプラットフォームを開発・運用しています。サービスもリリースして3年を超え、"負債"と呼ばれるものが増えてきました。一方でビジネス的に開発したいものは後を絶ちません。そこで開発チームでSLOを制定し、サービスの健全な状態を測定・監視することで「システムが健全にサービス提供できているか」を調べ、必要なときに必要な改修を行えるようにしました。本セッションでは弊社のSLOの解釈や利用方法を伝えるとともに、実際に感じたメリットや行われた技術的改善を紹介します。
セッション動画 https://www.youtube.com/watch?v=VburNEFcg64
株式会社タイミー 岡野兼也SLOを活用した技術的改善@Juju_62q
View Slide
まずは伝えたいこと
継続的な技術的改善、どうやったらいいの？
すぐに気づいてすぐに実行
いや...そんなこといわれても...
今日は技術的改善を「すぐに気づいてすぐに実行」する方法を紹介します
目次● 技術的改善の流れ● 技術的改善の問題点● 指標を使おう● 事例紹介● 一歩先の未来とまとめ
岡野兼也 / @Juju_62q株式会社タイミープロダクト本部 ワーカーチームBackend Engineer
よくある？技術的改善
技術的改善のながれパフォーマンスちょっとやばい...?よく気づくエンジニア
技術的改善のながれなんかパフォーマンス遅そうで、直したほうが良さそうですおっ、ちょっと考えたいから起きる問題と時期、予想工数ほしいですよく気づくエンジニアPM
技術的改善のながれこれならhoge機能開発よりも先にやったほうが良さそうですね。資料作りました！よろしくおねがいします！
技術的改善のながれ
技術的改善のながれ1. 誰かが唐突に気づく2. PMが判断可能な材料を作る3. 優先度判断4. 技術的改善の実行5. 効果測定
歯車が狂うと...?パフォーマンスちょっとやばい...?
歯車が狂うと...?でも伝えるとなんかやりたくない仕事めっちゃ増えちゃうしな〜
歯車が狂うと...?今週はhoge機能とfuga機能を作ろう来週はfoo機能とbar機能を作ろう
歯車が狂うと...?なんかアプリ全然開かないんだけど...?
歯車が狂うと...?やばいやばい！早くなんとかしないと！！開発全部止めてなんとかするぞ！！
歯車が狂うと...?問題が絡まってて解決できない
どうしてこうなった？
よくある技術的改善のつらいところ- 問題に気づくと作業が増える- やりたいことに対してやらなきゃいけないことが多い- 技術的改善が気づく人に属人化している- 問題が起きてから解消が遅い- 時間がたつと往々にして問題は大きくなる- 大きな問題は解決が難しい
炎上と鎮火を繰り返す
遅く気づいて遅く実行
技術的改善のながれ（再掲）1. 誰かが唐突に気づく2. PMが判断可能な材料を作る3. 優先度判断4. 技術的改善の実行5. 効果測定
エンジニアの立場で見てみる
エンジニアのやりたいこと1. 誰かが唐突に気づく2. PMが判断可能な材料を作る3. 優先度判断4. 技術的改善の実行5. 効果測定
エンジニアの立場- システムに近いので気づきやすい- 実行権限はない- 技術的改善をしたい- プログラミング（エンジニアリング）をしたい- 技術的改善をやるために頑張りたくない- 局所最適に陥りやすい
PMの立場で見てみる
PMのやりたいこと1. 誰かが唐突に気づく2. PMが判断可能な材料を作る3. 優先度判断4. 技術的改善の実行5. 効果測定
PMの立場- はじめの気付きは遅い- 意見通したい人に説明責任を担ってほしい- 実行権限がある- 全体最適を考えるのが仕事
二人に問題はあった？
問題...?- エンジニアの仕事は資料作りではないので面倒臭がるのも自然- PMがエンジニアリング起因の問題に気づかないのも不自然でない- 問題を評価してから実行するのは当然
あれ？
人は最善の行動をしてる...？
改めて問題を探す
誰もやりたくない1. 誰かが唐突に気づく2. PMが判断可能な材料を作る3. 優先度判断4. 技術的改善の実行5. 効果測定
仕組みの問題- 気づく人に負荷が偏ってしまう- やりたくないけどやらないといけない仕事がある- やりたくない仕事は頑張れない- やれる人・気づく人がやって疲弊する- 判断ポイントが介在している- 作業者から見た不確実性- 実行が遅れる可能性
解決策1: よく気づく社員しか採用しない- メリット- 気づいて実行する人が分散される- デメリット- 採用が大変そう- 気づく人ってなんやねん
解決策1: よく気づく社員しか採用しない- メリット- 気づいて実行する人が分散される- デメリット- 採用が大変そう- そもそもよくわからない
解決策2: 現場の意見はすべて即実行する- メリット- よく気づく社員が疲弊しない- 問題が深化する前に解決できる- デメリット- 適切な優先度判断がなされない- 全エンジニアがPM的な視点を持たなければならない- 妥当な説明が社内に残りにくい
解決策2: 現場の意見はすべて即実行する- メリット- よく気づく社員が疲弊しない- 問題が深化する前に解決できる- デメリット- 適切な優先度判断がなされない- 全エンジニアがPdM/PjM的な視点を持たなければならない- 妥当な説明が社内に残りにくい
じゃあどうするか...?
技術的改善のながれ（改良版）1. SLOをチームで見る2. エラーバジェットの減少を認知3. 技術的改善の実行4. SLOの改善をチェック
SLO/Error BudgetSLO (Service Level Objective)サービスを運用する上で守るべき基準値ex. /hoge APIは99.95%で正常なレスポンスを返却するError Budget事実とSLOの間にある余裕ex. SLOが99.95%に対して事実99.97%であれば40%（0.02%分）のエラーバジェットがある
どうしてSLOを使うか?
技術的改善のながれ（再掲）1. 誰かが唐突に気づく2. PMが判断可能な材料を作る3. 優先度判断4. 技術的改善の実行5. 効果測定属人的面倒くさい
Why SLO…?属人性排除SLOはシステム/チームに所属するので個人の所作に非依存面倒臭さの解消SLOを作成した段階で観測可能で合意形成が完了しているエンジニアは原因究明や改善に注力することができる
技術的改善のながれ（改良版・再掲）1. SLOをチームで見る2. エラーバジェットの減少を認知3. 技術的改善の実行4. SLOの改善をチェック
従来との違い（属人性）よく気づくエンジニアが、たまたま観測できた結果として技術的改善につながっていた問題の発生にチームで速やかに気づくことができるもっと言えば、問題の予兆に対応ができるようになる
従来との違い（面倒くささ）PMが問題を適切に評価するために資料を作る必要があったまた、これはあまりやりたい仕事ではなかったSLOを眺めて閾値を超えているかをチェックすれば良くなった運用フェーズで疲弊せず、最速で実行に移すことができる
なぜそうなっているのかSLOを策定する場合以下について事前に考える- 対象に問題が起きたときのビジネスインパクト- 問題が顕在化するしきい値コストを事前に支払うことで、運用の再現性を高め、技術的改善の実行を容易にできる
ここからタイミーの話
岡野兼也 / @Juju_62q株式会社タイミープロダクト本部 ワーカーチームBackend Engineer今日の話はtoC側の話です
SLO導入前の技術的改善- 良くも悪くも熱意ベース- やりたい人がやるべきという材料を揃えられるかが実行に対する強い変数となる- ファーストビューの高速化とかは実施されなかった- やったほうが良さそう- やると確実に良いと説明しにくい- 限界がどこにあるのか誰も知らない- 何なら問題に気づかない
SLOを作ってどう変わったか
タイミーで運用中のSLOCS, PdMなどにヒアリングを重ね、重要な機能がなにかを調査し以下のSLOを作成した（一部抜粋）1. API全体のx%が正常なレスポンスを返却する2. ファーストビューがy%以上の期間でz秒以内に開く
SLOをチームで見る- 毎日SlackでSLOを画像として投稿- 開発スプリントごとにSLOの傾向をチェック
エラーバジェットの減少を認知開発スプリント末に傾向をチェックする- 問題が発生しそうな時期の推定- いつ作業を入れるかを話す
エラーバジェットの減少を認知違反した場合Slack内やデイリーMTGで話す
技術的改善の実行（SLO違反）デイリーMTGで以下を周知する- 違反している事実- チームの対応- 基本的に他の作業に作業に割り込む※ただし、現状はエラーバジェットの減少を検知できているのであまり発生していない※事実として発生し、計測期間内の改善困難となった場合再発防止策をたてる
技術的改善の実行（例）過去にTV露出でアクセスがスパイクし、コンテナが落ちてしまい、DBも処理できない状態となった結果としてALB -> ECSのアクセスが通らなくなり5xxエラーが大量に発生し、エラーレートのSLO違反となったこれを受けてRDSのRead Replicaを増やし、重要なAPIに関してECSServiceを分けることでインフラの独立性を高めた
技術的改善の実行（例）サービス成長や繁忙期により、x月あたりに現状のロジックではファーストビューのSLOを満たせないことがわかったファーストビューにページングを入れることで処理対象を制限することにした
SLOの改善をチェック実行した改善がSLOにきちんと響いているかを翌日等にチェック
できるようになった
5 一歩先の未来とまとめ
できるようになったこととできてないこと- できるようになったこと- システムの振る舞いが伴う技術的な改善- 長期的なシステム品質低下の抑止- できていないこと- システムの振る舞いが伴わない技術的な改善- リファクタリング- インフラの刷新
今後やっていきたいことエンジニアの生産性の測定エンジニアの生産性を測定することで、コードの可読性などシステムの振る舞い以外の負債の大きさを明らかにする挑戦に対する環境圧の形成エンジニアが挑戦しやすい、したほうがうまくいきやすい環境を作り負債になる前の改善をサポートする
まだわからないこと- 測定や効果測定は大切であることに対して測定/観測可能にする行為ROIをどう示すのが良いか- 現状は定性的に判断している- 本当にコスパが良かったのかは不明- 根拠のない満足感が高い- SLO違反時の行動- 原因が常に異なるため都度都度判断している- 現状エラーバジェット消費の逆の行動をしている
まとめ- 技術的改善の問題はエンジニアリングじゃないところにありがち- 合意形成- 放置するとよく気づく人が疲弊する- 技術的改善にはSLOを使うと便利- 意思決定コストを前払いしているので、エンジニアにとっては気が楽- 責任をチームに持たせるので属人性も撤廃
もしこの発表を見てタイミーに興味を持った方がいればこちらご覧ください！
Thank you
juju62q
riru
mitsuakitohei
tomzoh
yellowshippo
kyonmm
_kensh
imsaku
tammyeverts
yurihondo
keio_smilab
senkin13
hiashisan
edds
sonatard
danielanewman
cherdarchuk
akosma
reverentgeek
bkeepers
vanstee
geeforr
smashingmag
addyosmani
lara