今さら聞けないシリーズ4「Site Reliability Engineering(SRE)」再入門

ミシュラン調査員も認める「Site Reliability Engineering」

안녕하신게라！パナソニック コネクト株式会社クラウドソリューション部の加賀です。

一人のシェフから始まったあなたの旅路は、ついにレストラン帝国の経営を担うオーナーの片腕にまで到達しました。しかし、経営者として帝国全体を俯瞰するあなたの元には、新たな、そしてより深刻な課題が持ち込まれていました。

「もっと早く新メニューを出したい」と願う開発チームと、
「これ以上システムを複雑にすると品質が下がる」と訴える運用チーム。
両者の対立は日に日に深まり、帝国全体の成長を鈍化させています。

さらにオーナーはあなたに問いかけます。
「我々のレストランが提供する体験は、本当に最高だと言えるのか？その『信頼性』を、どうやって証明するのだ？」と。

あなたは悟ります。
信頼とは、内輪で「頑張っている」と言うだけでは得られない。内部の対立を乗り越える仕組みを築き、その上で、顧客体験を客観的なデータで証明して初めて、本物の「信頼」となるのだ、と。

このシリーズは、混沌とした開発現場を理想のレストランへと変革するための旅路、最終回です。

1. シェフのバイブル「The Twelve-Factor App」を学び（完了！）、
2. ヘッドシェフのメニュー開発術「Beyond the Twelve-Factor App」を手に入れ（完了！）、
3. セントラルキッチン活用のための「Cloud-Native」で厨房を設計し（完了！）、
4. ミシュラン調査員も認める「Site Reliability Engineering」 の品質を追求する（本記事）

前回では、クラウドの力を最大限に引き出す「Cloud-Native」という思想で、世界中に展開可能なスケーラブルな「セントラルキッチン」を設計しました。
しかし、どれほど素晴らしい仕組みを設計しても、その上で提供される体験の「品質」、つまり「信頼性」が客観的に証明され、維持・向上されなければ、顧客の信頼は得られません。

SREが目指す「信頼性」とは、ミシュランガイドが星を与える基準の一つである「常に安定して最高品質の料理を提供し続けること」という哲学とも深く通じます。
最終回では、その究極の品質を追求し、開発と運用の対立に終止符を打ち、究極の顧客体験をデータで証明するための哲学「Site Reliability Engineering」の世界へご案内します。

この記事で学べること

この記事では、「Site Reliability Engineering（以下SRE）」を初めて学ぶ方から、以前学んだけれど改めて全体像を整理したい方までを対象としています。

単にSLOやエラーバジェットといった概念を解説するだけでなく、ミシュラン調査員も認める品質管理という比喩を交えながら、ビジネスの成長とシステムの信頼性という二つの要求を両立させ、対立を乗り越えるための哲学と具体的な実践方法を深く理解することを目指します。

• SREが解決する2つの課題
  開発と運用の対立を乗り越える「内部の調停者」と、顧客体験を証明する「外部への証明責任者」としての役割を学びます。
• SREの段階的な実践
  SREのプラクティスがどのような優先順位で成り立っているのかを理解し、全体像を掴みます。
  • SLI / SLO / SLA
    顧客体験を数値化し、「努力目標」と「顧客との約束」を区別する。
  • エラーバジェット / インシデント対応 / ポストモーテム
    障害発生時の対応プロセスを定め、挑戦のための予算を管理し、失敗から学ぶ文化を築く。
  • キャパシティプランニング / 負荷テスト
    成長を予測し、システムの限界を知るための「防災訓練」を行う。
  • Toilの削減
    未来への投資時間を捻出し、創造性を高め、監査にも動じない体制を築く。

SREが解決する2つの課題

SREとは、Googleの経験から生まれた実践哲学であり、ソフトウェアを用いてインフラと運用の課題を解決する考え方です。

SREの最終的な目的は、単にシステムを安定させることではありません。高い信頼性を維持することで、むしろ新機能の開発スピードを加速させ、ビジネスの成長を後押しすることにあります。そのため、SREは単なるツールセットではなく、データドリブンな意思決定と心理的安全性を重視する、組織文化の変革そのものなのです。

