[レポート] SRE の基本と組織への導入 〜サービスレベル目標やエラー予算などサービスの信頼性に対する考え方〜 #GoogleCloudDay

TL;DR

• Googleでは4分間システムを止めるとボーナスが貰える（語弊）
• 原則 「信頼性は最も重要な機能」「信頼性を決めるはユーザー」「99.999%はソフトウェアだけでも運用だけでも達成出来ない」
• 人間の脳はリスク分析を正しく行えない。ではどうするか？
• class SRE implements DevOps {}

5/25〜27の日程で行われたオンラインイベント、Google Cloud Day: Digital '21。
3日目に公開されたセッション「SRE の基本と組織への導入」を拝聴しましたのでレポートします。

個人的にめちゃくちゃツボだったセッションでした！

具体的なサービスレベル目標(SLO)の策定方法・エラー予算(エラーバジェット)の策定方法・考え方から、そもそもSREとは・信頼性とはといった概要論、組織への導入方法・文化論まで、「SRE」を中心に置いた事柄がほぼほぼ網羅出来る内容です。SRE発祥の地であるGoogleがどのように扱っているか、そもそもSREを生んだ土壌は何だったか、非常に興味深い話が並んでいます。すごく実践的なセッションだと思います。

ちなみに、初見で拝聴した直後の勢いで社内Slackでも共有したのですが好評で、企業の内製化・DevOps論や心理安全性などについて盛り上がりました。

もう少し具体的な内容もこのあと紹介していきますが、もちろん全てを紹介できるわけではありません。
30分程度のセッションなので、是非レジストレーションした上でオンデマンド動画と資料をご覧になって下さい！

セッション概要

ビジネスのさらなるデジタル化が進むなかで、すばやく市場へ価値を届けながらサービスの信頼性を保つためのしくみが求めらるようになり、SRE (Site Reliability Engineering) への関心が高まっています。
本セッションでは、サービスレベル目標やエラー予算などの SRE の基本となるサービスの信頼性に対する考え方をご紹介し、どのようにして SRE を組織へ導入していくかを議論します。

記事公開時点で、セッションのページからオンデマンド動画とスライド資料が閲覧可能です。
公開期限は明示されていませんし、このあとレジなしで見られるようになるかどうかも不明なので、お早めに！¹

スピーカー

• Google Cloud 川端 俊司氏
  • プロフェッショナル・サービス ストラテジック / クラウド エンジニア
  • 顧客システムに対する技術支援を行うエンジニア

内容

導入

• 素早く開発しながら世の中にリリースする仕組みが求められるようになっている
• ビジネスライフサイクルの間にある摩擦
  • ビジネスの要求
  • 開発はより早くリリースしたい
  • 事故防止のため、慎重なテストやリリース要件を運用は求めるように
• DevOps導入で解決しようとして、そこにも困難さがある
  • ひとやプロセスが変化についていけない、ツールでは解決しない
• Googleには人を責めない文化がある
  • 高い心理安定性を保つよう努力している
  • 例：想定外の事象によりGoogleの主要なサービスを4分間停止させてしまった担当者に、そのあと何か起きたか？
    • -> この担当者が失敗できてしまった「不備」が明らかになり、改善によりユーザーのためになった
    • -> 担当者にボーナスが支給された
    • -> 週次の全社MTGで共有、役員含め参加者らから大きな拍手
    • Googleには本当に「ひとを責めない」文化がある
• 必ずものは壊れる。壊れてもいいように仕組みを改善する
  • この問題にGoogleはどう取り組んだか？
  • どのように改善していったか？

01 SREの基本

• Googleでは、ソフトウェアエンジニアがシステム管理の仕組みを作って運用している（SREチーム）
• SREの原則
  • 1: 最も重要な機能は信頼性
    • 信頼性とは？
    • 「ユーザーに使って貰える」状態にする
    • 目指すのは「それなり」
      • 魅力的な機能の追加・実装とのバランスが重要
  • 2: 信頼性を決めるのはユーザー
    • 監視システムの設定値を下回っているからといって、それが信頼性の高さを示しているわけではない
    • ex) CPU値が100%でもサービスが使えていればユーザーは満足、逆に余裕があっても使えなければ不満
  • 3: 可用性 99.999% (Five-Nine、25秒/30日) を達成するには
    • 99.9% はソフトウェアの設計で達成出来る
    • 99.99% （4分+/30日）を達成するには、しっかりした運用設計と熟練、自動化が必要
    • 99.999% のためには投資やリリース計画など、経営(ビジネス)判断が必要
