SREとDevOpsの違いに対するGoogleの解説
ではここで、SRE本家のGoogleが、SREとDevOpsの違いに対して、どのように回答しているかをご紹介します。
この動画は、Googleが公開しているYouTubeの動画で、「What's the Difference Between DevOps and SRE?」というタイトル通り、SREとDevOpsの違いについてGoogleのエンジニアが解説をしています。
この動画の中で、「class SRE implements DevOps」というメッセージが登場します。エンジニアの方にとっては馴染みやすい解説ではないでしょうか。つまり、SREがDevOpsを実装している、とする考え方です。動画内では、「DevOpsを哲学とするならば、SREはその哲学を達成するための規範的な方法です」とも解説されています。
また、動画の後半では、「しかし、プログラミングのクラスがそうであるのと同様、class SREには、追加の機能やメソッドがあるかもしれない」と補足されています。要するに、SREは、DevOpsを推進するための実装も行いますが、それだけではなく、本記事で散々述べてきたような従来のシステム管理の役割も担う、ということでしょう。
SREとDevOpsの違いについてご理解いただけたでしょうか？
SREに取り組む前に考えるべきこと
ここまででSREについての基礎的な知識や、SREが誕生した文脈をご紹介しました。最後に、これからSREをはじめる人が考えるべきことを2つ述べて記事を締めくくります。
SREを取り入れるメリットについての期待値コントロールを行う
オジサンの説教じみた内容で恐縮ですが、エンジニアの仕事に限らず、仕事においては期待値コントロールを適切に行うことが重要です。特に、組織で新しいことを始める場合はなおのことです。
期待値コントロールができていない状態で実践に移し、失敗すると「なんだ、うちではSREってのはやっても効果なかったし、無理だったんだね」と言われてしまうかもしれません。こんな様子では、新しいことをはじめようとしていたメンバーの士気も落ちてしまうでしょう。
そこでオススメしたいのが、みなさんの会社においてSREを取り入れるメリットを改めて整理することです。本記事では、従来のシステム運用の考え方に対し、SREの考え方を取り入れるメリットをご紹介しましたが、実践することで得られるメリットはみなさんの会社それぞれで微妙に異なっているはずです。
メリットの整理や提案を誤ると、そもそもSREを取り入れてはいけない、と上司に一蹴されてしまう可能性だってあるでしょう。例えば、みなさんの会社が、システムの運用に関わる人月計算でビジネスが動いているとしましょう。そこで、「SREを取り入れて、運用工数を削減しましょう」と提案しても、「そんなことをしたらうちのビジネスが縮小するだけでは？」と、SREに否定的な態度を取られてしまう可能性だってあります。
ソフトウェアエンジニアが運用を設計することのメリットは、必ずしも効率化や自動化だけではありません。メリット・デメリットの整理はみなさんご自身の組織やチームを見渡しながら考えてみてください。「いま、組織でこういう問題が起きているけど、SREの考え方を取り入れれば解消するのでは？」「うちの場合は、SREを取り入れるメリットが適切に発揮できそうだ」などきっと色んなアイデアが思い浮かぶことでしょう。
このプロセスを、仕事のための仕事と一蹴するか、納得して実践していただけるかは読者のみなさまにお任せしたいと思います。
一点、ご参考までに補足しますが、SREを取り入れる際に組織規模は関係ありません。ソフトウェアエンジニアの考え方を以てシステム運用を設計する原理原則に従うことに、組織やチーム規模は関係ないからです。
Google SREとの差分を意識しよう
SRE本は、各章それぞれがエッセイ（小論）で構成されています。それぞれがSREの原理原則に従いGoogle社内で実践されてきたプラクティスですが、厳密で学術的なものではありません。
ですので、Googleのプラクティスはもちろん大いに参考すべきですが、必ずしもGoogle SREと全く同じ実践をする必要はありません。そのためにも、Google SREと自分たちとの差分を意識するとよいでしょう。
例えばSRE本では、分散化されたシステムという表現が何度も登場しますが、みなさんの会社で扱うシステムは適切に分散化されているでしょうか？ Googleほど分散化されたシステムの構築に長けた企業は、めったにないでしょう。分散化されたシステムの知見がない状態で、いきなりSRE本の真似をすべてするのは非常に大変です。
であれば、モノリシック（一枚岩）なシステムで、同様のプラクティスに落とし込むには、どう考えればよいか、をみなさん自身の会社で実践すればよいのです（もちろん最終形としてGoogleの分散化されたシステムを意識することは全く悪いことではありません）。
他にも、みなさんの会社では、SRE本に記載された規範的な方法がうまくはまらない可能性もあるでしょうし、それはそれで全く問題ないのです。
SRE本の出版は、世の中の他の企業からもたくさんSREに関するプラクティスを生み出して欲しいというGoogleの想いが込められていると筆者は感じています。
さいごに
Googleと言えば、エンジニアリングばかり注目されがちですが、SREに関して理解を深めると、組織運営のプラクティスも非常に先進的な企業であることが分かります。
筆者は、過去参加したGoogleのカンファレンスにて、Google社員の方が「Googleはボトルネックを発見し、それを解消するために0から考えることを厭わない企業である」「また、そのためのボトルネック発見が非常にうまい企業だと中から見ていて感じる」と発言していらっしゃるのを聞いたことがあります。SREの考え方も、まさにボトルネックを解消するための一つの方法論ではないかと思います。
世の中のすべての企業が、SREという役割や名称を引き継ぐかどうかは分かりませんが、多かれ少なかれ、SREの考え方に影響を受ける企業は増えていくと感じます。
次回記事では、SREをどのようにはじめていくか？ について具体的に紹介をします。お楽しみに。
