アドベントカレンダー1日目：SREを読んでみた「はじめに」編

今日からアドベントカレンダー方式でオライリーから出版されている「SRE サイトリライアビリティエンジニアリング」を読んだ感想を書いていこうと思います。
できるだけ章ごとに投稿しようと思いますが、内容がかなり濃いので、1～2日で一章できればいいかなと思ってます。
ちなみにページ数は本文だけでも500弱あり、章立ては34章に分かれています。

この本を読む理由

上司から今後のキャリアについて考えていることを聞かれた時、インフラに興味がありますと伝えたところ、会社からこの本を買っていただき、かなり読みごたえがある本ですが、これを機に本格的に勉強してみようと思ったからです。

読む前に

SREという言葉は、ほとんど知らなかったので、まず簡単に検索してみました。wikiによると

Google社が提唱、実践しているシステム管理とサービス運用の方法論である¹

一般で言われているdevopsと何が違うのかということにまず疑問を持ちました。
単にGoogle社のインフラのベストプラクティスという一番浅い理解から読み始めてみようと思います。

##「はじめに」を読む

ソフトウェアエンジニアリングについては、誕生後に比べて誕生前についての議論にはるかに多くの時間を費やすものの、システムのトータルコストの４０％～９０％は、そのシステムの誕生後に生じるものと推定されます。²

４０％～９０％とかなり幅がありますが、システムが長く続くことができるかによって、ブレが出るのかなと思いました。いずれにしても、システムが続けば続くほど、運用コストの比重が大きくなっていくはずなので、コストの多くが運用に割かれるのは、納得できます。

この業界に広く見られる視点では、デプロイされ、運用されているソフトウェアをプロダクション環境下で「安定している」とみなし、したがってソフトウェアエンジニアからの注意はそれほど必要ないものと考えますが、それは間違っています。²

いきなりガツンと言われてしまいました。仕事上プロダクション環境を触ることがありますが、プロダクション環境はなんとなくきれいで、開発環境はよく触るので、汚れているというイメージを持っていました。どのような環境も壊れる可能性があるということを忘れてはいけないと思いました。というかよく触っている環境ほど手入れされていると考えることもできるので、動いているから触りたくないという怯えも自分の中にあることに気づきました。

（↑の引用の続き）この視点に立つと、もしもソフトウェアエンジニアリングがソフトウェアシステムの設計と構築に焦点を当てる傾向があるのなら、そもそもの始まりからデプロイと運用、改善、そして最終的に迎える平穏な撤去に至る、ソフトウェアのライフサイクル全体に焦点を当てる、もう一つの分野が見えるはずです。²

この分野がいわゆるSREということなのだそうです。システムの誕生にあたり過ぎている焦点をシステムの一生に目を向けた分野と理解しました。しかし、じゃあ実際にどんなことをするの？という指摘にははっきりと答えることができないと書かれています。GoogleのSRE担当もどんな仕事をしているのかをよく聞かれるそうです。

SREのタスクの例が書かれます。

まず何よりもSREはエンジニアです。私たちは、コンピュータサイエンスとエンジニアリングの原則を、概して大規模な分散型のコンピュータシステムに適用します。ときにはGoogleの開発担当者と共に、そういったシステムの為にソフトウェアを書くことがタスクになります。またある時には、そういったシステムが必要とするバックアップやロードバランスのようなあらゆる付加的な各種ソフトウェアを、できればシステム間にわたって再利用できるように構築することがタスクになります。またある時には、既存のソリューションを新しい課題に適用する方法を見出すことがタスクになります。²

SREの役割の広さが伺えます。運用を考えたときにできることはなんでもするみたいに思えます。何かしらの観点でどこまでを行うのかは、区切っているはずなので、今後読み進める中で確認していきたいです。

信頼性こそあらゆるプロダクトの基本的な機能だと考えてます。誰も使えないシステムは、有益なものではありえません。信頼性は非常に重要なので、SREはシステムのスケーラビリティ、信頼性、効率性を向上させるために、その設計と運用の改善方法を見つけることに集中します。とはいえこの改善努力は際限なく行われるわけではありません。システムが「十分な信頼性を持った」なら、私たちは機能の追加や新プロダクトの構築のために力を注ぐのです。²

SREでは、特に信頼性に重きを置きます。名前にも信頼性を含むくらい、信頼性が大事です。
信頼性とはシステムが求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こすことなく実行する確率と定義されています。
十分な信頼性とは、何％くらいなのでしょうか？
開発初期は低くて当然ですし、そうだとしても問題ないと思います。運用中はそれこそ１００％に近ければ近いほどいいはずです。
ただ、メンテナンスなどで計画的に止める場合は、信頼性の値は下がるのでしょうか？これも後々読み進める中で確認していきたいです。
また、十分な信頼性を持ったなら、機能の追加などを行う、日頃から課題を見つけて、改善する。これは自分に足りない力なので、意識していきたいポイントです。

私たちの名前の中の「サイト」は、もともとgoogle.comのWebサイトを動作させ続けるというSREの役割を指すものでした。²

ここでSREのサイトの意味が分かりました。サイトとは、google.comのことでした。googleが大きくなるにつれて、様々なサービスが誕生し、それらを「動作させ続ける」役割となっていったのでしょう。

ある程度小さな組織においては、本書で紹介されているような経験を最大限に活用すべきか疑問に感じる向きもあるでしょう。
しかしセキュリティの場合と同様に、信頼性についても考慮するのは早ければ早いほどいいのです。すなわち、小さな組織には緊急性のある多くの懸念事項があり、選択するソフトウェアもGoogleとは異なるかもしれないとはいえ、早い段階で負担の軽い信頼性への取り組みを始めておくことには十分な価値があります。²

そうですね。何事も先手先手が重要です。
泣き言ですが、開発を進めている時、目の前のことに集中しているので、先のこと（運用）を考えられないことが、よくあります。これを機に運用の視点やどう考えるべきかを学んでいこうと思います。

まとめ

• SREは、信頼性に重きを置く。信頼性とは、条件を満たしながら、システムを動かし続けること。
• SREは、システムの一生を見据えて、それを動作させ続ける役割を持つ。

雑感

まずは、SREの役割やどういうものかを少し理解しました。
重要だと思う箇所が多すぎて、引用が多い内容になってしまいましたが、「はじめに」については、これで終わりです。
次回は、1章イントロダクションについて、書こうと思います。

引用

1. 「サイトリライアビリティエンジニアリング」（2020年12月03日 (日) 23:13）フリー百科事典『ウィキペディア（Wikipedia）』
2. Betsy Seyerほか　SRE サイトリライアビリティエンジニアリング　オライリー　xiii-xiv