P0-1 (limits.go): Allow()方法改为全程使用写锁保护counters map读写,避免RLock写入时的data race P0-2 (ticket_workflow.go+ticket_handler.go): Assign/Resolve/Close操作先查询ticket存在性和状态,返回明确的CS_TICKET_4001/CS_TKT_4002/CS_TICKET_4092/CS_TICKET_4093错误码,handler根据错误前缀路由HTTP状态码 P1-1 (ticket_store.go): 移除GetStats中3处手动rows.Close(),只保留defer Close()
127 lines
4.5 KiB
Markdown
127 lines
4.5 KiB
Markdown
# 客服 SLA 与升级响应规范
|
||
|
||
> 版本:v1.0 | 状态:已生效
|
||
> 关联:tech/INTERFACE.md、PRODUCTION_PHASE1_STATUS.md
|
||
|
||
---
|
||
|
||
## 1. 客服 SLA 定义
|
||
|
||
### 1.1 核心 SLA 指标
|
||
|
||
| 指标 | 目标值 | 说明 |
|
||
|------|--------|------|
|
||
| Webhook 可用率 | ≥ 99.5% | 成功接收渠道消息的比率 |
|
||
| 首次响应时间(机器人) | ≤ 5s | 从收到消息到发出首字的时间(P95) |
|
||
| 机器人回答准确率 | ≥ 85% | FAQ 命中且用户未点"不满意" |
|
||
| 转人工率 | ≤ 15% | 需要人工介入的会话比例 |
|
||
| 工单响应时间 | ≤ 30min | 从创建到客服接单的时间(P95) |
|
||
| 工单解决时间 | ≤ 4h | 从创建到解决的时间(P95) |
|
||
|
||
> **注**:上述指标为生产一期目标值,实际值需在灰度阶段采集并调整基线。
|
||
|
||
### 1.2 SLA 优先级定义
|
||
|
||
| 优先级 | 定义 | 响应时间 | 解决时间 |
|
||
|--------|------|----------|----------|
|
||
| P1 | 机器人完全不可用(所有消息报错) | 15min | 1h |
|
||
| P2 | 核心能力降级(签名/幂等失效、频繁 5xx) | 30min | 2h |
|
||
| P3 | 非核心功能异常(部分渠道失败、偶发报错) | 2h | 8h |
|
||
|
||
---
|
||
|
||
## 2. 升级响应规范
|
||
|
||
### 2.1 升级链路
|
||
|
||
```
|
||
告警/故障发现 → P3 处理(值班工程师) → 若恶化升级 P2 → 若继续恶化升级 P1
|
||
```
|
||
|
||
### 2.2 告警触发条件
|
||
|
||
| 条件 | 级别 | 通知方式 |
|
||
|------|------|----------|
|
||
| Webhook 可用率 < 99% 持续 5min | P2 | 飞书群 + 电话 |
|
||
| 错误率 > 5% 持续 5min | P2 | 飞书群 |
|
||
| PostgreSQL 连接失败 | P1 | 电话 + 飞书群 |
|
||
| 签名校验失败率 > 20% 持续 10min | P3 | 飞书群 |
|
||
| 工单积压 > 50 个 open 状态 | P3 | 飞书群 |
|
||
|
||
> **注**:告警系统(metrics/tracing/SLO)属于 P1 缺口,**当前未落地**,告警触发依赖人工巡检。生产一期灰度阶段需补齐可观测性基础设施。
|
||
|
||
### 2.3 升级决策人
|
||
|
||
| 级别 | 第一响应人 | 升级对象 |
|
||
|------|------------|----------|
|
||
| P3 | 值班工程师 | Team Lead |
|
||
| P2 | Team Lead | 技术总监 |
|
||
| P1 | 技术总监 | 小龙/业务负责人 |
|
||
|
||
### 2.4 故障处理要求
|
||
|
||
- P1/P2 故障:故障清除后 24h 内提交故障报告
|
||
- P3 异常:记录在运营日志,下周一回溯复盘
|
||
- 所有故障必须在下一灰度周期前完成根因分析
|
||
|
||
---
|
||
|
||
## 3. 当前阶段说明
|
||
|
||
### 3.1 可用性现状
|
||
|
||
| 能力 | 当前状态 | 备注 |
|
||
|------|----------|------|
|
||
| Webhook 可用率监控 | 未完成 | P1 缺口,metrics/tracing 未落地 |
|
||
| 错误率监控 | 未完成 | 同上 |
|
||
| PostgreSQL 连接监控 | ✅ 已完成 | `/ready` 含 PostgreSQL 依赖检查 |
|
||
| 工单积压监控 | 未完成 | 无定时任务扫描 open 工单 |
|
||
| 安全拒绝事件审计 | ✅ 已完成 | `webhook_security.go` 的 `auditReject` 写入审计 |
|
||
| 工单状态流转审计 | ✅ 已完成 | `TicketWorkflowStore.writeAudit` 在 assign/resolve/close 时调用 |
|
||
|
||
### 3.2 接口级 SLA(当前代码能力)
|
||
|
||
以下为代码中已实现的接口响应时间基准(本地压测数据,待灰度验证):
|
||
|
||
| 接口 | 目标延迟 | 当前状态 |
|
||
|------|----------|----------|
|
||
| `POST /webhook` | < 200ms P99 | HMAC 校验 + 幂等检查开销约 5-10ms |
|
||
| `GET /tickets` | < 300ms P99 | PostgreSQL 查询,无索引优化 |
|
||
| `POST /tickets/{id}/assign` | < 200ms P99 | 单条 UPDATE |
|
||
| `POST /tickets/{id}/resolve` | < 200ms P99 | 单条 UPDATE |
|
||
| `GET /actuator/health` | < 50ms | 依赖 PostgreSQL |
|
||
|
||
> **注**:当前压测数据为本地单实例,未经过真实渠道流量验证。
|
||
|
||
---
|
||
|
||
## 4. 错误码与 SLA 映射
|
||
|
||
错误码定义见 `tech/INTERFACE.md`,与 SLA 相关联的快速参考:
|
||
|
||
| 错误码 | 含义 | SLA 影响 |
|
||
|--------|------|----------|
|
||
| `CS_SES_4001` | 会话不存在 | 返回 404,用户可重试 |
|
||
| `CS_SES_4002` | 消息频率过高 | 返回 429,触发限流逻辑 |
|
||
| `CS_TKT_4001` | 工单不存在 | 返回 404 |
|
||
| `CS_TKT_4002` | 工单已被分配 | 返回 409,幂等性保证 |
|
||
| `CS_LLM_5001` | LLM 服务不可用 | 触发转人工,SLA 降级 |
|
||
| `CS_LLM_5002` | LLM 超时 | 同上 |
|
||
|
||
---
|
||
|
||
## 5. 持续改进
|
||
|
||
SLA 基线在灰度第一周期(建议 2 周)后复盘,根据真实数据调整:
|
||
- 若机器人响应时间 P95 > 5s,需优化 LLM 调用链路
|
||
- 若转人工率 > 20%,需复盘意图识别准确率
|
||
- 若工单解决时间 P95 > 4h,需增加客服人力或优化分流策略
|
||
|
||
---
|
||
|
||
## 6. 当前版本状态
|
||
|
||
- **本文档版本**:v1.0
|
||
- **生效日期**:2026-04-30
|
||
- **下次审查**:灰度第一周期结束后
|