SLI、SLO、SLA

本番環境を動かす3文字

測定のない信頼性は演技です。SREは、事前に合意され、誰でも検証可能な数値として信頼性を定義します。

Service Level Indicator (SLI): サービス行動の測定値。例: リクエストレイテンシ、エラーレート、スループット、キュー深度。SLI はグラフ化できる指標です。

Service Level Objective (SLO): SLI の目標値または範囲。例: 「過去28日間のローリングウィンドウで HTTP リクエストの 99.9% が成功する」。SLO は、自分自身とユーザーに対して「許容できるサービス品質」を約束するものです。

Service Level Agreement (SLA): 違反時に金銭的ペナルティを伴う契約上のコミットメント。例: 「月間可用性が 99.9% を下回った場合、10% を返金する」。SLA は弁護士によって強制される約束です。

重要な違い: SLA は常に SLO より緩やかでなければならない。内部で 99.9% を目標にし、外部で 99.9% を契約すると、余裕がゼロになる。SRE は通常、SLO を SLA より 1 ナイン厳しく設定する（例: 目標 99.95%、契約 99.9%）。この差が、避けられない悪い週を吸収する。

Error Budgets: The Inverse SLO

信頼性目標からエンジニアリング判断へ

SLOは信頼性の目標を設定します。エラーバジェットとは、その目標を達成するために許容できる残りの失敗量です。

SLOが28日間で99.9%の成功を約束する場合、エラーバジェットはリクエストの0.1%に相当し、1ヶ月あたり約40分間の完全停止に相当します。この予算は、計画的なリリース、実験的な機能、chaos engineering、依存関係の不具合への耐性など、自由に使えます。

エラーバジェットは、開発と運用の対立を再定義します。 予算がない場合、障害が発生するたびに「誰が悪い変更をデプロイしたか」「次にどう防ぐか」という議論が始まります。予算がある場合：

- 予算が残っている場合：より速くリリースし、リスクを取って実験できます。予算がその代償を支払います。

- 予算が使い切られた場合：新機能のリリースを停止し、リスクの高い変更を凍結し、予算が回復するまで信頼性向上に注力します。

これにより、信頼性は感情的な議論ではなく、測定可能なリソースへと変わります。エンジニアは予算を他の生産リソースと同じように意図的に使うことができます。

Toilの定義

Toilに該当するもの

すべての運用タスクがToilに該当するわけではありません。SREではToilを厳密に定義しています。それは 手動で、繰り返し発生し、自動化可能で、戦術的で、永続的な価値がなく、サービスが成長するにつれて直線的に増加する 作業です。

これら6つの条件すべてが満たされる必要があります。一度限りのデータ移行は手動ですが繰り返しではないため、Toilには該当しません。上級エンジニアが新しいサービスアーキテクチャを設計する作業は戦術的な判断ですが、永続的な価値を生むため、Toilには該当しません。

Toilに該当する例：

- メモリリークによるクラッシュ後にサービスを手動で再起動する

- インシデント対応中にログの断片をチャットチャンネルに貼り付ける

- 新しいデータベースをプロビジョニングするためにチケットフォームに入力する

- 手作業による四半期キャパシティレポートの作成

- 日常的なデプロイ要求を一件ずつ承認する作業

50%ルールは、ToilをSREの時間の半分までに制限します。50%を超える場合、チームはプロダクトチームに責任を戻すか、エンジニアを増員する必要がありますが、目標は変わりません。人間の介入なしで同じ作業を行うエンジニアリングされたシステムに置き換えることで、Toilをゼロに近づけることです。

自動化は単に時間を節約するだけではありません。ある種のヒューマンエラーを完全に排除します。データベースをプロビジョニングするスクリプトは、長時間のシフト後に手順を忘れることはありません。

Toil監査の考え

Your team tracks how its time gets spent. Last quarter the breakdown was: 30% deploys, 25% incident response, 20% capacity work, 15% feature engineering, 10% one-off requests from product teams.

オンコール衛生 [BLOCK_TYPE oncall/rotation]

