SLO 違反への対処 : CRE が現場で学んだこと

サービスの可用性を数値化することの重要性については、この『CRE が現場で学んだこと』シリーズの過去記事で詳しく解説しました。機能開発に注力している開発チームと信頼性に注力している SRE チームとの間で勃発する優先順位に関する戦いを、サービス レベル目標（SLO）を使って管理する方法についても、すでに紹介済みです。

SLO がしっかりしていれば、組織内での摩擦を軽減でき、信頼性を損なうことなく開発スピードを保つことも可能です。しかし、SLO を満たすことができなかった場合はどうすればよいのでしょうか。

今回のブログ記事では、SLO 違反への SRE チームおよび開発チームの対処を示すポリシーの重要性を解説するとともに、ポリシーの構成と内容について提案します。また、Google の SRE チームでの事例とポリシーの施行に至ったシナリオについても、次回以降の記事で検証します。

機能 vs. 信頼性

真の開発組織であれば、たいていはビジネスの優先順位に従って、この 2 つの領域に対する労力の割き方を変えるものです。SLO の規定内でサービスが稼働していたとしても、積極的に信頼性を向上させることは、障害の将来的なリスクを抑え、効率性を改善し、そしてコスト削減につながります。一方、SLO を満たしていないからといって、すぐに内部での機能開発を完全にやめてしまう組織はほとんどありません。

この領域の主なインフレクション ポイント（変曲点）をポリシーの形で文書化しておくことは、SRE チームと開発チームのパートナーシップにおいて重要なことです。これにより、（すぐにでも起こりうる）SLO 違反の際に自分が何を求められているのかについて、組織全体でだいたい同じ認識を得ることができるはずです。

また、何よりも重要な点として、対応しなかった場合はどんな結果が待ち受けているのかを全員が明確に把握できます。インフレクション ポイントと帰結をどこに持っていくかは、組織や事業の優先度によって異なります。

インフレクション ポイント

また、違反への対応もそれぞれ異なり、その際に判定を行うのは SRE の仕事となります。ただし、考えられる対応が異なりすぎると結果もばらばらになり、システムを試してみようとする人が出てきたり、開発組織としての疑念が生まれたりします。

エスカレーションのポリシーに関しては、SLO 違反を重要度に応じていくつかのグループに分けておくことをお勧めします。重要度は、時間とともに積み重なっていく影響度によって決まります（つまり、どのくらいの期間にどの程度エラー バジェットを消費したのかということです）。

分類後のグループの境界線は、はっきりと定義しておかなくてはなりません。正当な理由がグループ分けの背景にあると便利ですが、それはメインのポリシーとは別に付録などに記載しておきましょう。ポリシーそのものを明確にするためです。

このグループ分けの境界線と SLO ベースのアラートを、少なくとも一部は結びつけておくとよいでしょう。たとえば、過去 1 時間にエラー バジェット 1 週間分の 10 % を消費するようだったら SRE を呼び出して調査する、といった具合です。

これは、インフレクション ポイントと結果が結びついている 1 つの例です。これにより、非公式に名づけた「誰かを呼び出さなければならないほどエラー バジェットは消費されていない」グループと、「長期的な SLO から外れてしまう前にサービスを今すぐ調査すべき」グループとの線引きができるようになります。次回の記事では、Google の SRE チームのポリシーを紹介しつつ、より具体的な事例を検証します。

SLO 違反がもたらすもの

SLO 違反の可能性や実際の違反を通知する
SLO 違反の可能性があったり実際に違反したりしたときに、最も一般的な結果として考えられるのは、監視システムが人間に対して調査や処置が必要だと通知することでしょう。

SRE がサポートしている成熟したサービスの場合、短期間にエラー バジェットが大量に消費されたときにはオンコール担当者のページャーに通知されますし、長い期間にわたってエラー バジェットが上昇しているときはチケットが発行されます。ページャーへの通知と同時にチケットを発行してデバッグの詳細を記録し、深刻な違反をエスカレーションする際は、チケットを情報伝達の場や参照として使うのがよいかもしれません。

また、関連する開発チームにも知らせましょう。このプロセスは手動でもかまいません。SRE チームは違反をフィルターにかけて集約し、意味のあるコンテキストを提供するなど価値を付け加えることも可能です。

ただ理想としては、実際に違反が発生したときには開発チームの上層部の一部にも自動的に通知されるようにしておくべきです（たとえば、どんなチケットでも上層部に CC を入れるなど）。そうすれば上層部はエスカレーションが発生しても驚きませんし、送られてきたチケットに適切な情報が含まれていれば議論に加わることもできます。

開発チームに SLO 違反をエスカレーションする
通知とエスカレーションの主な違いは開発チームに求められる対応です。SLO 違反が深刻な場合、たいていは SRE と開発者が密に協力して根本的原因を突き止め、再発防止策を講じるよう求められます。

エスカレーションは敗北を認めることではありません。SRE としては、開発チームの情報を検討し、解決までの時間が大幅に削減できるとある程度確信した段階で、すぐにエスカレーションするべきです。ただしポリシーには、SLO 違反（またはほぼ違反）が生じたときの猶予時間（エスカレーションせずに粘る時間）の上限を設けておきましょう。

もっとも、エスカレーションしたからといって、違反に対する SRE の仕事が終わったわけではありません。ポリシーにはそれぞれのチームの責任と、原因の調査や修復に費やす開発時間の量の下限を記載しておくべきです。またエスカレーションのレベルとしては、上層部のサポートが必要なレベルから、サービスの信頼性が戻るまで全開発チームの開発時間を使うといったレベルまでを含め、複数記載しておくと便利です。

サービス変更のリスク軽減で、SLO にさらなる影響を与える
エンドユーザーは定義上、SLO を満たしていないサービスには満足しません。そのため、エラー バジェットの消費率を増やすような日々の運用については、減速させるか完全にやめてしまいましょう。これは一般的に、バイナリのリリースや実験の頻度を制限するか、もしくは SLO が再度満たされるまでリリースを完全にやめるという意味です。

これについては、（SRE、開発部門、QA / テスト部門、プロダクト部門、幹部など）関係者全員がポリシーに合意しておくべき部分です。一部の開発チームは、SLO 違反によって開発やリリースのスピードに影響が及ぶことを受け入れがたいと感じるかもしれませんが、リリースをいつどのようにやめるのか、またこのようなことが起こった際にどの程度の人数のエンジニアが信頼回復に向けた仕事に取り組むのかを文書で合意しておくことが主な目的です。

サービスのサポートを取り消す
決められた SLO をどうしても満たすことができず、そのサービスの責任者である開発チームが、信頼性の改善に向けた開発への取り組みに後ろ向きだとしましょう。Google の SRE チームの場合、そうしたケースでは、稼働中のサービスの運用担当から手を引くことができるようになっています。これは、1 回の SLO 違反の結果というよりも、長きにわたって深刻な障害が何度も発生した結果として手を引くということです。

Google ではこれがうまく機能しています。開発の周辺においては、信頼性に対するインセンティブが変わってくるためです。サービスの信頼性を無視する開発チームはその結果を背負うことになる、ということがわかっているのです。

定義上、サービスから SRE のサポートを外すのは最後の手段ですが、そうなる条件を記載しておくことは、口先だけの脅しではなくポリシーとして当然のことです。開発チームがサービスの信頼性なんかどうでもいいと思っているのであれば、SRE が信頼性を気にしなければならない理由はどこにもありません。

まとめ

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

- By Alex Bramley, Customer Reliability Engineer