Work Records

日々の作業記録です。ソフトウェアエンジニアリング全般から、趣味の話まで。

SRE風のインフラエンジニアにならないために

この記事は、SRE Advent Calendar 2018 - Qiitaの24日目として投稿しています。

SRE風のインフラエンジニア

ここ数年で、SREという言葉が注目されていて色々な組織でSREチームが立ち上がっています。
特に、インフラチームが名前を変えてSREチームとなるケースは多いのではないかと思います。私もそうです。
この投稿では、DevOpsに対する考え方を通してインフラエンジニアではなくSREエンジニアがどう考えて働いていけば良いかということをまとめていきたいと思います。


SREとDevOps

そもそもDevOpsとは

DevOpsという言葉が生まれて随分立っていると思うので本稿を読む方にとっては釈迦に説法かもしれませんが、一応振り返って見ます。
DevOpsはDev(開発者)とOps(運用者)の境界を無くしていくことにより、提供しているサービスの価値を上げていく取り組みです。

SRE本でも取り上げられている、DevとOpsの目的の差異

マクロで見るとサービスの価値を上げたいことで目的が一致しているものの、ミクロで見ればDevとOpsで思惑が異なってくることが問題になります。

ミクロなDevの目的

新しいコードをどんどんリリースしてサービスを発展させていきたい。そのため、可能な限りリリースサイクルを高速にしたい。

ミクロなOpsの目的

システムを安定化させることが第一命題。そのため、可能な限り、システムに変更を加えたくない。

この両者の矛盾を解決するのがSREとしての役割です。



Ops側の視点での安定性の考え方を改める

まず、ミクロなOpsの目的として挙げていた、可能な限り、システムに変更を加えたくない、は正しくありません。短期的にはそれで問題ないとしても、長期的には必ず問題を引き起こします。極端な例を挙げるとすれば、何年も新規リリースをせずに放置されていたシステムにはもう修正は入れられない、といった具合です。(しかも、そんな感じのシステムは意外に存在します)

次に考えるのは、100%安全なリリースを、ある程度の長すぎないスパンで行う、といった試みかもしれません。が、これもまた間違いの一つです。100%安全なリリースは存在せず、また、100%に近づけるためのコストは指数関数的に増加してしまうからです。

システムを高速に更新可能にしておくことで安定性を担保する

100%安全なリリースは存在しないし、未来永劫新規リリースを行わないプロダクトは存在しないので、なるべく高速に更新可能な状態をキープすることが重要になります。これが実現できていれば、コスト的に見合うだけのQAを行なった後はさっさとリリースして、問題があったら速攻でロールバックや修正のリリースを行えます。
これがシステムを安定させるための解です。

インフラエンジニアではなくSREとしてどう高速リリースを実現するか

class SRE implements DevOpsGoogleが言っているように、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として考えるべき安定性は攻めの安定性と言えるんじゃないかと思います。



Site Reliability Engineering: How Google Runs Production Systems (English Edition)

Site Reliability Engineering: How Google Runs Production Systems (English Edition)

The Site Reliability Workbook: Practical Ways to Implement SRE

The Site Reliability Workbook: Practical Ways to Implement SRE

  • 作者: Betsy Beyer,Niall Richard Murphy,David K. Rensin,Kent Kawahara,Stephen Thorne
  • 出版社/メーカー: O'Reilly Media
  • 発売日: 2018/08/04
  • メディア: ペーパーバック
  • この商品を含むブログを見る