DevOpsとSREの違いとは?

ビズリーチのSREチームでJenkinsおじさんとマネジメントを担当している阪本です。もう先月の話になりますが、サンフランシスコで開催されたGoogle Cloud Next ‘18に参加してきました。今回はその場で何度も聞いた class SRE implements DevOps という考え方を紹介させて頂きます。DevOpsとSREの関係性を理解する上で大変参考になりました。

DevOps、SREという単語が使われるようになって時間が経ちましたが、若干のバズワード感も否めず私自身混乱していました。そのような中でSREの草分け的存在であるGoogleが新たに class SRE implements DevOps というメッセージを発信し始めました。これは「SREはDevOpsというinterfaceの実装である」という意味で、いわゆるプログラミング言語の抽象化機能であるinterfaceを想像してもらえれば良いと思います。まずはDevOpsの起源について説明させて頂きます。

チーム間摩擦との戦い

Softwareは導入後のコストが40%1〜90%2を締めると言われていますが、実際には運用・保守ではなく設計・構築に重点が置かれていることが多いです。その考えはチーム構成にも反映され、歴史的にも開発チームが新機能を開発し、運用チームが本番環境にデプロイするスタイルが取られていました。この場合、運用チームが信頼性・保守・拡張性に責任を持ち、開発チームは迅速に新機能をリリースすることに責任を持ちます。しかし運用チームは安定性を目指すため頻繁なリリースを良しとせず、両チームが目指す方向がずれてしまいます。このスタイルはチーム間で多くの摩擦を生み、スケーラビリティではなく、壊れやすいモデルでした。

また摩擦が生まれるのは開発チームと運用チームの間だけではありません。ビジネスサイドが製品機能を計画し、開発チームが実装しますが、そこにもチーム間の摩擦があります。ビジネスと開発の摩擦を減らすのがAgileで、開発と運用の摩擦を減らすのがDevOpsという思想です。

DevOpsが扱う5つの領域

DevOpsが扱う5つの領域について説明します。それらは具体的なプラクティスではなく思想・方針なのでプログラミングにおけるいわゆるinterfaceとも見なせます。

  • Reduce organizational silos(組織のサイロを削減する)
  • Accept failure as normal(エラーが発生するのを前提とする)
  • Implement gradual change(段階的に変更する)
  • Leverage tooling and automation(ツールと自動化を活用する)
  • Measure everything(全てを計測する)

Reduce organizational silos

IT会社に限らずチーム間の溝が深まり連携ができなくなる現象をサイロ化と呼びます。DevOpsではまず、開発チームと運用チームの壁を壊し、チーム間のコラボレーションを促進します。

Accept failure as normal

なかなか理解してもらえない事実ですが、あらゆるシステムは必ず壊れます。そのためシステムでエラーが発生するのを前提として設計や運用を計画します。

Implement gradual change

変更を小規模にすることにより、導入やロールバック、切り分けが簡単になります。

Leverage tooling and automation

あらゆるツールと自動化を活用して効率化し、人為的なミスを減らします。

Measure everything

全てを測定します。これは上記4つの領域の成功させるために重要です。

How SRE implement DevOps

ここまでDevOpsの成り立ちと扱う領域についてお話しさせて頂きました。ではDevOpsとSREはどのような関係なのでしょうか?GoogleはDevOpsは思想であり、SREは役割であると提唱しています。その例えとしてDevOpsはinterfaceであり、その実装がSREである = class SRE implements DevOps というキーワードが使われています。以下では各DevOpsの領域に対するSREの役割=実装を例示しています。

DevOps SRE
Reduce organizational silos Share Ownership
Accept failure as normal Error Budget / Postmortem
Implement gradual change Canary Release
Leverage tooling and automation Automate common case
Measure everything Measure Toil and Reliability

SREは権限を開発チームにも拡張することによりサイロを壊します。エラーバジェットはエラーを計画的に受け入れ、ポストモーテムによりその原因を究明します。カナリアリリースによりリリース時のリスクを減らします。あらゆるトイル(手動作業)を減らし自動化します。それらの成果を確認するためにトイルや信頼性を計測し、SLO/SLI/SLA3を定めます。

これによって今まで「で、結局DevOpsってどうやるの?」っとなっていたものに対して一つ指標ができたのです!

まとめ

DevOpsはあくまで思想=interfaceであり、SREはその実装である、というこの説明は私にとってクリアにそれらの単語を説明するツールとなりました。プログラミング言語のような表現で説明するのもGoogleらしくて良いですね。SREに関しては新しい本 The Site Reliability Workbookも出てさらに洗練されています。今後も目が離せない分野となると確信しています。

ちなみに私はGoogle Cloud Next ‘18で無料配布していたLaunch day editionをゲットしました!!!

参考

注記

本記事の画像資料は全てビズリーチ社が作成したものです。


  1. Glass, R.(2002). Facts and Fallacies of Software Engineering, Addison-Wesley Professional; p. 115. [return]
  2. Dehaghani. S. M. H., & Hajrahimi, N. (2013). Which Factors Affect Software Projects Maintenance Cost More? Acta Infomatica Medica, 21(1), 63-66. [return]
  3. SLO:Service Level Objective(サービスレベル目標), SLI:Service Level Indicator(サービスレベル指標), SLA:Service Level Agreement(サービスレベル契約) [return]