SREの原則：7つの基本ルール

7つのSRE原則は、データセンター、ネットワーク、ロードバランサー、およびその間のコードのすべてを所有する企業から出ています。あなたのスタックはおそらくそうではありません。ユーザーが体験する多くの部分は、SSHログインできないインフラ、つまりCDN、認証プロバイダー、決済ゲートウェイ、DNS、タグマネージャー、パートナーAPI上で動作しています。

このギャップは重要です。なぜなら原則はGoogleの外でも有効ですが、故障したコンポーネントが自分の管理下にない場合、いくつかの原則は形を変えるからです。エラーバジェットは、他者の障害で1/3が消費される場合、異なる振る舞いをします。4つのゴールデンシグナルは、ファイアウォールの内外では異なって見えます。そして、エンジニアリングで排除できないリスクは測定しなければなりません。

この記事では、Google SRE本が定義する7つの原則を順に説明し、その後、本が省略する部分を追加します：自分で管理しないサービスに依存する場合、それぞれの原則がどのように見えるかです。もしこの役割に不慣れなら、最初にサイト信頼性エンジニアとは何かから始めてください。

SRE原則とは何か？

SRE原則は、Googleが大規模に信頼できるシステムを運用するために定式化した作業ルールです。それは、リスクを受け入れ管理すること、サービスレベル目標、単純作業の排除、モニタリング、自動化、リリースエンジニアリング、そしてシンプルさです。これらは合わせてひとつの問いに答えます：このサービスはどれだけ信頼性が必要で、それを保つ最も安価で持続可能な方法は何か？

リストは2016年にSRE本が出版されて以来変わっていません。変わったのは平均的なスタックです。マイクロサービス、SaaS依存、サードパーティスクリプトのため、信頼性の一部は今や他社の手にあります。以下の各セクションは、原則の定義をまず示し、その後依存先が自分のものではないときに壊れるものを説明します。最後に全7原則から導き出されたSREベストプラクティスの短いリストを掲載します。

原則1 – リスクを受け入れ管理する

Googleの定式：100％の信頼性は間違った目標です。ユーザーは独自に故障するネットワークやデバイスを通じてあなたにアクセスします。だからある一定のポイントを超えると追加の「ナイン」は実際のコストがかかり、誰にも違いがわかりません。業務が守れる信頼性目標を選び、その目標と完璧の間のギャップを機能提供に使える予算として扱います。リスクを受け入れる章で詳細に説明されています。

Google内部では、この仕組みが機能します。なぜならリスクはつまみで調整可能だからです。リプリケーション増加、冗長化増、展開の遅延：金を使えばナイン数は増えます。

Googleの外では、そのつまみの一部が何にも接続されていません。支払いゲートウェイにレプリカを追加できません。DNSプロバイダーのフェイルオーバー動作も調整できません。彼らの信頼性は契約条件であってエンジニアリングパラメータではありません。

したがって原則は形を変えます：あなたの所有するコンポーネントはエンジニアリングでリスク管理し、所有しないコンポーネントは測定で管理します。認証プロバイダーの実際の可用性を、彼らのステータスページの数字ではなく、ユーザー側のインターネットから計測したものを知る必要があります。ステータスページは部分障害中も正常運転を示しがちで、依存先が自社のデータセンターでは稼働中でも、あなたのデータセンターからは到達不能かもしれません。独立した測定こそが「CDNがおかしいと思う」という推測を、データで裏付けられた更新交渉に変えます。これがDotcom-Monitorがここで行う最初の仕事です：すべての重要な依存に外部チェックを置きます。プロバイダーのネームサーバーに対するDNSチェック、CDNエッジに対するHTTP(S)チェック、決済ゲートウェイに対するAPIチェックです。それぞれ、グローバルネットワークからの稼働率と応答時間の記録を構築します。そして数値が正当性を示す箇所にはリスクを回避するための迂回ルートを用意します：第2のDNSプロバイダー、バックアップ決済経路、サードパーティスクリプトのキャッシュコピーなど。

リスク管理の実装方法

