SREとは？ DevOpsとの違い、特徴、メリットをわかりやすく解説

SREとは何か

SRE（Site Reliability Engineering）は、Google社が提唱するシステム管理・サービス運用の方法論で、日本語では「サイト信頼性エンジニアリング」と訳されます。開発担当と運用担当が連携し、システムの信頼性を高めて安定稼働を実現しながら、新機能の追加やサービス改善を円滑に行い、UX（ユーザー体験）を高めることを目指します。

現代では、信頼性と作業効率を両立したシステム開発が求められています。定型作業の自動化や各種指標の計測を行うSREの導入によって、企業競争力のさらなる強化に期待が寄せられています。

SREとDevOpsは何が違うのか

SREの概念は、開発（Development）と運用（Operations）を組み合わせた「DevOps」と混同されがちですが、Google社では両者の違いについて「class SRE implements DevOps」という考え方を打ち出しています。これはオブジェクト指向プログラミングになぞらえた表現で、要するに「DevOpsで示された抽象的な概念を、SREで具体的に実践する」という意味です。

つまり、DevOpsでは開発担当と運用担当が一体化して業務の効率化を図ることを目指すのに対して、SREでは、自動化ツールで運用タスクの処理速度を上げつつ、システムの信頼性を高めることを目指します。両者とも、企業競争力を高めるために開発運用のアジリティを高める（市場の激しい変化に機敏に対応する）という意味では共通しているといえます。

SREを実践する際に注意すべきこと

SREを実践しているにもかかわらず期待するような効果が得られない場合には、SREの「本来の目的」や「取り組み方」に関して誤解がある恐れがあります。ここでは、SREを実践する際に注意すべきことを2点お伝えします。

SREの「本来の目的」を理解する

サイト信頼性エンジニアリングという名称のとおり、SREには「信頼性」をシステムの重要機能の一つとして位置づけているという特徴があります。そこで信頼性を高めるために、エラーの発生を限りなくゼロに近づけるなど、理想的な目標を設定することに固執して、かえって現場の混乱を招く結果に陥っている場合があります。

しかし、SREの本来の目的は単純な信頼性の向上ではなく、極端に高い指標を追いかけることでもありません。ユーザーが一定の満足度を得られるサービス運用を実現しながら、開発のライフサイクルを高速化し、開発運用のアジリティを高めることです。あくまでも、高すぎない目標値の下でトイル（手作業で繰り返し行われる運用作業）の自動化を進め、システムの改善とサービスレベルの向上におけるトレードオフに挑むことが大切だといえます。

このようなSREの本来の目的を踏まえつつ、サービスレベルの評価を行う必要があります。

SREチームづくりは「最初の一歩に過ぎない」と認識する

SREでは、複数部署の担当者同士が連携することが求められます。そのため、「SREの実現」という共通目的を持った専門チームの構築が不可欠であり、SREの実践にあたっては、部署をまたいだSREチームを構築するところから始めます。

ただし、せっかくSREチームを構築したにもかかわらず、うまく機能しないというケースは珍しくありません。SREを適切に機能させるためには、チームの人材選定に加え、「チーム構築後の運用方法」と「会社全体でSREを支える組織文化」が重要です。

SREは、継続的な実践によって精度の向上が見込める、中長期的な取り組みです。そのため、チーム内での役割分担や会議の頻度など、運用に関するルールが明確でなければ停滞しやすくなる恐れがあります。また、何より重要なのが組織文化です。SREの成功には社内各所からの協力が欠かせないため、SREのメリットや成果を広く伝えるなどして、組織全体でSREを推進していこうとする文化を根気強く醸成する必要があります。

ただSREチームをつくって満足するのではなく、その後のチーム内外に対する働きかけを適切に行うことで、より円滑なSREの実践が可能です。

SREの実践に欠かせない要素

SREを実践する際には、サービスの信頼性を維持するための指標を定め、継続的に測定する必要があります。ここでは、そのために欠かせない4つの要素を紹介します。

CUJ：ビジネス視点で重要な箇所に焦点を当てたカスタマージャーニー

製品・サービスの発見から購入後の行動に至るまで、ユーザーがたどる一連の購買体験を「旅」に例えて「カスタマージャーニー」と呼びます。CUJ（Critical User Journey）は、そのカスタマージャーニーの中でも特にビジネスの観点で重要な部分に焦点を当てたもので、ユーザーが頻繁に行う作業や重要な操作が選定されます。例えば、ECサイトの場合だと「ログイン」「商品の検索」「カートへの追加」「決済」といった行動が該当します。

分析手順としては、まず分析目標の設定やペルソナ設計、データ収集、ユーザーのセグメンテーションなどの下準備を行います。そして、タッチポイント（企業との接点）とユーザーの感情などをマッピングして視覚化し、どの体験がユーザーにとって重要度の高いものなのか、ビジネスの観点で影響が大きいのかを検討し、モデル化します。

