はじめに
マーケティングテクノロジー部の宮田(@miyata_17_)です。部内の開発保守改善、採用、テックリード活動、マネジメント等に取り組んでいます。
今年の目標はK-1のアマチュアの試合でBクラスへ昇格することです。
マーケティングテクノロジー部はDMMにおけるマーケティング施策に関わるシステム面を担当しており、「管轄プロダクトを通してプラットフォームの事業成長を支える」ことをミッションに掲げている横断組織で、管轄プロダクトは
- 総合TOPの開発・保守運用
- アドサーバーの開発・保守運用
- DMMアフィリエイトの開発・保守運用
- メールマガジン配信基盤の開発・保守運用
- 共通ナビの開発・保守運用
- 広告効果測定CV発火制御APIの開発・保守 等々...
と多岐にわたります。
DMMサイト内で利用しているアドサーバーは以下のような構成で作っているので、是非こちらの記事もご覧ください。
3ヶ月で作る高負荷広告配信サーバーの4つの注意点｜inside.dmm.com
元々抱えていた課題
上記の通り多くの管轄プロダクトがある中で「各プロダクトが安定して稼働しているか」を測るためにSLI/SLOを使用していました。
しかし実情は、重要そうなメトリクスから捻出したなんとなくのSLIと、全プロダクト共通で同じ数値のSLOで運用しており、期待されている安定運用を本当に担保できる状態ではありませんでした。
また、最近は別部署から移管されたプロダクトも多く、開発において重要視する指数の勘所、タスクや障害対応の優先順位の評価軸、新機能の提案の方向性...等々、ステークホルダー間でプロダクトに対する感覚のずれがありました。
SLI/SLO文化を組織に浸透させるためにやったこと
この記事では、多くのプロダクトを開発運用していく中で、プロダクト憲章からSLI/SLOの運用を定着させた話を、4ステップに分けて簡単にご紹介いたします。
step1:プロジェクトの憲章を再定義する
そんな課題を解決するために、まずはインセプションデッキを作成しました。
インセプションデッキとは以下の10個の質問にメンバー全員で回答して作成する、プロジェクト憲章の作成手法です。
ステークホルダーの潜在的な想いを洗い出してプロダクトの方向性の認識を合わせ、プロダクト開発における不確実性を減らすことができます。
| 質問タイトル | 目的 | 回答の作り方 |
|---|---|---|
| 我々はなぜここにいるのか | プロジェクトのゴール、自分たちがそれをやる理由、を明確にする | ・何故会社がこのプロジェクトにお金を使うのか、その理由を全部書く ・5個以上出た場合は、最優先事項を決める |
| エレベーターピッチ | プロダクトの強みや解決する課題を明確化する | 下記フォーマットの穴埋めをする [〇〇(ニーズや課題)を〇〇]したい [対象顧客]向けの、 [プロダクト名]というプロダクトは、 [プロダクトのカテゴリー]です。 これは[重要な利点]ができ、 [代替手段]とは違って、 [差別化の決定的な特徴]が備わっています。 |
| パッケージデザイン | ユーザー目線に立って、このプロジェクトに期待していることを明確にする | 利用者から見たプロダクトの価値、使う理由を列挙する |
| やらないことリスト | プロジェクトの焦点を絞って無駄を省く | このプロジェクトでやらない事を全て列挙する |
| 「ご近所さん」を探せ | ステークホルダーへの考慮漏れによる無駄防止、隠れていた潜在的な情報伝達ルートの洗い出し | ・プロジェクト期間中にどこかのタイミングで関わることになる人、部署を全て列挙する ・列挙された人や部署に対して、チーム内の誰がいつ関わるかもメモをする |
| 技術的な解決策 | 採用する技術の選定、それぞれの利点とリスクの説明 | 今回はすでに運用中のシステムなので、現時点でのアーキテクチャと課題点をメンバー全員に伝わる形で共有、アーキテクチャ図等を載せた |
| 夜も眠れない問題 | 障害の影響範囲や、プロジェクト進行における潜在的な問題を洗い出す | チームや関係者が認識しているプロジェクトのリスクを全て洗い出す |
| 期間を明確にする | 必要なプロジェクト期間の算出 | 既存のマイルストーンを載せる。未決定の場合は大まかに定義をする |
| トレードオフスライダー | プロジェクトにおける優先度を明確にする。限られたリソースで注力すべき軸の共通認識を持つ | QCDSの優先順位 (QCDS: 質・予算・納期・スコープ)やプロダクト独自の軸で優先度をつける |
| 何がどれだけ必要か | ミッション達成に必要な期間・予算・チーム編成規模の共通認識。リソース不足、リソース過多の共有 | プロジェクトに必要な体制や人数、コスト感を並べる |
今回はすでに運用されている数多くのプロダクトに対してインセプションデッキを１つずつ作ることになりました。
そのため、ゼロから全てをブレストするのではなく、プロダクトオーナーがある程度内容を埋めてから挑み、各質問内容毎にタイムキープしつつメンバーから意見を抽出して進めました。
これにより、各プロダクト毎2時間程度の時間でスムーズに会を進めることができました。
我々の組織では、このインセプションデッキをステークホルダー全員で作成する事により、各プロダクトの方向性やゴールの認識を揃えることができました。
step2:SLI/SLOという概念と運用ポリシーの認識を合わせる
プロダクトのゴールの認識が揃い、チームの温度感が高まっているタイミングで、改めてステークホルダーとSLI/SLOの概念の説明とその運用ポリシーの認識を合わせます。
まず、積極的なリリースを目指す開発体制における、下記の前提事項を伝えます。
- バグや障害を完全にゼロにする事はかなり難しく効率が下がってしまう
- バグや障害件数、エラーや問い合わせ数だけでは実際の影響範囲が追いづらく、プロダクトがユーザーへ価値を提供できているかどうかの判断をしづらい
その上で、SLI/SLOとは何かを再確認します。
- SLI（サービスレベル指標）とは、数値で定量的にサービスの状況を表せる指数
- 例：サービスAのSLI＝サーバーからの成功レスポンス率/サーバーからの全体レスポンス数
- SLO（サービスレベル目標）とは、特定期間内でSLIをいくつ以上に保つかの目標数値
- 例：サービスAのSLIを30日間で99％切らないようにする
最後に、SLI/SLOの運用ポリシーを提案します。
- 計測している数値がSLOの閾値を下回った時、それはプロダクトのユーザーへの価値提供に問題が出ている時
- その状態を改善するために、バックログに入っている他のタスクを止めてでも修正や改善にリソースを割くべき
以上のことをステークホルダーと認識を合わせることによって、SLI/SLOの重要性と概念を伝えることができました。
参考： https://cloud.google.com/architecture/defining-SLOs
step3:プロダクトの提供すべき価値からSLI/SLOを定義する
いよいよ、実際にSLI/SLOを再定義していきます。
SLI/SLO定義は、計測の為の実装をしてみて定義に微調整が必要になってくることも多々あります。
継続的に定義を見直していく前提で、定義を固めました。
決め方は以下を参考にさせていただきました。
参考：Setting SLOs: a step-by-step guide
総合TOPを例にどう定義したかを紹介させていただきます。
-
クリティカルユーザージャーニー(CUJ)の抽出
送客ツールである総合TOPのCUJは「ユーザーさんがページに訪れ、ページを見て、リンクに飛べること」とした -
SLIの定義
SSRで描画しているサーバーなので「ALBの成功レスポンス率」とした（リンク切れチェックやデータ整合性は別途調整中） -
SLOの定義
30日間で99.99%を目標とした（月間のダウンタイム4.38分が目安）
「3. SLOの定義」では、指定したダウンタイムが起きることによって、売り上げ等の別指標への影響はどうなるかを同時に確認することによって、非エンジニアも含めたステークホルダーと共通の目線で会話をすることができました。
step4:DatadogでSLOの監視、アラートの対応体制を構築する
最後に、定義されたSLI/SLOを遵守するためにDatadogでのモニタリングとアラート設定を行ないます。
マーケティングテクノロジー部では基本的にAWS上のマネージドなサービスでシステムが動いており、各サービスと連携してDatadogにログとメトリクスを流し込んでいきます。
SLOの定義をDatadog上で設定することによって、このようにして確認をすることができます。
参考：サービスレベル目標
アラートに関しては、エラーバジェットの消費速度を表すバーンレートのアラートをslackに流すことで障害検知をして、対応しています。
DatadogによるSLOの監視運用をすることにより、障害やエラーが発生した際も、SLOに違反しているかという共有の指標で話せることで開発者の積極的なリリース体制、またアラートへの姿勢も変わりつつあります。
また、SLI/SLOの測定を正しくするにあたり、アプリケーションのエラーのハンドリングや構成のリファクタなどが伴うものもあり、結果として全体の整備に繋げることができました。
繰り返しになりますが、SLI/SLOは運用していく中でその定義を変えていく必要があるものなので、定期的な振り返りの文化も作る必要がある事を実感しました。
おわりに
インセプションデッキ作成からSLI/SLOを一緒に定義することによって、非エンジニア含めたステークホルダー全員と共通で追える指標ができました。
多くのプロダクトの保守の中で、機能開発も盛んに行っていくために、開発効率化に向けて、SRE活動も黙々と続けています。
Feature Toggleの導入でのリリース高速化、全プロダクトへのIaC導入とterraform標準化、といった様々な事をやっていますが、まだまだやることはたくさんあります。
そんなマーケティングテクノロジー部では、一緒に開発するメンバーを募集していますので、ご興味ある方は以下の募集ページからご応募ください。
