SRE チームの評価に役立つレベル別チェック リスト

※この投稿は米国時間 2019 年 1 月 26 日に Google Cloud blog に投稿されたものの抄訳です。

このたび、『The Site Reliability Workbook』がウェブサイトで閲覧できるようになりました。Google で生まれ、他の企業にも広まりつつある Site Reliability Engineering（SRE）は、運用上の問題をソフトウェア的に解決するためのエンジニアリングであり、Google におけるエンジニアリングの本質的な部分を占めています。

SRE は考え方であり、一連のプラクティスやメトリクスであり、システムの信頼性を保証するための処方箋でもあります。SRE モデルを構築すれば、サービスの信頼性が向上し、運用コストが下がり、人間が行う作業の価値が高くなって、サービスとチームの双方で大きなメリットが得られます。上述の新しいワークブックは、SRE の構築に向けてスタートを切り、SRE プラクティスを実行に移すための具体的なヒントを提供します（本稿では、ワークブック内の章に対応する本稿での記述箇所にリンクを付加しています）。

私たちはよく、SRE の実施とは実際にどういうことなのかと尋ねられます。これは、お客様がそれぞれの SRE プラクティス を築き上げていくうえで、達成度の定量化に苦労されているからでしょう。この問題に対する単純で標準的な答えはありませんが、本稿では、初歩的なものから順に達成度を測るためのチェック リストを示していきます（決して網羅的なものではありませんが）。このチェック リストは、高信頼性サービスの担当部門が SRE モデルに向かってチームを変えていこうとするときに役立ちます。どのチェック リストも項目は時系列順に並べてありますが、実際のニーズや優先順位がチームによって異なることは私たちも認識しています。

経験豊富な SRE チームに属する方にとっては、このチェック リストは業界ベンチマークの 1 つとして役に立つかもしれません。他の人たちも自身のチェック リストをぜひ公開してください。もちろん、SRE は厳密な科学ではなく、実現過程でさまざまな難問にぶつかるでしょう。各項目の 100 % 達成には至らないかもしれません。それでも、継続していくことが SRE にとって大切だということを、私たちは Google での経験から知っています。

SRE の基本

• 何らかのサービス レベル目標（SLO）を決め（開発、事業部門の一部でない場合は、これらの部門のメンバーと共同で）、ほぼ毎月目標を達成していること
• 非難を伴わない障害報告書を記録するカルチャーがあること
• 本番環境におけるインシデントの管理プロセスが作られていること（これは全社的であることが望ましい）

初級者チーム

• 人員の配置転換と採用のプランがあり、予算が承認されていること
• スタッフを配置したチームが何らかのサービスのオンコール サポートを担当するとともに、少なくともシステム運用の負荷の一部を担っていること
• リリース プロセス、サービスのセットアップとティアダウン（そして可能ならフェイルオーバー）のためのマニュアルを整備していること
• SLO の一部としてカナリア リリースを評価していること
• 必要なときのためにロールバック メカニズムを用意していること（ただし、たとえばモバイル アプリケーションが関係するときは簡単ではないことが考慮されます）
• 完全でなくても、運用手順書（プレイブック / ランブック）があること
• 少なくとも年 1 回は理論的な（ロールプレイングによる）ディザスタ リカバリ テストを実施していること
• SRE がプロジェクトの仕事を立案、実施していること（開発者の支持を必要としない運用負担軽減の取り組みなど、開発者から直接見えない部分でもかまいません）

• 定期的に（つまり毎週）インシデント対応手続きの訓練をする程度のオンコール
• SRE の統括責任者（つまり CTO）が審査、承認した SRE チーム憲章
• 問題点や目標について議論し、情報を共有するための SRE と開発リーダーの定例会議
• 開発と SRE の共同作業によるプロジェクトの立案、実施。SRE の貢献とプラスの効果が開発のリーダーにも見えていなければなりません

中級者チーム

