SLA順守を正確に追跡するウェブアプリの作り方

SLA準拠と作るものの定義

SLA準拠とは、サービスレベルアグリーメント（SLA）—プロバイダと顧客間の契約—に書かれた計測可能な約束を満たすことを意味します。あなたのアプリの仕事は、証拠とともに単純な問いに答えることです：この顧客について、この期間に私たちは約束を守ったか？

次の3つの関連用語を分けて考えると便利です：

• SLI（Service Level Indicator）: 生の計測値（例：「成功チェックの割合」「初回応答時間」「サービス復旧時間」）
• SLO（Service Level Objective）: SLIに対する内部目標（多くはSLAより厳しい）。例：「99.95%の稼働目標」
• SLA: 外部に合意したコミットメントで、クレジットや罰則に結びつくことが多い。例：「月間99.9%の稼働」

よく使うSLAメトリクス

多くのSLAトラッキングウェブアプリは、小さなセットのメトリクスから始めます：

• 稼働率 / 可用性: 報告期間中サービスが「稼働」していた割合
• 応答時間（サポート）: 顧客チケット作成から最初の有人応答までの時間
• 解決時間: インシデント/チケット作成からクローズまたは復旧までの時間
• 稼働時間ウィンドウ: 「営業時間のみカウント」「予定メンテナンスを除外」「顧客のタイムゾーンで08:00–18:00のみ測定」などのルール

誰がこのアプリを使うか、なぜ使うか

同じ“真実”を異なる形で見たいユーザーがいます：

• Ops/SRE: 違反を早期検出しインシデントタイムラインを検証する
• サポート: 顧客ごとの応答・解決コミットメントを追う
• マネージャ: トレンドやリスク、チームが目標を一貫して満たしているかを確認する
• 顧客: 何が起きたかを示す透明なレポート（場合によってはステータスページ）を確認する

作るもの（と作らないもの）

このプロダクトは追跡、証明、報告が目的です：信号を収集し、合意されたルールを適用し、監査向けの結果を生成します。性能を保証するものではなく、正確で一貫性があり後で説明できる形で測定することが目的です。

要件：メトリクス、ルール、そして誰が何を必要とするか

テーブル設計やコードを書く前に、「準拠」があなたのビジネスで何を意味するかを痛いほど明確にしてください。多くのSLAトラッキングの問題は技術的ではなく、要件の問題です。

インプットを集める（記憶に頼らない）

信頼できる情報源を集めます：

• 顧客契約とMSA（添付資料やチケット付帯条項を含む）
• サービスタイア（例：Basic vs Premium）と顧客の割り当て
• 顧客（またはサービス）ごとの営業時間とタイムゾーン
• 除外と特別ルール：予定メンテナンス、不可抗力、顧客起因の遅延、サードパーティ依存、猶予期間

これらを明示的なルールとして書き出してください。ルールが明確に述べられないなら、信頼して計算できません。

何を追跡すべきか決める

SLA数値に影響する現実世界の「もの」を列挙します：

• インシデント/障害（開始、終了、重大度、影響サービス）
• リクエスト/チケット（作成、初回応答、解決、顧客待ち）
• メンテナンス（予定 vs 緊急；可用性へカウントするか）
• 部分的な障害（性能低下）と、それをカウントするかどうか

また誰が何を必要とするかも特定します：サポートはリアルタイムの違反リスクを、マネージャは週次の集計を、顧客はステータスページ向けの単純なサマリを求めることが多いです。

最初のリリースでは1〜3のメトリクスを選ぶ

スコープを小さく保ちます。システムがエンドツーエンドで動くことを示す最小セットを選んでください。例：

• サービスごとの月間可用性 %
• 営業時間内のインシデント初回応答時間
• 重大度1インシデントの解決までの時間

要件チェックリストと成功基準

後でテストできる1ページのチェックリストを作成します：

• 明確なメトリクス定義（開始/終了タイムスタンプ、タイムゾーン、丸め）
• 包含/除外ルール（メンテナンス、顧客待ち）
• ティアごとの目標閾値（例：99.9%、応答1時間）
• 出力要件（顧客レポート、内部ダッシュボード、エクスポート）

