SRE の導入: SLO の設計プロセスを標準化する

※この投稿は米国時間 2023 年 3 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

3 人のサイト信頼性エンジニアに、「SRE（サイト信頼性エンジニアリング）とは何か？」という問いを投げかけてみてください。おそらく、DevOps の実装、役割、一連のプラクティス、文化のシフト、格好いい肩書、といった 5 つの異なる答えが返ってくるでしょう。これらの答えは、SRE の専門書に記載されている内容と必ずしも一致しないかもしれませんが、他の業務と比較したときに、SRE の明確な特徴として貫いているものがあります。それは、サービスレベル目標（SLO）です。SLO と意図的にわかりやすい呼び方がされていますが、実際にその内容を定義するのは簡単なことではありません。SLO の具体的な内容は業界や業種によって異なりますが、各々のワークロードで SLO の実装に成功したチームの手順や方針には、多くの共通点があります。

最初の重要なステップは、製品、開発、SRE の各チームが連携し、対象のワークロード、ならびに、特にそのクリティカル ユーザー ジャーニー（CUJ）について共通の理解を得ることです。これは多くのチームにとって、CUJ の詳細シーケンスやフロー図を（大抵は初めて）記述することを意味します。この作業に要する労力は、開発、製品、SRE という「スツールの 3 本足」間の関係がどれだけ成熟しているかによって異なってきます。ユーザーがワークロードに求めている要件について共通の認識に達することが、効果的な SLO を記述するための前提となります。

ユーザー ジャーニーをモデル化して SLO に落とし込む作業は高度な技術を要するのに加えて、二つとして同じアプリケーションは存在しません。しかし、SLO に関する議論を進めるにあたって、重要なポイントがいくつかあります。このプロセスを進めるうえで、常に「ユーザーにとって何が大事なのか？」という基本的な問いかけを意識することをおすすめします。この問いを基軸として思考プロセスを構築することによって、実装時の失敗や、基本方針がユーザーの期待から大きくずれてしまうことを回避できます。そのほかに、以下の点も検討するようにしましょう。

• ユーザーがアクションを起こすのを思いとどめるようなブレークポイントはあるか？

• ユーザーのインタラクションのうち、測定できる部分はどこで、測定できない部分（サードパーティに依存している部分など）はどこか？

• 他のユーザー ジャーニーとの共通項はあるか？たとえば、ログインの部分など、独立した CUJ として切り出せそうな箇所はあるか？

• ユーザー ジャーニーのどの部分をまとめて測定できるか？また、重要度やリクエスト率などの違いから、他と区別すべき箇所はあるか？

• ユーザー ジャーニーを構成するステップ間で、密接な依存関係があるか？

こうした問いへの答えを出し、リクエストの詳細図およびアプリケーション コードを準備したら、紙とペンを用意しましょう。モニタリング コンソールにすぐに移動する前に、SLO 設計書（選択した SLO の技術的詳細）を記述することをおすすめします。この作業に着手する際に便利なテンプレートをご用意しました（Google アカウントをお持ちでしたら、こちらのリンクからコピーできます）。このファイルには、空のテンプレートに加え、記入例も含まれているので、SLO 設計書を作成する際の参考にしてください。このテンプレートを使用するかどうかにかかわらず、SLO を文書化する際は以下のことをおすすめします。

• 技術仕様を徹底的に検討する - 実装時に重要になります

• 設計の過程で明確化した事項や、注意事項、トレードオフに関する章を作り、適宜更新する

• 測定の対象部分を検討する - 実際に測定可能であることを確かめましょう

• レイテンシの SLO について、要約データや、平均値、集計対象外の統計データに着目する

• ワークロードのコンプライアンス期間を統一する

• デフォルトとして推奨:

• 連続した 28 日間（運用上の必要性 - エラー バジェットのアラートのため）

• カレンダーに基づく一定の四半期（優先順位の検討および振り返りのため）

• 変更履歴: 利用している文書ツールに変更履歴機能がある場合でも、主な変更点をトラッキングできるように、変更履歴のセクションを用意しましょう

• チームメンバーや社内の関係者がアクセスできる場所に、SLO 文書を置く

• SLO の PRD（製品要求仕様書）が完成したら、その実装をコードとして扱い、バージョン管理システムに保存する

• DRY（Don't repeat yourself）を常に念頭に置く - 同じ作業の繰り返しは回避しましょう

上記の推奨事項とテンプレートが、SLO を本番環境に適用するうえでお役に立てば幸いです。SLO を実装するためのツールが必要でしたら、Google Cloud の SLO モニタリングの利用をご検討ください。Google Cloud Monitoring 内で利用可能な任意の指標に対して SLO を作成できるほか、エラー バジェットを自動計算し、バーンレートに基づくアラートを生成することも可能です。それでも無理難題に思われる場合や、推奨事項についてなんらかのサポートが必要なときは、Google プロフェッショナル サービスの信頼性エンジニアリング担当チームまでご相談ください。詳しくは cloud.google.com/sre をご覧になるか、Google Cloud のアカウント担当者までお問い合わせください。