SRE プラクティスを促進させるための 4 つのステップ
Google Cloud Japan Team
※この投稿は米国時間 2021 年 5 月 26 日に、Google Cloud blog に投稿されたものの抄訳です。
サイト信頼性エンジニアリング（SRE）を組織内で運用するための第一ステップは、リーダーシップ層の支持を得ることにあるという投稿を、数か月前に行いました。そこで、今回はそれができたものと仮定しましょう。どんなステップが続くでしょうか。SRE を軌道に乗せるには、どんな具体的なステップがあるでしょうか。このブログ投稿では、IT リーダーである皆様がチーム内で SRE を速やかに発展させていくためにできることを調べていきましょう。
ステップ 1: 小さく始めて、繰り返す
ことわざでは「ローマは一日にしてならず」と言われますが、どこからであっても着手するポイントは必要です。SRE の原則を運用するにあたって、私（および私のチーム）が見い出した最も効果的なアプローチは、概念実証から始め、我々の失敗から学び、そして反復することでした。
関連のアプリケーションやチームを洗い出すことから始める
SRE の概念実証に向けて具体的なチームやアプリケーションを選択するには、いくつかのファクターがあります。たいていの場合は組織の戦略的な意思決定でもありますが、本記事では取り扱いません。従来型や DevOps 型のオペレーションから SRE に移行するチームや、ビジネス クリティカルな製品の信頼性をアップさせる必要性は、候補にはなり得ます。理由はどうあれ、アプリケーションを選択するにあたってきわめて重要なのは、以下のような要素です。
ビジネスにクリティカルなものであること。お客様は、稼働時間と信頼性を重視しているはずです。
現在開発中であること。会社が現在アクティブに投資しているアプリケーションを選びましょう。
理想的には、アプリケーションからその動作パターンに関するデータと指標がもたらされる。
その一方で、プロプライエタリ ソフトウェアは避けます。皆様自身でビルドしたアプリケーションが、SRE には最有力候補です。皆様には必要に応じて、アプリケーションとアプリケーションに対するエンジニアリング変更に関して戦略的に意思決定する権限が必要になります。
ヒント: 一般論ですが、オンプレミスとクラウド両方にワークロードをお持ちの場合は、クラウドベースのアプリケーションで始めましょう。エンジニアが従来型のオペレーション環境に慣れているのであれば、クラウドベースのアプリケーションのほうが「ベアメタル」やインフラストラクチャ指標の思考様式から脱却させやすくなります。マネージド型のインフラストラクチャでは、プラクティショナーがユーザーに転換し、デベロッパー（API や Infrastructure as Code など）のように使わざるを得なくなるからです。
念のため: 目標は、現実的なものにしましょう。早期から非現実的な目標を立てると、チームのやる気を損ない、取り組みに悪影響を及ぼします。
ステップ 2: チームを支援する
SRE 原則の運用には、学習するカルチャーの醸成が求められます。その観点から見たチーム イネーブルメントには、知識のトレーニングと自律性の強化が含まれます。
トレーニング プログラムの開発自体、十分に考慮すべき内容ですが、イネーブルメント戦略も早期に検討しておくことが重要です。大規模な組織では特に、社内のスキルアップ、チームの新規採用と拡充はオンボーディングや学習コミュニティの創出とともに対処しておくべきトピックです。
イネーブルメント戦略は、さまざまな職能に従事するさまざまなレベルのスタッフを受容する必要があります。たとえば、リーダーシップ層のトレーニングはプラクティショナーのトレーニングとはまったく別のものになるでしょう。リーダーシップ層の啓蒙は彼らの同意を取り付けるもので、なおかつ組織としての意思決定をするに足るものである必要があります。組織全体で変化を推進するには、カルチャーのコンセプトやプラクティスに関するトレーニングもプラスして必要になるかもしれません。
エンジニアリング部門のリーダーシップ層や中間管理職（マネージャーを管理するマネージャー）の場合、トレーニングは目指すカルチャー育成のためのハイレベルのカルチャーのコンセプトと、優先順位、リソース割り振り、プロセス作成、将来のニーズを理解するための十分条件となる深度を持たせたテクニカルな SRE プラクティスを組み合わせたものにする必要があります。
プラクティショナーの場合は、知識とカルチャーの両面で組織全体の足並みをそろえることが理想的です。しかし、最初に申し上げたとおり、1 つのチームだけで小さくシンプルに始めるのが最善です。
チームのスタートラインは、信頼性や SLA、SLO、SLI、エラー バジェットのような重要コンセプトを理解するところに置くべきです。理由は、SRE がカスタマー エクスペリエンスを重視しているためです。システムとお客様の期待との適合性を計測するにはマインドセットの切り替えが求められますが、これには時間がかかります。
最初のアプリケーションと担当チームが決まったら、アプリケーションのユーザー ジャーニーを見つけます。このジャーニーとは、シングル クリックやマルチステップのパイプラインといった目標を 1 つ達成するために、ユーザーがサービスと交わすインタラクションのセットを指します。続いて、ビジネスへのインパクトによってこれらをランク付けします。中でも、最も重要なものがクリティカル ユーザー ジャーニー（CUJ）で、これらを基に SLO や SLI のドラフト作成を始めます。
ヒント: 皆様が SRE を速く習得する手助けになる汎用の技術的プラクティスを用意しています。たとえば、リポジトリの使用を減らすと、組織内の情報のサイロ化が軽減されて、リソース使用が改善します。
同じように、自動プロセスの優先順位決定や自己修復型のシステムは信頼性に貢献するだけでなく、チームの満足度が向上し、組織の優秀な人材の維持にもつながります。
最後に: 選択するテクノロジー、ソリューション、運用ツールは、アーキテクチャ設計の意思決定のときと同様に、皆様の目標の実現を妨げるのではなく、実現できるものであるべきです。
ステップ 3: 学んだことをスケールする
1 つのチームか少数のチームで SRE プラクティスが確立されたら、今度は SRE コミュニティと組織全体で形式化されたプロセスを作ります。ステップ 2 が終わるまでにこれを並行させて進める組織もあれば、問題のない運用事例でいくつか経験を積んでから着手する組織もあります。
このフェーズでは、皆様はおそらくコミュニティ、カルチャー、イネーブルメント、プロセスに対処しておくと良いでしょう。これらは相互に結び付いているため、いずれはこのすべてに対処する必要性が生じますが、優先順位は組織によって変わります。
組織内に SRE コミュニティを作ることは学習の面でも重要ですが、さらにベスト プラクティスのナレッジベースの確立、内容領域専門家のトレーニング、求められるガードレールの作成、プロセスの統一にも有用です。
コミュニティを作ることと、自律性を実現したカルチャーとチームのトレーニングを醸成することは共同歩調で進みます。アーリー アドプターは SRE の「アンバサダー」となって学んだことを周囲に伝えてくれますし、組織内のさまざまなチームのトレーナーにもなってくれます。
各開発チームで、SRE に熱意を持って実務の導入を支援してくれそうな「アンバサダー」や「推進者」を探しておくのも大切なことです。
入門セッションを含めて、各職能で反復可能なトレーニングを用意しておくことも非常に重要です。チームの新規メンバーの入門トレーニングは、トレーニング面はもちろん、SRE の支援カルチャーの醸成には必要となります。そのため、入門プロセスに配慮して、チームメンバーが交代しても知識が継承されるようにすることは不可欠です。
このフェーズでは、心理的な安全性を高め、失敗を許容し、チームが失敗から学べるようにするカルチャーを組織全体で醸成するのが良いでしょう。そのためには、目標とするカルチャーをリーダーシップ層がモデル化し、透明性を促す必要があります。
最後に、プロセスを構造化して形式化することで、緊急時対応、特にオンコール時のストレス軽減に役立ちます。プロセスが目に見えるようになると、チームは協力しやすくなり、より効果的に行動できます。
その影響を最大化するには、チームの検討事項の中で最も痛みを伴う領域から始めます。例としては、アラート疲れを回避（または対応）するためにアラートの音量ダウン、チェンジ マネジメント プロセスの自動化、チーム内の労力に余力を残しておくために必要なスタッフに限定するなどが挙げられます。チームメンバーは、ソフトウェア エンジニアリングのプロジェクトを抱えているときに、オンコールのインシデント管理をすべきではありません。その逆もまたしかりです。両方の業務を別個にこなせるように、仕事には余裕を持たせてください。さまざまな領域で言えることですが、データを使用する目的は、意思決定を促進するところにあります。だからこそ、チームがもっとも時間を取られている業務は何か、それに何時間を費やしているかを洗い出しましょう。
定量データにせよ定性データにせよ、この種のデータを収集するのが難しい場合は、緊急時対応プロセスをスタートラインにすると良いでしょう。これは緊急時対応がビジネス、特にエスカレーション プロセスやインシデント管理、それらに関連するポリシーに直接影響するためです。
ヒント: 前述のプラクティスは、すべて情報のサイロ化防止や、皆様のベンダーやエンジニアリング パートナーも含む組織全体の目標共有に貢献します。なお、ベンダーやパートナーとの契約内容が、これら目標に対応しているかどうかも併せて確認しましょう。
ステップ 4: データドリブン型のマインドセットを具体化する
SRE ジャーニーのスタートは、たとえチームがたった 1 つであっても時間がかかります。このスタート時にすばやくプラスの効果をもたらせる方法として、データ収集と責任追及のない事後分析があります。
SRE では、可能な限りデータドリブン型を目指すため、組織に測定カルチャーを作ることがきわめて重要です。収集するデータの優先度を決める際は、カスタマー エクスペリエンスを表すデータを求めるのが理想的です。こうしたデータは、事業におけるギャップの洗い出しに役立ち、自社のニーズとその延長線上にあるお客様の期待に合わせて優先順位を決める判断材料になります。
もう一つできるようになるのが、失敗から学び、強固な SRE カルチャーの醸成には不可欠な事後分析の実施と改善です。Google の経験則から、事後分析を実施している組織であっても細かい点をいくつか改善するだけで、事後分析の有用性はさらに高まります。ただし、チームが安心して事例を共有して失敗から学べるように、責任の追及のない事後分析が重要です。同じ失敗を繰り返さず、今日よりも明日をよりよくするため、事後分析にはアクション項目を盛り込み、オーナーにアサインします。
事後分析向けの共有リポジトリの設営はチームに多大な影響をもたらします。透明性を促し、情報のサイロ化を軽減しながら、学習カルチャーにも貢献します。さらに「自身が説いていることを実践している」組織であることが、チームにも認識が広がります。リポジトリの運用は、共有ドライブを作成する程度に簡単です。
ヒント: 事後分析では責任を追求せず、行動に反映できる内容であるべきです。
SRE への最短ルート
まったく同じ組織が存在しないのと同様に、まったく同じ SRE チームも存在しません。しかし、以上の手順をなぞることで、チームによる SRE 実現までの時間が短縮されます。効果的な SRE プラクティスの構築についての詳細は、以下のリソースをご覧ください。
-Strategic Cloud Engineer, Infra, AppMod, SRE, Ayelet Sachto
