2.1SLI / SLO / SLA
★★★ 必須| 用語 | 意味 | 例 | 誰のためのものか |
|---|---|---|---|
| SLI | サービス品質の実測指標 | 成功リクエスト数 ÷ 全リクエスト数 | 計測の基準 |
| SLO | SLIの内部目標値 | 30日間の可用性 99.9% | 開発・運用チーム |
| SLA | 顧客との契約上の約束（違反時にペナルティ） | 99.5%を下回ったら返金 | 顧客 |
SLOはSLAより厳しく設定するのが基本（SLA違反の前に気づいて手を打つため）。
SLOをSLAより内側に置くことで、契約違反の前に改善の時間を確保できる。
第2部 SREの考え方・第2章
SRE概念・監視・インシデント対応
★★★ 必須16トピック・面接 8問
定義を答えるだけでは足りない。「自社でどう決め、どう運用し、何が起きたか」まで話せると評価が上がる。
障害対応の演習を読み込んでいます…
2.2SLIの選び方（サービス種別ごと）
★★★ 必須| サービスの種類 | 代表的なSLI | 計測方法の例 |
|---|---|---|
| Web / API（リクエスト応答型） | 可用性（5xx以外の割合）、レイテンシ（300ms以内の割合） | ALBログ、APM、サービスメッシュ |
| バッチ・データ処理 | 鮮度（何分前のデータか）、正確性、処理完了率 | ジョブの完了時刻、検証ジョブ |
| ストレージ | 耐久性、読み書きのレイテンシ | ストレージのメトリクス |
| 非同期処理（キュー） | 処理遅延（投入から完了まで）、失敗率 | キューの最古メッセージ経過時間 |
| 外部ユーザーの体験 | ページ表示の成功率、Core Web Vitals | 合成監視、RUM |
レイテンシは平均ではなくパーセンタイル（p95、p99）で見る。平均は一部の極端に遅いリクエストを隠してしまう。
2.3可用性とダウンタイムの対応表
★★★ 必須| 可用性 | 年間の許容停止 | 30日の許容停止 |
|---|---|---|
| 99% | 約3.65日 | 約7.2時間 |
| 99.9% | 約8.76時間 | 約43分 |
| 99.95% | 約4.38時間 | 約22分 |
| 99.99% | 約52.6分 | 約4.3分 |
直列に依存するコンポーネントの可用性は掛け算になる（99.9% × 99.9% ≒ 99.8%）。冗長構成は 1 − (1 − a)^n で上がる。
2.4エラーバジェットの計算例
★★★ 必須| 項目 | 値 |
|---|---|
| SLO | 30日間で可用性 99.9% |
| 月間リクエスト数 | 1億件 |
| エラーバジェット | 1億 × 0.1% ＝ 10万件の失敗まで許容 |
| 時間換算 | 30日 × 0.1% ≒ 43分の全停止に相当 |
大きなインシデントは一度に予算を削る。残量でリリースの方針を切り替える。
2.5バーンレートアラート
★★★ 必須バーンレートは「エラーバジェットを想定の何倍の速さで消費しているか」。1なら30日でちょうど使い切る速さ。
| 重要度 | バーンレート | 判定窓 | 意味 | 対応 |
|---|---|---|---|---|
| 緊急（ページ） | 14.4 | 1時間（確認用に5分） | 1時間で月の予算の2%を消費 | 即時対応 |
| 緊急（ページ） | 6 | 6時間（確認用に30分） | 6時間で5%を消費 | 即時対応 |
| 通常（チケット） | 1 | 3日（確認用に6時間） | 3日で10%を消費 | 営業時間内に対応 |
長い窓だけだと検知が遅く、短い窓だけだとノイズが多い。両方を組み合わせる（マルチウィンドウ）のがGoogleのSRE Workbookで紹介されている方式。
2.6エラーバジェットポリシーの例
★★★ 必須| バジェットの状態 | 取る行動 |
|---|---|
| 50%以上残っている | 通常どおりリリース。実験的な変更も可 |
| 残り 25〜50% | リリースは継続、リスクの高い変更は慎重に |
| 残り 25%未満 | 信頼性改善のタスクを優先。大きな変更は延期 |
| 枯渇 | 機能リリースを停止し、信頼性改善に集中（緊急修正を除く） |
2.7監視のフレームワーク
★★★ 必須| 手法 | 対象 | 見る指標 |
|---|---|---|
| Four Golden Signals | ユーザー向けサービス | レイテンシ、トラフィック、エラー、飽和度 |
| RED | リクエスト駆動のサービス | Rate（秒間リクエスト）、Errors、Duration |
| USE | リソース（CPU、ディスク等） | Utilization、Saturation、Errors |
ひとことで
システムの外に出てくる情報から、中で何が起きているかを後から調べられる性質。メトリクス・ログ・トレースの3つを組み合わせる。
モニタリングは「あらかじめ決めた指標が閾値を超えたら知らせる」ことで、既知の問題に強い仕組みです。オブザーバビリティは、事前に想定していなかった問題でも、出力されたデータを組み合わせて原因まで掘り下げられる性質を指します。マイクロサービスのように経路が複雑になるほど重要になります。
| メトリクス | ログ | トレース | |
|---|---|---|---|
| 答える問い | 何かおかしいか | なぜ起きたか | どこで時間がかかったか |
| 中身 | 数値の時系列（エラー率、p99、CPU） | 個々の出来事の記録 | 1リクエストが通ったサービスと所要時間 |
| コスト | 安い | 量が多く高い | サンプリングで調整 |
| 得意なこと | アラート、傾向の把握 | 詳細な原因の調査 | ボトルネックの特定 |
トレースは、1つのリクエストにtrace IDを付け、サービスをまたぐたびにHTTPヘッダー（W3Cのtraceparent）で次へ引き継ぎます。各サービスでの処理はスパンとして記録され、親子関係でつながります。今は計装の標準としてOpenTelemetryが広く使われていて、特定の監視製品に縛られずにデータを送れます。
| 運用のポイント | 内容 |
|---|---|
| カーディナリティに注意 | ユーザーIDのように値の種類が膨大なものをメトリクスのラベルにすると、系列数が爆発してコストと性能を圧迫する。ログやトレースに入れる |
| ログは構造化する | JSONで出し、trace ID・サービス名・リクエストIDを必ず入れる。検索と集計がしやすくなる |
| サンプリング | すべてのトレースを保存すると高い。全体の一部を残すか、エラーや遅いものを優先して残す |
| SLOとつなぐ | ユーザー体験に近いSLIをメトリクスで出し、バーンレートでアラートする |
| コスト管理 | ログの保持期間、詳細度、サンプリング率を決め、量の推移を監視する |
3つを同じIDでつなげることで、グラフから原因のログまで数クリックでたどり着ける。
平均のレイテンシだけでは分からない「どの依存先が遅いか」が見える。
面接ではこう答える
オブザーバビリティは、外に出てくるデータから想定外の問題も調べられる性質で、メトリクス、ログ、トレースを組み合わせます。メトリクスで異常に気づき、トレースでどのサービスが遅いかを特定し、ログで原因を読みます。trace IDで3つをつなぎ、計装にはOpenTelemetryを使うのが一般的です。メトリクスのラベルに値の種類が多いものを入れないなど、コストにも気を配ります。
SREとの関わりAPM・監視基盤の設計、アラート設計、障害調査の速さ（MTTR）、監視コストの管理に直結します。
2.9監視・オブザーバビリティの構成
★★★ 必須| 種類 | 何がわかるか | ツールの例 |
|---|---|---|
| メトリクス | 数値の推移（傾向、しきい値） | CloudWatch、Prometheus、Datadog |
| ログ | 個々のイベントの詳細 | CloudWatch Logs、Loki、Datadog Logs |
| トレース | リクエストがどのサービスでどれだけ時間を使ったか | OpenTelemetry、X-Ray、Datadog APM |
| 合成監視 | 外部から見て使えるか | Datadog Synthetics、CloudWatch Synthetics |
| RUM | 実ユーザーの体験 | Datadog RUM |
ひとことで
ログは「すぐ検索する期間」と「長く保管する期間」を分け、法令・契約で決まる下限と、コスト・個人情報で決まる上限の間で期間を決める。
ログは種類ごとに、誰が、何のために、いつまで使うかが違います。障害調査のためのアプリのログは直近の数週間がよく使われ、監査のための操作ログは何年も保管が求められることがあります。すべてを高価な検索サービスに無期限で置くと、費用が膨らみ続けます。
| ログの種類 | 保持の考え方の例 |
|---|---|
| アプリ・アクセスログ | 直近は検索サービスに、それ以降はS3に移して必要時に検索 |
| 監査ログ（CloudTrailなど） | 別アカウントに集め、改ざんできない形で長期保管 |
| セキュリティのログ（WAF、VPCフローログ、認証） | インシデント調査に備えて一定期間保管 |
| 個人情報を含むログ | 必要最小限の期間に。マスキングしてから出力する |
| デバッグログ | 短期間。本番では出力量を絞る |
| 決めること | 内容 |
|---|---|
| 保持期間の根拠 | 法令、業界の基準（たとえばPCI DSSでは監査ログを1年以上保持し、直近3か月はすぐ参照可能に）、顧客との契約、社内規程 |
| 保管場所と階層 | ホット（検索サービス）・ウォーム（S3＋Athena）・コールド（Glacier） |
| 改ざん防止 | 監査ログは別アカウント、S3 Object Lock、ハッシュの検証（CloudTrailのログファイル検証） |
| 削除の自動化 | CloudWatch Logsの保持期間の設定（既定は無期限）、S3のライフサイクルルール |
| 検索できること | 長期保管したログを、必要なときに実際に検索できるか手順を確認しておく |
「保持期間が決まっていないロググループ」がないかを定期的に確認するだけで、費用は大きく下がる。
面接ではこう答える
ログは種類ごとに保持期間を決め、下限は法令・業界基準・契約で、上限はコストと個人情報の最小化で決めます。直近はCloudWatch Logsなどで検索し、それ以降はS3に移してAthenaで必要時に検索し、長期はGlacierで安く保管します。監査ログは別アカウントに集めてObject Lockで改ざんを防ぎ、CloudWatch Logsは既定が無期限なので保持期間を必ず設定します。
SREとの関わり監視コストの管理、監査やインシデント調査への備え、個人情報の取り扱いに関わります。
2.11インシデント対応の流れ
★★★ 必須検知（アラート、問い合わせ）
トリアージ（影響範囲と緊急度の判断、インシデント宣言）
役割分担（インシデントコマンダー、調査担当、連絡担当）
緩和（ロールバック、切り離し、スケールアウト。原因究明より復旧を優先）
復旧の確認と関係者への報告
ポストモーテムと再発防止策の追跡
4の緩和が最優先。原因が分からなくても、ロールバックや切り離しで先に影響を止める。
2.12インシデント対応の役割
★★★ 必須| 役割 | 責任 |
|---|---|
| インシデントコマンダー（IC） | 全体の指揮、判断、優先順位づけ。自分では手を動かさない |
| 調査・対応担当 | 原因調査と緩和作業 |
| コミュニケーション担当 | 社内外への状況報告（ステータスページ、CS、経営） |
| 記録担当 | タイムラインと判断の記録。ポストモーテムの材料になる |
2.13重大度レベルの例
★★★ 必須| レベル | 定義の例 | 対応 |
|---|---|---|
| SEV1 | 全ユーザーが主要機能を使えない、データ損失 | 即時招集、経営へ報告、ステータスページ更新 |
| SEV2 | 一部ユーザーや重要機能に影響 | 即時対応、関係部署へ連絡 |
| SEV3 | 軽微な影響、回避策あり | 営業時間内に対応 |
2.14ポストモーテムの構成
★★★ 必須| 項目 | 書く内容 |
|---|---|
| 概要 | 何が起きたかを3行で |
| 影響 | 影響を受けたユーザー数、時間、機能、売上やSLOへの影響 |
| タイムライン | 発生、検知、宣言、緩和、復旧の時刻（検知までの時間が重要） |
| 根本原因 | 技術的な原因と、それを許した仕組みの問題（なぜなぜ分析） |
| うまくいったこと | 次も続けるべき対応 |
| 改善できること | 検知、連絡、手順の課題 |
| アクションアイテム | 担当者と期限つき。追跡されなければ意味がない |
「人為的ミス」を根本原因にしない。人がミスできてしまう仕組み（確認なしで本番に適用できる等）を原因として扱うのがブレームレスの考え方。
2.15よく聞かれる質問と回答の要点
★★★ 必須| 質問 | 回答の要点 |
|---|---|
| エラーバジェットとは？ | 100% − SLO が「失敗してよい量」。余裕があればリリース速度を上げ、枯渇したら信頼性改善を優先する。開発と運用の合意形成の道具 |
| SLOはどう決める？ | ユーザー体験に近い指標（ユーザージャーニー単位）を選ぶ。過去実績を見て現実的な値から始め、定期的に見直す。100%は目指さない |
| 良いアラートとは？ | 原因ではなく症状（ユーザー影響）で鳴らす。すべてのアラートは対応が必要なものだけ。SLOのバーンレートアラート（短期・長期の多窓）が有効 |
| ポストモーテムで大事なことは？ | ブレームレス（個人を責めない）。タイムライン・影響・根本原因・再発防止策を書き、アクションアイテムを追跡する |
| トイルとは？どう減らす？ | 手作業・繰り返し・自動化可能・価値を生まない運用作業。計測して可視化し、自動化で削減。作業時間の50%以下に抑えるのがGoogleの目安 |
| オブザーバビリティとモニタリングの違いは？ | モニタリングは既知の問題を検知する。オブザーバビリティは未知の問題を外部出力から調べられる性質。メトリクス・ログ・トレースの3本柱 |
2.16追加で聞かれやすい質問
★★★ 必須| 質問 | 回答の要点 |
|---|---|
| MTTR を短くするには？ | 検知を早める（症状ベースのアラート）、手順書（Runbook）、ロールバックの自動化、権限の事前整備 |
| アラート疲れをどう解消する？ | 過去のアラートを棚卸しし、対応不要なものは削除か通知先を変える。症状ベースに寄せる |
| SREとDevOpsの違いは？ | DevOps は文化・考え方、SRE はそれを実装する具体的な方法（「SRE implements DevOps」） |
| SREチームの立ち上げで何をする？ | 重要サービスのSLO設定、監視とオンコールの整備、トイルの可視化、開発チームとの合意 |
| カオスエンジニアリングとは？ | 意図的に障害を起こして弱点を見つける。本番前の環境から小さく始め、影響範囲を制御する |
この章のまとめ
🖨 まとめシート（印刷・PDF）- SLI・SLO・SLAの違いと、可用性ごとの許容停止時間を数字で言える
- エラーバジェットはリリース速度と信頼性を両立させる合意の道具
- インシデントは原因究明より緩和が先。ポストモーテムは人を責めない
- オブザーバビリティ（メトリクス・ログ・トレース）：システムの外に出てくる情報から、中で何が起きているかを後から調べられる性質。メトリクス・ログ・トレースの3つを組み合わせる。
- ログの保持：ログは「すぐ検索する期間」と「長く保管する期間」を分け、法令・契約で決まる下限と、コスト・個人情報で決まる上限の間で期間を決める。
この章のクイズ
面接ではこう聞かれる
まず答えを見ずに声に出して答え、そのあと開いて比べる。
Q1SLI・SLO・SLAの違いを説明してください。
模範回答
SLIは実測値で、たとえば「成功したリクエストの割合」です。SLOはSLIの社内目標で、「30日間で99.9%」のように決めます。SLAは顧客との契約で、下回ると返金などのペナルティがあります。SLOはSLAより厳しく置き、契約違反の前に気づいて手を打てるようにします。
深掘りされたら
- SLOの値はどうやって決めますか？
- SLIにレイテンシを使うなら、平均とパーセンタイルのどちらですか？
見られているポイント3つの関係と、なぜSLOをSLAより内側に置くのか
Q2エラーバジェットとは何で、どう運用しますか？
模範回答
100%からSLOを引いた「失敗してよい量」です。99.9%なら月約43分の停止に相当します。予算が残っていればリリース速度を上げ、減ってきたら信頼性の改善を優先する、というルールを開発チームと事前に合意しておきます。これにより「速く出したい開発」と「止めたくない運用」の対立を数字で解消できます。
深掘りされたら
- 予算を使い切ったのに開発がリリースしたいと言ったら？
- バーンレートアラートとは何ですか？
見られているポイント技術ではなく合意形成の道具として説明できるか
Q3良いアラートの条件は何ですか？
模範回答
ユーザーへの影響（症状）で鳴ること、鳴ったら必ず人が対応すべきものであること、対応手順がわかることの3つです。CPU使用率のような原因側の指標はダッシュボードで見て、通知はSLOのバーンレートのような症状側に寄せます。対応不要なアラートは定期的に棚卸しして消します。
深掘りされたら
- アラート疲れが起きているチームに入ったら最初に何をしますか？
見られているポイント症状ベースとノイズ削減の考え方
Q4大きな障害が起きたとき、最初の15分で何をしますか？
模範回答
まず影響範囲と緊急度を確認してインシデントを宣言し、指揮役・調査役・連絡役を分けます。次に直前の変更を確認し、関係があればロールバックなどで影響を止めることを最優先にします。原因究明はその後です。並行して社内外へ定期的に状況を共有し、時刻と判断を記録しておきます。
深掘りされたら
- ロールバックできない変更だったら？
- 指揮役が自分で手を動かしてはいけないのはなぜ？
見られているポイント復旧優先と役割分担
Q5ブレームレスなポストモーテムとは何ですか？
模範回答
個人を責めず、ミスを許した仕組みを原因として扱う振り返りです。責められる文化では事実が隠れ、同じ障害が繰り返されます。タイムライン、影響、根本原因、うまくいったこと、改善点を書き、担当者と期限つきのアクションを追跡するところまでをセットにします。
深掘りされたら
- アクションアイテムが放置されがちな場合はどうしますか？
見られているポイント文化と仕組みの両面
Q6トイルとは何ですか？どう減らしましたか？
模範回答
手作業で繰り返し発生し、自動化でき、長期的な価値を生まない運用作業です。まず作業時間を記録して量を見える化し、頻度と時間が大きいものから自動化します。削減前後の時間を比べて効果を示すと説得力が出ます。
深掘りされたら
- 自動化に時間をかけるべきでない作業はありますか？
見られているポイント計測から始めているか
Q7オブザーバビリティを高めるために、何から始めますか？
模範回答
まず重要なユーザー操作ごとにSLIを決め、エラー率とレイテンシのメトリクスを取ってSLOのアラートを作ります。次にOpenTelemetryで主要サービスにトレースを入れ、trace IDをログにも出してつなげます。ログはJSONで構造化し、サービス名やリクエストIDを入れます。そのうえで、ラベルのカーディナリティやログの保持期間を決めてコストを管理します。
深掘りされたら
- サンプリングはどう決めますか？
見られているポイント優先順位とコスト意識
Q8ログの保持期間はどう決めていますか？
模範回答
ログの種類ごとに決めています。下限は法令、業界の基準、顧客との契約、社内規程で決まり、上限はコストと個人情報を必要以上に持たないことで決まります。直近はCloudWatch Logsなどで検索でき、それ以降はS3に移してAthenaで検索し、長期の監査ログはGlacierで安く保管します。監査ログは別アカウントに集めてObject Lockで改ざんを防ぎます。CloudWatch Logsは既定で無期限なので、保持期間の設定漏れを定期的に確認しています。
深掘りされたら
- 長期保管したログを実際に調べた経験はありますか？
見られているポイント根拠・階層・改ざん防止