SREの導入は、技術的な課題だけでなく、人の意識や組織構造にまで踏み込む必要があります。それは、あなたのレストラン帝国が抱える2つの課題を同時に解決する、2つの顔を持っています。

1. 内部の調停者
   開発と運用の感情的な対立に、「データ」という客観的な判断基準を持ち込みます。これにより、チームは「新機能開発（攻め）に注力すべき時」と「信頼性向上（守り）に集中すべき時」を自律的に判断できるようになり、失敗を許容する「エラーバジェット」という仕組みは、挑戦を促す心理的安全性を組織にもたらし、健全な協力関係を築きます。
2. 外部への証明責任者
   サービスの信頼性に関する客観的なデータを収集・公開し、外部のステークホルダー（顧客、ビジネスパートナーなど）に対して説明責任を果たします。これは、「私たちのサービスは、これだけの品質を維持しています」と胸を張って証明する活動です。

DevOpsが「開発と運用が協力し、ビジネス価値を迅速に届ける」という文化や哲学を指すのに対し、SREは「DevOpsの文化を、データとエンジニアリングでどう実現するか」という問いに対する、Googleが示した具体的な実装の一つと言えます。

SREは、信頼性をソフトウェアで解決すべき問題として扱うことで、DevOpsの理想を具体的なプラクティスに落とし込み、開発と運用の協力を促進する強力なフレームワークなのです。

SREの段階的な実践

あなたは、レストラン帝国に本物の信頼をもたらすため、SREの哲学に基づいた実践を導入します。

SREは、第3回で学んだCloud-Nativeの基盤の上で、その真価を最大限に発揮します。この基盤で構築したスケーラブルな「セントラルキッチン」があるからこそ、SREのプラクティスを効率的かつ効果的に導入できるのです。

ただし、SREの実践には推奨される「順序」があります。これは、GoogleのSRE本でも示されている「信頼性の階層モデル」に基づいています。信頼性という名の建物を建てるには、しっかりとした土台から順に積み上げていく必要があります。

• 可観測性（Observability）
  まずはシステムの稼働状況を把握できなければ、何も始まりません。
• インシデント対応（Incident Response）
  次に、問題発生時に迅速に対応し、そこから学ぶ文化が不可欠です。
• 効率化と自動化（Toil Reduction）
  安定運用を支えつつ、改善時間を生み出すための仕組みです。
• 予測と準備（Planning and Testing）
  将来の負荷に備え、システムの限界を把握します。
• 目標設定（SLI / SLO / SLA）
  これらの土台の上で初めて、意味のある目標を設定し、関係者と合意形成ができます。

（GoogleのSRE本で語られるモデルを参考に、本記事での解説順序に合わせて再構成したものです。）

本記事では、SREの思想を最も象徴し、すべての活動の指針となる「目標設定（SLI / SLO / SLA）」からあえて解説します。なぜなら、最初に「目指すべきゴール」を明確に理解することで、その土台となる各プラクティスが、ゴール達成のためにいかに重要であるかをより深く実感できるからです。

目的地を知ってから地図を読むように、まずはSREという旅のゴールから見ていきましょう。

SLI / SLO / SLA

まず、曖昧な「信頼性」や「顧客体験」を、3つのレベルの数値に分解し、定義を明確にします。

• なぜ (Why)
  内部での高い目標と、顧客に対する公的な約束を明確に区別するためです。
  「頑張ります」という想いだけでなく、「ここまでを保証します」という契約を結ぶことで、ビジネスの信頼性が格段に向上します。
