SREingを進めて行く中で、SRE roleのエンジニアを用意したり、チームを作ったりすることがある。そうしたときの実装パターンはいくつかある。代表的なパターンはここにまとめられている。
さて、SREチームを持つと大きく二種類のスケーラビリティのトレードオフに気づくと思う。
1つ目は、複数のチームやマイクロサービスを見るという意味でのスケーラビリティ。
2つ目は、https://map.r9y.dev/beck/map.htmlに書かれているような、様々なSREingプラクティスを導入するという意味でのスケーラビリティ。
1つ目の複数のチームを見るというスケーラビリティを優先する場合、それはSDK開発やプラットフォーム開発に重きを置くチームとなる。この場合は、SREメンバーのスキルセットもわかりやすくて、例えばKubernetesが得意なメンバーを採用するみたいな話になる。
2つ目の多様なSREingプラクティスの導入を優先する場合、フルサイクルエンジニアのような形で特定プロダクトの企画から運用まで一気通貫で関わる形になる。これは実装パターンとしては、外からプロダクトチームへアサインされる（埋め込まれる）Embedded SREと呼ばれるものが多いと思う。
私のチームは、そのEmbedded SREチームなわけだけど、当然ながら特定のサービスやチームへ埋め込まれるため、SREチームの成果が特定サービスに閉じやすい≒スケールしないという弱点があると思っていた。
しかしそれは誤解だった。Embedded SREの成果をスケールさせる際の鍵は、サービスの信頼性改善自体ではなく、サービスを開発するチームの成長だった。
詳細は下記の記事にあるが、人の成長は大きく4つの領域を通過する必要がある。
コンフォートゾーン（安定、現状維持）
フィアゾーン（不安で、コンフォートゾーンへ戻りたい）
ラーニングゾーン（積極的な学びの意欲）
グロウスゾーン（自律的な思考と自己実現）
これらの領域をより深く行く進むことで、結果としてコンフォートゾーン（安定、現状維持）が広がる。そしてそれが成長である、という話。
Embedded SREが意識するべきは、サービスの信頼性それ自体の改善ではなく、SREingプラクティスについてサービスチームをフィアゾーンから抜け出させるための支援だったわけだ。
例えば、回復性を意識したアーキテクチャであるとか、複雑性を受け入れたカオスエンジニアリングであるとか。
こういったプラクティスは、発想の転換が必要だったり、アンラーニングが必要だったり、既存の運用ツールの積み重ねを一度捨てる必要があったり、とにかくフィアゾーンが広くなりがちである。
Embedded SREは、そのフィアゾーンを抜け出す手助けをする。すると、開発者はラーニングゾーンやグロウスゾーンに突入し、人によっては自律的にSREingのプラクティスを吸収するようになる。その結果、社内にSREingを理解して実践しているエンジニアが増えることになる。これがEmbedded SREのスケーラビリティだった。
SREingの実践経験があるエンジニアが一度増えると、そこから先は指数関数的な変化が期待できる。
プラットフォームへのフィードバックとコントリビュートの増加
IaCが進むことで、チーム間での知見やコードの再利用性の向上
開発チーム同士の教え合いによる知見共有
これを推進するためには、「代わりに作業するEmbedded SRE」では全く無意味だということ。大事なのは、指導であるメンタリングと自律支援であるイネーブリングの2つのバランス。
そしてつまり、「やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ。」である。
（ここ最近、私が前に入ったチームの人が、他のチームに対して技術の紹介セッションをしていた姿をみて思ったのでした）