[2023年夏版] SRE入門編 SRE とは何か？コア技術と日本における事例や課題
DevOpsを具現化する取り組みである SRE （Site Reliability Engineering）は日本でも取り組みが広がり、多くの事例が登場し、伴って多くの課題が明らかになってきました。
この記事では、2023年夏時点の状況をもとに “そもそもSREとは何か？” “それを支える技術とは？” “日本における事例とは？” について、解説します。 2021年秋版を踏まえて軽く経緯にも触れるので、この記事だけを読めば事足りると思います。
参考：2021年秋版はこちら→ SRE入門編 SREとは何か？コア技術と日本における事例
目次
1.SRE （Site Reliability Engineering）とは何か
SREを一言で表すと「ソフトウェアエンジニアリングを軸に、フルスタックの迅速な継続的改善を、組織ぐるみ・組織横断で実現し続けること」です。 2016年、O’Reilly Mediaから書籍『Site Reliability Engineering』（通称「SRE本」。日本語訳は翌2017年発売）が発売され、SREの考え方が世に広く紹介されました。
本書は、GoogleにおけるSRE（Site Reliability Engineering）とSREs（Site Reliability Engineers）の取り組みをまとめた書籍です。
Googleは「class SRE implements DevOps」とも言っており、SREはDevOpsの実践スタイルのひとつといえます。
また “システム開発者・運用者” から “サービス提供者” へのマインドチェンジを促していて、「ユーザの期待・満足を、主要な評価・判断軸とする」「持続的成長に価値を置く」点に斬新さを感じる人が多いようです。
1-1.SRE本での SRE
この「SRE本」で語られるSREの概要は以下で、正直なところSRE以前の一般的な運用現場からすると結構過激に思えます。
- モチベーション： 複雑で大規模なコンピュータシステムを運用する際、システムの成長・拡大に比例してOps（運用系エンジニア）がどんどん増えていかないようにしたい
- コンセプト： ソフトウェアエンジニアリングで、運用を再定義する
- コアプラクティス： 伝統的オペレーションを行うOpsを全廃する
- 実現のためのアクション
- ソフトウェアエンジニアがソフトウェアエンジニアリングを用いて伝統的オペレーション*を破壊・再定義・置換する
- 実現のために会社が、SREを支持・支援する
*伝統的オペレーション･･･手作業など、システムの成長・拡大に比例して手間や量が増える手法のこと。Sysadminアプローチとも呼ばれる
なおSRE本で言うところのReliability（信頼性）は以下のように定義されています。
信頼性とは「[システムが]求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こす ことなく実行する確率」です。
1-2.SRE本を飛び出した「それぞれの現場の SRE 」
多くの運用現場が、運用現場の管理者がSREのモチベーション（労働集約モデルからの脱却）に共感しました。
SRE本に続き多くの書籍が出版されました。どれもブ厚く、気軽に「最初から最後まで通読しましょう」と言えるようなボリュームではありません。「通読せねば！」ということはないですし、通読ありきはお勧めしません。
運用現場の多様性と、背景にある多くの課題や悩みを感じます。
- O’Reilly Japan – サイトリライアビリティワークブック
- O’Reilly Japan – SREの探求
- O’Reilly Japan – データベースリライアビリティエンジニアリング
- O’Reilly Japan – オブザーバビリティ・エンジニアリング
- O’Reilly Japan – SLO サービスレベル目標
SRE本を読んで、取り組んでみて、結果「Googleのビジネスモデルだからこそできたのだ」「Googleの財務状況だからこそできたのだ」「Googleの人材だからこそできたのだ」「GoogleのようなBigTechだからこそできたのだ」という感想を得るに至る事例も多く発生しました。
わたしが見聞きした範囲では、SREならではの事情はなく、「個人単位と組織単位で成長（＝自己変革と行動変容）に不慣れなところが、プラクティスをなぞることで一足飛びに行動だけ変容しようとした」ケースがほとんどでした。
2023年夏の状況として「SRE」はハイプサイクルで言うところの幻滅期を乗り越え、アーリーマジョリティからレイトマジョリティが取り組み始め、いよいよ本格的な普及拡大期に入った感触があります。
SREに関連するイベントが数多く開催されるようになりました。
エンジニアをつなぐIT勉強会支援プラットフォーム connpass でキーワードに “SRE” を含むイベントの開催数を調べたところ以下のように激増しています。
- 2017年：63件
- 2018年：145件
- 2019年：125件
- …
- 2022年：263件
- 2023年：149件（7月末まで）
2.[最近の]一般的な SRE
アーリーマジョリティ・レイトマジョリティが参加し場が混沌としてきたところで、2023年にGoogleが 『SREエンタープライズロードマップ』 を公開しました。SRE本が547ページとハイボリュームなのに対して、『SREエンタープライズロードマップ』はたった56ページと短く、簡潔にポイントがまとまっています。
冒頭4ページの『第1章 エンタープライズSRE ことはじめ』から印象的なフレーズを抜粋します。
- 現状に関わらず、SREの導入で最も成功するのは、既存のフレームワークと真っ向から戦うのではなく、進化させ、補完することを選択した場合です
- SREの実践はITILフレームワークと共存できる
- 結果が一致していてもやり方を調整する必要がある
- DevOpsとSREの取り組みを両立させるためには、現実的であることが必要です
- 今いる場所から始める
- SREは「人」から始まる
- 特定の組織で SRE を導入するベストプラクティスは 1 つではありません。正しい方法は、あなたが成功した方法だけです
どうでしょう。読んでみたくなってきましたか？
ちなみに、わたしが一番好きなところは
あなたのSREのバージョンが Googleのものと完全に一致する必要はありません。原則だけは一致させてください
です。
2-1.[最近の] SRE の一般的な期待値
『SREエンタープライズロードマップ』にもあるように、現状を勘案せずプラクティスをはめ込むのはアンチパターンです。
とはいえ一般的には「SREやってます」と言えば、以下を実現している、あるいは志向し・価値を置いて・実現に向けてそれなりに取り組んでいることを期待するでしょう。
- ユーザの期待・満足を、主要な評価・判断軸とする
- ソフトウェアエンジニアリングする（再現性・再利用性の結果として、証跡確保・省略化・ミス削減などを狙う）
- データドリブンで判断・行動する（観測を実現し（オブザーバビリティ ）、観測結果を判断の前提にする。基本的にデータをもとに判断・行動する）
- アジャイル的に取り組む（継続的・漸近的に改善を積み上げ進捗を生み出し、結果としての成果を狙う）
- 個人・組織の壁を作らない・壁を壊す・壁を超える
またこれらの背景には、以下のような文化・行動様式が前提となっています。
- HRTを重視し遵守する（Humility：謙虚、Respect：尊敬、Trust：信頼）
- 心理的安全性を尊重する
- 検証し失敗し学ぶことを重視する
2-2.[最近の]組織での SRE の実現形態の例
まず前提としてSRE（Site Reliability Engineering）は人や役割ではありません。SREの専門家・専任者を表す場合はSREs（Site Reliability Engineers）と表記します。
（とはいえSREが広まった結果として、厳密でない用語が広く多く使われるようになり、使い分けがなされないケースが増えています。個人的に残念ではありますが、新しい用語が広まったときの宿命でもあり、あまり目くじらを立てて界隈や業界の発展の足かせになるのもなぁと思っています）
ではSREは何かと言うと、SREは文化であり習慣です。
セキュリティやパフォーマンス、アクセシビリティなど一般に非機能要件と呼ばれる類の事柄は、専門性が必要なので専門家はいるものの、専門家だけが取り組むことではありません。SREも、専門家や特定の誰かがではなく、システムに関わる誰しもが取り組むことです。
とはいえ専門性を獲得するには専門家が必要ですし、新しい取り組みにおいて専任者がいると実現性や達成度が大きく向上するのも世の常です。
専門家や専門チームの配置、他のチームとの関わり方はいろいろなパターンがありプラクティス化されています。詳しくは以下の記事をご参照ください。
数ある発展形のひとつとして、最近はプラットフォームエンジニアリング（Platform Engineering）やインナーソース（InnerSource）が注目されています。いずれも “組織内のエンジニアリング能力や成果を組織全体で共有化し、全体最適化と持続的成長を図る” 取り組みです。
3.[最近の]コアプラクティスを支える技術の深化：モニタリングからオブザーバビリティへ
SREの一般的な期待値にある “データドリブン” を成すためにはデータが必要です。
SREのマインドは「ユーザの期待・満足を、主要な評価・判断軸とする」「持続的成長に価値を置く」ですから、ここで言うデータは従前から扱われてきたシステムリソースの利用状況を表すシステムメトリクスだけでなく、サービスの稼働状況や実績を表すサービスメトリクス、結果としての事業成果を表すビジネスメトリクスなど多岐にわたります。
ユーザの実際の利用状態を把握するためのRUM（Real User Monitoring）や、アプリケーションの実際の稼働状態を把握するためのAPM（Application Performance Monitoring）も重要なデータソースです。
このような、いわば次世代のモニタリングを指してオブザーバビリティ（Observability：可観測性）と呼びます。ユーザサイドからバックエンドまで広く、本番環境でのアプリケーション動作状況をデバッグできるほど深い領域を対象に計測し、それらのデータを統合して一元的に把握・分析していきます。
詳しくは以下の記事をご参照ください。
3-1.ユーザの期待・満足を計測するSLI
ユーザの期待・満足を計測するためにSLI（Service Level Indicator）を策定し計測します。典型的にはCUJ（Critical User Journey：サービスにおける超重要なユーザ行動）を軸にSLIを何にするか決断します。網羅性を気にするとSLIだらけになり指標としての能力がなくなってしまうので、主要なものを絞り込みます。
そしてSLIの達成目標であるSLO（Service Level Objectives）を決断し、日々の判断や行動の材料にします。典型的には「CUJがエラー無く快適に高速に利用できる時間帯が直近1ヶ月間で99%以上」などとします。
なおSLIやSLOは、SLAと語感が似ていますが別物です。SLAの決定には市場競争力や顧客調整などSLI・SLOにおいては直接的には関係のない力学が働きます。SLA決定の一要因としてSLIやSLOを考慮することはありえますが、SLI/SLOを支配的要因としてSLAを決定するとSLAの価値を損ないます。
3-2.持続的成長を計測するFour Keys
持続性成長のことを考えると、中長期での開発速度やサービス品質の維持向上は欠かせません。これらを支えるのは開発者体験（Developer eXperience）ですから、これらも計測しデータソースとします。
Four Keysと呼ばれる以下の指標群を計測することが多いです。
- デプロイの頻度 – 組織による正常な本番環境へのリリースの頻度
- 変更のリードタイム – commit から本番環境稼働までの所要時間
- 変更障害率 – デプロイが原因で本番環境で障害が発生する割合（%）
- サービス復元時間 – 組織が本番環境での障害から回復するのにかかる時間
エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud 公式ブログ
4.[最近の]日本における SRE 事情と課題
SREの取り組みやSRE職について日本ではメルカリがアーリーアダプターです。メルカリは2015年にblogでSREチームの取り組みを公開しました。
2016年以降は、Webサービス提供会社を中心に、SRE職を設ける会社が増えました。
日本では伝統的オペレーションによって解決する課題を担当していたのがインフラエンジニアであったことが多いため、もともとのフェーズによる区分け（Dev/Ops）ではなく、レイヤによる区分け（アプリケーションエンジニア/インフラエンジニア）で語られることが多いです。
2023年夏時点では某求人サイトで「インフラ」よりも「SRE」のほうが求人件数が多くなっています。
2023年夏時点で日系大手システムインテグレーター各社も「SRE」を冠する運用サービスを提供し始めており、前述の通り「SRE」はハイプサイクルで言うところの幻滅期を乗り越え、アーリーマジョリティからレイトマジョリティが取り組み始め、いよいよ本格的な普及拡大期に入った感触があります。
わたしの見聞きする範囲ではSREの取り組みを社内に広げる段階で難航することがままあり、その多くはSREに限った話ではなく、「大人が成長するのは難しい（成長＝自己変革と行動変容）」「既存組織の枠組みをまたぐ取り組みが難しい」「他者に行動変容を促すのが難しい」「探索的な取り組みを承認・励行する仕組みや文化がない」ということのようです。
このあたりの取り組みについても前述の『SREエンタープライズロードマップ』 で取り上げられています。読みたい理由がひとつ増えましたね。
5.まとめ
- SREを一言で表すと「ソフトウェアエンジニアリングを軸に、フルスタックの迅速な継続的改善を、組織ぐるみ・組織横断で実現し続けること」
- SREはDevOpsの実現形態のひとつ
- SREでは「ユーザの期待・満足を、主要な評価・判断軸とする」「持続的成長に価値を置く」
- SREの実現形態はものすごく多様
- 主要な期待値のひとつに「データドリブンでの判断・行動」があり、それを支えるのがオブザーバビリティ（可観測性）
[PR] X-Tech5のSREサービスで『今日より、一歩前へ』
SREに取り組み始めたいものの、いまいち最初の一歩が難しいなぁという場合は、弊社X-Tech5のSREサービスをご検討ください。
まずは無料相談から！。直接ご支援・相談できます。
弊社エンジニアがSREとしてチームに参加し、チームの一員として動きSREを実現します。