• どうやって (How)
  • SLI（Service Level Indicator / サービスレベル指標）
    顧客体験を測るための具体的な指標。
    「注文アプリのレスポンスが200ms以下で応答したリクエストの割合（レイテンシ）」「決済処理の成功率（可用性）」「1分あたりに処理できる注文数（スループット）」など、ユーザーの満足度に直結する指標を選びます（※レストランの比喩で言えば「温かい料理が提供時に65℃以上である割合」も品質SLIの一つです）。
    これらを第3回で整備した可観測性（Observability）の仕組み、例えばPrometheusやDatadogといったツールを使って計測します。
  • SLO（Service Level Objective / サービスレベル目標）
    SLIが達成すべき内部目標値。
    「レスポンスタイムの99.9%が200ms以内であること」のように具体的な数値を定めます。これはあくまで内部の高い目標であり、100%を目指さないのがポイントです。
    100%の信頼性はコストがかかりすぎる上、失敗を許さない閉塞感を組織にもたらし、イノベーションを阻害するためです。
  • SLA（Service Level Agreement / サービスレベル契約）
    顧客と交わす、破れない約束。
    SLOよりは少し緩い現実的な目標値を設定し、破った場合のペナルティ（利用料の一部返金）や、信頼回復のための対応（改善計画の提出、透明性確保のための情報開示）を明確に定義します。
    「レスポンスタイムの99.0%が500ms以内であることを保証します。もしこの約束を果たせなかった場合、月額利用料の一部を返金します」といった形で、顧客との契約書に明記されます。
• アンチパターン
  • 内部目標であるSLOを、そのまま外部との契約SLAにしてしまい、達成できずにペナルティを連発する。
  • 重要な顧客体験を反映していない指標（CPU使用率やメモリ使用率など）をSLIにするケースがある。
  • 最初に決めたSLI/SLOを固持し、過去データの分析や部門との調整を怠り、繰り返しトライ＆エラーを行わない。

エラーバジェット / インシデント対応 / ポストモーテム

SLOという「高い内部目標」は、失敗への向き合い方も変革します。それは「許容される失敗の量」「障害が起きている最中」「障害が終わった後」という3つの側面で実践されます。

• なぜ (Why)
  「顧客との約束（SLA）を破らない」という絶対的な制約の中で、開発チームがどれだけ新しい挑戦をできるかを可視化するためです。
  そして、障害を混乱や犯人探しで終わらせず、チーム全体の学びと成長につなげる文化を醸成します。
• どうやって (How)
  • エラーバジェット
    SLOが99.9%の場合、エラーバジェットは100% - 99.9% = 0.1%となります。この「0.1%」という「失敗してよい予算」を使い切らない限り、開発チームは新しい挑戦を続けられます。もし、障害などでこの予算が尽きそうになったら、新機能リリースは一時凍結され、チーム全体で信頼性の改善に集中します。
    これにより、開発と運用の対立は「エラーバジェットの残量」という共通のデータに基づく意思決定に変わります。
  • インシデント対応プロセス
    エラーバジェットを大きく消費するような問題が発生した際、誰が指揮を執り（インシデントコマンダー）、誰が顧客対応し、誰が原因調査にあたるのか。役割分担と情報共有ルールを事前に定めた「防災マニュアル」が、パニックを防ぎ、迅速な復旧を可能にします。
    また、インシデントを検知し、対応を開始するためのOn-Call（オンコール）体制の整備も重要です。PagerDutyやOpsgenieのようなツールでアラート通知や対応フローを自動化し、担当者が持続可能な形で対応できる仕組みを整えます。
  • ポストモーテム（事後検証会）
    インシデントが解決した後、関係者全員が集まります。しかし、そこは誰が悪いのかを個人に求める場ではありません。「何が起きたのか、なぜ起きたのか、次にどうすれば防げるか」を、非難なし（Blameless） の文化のもと、事実とデータに基づいて冷静に分析し、具体的な改善アクションを決定する建設的な場です（詳細はGoogleのポストモーテム文化を参照）。
• アンチパターン
  • エラーバジェットを「使っていい失敗枠」と勘違いし、SLO違反をしても原因を調査・改善しない。
  • 失敗を恐れるあまり、エラーバジェットが潤沢に残っているのに新しいリリースに挑戦しない（顧客体験を向上させる機会を損失している）。

