バズワード化して何やらふわっと そういう感じ という扱いになっているSREというものについて、何をする人なのかわかりやすく説明したいと思います。
※概ねSRE本に書いてあるままですが、Googleの中の人とSREについて話をしたり、色々した結果得られた個人的な見解です。
TL;DR
SREとは
- ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるもの
- 運用業務とその自動化や全体的な効率化をする人たち
よくある誤解
SREは運用自体はしないんでしょ？
違います。ソフトウェアエンジニアであり、運用をする人です。
Continuous Deliveryにあるように自動化のためにも運用をする必要があります。
SREはインフラエンジニアのことでしょ？
違います。ソフトウェアエンジニアであり、運用をする人です。
SREは運用するだけでしょ？
違います。半分以上の時間をソフトウェアエンジニアとして自動化などの開発に当てます。
アプリケーションの非機能要件はSREがやるんでしょ？
必要ならしますが、それがSREの仕事というわけでもないです。
アーキテクチャを決めて基盤を作るんでしょ？
必要ならしますが、それがSREの仕事というわけでもないです。
アプリケーションのコードは触らないんでしょ？
必要ならします。
SREとは
Site Reliability Engineer(ing) の略。GoogleのBen Treynor Slossが運用チームを設計する中で作られた運用の形です。
Because reliability2 is so critical, SREs are focused on finding ways to improve the design and operation of systems to make them more scalable, more reliable, and more efficient. However, we expend effort in this direction only up to a point: when systems are “reliable enough,” we instead invest our efforts in adding features or building new products.
(Site Reliability Engineering, https://landing.google.com/sre/sre-book/chapters/preface/)
信頼性こそがあらゆるプロダクトの基本的な機能として位置づけ、SREはシステムのスケーラビリティ、信頼性、効率性を向上させるために、その設計と運用の改善方法を見つけることに集中し、 システムが「十分な信頼性を持った」ら、機能の追加や新プロダクトの構築のために力を注ぐ とされています。
信頼性って何？
"The probability that [a system] will perform a required function without failure under stated conditions for a stated period of time,"
(Site Reliability Engineering, https://landing.google.com/sre/sre-book/chapters/preface/#id-gA2u2Iyh4)
信頼性とは「[システムが]求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こすことなく実行する確率」。つまり、分かりやすく言えば可用性ということ。
なぜ信頼性が重要なのか
古より、人が人を選ぶにあたって最も重要なのは信頼であり、同じように人がプロダクトを選ぶにあたって重要なのも信頼です。
なぜ自動化をするのか
運用というのは可用性との戦いです。システムは何か障害があれば止まり、何か攻撃されれば止まり、バグがあれば止まります。その上で、メンテナンスやアップデートがあり、ユーザーの増加に伴い、適切にキャパシティを変更する必要があります。
１つの特徴として、運用は時間の経過とともに大変になっていきます。最初はシンプルで誰でも運用できるものだったのが、次第にシステムは複雑性を増し、障害ポイントは増え、複合的な要因による障害や不具合も発生するようになります。
そうした中で、人手による運用というのはどこまでもスケールしていくものではありません。どこかのタイミングでシステムの規模や複雑性に人の手が追いつかなくなる日がきます。
そうなると何か問題が起きても対応しきれず、システムはダウンし、ユーザーは不便な思いをするかもしれません。
可用性を高めるには人手による運用はやめ、自動化できるものを自動化し、プロダクトの運用をスケールできるようにする必要があります。
開発効率の向上
何か不具合があったときにそれを直すスピードが遅かったらどうでしょうか。
これもまた可用性を下げる要因になります。できる限り効率的な開発ができるようにすることもSREの仕事と言えます。
DevOpsとの関係
DevOpsは 文化 で、SREは 役割 です。
Googleの中の人が class SRE implements DevOps と言っていますが、これは方便のようなもので、運用や開発の効率を高める上でDevOps的な形になるということだと思います。
SREの始め方
SREのいない組織にSREを作りたいと思ったらどうすれば良いでしょうか。
1. SREについての認識を揃える
SREが何かということについてプロダクト組織で認識を揃えます。この記事に書いてあるようなことです。
2. 計測する
まずは計測をできるようにします。
主にはLBやWebサーバーのアクセスログ等の可用性に関するものです。
一般的なメトリクスで計測できるものは何でも計測するのがいいです。
3.SLIとSLOを決める
SLIは Service Level Indicator (サービスレベル指標)、SLOは Service Level Objective (サービスレベル目標)です。
できるだけシンプルな指標を定め、それの目標値を決めます。
リクエストの成功率をSLIとする場合、
例えばSLOは99.9%が正常なレスポンスで、エラーは残り0.1%というようなことになります。
SREはこのリクエストの成功率を守るために課題を見つけ、対処を行います。
4.課題を見つける
可用性を下げるのはどんなことが考えられるでしょうか。
手運用だったり、SPOFだったり、セキュリティだったり、キャパシティやパフォーマンスかもしれません。
危険なものから自動化したり改善をします。
その他
エラーバジェット
問題のほとんどはリリース時に発生します。
エラーバジェットは開発速度と品質のバランスを取るためのものです。具体的にはSLOを1から引いた値、上記の例では0.1%となります。
エラーバジェットはデポジットのようなものと考えることができます。
リリースはエラーバジェットを使用して行い、SLOを満たせなくなった時点でエラーバジェットが没収されます。リリースがうまくいっている間はエラーバジェットは引かれることはありません。逆に言えばエラーバジェットがなくなるまでは品質よりも速度を優先して良いということです（限度はありますが）。
エラーバジェットがなくなった場合は、信頼性回復のための行動を開発チームが行います。この信頼性回復の行動が開発速度と品質のギャップを埋めるものになります。
SREと開発チームの関係
GoogleではSREチームは稼働時間の50%以上を自動化等の開発に当てます。
それを満たせなくなった場合は、開発チームがSREの仕事に加わります。
また、SREはいつでも開発チームに参加することができます。
誰でもSREの仕事ができ、SREもアプリケーション開発ができる状態になるのが、SREのいるプロダクト組織のとりあえずの目指す状態だと思います。
SREのバックログ
SREのバックログと開発チームのバックログを1つにするかどうか、あるいは開発チームとSREチームの区別を無くし、1つのチームにすべきではないかという議論は結構な頻度で起きます。
基本的に1つにするのは難しいと思います。なぜならチームの目的が違うからです。片方はユーザーへの価値提供、もう一方は運用をし、信頼性を担保するための施策を行う。同じバックログやチームであればそれらが順番にやってきて同時に進めることができません。
誰でもSREの仕事ができる状態でないのであれば、もっと悲惨で、SREに負荷が集中することになります。
この辺は開発チームとのしっかりと認識を揃える必要があるでしょう。
まとめ
これがSREについての基本的な話ですが、もっとたくさんのプラクティスが SRE本
にまとめられています。Googleの中の人も本に全部書いてあると言っていました。
興味を持った方はぜひ読んでみてください。