ZOZOMAT/ZOZOGLASSにおけるSLOの立て直しについて

rebuilding_slo

はじめに

こんにちは、計測プラットフォーム開発本部SREブロックの近藤です。普段はZOZOMATやZOZOGLASS、ZOZOFITなどの計測技術に関わるプロダクトの開発、運用に携わっています。計測プラットフォーム開発本部では、以前プロダクト単位でSLO(Service Level Objective)1を定めましたが、うまく活用できず、再度SLOについて運用方法を考え直すことになりました。本記事では、SLOの再導入から運用に向かう中で見つかった課題と、課題に対する対応策についてご紹介します。

目次

背景

前述したように、各プロダクト毎にSLOを導入しましたが、運用できているとは言えない状況でした。具体的には、SLOを活用した改善が進められておらず、また他チームやビジネスサイドに浸透できていませんでした。これらの課題について要因分析し、対応策を検討しました。

要因分析

要因分析としてSREチーム内でKPTAフレームワークを使った振り返りを実施しました。この場で挙げられたProblem、Try、Actionを以下に記載します。

Problem

  • SLOの作成目的の抽象度が高く、解決したい課題が明確になっていなかった
    • 過去に設定した目的:ステークホルダーがどの作業を優先すべきかを決定するため
  • SLOの作成が優先され、何故作るのかが深掘りできていなかった
  • SLOの啓蒙を十分に行わずに他のチームへ展開してしまった
  • SLOが安定しており、課題が出てこない

Try

  • SLOによって何を得たいか具体化する
    • 現状の課題とSLOの目的を明確にする
      • 以下に例を載せるが、SLOがないことによる課題をあげ、SLOが運用されることでどういった状態を目指すか考える
        • 例:
          • 課題:サービスが信頼性を担保できているのかわからない
          • 具体例:レイテンシが悪化傾向にあったとして、対応すべき問題かわからない
          • 目指す状態:SLOがあることにより、サービスの信頼性について判断でき、信頼性の低下時に対応方法の議論/改善が行える
  • 初期段階から他チームやビジネスチームを巻き込むのは難易度が高い
    • SREだけでなく、他チームとSLOについて認識を合わせる
    • 段階を分け、各段階毎に課題と目的を明確にする

上記で他チームと記載しましたが、ここで計測プラットフォーム開発本部の組織体制図を紹介します。体制図からわかる通り、職能毎にチームが分かれている状態となっています。ビジネスサイドはさらに別の組織となっているため、ここでは割愛します。

organization_chart ※引用元スライド: https://speakerdeck.com/zozodevelopers/company-deck

Action

  • SLO設定時の段階分け
  • 各段階の課題と目的を明確化
  • SLOの定期的な見直しと改善

Actionの実行

SLO設定時の段階分け

段階の分け方としては、計測システム部、計測プラットフォーム開発本部、と巻き込む範囲をまずは段階の要素として考え、次にSLOの成熟度も段階の要素として考えました。この2つの要素を縦軸を成熟度、横軸を巻き込む範囲としてグラフ化し、プロダクトのフェーズや状態によって調整しようと考えました。実際には、SLOの計測、可視化、目標の調整、目標値を下回った際の対応など細かいフェーズがありますが、図では簡略化しています。

成熟度と巻き込む範囲を軸にして段階分け

実際に行った段階分けについてはプロダクト毎によって異なりますが、ここではZOZOMATを例として記載します。

縦軸がSLAの箇所に行くにはビジネスサイドを巻き込む必要があり必然的に横軸を進める必要がありますが、ZOZOMATはToB向けのサービスではないためSLOの運用までとし、横軸で段階分けを行いました。

例:ZOZOMATの段階分け

段階 状態
1 SREチーム内でSLOの運用が開始されている
2 計測システム部内でSLOの運用が開始されている
3 POを含め、SLOの運用が開始されている

課題の洗い出し

まずはSLOがないことによる課題を洗い出すところから始めました。ここでは、段階1のSREチーム内で洗い出した課題を例として記載します。

例:SLOがない事による課題(SRE視点)

  • サービスが信頼性を担保できているのかわからない
    • 具体例:メトリクスに変化があっても問題か判断できない
  • 仮に信頼性が低下傾向にあるとわかっても、信頼性を向上させることを他の事項よりも優先すべきか判断できない
    • 具体例:システム振り返りの調査タスクが積もりがち、プランニングで優先度を判断できない