• ユーザーのリクエストが触るすべての依存関係（DNS、CDN、認証、決済、サードパーティタグ）を一覧にし、エンジニアリング可能なものと測定のみ可能なものに分類する。
• 測定のみ可能なそれぞれについてDotcom-Monitorのデバイスを作る：プロバイダーのネームサーバーを指すDNSタスク、CDNエッジ上のHTTP(S)タスク、決済や認証エンドポイントに対するWebサービスのタスク。
• それらのチェックをユーザーの地域にある複数の監視ロケーションから実行し、ベンダーの一地域の障害により正常地域の裏に隠れないようにする。
• 各デバイスの稼働報告をベンダー談判に持ち込み、データがコストに見合うリスクと示す場合のみルーティングのバックアップ（セカンダリDNS、バックアップ決済経路）を追加する。

原則2 – サービスレベル目標（SLA、SLO、SLI）

3つの用語は頻繁に混同されるのでここで区分します：

• SLA（サービスレベル契約）: 契約。お客様に約束する内容と、それを守れなかった場合のペナルティ。
• SLO（サービスレベル目標）: サービスレベル指標に対する設定目標。通常社内向けでSLAより厳しく、自分たちのアラームが先に鳴るように設定。99.9%の稼働率、チェックアウト完了3秒以内など。
• SLI（サービスレベル指標）: 測定値そのもの。実際の稼働時間、応答時間、観測したエラー率など。

SLIが測定し、SLOが目標を設定し、SLAが約束します。お客様に渡す稼働率とSLAレポートも含め、すべての下流処理はSLIの信頼性に依存しています。

ここにほとんどのチームが盲点を持つ部分があります：エラーバジェットはその背後にある測定の精度に依存します。チェックが5分毎に実行される場合、記録された停止時間は開始と終了それぞれが5分の誤差範囲内でしかわからず、5分未満の停止は記録されない可能性があります。以下の表は典型的SLO目標に対する月間エラーバジェットに対し、30日（月あたり43,200分）として計算したものです。

5分チェックでは99.99％の月次SLOを測定できません。単一のチェック間隔が月間の全エラーバジェットを超えてしまいます。

確率の数学も厳しいものです。チェック間隔をI分、短い障害時間をD分（D < I）とすると、障害の開始タイミングがチェックスケジュールに依存しない場合、検出確率はおよそD/Iになります。つまり5分間隔で4分間の停止を検知する確率は5回中4回ですが、1/5回は2回のチェックの間に障害が完全に収まり検知されません。また、障害がチェック間隔より長い場合は平均検知遅延が約半分となり、5分チェックでは平均2.5分の検知遅れが発生します。

ただし注意点として、この表は単一の定期チェックと間隔ベースの停止時間計算を前提としています。複数ロケーション確認やリクエストベースのSLIは詳細は変えますが、サンプリングの問題は変わりません。

短時間の障害は例外ではありません。Dotcom-Monitorが検知した障害の約38％は5分以内に解決しています。これは主にネットワークのルーティングフラップ、再起動、フェイルオーバーなどで、自動回復するため人間が介入する前に完了します。私たちのレスポンスフィルターは正にこの理由でアラートを抑制します。しかしアラートから除外されても記録からは除外されません：その停止時間は内部SLAでもベンダーSLAでもカウントされなければならず、会計処理されます。アラートを発した障害のうち56％以上は最初の通知から15分以内に解決し、約18％が1時間以上継続し、約3％が24時間以上続きます。サービスの種類によって変動はありますが、形は同じで、すべての障害の3分の1以上が5分チェックでほぼ見えないバケットに入っています。これがチェック頻度がコストではなく測定決定である理由です：1分間隔では測定量子は99.9％の月間予算の11.6％から2.3％に減り、障害件数の大部分を占める短時間障害も記録に表れ始めます。だからDotcom-Monitorは1分毎にチェックを実行し、同じ記録を基にSLA報告を作ります：お客様に示す準拠数値は測定の裏付けがある場合にのみ信頼できます。

サービスレベル目標の実装方法

