通知戦略 — Severity / Channel / Source 設計

このドキュメントが Parky における通知設計の SSoT (Single Source of Truth)。 個別 source の手順 (Sentry alert rule / Synthetic healthcheck / Incident response) は 別 doc に詳細を持つが、Severity 区分・Channel 振り分け・Format 標準・Anti-pattern は すべて本 doc に従う。新規 alert を追加するときも本 doc の 4 軸 (severity / channel / format / dedup) を必ず守ること。

1. 設計原則 — 1 行で

Severity 4 段 (P0/P1/P2/P3) を Discord 4 channel に 1 対 1 マッピング。各 source は severity に応じて自動振り分け。Stripe 流 SLA + Linear 流 silent-by-default + Cloudflare 流 native notification のハイブリッド。1 人運用 / pre-launch に最適化。

2. Severity Taxonomy

判定フロー

1. 本番 user に影響あるか? → Yes なら最低 P1、影響大 (全停止 / データ損失) なら P0
2. 放置で P0 化するか? → Yes なら P1
3. 個別に見る価値あるか? → Yes なら P2、No なら P3 (digest)

1 人運用での簡略化: P0 のみ通知音 ON / mention 有り。P1 はサイレント通知 (見たら対応)。 P2 / P3 は寝かせて朝チェック。これにより「夜中に起きる必要があるのは P0 のみ」が明確化する。

3. Discord Channel 設計

通知 channel は 2 軸構成 で設計する:

• A. Operational alert (4 channel) — システム異常・運用イベント。Severity (P0/P1/P2/P3) と 1 対 1 マッピング。
• B. Business workflow event (N channel, topic 別) — 業務フローのトリガー (新規 task / 申請 / 重要 user action 等)。severity ではなく topic で分類。

両者は 完全に分離 する。Business event を operational channel に混ぜると alert 疲れの典型 anti-pattern (Stripe / Linear で確立された原則)。

A. Operational alert channels (severity-based)

Severity と 1 対 1 マッピング。1 人運用なら source 別 (Sentry / GHA / CF) 分割よりも severity 別の方が認知負荷が低い (Linear / Vercel 同パターン)。

B. Business workflow event channels (topic-based)

将来追加候補 (launch 後):

Channel	Topic
#parky-owner-applications	新規オーナー申請 / 書類提出
#parky-revenue	大口決済 / 売上速報
#parky-signups	新規ユーザー登録 (digest)
#parky-support	サポート chat 着信

Business event channel の設計原則:

1. 必ず severity を付与 (上表の "Severity 相当" 列) — 同じ format 標準を使い、視覚的に operational alert と一貫させる
2. 1 topic = 1 channel (混ぜない) — 「タスク全部」じゃなく「admin タスク作成」「owner 申請」のように具体的に
3. mention は基本 false — operational P0 だけが mention、business event は mute された情報源
4. 新規 channel 追加時は本 doc の表に追記必須 — channel 数が増えすぎないようゲートする (5+ になったら統合検討)
5. alert ではなく "event log" として扱う — 必ずしも対応必須ではなく、業務状況を見渡す目的

各 channel の用途まとめ

#parky-alerts (P0)

本番障害、データ損失、セキュリティ侵害、Critical CVE。15 分以内に確認 + Discord で「対応開始」リアクション or reply。

#parky-ops (P1)

業務に支障あるが緊急じゃない、修正計画立てる対象。営業時間内、4 時間以内に対応。

#parky-deploys (P2)

進捗確認、後追いで見ればよい情報。翌営業日に確認 OK、対応不要も多い。

#parky-insights (P3)

定期サマリー、傾向把握、business KPI。週次 review でまとめて見る。

4. Source × Channel × Action 完全表

新規 alert を追加するときは必ずこの表に行を足してから実装すること。各行が「① system / ② 頻度 / ③ check / ④ 条件 / ⑤ メッセージ / ⑥ channel / ⑦ action」の 7 軸を満たす。

P0 → #parky-alerts

P1 → #parky-ops

P2 → #parky-deploys

Business events → topic-based channels

P3 → #parky-insights

