docs: close caller analytics remediation delivery
This commit is contained in:
hectorzhao
@@ -0,0 +1,64 @@
|
||||
# 主叫号码实时分析专项整改交付报告
|
||||
|
||||
日期：2026-09-01
|
||||
状态：整改实现、B机发布及受控功能/可靠性验收完成；容量与真实多线路重试保留明确限制。
|
||||
|
||||
## 1. 交付版本与边界
|
||||
|
||||
- B机生效提交：`9fa1964dec98cbe3c53c901ba764373308054d5e`。
|
||||
- 发布目录：`/opt/lisglosips/releases/caller-analytics-20260901T024406Z`。
|
||||
- 回滚备份：`/var/backups/lisglosips-caller-analytics/20260901T024406Z`。
|
||||
- 发布制品SHA-256：`b2f22a04312b1979a11eec62ed797e65ab6c4c8d25174075a8dbc0d723ea7435`。
|
||||
- 新采集连续覆盖起点保留为`2026-09-01T02:23:21Z`，发布重启不伪造新的连续历史。
|
||||
- 本次只改主叫分析采集、分析存储、API、页面、独立Redis和运维脚本。没有修改计费、余额、路由选择和旧固定6秒CDR逻辑，没有部署A/T，也没有呼叫公网号码。
|
||||
|
||||
本地标准制品脚本在Windows创建符号链接时遇到`EPERM`。本次使用等价的delta overlay制品：B机先复制上一release，再覆盖本提交受控文件；发布脚本仍执行备份、迁移、候选配置检查、服务切换和健康门槛。
|
||||
|
||||
## 2. 整改结果
|
||||
|
||||
| 整改组 | 落地结果 | 状态 |
|
||||
| --- | --- | --- |
|
||||
| R01～R03 时长、未知与乱序 | TALK_START在对话路由匹配后产生，ACK后开始计时；时长分未知/暂定/最终；最终零时长具有权威优先级；状态归约支持重复和乱序 | 已完成 |
|
||||
| R04～R05 完整性、留存与隔离 | 生产/采集计数、水位、日志未读字节、持久gap/DLQ、pending安全裁剪；独立Redis启用AOF、noeviction及256MB上限；维护和logrotate已安装 | 已完成 |
|
||||
| R06～R07 生命周期与契约 | 增加显式CLOSE、生产节点/boot/sequence、事务阶段、证据来源与算法版本；单attempt保持当前真实路由语义 | 已完成；真实重试启用前补验 |
|
||||
| R08～R10 API、告警与页面 | 查询覆盖、snapshotId、稳定分页、供应商筛选、未知/null比率、告警规则独立持续计数与降级暂停、详情信令证据均已落地 | 已完成 |
|
||||
| R11 性能与容量 | 活跃呼叫分页、查询上限、资源隔离和延迟字段已落地；本轮只验证受控功能负载 | 工程整改完成；容量/P95未承诺 |
|
||||
| R12 发布回滚 | 版本化采集V3、完整备份、逐步回滚、独立Redis备份、配置校验、空闲检查、健康和提交校验已落地并用于本次发布 | 已完成；未逐点实施破坏性失败注入 |
|
||||
| R13 状态与证据 | V1.2设计、状态索引、测试索引、本报告及机器证据已同步 | 已完成 |
|
||||
|
||||
## 3. 验证结果
|
||||
|
||||
本地验证全部通过：ESLint、`tsc -b tsconfig.build.json`、Vite生产构建、Prisma schema校验；Vitest共29个文件、118项。OpenSIPS从V1/V2生成V3配置后在B机执行`opensips -C`通过。
|
||||
|
||||
B机最终审计显示以下服务均为`active/enabled`：OpenSIPS、API、CDR Worker、Caller Analytics Worker、Caller Analytics独立Redis、维护timer。`/api/v2/health/ready`返回`status=ok`，数据库和Redis检查均为ok。独立Redis实测AOF开启、持久化状态正常、`noeviction`、上限256MB；Stream pending为0。
|
||||
|
||||
末轮6通真实本机回环SIP全部通过原有平台路由，两个成功场景包含SDP offer/answer并通过RTPEngine：
|
||||
|
||||
| 场景 | 统计结果 |
|
||||
| --- | --- |
|
||||
| 180后486 | C=1，A=0 |
|
||||
| 183后487 | C=1，A=0 |
|
||||
| 直接486 | C=0，A=0 |
|
||||
| 直接200，ACK后约1.5秒BYE | C=1，A=1 |
|
||||
| 180→200，ACK后约300ms BYE | C=1，A=1 |
|
||||
| 100后486 | C=0，A=0 |
|
||||
|
||||
汇总为`T=6、C=4、A=2、N=2`，接通率66.6667%，总体应答率33.3333%，已接通应答率50%，`talkMs=1801`，未知、待接通和暂定应答均为0。实测数据覆盖为`CONTINUOUS`，末次API采集延迟468ms。该单点观测不能替代统计P95。
|
||||
|
||||
真实API与数据库还验证了状态表/分钟桶逐字段对账、5条事件重放幂等、未认证401、非法查询400、无授权/跨客户403、客户及供应商范围选项不越权。机器证据归档在[caller-analytics-real-20260901.json](../tests/reports/caller-analytics-real-20260901.json)。
|
||||
|
||||
可靠性验证包括：维护任务dry-run与实际执行、logrotate规则识别、独立Redis重启后Stream长度保持、非法JSON进入持久死信并ACK、覆盖状态转为降级、处置后恢复连续。最终保留一条`RESOLVED`的计划发布重启gap及一条`RESOLVED`的毒事件deadletter，作为审计证据。
|
||||
|
||||
## 4. 页面验收
|
||||
|
||||
优先使用Codex Browser插件访问B机时，HTTP入口被客户端阻止，HTTPS尝试超时并重置浏览器内核。按浏览器测试规范改用仓库Playwright和系统Chrome完成回退验收；登录通过真实`/auth/refresh`会话，业务数据来自真实API/MySQL，没有mock、静态替代或localStorage业务数据。
|
||||
|
||||
已验证应用壳、主叫分析菜单、客户/供应商筛选、连续覆盖、版本/未知字段、三个比例、详情证据及300ms时长，覆盖1440×1000桌面和390×844移动视口。移动端宽表使用现有横向滚动容器，抽屉独立纵向滚动。控制台无错误。截图保存在`.codex-private/caller-analytics-desktop-20260901.png`和`.codex-private/caller-analytics-mobile-20260901.png`。
|
||||
|
||||
验收后已删除临时登录会话，数据库中对应会话数为0；受控客户入口和供应商出口`cra_20260831`均已恢复为`DISABLED`，测试证据保留。
|
||||
|
||||
## 5. 未作出的承诺
|
||||
|
||||
本轮没有可确认的峰值CPS、号码/维度基数和目标保留期，因此没有执行有业务依据的容量压测，也不宣称页面端到端P95≤5秒或机器容量上限。后续在真实多线路重试启用前，还需按实际attemptId和路由策略补做两线路重试验收。上述两项不会把当前单线路统计结果解释成未完成，但限制容量与未来重试能力的对外声明。
|
||||
|
||||
Git本地提交和B机部署均已完成；`git push origin main`因远端HTTP用户认证失败而未成功。远端仓库在认证恢复前不包含本次提交，不能把B机部署或本地commit表述为已推送。
|
||||
@@ -172,7 +172,7 @@
|
||||
|
||||
新增影响包括OpenSIPS事件采集开销、Redis队列容量、MySQL写放大、查询和缓存负载。统计新表/新服务独立部署并使用功能开关；回滚可关闭采集钩子和分析Worker/入口，保留证据及新表，不删除既有话单、不调整计费余额和路由。生产修改及受控外呼须按届时任务授权执行。
|
||||
|
||||
## 10. 验收用例（设计，尚未执行）
|
||||
## 10. 验收用例（设计与执行状态）
|
||||
|
||||
以下单呼叫终态用例默认T=1；应答时长均指可信实际通话时长。未说明缺口的用例假设完整采集。
|
||||
|
||||
@@ -203,7 +203,7 @@
|
||||
| CRA-023 | 只有可信最终正时长CDR，过程丢失 | 补C/A并标CDR证据，不伪造180/183，不重复T |
|
||||
| CRA-024 | 采集失联导致一个呼叫阶段无法判定 | U单列，T=C+N+U，不自动判失败，率标暂定/不完整 |
|
||||
|
||||
功能验收须形成真实SIP信令、API返回、数据库状态/聚合与最终话单的对应证据；mock、静态页面或localStorage不构成功能验收。单元测试用于公式/状态转换，真实联调用于端到端与故障恢复。正常约定负载下事件或可信正时长可用至页面可见的P95目标≤5秒；这是待测目标，不是当前容量承诺。需分别记录采集、消费、API和页面延迟及原有呼叫/计费回归结果。
|
||||
功能验收须形成真实SIP信令、API返回、数据库状态/聚合与最终话单的对应证据；mock、静态页面或localStorage不构成功能验收。2026-09-01已完成公式/状态自动化回归、6通受控真实SIP、SDP/RTPEngine、真实API/MySQL/RBAC、重放幂等、故障恢复及真实页面验收，详见[整改交付报告](CALLER_REALTIME_ANALYTICS_DELIVERY_20260901.md)。正常约定负载下事件或可信正时长可用至页面可见的P95目标≤5秒仍为待测目标；当前没有约定峰值负载，不作容量承诺。真实多线路重试在路由功能启用前补验。
|
||||
|
||||
## 11. 本次交付边界
|
||||
|
||||
|
||||
@@ -1977,7 +1977,7 @@ corepack pnpm@10.33.0 exec vitest run apps/worker-recording/src/transfer.spec.ts
|
||||
|
||||
## 8A. 主叫号码实时分析验收设计索引（2026-08-31）
|
||||
|
||||
[主叫号码实时分析V1.1](CALLER_REALTIME_ANALYTICS_DESIGN.md)第10节定义CRA-001至CRA-024，覆盖180/183业务接通、正时长应答、总体应答率A/T、已接通应答率A/C、直接200/缺少100/零时长/亚秒时长、待接通与未知、线路重试、重复乱序、历史缺口、权限隔离和故障恢复。该组用例目前全部待执行，不计入既有通过数量；最终验收必须有真实SIP、API、数据库及CDR对账证据。
|
||||
[主叫号码实时分析V1.2](CALLER_REALTIME_ANALYTICS_DESIGN.md)第10节及第13节定义CRA-001至CRA-034。2026-09-01已完成状态/公式/乱序/告警/查询契约的自动化回归（全量Vitest 29文件/118项），并以6通受控真实SIP完成180、183、直接失败、直接200、ACK后1.5秒/300ms通话、SDP/RTPEngine、真实API、MySQL状态/分钟桶、重放幂等和RBAC验收；Redis重启、毒事件死信、覆盖降级/恢复、维护任务及真实页面也已验证。结果见[整改交付报告](CALLER_REALTIME_ANALYTICS_DELIVERY_20260901.md)和[机器证据JSON](../tests/reports/caller-analytics-real-20260901.json)。未按约定峰值负载执行容量与页面端到端P95统计，因此CRA容量项保持“未执行/不作容量承诺”；真实多线路重试启用前仍须补做对应实际路由验收。
|
||||
|
||||
## 9. 缺陷分级
|
||||
|
||||
|
||||
Reference in New Issue
Block a user