成功のイメージはこうです：2人が同じサンプル月を手動で計算し、あなたのアプリが完全に一致すること。

SLA、サービス、インシデント、イベントのデータモデル

正しいSLAトラッカーは、数値が何故そうなっているか説明できるデータモデルから始まります。月間可用性を正確なイベントとルールに紐づけられないなら、顧客との紛争や内部の不確実性と戦うことになります。

コアエンティティ（退屈で明示的に保つ）

最低限モデル化するもの：

• Customer（テナント/アカウント）: サービス、カレンダー、連絡先、レポート設定を所有
• Service: 計測対象（API、Webアプリ、リージョン固有コンポーネント）、親子関係でロールアップ可
• Plan: 商用ラッパー（例：「Gold」）、デフォルトのSLAポリシーセットに紐づけ
• SLA policy: 測定ルール（稼働目標、応答時間目標、計測ウィンドウ、除外項目）
• Incident: タイトル、重大度、タイムラインなどの人間向けグループ
• Event: 計算を駆動する不変の事実（状態変化、監視シグナル、承認）

有用な関係は：customer → service → SLA policy（plan経由も可）。IncidentやEventはserviceとcustomerを参照します。

時間ベース追跡の最小スキーマ

時間のバグはSLA計算を誤らせる最大原因です。次を保存してください：

• occurred_at を UTC（タイムゾーン意味付き）で保存
• received_at（システムがイベントを見た時刻）
• source（監視名、統合、手動）
• external_id（再試行をデデュープするため）
• payload（将来のデバッグ用に生JSON）

また表示と営業時間ロジックのために customer.timezone（IANA形式、例：America/New_York）を保存しますが、イベント時間を書き換えないでください。

営業時間と休日

応答時間SLAが営業時間外で停止するなら、カレンダーを明示的にモデル化します：

• working_hours を顧客（または地域/サービス）ごとに（日付毎の開始/終了）
• holiday_calendar を地域または顧客に紐づけ、日付範囲とラベルを持たせる

ルールをデータ駆動にして、オプスが祝日をデプロイなしで更新できるようにします。

監査性：生イベント vs 計算結果

生イベントは追加専用のテーブルに保存し、計算結果は別に保存（例：sla_period_result）します。各結果行には期間境界、入力バージョン（ポリシー版 + エンジン版）、使用したイベントIDの参照を含めるべきです。これにより再計算が安全になり、顧客から「どの障害分がカウントされたのか？」と聞かれても説明できます。

イベント取り込み：データがアプリに入る方法

SLA数値は取り込んだイベントの信頼性次第です。目標は単純：カウントに関係するすべての変更（障害開始、インシデント承認、サービス復旧）を一貫したタイムスタンプと十分なコンテキストでキャプチャすることです。

よくあるイベントソース

多くのチームは複数のシステムから引っ張ってきます：

• チケッティング/インシデントツール（Jira Service Management、ServiceNow、Zendesk）：作成/承認/解決タイムスタンプ、優先度変更、担当者変更
• 監視ツール（Pingdom、Datadog、CloudWatch、Prometheus Alertmanager）：up/downシグナル、アラート発火/クリア、シンセティックチェック結果
• インフラ/アプリケーションログ: デプロイイベント、エラースパイク、ヘルスチェック失敗（監視がノイズや欠落しているときに有用）
• 手動入力: 自動化で真実が分からない場合の「ビジネス承認による障害開始/終了」「メンテナンス開始」用の小さなUI

取り込みオプション（使い分け）

Webhookはリアルタイム精度と低負荷のため通常最適です：ソースがあなたのエンドポイントにイベントをプッシュします。

ポーリングはWebhookが使えない場合のフォールバック：アプリが定期的に前回以降の変更を取得します。レート制限と「since」ロジックに注意が必要です。

CSVインポートはバックフィルやマイグレーションに便利です。履歴の再処理が容易になるようにファーストクラスの取り込み経路として扱ってください。