5. Alert Format 標準

必須 field (1 つでも欠けたら NG)

任意 field

• owner: 主担当 (1 人運用なら省略 or dev@parky.co.jp 固定)
• related_alerts: 同 window で発火した別 alert ID (cascade 検知用)
• auto_resolve: 自動解決された時刻 (transient flap 等)

Discord embed の実例 (P0)

{
  "content": "@here :rotating_light: **[P0] parky-api (prod) 5xx burst**",
  "embeds": [{
    "title": "Sentry alert: 5xx errors burst",
    "color": 14431557,
    "fields": [
      { "name": "Service",   "value": "parky-api (prod)", "inline": true },
      { "name": "Env",       "value": "prod",             "inline": true },
      { "name": "Symptom",   "value": "52 errors / 5min (threshold: 50)" },
      { "name": "Sentry",    "value": "[Issue PARKY-123](https://parky-72.sentry.io/issues/123)" },
      { "name": "Runbook",   "value": "[incident-response.md#sev1-checklist](https://github.com/...)" },
      { "name": "Triggered", "value": "2026-04-29 10:23 JST (01:23 UTC)", "inline": true }
    ],
    "footer": { "text": "Parky Sentry alert · rule R-01" },
    "timestamp": "2026-04-29T01:23:00Z"
  }]
}

Discord embed 色コード (severity 視覚化)

6. Dedup / Suppression ルール

夜中 mute は 1 人運用では不要: Stripe / GitHub は on-call rotation があるので "wake up only for P0" は意味あるが、Parky 1 人運用なら寝てる間の P0 も「起きてから」対応で OK。むしろ dedup を強くして「鳴ったら 100% 本物」状態を作る方が効果大。

7. Failure handling & resilience — Webhook 失敗時の振る舞い

設計判断: Discord 直 + retry + DLQ (P0 のみ email backup)

「より可用性の高い relay サービス (PagerDuty / Opsgenie / 自前 Worker) を経由する」案は delivery 目的だけなら採用しない。理由:

採用するアーキテクチャは 3 層防御 + 多チャネル冗長化 (P0 のみ):

[Layer 1] Direct Discord webhook
    ↓ 失敗 (5xx / 429 / network error)
[Layer 2] Exponential backoff retry (3 attempts: 1s → 4s → 16s)
    ↓ 全失敗
[Layer 3] DLQ 永続化 (admin.notification_failures table)
    + P0 のみ email fallback (Resend, 別物理経路で送信)
    ↓ 後で
[Layer 4] 週次 cron が DLQ 集計 → #parky-insights に digest

故障モード別の挙動

Retry policy (詳細)

Backoff: 1s → 4s → 16s (4× 倍増)。最大 3 回試行 = 21 秒以内に決着。

P0 backup email の設計

• 対象: severity = P0 のみ (P1/P2/P3 は DLQ 記録のみで email しない、過剰通知防止)
• provider: 既存 Resend (lib/transactional-email.ts)。物理経路が Discord と完全分離 (Resend 障害 ≠ Discord 障害)
• 送信先: dev@parky.co.jp (固定、複数人運用時に env で多人数化)
• Subject: [P0 BACKUP] <title> で先頭明示 (重複時の dedup 容易化)
• Body: HTML + text 両対応、Discord embed と同じ field を平文化
• 失敗時の挙動: email も失敗したら DLQ の fallback_email_sent=false のまま、digest で目立つ
• 将来拡張: 別 provider (SES / SendGrid) を二段目 fallback として追加検討、launch 後の規模次第

DLQ schema (admin.notification_failures)

週次 DLQ digest cron

• 配信先: #parky-insights (P3)
• 頻度: 毎週月曜 09:00 UTC (JST 18:00) — HOURLY スロット同居
• 内容: 過去 7 日 status='failed' の集計 (channel 別 / 件数 / top 3 エラーメッセージ)
• 集計後: 該当行の status を manual_acknowledged に更新 (再 digest 防止)

8. アンチパターン

新規 alert / channel 設計時に以下を作らないこと:

