初級者チーム
Google の SRE チームは、全部ではなくてもそのほとんどが、次のプラクティスと特長を確立しています。チームが置かれた環境にこれらの実現を阻むもっともな理由がないかぎり、私たちはこれらを、優れた SRE チームの基礎だと考えています。
- 人員の配置転換と採用のプランがあり、予算が承認されていること
- スタッフを配置したチームが何らかのサービスのオンコール サポートを担当するとともに、少なくともシステム運用の負荷の一部を担っていること
- リリース プロセス、サービスのセットアップとティアダウン（そして可能ならフェイルオーバー）のためのマニュアルを整備していること
- SLO の一部としてカナリア リリースを評価していること
- 必要なときのためにロールバック メカニズムを用意していること（ただし、たとえばモバイル アプリケーションが関係するときは簡単ではないことが考慮されます）
- 完全でなくても、運用手順書（プレイブック / ランブック）があること
- 少なくとも年 1 回は理論的な（ロールプレイングによる）ディザスタ リカバリ テストを実施していること
- SRE がプロジェクトの仕事を立案、実施していること（開発者の支持を必要としない運用負担軽減の取り組みなど、開発者から直接見えない部分でもかまいません）
次の項目も、発足したばかりの SRE チームで一般的になっているものです。こういうものがなければ、チームが不健全で持続可能性に問題がある兆候かもしれません。
- 定期的に（つまり毎週）インシデント対応手続きの訓練をする程度のオンコール
- SRE の統括責任者（つまり CTO）が審査、承認した SRE チーム憲章
- 問題点や目標について議論し、情報を共有するための SRE と開発リーダーの定例会議
- 開発と SRE の共同作業によるプロジェクトの立案、実施。SRE の貢献とプラスの効果が開発のリーダーにも見えていなければなりません
中級者チーム
以下の項目は経験豊富なチームで一般的に見られるもので、チームがサービスの効率的な管理に積極的に取り組んでいることを示しています。
- ビジネス リーダーとともに、SRE プロジェクトの実績と効果を定期的に評価していること
- ビジネス リーダーとともに、SLI と SLO を定期的に見直していること
- 全体として少量の苦役があること（負担の軽いオンコール以上のものが 50 % 未満）。信頼性を考慮に入れた構成変更アプローチをチームが確立していること。SRE が単にオンコールの範囲を広げたりサービスを増やしたりするだけでなく、自らの影響力を大きくするためのプランを確立していること
- カナリア リリース失敗時のロールバック メカニズムを用意していること（自動化も可）
- ロールプレイングと何らかの自動システムを組み合わせた、インシデント管理の定期的なテストを用意していること
- SLO 違反発生時のエスカレーション ポリシーを規定していること。たとえばリリース プロセスの凍結 / 凍結解除など（SLO 違反の可能性については、こちらの記事をご覧ください）
- 開発と SRE が共有する障害報告書とアクション アイテムを定期的に見直していること
- 本番以外の環境を使用したディザスタ リカバリ テストを定期的に行っていること
- チームが需要と能力の関係を計測し、能力が需要に追いつかなくなりそうなときに積極的に予告していること
- 開発チームと共同で SRE チームが長期計画（年次ロードマップ）を作っていること
上級者チーム
次の項目は特にスキルの高いチームに見られるものですが、複数または全社の SRE チームがより広範な憲章を共有することで実現できる場合もあります。
- 少なくとも SRE チーム内の数名が、単なる運用や障害対策の枠組みを越えて、ビジネスの何らかの側面に大きなプラスの影響を与えていること
- プロジェクトの仕事を水平的に実施でき、実際によく水平的に実施されること。サービスの改善に時間がかかったり、かえって悪化させたりせずに、多くのサービスをまとめて改善できること
- ほとんどのサービス アラートが SLO バーン レートに基づいていること
- 自動化されたディザスタ リカバリ テストが用意されており、プラスの効果が計測されていること