コトラ（広報チーム） 
SREは、サービスを安定して提供しながら、新機能の開発や改善を継続的に進めるための考え方と実践方法です。システムが複雑になり、利用者の期待水準も高まるなかで、開発速度と安定稼働を両立する手段として注目されています。
本記事では、SREの基本、DevOpsとの違い、重要な指標、主な業務、導入の進め方を解説します。
SREとは何か
SREの意味と生まれた背景
SREは、Site Reliability Engineeringの略で、日本語では「サイト信頼性エンジニアリング」と呼ばれます。Googleで生まれた考え方であり、ソフトウェア開発の手法を運用に活用し、サービスの信頼性を高めることを目的としています。
従来の運用では、監視、障害対応、設定変更などを人が手作業で行う場面が多くありました。しかし、サービスの規模が大きくなるほど、人手だけで安定した運用を続けることは難しくなります。そこで、運用を単なる作業として扱うのではなく、ソフトウェアや自動化によって改善すべき課題として捉える考え方が広がりました。
SREでは、障害を減らすだけではなく、障害が起きたときに早く気づき、影響を小さくし、同じ問題を繰り返さない仕組みをつくります。
SREが目指す安定稼働と開発スピードの両立
サービスの安定性を重視しすぎると、変更を避けるあまり、新機能の提供や改善が遅くなる場合があります。一方で、開発速度を優先しすぎると、品質が不十分な状態で変更が行われ、障害や性能低下につながるおそれがあります。
SREは、この二つを対立するものとして扱うのではなく、数値にもとづいてバランスを取ります。たとえば、利用者にとって重要な機能の成功率や応答時間を計測し、許容できる品質の範囲を定めます。
その範囲内であれば開発やリリースを進め、品質が目標を下回りそうな場合は、信頼性を改善する取り組みを優先します。このように、感覚や部署ごとの立場だけで判断せず、共通の基準で意思決定する点がSREの特徴です。
従来の運用体制で起こりやすい課題
開発チームと運用チームが分かれている組織では、それぞれの目的が異なりやすい傾向があります。開発チームは新しい機能を早く届けたいと考え、運用チームは障害を防ぐために変更を慎重に進めたいと考えます。
この状態では、障害が起きたときに責任の所在をめぐる議論が起きたり、運用担当者に作業が集中したりすることがあります。また、手順が担当者の経験に依存していると、異動や退職の際に対応力が低下する可能性もあります。
SREでは、開発と運用がサービスの信頼性を共同で担う体制を目指します。手作業を減らし、対応手順や判断基準を共有することで、特定の担当者に依存しない運用へ近づけます。
SREが必要になりやすいサービスの特徴
SREはすべてのシステムで同じように必要になるわけではありません。ただし、次のような特徴があるサービスでは、SREの考え方が特に役立ちます。
- 利用者が多く、停止や遅延が事業に大きく影響する
- 機能追加や設定変更の頻度が高い
- 複数のシステムや外部サービスが連携している
- 障害対応や監視に多くの手作業が発生している
- アクセス数の変動が大きく、将来の容量を見通す必要がある
- 開発チームと運用チームの連携に課題がある
特に、利用者が頻繁に使う機能や、売上・契約・決済などに直結する機能は、早い段階で信頼性を測定する対象として検討する価値があります。
SREとDevOpsの違い
DevOpsとは開発と運用が協力する考え方
DevOpsは、開発を意味するDevelopmentと、運用を意味するOperationsを組み合わせた言葉です。開発チームと運用チームの間にある壁を減らし、協力してより速く、より安定的にサービスを提供するための考え方を指します。
DevOpsでは、情報共有、継続的な改善、自動化、小さな変更を頻繁に行う仕組みなどが重視されます。特定のツールや役職を指す言葉ではなく、組織の文化や働き方に関わる広い概念です。
SREとは信頼性を数値で管理する実践方法
SREは、DevOpsと近い考え方を持ちながら、特にサービスの信頼性を数値で管理する点に特徴があります。サービスの状態を測る指標を定め、目標値を設定し、その達成状況に応じて開発や改善の優先順位を決めます。
GoogleのSREに関する資料では、DevOpsを考え方や文化として捉え、SREをその考え方を実務に落とし込む方法の一つとして説明しています。SREは、監視、自動化、障害対応、容量管理などを通じて、信頼性を継続的に高めます。
SREとDevOpsの共通点
SREとDevOpsには、次のような共通点があります。
- 開発と運用の分断を減らす
- 自動化によって手作業や人為的なミスを減らす
- 小さな変更を継続的に行う
- データをもとに改善する
- 障害を個人の責任として追及せず、仕組みの改善につなげる
- 開発速度とサービス品質の向上を両立する
どちらも、サービスを提供した後の運用を単なる維持作業ではなく、事業価値を高める活動として捉える点が重要です。
SREとDevOpsを組み合わせるメリット
DevOpsの文化がある組織では、開発と運用の協力体制をつくりやすくなります。そこにSREの数値目標や自動化の仕組みを取り入れることで、改善活動の優先順位をより明確にできます。
たとえば、開発チームと運用チームが同じ指標を確認できれば、「今は新機能の提供を優先するべきか」「信頼性改善を優先するべきか」を共通認識のもとで判断できます。
文化や連携を重視するDevOpsと、具体的な運用管理の方法を示すSREを組み合わせることで、継続的な開発と安定したサービス提供を進めやすくなります。
SREで管理する重要な指標
SLIとはサービスの状態を測る指標
SLIはService Level Indicatorの略で、サービスレベル指標を意味します。利用者が感じるサービス品質を、数値で把握するための指標です。
代表的なSLIには、次のようなものがあります。
- 正常に処理されたリクエストの割合
- エラーが発生した割合
- リクエストへの応答時間
- 一定時間あたりの処理件数
- データが最後に更新されてからの経過時間
重要なのは、システム内部の状態だけではなく、利用者にとって重要な体験を測ることです。たとえば、ECサイトではログイン、商品検索、カートへの追加、決済といった操作が重要な測定対象になります。
SLOとは目指すサービス水準
SLOはService Level Objectiveの略で、サービスレベル目標を意味します。SLIで測定する数値に対して、どの水準を維持したいかを定めた目標です。
たとえば、「過去28日間のログイン成功率を99.9％以上にする」「95％のリクエストを2秒以内に応答する」といった形で設定します。
SLOは、理想的な数値を設定するものではありません。利用者が許容できる品質、事業への影響、技術的な実現可能性、必要なコストを考慮して決める必要があります。高い信頼性を求めるほど、冗長化や監視、人員などにかかるコストも大きくなるためです。
SLAとは利用者との約束
SLAはService Level Agreementの略で、サービスレベル契約を意味します。サービス提供者と利用者の間で交わす、品質に関する契約上の約束です。
SLAには、可用性や応答時間の基準、基準を満たせなかった場合の対応や補償などが定められる場合があります。たとえば、一定期間の可用性が契約で定めた水準を下回った場合、利用料金の一部を返金する取り決めなどです。
SLOは組織内で設定する目標であり、SLAは利用者に対する約束です。一般的には、SLAよりも厳しい水準を内部のSLOとして設定し、契約上の約束を守るための余裕を持たせます。
エラーバジェットとは改善と開発の判断基準
エラーバジェットは、SLOから導かれる、許容できる失敗の範囲です。日本語では、エラー予算と表現されることもあります。
たとえば、30日間の可用性SLOを99.9％とした場合、許容される停止や失敗は0.1％です。30日を43,200分として計算すると、0.1％は約43分です。この約43分が、その期間に許容されるエラーバジェットになります。
エラーバジェットが十分に残っている場合は、新機能のリリースや大きな変更を進めやすくなります。一方、予算を使い切りそうな場合は、リスクの高い変更を抑え、障害の原因解消や性能改善を優先します。
エラーバジェットは、開発速度と信頼性のどちらを優先するかを、客観的に判断するための共通基準です。
指標と目標を設定する具体例
たとえば、ログイン機能を対象にする場合、次のように設定できます。
- SLI：ログイン要求のうち、正常に完了した割合
- SLO：過去28日間でログイン成功率99.9％以上
- SLA：契約上の可用性を99.5％以上とする
- エラーバジェット：28日間のうち、SLOを満たせない時間や失敗率として0.1％を許容する
ただし、実際には単純にHTTPの成功コードだけを数えるのではなく、利用者にとって成功といえる状態を定義する必要があります。たとえば、ログイン画面が表示されても、認証後に必要な画面へ進めなければ、利用者にとっては成功ではありません。
指標は、プロダクト担当、開発担当、運用担当が協力して決めることが重要です。
SREの主な業務と取り組み
監視と障害の早期発見
SREでは、サービスの状態を継続的に把握するための監視を整えます。監視対象は、CPUやメモリなどのサーバー資源だけではありません。リクエストの成功率、応答時間、処理件数、データベースの負荷など、利用者の体験に影響する指標を確認します。
アラートは、多すぎると対応者を疲弊させ、本当に重要な異常を見落とす原因になります。そのため、すぐに人の対応が必要な問題に絞り込み、通知の基準を継続的に見直すことが必要です。
障害対応と再発防止
障害が起きた場合は、まず利用者への影響を抑え、サービスを復旧させることを優先します。その後、発生した経緯、影響範囲、対応内容、根本的な原因、再発防止策を振り返ります。
この振り返りは、個人の責任を追及するためではなく、システムや手順の改善につなげるために行います。担当者のミスだけを問題にすると、情報が共有されにくくなり、同じ問題を防ぐための学びが得られません。
原因調査の結果は文書化し、監視の追加、手順の見直し、自動化、設計変更などの具体的な改善につなげます。
手作業の自動化
SREでは、繰り返し発生する手作業を減らすことが重要です。人が毎回同じ操作を行う運用は、時間がかかるだけでなく、手順漏れや設定ミスの原因にもなります。
自動化の対象には、次のようなものがあります。
- インフラ環境の構築と設定
- ソフトウェアのデプロイ
- バックアップや復旧の実行
- 監視結果にもとづく通知
- 障害時の定型的な復旧作業
- 定期的なメンテナンス作業
自動化は一度にすべてを進める必要はありません。頻度が高い作業、失敗時の影響が大きい作業、担当者に依存している作業から優先すると効果を得やすくなります。
性能と容量の管理
サービスは、利用者数やデータ量の増加によって負荷が変化します。アクセスが急増したときに処理能力が不足すると、応答が遅くなったり、サービスが利用できなくなったりする可能性があります。
SREでは、現在の利用状況を監視するだけでなく、今後必要になる処理能力を予測します。季節要因、キャンペーン、新機能の提供、利用者数の増加などを踏まえ、必要な容量を計画します。
また、単に設備を増やすだけではなく、不要な処理の削減、データベースの最適化、負荷の分散などにより、性能とコストの両面から改善します。
開発チームと運用チームの連携
SREは、運用チームだけが担う活動ではありません。開発段階から、監視方法、障害時の対応、性能要件、変更時のリスクなどを検討する必要があります。
開発チームと運用チームが同じ監視情報や運用手順を利用し、サービスの状態を共通認識として持つことが重要です。障害時にも、両者が協力して原因を調べ、改善策を実行できる体制が求められます。
リリース前に、監視できる状態か、異常時に戻せるか、必要な手順が整っているかを確認することも、安定したサービス提供につながります。
SREを導入するメリットと注意点
障害による事業への影響を抑えられる
SREを導入すると、利用者に影響する異常を早く検知し、対応しやすくなります。監視、アラート、対応手順、復旧方法を整備することで、障害が起きた際の混乱を減らせます。
また、障害後の振り返りを通じて根本的な改善を進めるため、同じ問題の再発を防ぎやすくなります。サービス停止、機会損失、問い合わせの増加、信頼低下といった事業上の影響を抑える効果が期待できます。
開発チームが新機能の開発に集中できる
手作業の監視や定型的な障害対応が多いと、開発チームは本来取り組むべき機能開発や改善に時間を使えません。自動化や運用手順の標準化を進めることで、繰り返し作業の負担を減らせます。
また、運用に必要な情報や仕組みを開発段階から組み込むことで、リリース後に発生する対応コストも抑えやすくなります。結果として、開発チームは利用者価値の高い取り組みに集中しやすくなります。
データにもとづいて優先順位を決められる
SREでは、サービスの品質をSLIやSLOで測定します。これにより、「品質が不安だから変更しない」「新機能を急ぐべきだ」といった主観的な議論だけでなく、データをもとに優先順位を決められます。
エラーバジェットの残量も、開発と信頼性改善の配分を決める判断材料になります。関係者が同じ数値を見ながら議論できるため、部門間の認識のずれを減らすことにもつながります。
SREチームを作るだけでは成果につながらない
SREを導入する際に、既存の運用チームの名称だけをSREチームへ変更しても、期待する成果は得られません。SREは役職名ではなく、信頼性を数値で管理し、自動化と継続的改善を進める取り組みだからです。
チームを設ける場合も、開発チームとの責任分担、意思決定の仕組み、監視データの共有、改善に使う時間の確保などを整える必要があります。運用作業だけが集中すると、自動化や改善に取り組む余裕がなくなります。
組織全体が、信頼性をプロダクトの重要な要素として扱う姿勢を持つことが重要です。
完璧な安定稼働を目指しすぎない
SREでは、可用性100％を必ずしも目指しません。完璧な安定稼働を実現しようとすると、多大なコストや開発期間が必要になり、利用者にとって必要以上の品質になる可能性があります。
目指すべきなのは、利用者にとって十分な品質を、継続可能なコストで提供することです。SLOとエラーバジェットを設定することで、許容できるリスクを明確にし、過剰な対策と必要な改善を見分けやすくなります。
SRE導入を進める手順
現状の障害や運用負荷を整理する
最初に、現在どのような障害や運用上の課題が起きているかを整理します。過去の障害記録、問い合わせ内容、手作業の一覧、監視アラート、復旧までにかかった時間などを確認します。
特に、頻繁に起きる作業、特定の担当者に依存している作業、失敗した場合の影響が大きい作業を把握することが重要です。この整理によって、最初に改善すべき対象を選びやすくなります。
利用者にとって重要な機能を決める
すべての機能を同じ優先度で管理する必要はありません。まずは、利用者にとって重要で、事業への影響も大きい利用の流れを選びます。
たとえば、ログイン、検索、申し込み、購入、決済、データ登録などが候補になります。こうした重要な利用の流れを明確にすることで、利用者の体験に直結する指標を設定しやすくなります。
技術部門だけで決めるのではなく、プロダクト担当や事業部門とも話し合い、利用者にとって何が重要かを確認することが大切です。
小規模な範囲でSLIとSLOを設定する
最初から全サービスにSLOを設定しようとすると、設計や合意形成に時間がかかり、取り組みが進まなくなることがあります。まずは一つの重要な機能に絞り、測定可能なSLIと現実的なSLOを設定します。
設定時には、次の点を明確にします。
- 何を成功とみなすか
- どのデータを使って測定するか
- どの期間で評価するか
- どの水準を目標とするか
- 目標を下回った場合に何をするか
SLOは一度決めたら終わりではありません。運用結果や利用者の期待、サービスの変化に合わせて定期的に見直します。
監視と対応手順を整える
SLIとSLOを定めたら、実際に計測できる監視の仕組みを整えます。ダッシュボードなどで、現在の品質、目標の達成状況、エラーバジェットの消費状況を確認できるようにします。
同時に、異常を検知したときの対応手順も整備します。誰が確認するのか、どのように影響範囲を調べるのか、どの条件で関係者へ連絡するのか、復旧後に何を振り返るのかを明確にします。
手順は文書化し、実際の障害対応や訓練を通じて改善していくことが重要です。
振り返りを通じて対象範囲を広げる
小規模な範囲で運用を始めた後は、定期的に効果と課題を振り返ります。SLOが利用者の体験を適切に表しているか、アラートが多すぎないか、対応手順が機能しているか、自動化できる作業が残っていないかを確認します。
改善の成果が見え始めたら、対象となる機能やサービスを少しずつ広げます。SREは短期間で完成させる取り組みではなく、監視、自動化、障害対応、組織間の連携を継続的に改善する活動です。
まずは利用者にとって重要な一つの機能を選び、SLIとSLOを設定するところから始めるとよいでしょう。
