これでよいのか: SRE チームの成熟度評価について考える
Google Cloud Japan Team
※この投稿は米国時間 2021 年 6 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。
Google の顧客信頼性エンジニアは、Google Cloud のお客様の組織で実践を支援するよう選任された、Google サイト信頼性エンジニア（SRE）です。その仕事の一つに、運用の成熟度を高めるために行う経営陣や SRE チームへのアドバイスがあります。Google はそのディスカッションの多くで、「今やっていることは『SRE の仕事』でしょうか？」あるいは、もう少し実存的不安の響きがする「自分たちを SRE と呼んでもいいでしょうか？」という質問を何度も受けています。
この質問には、すでに、SRE ワークブックの実践リストで答えています。しかし、このリストは「SRE とは何か」については詳しいですが、その理由について詳しく述べていないため、SRE とは何かという点で悩んでいる方にとっては、理解しづらいかもしれません。そこで、SRE チーム運営の基礎となるいくつかの原理を説明することで、ある程度答えになればと考えています。また、これらの原理がなぜ重要なのかを説明し、チームがどの程度まで原理を具現化できているかを明らかにする問いを記載しています。
これでよいのでしょうか？
この質問は、さまざまな目的で、さまざまな意味合いで問いかけられます。そして、お客様の運用環境が多種多様であるため、答えることが困難です。また、CRE も Google も、お客様の組織の「SRE」が何であるか、何でないかを決定できるわけではありません。絶対的な答えがあったとしても、それを Google が決めることはできません。できることは、個別に、または書籍やブログ投稿を通じて、Google の考え方や経験を示し、組織や大きなコミュニティに影響を与えることだけです。
また、「SRE」という用語は次の 3 つのどれも指すように使われるため、ディスカッションが混乱しがちです。
主にサービスまたは製品の信頼性維持にフォーカスする職務
通常、上記の職務として組織内で勤務する人々のグループ
サービスの信頼性を向上させるために上述の職務の人々が利用できる原理と実践のセット
「自分たちを SRE と呼んでもいいでしょうか？」という質問は、この 3 つの定義を結び付けたいという意味かもしれません。つまり、「このグループは、この職務を SRE と呼ぶために必要な原理と実践の適用において十分なレベルに達しているでしょうか？」という意味かもしれません。
ここで強調したいこととして、SRE として認められるための原理と実践を利用する前に、職務（またはチーム）を明確に定義する必要があるというわけではありません。職務とチームは、組織の成長に合わせて、流動的な担当範囲から自然と決定されていくものです。しかし、このプロセスが続く中で、当事者は自分の担当範囲がわからなくなり、突然、「これでよいのだろうか？」と不安になるのでしょう。実存的不安感が漂う口調は、ここから来ているのかもしれません。
主要な SRE のインジケーター
Google Cloud の CRE チームでは、「これでよいのでしょうか？」という質問によって、SRE チームを導く中核的な原理に関してさまざまな考え方があることが表面化しました。その中で大まかな合意をまとめあげました。ただし条件が 1 つあります。この質問への答えは、サポートするサービスに対するチームのエンゲージメントによって異なります。
この投稿では、主に「本番環境のサービスを直接サポートする」SRE として働く人が従うべき原理を中心にご説明します。リトマス試験と同様、厳密に正確というわけではありませんが、少なくとも Google では、後述の原理のほとんどに従っていれば、そのチームは「サイト信頼性エンジニアリング」と認められる行動を取っていると考えます。
直接的なエンゲージメントの SRE チームは、通常、サービスの信頼性に関する「説明責任者」（RACI 用語）とみなされ、SRE と開発チームとで「実行責任」を共有します。チームのサポートが直接的でなくなるほど、これらのインジケーターは当てはまらなくなります。そのようなチームも、それぞれの条件下で、こうした原理を適用できるでしょう。
適用方法を示すために、原理ごとに、アドバイザーとして機能する SRE チームによる反例を示します。このチームは問題の専門家で、開発チームへの「助言者」です。サービスの信頼性に関する「実行責任者」および「説明責任者」は、開発チーム自身です。
エンゲージメント モデルがこの範囲にある場合、サービスの信頼性に関して合同で責任を負う、または信頼性の問題の専門家であると組織の他部門から認められていることが、SRE であることを示す主要なインジケーターになります。
原理 1: SRE は現在および「将来」のインシデントを軽減する
この原理は、通常、サービスの信頼性に関する実行責任と説明責任を認める基礎となります。世界中の慎重なエンジニアリングとアクティブな統制をもってしても、信頼性の保証はできません。これは特に、複雑な分散型システムで当てはまり、予期しない不具合が生じて、対応、軽減、修正の必要に迫られることがよくあります。SRE は、このような場合に、サービスを迅速に復旧させる権限と技術を持ちます。
しかし、すぐに対応が必要な問題を軽減させるだけでは不十分です。同じことが明日も起こる可能性がある場合、明日になれば今日よりも状況が良くなるわけではありません。SRE はインシデントを引き起こす要因を調べ、担当するインフラストラクチャの問題を全体的に修正できる変更を提案する必要があります。来月、また同じことを繰り返すわけにはいきません。
自社のサービス停止の独自性はどの程度か。次の質問について考えてみましょう。
開発チームのスペシャリストの知識なしで、インシデントの多くを軽減できるか。
自分たちでトレーニング資料と実践的なインシデント対応シナリオを管理しているか。
大規模なサービス停止が発生した後、主要な関係者として、実際に何が悪かったか、将来の停止を防ぐにはどうしたらよいかを正しく解明することができるか。
反例を見てみましょう。多くの組織では、SRE は希少なリソースで、インシデント対応に集中するのではなく、プラットフォームやベスト プラクティスの開発を通じて企業の業務を広く改善します。つまり、助言する SRE チームは、広範囲なサービス停止のインシデント対応の調整に呼ばれることはあっても、ほとんどのインシデントの軽減には直接関わりません。トレーニング資料や事後検証を作成するのではなく、アドバイスする対象のチームが作成した資料のレビューを担当します。
原理 2: SRE は、サービスの信頼性をアクティブに統制する
信頼性の目標とフィードバック シグナルは、SRE の作業の動機付けとなり、開発作業の優先度に影響を与える基礎です。Google では、信頼性の目標を「サービスレベル目標」と呼び、フィードバック シグナルを「エラー バジェット」と呼びます。これらの使用方法については、サイト信頼性ワークブックをご覧ください。
信頼性のシグナルは組織の優先度に影響を与えるか。次の質問について考えてみましょう。
サポートするサービスの信頼性の目標について、組織と合意しているか。この目標を基準にして、パフォーマンスをリアルタイムで追跡しているか。
最近のサービスの信頼性に基づいて組織の行動を調整するフィードバック ループが確立されているか。
信頼性の目標を達成するために、組織を変化させる影響力があるか。
サービスの信頼性に関して現在の目標を満たせなくなる変更を求められたときに、より低くなった目標を拒否または交渉する行為主体性があるか。それぞれの質問の基礎は、最後の質問にあります。明確に定義された測定可能な信頼性の目標がなければ、データドリブン型のフィードバック ループを構築することはほぼ不可能です。こうした目標を意味のあるものにするには、SRE が目標を保護できる必要があります。サービスの信頼性が低い期間があると、将来の本番環境変更の総リスクを一時的に減らし、エンジニアリングの優先度を信頼性にシフトさせることになります。
サービスの信頼性を犠牲にして、信頼性の低い新機能をロールアウトするよう求められたときに、SRE は拒否できなければなりません。これは、データドリブンで決定する必要があります。エラー バジェットに十分な余裕がない場合、ユーザーの不利益を正当化できるだけのビジネス上の理由が必要です。もちろん、そのような理由が存在することもあります。その場合は信頼性の要件を緩め、以前よりも低い、新しい SLO 目標を使用できます。
これに対し、助言する SRE は、チームによる信頼性の目標の作成を支援します。また、組織全体で使用できる、目標を測定するための共有モニタリング インフラストラクチャを開発することもあります。SRE は、信頼性のフィードバック ループの事実上の統制者で、基礎となるポリシー ドキュメントを管理します。多くのチームおよびサービスと関係しているため、機能を横断して信頼性を向上させる広範な分析ができます。
原理 3: SRE は早期に、包括的に関与する
すでに述べたように、SRE は、明日を今日よりも良くすることに力を注ぎます。サポートするサービスのコードと構成を変更できる能力がなければ、問題が発生してもすぐには修正できません。設計プロセスの早期に SRE が関われば、「事後」修正のコストが高くなるという、よくある信頼性のアンチパターンを回避できます。また、SRE はアーキテクチャに関する意思決定に影響を与えることができるため、あるサービスの信頼性を向上させることで企業全体に利益をもたらすように、組織全体の集約化を促すことができます。
チームは、明日を今日よりも良くすることに力を注いでいるか。次の質問について考えてみてください。上の質問ほど詳細で、下に行くほど広義で、高レベルの質問になります。
ソースコードや構成の確認、変更など、サービスの信頼性を高めるエンジニアリングを、現時点で行っているか。
サービスの将来のイテレーションで、信頼性 / 運用性 / 保守性を重視した分析と設計に関わっているか。
広範なアーキテクチャに関する組織の意思決定に影響を与えることができるか。
他のチームにアドバイスする場合、本質的に、個別のサービスの構成またはコードを直接変更する優先度は下がります。ただし、助言する SRE は、共通指標のエクスポートや正常なサービス低下手順など、信頼性のコア機能を提供するフレームワークや共有ライブラリをメンテナンスします。多くのチームと幅広く関わるため、アーキテクチャに関して、組織全体で信頼性を向上させる高レベルなアドバイスができます。
原理 4: SRE はあらゆる反復作業を自動化する
最後に、SRE は、反復作業には人間よりもコンピュータが本質的に適していると確信しています。ルーティン ワークの自動化の費用対効果は、過小評価されがちです。しかし、大規模なサービスを正常に運用することで飛躍的に成長を遂げ、利益を生み出すには、まず、自動化が必要です。また、コンピュータは、何百回も同じ作業を繰り返しても、集中力が切れて間違えることも、飽きてやめてしまうこともありません。SRE のトレーニングや雇用には、費用も時間もかかります。SRE 組織を成功させるには、面倒な作業の大部分をコンピュータに任せることが重要です。
作業を十分に自動化しているか。次の質問について考えてみましょう。
組織の成長やサポートするサービスの数に比例して運用負荷が増大することがないように、自動化などのツールを使って（または作成して）いるか。
チームの反復作業を調べ、時間とともに削減するようにしているか。
熟考のすすめ
ほとんどのブログ投稿では、最後になんらかのアクションを取るようにおすすめしています。しかし、今回は読者の方々に対し、読み終わった後すぐに行動するというよりは、熟考することをおすすめします。このような、強く主張する記事を書くことには、その主張が成長と改善ではなく、分断に使われるリスクがあります。SRE を制限して、チェック項目を満たさない SRE を除外する意図はまったくありません。そのようなゲートキーピングは無意味です。しかし、ある意味ゲートキーピングは、職務の「目的」そのものです。あらゆる組織で、専門化と分業は成功のために不可欠で、このような線引きを避けることは困難だからです。
SRE を名乗りたい人、または自分が SRE だと認めてもらえないのではないかと心配している人に、この考え方で実存的不安を少しでも和らげてもらえれば何よりです。
-顧客信頼性エンジニア Alex Bramley