冪等性を考えた推奨イベントフォーマット

上流のペイロードが違っても、内部では単一のイベント形に正規化します：

• event_id（必須）：再試行で安定する一意ID。ソースのGUIDを優先、なければ決定的ハッシュ生成
• source（必須）：例 datadog, servicenow, manual
• event_type（必須）：例 incident_opened, incident_acknowledged, service_down, service_up
• occurred_at（必須）：発生時刻（発生時刻であり受信時刻ではない）、タイムゾーン付き
• received_at（システム）：取り込んだ時刻
• service_id（必須）：影響するSLA関連サービス
• incident_id（任意推奨）：複数イベントを一つのインシデントにリンク
• attributes（任意）：優先度、リージョン、顧客セグメントなど

event_id にユニーク制約を設け、取り込みを冪等にします：再試行しても重複が作られません。

不正データを防ぐバリデーションルール

以下のイベントは拒否または隔離してください：

• タイムスタンプが欠落/無効、occurred_at が将来過ぎる
• 既知の service_id にマッピングできない（または明示的な“unmapped”ワークフローを要求）
• 既存の event_id と重複する
• ルールを壊すほど順序が狂って届く（上書きせずに「要レビュー」とマーク）

こうした初期の規律があれば、後でSLAレポートを巡る議論を避けられます—いつでもクリーンでトレース可能な入力を示せるからです。

SLA計算エンジン：イベントを準拠結果に変える

生イベントがSLA結果になり得るのは計算エンジン次第です。鍵は会計的に扱うこと：決定論的ルール、明確な入力、リプレイ可能なトレイルです。

正規化されたタイムラインから始める

すべてをインシデント（またはサービス影響）ごとの単一の順序付きストリームに変換します：

• タイムスタンプ（UTC）: インシデント開始、承認/初回応答、緩和、解決、再オープン
• 状態変化: 一時停止/再開、顧客待ち、メンテナンスアクティブ
• 範囲: どのサービス/顧客が何の重大度で影響を受けるか

このタイムラインから区間を合算して期間を算出します。単純に2つのタイムスタンプを引くのは避けてください。

TTFR（初回応答時間）とTTR（解決時間）

TTFRは incident_start と first_agent_response（または acknowledged）の間の“課金対象時間”として定義します。TTRは incident_start と resolved の間の“課金対象時間”です。

“課金対象”とは、次のような除外区間を取り除いたものを指します：

• 営業時間外（営業時間SLAの場合）
• 明示的な一時停止（例：「顧客待ち」）
• 予定メンテナンスや顧客起因の遅延などポリシーで除外されるもの

実装の詳細：カレンダ関数（営業時間、祝日）と、タイムラインを受け取って課金区間を返すルール関数を保存してください。

部分障害とマルチサービスインシデント

事前に次を決めておきます：

• サービス別SLA（推奨）：1つのインシデントは複数のサービス影響レコードを生み、各々にTTFR/TTRがある
• 顧客別SLA：同じ障害が全テナントに影響しない可能性がある

部分的な障害は、契約が影響度で加重することを要求する場合のみ加重し、そうでなければ“劣化”を別カテゴリの違反として扱ってください。

トレーサビリティ：入力、出力、リプレイを保存

すべての計算は再現可能であるべきです。次を永続化してください：

• 使用した正確なイベント（ID、タイムスタンプ、ソース）
• 導出された区間（何が除外され理由は何か）
• 最終結果（TTFR、TTR、違反フラグ、ルールバージョン）

ルール変更時に履歴を書き換えずにバージョンで再計算できることは、監査や顧客紛争で重要です。

レポーティングロジック：期間、可用性、エッジケース

レポーティングはSLAトラッキングが信頼を得るか疑念を招くかの分かれ目になります。アプリは何を測っているかの時間範囲、どの分がカウントされるか、最終数値がどう導出されたかを明確に示すべきです。

期間：カレンダー、請求、ローリングウィンドウ