キャパシティプランニング / 負荷テスト

あなたのレストラン帝国は、次のブラックフライデーに史上最大のキャンペーンを計画しています。
オーナーはあなたに尋ねます。「このシステムは、本当にその負荷に耐えられるのか？限界はどこなんだ？」

• なぜ (Why)
  ビジネスの成長や季節的なイベントによる負荷の変動を予測し、備えるためです。第3回で学んだ、コンテナ技術や宣言型API（Kubernetesなど）を前提としたクラウドの自動拡張（オートスケール）は強力ですが、万能ではありません。
  事前にシステムの限界点を把握し、「どの指標（SLI）をトリガーに」「どれくらいの速さで」厨房（コンテナ）を増やすべきかを設計・検証しておかなければ、突然のアクセス急増に対応できず、顧客の信頼を失います。
• どうやって (How)
  • キャパシティプランニング
    クラウド時代におけるキャパシティプランニングは、物理サーバーの購入計画から「オートスケールの戦略設計」へと変わります。過去のデータやキャンペーンの予測に基づき、「CPU使用率が70%を超えたら、コンテナを2つ追加する」といったルールを定義します。また、クラウド利用料が予算を超えないよう、上限設定やコストアラートも計画に含めます。
  • 負荷テスト（オートスケールの防災訓練）
    本番環境に極めて近いステージング環境で、予測される最大負荷、あるいはそれ以上の負荷を意図的にかけます。このテストの目的は、単に限界点を知るだけでなく、「定義したオートスケールのルールが、期待通りに、かつ十分な速さで機能するか」を検証することです。
    「負荷急増から新規コンテナ起動完了まで3分かかる」といった具体的な数値を把握し、SLOを守るために改善が必要かを判断します。
• アンチパターン
  • オートスケールを過信し、「クラウドが自動でなんとかしてくれるだろう」と、負荷テストを一切行わない。
  • コストを恐れるあまり、オートスケールの設定を過度に控えめにし、ピーク時の負荷を捌ききれない。

Toilの削減

日々発生する「手作業で、繰り返され、自動化可能で、長期的な価値を生まない作業」。
これをSREではToil（トイル/苦労）と呼びます。

• なぜ (Why)
  エンジニアを単純作業から解放し、より創造的で長期的な価値を生む仕事（自動化、システムの再設計、信頼性向上など）に集中できる時間を生み出すためです。SREの目標は、Toilに費やす時間をエンジニアの時間の50%未満に抑えることです（※これはGoogleの例であり、各組織で適切な目標値を設定することが重要です）。
  第3回で学んだ「イミュータブルインフラストラクチャ」や「宣言型API」は、手作業でのサーバ設定変更といった典型的なToilを根本から排除する、SREの思想と非常に親和性の高いアプローチです。
• どうやって (How)
  チームはToilを特定し、その削減に積極的に取り組みます。例えば、手動で行っていた日々のレポート作成を自動化したり、頻繁な問い合わせに対応するチャットボットを開発します。あるいは、GitHub ActionsによるCI/CDパイプラインの改善や、Terraformなどによるインフラ構成管理の自動化もToil削減の重要な活動です。これにより、エンジニアは未来への投資に時間を使えるようになり、組織全体の生産性が向上します。
• アンチパターン
  • 目の前の障害対応や問い合わせ対応に追われ、Toilの自動化が「いつかやるタスク」として永遠に後回しにされる。
  • 自動化自体が目的化し、費用対効果の低いToilの自動化に時間を浪費するケースがある。

そして伝説へ

あなたが築き上げたSREの仕組みは、レストラン帝国に本物の「信頼」をもたらしました。

かつて険しい顔で睨み合っていた開発チームと運用チームは、今、一つの大きなデジタルダッシュボードを一緒に見つめています。そこに映し出されているのは、今月の「エラーバジェット」の残量です。

開発リーダーが口火を切ります。
「エラーバジェットはまだ潤沢ですね。来週、計画通り新しいモバイルオーダー機能をリリースしましょう」

