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()
4.5 KiB
4.5 KiB
客服 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
- 下次审查:灰度第一周期结束后