顧客が実際に使う一般的な報告期間をサポートします：

• カレンダー（月次/四半期）（例：3月1日–31日）
• 請求サイクル（例：15日–翌月14日、請求に合わせた期間）
• ローリングウィンドウ（例：「過去30日」）

期間は明示的な start/end タイムスタンプとして保存し、後で計算を再生して説明できるようにしてください。

可用性：総分と対象分

議論の元になりやすいのは分母を「期間全体」か「対象時間」かで扱うかです。

各期間に対して2つの値を定義します：

• Eligible minutes：SLAにカウントされる分（予定メンテや顧客起因の障害、サポート時間外を除外することが多い）
• Downtime minutes：サービスがダウンと見なされた eligible 分

そして計算します：

availability_percent = 100 * (eligible_minutes - downtime_minutes) / eligible_minutes

eligible がゼロになる可能性がある場合（例えば、期間に監視対象の営業時間がまったく含まれないサービス）、事前にルールを決めてください：「N/A」か「100%」扱いにするなど。一貫して文書化してください。

数字を明確な合格/不合格にする

多くのSLAは割合と二値の結果の両方を必要とします。

• 割合：例 99.95%（期間）
• 合格/不合格：SLA目標（例：≥99.9% で合格）と比較

また「違反までの残り余地（残りのダウンタイム予算）」を保持すると、閾値を超える前にダッシュボードで警告できます。

意図的に扱うべきエッジケース

• タイムゾーン：顧客/契約ごとの報告タイムゾーンを選び（多くは顧客のタイムゾーン）、イベント変換は一貫して行う
• 夏時間（DST）：1日が常に1440分あると仮定しない。タイムゾーン対応のタイムスタンプを使い、期間長がDSTで正しくなるようにする
• 終了時刻の欠落：インシデントが resolved タイムスタンプを欠くことがある。これを「オープン」と扱い、レポート終了時刻で打ち切る一方でクリーンアップのフラグを立てる

最後に、原始入力（含めた/除外したイベントや調整）を保持して、各レポートが「なぜその数になったか」を手でごまかさず説明できるようにします。

UIとダッシュボード：SLA状況を一目で分かるようにする

計算エンジンが完璧でも、UIが基本的な問い「今すぐSLAを満たしているか、なぜ？」に答えられなければユーザーは失望します。各画面はまず明確なステータスを示し、そこから数値とそれを生んだ生イベントへドリルダウンできるように設計してください。

作るべき主要ビュー

概要ダッシュボード（オペレーションとマネージャ向け）。 小さなタイルで現在の期間のコンプライアンス、可用性、応答時間コンプライアンス、「違反までの残り時間」を先頭に表示します。ラベルは明示的に（例：「Availability (this month)」ではなく「今月の可用性」）複数SLAをサポートする場合は最悪のステータスを先に表示し展開させると良いです。

顧客詳細（アカウントチームと顧客向け報告）。 顧客ページはその顧客のすべてのサービスとSLAティアを要約し、合格/警告/不合格のシンプルな状態と短い説明（例：「2件のインシデントがカウントされ、18分のダウンタイムが計上」）を表示します。/status（顧客向けステータスページ）へのリンクやレポートエクスポートへのリンクを追加します。

サービス詳細（深掘り調査用）。 ここでは適用されたSLAルール、計算ウィンドウ、コンプライアンス数がどのように形成されたかの内訳を表示します。可用性の時系列チャートとカウントされたインシデント一覧を含めます。

インシデントタイムライン（監査用）。 単一インシデントビューはイベントのタイムライン（検知、承認、緩和、解決）と、どのタイムスタンプが応答・解決メトリクスに使われたかを示します。

実際の問いに合うフィルタ

すべての画面でフィルタを一貫させます：日付範囲、顧客、サービス、ティア、重大度。単位も統一（分 vs 秒、同じ小数桁の割合）し、日付範囲を変えるとページ内の全メトリクスを更新して不整合を防ぎます。

信頼を損なわないドリルダウン

