SLAレポート作成事例
信頼されるSLAを作るためのKPI設計とデータ源
サーバ監視の現場でSLAレポートは「運用品質の合意書」です。先にKPIとデータ源を固定すると、集計や議論のコストが激減します。基本のKPIは、可用性（Availability）、MTTR、重大度別インシデント件数、検知遅延、一次対応完了率の5つ。可用性はSLAの看板指標なので、分母・分子の定義を最初に決めます。月次SLOが99.9%なら、30日月のエラーバジェットは43分12秒です。これを消費したら新機能リリースを抑制する、といった運用ルールに直結させます。
データ源は3系統に分けて棚卸しします。（1）監視アラート（メトリクス/ヘルスチェック/合成監視）（2）インシデント管理（発生・回復・暫定/恒久対応の時刻と責務）（3）ユーザー影響（HTTP成功率、該当テナント数、地域カバレッジ）。特に後者が弱いと「落ちていたが誰も気づかなかった」問題が起きます。収集する最低限のカラムを固定しましょう。
- incident_id, service_name, severity, start_at, end_at, timezone
- user_impact_rate（影響ユーザー割合0〜1）, region, tenant
- is_planned（計画停止フラグ）, cause_category（NW/アプリ/DB）
- detect_at（監視検知）, acknowledge_at, workaround_at, resolve_at
分析メモの作成やサマリー文面は人手だけでなく、ChatGPTやClaudeを下書き用に活用すると早いです。数値はBIやCSVから参照し、文章だけ生成する方針にして幻覚を防ぎます。ログの傾向把握や類型化にはGeminiがアイデア出しに向き、ExcelやPower BIの検算はCopilotで関数候補をもらうと工数が削減できます。
可用性の算出で揉めないための定義と算式
障害ウィンドウの定義
算式はシンプルでも、定義が曖昧だと毎月“揉めます”。可用性は「1 − 影響時間の合計 / 対象期間の総時間」で計算します。影響時間は「ユーザー影響開始から回復まで」の連続時間をベースに、部分劣化は重み付けします。
影響時間分 = 継続時間分 × user_impact_rate（0〜1）。例えば決済の成功率が80%まで下がった30分は、影響時間を24分と記録します。複数のアラートが同時多発しても、インシデント単位に正規化して重複を潰すのがコツです（同一サービス・同一原因・重なり時間は和集合で1件）。タイムゾーンはUTC固定、丸めは5分単位、1分未満の断続は3回以上/15分で1イベントに畳み込むなど、機械的ルールをレポート先頭に明記すると解釈のズレを防げます。
計画停止と例外
計画停止は「72時間前告知・夜間帯・回避策あり」を満たす場合のみ除外。緊急パッチは除外しません。マルチリージョン構成では、影響地域のトラフィック比率でuser_impact_rateを自動付与します。B2Bマルチテナントは「該当テナント数/全契約テナント数」で重み付けするのが現場で現実的です。重要なのは、例外適用時に理由をチケットIDと共に残すこと。翌月以降の再現性が担保されます。
レポートの型と自動化：週次30分で締める
集計の手を動かす時間を減らし、原因と改善に時間を使うための最短ルーチンです。
- データ抽出：監視・インシデント・アクセスログから前週分をSQLで抽出。生データは変更不可のフォルダに保存。
- 正規化：アラートをインシデントにグルーピング（service_name＋cause_category＋時間重なり）。重複を和集合で統合。
- 可用性計算：ユーザー影響を重み付けし、SLO対比とエラーバジェット消費率を算出。99.9%の月で残り10分を切ったら「リリース凍結候補」に自動フラグ。
- 可視化：週次トレンド、重大度別件数、エラーバジェット消費チャート、検知〜回復のタイムライン。
- 解説ドラフト：ChatGPT/Claude/Geminiに「表の数値はそのまま引用」「推測禁止」と明記して要約文を作成。人がファクトチェック。
- 検算：CopilotによりExcelのピボット・関数の誤りを自動チェック。差分はマクロで赤入れ。
- 掲載順：Executive Summary→SLO達成/未達→主要インシデント3件の根因・再発防止→次週のリスクとアクション。
自動化の肝は、集計ロジックのバージョン管理と、例外ルールの台帳化です。ルール変更日はレポートに明記し、前年同月比の比較は「旧ロジック換算値」も併記すると経営判断に耐えます。
身近な企業活用例：中堅ECの失敗と改善
月次SLAが98.5%と報告され、広告停止の検討まで進みました。内訳を追うと、（1）計画メンテをダウンタイムに算入（2）重複アラートの二重計上（3）地域限定障害を全体影響として計上、の三重苦。実際の顧客影響はそこまで大きくありませんでした。
改善では、インシデント正規化と重み付け定義を刷新。「可用性 = 1 − Σ(継続時間×影響率)/総時間」を明文化し、計画停止の除外条件も固定。監視とインシデントのグルーピングは機械的ルールに寄せ、可用性の丸めを5分単位に統一しました。サマリー文はChatGPTで下書きし、Geminiでログのピーク時間帯を類型化、非技術メンバー向けの説明文はClaudeで平易に整え、Excel検算はCopilotで関数エラーを洗い出し。結果、翌月からSLAは99.96%（SLO 99.95%達成）と正確に可視化でき、報告作業は月6時間から45分へ短縮。エラーバジェット消費が月中で60%に達した週は、計画外の大規模UI変更を翌月に延期し、翌月の重大障害は30%減りました。失敗は「定義と重複処理の弱さ」に起因しており、レポートの型が整うと運用判断が一段引き締まる好例です。
SLAレポートは数字の羅列ではなく、「どれだけ安全に届けられたか」を合意形成するための装置です。定義を先に固め、重み付けと例外を台帳化し、自動化で人の注意を“原因と改善”に集中させる。この積み重ねが、サーバ監視運用事業における信頼と継続改善の土台になります。
