SRE本3章 - リスクの受容

では引き続き、「SRE サイトリライアビリティエンジニアリング」の、今日は3章を見ていきます。

この章は冒頭でこのように書かれており、非常に重要な章であることがわかります。

「SREの仕事とはどういうものか」、そして「なぜそのような仕事をするのか」
についての幅広い見地を得たい方にとっては、最重要となる必読の章です。

では、さっそく見ていきます。

この章では、大きく4つのことが書かれています。

  1. リスクの管理
  2. サービスリスクの計測
  3. サービスのリスク許容度
  4. エラーバジェットの活用

個人的に特に面白かったのは、4. エラーバジェットの活用 でした。 一つ一つ、いつものように雑にまとめてみましょう。

1. リスクの管理

信頼性のないシステムは急速にユーザーの信頼を失うことになるので、可能性を減らすためのコストは支払う必要があります。 このコストには2つの特徴があります。

  • 冗長なマシン / コンピュートリソースのコスト
    設備の冗長化にかけるコスト。

  • 機会のコスト
    リスクを減らすためのシステムや機能を構築するために組織がエンジニアリングリソースを割り当てることから生じるコスト

SREでは、サービスの信頼性を管理する大部分は、リスクを管理することによって行います。
下記2つは、等しく重要なポイントです。

  • システムの信頼性を高めるためにエンジニアリングを見いだすこと
  • 動作させるサービスの適切な障害許容レベルを定めること

サービスを十分信頼できるものにするための努力はしつつも、必要以上に信頼性を高めようとはしない、というのも重要なポイントです。

2. サービスリスクの計測

Googleが注目している客観的なリスク検知のメトリクスは、計画外の停止時間です。
この計画外の停止時間は、サービスの可溶性に求められるレベルによって把握できます。

可用性=\frac{稼働時間}{稼働時間+停止時間}

ただ、Googleのように24/7で世界中のどこかからサービスのトラフィックを少なくとも一部を提供している可能性が高いとなると、時間を基にしたメトリクスは意味を持たないので、リクエストの成功率の観点から可用性を定義しています。

可用性=\frac{成功したリクエスト数}{総リクエスト数}

このサービス可用性のターゲットを四半期単位で設定し、そのターゲットに対して週単位、もしくは日単位でパフォーマンスを追跡しています。

3. サービスリスクの許容度

サービスリスクの許容度を特定するためには、SREがプロダクトのマネージャーと共同で作業を行い、一連のビジネスゴールをエンジニアリング可能で明確な目標に変換する必要があります。
この共同作業は、現実には簡単ではなく、本の中ではコンシューマサービスとインフラストラクチャサービスの場合で分けて解説されていますが、共通するリスク許容度の評価に関しては、以下の4点が挙げられています。

  • 必要な可用性のレベル
  • 障害の種類の違いによってサービスへの影響に差はないか
  • リスク曲線状にサービスを位置付ける上で、サービスコストはどのように利用できるか
  • 考慮すべき重要なサービスメトリクスとして、他にはどのようなものがあるか

4. エラーバジェットの活用

プロダクト開発者のパフォーマンスがプロダクトの開発速度で主に評価されているのに対し、SREのパフォーマンスはサービスの信頼性を基にして評価されます。
そのため、この両者には本来的な緊張が存在していますが、エラーバジェットはこの緊張を客観的に解消することのできる手法です。

エラーバジェットは、Googleでは以下のように形成されます。

  • プロダクトマネージャーがSLOを規定。四半期内に期待されるサービスの稼働時間を設定
  • 実際の稼働時間は、中立な第三者であるモニタリングシステムによって計測
  • この2つの値の差異が、その四半期内の「損失可能な信頼性」という「予算」の残分となる
  • 計測された稼働時間がSLOを超えている、言い換えればエラーバジェットがまだ残っているなら新しいリリースをプッシュできる

非常にわかりやすいですね。
これなら社内政治等のわかりづらい手法で両者の対立が激化することなく、プロダクト開発とSREとのバランスを保つことができます。
もしエラーバジェットが枯渇したタイミングで、どうしてもその四半期内に追加のプロダクト開発を行いリリースをプッシュしたいときは、SLOを緩和することによってエラーバジェットを増やす、という選択肢を取ることもできます。

まとめ

  • サービスの信頼性管理の大部分はリスク管理に関係することであり、リスク管理には多くのコストがかかることがある
  • 信頼性のターゲットとして100%が適切であることはほぼありえない。
  • エラーバジェットは、SREとプロダクト開発者との間でインセンティブを一致させると共に、共同所有ということを強調する