要約メトリクスはすべて「なぜ？」パスを持たせます：

• コンプライアンス割合 → その期間にカウントされたインシデント一覧
• インシデント → 計算に使われた生イベントと導出タイムスタンプ
• 可用性 → ソース（監視イベント vs 手動調整）付きのダウンタイム区間

ツールチップは用語定義（「除外ダウンタイム」や「営業時間」など）に節度を持って使い、サービスページに適用ルールの正確な文言を表示してユーザーの推測を減らしてください。

単純だが明確に

略語より平易な表現を優先します（「Response time」ではなく「応答時間」）。ステータス表示では色とテキストラベルを組み合わせ（例：「危険：エラーバジェットの92%を消費」）て曖昧さを排除します。SLAルールや除外の変更履歴が見られる /audit への小さな「最終変更」ボックスを置くと監査性が高まります。

違反のアラートと通知

アラートはSLAトラッキングを受動的なレポートから、チームが罰則を回避するために動けるツールに変えます。最良のアラートはタイムリーで具体的、かつ実行可能です—単に「悪い」と伝えるのではなく「次に何をすべきか」を示します。

現実的な意思決定に合うトリガーを定義する

まず次の3種類のトリガーから始めます：

• 差し迫った違反（Approaching breach）：例「応答時間SLAまで残り30分」「今月の可用性が99.92%でSLAは99.9%」—回復の余地があるため最も価値あり
• 違反発生（Breach occurred）：計算エンジンが該当ウィンドウでSLA違反を確定したときに発火
• 繰り返し違反（Repeated violations）：例「30日で3回違反」「同サービスが今週2回違反」—根本原因の兆候

トリガーは顧客/サービス/各SLAごとに設定可能にして、契約ごとの許容度差に対応してください。

チャネルを選び、メッセージを実行可能にする

実際に対応する場所へアラートを送ります：

• Email：監査向け通知や外部ステークホルダ向け
• Slack：迅速な内部調整用
• SMS（任意）：高重大度のエスカレーション用

各アラートに /alerts, /customers/{id}, /services/{id}、インシデントやイベント詳細へのディープリンクを含め、対応者が迅速に数値を検証できるようにします。

ノイズ低減：重複抑止、静穏時間、エスカレーション

重複抑止を実装して、同じキー（customer + service + SLA + period）のアラートをグルーピングし、クールダウン中は繰り返しを抑えます。

静穏時間（チームのタイムゾーンごと）を設定して、重要度が低い差し迫った違反アラートは営業時間まで遅らせ、重大度が高ければ静穏時間をオーバーライドするようにします。

最後にエスカレーションルール（例：10分でオンコールに通知、30分でマネージャへエスカレーション）をサポートして、アラートが一つの受信箱で滞留しないようにします。

アクセス制御、認証、監査ログ

SLAデータは内部のパフォーマンスや顧客固有の権利を露呈するため機微です。アクセス制御はSLAの「算出」に直結します：同じインシデントでも適用するSLA次第で結果が変わり得ます。

最初からサポートすべきロール

まずはロールを単純にして、徐々に粒度を細かくします。

• Admin: グローバル設定、サービス、SLA、ユーザー、統合、請求関連の管理
• Agent: インシデントとメンテナンスウィンドウの作成/更新、イベント添付、ポストモーテム追記
• Manager: 所属範囲の閲覧、SLA定義の承認、レポートエクスポート
• Customer viewer: 自社のサービス、SLA目標、インシデント履歴、顧客向けレポートのみ閲覧

実務的なデフォルトは RBAC + テナントスコーピング です：

• 各レコード（service, SLA policy, report）には オーナーテナント/顧客 がある
• 内部ユーザーは複数テナントにスコープでき、顧客ビューアは1つに限定
• 編集権限は閲覧より狭く（例：エージェントはインシデントは編集できてもSLAルールは変更不可）

各ロールの閲覧/編集範囲

顧客固有データについて明確にします：

