エラーバジェット、どう運用していますか？/ Error budget practice

SRE Lounge #13 登壇資料

開発速度と信頼性のバランスを取るためのエラーバジェット。これが枯渇した場合にSREと関係者はどのように行動することとしているか、その考え方や取り組みの事例についてお話しします。

https://sre-lounge.connpass.com/event/227250/

Transcript

1. エラーバジェット、どう運用していますか？ SRE Lounge #13 株式会社ビズリーチ (Visionalグループ) 山原 崇史
2. 山原 崇史 (やまはら たかし) 所属 株式会社ビズリーチ（Visionalグループ） HRMOSプロダクト本部 RSプロダクト部 Site Reliability Engineeringグループ 経歴 SIer・銀行・Web系等を経て、2021年2月に株式会社ビズリーチ入社 自己紹介 @shonansurvivors
3. 設立　　 ：2020年2月（ビジョナル株式会社設立） 創業　　 ：2009年4月（株式会社ビズリーチ創業） 代表者　 ：ビジョナル株式会社 代表取締役社長　南 壮一郎 グループ従業員数：1,466名（2021年7月末時点） 資本金　 ：164億円（資本準備金含む）※2021年5月18日時点 拠点　　 ：東京、大阪、名古屋、福岡、静岡、広島 グループ概要
4. グループミッション
5. グループ運営サービス インキュベーション（新規事業領域） 採用プラットフォーム 人財活用プラットフォーム 人材マネジメント（HR Tech）エコシステム 事業承継M&A 物流Tech Sales Tech サイバーセキュリティ
6. エラーバジェット、どう運用していますか？
7. • ここまでは信頼性を損失しても良い、という予算 • サービスレベル目標(SLO)と現在のサービスレベル指標(SLI)から導かれる エラーバジェットとは SLO 信頼性 時間 SLI エラーバジェット エラーバジェットが 枯渇！
8. ◦ リリースを一時的に停止する／リリース速度を下げる ◦ システムの弾力性を増す／パフォーマンスを改善する ◦ テストや開発へのリソース投資を追加する (p37〜p38から抜粋・要約) 2017 Besty Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy「Site Reliability Engineering」O’REILLY • 開発速度よりも信頼性を優先し、上記のような行動を取る ◦ なお、枯渇してからではなく、枯渇しそうになった段階で上記に準じた 行動を取り始めても良い エラーバジェットが枯渇したら？
9. 実際に機能の開発速度より信頼性を最優先にできるか？
10. ・Devを巻き込めていないと・・・ Devからの反対 SRE プロダクトオーナー & 開発チーム 😥 ビジネスサイド 機能開発が できないのは 困る！
11. ・Devを巻き込めていたとしても、Bizを巻き込めていないと・・・ Bizからの反対 SRE 😥 ビジネスサイド 😥 リリースに 遅れが出るのは 困る！ プロダクトオーナー & 開発チーム
12. 「HRMOS採用」の場合はどうだったか？ HRMOS採用・・・HRMOSのうち採用管理に関するプロダクト
13. • もともとBiz、Dev、Opsそれぞれが対等な文化、土壌があった • エラーバジェット導入時も強い抵抗に遭うようなことはなかった • それでも関係者全員でエラーバジェットを共有し続けられるようにするため、 各種取り組みを行なった 「HRMOS採用」の場合
14. 1. 運用ルールの明確な定義と文書化 2. 関係者全員のコミットメントを得る 3. ルールが形骸化せずに遵守される仕組み作り エラーバジェットを関係者全員で共有するために
15. 内容 • エラーバジェット過剰消費／枯渇時の行動指針を中心に記述 狙いや効果 • ルールの文書化なんて、当たり前のことではありますが・・・ ◦ 関係者全員がブレずにルールを運用するためにも、ルール内の矛盾や曖昧さを排除 ◦ SRE個々人によってエラーバジェットに対して言っていることが違う、と いったことも無くす 1. 運用ルールの明確な定義と文書化
16. 大まかな流れ 1. 信頼性向上期間(≠ リリース凍結期間)に入る 2. 信頼性向上期間に何を行い、何をもって同期間を解除するかの基準を策定する 特記事項 • ただし、信頼性向上期間に即日入るか、数日の猶予を持たせるかは プロダクトオーナーに最終的な判断を委ねる余地を残している 参考：HRMOS採用でのエラーバジェット枯渇時の行動
17. ルールを広く関係者に事前説明し、理解と合意を得る • 開発チーム • プロダクトオーナー • 各部門の責任者(エンジニア／カスタマーサクセス／営業) その他コミットメントを得るための取り組み • 各関係者はルールの見直しを随時提案可能であることを明文化 2. 関係者のコミットメントを得る
18. スクラムのDoneの定義への組み込み • 「エラーバジェットが枯渇していないこと」をDoneの定義に組み込んだ • スクラムに関わる全員が自然とエラーバジェットを意識した プロダクト開発を行うことを実現 補足 • エラーバジェットはPBI(プロダクトバックログアイテム)単位に紐づくものではないが、 リリース判定の判断材料とすることで、開発速度と信頼性のバランスを取る 3. ルールが形骸化せず遵守される仕組み作り
19. • エラーバジェットは「ここまでは信頼性を損失しても良い」という予算 • エラーバジェット枯渇時には、信頼性回復の行動を最優先とすることとした • 組織が一体となって行動できるようにするための各種取り組みを行なった ◦ 運用ルールの明確な定義と文書化 ◦ 関係者のコミットメントを得る ◦ ルールが形骸化せずに遵守される仕組み作り まとめ
20. ご清聴ありがとうございました We are hiring!