• ユーザーが認識できる、実ブラウザ起点の稼働率やチェックアウト時間のようなSLIを2,3個定義し、Dotcom-Monitorのチェックを記録ソースとする。
• 保護するSLAより厳しいSLOを設定し、上記表に従い、99.9％以上であれば1分毎のチェック頻度にデバイスを設定する。
• SLA談判の担当者に向けて稼働率およびSLAレポートを定期的に送る。準拠数値はアラートと同じチェック記録に基づく必要がある。
• 誰も特定の障害を議論していない時に、エラーバジェットを使い切った場合の対処方法を事前合意しておく。

原則3 – 単純作業を排除する

単純作業（トイル）は、サービスの規模に比例して増え、永続的価値を生まない手動で繰り返しの作業を指します。単純作業排除の章では有名な目標が設定されています：SREは時間の半分以上を単純作業に使わず、残りは単純作業を無くすエンジニアリングに使うべきと。

抽象的な定義は理解しやすいですが発見しづらいので、名前を挙げましょう。多くのチームでは以下のようなものです：

• 誰かが毎朝ログインしてチェックアウトフローがまだ機能することを確認する。
• 誰かがデプロイ後にサインアップフォームを手動テストする。
• 誰かがSSL証明書の有効期限をカレンダーに記録している。
• サポートチケットが急増した時に誰かが手動でパートナーAPIを叩き、「問題が自分たちか相手か」を調査する。

これらはすべてスクリプト化可能なトランザクションです。Dotcom-Monitorが役立つ部分です。EveryStepというポイント＆クリックのトランザクションレコーダーを使えば、実ブラウザで数分おきに同じチェックアウト経路を歩かせ、失敗した瞬間にアラートを上げられます。証明書チェックはカレンダー不要、APIチェックはスケジュール実行で応答時間履歴を保持し、「自社か相手か」問題を一目で解決します。

優先的に自動化すべきかどうかは複雑さではなく、再発頻度が基準です。日々手動で行われるチェックは機械で1分ごとに実施すべきチェックです。

単純作業排除の実装方法

• チームメンバーが行うすべての手動チェックを1週間記録する。複雑さではなく頻度が優先度を決める。
• 最頻のものをEveryStepスクリプトに記録し、朝1回の代わりに数分毎に実行させる。
• 証明書有効期限カレンダーはDotcom-MonitorのSSLチェックに置き換え、パートナーAPIはスケジュールされたWebサービスチェックで管理する。
• 四半期ごとに削減した手動チェック時間を追跡し、自動化作業を可視化し資金を維持する。

原則4 – モニタリングと4つのゴールデンシグナル

分散システムモニタリングの章は4つのゴールデンシグナルを名指しします：レイテンシ、トラフィック、エラー、飽和状態。この4つを監視すればほとんどの問題を捕捉できます。

章はブラックボックス監視に言及していますが、多くのチームはこれら4つの信号をシステム内部から計測しています。代わりにユーザー視点から監視すれば、このうち3つは変化します：

表を正直に読むと結論は「外部の方が良い」ではなく、どちらの視点もすべてを見ていないということです。トラフィックと飽和は内部ツール群の領域：Prometheus、Datadog、New Relicなど。ユーザーが体験するレイテンシとエラーは外部の合成監視の領域です。ここがDotcom-Monitorの担当部分です。実ブラウザチェックはグローバルネットワークからユーザーのページを読み込み、DNS解決、TLSハンドシェイク、CDNエッジ、ページレンダリング、ユーザースクリプトのステップ時間を測ります。HTTP(S)、API、DNS、TCP、ICMPのプロトコルチェックはページ周辺の依存関係を監視します。これら2つは競合するものではなく、同じ4つの信号の異なる視点であり、双方が必要です。

実用的なルール：ユーザーが実感できる信号は必ずユーザーがいる場所で測定が必要です。CDNがヨーロッパ半分にキャッシュされたエラーページを返す間、APMダッシュボードがグリーンを示す光景は仮想のものではありません。これは内部監視のみの標準的な失敗モードです。

モニタリングの実装方法

• トラフィックと飽和はAPMまたはPrometheusスタックに残し、レイテンシとエラーはユーザーの実際の地域からのDotcom-Monitorの実ブラウザチェックに任せる。
• ステータスコードチェックだけでなくコンテンツ検証も設定し、HTTP 200なのに壊れたチェックアウトがユーザーと同じように失敗扱いになるようにする。
• EveryStepで重要なトランザクション（ログイン、検索、チェックアウト）をスクリプト化し、監視がユーザーの行動経路をたどるようにする。
• 内部外部の数値を定期的に比較し、その差分がCDN、DNS、サードパーティ層であることを理解する。

