重要な SRE 原則とプラクティス: 好循環
ある意味で "不言実行" が真実となれば、このモジュールの核心にたどり着いたことになります。 このユニットでは、SRE 実践の中心としばしば見なされている 2 つのプラクティスについて見ていきます。 いずれも "好循環" を作ることが重要であるという原則から来ています。ここで言う好循環とは、組織を継続的に改善するフィードバック ループを組織内で作り出すプラクティスのことです。 この 2 つのプラクティスには後続のモジュールが用意されているので、ここでは概要だけ見ておきます。
好循環 #1: SLI と SLO
このモジュールで先に、"適切な信頼性レベル" に向けて取り組むことについてのポイントを強調しました。 その概念が活かされるのはまさにこのセクションです。
運用環境への移行を計画している新しいサービスがあるとします (構築済みのサービスかまだ計画段階にあるサービス)。 その過程の一環として、それに望まれる信頼性についていくつかの決定を行うことが重要です。 コードをすべて自分で記述しない場合、これらの決定はコードを記述する開発者と共同で行われます (このポイントは非常に重要です)。
最初に行う決定は、サービスの正常性の指標として何を使う必要があるか、ということです (Service Level Indicator (SLI: サービス レベル指標))。 または、"サービスが正常に稼働していることを、どのようにして知るか?" という質問にすることもできます。 SLI を追跡する方法は多数あり、後でいくつか詳しく調べます。 ただし、通常は、次のような指標を使います。
- 成功か失敗かの測定。 サービスは、ある程度の時間、操作を正常に完了しているか?
- タイミングの測定。 一定の時間内に回答を返したか?
- スループットの測定。 一定の量のデータを処理したか?
または、これらすべての測定のいくつかの組み合わせ。
簡単な例を挙げると、Microsoft サービスの SLI は、(500 やその他のコードではなく) HTTP 200 コードで示される成功を返した頻度と言えるかもしれません。
これで、サービスの動作状況を示す明確な指標が作成されました。 サービスに予想される、または望まれる信頼性のレベルを決める必要があります。 たとえば、1 日という期間について、サービスの失敗率を 20% と予想しますか? 端数のない大きな数を使用します。最初の段階では説明しやすいからです。 後のモジュールでは、"そのエラー率はどのユーザーに示されるのか、一部のユーザーか、ほとんどのユーザーか?" などのように、ステートメントの複雑さと正確さを高めます。 その期待されるものが、サービスの開発者との共同で作成される、サービス レベル目標 (SLO) です。
SLO は、精確に計測し、監視システムに表示できるものでなければなりません。 サービスの信頼性として、客観的でわかりやすい目標にします。どのくらいの数値で十分でしょうか。 "このサービスはこの 1 週間くらい問題なく稼働していると思うけど、断言するのは難しい" というのはここでは論外です。 サービスがその SLO を満たすかどうかは、データではっきりさせてください。 その SLO を満たしていない場合 (特に、一定期間に繰り返される)、何かに問題があり、対処する必要があります。
エラー予算
サービスが SLO を満たしていない場合、組織は素早く行動に移る可能性があることは理解できます。 しかし、SRE では、SLO を満たしているか上回っている場合まで、この概念全体をさらに一歩進めます。 SLO を利用し、"エラー予算" と呼ばれるものを作る組織があります。
このアイデアを示すために、ここまでの説明に登場したサンプル サービスを利用します。その SLO は 80% 成功です (これは "時間の 80% は稼働していなければならない" と考えてください)。 80% アップタイムの SLO をもって、サービスは時間の 80% は稼働していなければならないと宣言しました。 それでは、残りの 20% はどうなりますか? 残りの 20% でサービスが停止している場合、特に "気にする" ことはありません。サービスの目標で、残りの 20% も稼働することは重要ではないと決定されているためです。
それでは、その間に発生することについて気にしない場合、サービスに関して何ができるでしょうか。 確かにできることの 1 つは、いくつかの機能を追加する新しいリリースなどでアップグレードすることにより、実行中のサービスを揺るがすことです。 その新しいリリースが稼働し、ダウンタイムが増えないようであれば最高です。 その新しいリリースによってサービスの安定性が低下し、デバッグしたとき、さらに時間の 10% でエラーが返される場合、それも良しとします。 許容される信頼性の予算内です。
エラー予算は、サービスの潜在的完全信頼性とその望まれる信頼性の差です (100% - 80% = 20%)。 この場合、エラー予算により、20% の信頼性欠如と、20% の "仕様の範囲内であるから稼働しているかどうか問題にしない" 時間が提供されます。 他の予算と同じように予算が尽きるまで、その 20% の時間は好きなように使うことができます (おそらくはリリースを増やすでしょう)。
また、SLO を作成していないような、満足度の低い一部の組織では、エラー予算も利用されます。 その場合、"措置を講じる" より少しばかり厳しい行動を選択するかもしれません。 サービスに問題があり、先に選択した SLI で示されるように、時間の 60% だけ稼働したとします。 目標 (SLO) は作りませんでした。 サービスはそのエラー予算を使い切っています。 この時点でシステムがさらに不安定になると、おそらく信頼性が低下するだけなので、組織では予定していたリリースを控える場合があります。 通常、エラー予算は、一定の期間、つまり 1 か月や 1 四半期などに対して計算されます。 サービスの信頼性が向上したとき、その予算が戻るように、ローリング基準で計算されます。
組織は、リリースを控える間、機能開発から信頼性作業にエンジニアリング リソースの一部を移すことを選ぶことがあります。 その目的は、SLO を達成できなかったサービス上の問題の原因を探し、改善することです。
エラー予算の話になるとき "一部の組織" と表現する理由は、その実装方法にあります。特に、リリースを控える場合、組織内で何らかの同意を得る必要があります。 組織は、リリースの決定に直面したとき、その時点までのサービスの信頼性に問題があれば、リリースの取りやめを進んで受け入れる必要があります。 すべての組織がそのような決定を進んで行うわけではありません。 この決定はまた、エラー予算の枯渇に対する唯一の応答ではなく、最も議論される応答です。
SLI、SLO、エラー予算については、別のモジュールでさらに詳しく説明します。 しかし、ここでこれらのプラクティスの好循環の側面から強調することには意味があります。 理論上、それは組織がサービスの信頼性を説明し、伝達し、対処するための手段を提供します。 より良い信頼性を目指して皆を働かせるような方法でそれを行います。 このフィードバック ループは非常に重要であることがあります。
好循環 #2: 責めない事後分析
事後分析、つまり、通常は望まれない重大なイベントを遡及的に分析するという考えは、サイト リライアビリティ エンジニアリングだけに固有ではありません。 事業の世界では珍しいことですらありません。 他とは違うことがあるとすれば、SRE では事後分析に "責めないこと" が求められるということです。 特定の人の行動ではなく、問題を起こしたプロセスやテクノロジの失敗に集中的に取り組む必要があります。 "X が失敗に至る原因になったことを、講じたプロセスはどうだったか。 間違った結論が導かれたとき、その担当者はどのような情報が利用できなかったのか。あるいは、どのような情報が目立っていたのか。 そのような壊滅的な障害が起こらないようにするには、どのようなガードレールを設ける必要があったのか?" このような質問は、責めない事後分析で行われるものです。
こうした質問の質と方向が非常に重要です。 システムまたはプロセスを改善するための方法を模索するものであり、よかれと思ってした行動でシステムまたはプロセスの停止を引き起こした個人を罰するためのものではありません。 "誰かを解雇しても信頼は得られない" ということを覚えておいてください。 経験では、(わずかな例外はありますが) 運用環境で問題が発生するたびに人を解雇する組織はその問題から何も学びません。 代わりに、ひとりの人間が置き去りにされ、隅っこで震え、何らかの変更を行うことを恐れるようになります。
しかしながら、組織で事後分析プロセスを正しく機能させると好循環が生まれます。 組織はダウンタイムから学び、そのシステムを継続的に改善できます (適切な分析と事後処理が行われるなら)。
障害やエラーとこのように付き合うこと、つまり、組織が失敗を学習と改善のための機会と捉えることが、サイト リライアビリティ エンジニアリングの中心的原則です。 好循環を作り、機会を活かし、組織の信頼性を上げる方向に導くことがもう 1 つの中心的原則です。
次のユニットでは、SRE の人間側を中心とする、他の原則とプラクティスについていくつか確認します。