ここでモデル化された行動が、当該サービスにおけるサービスレベルの観測ポイント（SLI：サービスレベル指標）となります。

SLI：サービスレベル指標

SLI（Service Level Indicator）は「サービスレベル指標」と呼ばれ、システムの品質を測定するための指標のことです。数値やパーセンテージなどで定量的に測定できることが重要です。用いられる指標の種類はサービスによって異なりますが、一般的には「稼働率」「エラー率」「スループット」「応答時間」といったメトリクスが用いられます。

SLIの設定時には、SLIに採用するメトリクスの数に注意が必要です。多すぎても少なすぎても重要な指標の検証が難しくなってしまうため、あらかじめCUJによって数を絞り込んでおくことが大切です。CUJに対してSLIを設定すれば、重要な機能がどれほどユーザーに提供できているかを計測することが可能です。

なお、SLIはSLO（サービスレベル目標）の達成状況を測定する指標です。例えば「月間の稼働率が99.00%」をSLOとして定めた場合、SLIはその値以上である必要があります。

SLO：サービスレベル目標

SLO（Service Level Objective）は「サービスレベル目標」と呼ばれ、SLIで選定した指標が目標とする数値のことです。例えばSLIを「エラー率」に、SLOを「0.1%未満」とした場合、1,000件のリクエストに対してエラーが1件もないことが目標となります。

目標といっても、SLOは理想的な数値で設定するのではなく、許容可能な最低限のレベルにするのが望ましいとされます。ユーザーが不満を感じていないのであれば、必要以上にリスクをとらず、さらなる機能の開発などに注力する方が、ビジネスの観点でよほど有益だと考えられるためです。そのため、例えば「1万件のリクエストに対してエラーが1件もない」といった、厳しい基準は求めません。

なお、リスクをとれる範囲のことを「エラーバジェット」と呼びますが、この許容範囲をいかに有効活用できるかが、開発運用のアジリティを高めるというSREの本質であるともいえます。

SLIとSLOの関係性をまとめると、以下の表のようなイメージです。

SLIとSLOの関係性（例）

	SLI	SLO
稼働率（可用性）	システムが継続して稼働可能な時間の比率	99.00％以上
エラー率	ユーザーからのリクエストに対するエラーの比率	0.1%未満のエラー率
システムスループット	単位時間あたりに処理が可能なデータ量	1万件/秒のリクエストを処理
リクエストのレイテンシ（応答時間）	ユーザーからのリクエストに対して、レスポンスを返すまでにかかった時間	平均1秒以内の応答時間

SLA：サービスレベル契約

SLA（Service Level Agreement）は「サービスレベル契約」という意味で、サービス提供者と顧客の間で交わされる、サービス品質に関する契約のことです。信頼性を保つための基準をSLIとSLOに基づいて詳細に定め、書面で締結します。

SLAはサービス提供者と顧客の権利と義務を明確にするものであり、定められた基準を満たせなかった場合には、何らかの補償が行われる場合が多くあります。例えば、SLIを「エラー率」に、SLOを「0.1%未満」とした場合、1,000件のリクエストに対してエラーが1件でもあったなら、サービス提供者は顧客に対して返金などの補償を行います。

もちろん、信頼性を保てないような状況が想定される場合には、補償を行う以前から迅速に対応する必要があります。SREでは自動でSLIの監視を行い、異常があれば即座にアラートを出したり、可能な範囲で自動対応を行う仕組みを取り入れたりします。

なお、SLAはビジネス上の契約であり、SREの核はSLIとSLOにあります。ただ、顧客側としてはそのサービスの可用性を測る一つの指標となるため、サービス選定時にはSLAの確認が必須です。

SREを成功させるためのポイント

SREを成功させるためには、常に起こり得る異常へ迅速に対応できる体制を構築しながら、可能な限りミスの起こらない環境を目指すことが大切です。それと同時に、SREという概念には誤解が生じやすいため、組織全体で正しい認識を持つ必要があります。

オブザーバビリティを高める

SREの成功には、高いオブザーバビリティの獲得が欠かせません。オブザーバビリティとは、システム上で起こった異常を通知するだけでなく、どこで何が起こったのか、起こった理由、解決方法を把握する能力を表す指標・仕組みを指します。「Observe：観察する」と「Ability：能力」を組み合わせた、「可観測性」を意味する言葉です。

SREでは、ユーザーが許容可能な範囲にサービス品質を収めつつ、高頻度で新機能の追加やサービスの改善を行い、UXの維持と向上を図り続けていきます。そのためには常にシステムの全体像を把握して、内部で何が起きているのかを詳細に知っておく必要があります。

オブザーバビリティを高めることで、膨大な情報の中から必要なデータを取得し、複雑なシステムの状態を可視化することができます。エラーとして表出した結果だけでなく、そこに至るまでの道筋をたどって原因を探り出せるため、予期せぬトラブルに対しても有効です。オブザーバビリティは、SREを実践する上で効果的な指標の計測や改善を進める強力な力となります。