原則5 – 自動化

SREにとって自動化はスケール時の一貫性です。人間はステップを忘れるが機械は忘れず、午前3時に対応が必要な場合、人間の鋭敏さに依存すべきではありません。

Googleの外で変わる部分：自動化はそれを起動するシグナルの質に依存します。フェイルオーバースクリプト、ロールバックジョブ、自動スケールルールはすべて検知イベントで起動するため、検知遅延1分はそのまま自動応答処理の遅れになります。SLOセクションの計算はここでも直接適用でき、5分チェックでトリガされた自動フェイルオーバーは平均2.5分の先行を相手に与えることになります。

また一部の自動化トリガーは外部からしか得られません。バックアップ決済プロバイダーにフェイルオーバーするスクリプトは、健康診断エンドポイントが社内ネットワークからping応答するだけではなく、本当にユーザーがプライマリの障害を体験していることを知る必要があります。Dotcom-Monitorは外部チェックからのアラートとWebhookでそのループを閉じており、ヘルスエンドポイントの主張ではなくユーザー体験に基づいてフェイルオーバートリガーを発生させます。

自動化の実装方法

• インシデント中に手動で行う応答（再起動、フェイルオーバー、ロールバック）を自動化の起点にする。
• Dotcom-MonitorのアラートWebhookをこれらのスクリプトに接続し、トリガーを内部ヘルスエンドポイントではなく外部で確認された障害にする。
• アラートエスカレーショングループを設定し、最初の通知が真に行動する人またはシステムに届くようにする。深夜3時に誰も見ない共有Inboxではない。
• Response Filterで自己解決する瞬間的障害を吸収し、自動化トリガを発火させないようにし、四半期ごとに誤警報率を見直す。

原則6 – リリースエンジニアリング

リリースエンジニアリングとは、毎回同じ方法でソフトウェアをビルド・出荷する技術です：バージョン管理されたビルド、再現可能なパイプライン、リハーサル済みで動作するロールバック。

モダンCI/CDによってパイプライン内部の大部分はカバーされています。テストは合格し、アーティファクトは生成され、フラグを使ったデプロイが行われます。パイプラインでは、デプロイ後にシステムがユーザーにとって正常動作するかは測れません。ビルドが成功しても、伝播しないDNSレコード、古いバンドルがキャッシュされたCDN、組み合わさって壊れるサードパーティタグ、プロダクションにしか存在しない設定値などはわかりません。

そこを埋めるのがデプロイ後の検証です。EveryStepで重要経路（ページ読み込み、ログイン、トランザクション完了）を歩くスクリプトをDotcom-Monitorのネットワークからプロダクションに対してデプロイ毎に即実行し、ユーザーが実際に得るものをテストします。この検証を実行するチームは、パイプラインの最終段階として扱います：デプロイ→外部からの検証→成功ならリリース完了。チェックが失敗すれば、被害半径がまだ数分のうちにロールバックが動きます。

リリースエンジニアリングの実装方法

• すべてのビルドにバージョンを付け、ロールバックは即時にかつリハーサル済みのワンステップ操作にする。
• EveryStepトランザクションをプロダクションに対してパイプラインの最終段階に設定し、Dotcom-MonitorのネットワークからDNSやCDNキャッシュ、サードパーティタグを含めてテストする。
• チェックのアラートWebhookをパイプラインに戻し、ポストデプロイ検証失敗は翌朝のチケットではなく自動ロールバック合図にする。
• リリース間でも同じチェックを継続実行し、その履歴を基準線としてデプロイ後の速度低下を判断する。

原則7 – シンプルさ

シンプルさの章は信頼性と複雑性はトレードオフ関係にあり、追加するコンポーネント数が増えるほど故障ポイントも増えるため、ソフトウェアは仕事に必要な分だけの複雑さであるべきだと論じます。

