本記事はUzabase Advent Calendar 2023の15日目の記事です。
はじめに
株式会社ユーザベースSREの杉山とSWE（ソフトウェアエンジニア）の山本です。
私たちはSLOの運用をSREとSWEで組織的に取り組んでいます。
要旨
開発チームは日々の開発とSLOの運用を並行して遂行しています。ただ、SLOの運用に割く時間が増えてきて開発に影響が出てきました。対応策としては、ユーザーの信頼性を維持しつつ現状のCUJを絞りSLOの目標値を下げました。これによって開発チームも納得感を持ち取り組めるようになりました。
本稿では組織的に取り組む上で生じた課題などご紹介します。
背景
事業内容と開発体制
FORCASとは、B2B事業向け顧客戦略プラットフォームを提供しているSaaSプロダクトです。具体的には、顧客企業が保有するリードリストとFORCASが所有する企業データベースを名寄せすることでデータをエンリッチにし、ターゲットリストを作成することでABM（アカウントベースドマーケティング）を実行することができるプロダクトです。
またFORCASの開発チームは3チーム計SWE12名で、組織全体ではアジャイル（XP）に開発しています。
開発チームの中からSLOの対応を一部リードする存在として3名のSWEがSLOチームとして稼働しています。
なぜSLOを運用しているのか
2点挙げると、1点目は信頼性が低いサービスはチャーン（解約）に繋がる可能性があるからです。具体例として、顧客はリードリストをFORCASにアップロードすることで名寄せを行い、リストをエンリッチにすることができます。このエンリッチを価値だと感じている顧客からすると、もしこの名寄せ処理のエラーが多発しリストのエンリッチができなかった場合、ユーザーはFORCASというサービスに対して信頼性を持てなくなり解約に繋がるでしょう。それを防ぐためにSLOでエラーを監視・対応しサービスの信頼性を保ちます。
2点目はユーザー体験の悪化に繋がるであろう遅いレスポンスを観測するためです。
このようにFORCASでは「Error」と「Latency」の2点のメトリクスと18個のCUJ、96個のSLOを監視しています。
取り組み内容
週3回SLOチームでMTGを開き、SLO運用の課題出しや対応案出し・施策立案などを行っています。そのSLOチームで生まれた議題をSWE全体の週次で共有します。また、その週に発生したアラートの共有も行い、原因調査や対応アクションのタスクを各チームに割り振って対応しています。
それ以外にもPdMとコミュニケーションをとりながら現状SLOの課題点の共有や、四半期ごとにCUJ、SLOの見直しをしています。またPdMだけではなく事業部のビジネスサイドにもSLOの重要度の共有や啓蒙・社内アンケートの実施を行いました。
課題
こうしたSLOの運用は次第にコストが高まり、開発時間に影響があることが発散的に開発チームから上がってくるようになりました。声を受けてSLOチームとSREでディスカッションをしていくと現時点で定めているSLO全てを監視・対応することには現時点では無理があるのでは？と収束してきました。
解決策＆評価
注力するCUJを絞り、部分的に目標値を下げました。
取り組み内容で記載したようにCUJを18個設定していましたが、2個だけに注力して対応していくことにしました。
これは開発チームと話し合い、現状の開発リソースでは全てを対応し切ることが厳しいという判断のもと、直近数ヶ月で特にアラートが発生しているCUJにだけ絞り、まずはこのCUJ2個とSLO20個をアラートが発生しない状況に持っていくことに注力することにしまし。
例えば「Error：ユーザーはxx画面をでxxをすることができる」というCUJがあったとします。この目標値を今までは99.9%にしていたのですが、本当にユーザーが望む品質はこの閾値の高さでいいのか？もっと下げる余地はあるのではないか？といったことをユースケースなど含めPdMと議論を重ねながら、ユーザーの理想よりも目標値が高いだろうと推測できるものに関しては機能開発を優先するためにいくつかの目標値を下げるという意思決定を行いました。下げた目標値や絞ったCUJに関してはステイというわけではなく、開発の優先度と検討し上げる余地も残しておきつつ、引き続きSLOを運用していきます。