• 顧客ビューアは内部専用フィールド（根本原因仮説、内部的な重大度、オンコールノート、非公開タグ）を決して見られないようにする
• SLAポリシーはバージョン管理して、顧客が「そのインシデント時に適用されたSLA条件」を確認できるようにする

認証オプション（後で行き詰まらないために）

まずは メール/パスワード を開始し、内部ロールにはMFAを必須にします。後で SSO（SAML/OIDC） を導入するために、アイデンティティ（誰か）と認可（何にアクセスできるか）を分離して設計してください。統合用にはスコープの狭いサービスアカウントAPIキーを発行し、ローテーションをサポートします。

ありがたい監査ログ

次の変更について不変の監査エントリを追加します：

• SLAルールの変更（閾値、カレンダー、除外、サービス/顧客へのマッピング）
• インシデント編集（タイムスタンプ、ステータストランジション、手動のダウンタイム上書き）
• 権限やAPIキーの変更

保存する情報は「誰が」「何を変えたか（前/後）」「いつ」「どこで（IP/ユーザーエージェント）」「相関ID」です。監査ログは検索可能かつエクスポート可能にしておく（例：/settings/audit-log）。

統合と自動化のためのAPI設計

SLAトラッキングアプリは孤立して動くことは稀です。監視ツール、チケッティングシステム、内部ワークフローがインシデントを作成し、イベントをプッシュし、レポートを取得できるAPIが必要です。

小さく予測可能なAPI表面から始める

バージョン付きベースパス（例：/api/v1/...）を使い、ペイロードを進化させても既存統合を壊さないようにします。

主要なエンドポイント：

• Events: POST /api/v1/events（状態変化取り込み）、GET /api/v1/events（監査・デバッグ）
• Incidents: POST /api/v1/incidents, PATCH /api/v1/incidents/{id}（承認、解決、割当て）, GET /api/v1/incidents
• SLAs: GET /api/v1/slas, POST /api/v1/slas, PUT /api/v1/slas/{id}（契約と閾値管理）
• Reports: GET /api/v1/reports/sla?service_id=...&from=...&to=...（コンプライアンスサマリ）
• Alerts: POST /api/v1/alerts/subscriptions（Webhook/Emailターゲット管理）、GET /api/v1/alerts（アラート履歴）

ページネーションとフィルタを一貫させる

1つの慣例を選び全てに適用します。例：limit と cursor ページネーション、標準フィルタ service_id, sla_id, status, from, to。ソートは予測可能に（例：sort=-created_at）。

統合先が頼れるエラー応答を定義する

構造化されたエラーを返し、安定したフィールドを持たせます：

{ "error": { "code": "VALIDATION_ERROR", "message": "service_id is required", "fields": { "service_id": "missing" } } }

HTTPステータスは明確に（400 バリデーション、401/403 認証、404 未発見、409 競合、429 レート制限）。イベント取り込みでは冪等性（Idempotency-Key）を考慮して再試行でインシデントが重複しないようにします。

レート制限と基本的なセキュリティ

トークンごとに適切なレート制限を適用（取り込みエンドポイントはより厳しく）。入力をサニタイズし、タイムスタンプ/タイムゾーンを検証します。読み取り専用と書き込み権限でスコープされたAPIトークンを推奨し、誰がどのエンドポイントを呼んだかログに残しておきます（監査ログ節を参照、/blog/audit-logs）。

テスト戦略：数値が正しいことを証明する

SLA数値は信頼されなければ意味がありません。SLAトラッキングアプリのテストは「ページが読み込むか」よりも「契約通りに時間計算が正確か」を重視すべきです。計算ルールを製品機能としてテストスイート化してください。

固定タイムラインでルールをユニットテストする

計算エンジンを決定論的な入力でユニットテストします：インシデントのタイムライン（opened, acknowledged, mitigated, resolved）と明確なSLAルールセットを与えます。

時間を固定（freeze time）してテストが時計に依存しないようにします。よく壊れるエッジケースをカバーしてください：