すると、運用リーダーが続けます。
「賛成です。ただ、先週予算を少し消費したデリバリー遅延の件、ポストモーテムは終わっていますか？」

「もちろんです。個人を特定して責任を追及するのではなく、事実ベースで原因を分析し、再発防止策として配送ルート最適化ロジックの改善を次の開発計画に組み込みました。その議事録もいつでも閲覧可能です」

この会話には、もはや対立や非難の空気はありません。
エラーバジェットという共通言語と、ポストモーテムという「失敗から学ぶ」文化が、彼らを同じデータを見て、同じ目標に向かって走る一つのチームに変えたのです。

その透明性の高い文化は、レストランの評価にも現れます。予告なしに訪れたミシュラン調査員は、料理の味はもちろんのこと、アプリの軽快な動作、注文から提供までの驚くべき速さ、いつアクセスしても安定している予約システムといった、あらゆる顧客体験に感銘を受けました。
その結果、あなたのレストランは星だけでなく、業界の新たなスタンダードとして最高の評価を獲得するに至ったのです。

もちろん、SREを導入し、文化として根付かせる道のりは平坦ではありませんでした。特に、個人を責めない「Blamelessな文化」 を根付かせることには、大きな努力が必要でした。
時にはツールの導入コストや、慣れないプロセスへの抵抗に直面することもありました。しかし、オーナーを説得しスタッフを信頼した上での先行投資は、長期的な視点で見れば、サービスの信頼性向上による機会損失の削減、Toil削減によるエンジニアの工数創出といった形で明確なリターンを生み、ビジネスの成長を加速させるROI（投資対効果）の高い重要な投資となりました。

シリーズで取り上げた様々な改革を乗り越えた先に、ビジネスの成長と揺るぎない信頼性という、かつてはトレードオフだと考えられていた二つを両立させる未来が待っていました。
こうして、あなたのレストランは伝説となったのです。

まとめ

お疲れ様でした。一人のシェフから始まったこの長い旅路は、これにて終幕です。

思えば、「Cloud-Native」がスケーラブルな「仕組み」を構築するための設計思想だとしたら、SREはその仕組みの上で、ビジネス価値と信頼性を両立させながら「運用」していくための哲学と言えるでしょう。「Cloud-Native」が強力なエンジンだとすれば、SREはその性能を最大限に引き出し、安全に目的地までたどり着くための計器盤と運転技術だと言えます。

このシリーズで取り上げた「The Twelve-Factor App(12FA)」「Beyond the Twelve-Factor App(Beyond 12FA)」「Cloud-Native」「Site Reliability Engineering(SRE)」とは、単なる技術用語やバズワードではありませんでした。そして、SREは特定のツールを導入すれば完成するものではなく、開発チームや運用チーム、時にはビジネスサイドまで巻き込んだ組織全体の文化変革であると解釈しています。

これらは、変化の激しい時代の中で、顧客に価値を届け続けるために、先達が築き上げてきた知恵の結晶であり、より良いソフトウェアを開発・運用するための壮大な冒険の地図だったのです。

次回はあなたの物語を

現実は色々厳しいのも重々承知ではありますが、これらの地図・知識は、少しずつでも実践することで初めて真価を発揮します。

このシリーズで紹介した知見を活かし、あなたの現場を「最高のレストラン」へと変革するための具体的なネクストアクションを、各旅の段階と紐づけて整理します。

• 「最高の厨房の基礎」を固める（第1回 The Twelve-Factor Appの実践）
  • コードベースと依存関係の明確化
    あなたのプロジェクトのpackage.jsonやrequirements.txtなどを確認し、依存関係が明示的になっているか、バージョン管理が適切に行われているかをチェックしましょう。もし曖昧な部分があれば、すぐに修正に取り掛かりましょう。
  • 設定の分離
    環境固有の設定（APIキーやDB接続情報など）がコード内にハードコードされていないか確認し、環境変数や専用の設定管理ツールへの移行を検討しましょう。
  • ログの標準化
    アプリケーションのログがファイルではなく、標準出力（stdout）に出力されるように変更し、ログ収集基盤での一元管理を計画しましょう。
