SRE風のインフラエンジニアにならないために
この記事は、SRE Advent Calendar 2018 - Qiitaの24日目として投稿しています。
SRE風のインフラエンジニア
ここ数年で、SREという言葉が注目されていて色々な組織でSREチームが立ち上がっています。
特に、インフラチームが名前を変えてSREチームとなるケースは多いのではないかと思います。私もそうです。
この投稿では、DevOpsに対する考え方を通してインフラエンジニアではなくSREエンジニアがどう考えて働いていけば良いかということをまとめていきたいと思います。
SREとDevOps
そもそもDevOpsとは
DevOpsという言葉が生まれて随分立っていると思うので本稿を読む方にとっては釈迦に説法かもしれませんが、一応振り返って見ます。
DevOpsはDev(開発者)とOps(運用者)の境界を無くしていくことにより、提供しているサービスの価値を上げていく取り組みです。
Ops側の視点での安定性の考え方を改める
まず、ミクロなOpsの目的として挙げていた、可能な限り、システムに変更を加えたくない、は正しくありません。短期的にはそれで問題ないとしても、長期的には必ず問題を引き起こします。極端な例を挙げるとすれば、何年も新規リリースをせずに放置されていたシステムにはもう修正は入れられない、といった具合です。(しかも、そんな感じのシステムは意外に存在します)
次に考えるのは、100%安全なリリースを、ある程度の長すぎないスパンで行う、といった試みかもしれません。が、これもまた間違いの一つです。100%安全なリリースは存在せず、また、100%に近づけるためのコストは指数関数的に増加してしまうからです。
システムを高速に更新可能にしておくことで安定性を担保する
100%安全なリリースは存在しないし、未来永劫新規リリースを行わないプロダクトは存在しないので、なるべく高速に更新可能な状態をキープすることが重要になります。これが実現できていれば、コスト的に見合うだけのQAを行なった後はさっさとリリースして、問題があったら速攻でロールバックや修正のリリースを行えます。
これがシステムを安定させるための解です。
インフラエンジニアではなくSREとしてどう高速リリースを実現するか
class SRE implements DevOpsとGoogleが言っているように、DevOpsはインターフェースとしてシステムを高速に更新可能にしておくことで安定性を担保するということを定義しているが、SREはそれを実現するもの(実装)であると考えられます。
そのため、実装方法はプロダクトや組織によって多種多様になると思います。ここで、今までのインフラエンジニアという保守や管理がメインの立場から一歩踏み出し、DevとOps、もしかするとビジネスサイドなどの境界を飛び越えてどこを改善すれば、プロダクトの高速リリースの実現と安定化を達成できるか、ということを考えていく必要が出てきます。
いくつかの例をあげていきたいと思います。
プロダクトの高速リリースに効くところを見極める
ひとえにリリースの高速化といっても具体的に何を高速化するのか？は考え所です。インフラだけ担当していると割と見えにくいのですが、CI/CDの改善や、開発環境の充実、QA環境の充実、といったあたりがかなり重要ではないかと思います。これらの要素は、本番環境に比べれば軽視されがちだったりしますが、本番環境を安定させるためにも超重要な項目であるという認識を持ちましょう。
また、SREやインフラエンジニアの視点から見るDevはサーバーサイド開発者であることが多いと思いますが、もしモバイルアプリを提供しているサービスであればクライアントのエンジニアもDevであり、アプリケーションのリリースサイクルを考える一員であることを忘れないことも大事です。よく話して見ると意外とSREチームが解決できる問題を抱えていたりすることがあると思います。
リリースするにあたっての心配事を潰す
いざ新機能をリリースして見たら全サービスが落ちてしまった、なんて経験をした開発者であえば、リリースが怖くなります。こういった心理的な障壁も高速リリースに対する壁であると思います。これに対しての施策はいくつもあると思いますが、大きな修正を小さく試せるカナリアリリースや、一部の機能が落ちても全体としてはサービスが提供できるようになるためにサーキットブレイカーを導入するといったことが効果があります。
また、リリースに際して怖いものの一つに、プロダクション環境のデータでしか再現できないようなバグ、があります。これに関してもプロダクションと同等のデータを扱える検証環境が用意されていればかなり安心してリリースが行えるようになります。
もう一点大事なのが検知システムで、システムが正常に動作しているかをいち早く検知できる仕組みが整っているかどうか、という点も重要です。
Chaos Engineeingしてみるのも一つの解ではないでしょうか。
開発チームが自律して動ける仕組みやツールを提供する
SREチーム無しでも完結できる作業を増やすための仕組みやツールを提供することも重要です。全ての構成がコード化されていたり、クラウドサービスを利用しているのであれば十分可能だと思います。
また、監視アラートの対応についても事前に十分なドキュメントや対応ルールが決まっているのであればSREチーム無しでも十分対応可能なものは多いです。
ただし、注意したいのは、十分なコミュニケーションや準備無しでこれをしようとするとアラートの押し付け合いに発展したり、お見合いが発生します。
今の組織でやれていること
色々と偉そうに書いてきたものの、私が所属しているチームで全てやれているというわけでもありません。ですが、結構いい動きができているなあと思う点もあるので紹介したいと思います。
開発チーム出身の人がSREチームにジョインしてくれている
DevとOpsが融合するための一番手っ取り早い方法だと思います。
SREチームに入る新人のエンジニアさんもRails研修などを通して最低限の開発力を持っている
これも非常にいいことで、問題が起きた時にコードまでちゃんと読めるとか、そういった素地を最初に作ってもらっています。
SREチームのケツを叩いてくれる人がいる
やはりどうしても100%開発に従事しているわけではないので、Devチームが困っていることを十分理解することは困難です。そんな時にしっかり要望を投げつけてくれるDevチームがいることが一番大事ではないかと思います。DevとOpsはお互いに忖度無しに要望を投げつけあうくらいの方がうまくいくと思います。
今の組織でこれからやってみたいこと
SREチームからの短期留学
SREチームへの短期留学はたまに聞きますが、SREチームから開発チームへの短期留学ってあまり聞かないかなと思っています。
やっぱり身を以て他のチームがどんな苦労をしているかを理解することがチーム間の境界を無くすことに繋がるのでチャンスがあればやりたいと思っています。
まとめ
インフラエンジニアからSREエンジニアになって3年くらい経ちますが、色々と感じてきたことを書いて見ました。
私が経験してきたインフラエンジニアの考える安定性が守りの安定性であれば、SREとして考えるべき安定性は攻めの安定性と言えるんじゃないかと思います。