• ビジネス リーダーとともに、SRE プロジェクトの実績と効果を定期的に評価していること
• ビジネス リーダーとともに、SLI と SLO を定期的に見直していること
• 全体として少量の苦役があること（負担の軽いオンコール以上のものが 50 % 未満）。信頼性を考慮に入れた構成変更アプローチをチームが確立していること。SRE が単にオンコールの範囲を広げたりサービスを増やしたりするだけでなく、自らの影響力を大きくするためのプランを確立していること
• カナリア リリース失敗時のロールバック メカニズムを用意していること（自動化も可）
• ロールプレイングと何らかの自動システムを組み合わせた、インシデント管理の定期的なテストを用意していること
• SLO 違反発生時のエスカレーション ポリシーを規定していること。たとえばリリース プロセスの凍結 / 凍結解除など（SLO 違反の可能性については、こちらの記事をご覧ください）
• 開発と SRE が共有する障害報告書とアクション アイテムを定期的に見直していること
• 本番以外の環境を使用したディザスタ リカバリ テストを定期的に行っていること
• チームが需要と能力の関係を計測し、能力が需要に追いつかなくなりそうなときに積極的に予告していること
• 開発チームと共同で SRE チームが長期計画（年次ロードマップ）を作っていること

上級者チーム

• 少なくとも SRE チーム内の数名が、単なる運用や障害対策の枠組みを越えて、ビジネスの何らかの側面に大きなプラスの影響を与えていること
• プロジェクトの仕事を水平的に実施でき、実際によく水平的に実施されること。サービスの改善に時間がかかったり、かえって悪化させたりせずに、多くのサービスをまとめて改善できること
• ほとんどのサービス アラートが SLO バーン レートに基づいていること
• 自動化されたディザスタ リカバリ テストが用意されており、プラスの効果が計測されていること

• SRE のオンコールが年中無休の 24 時間体制ではないこと。米国と欧州というように SRE チームが 2 つの地域に分散されており、どちらも副次的な扱いになっていないこと
• SRE と開発チームが目標を共有し、SVP 以上の幹部からの指揮命令系統が別々になっていること（利害衝突を防ぐことに役立ちます）

次に何をすべきか

まだ SRE チームが存在せず、初級者チーム向けチェック リストの多くが未達なら、冒頭で紹介した SRE ワークブックを最初の章から順に読むことを強くお勧めします。自社が Google Cloud Platform（GCP）のユーザーで、CRE の関与を希望される場合は、アカウント マネージャーに連絡してこのプログラムに応募してください。ただし、SRE はさまざまなインフラストラクチャに適用できるメソドロジーであり、この一連のエンジニアリング手法を用いるうえで Google Cloud の使用は前提条件でないということを、はっきりさせておきたいと思います。

また、人材採用の停滞などを解決するベスト プラクティスを共有するため、既存のカンファレンスに出席したり、他社とのサミットを組織したりすることもお勧めします。

変化の激しさゆえに、上級者チーム向けチェック リストの達成に苦労しているチームもよく見かけます。システム変更や人事異動が上達の遅延要因になるかもしれません。チームが初級者レベルの段階に逆戻りするなどの問題を避けるため、Google の SRE リーダーたちは、6 か月ごとにそれぞれのチームの主要指標をチェックしています。この場合、一部の項目はすでに標準になっているので、チェック範囲は上記のチェック リストよりも狭くなっています。

すでにお気づきかもしれませんが、本稿の中心的な問いに答えるということは、チームの影響力と健全性、そして何よりも大切なことですが、実際の仕事のしかたを評価するということです。結局のところ、最初の SRE 本で書いたように、自動化できないプロセスやソリューションを作っているなら、システムを維持するために人員を確保し続けなければなりません。人間がいなければ仕事がまわらないのであれば、人間の血と汗と涙をマシンに注ぎ込んでください。

だからこそ、あなたはもう SRE チームを設けているのでしょう。そのチームは効果的ですか？ スケーラブルですか？ 人々は満足していますか？ SRE チームのスキルがどの程度であっても、チームの仕事と会社のサービスにはまだまだ発展、成長、強化の余地があるはずです。SRE チームの立ち上げ方をもっと詳しく学びたい方はこちらを参照してください。

本稿に力を貸してくれた多くの人々、特に Adrian Hilton、Alec Warner、David Ferguson、Eric Harvieux、Matt Brown、Myk Taylor、Stephen Thorne、Todd Underwood、Vivek Rau の各氏に感謝いたします。

- By Gustavo Franco, Customer Reliability Engineer