SRE入門：信頼性工学の基礎
ビジネスに効くSRE：信頼性は“投資配分”の問題
信頼性は上げ続ければ良いものではなく、コストと価値の釣り合いで決めるべき指標です。SREは「どの程度の不具合を許容し、どの速度で変更を届けるか」を定量で合意し、運用し、学習を回す実践です。SLA（対外契約）、SLO（内的目標値）、SLI（観測指標）を分け、意思決定の単位を“数字”に揃えます。たとえば月間の可用性を99.9%にすると、許される停止は約43分です。このエラーバジェットが意思決定の通貨になります。新機能を早く出すのか、安定化を優先するのか——曖昧な議論をやめ、消費スピード（バーンレート）で会話できます。
ダウンタイムの損失を見積もるのも有効です。1分の停止が50万円の機会損失なら、MTTR短縮や自動化の投資枠はすぐに正当化できます。SREは現場の運用（監視、アラート、オンコール）とプロダクトの開発（変更管理、リリース戦略）を一本化する“経営と現場の翻訳レイヤー”として機能します。
まず決めるのはSLOとエラーバジェット（手順つき）
1. ユーザ行動からSLIを切り出す
テクニカルな内部状態ではなく、ユーザ体験を代表する指標に寄せます。典型はゴールデンシグナルです。
- レイテンシ：API p95応答時間（例：検索API p95 < 400ms）
- エラー率：5xx/全リクエスト（例：5分移動平均で < 1%）
- トラフィック：1分あたりのリクエスト数
- 飽和度：キュー長やCPU/メモリ利用率（原因調査用）
さらに「購入フロー完了率」「動画再生成功率」など、コア体験のSLIを1〜3個定義します。監視はエッジ（ユーザに近い）での黒箱計測と、アプリ内部の白箱計測を組み合わせます。
2. SLOとバジェットを数字にする
期間を月/四半期で決め、可用性SLOを設定します。月間43,200分に対し、
- 99.9%なら許容停止は約43分
- 99.5%なら約216分（3.6時間）
これがエラーバジェットです。バーンレートでの運用例：
- 2時間窓で14.4倍以上の消費、かつ6時間窓で6倍以上ならページング
- バジェットを50%以上消費でデプロイ速度を落とす（カナリア必須）
- 100%消費で新機能は凍結、信頼性改善に集中
SLOは“守れるほどに厳しく、意思決定に効くほどに野心的”が現実解です。まず4週間のベースラインを測り、達成余地が±1%以内に収まる水準から始めます。
3. 改善の順序を決める
違反の上位原因をパレートで特定し、MTTR短縮（自動復旧/ランブック整備）→MTBF延伸（ボトルネック解消）→変更リスク低減（段階的リリース）の順で打ちます。先にDBシャーディングに走るのではなく、まずキャッシュやキューのタイムアウト調整と“失敗の速さ”を詰めるのが定石です。
監視・アラート設計は“症状起点”で鳴らす
観測性の配置
メトリクス（時系列）、ログ（詳細）、トレース（呼び出し鎖）を分離し、役割を明確にします。SLIはメトリクスとして集約し、主要ディメンション（リージョン、テナント、重要API）で切れるようにします。外形監視（多リージョンの黒箱）で「ユーザ影響」を、内側の白箱で「原因」を探る二層構造がノイズを抑えます。
アラートの作り方（現場の実用値）
- ページングは症状に限定：ユーザ影響を示すSLI違反や高バーンレート
- 原因系（CPU高騰、GC頻発）はチケット化やダッシュボードで可視化
- 閾値はp95/移動平均でブレを吸収、連続N回で発火
- デプロイ時は抑制ウィンドウを自動適用、夜間は要約通知に集約
ランブックは「想定原因→確認手順→切り戻し条件→責任範囲」を1ページで。テンプレの下書きはChatGPTやClaudeで要点を整形し、運用チームで実地検証すると初速が上がります。障害の時系列要約はGeminiでログから抽出すると当番交代が滑らかです。軽量な自動復旧スクリプト（ヘルスチェック失敗でPod再作成、キュー詰まりでコンシューマを一時増やす等）はCopilotを使うとレビュー前の叩き台が早く作れます。
事例：中堅ECのSRE立ち上げ
セール時に検索APIがタイムアウトし、チャットと電話がパンク。目標は99.99%で、実態は99.6%前後。CPU高騰やディスク警告で常時鳴るノイズに埋もれ、夜間ページが多発。失敗は「高すぎる目標」「症状ではなく原因にアラート」「変更を止めすぎ」の三点でした。
改善はユーザ行動から再設計。SLIを「検索API p95 < 450ms」「カート追加成功率 ≥ 99.5%（5分窓）」に揃え、月次SLOを99.5%に設定。エラーバジェット216分のうち50%消費で変更速度を半減、100%で凍結というポリシーを合意。外形監視を多リージョンに拡張し、SLIメトリクスをダッシュボード中心に再構成。バーンレート（2時間14.4x、6時間6x）をページ条件に採用。オンコールは週交代2名体制、ランブックを標準化（ChatGPTでテンプレ下書き、現場で補正）。Geminiでアクセスログから「特定のプロモコード時だけカートAPIの再試行が増加」というパターンを抽出し、カナリアで修正を段階配信。軽微な詰まりはCopilotで作った自動復旧スクリプトで解消。
結果として、セール月のSLO違反は6→1回、MTTRは90→22分、夜間ページは60%減、デプロイ頻度は週2→毎日へ。学びは「現実的なSLOが改善速度を生み、症状起点の監視が意思決定を簡潔にする」でした。ポストモーテムは非難しない文化で定着し、再発防止が資産化しました。
監視・アラート・オンコール・ランブック・事後分析という流れが整うと、SREの基礎は事業運営の速度そのものになります。とりわけサーバ監視運用事業では、24/365の観測とアラート設計、エスカレーション、改善サイクルのファシリテーションが中核です。SLOとエラーバジェットを“共通言語”に据えることで、運用現場と開発、そしてビジネスを同じ地図の上で前に進められます。
