コンテンツに移動
Google Cloud

エスカレーション ポリシーの適用 : CRE が現場で学んだこと

2018年2月26日
Google Cloud Japan Team

過去の投稿では、サービス レベル目標(SLO)違反のエスカレーション方法を示した明確なポリシー文書を作成することの重要性と、Google の SRE チームによる実際の文書例について説明しました。このテーマの最終回となる今回は、エスカレーション ポリシーを適用する仮定のシナリオをいくつか用意し、エッジ ケースとして紹介します。

以下に示すシナリオは、すべてスリー ナイン(99.9 %)の可用性の SLO が設定されたサービスのもので、エラー バジェットの半分はバックグラウンドのエラーで消費されることを想定しています。つまり、エラー バジェットは 0.1 % で、0.05 % のエラーで稼働している状態は「正常」となります。

最初に、ポリシーの基準値をおさらいしておきます。

  • 基準値 1 : SLO が影響を受ける可能性があると SRE に通知される。
  • 基準値 2 : SLO を保つには支援が必要だと SRE が判断し、開発者にエスカレーションする。
  • 基準値 3 : 30 日間のエラー バジェットが消費されたものの根本的原因が判明していない。SRE はリリースを停止し、さらなるサポートを開発チームに要請する。
  • 基準値 4 : 90 日間のエラー バジェットが消費されたものの根本的原因が判明していない。SRE は、より多くの開発時間を信頼性向上に充ててもらうよう、幹部にエスカレーションする。

上記を念頭に、SLO 違反を詳しく掘り下げてみましょう。

シナリオ 1 : 短時間だが重大な障害が根本的原因となり、すぐに依存関係の問題が発生した


状況 : 重要な依存関係を誤ってプッシュしてしまい、その依存関係を担当するチームが当該リリースをロールバックする間、サービスの 50 % が 1 時間停止しました。ロールバックが完了するとエラー率は以前のレベルに戻り、チームは根本的原因となる要因を特定して元に戻します。依存関係を担当するチームが事後分析を作成しますが、再発防止に向けてやるべきことについては、一部サービスを担当する SRE が作成に協力します。

エラー バジェット : 可用性がスリー ナインのサービスの場合、今回の障害だけで 30 日間のエラー バジェットのうち 70 % を消費したことになります。7 日間のエラー バジェットは上回っており、バックグラウンドのエラーも考慮すると 30 日間のエラー バジェットも超えたことになります。

エスカレーション : 本番への影響に対処するよう SRE に通知されます(基準値 1)。この一連の問題(設定ミスまたはバイナリ プッシュ)が発生することはまれであるか、問題は適切に収拾したと SRE が判断した場合、サービスは SLO の規定内に戻され、ポリシーとしては他にエスカレーションする必要はないと判断されます。これは意図的なものです。ポリシーでは開発速度をこれ以上ないほど重視しており、単に 30 日間のエラー バジェットを消費したからといってリリースを止めてしまうのはポリシーに反するのです。

問題が何度も再発する場合(たとえば 2 週間連続で発生し、四半期分のエラー バジェットの大半を消費するような場合)や、再発の可能性があるとの判断が下った場合は、基準値 2 または 3 へとエスカレーションします。

シナリオ 2 : 短時間だが重大な障害が発生し、根本的原因がはっきりしない


状況 : 1 時間にわたってサービスが 50 % 停止し、その原因はわかっていません。

エラー バジェット : シナリオ 1 と同様、7 日間および 30 日間のエラー バジェットを超えました。

エスカレーション : 本番環境への影響に対処するよう SRE に通知がなされ(基準値 1)、それを受け取った SRE は迅速に開発チームにエスカレーションします。SRE は、問題をより明確に可視化するために新たな測定基準を要求し、フォールバック アラートをインストールすることもあります。また、SRE とオンコールの開発担当者は翌週に向け、問題の調査を優先します(基準値 2)。

引き続き根本的原因がはっきりしない場合、SRE は障害の 1 週目以降、30 日間の SLO 測定枠が過ぎ去るまで機能リリースを停止します。他のプロジェクトを進めている SRE と開発チーム担当者がさらに招集され、デバッグや障害の再現を試みます。サービスが SLO 規定内に収まるか根本的原因が見つかるまでは、それが彼らの最優先事項となります。

調査が進むと、SRE と開発チームは事態収拾や回避策、多重防御に向けた取り組みを始めす。理想としては、今後同様の障害が発生したとしても、根本的原因を見つけるのが今回ほど難しくなく、今回ほどの影響も出ることはないと SRE が自信を持って言えるようにしておきましょう。そうなれば、根本的原因がまだわかっていなくても、リリースのプッシュ配信を再開できることになります。

