⾃律的な開発チームを⽀えるためのSLO運⽤

⾃律的な開発チームを⽀えるためのSLO運⽤ Sansan株式会社 Bill One Engineering Unit SREチーム上司陽平

⾃⼰紹介じょーし（上司） Sansan株式会社 @paper2parasol - Sansan株式会社でBill OneプロダクトのSREチームに2022年8⽉から所属 - 前職はSIer企業でコンテナ技術やSREの普及活動、
AWS・AzureでのKubernetesサービスの設計・構築に従事 - 現職ではSREのミッション定義、オブザーバビリティの向上、負荷試験による性能改善、IaC化などを推進 - 好きなものはラーメンとCloud Run

Bill OneとSREチームの紹介 SLOの取り組み今後の展望

プロダクト開発チーム 4 ⼈前後のチームが 12 個存在 SRE 機能開発グローバル対応機能開発機能開発
機能開発コンプリケイテッド・サブシステムグローバル対応機能開発機能開発機能開発機能開発

マイクロサービスを採⽤サービス機能開発チーム機能開発チームサービス機能開発チームサービス機能開発チーム開発・運⽤開発・運⽤
開発・運⽤主要マイクロサービスが10個程あり、各マイクロサービスを1~2の機能開発チームで担当（重複あり）

アーキテクチャ概要図 Microservice B Microservice A BFF (backend for frontend) Microservice
Z ‧‧‧ DB DB DB

Bill One SREチームのビジョンとミッションミッション開発チームが⾃律的に動ける仕組みを整えつつ、信頼性と開発効率の向上をリードするビジョン⾃律的に⾼い信頼性を維持できる開発チームを⽀えるための触媒となる

ビジョン⾃律的に⾼い信頼性を維持できる開発チームを⽀えるための触媒となる ※ 触媒とは化学反応の反応速度を速める物質で、⾃⾝は反応の前後で変化しないものをいうサービス機能開発チーム機能開発チームサービス機能開発チームサービス
機能開発チーム開発・運⽤開発・運⽤開発・運⽤

SRE チームなんかめっちゃ信頼性維持しやすい！ビジョン⾃律的に⾼い信頼性を維持できる開発チームを⽀えるための触媒となる ※ 触媒とは化学反応の反応速度を速める物質で、⾃⾝は反応の前後で変化しないものをいうサービス機能開発チーム
機能開発チームサービス機能開発チームサービス機能開発チーム開発・運⽤開発・運⽤開発・運⽤

- SRE チームメンバの専⾨性が必要なタスクは SRE が主導する - 並⾏してそれらを機能開発チームに委譲する仕組みづくりを検討・推進する信頼性向上促進 SRE
チームミッション開発チームが⾃律的に動ける仕組みを整えつつ、信頼性と開発効率の向上をリードするサービス機能開発チーム機能開発チームサービス機能開発チームサービス機能開発チーム開発・運⽤開発・運⽤開発・運⽤

サービス全体のSLOとバーンレートアラートの試験運⽤を開始各バックエンドサービスのSLOとバーンレートアラートの運⽤開始改善を重ねてバーンレートアラートが実⽤的になる SREチームの⽴ち上げ、リリースフローや性能など様々な課題に向き合う 2022/02 2022/03 2023/01 2023/07

Bill One サービス全体（≒BFF）のSLI/SLO Users サービス・・・ SLO レイテンシ 99%tileが1000ms以下エラー率
0.1%以下 - ユーザリクエストのレスポンスレイテンシとエラー率をSLIとしている - エラーバジェットが急激に低下した場合にバーンレートアラートを発報するサービス

サービス全体のバーンレートアラート活⽤状況 - バーンレートアラートを受けて異常事態としてSREチーム外のメンバが調査を開始できる状況になってきた - 設定当時はアラートがよく発⽣し、SREだけが気にしている感じだった - 2023/01頃には様々な改善によりアラートが基本発報されなくなった Users Bill
One バーンレートアラート Slack

