ビズリーチの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をゲットしました!!!
I got Launch Day Edition! #SRE #GoogleNext18 pic.twitter.com/rbZzSVxphk
— (* sakamoto *) (@sakamoto_desu) 2018年7月26日
参考
- What’s the Difference Between DevOps and SRE?
- Solving Reliability Fears with Site Reliability Engineering (Cloud Next ‘18)
注記
本記事の画像資料は全てビズリーチ社が作成したものです。
-
Glass, R.(2002). Facts and Fallacies of Software Engineering, Addison-Wesley Professional; p. 115. ↩︎
-
Dehaghani. S. M. H., & Hajrahimi, N. (2013). Which Factors Affect Software Projects Maintenance Cost More? Acta Infomatica Medica, 21(1), 63-66. ↩︎
-
SLO:Service Level Objective(サービスレベル目標), SLI:Service Level Indicator(サービスレベル指標), SLA:Service Level Agreement(サービスレベル契約) ↩︎
