開発組織全体で意識するSLI/SLOを導入している話

本記事は SimpleForm Advent Calendar 2024 の 21 日目の記事です。
シンプルフォーム株式会社で SRE をしている守屋です。
今年(2024年)に当社で進めている開発組織全体で意識する SLI/SLO の導入プロセスについて紹介します。

※本記事は渋谷でSRE大忘年会で LT 登壇した内容を元に執筆しています。サクッと読みたい方は以下のスライドをご覧ください。
https://speakerdeck.com/zepprix/slonodao-ru-wowan-zhang-tutemasita

なぜSLI/SLOを設定するのか

当初は不要な気がしていた

私が 2024 年 2 月に入社して間もない頃、正直今すぐ SLO/SLO を設定する必要性を感じていませんでした。その時点で監視やオブザーバビリティの仕組みが整備されていたためです。アプリケーションの各種メトリクスを可視化するダッシュボードを毎日 DevOps チームが確認し、異常がある場合は調査する流れができていました。

New Relicダッシュボード

DevOps チームはアラートへの感度も高く、顧客から指摘される前に障害を検知して CS(カスタマーサクセス)と連携して障害対応するフローも出来上がっていました。SRE として何をやるか考えていた当時の私も、SLI/SLO の設定は無理してやらなくてもいいかな？と考えていました。

一転、導入する機運が高まった理由

しかし、よくよくエンジニア組織全体を観察してみるとある課題が浮き彫りになってきました。当社の開発組織の特徴として、プロダクトの数に合わせて分割されているわけではないことが挙げられます。以下はその概要図です。(実際のチーム名とは異なります)

プロダクトの開発組織

各チームの細かい説明は省略しますが、要は同じ領域を複数チームが触る機会があるという点に注目いただければと思います。冒頭にダッシュボードを毎朝確認していると述べましたが、これは上図でいうと DevOps チームの話です。本チームは顧客に提供している主要プロダクトの開発・運用を担っていることもあり、普段から SRE 的な動きが自然とできています。一方で、他チームには DevOps チームとは別のミッションがあり、それ故に各チームの価値観も微妙に異なっています。

チーム間の価値観の違い

チーム毎に責務が異なるので価値観に差分が出るのは当然のことです。仮に各チームが運用しているプロダクトが完全に独立しているのであれば問題ないのですが、当社の場合は相互に API 連携やデータ同期を通してある程度の依存関係が存在しています。DevOps チーム目線だと、他チームがメンテナンスしている連携用 API や同期されるデータの精度が気になってしまいます。いくら DevOps チームが可用性を高める活動をしても、他チームのシステムの品質が足を引っ張って、プロダクト全体の品質が低下しているという意識が芽生えてしまいます。

SLI/SLOを策定することへの期待

チーム間の価値観、温度感の差異は今後、プロダクトや組織がスケールしていくにつれてより顕在化していくでしょう。CTO、EM 陣でも少なからず問題意識は持っており、ガイドラインや意識決定のプロセス整備など様々な改善施策が打たれています。その一環で SLI/SLO にスポットライトが当たりました。

SLOを引くことで攻めと守りのバランスを取れるようにしたい

品質、性能など非機能部分に対してどこまで投資するのか水準、すなわち SLO を設定して開発組織全体に共有しておくことで、意識を上げてもらうだけではなく過剰に安全側に倒して生産性を落とすことを防ぐことができるとよさそうです。このように社内で SLI/SLO を導入する機運が高まり、策定委員会が立ち上がりました。

どのように策定を進めたか

各チームでブレスト

策定委員会は CTO を筆頭に各開発チームからの有志で構成され、エンジニアだけではなく顧客の目線も取り入れるために CS メンバーにも参加してもらうことになりました。手始めに委員会メンバーが各開発チームに入って、SLI 案をブレストしてもらうことにしました。

とある開発チーム内で開催したブレストの様子

ブレストの方法ですが、「我々が守るべき品質とは？」など専門用語を避けてイメージし易いようなテーマで案を出してもらう形を取りました。基本的には自由に意見を出してもらいつつ、ある程度出して欲しい意見の目安を明示しておきました。以下はブレスト前に提示した実際の文章です。

