92 lines
5.5 KiB
Markdown
92 lines
5.5 KiB
Markdown
# 宠小它生产监控与告警基线
|
||
|
||
> 适用阶段：3～5 家单店试点。阈值是首版基线，上线两周后按真实流量校准。当前仓库只提供健康探针与运行手册；外部监控、日志平台和通知渠道必须在生产发布前实际接入并留证。
|
||
|
||
## 1. 监控目标
|
||
|
||
按优先级守住四件事：
|
||
|
||
1. 预约、开始服务、提交报告、打开报告的主链路可用；
|
||
2. 不产生跨店、身份错绑、状态回退、重复报告或容量超卖；
|
||
3. 数据库、上传目录、磁盘、FFmpeg 和 TLS 等运行依赖可用；
|
||
4. 监控本身不泄露密码、手机号、完整 token、微信标识或私密媒体 URL。
|
||
|
||
## 2. 健康探针
|
||
|
||
| 探针 | 地址 | 含义 | 使用方式 |
|
||
|---|---|---|---|
|
||
| Liveness | `/actuator/health/liveness` | JVM/Spring 是否存活 | 连续失败才重启，避免业务依赖短抖导致重启风暴 |
|
||
| Readiness | `/actuator/health/readiness` | DB、磁盘、上传目录、FFmpeg/ffprobe 是否可用 | 非 UP 立即摘流，不把请求送给未就绪实例 |
|
||
|
||
生产 `show-details=never`，公网响应只显示总状态。探针日志不得附环境变量值。`petstoreRuntime` 结果缓存 30 秒，避免每次 readiness 都启动外部进程。
|
||
|
||
## 3. 首版告警阈值
|
||
|
||
| 信号 | Warning | Critical | Owner |
|
||
|---|---|---|---|
|
||
| Readiness | 1 次失败 | 连续 2 次失败或持续 2 分钟 | Backend Ops |
|
||
| HTTP 5xx | 5 分钟 ≥ 2% 或 ≥ 5 次 | 5 分钟 ≥ 5% 或 ≥ 20 次 | Backend Ops + 业务 owner |
|
||
| API p95 | 10 分钟 > 1 秒 | 10 分钟 > 2 秒 | Backend Ops |
|
||
| DB 连接池 | active/max 持续 5 分钟 > 70% | 持续 5 分钟 > 85% 或获取超时 | Backend Ops / Data Model |
|
||
| 磁盘 | 可用 < 20% 或 < 20 GB | 可用 < 10% 或 < 10 GB | Backend Ops |
|
||
| 上传失败 | 10 分钟 ≥ 3 次 | 10 分钟 ≥ 10 次或连续失败 | Report Media Backend |
|
||
| 成片失败 | 30 分钟失败率 ≥ 10% | ≥ 20% 或连续 3 个任务失败 | Report Media Backend |
|
||
| TLS | 距到期 < 21 天 | 距到期 < 7 天 | Backend Ops |
|
||
| 主链路人工救援 | 当日 ≥ 1 次 | 同类问题当日 ≥ 3 次 | Core Flow QA / PM |
|
||
| 权限或隐私异常 | 不设 Warning | 任意 1 次即 Critical | System Architect / Privacy owner |
|
||
|
||
低流量试点同时看比例和绝对数量，避免一个请求造成噪音；权限、隐私和数据串店不做流量豁免。
|
||
|
||
## 4. 应用与业务信号
|
||
|
||
### 技术指标
|
||
|
||
- 按 endpoint family 聚合请求量、2xx/4xx/5xx、p50/p95/p99，不记录 query 中的 token；
|
||
- JVM heap、GC pause、线程数、进程重启次数；
|
||
- Hikari active/idle/pending/max 和获取连接耗时；
|
||
- 上传目录容量、inode、读写失败；
|
||
- FFmpeg/ffprobe 可执行性、成片耗时、失败归类（material/service/network/unknown）；
|
||
- Nginx 499/502/503/504、上游延迟、证书到期；
|
||
- 每次发布的 commit、时间、操作者和 readiness 变化标记。
|
||
|
||
### 业务漏斗
|
||
|
||
每天按门店聚合 `appointment_created → service_started → service_completed/report_submitted → report_opened → lead_submitted → rebooked`。试点初期不把业务漏斗波动直接当系统故障，但需检查：
|
||
|
||
- 有 done 无报告、报告无客户/作者、重复报告；
|
||
- BusinessEvent 缺失或幂等键重复；
|
||
- 服务时长/预约快照非法、容量超卖；
|
||
- 报告已提交但长期未打开；
|
||
- 回访后没有明确状态或再次预约归因。
|
||
|
||
发布前的 `release-preflight.sh` 已覆盖前四类结构/数据不变量；运行期应每天做等价的只读审计或报表，不自动修复。
|
||
|
||
## 5. 日志与隐私
|
||
|
||
- 采用结构化字段：timestamp、level、traceId、endpoint、status、duration、storeId（内部受控）；
|
||
- 不记录请求/响应全文，不记录密码、验证码、AppSecret、session token、完整 report token、完整手机号、openid/unionid 或媒体签名 URL；
|
||
- 公开报告只允许使用不可逆短 hash 做技术关联，业务事件表本身不保存 token/hash；
|
||
- 错误对用户返回稳定业务码和可理解文案，堆栈只进入受控日志；
|
||
- 生产日志访问采用最小权限，导出/截图前脱敏，并设置保留周期。
|
||
|
||
## 6. 告警处理流程
|
||
|
||
1. 告警必须带：环境、时间、信号名、当前值、受影响 endpoint/门店数量、最近发布版本；不得带敏感值。
|
||
2. 值班人先判断是否为探针、依赖或业务错误；readiness Critical 先摘流，权限/隐私 Critical 先关闭相关入口。
|
||
3. 15 分钟内明确 owner 和下一动作；30 分钟仍未恢复则启动回滚评估。
|
||
4. 若问题与新版本相关且旧应用兼容当前数据库，按 Runbook 切回上一版本；禁止为了快速恢复而删新列/表或直接改业务状态。
|
||
5. 恢复后补时间线、根因、影响、修复、验证和预防项；事故报告不粘贴真实 token/手机号/媒体 URL。
|
||
|
||
## 7. 上线前接入清单
|
||
|
||
- [ ] 外部 HTTPS 探测覆盖 liveness/readiness、admin、H5 报告入口；
|
||
- [ ] 5xx、延迟、DB 池、磁盘、证书和进程重启已配置告警；
|
||
- [ ] FFmpeg/上传失败有可聚合字段，而非只能搜索自由文本；
|
||
- [ ] BusinessEvent 日漏斗和 15 项只读数据审计有每日结果；
|
||
- [ ] 通知渠道、Primary/Backup 值班人和升级联系人完成真实测试；
|
||
- [ ] 日志脱敏抽查通过，访问权限和保留周期已批准；
|
||
- [ ] 发布标记能关联四仓 commit 与 RC；
|
||
- [ ] Gitea/GitLab 有独立监控，Petstore 发布后做旁路回归。
|
||
|
||
未完成以上接入，RC 只能保持 `Ready for Release`。
|