Google Cloud

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

2018年2月6日

Google Cloud Japan Team

前回のブログ記事では、信頼性と機能開発の間で生じる技術的な苦労や、サービスレベル目標（SLO）が満たされていないサービスに対して、企業はいつどうやってエンジニアの時間を信頼性向上に費やすよう決断すべきかについてお話ししました。今回は、SLO のエスカレーションポリシー（一部編集済み）と、それに関連する Google の SRE チームによる論理的根拠を解説し、開発速度の迅速さを保つために SRE と開発の各チームがどこに妥協点を置いているのかを紹介します。

この SRE チームでは、サービススタックのさまざまな領域に注力する大規模な開発チームと連携しています。そのスタックには、トラフィックの多いサービスが約 10 件、比較的小規模なサービスが 10 数件含まれており、すべて SRE チームがサポートしています。チームは欧州と米国に分かれており、それぞれの地域で日中オンコール担当となるように 12 時間ごとのローテーションを組んでいます。

サポート対象のサービスには、求められるユーザーエクスペリエンスを示すざっくりとしたトップレベルの SLO と、スタックのコンポーネントにおける可用性の要件を示す詳細な SLO が設定されています。重要なこととして、SRE チームは呼び出しがかかった際に、それぞれの SLO の粒度に応じて開発チームに担当を引き継ぐことが可能であり、SLO に対する「サポートの取り消し」を安価かつ迅速にできるようになっています。

アラートの設定については、サービスが 1 時間の間に 9 時間分のエラーバジェットを消費するとページャーが鳴るようになっています。また、前週に 1 週間分のエラーバジェットを消費した場合はチケットが発行されます。

なお、ここでのエスカレーションポリシーは単なる一例だという点に留意してください。しかも、もし 99.99 % 以上の可用性を目標としたサービスを SRE チームがサポートしている場合は、あまり良い例ではないと考えられます。この Google チームが担当している業界は非常に競争が激しく動きも速いため、高可用性の維持よりも、機能のイテレーションスピードや市場投入までの時間を重要視しているのです。

エスカレーションポリシーの目的

エスカレーションポリシーの詳細に入る前に、以下の点を検討する必要があります。

まず、エスカレーションポリシーは何かを完全に禁止するためのものではありません。直面した状況に適切に対応するための判断が SRE には求められるため、特定の行動を取るにあたっての妥当な基準値を設定し、想定される対応の幅を縮小して一貫した基準内で対応できるようにすることが、エスカレーションポリシーの目的となります。ポリシーにはさまざまな基準値が設定されており、その基準値を超えたときは、SLO 違反に対処するべくエンジニアの労力を注ぎ込みます。

また SRE は、インシデントが解決したと宣言する前に、一連の問題を修復するよう注力しなくてはなりません。これは、問題そのものを修復するよりも大変なことです。

たとえば、悪いフラグフリップによって深刻な障害が発生した場合、フラグフリップを取り消すだけではサービスを SLO の規定内に戻せません。そこで SRE は、段階的なロールアウトや、プッシュ失敗時の自動ロールバック、フラグとバイナリのバージョンを結びつける設定へのバージョニングなどにより、今後フラグフリップによって SLO が脅かされることがないようにする必要があります。

後述するエスカレーションポリシーの 4 つの基準値において、「サービスを SLO の規定内に戻す」ということは、以下のいずれかの状態を指します。

根本的原因を突き止め、関連する一連の問題を修復する
自動修復によって手作業による介入が必要なくなった
一連の問題が、今後その発生頻度や深刻度によって将来的に SLO を脅かす可能性が極めて低い場合は、とりあえず 1 週間待つ

つまり、手作業で修復する計画を立てたとしても、それだけではサービスを SLO の規定内に戻すには不十分なのです。SLO 違反の根本的原因については、今後違反が発生する可能性や自動修復の有無といった面から理解しておかなくてはなりません。

エスカレーションポリシーの基準値

基準値 1 : SLO が影響を受ける可能性があると SRE に通知される
SRE は、サポート対象の SLO に危機が迫ると通知されるように警戒態勢を維持します。そして通知が来ると、SRE は調査を行って根本的原因を見つけ出し、それに対処するようにします。また、ロードバランサでトラフィックをリダイレクトしたり、バイナリをロールバックしたり、設定をプッシュしたりと、状況緩和に向けた対応を検討します。

SRE のオンコール担当エンジニアは、SLO への影響を開発チームに通知し、必要に応じて開発チームに最新情報を提供するようにしますが、この段階で開発チームが何らかの対策を講じる必要はありません。

基準値 2 : SRE が開発者にエスカレーションする
次の状況に当てはまるかどうかを判断します。

支援がなければサービスの SLO を保つことは困難だと SRE が判断した
求められるユーザーエクスペリエンスを SLO が表していることを、SRE と開発の両チームとも認めている

すべてに当てはまる場合は、次のような対応が考えられます。

SRE と開発チームのオンコール担当者は根本的原因の修復を優先し、バグを日々更新する
SRE が開発チームのリーダーにエスカレーションし、必要に応じて可視化や追加の支援を要請する
既知の問題に対して継続的に呼び出しがかかるのを避けるため、アラートの基準値を緩める一方で、さらなる不具合に対しては引き続き対策を講じる

サービスが SLO の規定内に戻った場合は、次のことが想定されます。

SRE がアラートの変更を元に戻す
SRE が事後報告を作成することもある
求められるユーザーエクスペリエンスを SLO が正確に表していない場合、SRE、開発チーム、プロダクトチームは SLO を変更もしくは撤回することに同意する

基準値 3 : SRE が機能リリースを一時的に停止させ、信頼性向上に努める
次の状況に当てはまるかどうかを判断します。