エンジニアであって、Pagerではありません

オンコールには実質的なコストが伴います。睡眠が妨げられ、週末が中断され、未知の問題に対するストレスが積み重なります。SREはオンコールを有限のリソースとして扱い、持続可能な状態に保つべきものであり、誰かが最も気にかけるからといって英雄的に負担を背負うものではありません。

健全なオンコールローテーションは、いくつかの原則に従います：

- 補償される時間: オンコール時間は代休、追加手当、または同等の特典に換算されます。無償のオンコールはチームを疲弊させます。

- 適切なローテーションの深さ: 6人チームで一次担当と二次担当を回す場合、各エンジニアは3週間に1回のシフトを担当します。2人でのローテーションはキャリアを破壊します。

- ページング量の予算: GoogleのSRE本では、12時間シフトあたり最大2件のページングイベントを推奨しています。それを超える場合は、チームはアラート量を耐えるのではなく、削減するためのエンジニアリング時間を投資する必要があります。

- アクション可能なアラートのみ: すべてのページは人間のアクションを必要とするものでなければなりません。無視される、自動化される、または通常運用中に繰り返し発生するページは存在すべきではありません。アラート疲労は信頼性の欠陥です。

- フォロー・ザ・サンの引き継ぎ: グローバルに分散したチームはタイムゾーンの境界でシフトを引き継ぎ、システムが本当に朝まで待てない場合を除き、誰も午前3時にページを受けないようにします。

Blameless Postmortems

How Outages Become Improvements

重大なインシデントはすべてポストモーテムを実施します。これは、何が起こったのか、なぜ起こったのか、何が問題を修正したのか、そして再発を防ぐためにどのような変更が必要かを分析した文書です。ポストモーテムはSREにおける複利のようなものであり、それぞれがシステムに永続的な信頼性を加えます。

Blameless（非難を排する）とは、文書が個人の責任ではなく、システムやプロセスに失敗の原因を求めることを意味します。エンジニアが誤ったコマンドを実行した場合、ポストモーテムは「なぜシステムがそのコマンドを許可したのか」「なぜセーフガードが機能しなかったのか」「システム・ドキュメント・ツールのどの変更が、同じミスを次に防げるのか」を問いかけます。

Blamelessnessが存在する理由はただ一つです。人々は罰を恐れるとミスを隠します。隠されたミスは次のインシデントになります。非難を排する文化のコストは、未開示の欠陥が蓄積するコストに比べれば安価です。

ポストモーテムは通常、以下を扱います：

- Summary: インシデントとその影響を1段落で説明

- Timeline: タイムスタンプ付きの分単位の再現記録

- 根本原因分析: 障害を許した技術的・プロセス的な要因

- 検知: チームがインシデントをどのように把握したか、およびその所要時間

- 復旧: サービスを復旧するために実施したアクション

- 教訓: うまくいったこと、いかなかったこと

- アクションアイテム: 具体的で担当者が決まり、期限付きのエンジニアリングタスク

アクションアイテムはトラッカーで管理されます。他のエンジニアリング作業と同様に優先順位付けされます。アクションアイテムのないポストモーテムは単なるお話会に過ぎず、何も変わりません。

4つのゴールデンシグナル

すべてのサービスが測定すべきこと

GoogleのSRE本では、ユーザー向けサービスが必ず公開すべき4つのシグナルを提唱しています：レイテンシ、トラフィック、エラー、サチュレーションです。これら4つを組み合わせることで、ユーザーの視点からサービスの健全性を把握できます。シグナルが少なすぎると盲点が生まれ、数百ものメトリクスを監視するとアラート疲れに陥ります。

レイテンシ：リクエストの処理にかかる時間です。平均値ではなく分布を追跡してください。p50（中央値）は典型的なユーザー体験を示し、p99は最悪の1%のユーザーを表します。平均値だけを見ていると長いテールが隠れてしまいます。中央値50ms、p99が5,000msのサービスは平均値では問題なく見えますが、100人に1人のユーザーを苦しめます。