上記で記載したシステム振り返りは、以下のような形で行っています。

  • 開催頻度:週次
  • 参加者:計測システム部所属メンバー
  • 対象システム:ZOZOMAT、ZOZOGLASS、ZOZOFIT
  • 確認する項目:AWSコスト、Datadogコスト、アラート通知履歴、プロダクト毎のDatadogのダッシュボード
  • 進め方:確認項目で気になる点を各自が記載した後、同期的に議論し、改善や調査の必要があればタスクを起票する

目的の明確化

課題について深掘りし、目的を明確化しました。ここでは、段階1のSREチーム内での目的を例として記載します。

信頼性とはそもそも何か

課題に記載した信頼性について言語化ができていない状態だったので、信頼性については定義することから始めました。信頼性が高い状態=ユーザに価値を継続して提供できている状態と考え、それはどういった状態かチーム内で議論しました。まずは、一般的な信頼性について考え、次に計測プロダクトに当てはめた場合について考えてみました。

一般的な信頼性
  • ユーザに価値を提供できていない状態とはどんな状態か
  • ユーザが体験を損なわない速度で応答を返せているか
計測プロダクト
  • 計測に時間がかかりすぎて、こんなに待てないとなっていないか
  • ユーザが体験を損なわない成功率を出せているか
  • 計測の成功率が低く、繰り返しの計測が求められ、離脱に繋がっていないか

ここで計測プロダクトの特性を加味した信頼性について考えることで、SLIを立てる際にユーザージャーニー(以下、UJ)を整理して調整することになりました。

UJの整理

zozomat_uj_list

このように課題を洗い出して深堀りした上で、最初の目的は「SREチームがサービスの信頼性について判断できる状態にし、信頼性の低下を防止できるようになる」としました。

同じ流れで各段階毎の課題と目的を明確化し、最終的にZOZOMATについては以下のように整理されました。

段階 目標 目的 課題が解決された状態
1 SREチーム内でSLOの運用が開始されている SREチームがサービスの信頼性について判断できる状態にし、信頼性の低下を防止できるようになる プランニングで信頼性の向上施策について、優先度を判断できる
2 計測システム部内でSLOの運用が開始されている 計測システム部がサービスの信頼性について判断できる状態にし、信頼性の低下を防止できるようになる システム振り返りで調査対応すべきタスクを定量的な指標で判断できるようになる
3 POを含め、SLOの運用が開始されている POがサービスの信頼性について判断できる状態にし、信頼性の低下を防止できるようになる 信頼性が低下した場合に、他プロダクトの案件と比較して、優先度を判断できる

SLOの定期的な見直しと改善

SLOの定期的な見直しと改善に関しては、チームでスクラムを採用している関係もあり、スクラムイベントの中に組み込みました。具体的には、SLOの確認はリファインメントで行い、課題が見つかった場合もその場で改善タスクを起票すると言った形です。当初は定期的な振り返りを想定していましたが、結果としてMTGの時間を増やす事なく、SLOの評価と改善が行えるようになりました。

SREチームのスクラムについてはブログ記事が公開されているので、気になる方はこちらの記事をご参照ください。

techblog.zozo.com

SLOダッシュボード

SLOの定期的な見直しと改善をするにあたってダッシュボードを整備しました。工夫したポイントとしては、1つのダッシュボードで全てのプロダクトのSLOが確認できる点と、SLOで問題があるものだけが表示される点です。情報量が多くなると見落としがちになるため、必要な情報のみ出すことで議論すべきSLOが明確になりました。なお、ZOZOFITのSLOは今後導入を予定しています。

slo_dashboard

まとめ

本記事では、SLOを導入し運用を進める中での課題と対応策について紹介しました。現状はSREチーム内での運用が開始され、次の段階である計測システム部での運用を目指している状態です。導入し運用に向かう中で見つかった課題と向き合うことで、本来解決したかった課題と目的を改めて考える機会を得られ、結果としてSLOの設計から見直すことができ、運用フローもチームに適した形となりました。SLOの作成や導入を急ぐと陥りがちな状況かもしれませんが、これからSLOの導入を進める方、運用に課題を感じている方の参考になれば幸いです。

余談になりますが、稼働中のPODに対して変更する上でエラーは発生するもののSLOに問題ない=サービスとして許容可能なリスクであると判断し、変更方法を決める際の後押しにもなりました。信頼できるSLOがあることで攻めの姿勢を選択しやすくなりました。これは予期せぬ副産物でした。

ZOZOでは一緒にサービスをより良い方向に改善して頂ける方を募集中です。計測プラットフォーム開発本部としては、既存サービスの改善を日々行いつつ、新規サービスの開発も行っています。このような環境を楽しみ、サービスを一緒に盛り上げていける方を募集しています。少しでもご興味のある方は以下のリンクからぜひご応募ください。

corp.zozo.com

カテゴリー