最低でも 1 週間は以前の基準値を満たしている
サービスはまだ SLO の規定内に戻っていない
30 日分のエラーバジェットを使い切った

すべてに当てはまる場合は、翌週は次のような対応が考えられます。

根本的原因が判明した不具合を対象に、入念にチェックした修正パッチのみを本番環境にプッシュしてみる
SRE が自分の上司や開発チームのマネージャーにエスカレーションし、緊急でない仕事はすべて後回しにして根本的原因を探し出し修復するように開発メンバーに依頼する
日々の更新を “エスカレーション” のメーリングリストとして発信してみる（幹部を含め、さまざまな人員に障害の情報を知らせるため）

サービスが SLO の規定内に戻った場合は、次のことが想定されます。

通常のバイナリリリースを再開する
SRE が事後報告を作成する
チームメンバーが再び通常のプロジェクトを優先することも可能になる

基準値 4 : SRE が幹部にエスカレーションする、またはサポートをやめる
次の状況に当てはまるかどうかを判断します。

最低でも 1 週間は以前の基準値を満たしている
サービスはまだ SLO の規定内に戻っていない
90 日分のエラーバジェットを使い切ったか、機能開発を中止して信頼性の回復に努めることを開発チームが拒否している

すべてに当てはまる場合は、次のような対応が考えられます。

問題解決に専念する人員を増やすため、SRE が幹部にエスカレーションする可能性がある
SRE が SLO やサービスのサポートを取りやめ、関連するアラートをリダイレクトしたり停止したりすることもある

エスカレーションとインシデントレスポンス

SRE は最初のレスポンダーです。開発者にエスカレーションする前に、サービスが SLO の規定内に戻るよう手を尽くすことが SRE には求められます。そのため、7 日分のエラーバジェットが消費されたことを示す 1 週間のチケットアラートにかかわらず、SRE チームに SLO 違反が通知されると基準値 1 を適用します。SRE は開発者へのエスカレーションを、通知を受けてから 1 週間以上先に延ばすべきではありませんが、この段階でのエスカレーションが適切かどうかは、SRE が独自に判断してもかまいません。

SRE によるエスカレーションの際は、可用性の目標値が信頼性と開発速度との望ましいバランスを保っていることを開発者に必ず確認するようにしてください。こうすることで開発者は、新機能をロールバックして可用性の目標値を維持するほうがよいのか、それとも一時的に目標値を緩和して新機能をリリースするほうが望ましいのかを検討できます。

短期間に同様の SLO 違反が繰り返し発生した場合は、何度も考える必要はありません。ただ、こうした状況はさらにエスカレーションが必要だという強力なサインでもあります。開発者が以前合意した可用性の目標値を復帰させることに意欲を見せるまで、開発者に再度そのサービスのページャー担当になってもらうよう主張してもかまいません。開発者が一時的にサービスの信頼性を下げ、ビジネスに重要な機能を提供しつつ信頼性回復に取り組みたい場合も、障害の負担を肩代わりすることができます。

リリースの停止

機能リリースの停止が適切な処置である理由は、主に以下の 3 点です。

一般に、安定した状態で最もエラーバジェットが消費されるのはリリースのプッシュ配信時です。すでにエラーバジェットを使い切っている場合、新たなリリース配信をやめてしまえば、安定した状態でのバジェット消費率が下がり、サービスをより迅速に SLO 規定内に戻すことができます。
リリースの停止により、新たなコード内のバグが原因で今後予期しない SLO 違反が発生するリスクを抑えることができます。根本的原因の修復パッチを新リリースに対してロールアウトするのではなく、現在のリリースに適用すべきなのは、これが理由です。
リリースの停止は制裁処置ではないものの、開発チームにとって非常に気になるリリース速度に直接影響を及ぼします。つまり、SLO 違反と開発速度の低下を結びつけることで、SRE と開発チーム双方のインセンティブにつながるのです。SRE はサービスを SLO の規定内に収めることを望みますが、それに対して開発チームは新機能を迅速に構築したいと考えます。この 2 つは同時に実現するか、双方とも実現しないかのどちらかです。

SLO 違反の根本的原因が特定され修復されたら、SRE は機能リリースの停止を早めに解除することを検討すべきです。SLO が 30 日間の枠内における規定を満たし、今後はサービス低下は起こらないとする開発チームを大目に見ることで、より妥当な信頼性と開発速度のバランスが保てるようになります。

これは、サービスが基準を満たす前に、妥当な時間枠内に収まるだろうと想定して今後のエラーバジェットを効果的に「借り」つつ、リリースを解禁するということです。プッシュ関連の障害がなければ、新機能によってユーザーのサービスに対する評価は向上し、SLO 違反で低下した満足度を回復できるはずです。

SLO 違反の発生前にエラーバジェットの消費率が SLO の基準値に近づいている場合、SRE はリリースの再開をやめることも可能です。こうしたケースでは前借りできるバジェットが少なく、今後 SLO 違反が起こる危険性も高くなり、リリースが許可され続けたときはサービスが SLO の規定内に戻るまでの時間も長くなります。

まとめ

本稿で紹介したエスカレーションポリシーの例が、サービスの信頼性とビジネス優先度の高い開発速度との妥協点を決めるうえでお役に立てば幸いです。開発速度に対する主な譲歩点としては、SLO に違反したからといって SRE はすぐにリリースを停止せず、SRE との合意に従い SLO が規定内に戻る前に再開のメカニズムを提供することです。

このシリーズの最終回では、今回紹介したポリシーの基準値を仮定シナリオに当てはめてみたいと思います。

* この投稿は米国時間 1 月 19 日、Customer Reliability Engineer である Alex Bramley と、Site Reliability Engineer である Will Tipton によって投稿されたもの（投稿はこちら）の抄訳です。

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

投稿先