シナリオ 3 : 誤った根本的原因により、エラー バジェットが徐々に消費される


状況 : ある特定の時刻 T に、以前のバージョンにはなかったバグが本番環境に入り込み、サービスが 0.15 % のエラーを出すようになりました。数週間経っても、SRE も開発者もその根本的原因がわかりません。さまざまな修正を試みるものの、影響は収まりません。

エラー バジェット : このまま解決しなければ、1 か月の間に 1.5 か月分のエラー バジェットを消費することになります。

エスカレーション : 発生時刻 T から約 5 日後、7 日間のエラー バジェットが消費されたため、オンコールの SRE 担当者にチケットが送信されます。SRE は基準値 2 を発動し、時刻 T から約 7 日後に開発チームへとエスカレーションします。CPU 使用率の増加と関連があることから、SRE とオンコール担当の開発者はエラーの根本的原因がパフォーマンスのデグレードにあると推測します。オンコールの開発者がシンプルな最適化を見つけ出して送信し、時刻 T から 16 日後に通常のリリース手順の一部として本番環境に提供します。その修正で問題が解決されるわけではないのですが、今となっては、影響を受けたサービスに対して日々のコード リリースを 2 週間分ロールバックするのも現実的ではありません。

時刻 T から 20 日後、サービスが 30 日間のエラー バジェットを超えたため、基準値 3 が発動されます。SRE はリリースを停止し、開発者にさらに真摯に対応してもらうべくエスカレーションします。開発チーム側も、開発者 2 人と SRE 1 人による担当グループを設けることに同意します。担当グループは問題の根本的原因を見つけ出して修復することを最優先とします。

コードの変更と不具合との間に適切な関連性を見いだせないため、担当グループは詳細にパフォーマンスを分析し、ボトルネックを順に排除します。修正はすべて現在の本番リリース上で週 1 回のパッチとして集約されます。サービスは顕著に効率化されますが、それでもエラー率は上昇します。

時刻 T から 60 日後、サービスが 90 日間のエラー バジェットを消費し、基準値 4 が発動されます。SRE は幹部にエスカレーションし、信頼性が欠如している状況が継続していることに対して相当な開発作業が必要だと訴えます。開発チームは問題を深く掘り下げ、アーキテクチャに不具合を発見し、最終的にサーバーとクライアント間におけるエッジケース インタラクションの停止機能を再実装します。エラー率は以前の状態に戻り、リリースを再度開始した段階で停止機能をバッチでロールアウトします。

シナリオ 4 : 繰り返し発生する、一時的なサービス レベル指標(SLI)の逸脱


状況 : 日々または週ごとのバイナリ リリースにより、そのつど一時的なエラーが急増しています。

エラー バジェット : エラーが長期的に SLO を脅かすことがない場合、SRE は責任を持ってアラートを適切に調整しておく必要があります。そこで、このシナリオではエラーが急増しても、SLO が数時間にわたって脅かされることはないと仮定します。

エスカレーション : SLO を基にしたアラートによってまず SRE に通知され、ゆっくりとエラー バジェットが消費される場合と同様のエスカレーション手法が採られます。ここでは、リリースとリリースとの間に SLI が正常に戻ったからといって、それで問題が「解決された」と捉えないようにしてください。というのも、サービスを SLO の規定内に収めるための基準はそれより高く設定されているためです。SRE は、エラー バジェットの消費が長くなったり速くなったりしたときにページャーを鳴らすようアラートを調整してもいいですし、継続的に実施しているサービスの信頼性向上に向けた作業の一環として問題を調査してもいいかもしれません。

まとめ


どんなエスカレーション ポリシーにおいても、仮定のシナリオで「軍事演習」を行い、予期しないエッジ ケースがないか、またポリシーの言葉が明確になっているかを確認しておきましょう。ポリシーの下書きをいろんな人に回覧し、そこで上がってきた懸念事項を付録に記載してください。ただし、あるインフレクション ポイント(変曲点)を正当化するためにポリシーそのものを乱さないようにしましょう。提案したポリシーに対して同僚から異論があった場合は、さらに議論を進める心構えでいてください。

ここで紹介したポリシーは単なる一例にすぎません。高い可用性を実現しようとする実際の SRE チームは、大きく異なるエスカレーション ポリシーを作成している可能性が高いことを忘れないでください。

* この投稿は米国時間 2 月 8 日、Site Reliability Engineer の Will Tipton と、Customer Reliability Engineer の Alex Bramley によって投稿されたもの(投稿はこちら)の抄訳です。

- By Will Tipton, Site Reliability Engineer and Alex Bramley, Customer Reliability Engineer

投稿先