• 全部 1 channel に流す — P0 と info が同じ channel に並ぶと user は info の山から P0 を見つけられない、3 日で「もう見ない」状態に
• @here を P1/P2 で使う — @here が無意味化、本当の P0 で誰も気付かない、P0 のみ mention を厳守
• 同じ事象を複数 source から重複通知 — 例: 5xx burst で Sentry alert + healthcheck + GHA E2E fail が同時発火 → 3 通知、Cascade suppression 必須
• Email + Discord 並行 — どちらか一本に絞る、Parky は Discord メイン、email は Sentry 個別 issue triage 用にだけ残す
• Runbook link なし — 「何が起きたか」だけ書いて「どうすればいいか」が無いと寝起き / 移動中に対応できない、全 alert に runbook link 必須
• 平文だけ (Discord embed 不使用) — 色 / icon / structured field がないと一瞥で severity 判別不可、必ず embed 形式
• Quiet hours を 1 人運用で強制 — on-call rotation があるなら意味あるが、1 人運用では結局自分で見るので mute しても意味薄い、むしろ dedup を強化
• Severity の判断を都度 — 各 alert で「これ P0?」を悩むのは時間の無駄、alert rule 作成時に severity を必ず固定、後で見直しは月次

9. テック企業ベンチマーク

結論: Linear 流の severity-based 4 channel + Stripe 流の SLA + format 標準 + Cloudflare 流の native notification 活用 のハイブリッドを Parky で採用。

10. 実装ロードマップ

Phase 1 — 今週 (工数 2-3h)

1. Discord channel 5 本作成: #parky-alerts / #parky-ops / #parky-deploys / #parky-insights / #parky-admin-tasks
2. Webhook URL 5 本発行 → 1Password に保存
   • Vault: PJ｜Parky
   • Item 名: Discord Webhook｜#parky-alerts / #parky-ops / #parky-deploys / #parky-insights / #parky-admin-tasks
   • Field: url (secret)
3. GH Secrets に登録: DISCORD_WEBHOOK_ALERTS / DISCORD_WEBHOOK_OPS / DISCORD_WEBHOOK_DEPLOYS / DISCORD_WEBHOOK_INSIGHTS / DISCORD_WEBHOOK_ADMIN_TASKS
   • 既存 DISCORD_HEALTHCHECK_WEBHOOK_URL は廃止 → DISCORD_WEBHOOK_OPS に統合
4. Wrangler secrets に投入: DISCORD_WEBHOOK_ADMIN_TASKS を dev / prod に。api/src/env/bindings.ts に型宣言済み。

   cd parky/api
   wrangler secret put DISCORD_WEBHOOK_ADMIN_TASKS --env dev
   wrangler secret put DISCORD_WEBHOOK_ADMIN_TASKS --env prod
   

5. Synthetic healthcheck workflow を severity-aware に改修: dev fail → OPS / prod fail → ALERTS
6. Reusable workflow _notify-discord.yml 作成: severity / channel / message を input に取り、適切な webhook + format で送信
7. 全 prod deploy workflow に if: failure() notify step 追加: _notify-discord.yml を使い OPS へ送信
8. Admin task 通知の動作確認: 管理者ポータルから新規 task 作成 → #parky-admin-tasks に投稿されるか確認 (未投入なら warn log のみ)

Phase 2 — 1-2 週 (工数 4-6h)

1. Sentry Discord native integration 設定: 2024+ で native 提供、12 alert rule 全てを severity に応じた channel に振り分け
2. Cloudflare Notifications 設定: Workers outage / Pages deploy fail / R2 quota / WAF を該当 channel に webhook 配線
3. DLQ monitor を OPS へ統合: DLQ_WEBHOOK_URL を DISCORD_WEBHOOK_OPS に向け直し
4. Cost / Quota 監視 cron 作成: 週 1 回 GH Actions で各 service API を叩いて集計、80% 超過で OPS へ
5. Dependabot 通知整理: GitHub Settings → Notifications → Dependabot を email デフォルト → repo 内 weekly digest 化

Phase 3 — 1 ヶ月 (工数 6-8h)

