SREとは？DevOpsとの違いや、実践で誤解しがちなポイントを解説

SREとは？DevOpsとの違いや、実践で誤解しがちなポイントを解説

SREは、Google社によって提唱されたシステム管理とサービス開発運用に関連するプラクティスです。「Webサイトの信頼性や安定性を高めるために行うもの」などと説明されることが多くありますが、これは本来のSREとは解釈が異なります。間違った認識でSREを実践しようとして効果的な成果が出せないというケースも少なくありません。そのため、SREを実践する前に、まずはSREについて正しく理解することが大切です。
ここでは、SREの意味や目的、DevOpsとの違いのほかSREを効果的に実践する方法について解説します。なお、本記事では技術的な内容についてはあまりふれず、主にビジネス観点を含めたSREの全体像の理解に焦点を当てています。

SREは「システム開発運用のDX」

SRE（Site Reliability Engineering）は、手間のかかる運用面をプログラムに任せて自動化し、ユーザーが満足できるサービスレベルを維持しながら、ソフトウェアサイクルをさらに高速化してシステムとビジネスのアジリティを高める取り組みを指します。つまり、SREを一言で表現すると「システム開発運用のDX」といえるかもしれません。

現代では、多くのビジネスがデジタル化され、WebサイトやWebアプリケーションを通じてサービスが提供されています。システムの信頼性や安定性はビジネスに直結するため、新機能の追加や更新だけではなく、エラー発生の抑制や障害復旧の短期化、事業の拡大・縮小に迅速に追従することなども重視しなくてはなりません。
しかし、多くの企業では、ひとたび障害が発生すると、その原因究明と対策に多大な時間と人手が割かれているのが実情です。異常を検知すると、優秀なエンジニアが膨大なログから原因と思われる点を探り出して、1つひとつ手作業で対応している企業も少なくありません。

そこで、不具合を検知して原因究明から対策までの時間を大幅に短縮することができれば、エンジニアは障害対応にかけていた時間を新機能の開発やブラッシュアップといった、よりクリエイティブな業務に注力できるようになります。さらにいえば、あらかじめシステムをスケーリングするように設計しておくことで、ビジネスの拡大とともにシステムをスケールさせる必要が出てきたときに、そこに関わる人手と時間を大幅に圧縮できます。

プログラミングは人間が楽になるために組み込まれたものであるにもかかわらず、その運用には多くの人手がかかっているのが現状です。それを変えるのがSREなのです。

SREとDevOpsの違い

SREとDevOpsはいずれも、開発運用のアジリティを高めてビジネスの価値を向上させる目的であることは共通していますが、SREは目標達成のためのプラクティスを指すのに対し、DevOpsは定義が定まっておらず一般的に概念を指します。
SREは、システムの信頼性に重きを置き、運用作業を自動化しながらソフトウェアのリリースサイクルの高速化にチャレンジする取り組みです。
一方、DevOpsは、開発・運用を連携または一体化しながら、開発から運用までの業務効率化と作業時間の短縮を図り、より洗練されたサービスをユーザーに素早く提供するという概念で、一般的には文化やツール、プラクティスを指します。
つまり、SREは、DevOpsに独自拡張を加えた1プラクティスと考えることもできます。

SREの実践におけるよくある誤解

「SREを実践しているけど期待するような効果が得られない」と悩む企業の声を聞くことがありますが、SREの目的や取り組み方の誤解によってSREの実践が難航しているケースも少なくありません。
SREを実践する際のよくある誤解について見ていきましょう。

SREの目的は「信頼性を高めること」ではない

SREの目的を単純に信頼性向上とだけ捉えてしまい、「信頼性を高める＝SLO（サービスレベル目標）の値を追いかけること」を実践しているケースや、SLOを100%、もしくはそれに近い値を設定することで現場の運用が混迷を極めているといったケースも少なくないでしょう。
しかし、SREの本来の目的は、ユーザーが不満を感じないギリギリのサービスレベルを維持しながら、ソフトウェアライフサイクルを高速化し、システムとビジネスのアジリティを高めることです。不必要に高い目標値を達成することが目的ではありません。SLOの最高値を上げ続けることよりも、SLOの範囲内で時間と手間（トイル：繰り返し行われ自動化可能な手作業）とコストの削減を行いながら、サービスレベルの向上とリリースサイクルの高速化というトレードオフにどこまでチャレンジするかが大切なのです。
本来のSREの目的を踏まえた上で、何をSLI（サービスレベル指標）に設定し、どのレベルでSLOを設定するかを考える必要があります。SLIとSLOについては、後述します。

