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