オペレーションの自動化を進める

システムの安定稼働を実現するには、オブザーバビリティを高めるだけでなく、そもそもミスが起こりにくい環境をつくることも大切です。そのためには、可能な限り自動化を行って手作業を減らし、ヒューマンエラーのリスクを抑える必要があります。

例えば、インフラの構築と運用には、インフラ構成のコード化「IaC（Infrastructure as Code）」が役立ちます。人手でインフラを構築しようとすると複雑な手作業が求められ、大規模になるほどエラーが起こりやすいですが、IaCを導入すればコードの実行だけでインフラ環境を構築できるため、ヒューマンエラーの回避と迅速な環境構築が可能となります。

そのほか、頻繁に発生する手作業には「ランブック（手順書）」の活用も役立ちます。ランブックは業務手順を詳細に記した説明書のようなもので、例えば「WebサイトのSSL証明書の更新手順」「データベースのバックアップ手順」などを記載します。ランブックによって手順が明確化するため、作業品質が均一化できる上、ワークフローの自動化促進にもつながります。

組織全体が一丸となって取り組む

DX化が進んだ現代では、あらゆる業務の推進やサービス提供にIT技術が用いられており、システムの開発・運用体制の改善は組織の枠組みそのものを変えるほどに重要な課題であるといえます。そのため、組織全体が一丸となってSREに取り組む体制づくりは非常に重要です。

その試みとしては例えば、開発運用チームに対してSREのプラクティスや文化を浸透させ、SREの動き出しをサポートする「Enabling SRE」や、SREメンバーが各プロダクト開発チームに直接入り込み、運用現場の内情把握と実践サポートをより解像度高く行う「Embedded SRE」といったものがあります。

ただ、実際の現場でそういった試みが最初から適切に行えるとは限らず、SREがインフラエンジニアの業務やDevOpsと同じものだと誤解されることも少なくありません。そのような場合でも、SREの正しい知識や考え方を組織全体で積極的に取り入れていけるよう、根気強く啓蒙と実践を続けていくことが大切です。

SREを導入するメリット

SREを導入することで、企業はより一層、信頼性と作業効率を両立したシステム開発・サービス運用が可能となります。ここでは、SREの主なメリットを改めて紹介します。

システムの信頼性が向上する

SREの導入によって、システムの信頼性が向上します。各種タスクを自動化することで手作業による人的ミスや不具合の発生が抑えられるほか、SLIを監視してシステムの状態を定量的に管理することで、異常の検知や障害への初動対応もスムーズに行えます。そのため、新機能のリリース直後に起こりすいトラブルにも対応可能です。

ダウンタイムを最小限に抑えてUXを向上させることは、ユーザーとの信頼関係を構築する上でも重要であり、SREの大きなメリットであるといえます。

自動化により運用が効率化される

ログの監視など、定型的な運用作業の自動化が進められることで、運用チームは浮いた時間をより戦略的な業務に充てることが可能です。運用の仕組みを改善すれば、さらなる効率化の好循環を生み出すことにもつながります。

また、特にデプロイメントフェーズで数多く発生する細かいタスクの処理スピードを高めることで、開発を終えたシステムを素早くリリースできるようになります。

運用タスクの属人化を防げる

運用作業の自動化に取り組む過程ではタスク内容が明確化されるため、作業品質を均一化し、属人化を防ぐことにもつながります。知らず知らずのうちに属人化が起きていると、担当者の異動や退職・トラブル発生時に対応できず重大な損害を引き起こす恐れがあるため、気をつけなければなりません。

特に重要な業務で用いているシステムではもちろんのこと、属人化を防止するには、ささいな作業手順なども誰にでもわかるかたちで整理されていることが望ましいといえます。

システム開発運用のアジリティが高まる

SREでは、障害の原因分析や運用データの結果に基づき、システム開発運用プロセスの継続的な改善を行います。また、新機能を高頻度にリリースすれば、開発チームと運用チームの関わりが密になるため、開発と運用のいずれかの都合に偏りすぎることなく、より連携のとれた強固な体制を築きやすくなります。

SREの実践によって、長期的な安定稼働と効率的な開発体制の確立に期待することが可能です。このようなアジリティの高まりがSRE最大のメリットであり、本質であるといえます。

まとめ

SRE（サイト信頼性エンジニアリング）について、その意味や評価指標をはじめ、実践時の注意点、成功させるためのポイントなどについて詳しく紹介しました。システムの開発と運用の連携体制は以前から課題とされてきましたが、定型作業の自動化などによって効率的な監視・運用が実現できれば、密な連携体制を整えることが可能です。

SREによって、システムの信頼性を高めて安定稼働を実現しながら、新機能の追加やサービスの改善を行うことができます。結果としてUXが高まり、企業競争力の強化へつながることに期待が寄せられています。