トラフィック：サービスにかかる負荷です。Webサービスの場合は1秒あたりのリクエスト数、ストリーミングサービスの場合は同時接続数、バッチジョブの場合は1分あたりの処理件数で表されます。トラフィックはキャパシティ計画と相関し、異常なワークロードを検知する手がかりになります。

エラー：失敗したリクエストの割合です。明示的な失敗（HTTP 500）、暗黙的な失敗（HTTP 200だがデータが破損）、ポリシー上の失敗（SLOを満たせないほど遅い応答）すべてをカウントします。これらを区別することは重要です。ペイロードが不正な200は、正直な500よりもユーザーへの影響が大きい場合があります。

飽和度: システムがどれだけフル稼働しているか。CPU使用率、キューの深さ、メモリプレッシャー、コネクションプール占有率。飽和度は将来のレイテンシを予測する。CPU使用率95%のシステムでは、ユーザー向けレイテンシが急増するまでの余裕がほとんどない。

SREのアラートのほとんどは、これら4つのシグナルから導かれる。症状ベースのアラート（ユーザーが気づくタイミングで発報）は、原因ベースのアラート（CPUが80%を超えたら発報）よりも優れている。4つのゴールデンシグナルは症状を表す。

SREのキャリアパス

SREスキルが活きる場所

SREのキャリアは、エンジニアがどの部分の分野を最も楽しむかによって分かれる：

インフラSRE: 他のチームが稼働するプラットフォームを構築する。Kubernetes、サービスメッシュ、社内クラウドなどを扱う。システムエンジニアリング、分散システム理論、プラットフォーム設計が中心。大規模企業では、1人のインフラSREが数百人のプロダクトエンジニアを支えるため、非常に高い報酬が得られる。

Embedded SRE: 特定のプロダクトエンジニアリングチームと連携し、サービスの信頼性を向上させる。エンジニアとコーチの両方の役割を担う。技術力だけでなく、コミュニケーション力やコードレビュー力が重要。教えることが好きなエンジニアに向いている。

Reliability tooling: 可観測性スタック（監視、アラート、ダッシュボード、ポストモーテムツール、インシデント管理プラットフォーム）を構築する。フロントエンドとデータエンジニアリングの要素が強い。他のすべてのチームが利用する成果物となる。

Production engineering: Facebook/MetaにおけるSREの呼称で、キャパシティ、デプロイ、トラフィック管理に注力する。ネットワークとシステムに関する作業が中心。

保有する価値のある技術認定: Google Cloud Professional Cloud Architect、AWS Solutions Architect Professional、CNCF認定（Kubernetes Administrator、Kubernetes Application Developer）はクラウドネイティブの習熟度を示します。Linux Foundation認定はシステムの深さを示します。これらはポートフォリオの代わりにはなりませんが、リクルーターのスクリーニングを通過するのに役立ちます。

まとめ

学んだこと

Site reliability engineeringは、Googleがスケーリングの問題に対する解決策として生まれたものが、現在では業界全体で実践される分野へと成長しました。以下の内容を学びました：

- 手動運用からエンジニアリングによる信頼性への移行

- SLI、SLO、SLA、およびSLOの逆概念であるエラーバジェット

- Toilの定義、50%ルール、およびエンジニアリング主導の削減

- 持続可能なオンコールローテーションと非難を排したポストモーテムの実施

- サービス監視の出発点としての4つのゴールデンシグナル

- SREのキャリアパスと、扉を開く各種認定資格

最も重要な考え方が2つあります。信頼性とは事前に合意された数値であること。そしてトイルは欠陥であり、職務記述書ではないこと。この2つを胸に刻めば、残りのSREは自然に導かれます。

おすすめの参考資料：GoogleのSRE Book（無料でオンライン公開：sre.google/books/）、実践演習向けのSRE Workbook、そしてCharity Majors氏による可観測性に関する記事です。併せて提供される「geometry-of」レッスンでは、SREの実践を支える視覚的構造（レイテンシ分布、エラーバジェットコーン、依存関係グラフ、ダッシュボードレイアウト）についてより深く掘り下げています。