SRE実践の形:7種類の SRE 実践パターン
わたしたちが自身の経験をもとに書いたものですが、参考資料の影響を多大に受けています。参考資料がどれも厚すぎて参考にしきれていない感はあります。
これらの実践パターンはどれかが優れているというものではなく、組織やプロダクトの状況によって選択するものだと考えています。
なお次のエントリでSREを成していく道のりの話をしています。
目次
7種類のSRE実践パターン
これらは順番に発生していくものではありません。また これらの実践パターンは排他的ではなく、複数を並行実施する ことがあります。
わたしたちが知る限りSREのミッション(あるいはSREに対する期待値)は両極端で、全体を俯瞰し全体最適を図る方向性の場合と、可用性・パフォーマンス・モニタリング・DX=Developer eXperienceなど特定のトピックに特化する方向性の場合があります。結果としてごっちゃりしやすいです。ちなみにX-Tech5では全体を俯瞰しUX(User eXperience)を最適化することを志向しています。
SREのミッションはごっちゃりしがちですが、人間の認知能力には限界があるので、認知負荷を下げることが効率や品質に寄与すると考えます。ここで紹介するパターンを知っていると、状況や役割分担を整理るすときに役に立つことでしょう( breaking down the invisible wall
の流れを考慮すると、分担より主戦場領域という表現がしっくりくるかもしれません)。
なお、このエントリではSRE(Site Reliability Engineering:技法)とSREs(Site Reliability Engineers:役割や人)を区別して記述します。
1.中の人が SRE する、あるいは中の人として SRE する
専任のSREsがいない、あるいはSREsがDevsの一員であるパターン。
普通にメンバーとして機能開発を担当することもあれば、SREのエキスパートとしてSite Reliabilityに関連する機能を開発したり、他のメンバーが書いたコードをSREの観点でアーキテクチャレビューやコードレビューしたりすることもあります。
SRE/SREsの起こりの段階でまずこのパターンになることが多く、Devsメンバーが(多くの場合は片手間で)SREを実践している状態になります。またSREの普及段階以降にSREsがDevsに入り込んでSREを啓蒙・普及・実践していくパターンもあります。
実装例:Embedded SRE(実践を主眼に置いた表現)、Enabling SRE(啓蒙・普及を主眼に置いた表現)
2.外の人として、SRE に関わるタスクや機能開発を引き受ける
DevsとSREsがスコープを切り分け、かつ両方がアプリケーションのソースコードを直接いじるパターン。
以下のような、SREに直接関わるタスクを切り出して実施します。
-
外部API呼び出しにリトライを実装したい
-
APMを仕込みたい(APM:Application Performance Monitoring)
-
ログ出力やエラーハンドリングを見直したい
-
パフォーマンスを改善したい
SREsをチームから切り離して専任化したものの、Devs側がSREを担うのはまだ荷が重いという状況でよく発生します。そのような状況を脱する日は来ないのではないか、などと言ってはいけません。
実装例:SREチーム、Everything SRE、Kitchen Sink
3.外の人として、SRE に関わる助言を行う
SREsはアプリケーションのソースコードを直接いじらず、助言に徹するパターン。
SREの観点でアーキテクチャレビューやコードレビューを実施することはあります。
SREの主体者がDevsになっていく段階・あるいはDevsがSREするようになったタイミングで効果を発揮します。SREsに助言を行うSREsを設けることもあります。
実践例:コンサルティング、アドバイザリ、テクニカルアドバイザ
4.SDKやライブラリを提供する
アプリケーションのソースコードは直接いじらないが、SREを実現するためのSDKやライブラリを提供するパターン。
後述するエコシステム整備やプラットフォーム提供、プロダクト・サービス提供と並行して実施することが多いです。
実践例:{ライブラリやツールの名前}開発チーム
5.エコシステムを整備する
SREの実現に寄与するエコシステムを整備するパターン。
典型的には以下のような取り組みを行います。
-
CI/CD機構を提供する
-
プライベートリポジトリを提供する
-
開発レギュレーションを策定する
-
技術選定レギュレーションを策定する
比較的初期にボトムアップで取り組みが始まることが多くあります。またボトムアップでできあがってきたものが、規模が大きくなり、収集がつかなくなり、さて見直しましょうかという段階で取り組むことがよくあります。
実装例:CTO室、基盤開発チーム
6.プロダクト・サービスを提供する
アプリケーションを安全に・効率よく開発・運用するためのプロダクトやサービスをSaaSとして提供するパターン。
典型的には社内PaaSや社内SaaSを提供します。
発展していくと後述のプラットフォームとあまり区別がつかなくなります。
実装例:データ基盤チーム、社内PaaS(例:社内向けメール配信基盤)、社内SaaS(例:社内向けデータ分析ポータル)
7.プラットフォームを提供する
アプリケーションを動作させるためのプラットフォームを提供するパターン。
典型的にはKubernetes基盤やモニタリング・ログデータ収集基盤を整備する取り組みを行います。
前述のプロダクト・サービス提供の次の一手として取り組まれることがよくあります。
実装例:共通基盤チーム、Platform SRE
まとめ
本エントリでは7種類のSRE実践パターンを紹介しました。
MECEになるようなものではなく、他にもパターンがありそうに思います。
いい感じのものを発見したらぜひ共有してください。
参考
実践への道
参考情報
- DevOps入門編 DevOpsとは何か?実現する方法
- SRE入門編 SREとは何か?コア技術と日本における事例
- SRE実践編 どのような取り組みを行うのか
- O’Reilly Japan – SRE サイトリライアビリティエンジニアリング
- O’Reilly Japan – サイトリライアビリティワークブック
- O’Reilly Japan – SREの探求
- SRE at Google: How to structure your SRE team | Google Cloud Blog
[PR] X-Tech5のSREサービスで『今日より、一歩前へ』
SREに取り組み始めたいものの、いまいち最初の一歩が難しいなぁという場合は、弊社X-Tech5のSREサービスをご検討ください。
まずは無料相談から!。直接ご支援・相談できます。
弊社エンジニアがSREとしてチームに参加し、チームの一員として動きSREを実現します。