• 「攻めのメニュー開発」に挑む（第2回 Beyond the Twelve-Factor Appの実践）
  • API Firstの検討
    新規機能開発や既存機能の改善において、まずAPI仕様から定義する「API First」のアプローチを試してみましょう。OpenAPI Specificationなどのツールを導入し、開発者間の共通言語とすることで、開発速度の向上を実感できるはずです。
  • テレメトリの導入
    重要なユーザー体験に紐づく指標（レスポンスタイム、エラー率など）を特定し、アプリケーションにログ、メトリクス、トレースを組み込むことを始めましょう。Prometheus, Grafana, Datadog, New Relicといったツールで可視化することで、お客様の「声」がデータとして見えてくるでしょう。
    これらは、SLI/SLOの計測という「目標設定」、障害の予兆検知という「インシデント対応」、負荷状況の把握という「キャパシティプランニング」など、SREの各プラクティスを支える生命線となります。
  • セキュリティのシフト・レフト
    新規プロジェクトや機能追加の際、設計段階からセキュリティ要件を議論し、CI/CDパイプラインにSAST/SCAツールを組み込むことで、開発早期に脆弱性を発見できる仕組みを作りましょう。
• 「世界展開可能なセントラルキッチン」を設計する（第3回 Cloud-Nativeの実践）
  • コンテナ化の推進
    既存のアプリケーションをDockerなどのコンテナ技術でパッケージングしてみましょう。開発環境と本番環境の差異をなくし、デプロイの安定性を高める第一歩です。
  • 宣言的APIの体験
    Kubernetesなどのコンテナオーケストレーションツールに触れてみましょう。YAMLファイルで「あるべき姿」を記述し、システムが自律的にその状態を維持する体験は、これまでの運用概念を大きく変えるはずです。
  • CI/CDパイプラインの構築
    コードの変更が自動的にテストされ、デプロイされるパイプラインを構築してみましょう。GitHub Actions, GitLab CI, CircleCIなどのツールを活用し、手動作業を排除し、新しい価値を迅速かつ安全に届けられるようになります。
• 「ミシュランも認める信頼性」を追求する（最終回 Site Reliability Engineeringの実践）
  • チームでSLI/SLOを設定してみる
    まずは小さなサービスや機能からでも構いません。チームで「本当に重要な顧客体験は何か？」を議論し、それを数値化するSLIを定義し、現実的なSLOを設定してみましょう。この議論自体が、開発と運用の共通認識を深める第一歩となります。
  • Toilを特定し、自動化のアイデアを出す
    あなたの日常業務で「手作業で、繰り返される苦痛な作業」はありませんか？ それをリストアップし、週に1時間でも自動化に向けた時間を確保してみましょう。TerraformによるIaC化や定型作業のスクリプト化など、たとえ小さな自動化でも、その積み重ねが大きな変化を生み出します。
  • SRE本を読んでみる
    本シリーズで紹介した概念は、Googleが公開しているSRE本で、さらに深く学べます。特に興味を持った章から読み進めてみることをお勧めします。
  • 社内でSREの概念を共有する
    学んだことをチームや組織内で共有する勉強会を開いてみたり、社内ライトニングトーク会に登壇してみましょう。SREは文化的な変革でもあるため、多くの人を巻き込むことが成功の鍵となります。
    また、SREを推進する専門チームをどう組織するか（開発チームにSRE担当者を置くEmbeddedモデル、全社的な基盤を提供するPlatformモデルなど）についても議論を始める良い機会になるでしょう。

これらが、あなたの現場をより良くするための具体的なステップとなることを願っています。

この壮大な旅路は、まだ始まったばかり。
あなたの手で最高のレストランを創り上げ、ミシュランガイドをオーバーフローさせましょう！

---

お断り
記事内容は個人の見解であり、所属組織の立場や戦略・意見を代表するものではありません。
あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。