エラーバジェットという考え方が素晴らしい

投稿日:
SRE

SRE本買いました

まだ早いかなと思ったのですが、 DevOps/SREを主軸に据えていくと決めたので、思い立ったが吉日ということで。


SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

DevOpsとSREの違い

この本では以下のように書かれています。 DevOpsの方がどちらかと言えば広い、あるいは曖昧で、 SREの方が狭い、あるいはきっちりしている感じでしょうか。

その中核となるのは、(中略)これらはSREの方針やプラクティスの多くとも一致します。 DevOpsは、SREの中核的な方針のいくつかを、幅広い組織、管理の構造、個人に対して一般化したものと捉えることもできるでしょう。 同様に、SREをDevOpsに独特の拡張を少し加えたプラクティスと捉えることもできるでしょう。

エラーバジェット

で、タイトルのエラーバジェット。 バジェットは「予算」という意味です。

まだ読み始めましたが、この概念が素晴らしいです。

可用性のターゲットは、SLAというもので定義されています。 例えば、Amazon EC2(この本はGoogleですが)のSLAは以下に記載されている通り、 99.99%です。

Compute Service Level Agreement

99.99%の可用性がどれくらいかというと、1年間の動作不能時間が52分34秒ということです。 これを逆に考えて、52分34秒までは障害が起きても構わないとみなすのがエラーバジェットです。

もっとも、単に障害を起こしても意味がない(障害のリカバリーテストは別としても)ので、 エラーバジェットの時間は新サービスの提供などの「攻めのための時間」として使うのが理想です。 いくら安定稼働していても、新しいサービスが提供できないとダメですから。

ドラッカー的には「変化のマネジメント」ですね。 変化を恐れるのではなく、かといって意味もなく変化するのではなく、 自ら目的を持って変化を起こすことが重要です。

次の記事:
自分のやろうとしてたことがJAMstackと呼ばれているのを知った
前の記事:
ニュースを見ない生活: ニュースを見ないと困る?