これをモニタリングスタックにも適用すると、複雑さは静かに積み重なります。チームはAPMツール、ログプラットフォーム、稼働監視、ステータスページサービス、そして誰も開かない3つのダッシュボードを持つようになります。各ツールは各自のスケジュールでアラートを出し、合計で警告疲労を起こします。重要なものが他の通知と一緒に見過ごされるようになります。

モニタリングベンダーが監視ツールを減らせと言うのは珍しい議論であり、それがゆえに価値があります。監視スタックのシンプルさのテストは2つの質問に集約されます。まず、監視対象ごとに、複数ツールで不一致があった時にどれが信頼されるか明確か。次に、発生するすべてのアラートに必ず対応する人がいるか。どちらも満たさないツールは監視ではなく騒音であり、購読料を取るゴミです。稼働監視、トランザクション、API、インフラチェックを単一プラットフォームにまとめ、単一のアラート経路を持つことは購入判断の前にシンプルさ決定です。これがDotcom-Monitorの設計方針です：すべてのチェックを1カ所で行い、単一の通知経路で扱い、内側監視のAPMツールと共存します。

シンプルさの実装方法

• 監視ツールを一覧化し、それぞれが権威を持つ一つの項目を明示する。
• 所有者も対応もないアラートはすべて削除する。誰も対応しないものは騒音である。
• 外部チェック（稼働、ページ、トランザクション、API、インフラ）をDotcom-Monitorに統合し、単一プラットフォーム化し単一アラート経路にまとめ、APMは内部監視のまま維持する。
• 毎年監査を繰り返す。監視スタックは放置すると複雑さが再成長する。

SREベストプラクティス

原則は目指すべき方向を示します。以下は、スタック全体を所有しないチームでも機能する実践例です：

• サーバーが報告するデータではなく、ユーザーが体験する内容にSLOを設定する。「実ブラウザで4秒以内にチェックアウト完了」はユーザーが認識できるSLO。「API p95が200ms以下」はインプットです。
• チェック頻度をSLOに合わせる。上記のエラーバジェット表に基づき、99.95％以上では5分のチェック間隔が月間予算の23％を消費し、99.99％では予算を超過します。99.95％以上は1分チェックが実用的な下限と考える。
• 依存先も自身と同じく監視する。DNS、CDN、決済、認証の各重要依存に対して独自の外部チェックを持ち、それぞれ応答時間履歴を持つ。ベンダーのステータスページが正常でもユーザーが障害を感じれば、データが議論を解決する。
• エラーバジェット方針は予算消費前に策定する。予算消費後に何が起きるか、機能凍結、信頼性改善、ポストモーテムの優先順位を事前合意しておく。方針のない予算は誰も使わないグラフに過ぎない。
• インシデント対応は事前にリハーサルする。オンコール交代、エスカレーションパス、ブレームレスポストモーテムはSREインシデント管理ガイドで詳述する。
• ツール数は正直に管理する。年1回上記シンプルさの質問に基づき監視スタックを監査する。SREツールまとめで維持する価値のあるカテゴリを紹介。
• 信頼性報告は慌てるものではなく習慣にする。スケジュールされた稼働率とSLAレポートにより、コンプライアンスの会話は争いの後のログ掘りよりも共有数値から始まる。

結論

7つのSRE原則はGoogleから外に出ても生き残りました。しかしその背後にある前提、適用するチームがスタック全体をコントロールしている、は生き残りませんでした。実際にはコントロールできず、それが仕事を変えます。エンジニアリングで排除できないリスクは測定し、エラーバジェットはその裏にあるチェック間隔に依存します。トラフィックと飽和は内部ツールがカバーし、ユーザー体験するレイテンシとエラーは外部視点でしか現れません。デプロイ後の検証は外部から行う必要があります。なぜならシステム全体が存在する唯一の場所だからです。

共通するのは外部からの測定です。所有していないコンポーネントで満たす原則は、独立した視点を必要とします：リスクには依存ごとのチェック、エラーバジェットには1分間隔、ゴールデンシグナルには実ブラウザ、単純作業とリリースにはスクリプト化されたトランザクション、シンプルさには単一プラットフォーム。この役割をDotcom-Monitorは7原則全体に渡り担います。ツールの好みではなく、スタックが自社のものではなくなった時に原則が要求するものです。

よくある質問