皆さまは昨今のITサービス開発・運用において重要な考え方としてよく取り上げられる「SRE」について皆さんはご存じでしょうか。

本記事では、SREとは何なのか、DevOpsとの違い、具体的な実践方法など知っておくべき基礎知識をご紹介します。

SREとはITシステムの開発と運用をつなぐ手法

SREとは、Site Reliability Engineering（サイト信頼性エンジニアリング）の略で、2004年にGoogle社のBenjamin Treynor Sloss氏によって提唱されました。平たく言えば、大規模かつ複雑なシステムを運用するにあたって、安定性を確保するべく開発側のITエンジニアがシステムの運用に参画するための手法、あるいはそれを行うためのエンジニアチームや人(Site Reliability Engineer： サイト信頼性エンジニア)を指します。

従来、ソフトウエア開発フェーズと運用フェーズの分断が存在していたことで生じていたのが、開発チームと運用チームの対立やシステムの複雑化や機能追加に伴う運用負荷の高まりでした。製造業のシステム導入にあたってもこれまで、開発フェーズはSIerに委託し、運用は社内エンジニアが行うという体制になることは少なくありませんでした。その結果、運用時の負荷が増大することを懸念して、改変や機能追加に及び腰になる、あるいは、開発時に運用負荷に対するアプローチが十分に行われないという現象が生じることも。これは、レガシーシステム問題や、労働生産性の低さといったマイナスの影響を日本の産業全体に及ぼしているはずです。
運用・保守のコストが膨らんでいくこと、システム変更に抵抗する流れが生じることの両方に対抗するための方法論が、SREと言い換えることもできるでしょう。

SREとDevOpsはどう違う？

SREの概念を聞き、「DevOps」という言葉を思い出す方も少なくないでしょう。
両者は重なる部分も大きく完全に峻別できるものではないと、当のGoogleが無料公開しているSREについての解説書『Site Reliability Engineering』（O'Reilly Media、2016）でも示しています。DevOpsが前述の問題を回避するため、「開発（Development）と運用（Operation）が協調する」という「状態」を指すのに対し、SREはより具体的なルールの設定方法やチームの作り方をメソッド化したものであるといえるでしょう。

SREの重要性はその具体性やGoogle自身が方法論を豊富に公開しており資料にあたりやすいということですが、それはGoogle流のやり方であり、そのまますべての企業に応用できるわけではないということでもあります。

DevOpsを自社のシステム運用に応用するため、SREを「使う」というのがスタンダードな取り入れ方でしょう。

SREを実践するための具体的手法

それでは、具体的なSREの実践手法を見ていきましょう。

SREにおいてまず必要とされるのが、“100％信頼のおける、すなわち問題の生じないシステムは存在しない”と認めることです。運用チームがシステムの安定運用を求めるあまりシステムがどんどんレガシー化していってしまえば、結果としてシステムの有用性も低下していってしまいます。そこで、「100％ダウンしないシステム」を前提とするのではなく、どれだけのリスクを許容できるのか、回復力が求められるのかなどについて定義する必要があります。

その定義のためのツールとしてSREで用いられるのが以下の三つです。

• SLI（service level indicators：サービスレベル指標）
• SLO（service level objectives：サービスレベル目標）
• SLA（service level agreements：サービスレベルについての合意）

SLIはエラー率やITシステムが利用可能な時間など、直接的にサービスの信頼性を測るために用いられる指標です。ここで、サービスの安定性と変化のバランスを取れる指標を設けることがSRE実現のカギとなります。そうして定められるSLIの目標値が、SLOです。SLOはシステムの利用のされ方によって、何度も更新されることになるはずです。SLAはSLOを達成できなかった場合の対応についてのユーザーとの合意を意味します。

SREはGoogleで開発された手法であり、基本的にはITベンダーによる活用を想定していますが、システムユーザー側であるものづくり企業も本記事の知識を踏まえることが、適切なSLI、SLO、SLAの策定につながるはずです。

なお、GoogleのSREでは、手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増加するといった特徴を持つ作業をtoil（「労苦」の意）と呼び、業務全体の50％以下に抑えることで開発と運用のバランスを取っていると言います。

安定性と変化の綱引きは常に生じている

ユーザー企業でも知っておきたいSREの基本について解説しました。開発側、運用側、あるいはベンダー側、ユーザー側という隔たりがITシステムに与える弊害を排除しようという試みはこのように発展してきています。
安定性と変化の綱引きは常に生じているということを意識し、IT環境の整備・あるいは提供に取り組んでみてください。