Webサービスの信頼性や価値の向上に用いられるアプローチ方法としてSRE（Site Reliability Engineering）というものがあります。システム開発側と運用側の溝を埋めるために生まれたこの手法ですが、従来のDevOpsとはどのような違いがあるのでしょうか。
本記事ではSREとDevOpsの違いについて見ていきます。
SREとDevOpsの違い
SREとDevOpsの違いや関係性を知るには、Googleが提唱している「class SRE implements DevOps」の考えが最も明解でしょう。
「class SRE implements DevOps」は、「SREはDevOpsというinterfaceの実装である」という意味を表します。「DevOps = 思想」という定義に対し、それを具体化し実装したものがSREであるという考えです。
ここからはより詳しく、DevOpsとSREについて触れていきます。
DevOpsとは
DevOpsとは、開発担当（Dev）と運用担当（Op）が協力し合ってサービスを作り上げていく思想を指します。
開発者はスピード感のある開発で新機能を追加することを重視し、運用者は信頼性・安定性を重視した運用を行うのが、従来までのサービス開発・運用の構図でした。しかしお互いに良いサービスを作りたいというゴールは同じなのにも関わらず、開発者/運用者のように分断された関係では、お互いのチームが目指す方向性にズレが生じてしまうという問題がおこります。
このような問題を解決するために生まれたのが、DevOpsという考えです。以下の5つの方針が、DevOpsをスムーズに実行するために必要な要素とされています。
①組織のサイロの削減：
サイロとは「独立している」状態のことで、開発側・運用側のチーム同士がうまく連携できていない状態を指します。お互いの組織に溝があることで生じる弊害を無くすため、DevOpsでは組織のサイロ化の削減を大きな指針のひとつに掲げています。
②エラーが発生するのを前提とする：
いくら要件定義・詳細設計の段階で細かく設計したとしても、必ずシステムのエラーは発生してしまいます。完璧なシステムはなく、エラーが発生するのを前提としてシステムの開発・運用に取り組むべきであるという考えです。
③段階的に変更する：
システムを開発・運用していくうちに、必ずプログラムの変更は起こります。そのため変更によって起こりうるエラーを考慮して、段階的に変更を加えることを推奨する考えです。段階的な変更をすることにより、新規機能の追加対応、正常状態に戻すロールバッグ作業が迅速に行えるため、システムの安定稼働には欠かせない考えです。
④ツールと自動化を活用する：
開発および運用の効率化という面で、ツールや自動化を活用することは非常に重要であるという考えです。これはサービスが拡大し、継続すればするほど初期での導入効果は大きくなります。また人的なエラーを起こさないための取り組みとしても非常に有効な手段です。
⑤全てを計測する：
システムの運用ログやエラー検知、パフォーマンス含め、全てのデータを計測して数値化していくことが重要です。それにより新規機能の開発やプログラム修正の際に役立つという考えです。
しかしDevOpsは、あくま上記のような概念や思想にとどまり、具体的な実装までは明示されていません。これらの思想に対してより具体的に実装方法を明示したのがSREということになります。
SREとは
SREを日本語で表現すると「サイト信頼性エンジニアリング」となります。つまり信頼性のあるサイトを運用するための体制ないし実装方法を指しています。DevOpsが思想であるのに対し、SREは具体的な実装までも明示されているのが大きな特徴です。
SREは、「システム運用作業の効率化」および「エラーバジェットによる優先順位付け」が基本の考えとなります。それらを具体的に成果として確認するために、以下のような取り決めを行っています。
※あくまで代表的な取り決めの紹介にとどめます。
①トイル（苦労）の制限および自動化：
トイルは日本語で「苦労」の意味を表す言葉で、システム開発・運用上では「手作業による工数の消費」を表します。SREの取り組みとしては最大限、ツールの利用や自動化をすることで効率の向上を重要視しています。
SREの提唱元であるGoogleでは、SREがトイルにかける時間は全体作業の50%までという制限をかけており、残りの50%をコーディングスキルを使うプロジェクトの作業にあてるということを定めています。
この取り決めを忠実に守ることにより、バランスとの取れた運用を担保しながら、リスクを伴う開発作業が行えるようになります。
②SLI・SLO・SLAによる目標定量化：
安定したサービスを運用するためには、SLI・SLO・SLAの指標で評価し、目標を定量化する必要があります。これらの数値状況によりサービスが正常な状態かを判断することで、開発・運用ともに共通の問題意識を持つことが可能になります。
以下の項目を使い、エラーバジェットの評価に役立て、サービスの開発・運用をより効率化してます。
SLI（Service Level Indicator）：
「サービスレベルの指標」を指します。
サービスの可用性・性能・セキュリティなどの指標を指します。SLIはあくまで指標なので数値化する必要はありません。
SLO(Service Level Objective)：
「サービスレベルの目標」を指します。
SLIの計測項目の具体的数値であり、ユーザーが満足するレベルのサービスを維持するために、サービスの可用性・性能・セキュリティなどの目標値を数値化したものを指します。
SLA(Service Level Agreement)：
「サービスレベルの保証」を指します。
安定・信頼を担保するためにSLOをもとにお客さまとの取り決めを行います。
関連記事：SREとはなにか [サイト リライアビリティ エンジニアリング]
DevOpsの実装としてのSRE
さて、冒頭で「class SRE implements DevOps」（SREはDevOpsというクラスの実装である）という考えについて解説いたしました。つまり、DevOpsは思想であり、SREはその実装方法であるというものです。
そして、DevOpsを踏まえた実装であるSREの中で、DevOpsの思想を色濃く継承している点があります。ここでは6点を取り上げて解説します。
継続的な改善の必要性
DevOpsならびにSREは、「現状を良しとするのではなく、改善が必要」という前提に基づいています。
なお、ここでいう改善とは「プロジェクト的に一時的なチームを組成し、場当たり的な改善を時々行う」のではなく、「恒常的なチームを組織して、開発プロセスと強く連動し、そのプロセスに組み込まれる一貫した改善を継続的に行う」という点が特徴となります。
組織を超えたコラボレーション
「チーム内で開発や改善のための活動が閉じてしまうのではなく、横断的な取り組み・活動が必要」という点で、DevOpsとSREは共通しています。実際、Googleが提唱するSREはそれぞれの開発チームとは独立した組織として、横断的な改善活動を行うことを目的として設置されています。
変更管理と自動化
DevOpsもSREも、サービスの変更が必要となった場合、変更の大部分が自動的にテストされることを前提（または目標）としています。変更管理と信頼性には相関があり、「信頼性向上を目的としたDevOps実装」ともいえるSREにおいては、この点は非常に重要なポイントとなります。
具体的には、IaCやCI/CDによる変更のコード管理やテスト・デプロイの自動化を取り入れることで実装されます。
計測の重要性
DevOpsとSREを特徴づけるポイントのひとつがデータ志向です。DevOpsの「全てを計測する」という思想、データ志向を貫くためには、正しい計測が必要です。
正しい計測の先に、データに基づく議論があり、最終的にはSREで用いられる信頼性やトイルの測定ならびに監視、そして正しいSLO等のKPI設定につながります。
非難のない文化
インシデントの発生は最小化されるべきです。しかし、変更を行う上で、インシデントの発生は避けられないという前提を、DevOpsとSREでは共有されています。
そのうえで、発生したインシデントを組織として学習し、改善を行っていく事が必要とされています。これを、SREでは具体的に「非難のない文化の醸成とポストモーテムの実施」として実装されています。
開発速度の改善
「改善」が意味する点を狭く捉え、SLOだけを取り上げて指標とすることは望ましくありません。多くのDevOpsならびにSREの専門家は、改善の成果には開発速度の改善も含まれるべき、という点で共通しています。
具体的には、トイルやオンコール対応といった割り込み作業は、開発速度を遅延させます。多くの組織ではトイルに割く時間が50%を超えていますが、Googleではこの数字が33%となっています。思想としてのDevOpsと、実装としてのSREが、Googleの開発速度を支えていることに疑いはありません。
変更管理と自動化で紹介したCI/CDを構築することで、自動化はもちろんのこと変更テスト・デプロイが自動化されることにより、開発速度の改善にも繋げることも可能です。
SREのことなら弊社にお任せください
DevOpsとSREの違いについて紹介してきましたが、やや概念的な面も多く「実際、どのようにSREを導入すれば良いのだろう？」や「専任のSREチームなしでSRE原則を適用する方法がない」と思う担当者の方も多いかと思います。
弊社は、金融・医療・動画配信・AI・ゲームなど、特に技術力が求められる領域で豊富な経験を持つSREの専門家が集まったチームです。戦略策定から設計・構築・運用、SaaS提供までSREに必要な要素を統合的に提供可能です。
もし少しでもSREに興味があるという企業様がいらっしゃいましたら、気軽にお問い合わせください。
東京在住のソフトウェア開発者、Motouchi Shuyaです。
システムの開発・運用・最適化が好きです。