1. Supabase 健全性監視: pg_cron で pool / slow query / RLS violation 集計 → BFF endpoint → Discord webhook
2. Weekly digest workflow: 月曜朝に Sentry + GHA + uptime + cost を集約 → INSIGHTS へ HTML サマリ
3. Business KPI digest (launch 後): signup / DAU / 駐車場登録 etc. → INSIGHTS
4. Maintenance window mute: scripts/notify/suppress.sh --duration 30m で全 webhook 一時無音化
5. Status page (status.parky.co.jp): launch 後の customer-facing 透明性のため Better Uptime Public Status / Atlassian で構築

Phase 4 — 3 ヶ月 (工数 4h, 任意)

1. Runbook automation: alert に Discord button (interactive component) 追加で "ack" / "runbook 開く" / "mute 30m" を 1 click 化
2. Postmortem 自動雛形生成: P0 alert 解決後に GitHub Issue を自動生成、postmortem-template.md ベースで雛形プレフィル

11. コスト見積もり

段階別コスト

• Phase 1-2 (現状): $0/mo (Discord + GH Actions + Sentry Dev + CF Notifications + Better Uptime Free)
• launch 後 (~3 ヶ月): $25-50/mo (Supabase Pro + Sentry Team)
• scale 後 (~6 ヶ月): $100-150/mo (CF Pro / Honeycomb Pro / 専用 monitor 等)

GH Actions 圧縮策: synthetic healthcheck cron を 5 分 → 10 分間隔に変更で月使用 720 → 360 min。Better Uptime Free (10 monitors / 3 分間隔) に丸ごと移行すれば GH Actions 0 min に。

12. シナリオ別の挙動例

シナリオ A: 平常時 (ローンチ前)

• 月曜朝に #parky-insights で weekly digest 4-5 通
• 日中に #parky-deploys で dev deploy 通知 5-10 通
• #parky-ops #parky-alerts は基本無音

シナリオ B: dev healthcheck 1 回 fail

• #parky-ops に [P1] dev healthz down 1 通
• 5 分後の次 cron で復活したら何も来ない (auto-resolve)

シナリオ C: prod に bad deploy

• #parky-alerts に [P0] prod healthz down (synthetic healthcheck)
• #parky-alerts に [P0] 5xx burst (Sentry)
• → cascade suppression で 2 通目以降は thread reply に集約
• #parky-ops に [P1] prod deploy failed (post-deploy assert) (GHA)
• 対応 → wrangler rollback → 5 分後 healthz 緑 → #parky-alerts thread に「auto-resolved」reply

シナリオ D: Critical CVE (例: lodash 脆弱性)

• #parky-ops に [P1] Critical CVE: lodash@4.17.x 1 通 + Dependabot PR link
• 翌営業日に PR review → merge → #parky-deploys で deploy success 通知

13. 関連 doc

このドキュメントが SSoT。以下は本戦略に従って動く individual runbook:

• incident-response.md — P0/P1 発火時の対応フロー、SEV1/2/3 → P0/P1/P2 に整合
• sentry-alert-rules.md — Sentry 12 alert rule の severity 振り分け実装
• synthetic-healthcheck.md — synthetic-healthcheck.yml の channel routing
• observability-hookup.md — Sentry / Honeycomb DSN 投入手順 + Discord native integration
• postmortem-template.md — P0 解決後の postmortem 雛形
• slo-error-budget.md — SLO 定義、burn rate alert の根拠
• secret-rotation.md — Webhook URL rotation を含む secret 全般
• logging.md — log level 設計 (alert 発火条件の判断材料)

監査根拠 (社内 work)

• .work/parky/2026-04-29_001_parky_comprehensive_evaluation_v2.html — Operations 軸監査 (本戦略の動機)
• .work/parky/2026-04-29_002_parky_notification_strategy.html — 本 doc の HTML 版 (visual reference)

変更履歴

• 2026-04-29: 初版作成。既存 3 つの通知配線 (Sentry alert / DLQ / synthetic healthcheck) を整理し、Severity 4 段 + Discord 4 channel の framework を確立。