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

SRE Lounge #13 登壇資料

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

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

Transcript

1. エラーバジェット、どう運用していますか？
   SRE Lounge #13
   株式会社ビズリーチ (Visionalグループ)
   山原 崇史
   

   View Slide

2. 山原 崇史 (やまはら たかし)
   所属 株式会社ビズリーチ（Visionalグループ）
   HRMOSプロダクト本部
   RSプロダクト部
   Site Reliability Engineeringグループ
   経歴 SIer・銀行・Web系等を経て、2021年2月に株式会社ビズリーチ入社
   自己紹介
   @shonansurvivors
   

   View Slide

3. 設立　　 ：2020年2月（ビジョナル株式会社設立）
   創業　　 ：2009年4月（株式会社ビズリーチ創業）
   代表者　 ：ビジョナル株式会社 代表取締役社長　南 壮一郎
   グループ従業員数：1,466名（2021年7月末時点）
   資本金　 ：164億円（資本準備金含む）※2021年5月18日時点
   拠点　　 ：東京、大阪、名古屋、福岡、静岡、広島
   グループ概要
   

   View Slide

4. グループミッション
   

   View Slide

5. グループ運営サービス
   インキュベーション（新規事業領域）
   採用プラットフォーム 人財活用プラットフォーム
   人材マネジメント（HR Tech）エコシステム
   事業承継M&A 物流Tech
   Sales Tech
   サイバーセキュリティ
   

   View Slide

6. エラーバジェット、どう運用していますか？
   

   View Slide

7. ● ここまでは信頼性を損失しても良い、という予算
   ● サービスレベル目標(SLO)と現在のサービスレベル指標(SLI)から導かれる
   エラーバジェットとは
   SLO
   信頼性
   時間
   SLI
   エラーバジェット
   エラーバジェットが
   枯渇！
   

   View Slide

8. ○ リリースを一時的に停止する／リリース速度を下げる
   ○ システムの弾力性を増す／パフォーマンスを改善する
   ○ テストや開発へのリソース投資を追加する
   (p37〜p38から抜粋・要約)
   2017 Besty Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy「Site Reliability Engineering」O’REILLY
   ● 開発速度よりも信頼性を優先し、上記のような行動を取る
   ○ なお、枯渇してからではなく、枯渇しそうになった段階で上記に準じた
   行動を取り始めても良い
   エラーバジェットが枯渇したら？
   

   View Slide

9. 実際に機能の開発速度より信頼性を最優先にできるか？
   

   View Slide

10. ・Devを巻き込めていないと・・・
    Devからの反対
    SRE
    プロダクトオーナー
    & 開発チーム
    😥
    ビジネスサイド
    機能開発が
    できないのは
    困る！
    

    View Slide

11. ・Devを巻き込めていたとしても、Bizを巻き込めていないと・・・
    Bizからの反対
    SRE
    😥
    ビジネスサイド
    😥
    リリースに
    遅れが出るのは
    困る！
    プロダクトオーナー
    & 開発チーム
    

    View Slide

12. 「HRMOS採用」の場合はどうだったか？
    HRMOS採用・・・HRMOSのうち採用管理に関するプロダクト
    

    View Slide

13. ● もともとBiz、Dev、Opsそれぞれが対等な文化、土壌があった
    ● エラーバジェット導入時も強い抵抗に遭うようなことはなかった
    ● それでも関係者全員でエラーバジェットを共有し続けられるようにするため、
    各種取り組みを行なった
    「HRMOS採用」の場合
    

    View Slide

14. 1. 運用ルールの明確な定義と文書化
    2. 関係者全員のコミットメントを得る
    3. ルールが形骸化せずに遵守される仕組み作り
    エラーバジェットを関係者全員で共有するために
    

    View Slide

15. 内容
    ● エラーバジェット過剰消費／枯渇時の行動指針を中心に記述
    狙いや効果
    ● ルールの文書化なんて、当たり前のことではありますが・・・
    ○ 関係者全員がブレずにルールを運用するためにも、ルール内の矛盾や曖昧さを排除
    ○ SRE個々人によってエラーバジェットに対して言っていることが違う、と
    いったことも無くす
    1. 運用ルールの明確な定義と文書化
    

    View Slide

16. 大まかな流れ
    1. 信頼性向上期間(≠ リリース凍結期間)に入る
    2. 信頼性向上期間に何を行い、何をもって同期間を解除するかの基準を策定する
    特記事項
    ● ただし、信頼性向上期間に即日入るか、数日の猶予を持たせるかは
    プロダクトオーナーに最終的な判断を委ねる余地を残している
    参考：HRMOS採用でのエラーバジェット枯渇時の行動
    

    View Slide

17. ルールを広く関係者に事前説明し、理解と合意を得る
    ● 開発チーム
    ● プロダクトオーナー
    ● 各部門の責任者(エンジニア／カスタマーサクセス／営業)
    その他コミットメントを得るための取り組み
    ● 各関係者はルールの見直しを随時提案可能であることを明文化
    2. 関係者のコミットメントを得る
    

    View Slide

18. スクラムのDoneの定義への組み込み
    ● 「エラーバジェットが枯渇していないこと」をDoneの定義に組み込んだ
    ● スクラムに関わる全員が自然とエラーバジェットを意識した
    プロダクト開発を行うことを実現
    補足
    ● エラーバジェットはPBI(プロダクトバックログアイテム)単位に紐づくものではないが、
    リリース判定の判断材料とすることで、開発速度と信頼性のバランスを取る
    3. ルールが形骸化せず遵守される仕組み作り
    

    View Slide

19. ● エラーバジェットは「ここまでは信頼性を損失しても良い」という予算
    ● エラーバジェット枯渇時には、信頼性回復の行動を最優先とすることとした
    ● 組織が一体となって行動できるようにするための各種取り組みを行なった
    ○ 運用ルールの明確な定義と文書化
    ○ 関係者のコミットメントを得る
    ○ ルールが形骸化せずに遵守される仕組み作り
    まとめ
    

    View Slide

20. ご清聴ありがとうございました
    We are hiring!
    

    View Slide