サービス全体のSLOとバーンレートアラートの試験運⽤を開始各バックエンドサービスのSLOとバーンレートアラートの運⽤開始改善を重ねてバーンレートアラートが実⽤的になる SREチームの⽴ち上げ、リリースフローや性能など様々な課題に向き合う 2022/02 2022/03 2023/01 2023/07

- 信頼性と開発のバランスを取れるようにする - バーンレートアラートにより単⼀サービスの異常を検知し、各開発チームが⾃律的に担当サービスの信頼性を向上しやすくする各バックエンドサービスごとにSLO運⽤を開始した⽬的最速機能追加最速機能追加信頼性向上信頼性向上
バジェットが残っているバジェットが枯渇

- 開発チームの負荷が⼤きくなり過ぎないように⼩さく始めて少しずつ改善していくことを前提に進めた - エラー率を0.1%以下にするというSLOのみを設けた - SLI/SLOなどの⽤語や基本的な考え⽅、Bill Oneでの運⽤（後述）の説明会を実施して開始したはじめの⼀歩

- 調査 - （Fast Burnの場合）即座に原因調査 - （Slow Burnの場合）適宜原因調査 - エラーバジェットが枯渇していない限り、原因不明の場合は各チームの
判断で適宜調査を打ち切って良い - 対応・対策・改修 - チーム内で話し合い、任意で実施する - 誤検知削減 - 各チームが誤検知を減らすように適宜値を調整するバーンレートアラートの発報時の運⽤

- 必ず枯渇原因を調査し、優先度が⾼い場合は改善計画を⽴てる - 必ず即座に対応するのではなく、まずはライトな意思決定で活⽤していくことにしたエラーバジェット枯渇時の対応

エラーバジェットを意思決定に活⽤できています！！

エラーバジェットを意思決定に活⽤できています！！ …と⾔いたかったですがまだ道半ばです。。。

- エラーバジェットの残量を活⽤したアラートが作成できない - エラーバジェットを表⽰する機能はあるが枯渇前の検知などができない - 各チームに定期的に⾒ることを強制したくなかったのでバジェット枯渇時の運⽤を保留している - 特定エンドポイントのエラー率やレイテンシのSLIにはログベースの指標が必要
- CUJ (Critical User Journey)を元にした重要なエンドポイントのみを対象としたSLIを作成するときにサクッと作れると嬉しい - SLO 99.9%が最⼤ - Bill Oneの各サービスのエラー率は低いので必要に応じてより厳しい値で運⽤ができたら良いかもと妄想している Google CloudのSLO機能の課題

- 現在CUJ (Critical User Journey) を踏まえたエンドポイントを別の⽂脈で洗い出している - 今後整理したエンドポイントを活⽤し、SLIとして活⽤していくことも考えている
CUJベースのSLI/SLOの作成

- エラーバジェットが残り少なくなった際のアラートを実装し、エラーバジェットによる意思決定を実施 - CUJを踏まえて洗い出したエンドポイントを活⽤し、SLI/SLOを実装 - エラー率のSLOを99.9%より厳しくするかの検討 - バーンレートアラートからサービスマップに直接遷移できるようにし、より迅速な対応を実現
SLOの実装をGoogle CloudからSplunkに移⾏

- Bill OneのSREチームは開発チームが⾃律的に信頼性を向上できる仕組みを整えつつ、信頼性と開発効率の向上をリードする - バーンレートアラートを受けてSREチーム外のメンバも調査を開始できる状況になってきた - バックエンドサービスのSLO運⽤を始めたがエラーバジェット枯渇時の運⽤はまだできていない
- SLOの実装をGoogle CloudからSplunkに移⾏することでSLO運⽤を洗練していきたいまとめ

⾃律的な開発チームを⽀えるためのSLO運⽤

⾃律的な開発チームを⽀えるためのSLO運⽤

SansanTech
PRO

More Decks by SansanTech

Other Decks in Technology

Featured

Transcript