計測可能であること、目標を定める前提で考えること

ブレストに型を設けることには賛否両論あるかと思いますが、最終的に SLI 候補をスムーズに集約できるようにあえて設定してみました。実際に計測できる指標が望ましいということと、後に達成目標(SLO)を設定するという前提条件について述べています。SLO について言及したのは、目標を定めて改善していく価値のある指標はなにか？という観点を盛り込むことで、より本質的なアイデアが出易くなるのではないか？という期待を込めた結果です。

ブレスト結果の集約

各チームから挙がった SLI 候補を集約し、委員会で採用する案を検討していきました。当然、優先度をつけて案を取捨選択していく必要がありますが、その際には今回、SLI/SLO を導入する目的を判断基準として活用しました。当社では以下を目的として設定しています。

• 開発組織全体で共通課題として意識する
• 継続的な運用改善により顧客からのシステムへの信頼を維持する

大勢を巻き込んでブレストした結果、やりたいことが発散していました。例えば「経営層への説明資料として活用する」「SLA として顧客に開示する」といった内容です。一つ目の開発組織内で意識するためであるという目的に立ち返り、SLA までは一旦考慮しないことにしました。また、二つ目の目的は SLI 候補を絞り込んでいく際に役立ちました。ただ計測するだけではなく、既存の運用における課題を洗い出し、継続的な運用改善に繋がるような指標を優先して採用するといった塩梅です。軸を定めて議論を進めた結果、何とか SLI の一覧をまとめることができました。

最終決定したSLI一覧

やってよかったこと

本記事の執筆時点(2024/12/21)では計測する SLI が確定した段階であり、本格的な運用はこれからです。ここまでの検討プロセスを振り返り、良かったと感じることをいくつか挙げてみます。

指標について考える中で現状の運用の課題が炙り出された

SLI/SLO の検討プロセス自体が現状の運用について見直す契機になりました。例えばエンジニアが障害を検知すると Slack ワークフローで障害報告を上げる運用になっているのですが、この際に CS がほしい情報とエンジニアが報告する内容に差分があることが分かりました。例えば顧客対応をするためには復旧目安時間や内部・外部要因のどちらなのか、といった情報が重要ですが、誰しも主体的に情報を漏れなく報告できているわけではありませんでした。そこで SLI/SLO とは別の文脈で障害報告のワークフローを改善しようと動いています。

あえて大勢の意見を集約する形を取ったことでより本質的な指標を定義できた

少人数の委員会内で意思決定を完結させてしまえば当然ですが迅速に SLI が決定できていたことでしょう。しかし今回あえて大勢の意見を集約したことでより当社にとって価値のある指標を定義できたと感じています。当初、私は API のレイテンシーやエラー率といったいわゆるゴールデンシグナルを計測することをイメージしていました。実際各チームでのブレスト結果にもそのような案が多く含まれていましたが、可用性という軸だけではなく、セキュリティやデータ精度といった観点でも多くの意見が挙がってきました。例えば「脆弱性のあるライブラリの混入率」を GitHub のDependabot alerts から取得して SLI として追っていくのはどうか？といった具合です。最終的に「データ精度」「セキュリティ」及び「可用性」という大枠の三本柱で SLI を定義していくことに決まりました。私一人ではこのような結論には辿り着けなかったと思いますし、結果的に社内に公開した際に皆の納得が得られる指標に辿り着けたと感じています。

まとめと今後の運用について

本記事では開発組織全体で意識する SLI を定義するところまでのプロセスについて紹介してきました。今後はしばらく SLI を計測し、その実績値や現状の運用体制を踏まえて SLO を順次、設定していく予定です。委員会は月一で定例 MTG を開いて、各指標のチューニングや計測結果を受けての改善アクションの検討を行っていこうと考えています。正直、大変なのは運用に乗せていくこれからなのですが、皆で いい感じ の運用を実現するために頑張っていきたいと思います。