「SREチームを作ればうまくいく」というわけではない

「社内でSREチームを作ったのに、うまく機能していない」というケースも少なくありません。SREを社内に普及させて実践するためには、専任チームを作ってチーム主体として取り組む以上に、組織全体が一丸となって取り組むほうが効果的であるといえます。
というのも、SREは自社のデジタルサービスの健康状態を目標の範囲内に維持し、他社との競争優位性を発揮し続けるために活用する施策です。SREはデジタルビジネスのこの時代の企業の行く末を左右する施策であるといってもいいでしょう。そのため、運用チームだけではなく、開発チームやビジネス側の理解と巻き込みも、重要なポイントといえます。

SREを実践するための4つの要素

SREの実践において、サービスレベルはどのように評価すればいいのでしょうか。サービスレベルを評価するための要素として、下記の4つの要素を理解する必要があります。
それぞれについて詳しく見ていきましょう。

CUJ：ユーザーがサービスを利用する際の重要な一連の流れ

CUJ（Critical User Journey）は、ユーザーが製品やサービスを利用する際に重要とされる一連の行動のことです。例えば、通販サイトの場合の重要な一連の流れは、「会員登録」「ログイン」「商品閲覧」「カート投入」「決済処理」です。CUJは、ユーザーが体験する重要な工程における満足度を測定し、分析することで、満足度を最大化することを目指します。

まず、CUJをマッピングして、どの体験がユーザーにとって重要度が高いか、またビジネスの成果に大きく影響を与えるかを詳細に検討し、モデル化します。このプロセスは開発・運用の現場だけでなく、ビジネスサイドのメンバーも参加して検討するとよいでしょう。
モデル化された行動がそのサービスにおけるSLIの観測のポイントになるため、CUJにSLIを設定することで、重要な機能がユーザーに提供できているかを計測できます。あとはSLOが達成できる範囲内で、リリース速度の高速化、変更にチャレンジします。

SLI：サービスレベル指標

SLI（Service Level Indicator）は、サービスレベル指標と呼ばれ、文字通りサービスレベルを測定する指標となるものです。一般的には、稼働率、エラー率、スループット、リクエストに対するレイテンシなどが使われますが、サービスによって指標は変わってきます。複数設定すれば多角的な分析が可能ですが、多すぎると実情を把握しにくくなるため、CUJによってある程度の数（1CUJあたり3-5SLI）に絞り込んでおきましょう。

SLO：サービスレベル目標

SLO（Service Level Objective）は、サービスレベル目標と呼ばれます。SLIでピックアップした指標の目標とする数値です。ユーザーが不満を感じるラインを想定して、数値を設定します。
例えば、SLIを「稼働率」に、SLOを「99.9％」に設定した場合、「100時間のうち正常稼働している時間が99.9時間」が稼働目標です。なお、稼働率をSLIに設定した場合、SLOが100％になることはありません。ソフトウェアが物理的なサーバーに納められている以上、天災などによる電源喪失、稼働停止のリスクがあるからです。
「目標は高いほうがよい」という考え方もありますが、ユーザーが不満に感じないギリギリの範囲でリスクを取ったチャレンジができているのであれば、それ以上を目指すよりも、新機能の開発やブラッシュアップなどに注力したほうが有益でしょう。
このリスクを取れる範囲をエラーの予算と考えることができ、エラーバジェットと呼ばれます。エラーバジェットを有効に活用することが、アジリティを高めるSRE実践の本質的な側面でもあるのです。このことからも、「SLOを100％に設定すること」がSREの目的ではないという意味をご理解いただけるかと思います。

SLA：サービスレベル契約

SLA（Service Level Agreement）は、サービスレベル契約と呼ばれます。SLIで挙げるような指標について、顧客に対して保証するサービスレベルを数値化したものです。SLAをクリアできなかった場合には、事業者は顧客に対して何らかの補償を行う必要があるケースが多いです。