• インシデントが報告期間開始前に始まり期間内に終わる
• 重複/重なり合うインシデント（ダウンタイムをマージするか積み上げるか）
• 複数の一時停止（メンテ、顧客待ち）
• 境界の分/秒（00:00ちょうど、月末、うるう日）

パイプライン全体のエンドツーエンドテスト

取り込み → 計算 → レポート生成 → UIレンダリング、というフローを通すE2Eテストを小セット用意します。これによりエンジンとダッシュボード間の不整合を検出できます。シナリオは少数だが価値の高いものに絞り、最終数値（可用性%、違反の有無、応答時間）をアサートします。

カレンダーとタイムゾーン用の再利用可能なフィクスチャを作る

営業時間、祝日、タイムゾーンのテストフィクスチャを用意します。例：「現地金曜17:55にインシデントが発生」「祝日が応答時間カウントをずらす」などの再現可能なケースを作っておきます。

SLAアプリ自身のモニタリング

テストはデプロイで終わりません。ジョブ失敗、キュー/バックログのサイズ、再計算時間、エラー率を監視します。取り込みが遅延したり夜間ジョブが失敗すると、コードが正しくてもレポートが間違うので監視が重要です。

デプロイ、運用、実践的なMVPロードマップ

SLAトラッキングアプリを出すのは派手なインフラよりも運用の確実性が重要です：計算は期日通り実行され、データは安全で、レポートは再現可能であること。

シンプルで信頼できるデプロイ経路

まずはマネージドサービスを使って正確性に集中します。

• Managed DB（PostgreSQL）: 自動バックアップ、ポイントインタイムリカバリ、暗号化
• コンテナホスティング（Web/API用）: ロールバックが容易で環境が一貫
• オブジェクトストレージ: エクスポート（CSV/PDF）や大きなアーティファクトの保存、ライフサイクルルール

環境は最小化：dev → staging → prod、それぞれ別DBとシークレットで。

初日から必要なバッチ/ジョブ

SLAトラッキングは同期処理だけでなく定期処理に依存します。

• 計算ジョブ: 新規イベントに基づいてSLAウィンドウを再計算、遅延到着データに対する再実行
• レポート生成: 日次/月次サマリ、顧客向けエクスポート
• データ衛生: 古い生イベントのアーカイブ、導出テーブルの圧縮、参照整合性の検証

ワーカプロセス＋キューかマネージドスケジューラで運用し、ジョブは冪等にして再試行が安全であることを保証し、各実行をログに残してください。

保持期間とエクスポート（過度な約束はしない）

データ種別ごとに保持方針を定め、導出結果は生イベントより長く保持します。エクスポートはまず CSV を提供し（透明で高速）、後でPDFテンプレートを追加。エクスポートは「最善努力のフォーマット」であり、データベースが真のソースであることを明確にしてください。

スコープ管理しながら段階的に進めるロードマップ

1. MVP: 1サービス、1SLA、1タイムゾーン、基本ダッシュボード + 月次レポート
2. 追加メトリクス: 応答時間SLA、メンテナンスウィンドウ、除外、複数カレンダー
3. 顧客ポータル: 顧客ごとのビュー、アクセス制御、ダウンロード可能なレポート
4. ステータスページ: 計算された可用性に基づく公開/非公開ページ（参照：/blog/status-pages）

プロトタイピングを速めるツール（任意）

データモデル、取り込みフロー、レポーティングUIを素早く検証したいなら、Koder.ai のようなバイブコーディングプラットフォームが助けになります。チャット経由でフルアプリ（Web UI + バックエンド）を生成でき、以下を短期間で試せます：

• コンプライアンス、エラーバジェット、ドリルダウンタイムライン用のReactダッシュボード
• 生イベントと期間結果を保存するGo + PostgreSQL バックエンド
• エクスポート/レポートエンドポイントと簡易顧客ポータル

要件と計算が検証できたら（ここが一番難しい）、ソースをエクスポートして通常のビルド＆運用ワークフローへ移行し、スナップショットやロールバックといった機能を活用しながら反復できます。

availability_percent = 100 * (eligible_minutes - downtime_minutes) / eligible_minutes