• 物が壊れるのは、雨が降るのと同じ自然現象
  • 雨を止めるのではなく、「雨が降ったらどうするか」を考えるほうが現実的
  • = 失敗・故障・障害を前提として設計する

• 極端に高い信頼性を実現しようとすると？
  • ユーザーに価値を届ける速度が制限される
  • にもかかわらずコストは大幅増
• SREが最大化するのは信頼性ではなくてユーザーの幸せ
  • リスク、イノベーション速度、運用効率のバランス
  • サービスの機能を最適化
• 信頼性とは？
  • ユーザーが満足するのは、(システムが) その期待に応えているから
  • ユーザーは何をもって「そのシステムが信頼できる」と判断するのか？
    • -> SLI（サービスレベル指標）
  • そのSLIにおいて、ユーザーがギリギリ「満足」出来るライン
    • -> SLO (サービスレベル目標)
• クリティカルユーザージャーニー (CUJ)
  • ユーザーが(最終的に)目的を達成するためにサービスと(何回か)行うやり取りのこと
  • SLIとして、このCUJを使うのがよさそう
  • CUJを測定するために使えるSLI
    • リクエスト・レスポンス（可用性、遅延、品質）
    • データ処理（カバレッジ、正確性、鮮度、スループット）
    • ストレージ（スループット、遅延）
• エラー予算（※エラーバジェット）
  • 信頼性を保つ上で許容できる不具合の量のこと
  • どれくらいシステムを止められるか？
  • 1 - SLO
    • SLO 99.95%であれば、エラー予算 = 0.05%
    • 30日間で 21.6分
    • エラーの発生率が全体のトラフィックの 1%であれば -> 36時間/30日
    • -> カナリアリリースが有効
  • エラー予算の使い方
    • エラーが多いシステムならリリースを遅らす
    • エラーが少なければ（予算が残っていれば）計画通りのリリースを
    • データに基づいて判断を
    • Cloud Operation Suiteを使うと計測できる
  • エラー予算のメリット
    • 開発とSREの共有のインセンティブ
    • 開発チームが自分でリスクを管理出来る
    • 非現実的な信頼性の目標は魅力的でなくなる（イノベーションの速度を遅くすることが可視化される）
    • 信頼性に対する責任をチーム全体（開発・運用）で共有できる
• リスク
  • 人間の脳は、リスクの比較と評価において、信頼できないということが知られている
    • 間違った評価・分類をしてしまう
  • リスクを客観的に分析できるフレームワークが必要
• Googleで採用されている方法↓

• エラー予算の使い方を検討・実行
• SLOは定期的にレビューする

02 SREの組織への導入

• SREの実践分野
  • 指標と監視、監視と警告、トリガーとアクション
    • これまで話してきた部分
    • 本当に深刻な脅威の場合にのみ人間を巻き込む
  • キャパシティ計画、有機的・非有機的な成長
  • 変更管理、約70%の障害は変更を加えることによって発生する
  • 緊急対応、インシデント基準、業務責任(RACI）、手順書・ドキュメント
  • 文化、心理安全性、徹底したデータ駆動
    • DevOpsはツールだけでは実現できない

• SREを導入するためのアプローチ
  • 新しいことを始めようとすると、必ず反対する力が働く(当たり前のこと)
  • 小さく始める、反対勢力を巻き込み段階的に進める
  • ひとつのアプリチームからはじめて、必要に応じて繰り返す
    • 組織内にチャンピオンを作る
  • その後に他のチームへ横展開
  • 年単位で計画
  • GoogleによるSRE導入支援
    • 4つのメニュー
• 次のステップ
  • 01 google.com/sre を訪問する
  • 02 SLOを導入する
  • 03 ポストモーテムを実践する
  • 04 Googleといっしょに始める
• まとめ：さあ、一緒にSREの旅を始めましょう！

所感

冒頭で書いた内容の繰り返しになりますが、非常にためになるセッションでした。
AWSでも唱えている「Design for Failure」ですとか、またWell-Architected Frameworkの信頼性の柱など、プラットフォームを越えて共通のメッセージがあるように思えました。

SRE自体はGoogleが発祥ということで、文化的な土壌は最初からGoogleに備わっていたものであり、他の組織がそのまま導入するのは難しいと思われるのですが、「SRE」という考え方はその困難さを受け入れて余りある恩恵がある文化だと思っています。
このセッションでも言われていたように、その組織に合わせて柔軟に、段階を経て、必要な・できるところところから少しずつ始めていくのが良いのではないでしょうか。

併せて読みたい