例えば、SLIを「稼働率」、SLAを「99.5％」と設定した場合、100時間の稼働時間のうち、稼働できない時間が0.5時間以上あったなら、事業者は顧客に返金等の補償を行います。
なお、SLAは契約上の数字であるため、SREが実際にフォーカスしているのはSLIとSLOになります。

SREの実践にあたっての重要なポイント

SREの実践にあたっては、重要なポイントがいくつかあります。中でも、特に重要とされる2つのポイントをご紹介します。

オブザーバビリティを導入する

SREの実践には、オブザーバビリティの実装が必要不可欠です。オブザーバビリティとは、システム上で何らかの異常が起こった際に、それを通知するだけでなく、どこで何が起こったのか、なぜ起こったのか、どうやって直すのかを把握する能力を指します。

SREでは、サービスレベルをユーザーが不満にならないギリギリの許容範囲内に維持しながら、ユーザー体験の向上・維持のために頻回なCI/CDを続けていくことになります。それには、常にシステムの状態を把握し、フロントエンドからバックエンドまで、どこで何が起こっているか、どこがどのような状態なのかを知らなくてはなりません。そこで、SREが効果的に指標の計測や改善、維持をサポートするのが、オブザーバビリティです。

また、オブザーバビリティを獲得しているシステムと組織では、異常を検知したらアラートを飛ばすだけでなく、その原因がどこにあるかを即座に特定することもできます。そして、現在は生成AIがその原因特定をサポートする時代になり、トラブル対応の時間を大幅に削減することも可能です。

全社的に取り組む

デジタルサービスの良否がビジネスに大きなインパクトを与える現代では、SREは全社的に取り組むべき課題といえます。具体的には、開発運用チームにSREを支援する「Enabling SRE Team」を立ち上げ、SREの実践のサポートを行ったり、SREのメンバーが各プロダクトチーム内に直接入り込んで、チーム全体でのSRE実践のサポートを行う「Embedded SRE」を実践したりすることが有効な方法です。

しかし、現場では、それまでDevOpsチームにいたエンジニアが突然SREチームに配属されることやインフラチームの名前をSREチームに変更することも少なくありません。こうした場合でも、現場でSREチームとして作業する「SREer」にとどまらず、SREの正しい知識を啓蒙し、組織全体で積極的に取り入れて日常業務に組み込む「SREing」を実践できるように組織一丸となって実践することが理想的です。そうすることで、SREの概念が組織に根付き、企業全体で正しく認識できるようになります。
最近では、あえてSREという名前を使わずに既存の組織全体で、SREの概念で実現したいことを実践するという組織も出てきています。

SREを実践するためにはNew Relicの導入が効果的

SREの推進にあたってオブザーバビリティを導入するなら、New Relicがおすすめです。New Relicは、数多くの機能が統合されたオブザーバビリティ・プラットフォームです。
フロントエンドからバックエンドまで、システム全体を詳細に観測し、データの収集から分析、インサイトの抽出までを統合的に提供し、日々直面する課題に迅速に対応ができます。New Relicを導入していれば各SLIも数クリックで設定可視化が可能で、SLIを把握だけでなく、そのSLIが低下しているときには瞬時にその原因特定と修正方法までわかります。
また、生成AIと機械学習を活用しているため、障害を検知するとアラートを飛ばすだけでなく、生成AIアシスタントにトラブルシューティングをサポートしてもらえる点も大きなメリットです。New Relicを導入することで、エンジニアが障害対応に追われる状況を改善・解決できます。

さらに、New Relicを活用すれば、チームの垣根を超えて、ひとつの画面で共通の指標を見ながら「システムの信頼性がビジネスにどのようなインパクトを与えているか」を正確に把握が可能です。そのため、人的リソースの有効活用だけではなく、将来にわたってビジネスに大きなプラスをもたらす効果も期待できます。New Relicオブザーバビリティを活用すれば、各エンジニアのビジネス貢献をサポートすることができるのです。

効果的なSREの実践を目指すなら、まずは、New Relicの使用感やコストなどを確かめてみてはいかがでしょうか。
New Relic導入のご相談については、お問い合わせフォームよりご連絡ください。