従来のシステム運用のデメリット
次に、従来のシステム運用のデメリットについて考えましょう。SRE本では、従来のシステム運用のデメリットについて「直接的」「間接的」の2つに分けて論じています。
直接的なコスト
前述したシステム運用を手作業で行っていた場合、システムが大きくなればなるほど、比例して作業量が増加します。ユーザーが増えれば、それに伴い管理するサーバは増えるでしょうし、開発に関わるソフトウェアエンジニアが増えれば、変更頻度が増えることにより障害発生頻度も増加するでしょう。それにより、システム管理者をたくさん雇用しなければなりません。
間接的なコスト
従来のシステム運用では、DevとOpsが、時に対立的にならざるを得ない場面があります。開発した修正を次々にリリースしたいDevに対して、安定してシステム運用するために変更頻度を減らしたいOpsとでは、修正変更を行うことに対するスタンスが真逆です。そのため、時に利害関係解消のための、コミュニケーションコストが発生することがあります。これをSRE本では、間接的なコストと呼んでいます。
SREと従来のシステム運用との違い
SREの話に戻ります。SREは従来のシステム運用が抱える これらのデメリットを解消するための方法論を持っています。
まず、システム運用に伴う作業の多くをエンジニアリングによって効率化・自動化を行います。エンジニアリングによって効率化・自動化された作業には、人手による作業を削減・もしくは撲滅することができます。ですので、システムが大きくなることに伴う直接的なコスト（人件費）の増加速度を低減させることができます。
また、SREでは、エラーバジェット（エラー予算）の考え方を採用することで、前述した対立構造を解消します。エラーバジェットとは文字通り、エラーの発生を予算のように扱う考え方です。エラーが発生すると予算が減り、予算がなくなりそうになると、Devは新しい変更をリリースせずに、既存のエラーに優先対応します。こうすることで、DevもOpsもエラーバジェットという共通目標に向き合うことで、協力的な関係が生まれます。
ここまでで、SREが従来のシステム運用の考え方に対して、どのようなメリットがあるかをご紹介しました。SREは、従来のシステム運用と完全に異なる概念ではなく、これまで存在していたシステム運用における問題を解消するための、延長線上にある考え方だとお分かりになると思います。「SREは、ソフトウェアエンジニアに運用チームの設計を依頼した時にできあがるもの」という言葉の意味を少しでも感じ取っていただければ幸いです。
SREとDevOpsは何が違うの？
さて、ここまで読みながら「運用作業の自動化は、私たちの会社でもすでに実践している」や、「そもそも、それってDevOpsと何が違うのですか？ DevOpsもDevとOpsの関係性に焦点を当てた考え方で、同じものではないですか？」といった感想をお持ちの方もいらっしゃるのではないかと思います。
たしかに、前述したような運用業務の効率化・自動化や、DevとOpsの連携については、DevOpsという文脈で散々議論されてきました。
例えば、以下に紹介するのは、Flickerのエンジニアが2009年に発表した、DevOpsの原典とも呼ばれる資料です。 まさに本記事で書いたDevとOpsの対立をどのように解消するかについて述べられています。
10枚目のスライドに「Dev's job is to add new features」「Ops’ job is to keep the site stable and fast 」と書かれています。この描写は、前述した、従来のシステム運用業務が抱える間接的なコストと同じです。どうやら、SREとDevOpsは非常に近い問題意識を持つ用語だと言えそうです。ここで、「なーんだ、似たような用語か、じゃあなんとなく分かったからいいや」で終わらせてはいけません。専門用語の曖昧な理解は、専門家間での溝をつくることになりかねません。
