feat: improve operations diagnostics and channel management
This commit is contained in:
hectorzhao
@@ -1688,10 +1688,10 @@
|
||||
|
||||
## 2026-07-24 CMPP/HTTP 通讯交互日志要求
|
||||
|
||||
1. 运营端“系统日志”必须将人员操作审计与协议通讯日志分成两个独立页签。通讯日志至少支持协议、交互方向、事件类型、结果、关键字和时间范围过滤，并展示平台消息号、上游消息号或HTTP请求号、脱敏对象、结果码、耗时和安全详情。
|
||||
1. 运营端“系统日志”必须将人员操作审计与协议通讯日志分成两个独立页签。通讯日志至少支持协议、交互方向、事件类型、结果、关键字和时间范围过滤，并展示平台消息号、上游消息号或HTTP请求号、完整手机号或账号、结果码、耗时和安全详情。
|
||||
2. CMPP应覆盖客户登录/Submit、供应商SubmitResp、状态报告Deliver、上行Deliver及平台下游投递；HTTP应覆盖客户发送请求和平台回执/上行Webhook。数据库中一条记录必须对应一个真实业务报文，不得把同一报文的“入口收到”和“处理成功”拆成两条记录；处理结果、结果码和耗时写在该报文同一条记录中，失败、重试等后续真实交互另行记录。
|
||||
3. Gateway收到状态报告或上行后，必须对解包/解码失败及转发NestJS失败输出结构化安全日志；NestJS入口把业务处理结果合并回同一报文记录，以便区分“上游未发”“Gateway未收到”“Gateway转发失败”和“API落库失败”。一条正常短短信的供应商侧完整成功闭环应依次展示四个真实报文：平台→通道 `CMPP_SUBMIT`、通道→平台 `CMPP_SUBMIT_RESP`、通道→平台 `CMPP_DELIVER`、平台→通道 `CMPP_DELIVER_RESP`；箭头只表达报文实际传输方向。
|
||||
4. 通讯日志不得保存短信正文、密码、密钥、Token、签名鉴权值或完整HTTP请求体；手机号只保存脱敏值。CMPP心跳不得逐包写入数据库，连接健康仍使用连接状态和聚合指标。
|
||||
4. 通讯日志不得保存短信正文、密码、密钥、Token、签名鉴权值或完整HTTP请求体；手机号按完整明文保存、展示并支持关键字查询，不做脱敏。CMPP心跳不得逐包写入数据库，连接健康仍使用连接状态和聚合指标。
|
||||
5. 通讯日志写入不能阻塞短信主链路，默认批量异步写入，缓冲区应有上限和溢出告警；热数据默认保留30天，保留期允许通过环境变量配置。
|
||||
6. 通讯日志方向固定使用“企业应用 → 平台、平台 → 供应商通道、供应商通道 → 平台、平台 → 企业应用”。供应商长短信每个真实 `SUBMIT` 和 `SUBMIT_RESP` 分片各记一条，企业应用每个真实 `SUBMIT_RESP` 也必须记录；内部 `submit-result` 聚合回调不是协议报文，不得重复生成通讯日志。
|
||||
7. 供应商长短信回执必须先写入对应 `SmsMessageSegmentAudit`。仅当同一提交尝试的全部分片均为 `delivered` 时，主记录才转 `delivered`；任一分片明确失败可进入最终失败/补发状态，分片尚未齐全时主记录保持 `submitted`，不得由首片成功提前聚合。内部业务终态只聚合一次，但对企业应用的CMPP状态报告必须按其原始Submit分片逐片投递，并分别使用平台当初为该分片返回的`CMPP_SUBMIT_RESP.Msg_Id`；HTTP Webhook仍按原HTTP消息投递一个最终事件。
|
||||
@@ -1890,7 +1890,7 @@
|
||||
|
||||
- 本期只识别、记录、查询和统计短信内容是否含引流信息。引流资料是否已报备、审核状态及报备进度均不得拦截或转人工审核；所有发送入口移除`DRAINAGE_NOT_APPROVED`决策，既有模板、签名、余额、黑名单和其他风控规则保持不变。
|
||||
- 运营端“系统管理”新增“引流识别规则”页面，规则存储在真实数据库，支持 URL、手机号码、固定电话三类表达式的新增、编辑、启停、优先级和测试。变更保留版本并写操作日志，发送入口按当前启用规则生成识别快照和规则版本。
|
||||
- URL 识别覆盖带协议链接、无`http://`的裸域名、短链接、IP 地址及端口/路径，并支持中文标点相邻、空格或中文句号拆分等规避写法；手机号码支持`+86`、空格、短横线和中文标点拆分；固定电话支持区号括号、分隔符和分机号。邮箱地址不属于引流信息。
|
||||
- URL 识别覆盖带协议链接、无`http://`的裸域名、短链接、IP 地址及端口/路径，并支持中文标点相邻和中文句号替代域名点号；URL遇到空格、制表符、换行或其他空白字符时必须立即结束，空白后的字符不得拼接进前一个链接，空白拆分的域名也不得恢复成一个URL。手机号码仍支持`+86`、空格、短横线和中文标点拆分；固定电话仍支持区号括号、分隔符和分机号。邮箱地址不属于引流信息。
|
||||
- 识别规范化只作用于检测副本，不得修改真实短信发送内容。消息记录持久化是否含引流、命中类型、原文位置、规则版本和检测时间；历史未检测数据保留为“未检测”，不得伪造为不含引流。
|
||||
- 运营端短信记录提供“是否含引流信息”筛选，支持含引流、不含引流和未检测；含引流记录使用提示色底色并高亮原文命中片段，CSV 同步导出该维度。
|
||||
- 数据统计的签名发送质量明细保留原“通道 × 运营商”整体矩阵，并提供按含引流、不含引流、未检测切分的矩阵视图；整体统计必须直接反映全部提交，不得用分组平均值替代。
|
||||
@@ -1915,3 +1915,58 @@
|
||||
- 已按整条级成功形成`delivered`终态后，如果同一提交尝试又收到明确失败回执，平台保留原始回执和分片审计，但不得自动把已送达终态改成失败、重复退款或向客户推送互相矛盾的失败结果；系统按稳定异常键写入`SmsReceiptAnomaly`，重复矛盾回执累加发生次数。
|
||||
- 运营菜单“Gateway提交异常”更名为“网关异常”，原路由保持兼容。页面使用“提交异常”和“回执异常”两个Tab，均查询真实后端和PostgreSQL；每个Tab必须在标题区说明其数据来源、业务含义、不能代表的结论及人工处理注意事项，避免运营人员间隔较久后误判。
|
||||
- “提交异常”展示Gateway消费提交命令连续失败且没有明确供应商提交结果的死信，可在严格确认未被供应商接收后重新入队；“回执异常”展示供应商回执与平台既有终态冲突的结构化异常判定。回执异常详情必须指明真实回执保存在回执记录、原始CMPP报文在通讯交互日志，不得用异常摘要替代原始证据。
|
||||
|
||||
## 运营端休眠唤醒与会话锁定恢复（2026-08-09）
|
||||
|
||||
- 同一单页应用内完成重新登录时，前端必须把本次成功登录视为新的用户活动起点，不得沿用上一会话或电脑休眠前的内存活动时间，避免新会话登录后被立即误锁。
|
||||
- 服务端返回`401/SESSION_LOCKED`或前端空闲计时触发锁定后，运营端必须同步暂停当前业务路由和全局待审核角标轮询；锁定期间不得继续请求短信记录、筛选项或`pending-audits`等受保护接口。
|
||||
- 全局角标轮询的启停必须跟随当前实时锁定状态，不得只读取布局首次挂载时的`session.locked`快照。浏览器重新获得焦点时，仅在会话处于解锁状态后才允许刷新待审核数量。
|
||||
- 密码解锁成功后恢复原路由并重新挂载页面，由真实后端重新读取短信记录和筛选项；不得用锁定前缓存、静态数据或localStorage伪造恢复后的业务数据。
|
||||
- 锁定、解锁和跨标签会话事件必须同时更新锁屏界面、业务路由暂停状态和全局轮询状态；重复事件应保持幂等，不得形成额外登录、短信发送或其他业务副作用。
|
||||
|
||||
## 签名删除预检与多通道报备汇总修正（2026-08-09）
|
||||
|
||||
- 签名删除预检中的“未结束报备任务”只统计仍需处理的过程态任务；`approved`、`completed`、`failed`、`cancelled`、`rejected`、`abandoned`、`partial`和`partial_success`均属于已结束历史，不得仅因这些任务存在而阻止删除。模板、引流信息等其他真实依赖仍按原删除治理规则阻止删除。
|
||||
- 签名及运营商报备汇总不得因单个目标通道失败就直接变为整体“报备失败”。全部当前目标通道通过时为“报备成功”；至少一个通过但尚未全部通过时为“部分成功”；没有通过且仍有其他目标待处理时为“报备中”；只有全部当前目标通道均为`failed/rejected`时才为整体“报备失败”。
|
||||
- 每个通道的失败事实、失败原因和历史报备记录必须继续保留并展示；汇总状态修正只改变整体归因，不得覆盖或删除通道级失败证据。
|
||||
|
||||
## 通道组删除风险展示与历史保留（2026-08-09）
|
||||
|
||||
- 运营端删除通道组前，必须通过真实后端和数据库统计并展示：关联正常企业应用数、关联已删除企业应用数、组内通道数、等待供应商提交结果数。企业应用按不同`applicationId`去重；状态不是`deleted`的现存应用计为正常应用，状态为`deleted`或应用记录已不存在的残留关联计为已删除应用。
|
||||
- “等待供应商提交结果”固定为该通道组下`SmsSubmitRecord.submitStatus = queued`的记录数，表示平台已选定该组但尚未收到供应商提交结果；该状态不按三个工作日自动完成，不能与最终回执超时口径混用。
|
||||
- 正常应用关联、已删除应用残留关联、组内通道和等待提交记录均只作风险展示，不得隐藏、禁用或阻止“确认删除”；弹窗不要求输入通道组名称，不要求填写删除原因，由运营查看真实影响后确认。
|
||||
- 删除采用逻辑删除，将通道组状态置为`deleted`并从通道组列表及新短信选路中排除；不得删除组内通道配置、企业应用关联、发送记录、回执或审计数据，确保历史查询、回执处理及上行接入号匹配仍可追溯。
|
||||
- 弹窗标题为“删除通道组：{通道组名称}”，正文依次展示上述四项真实数量，并明确：“删除后该通道组不再参与新短信发送，历史配置、发送、回执和审计数据继续保留。”操作仅保留“取消”和“确认删除”。
|
||||
|
||||
## 发送质量矩阵与成功率色阶统一（2026-08-09）
|
||||
|
||||
- 数据统计“签名通道发送质量”的明细抽屉中，“按引流切分”固定按每个通道三行展示，顺序为“含引流、 不含引流、未检测”；运营商固定为三列，顺序为“移动、联通、电信”。即使某个组合没有真实提交，也必须保留该行列并明确显示`0`，不得省略、错位或用空白代替。
|
||||
- 上述固定行列只改变真实统计结果的展示，不改变后端签名、通道、运营商、引流状态、提交量、送达结果和到达时间口径；整体统计页签继续展示全部真实提交。
|
||||
- 签名发送质量列表、明细抽屉、短信通道管理列表和通道报备详情中的成功率数字统一使用六档颜色：`0`为红色，`>0且<=25`为橙色，`>25且<=50`为黄色，`>50且<=75`为蓝色，`>75且<96`为绿色，`>=96`为深绿色。小数成功率必须按该连续边界归档。
|
||||
- 短信通道管理列表及通道报备详情中的提交失败、回执未知和送达失败比例与数量统一使用黑灰色，不因数值高低显示为红、橙或其他告警色；该展示规则不改变真实失败状态及统计值。
|
||||
|
||||
## 报表筛选结果全量汇总（2026-08-09）
|
||||
|
||||
- 对账单、利润报表和发送质量报表在每次搜索后都必须展示当前筛选条件匹配的全部结果汇总，不得只对当前分页明细在前端求和。汇总、总数、分页和CSV导出必须复用同一套日期、企业、应用、通道及统计维度筛选口径。
|
||||
- 三类报表均汇总提交、发送、未知、成功和失败条数；利润报表另汇总净消费、返还、成本和利润金额。综合成功率必须按合计成功量/合计发送量重算，综合利润率必须按合计利润/合计净消费重算，不得对每行百分比求和或简单平均；分母为0时显示0%。
|
||||
- 平均到达时长不属于可加总数据，本汇总区不对各日、各维度均值再求和；明细表仍保留每组的真实P95截尾平均到达时长。
|
||||
|
||||
## 新建企业省份与地市字典（2026-08-09）
|
||||
|
||||
- 运营端新建和编辑企业的省份、地市必须使用真实后端字典及级联关系，不得在页面写死少量省市选项。本版字典从PostgreSQL `PhoneSegment.province/city`中查询去重后的真实归属关系，与平台手机号段库保持一致。
|
||||
- 新增`GET /api/admin/dictionaries/administrative-regions`返回省份及其地市数组；前端选中省份后只展示该省真实地市，切换省份必须清空原地市。字典请求失败时必须明确报错，不得回退到Mock或静态列表。
|
||||
- 编辑历史企业时，若原省市值与当前号段字典格式不同或暂无对应项，页面仍必须保留并显示原值，不得因加载字典而静默清空已存档案。
|
||||
|
||||
## 运营端菜单与查询控件细节修正（2026-08-09）
|
||||
|
||||
- “风控规则”菜单归入“安全控制”业务域，并同步更新页面面包屑；路由、真实规则接口和数据库数据不变。
|
||||
- 发送监控页面的通道运营商必须显示中文名称，至少统一映射移动、联通、电信、三网和未识别；无法识别的新增值保留后端原值，避免隐藏真实数据。
|
||||
- “待生成报备批次”的两个页签标题固定为“待生成资料”和“已生成批次”，不在标题后展示括号及总数；真实后端分页总数仍用于分页，不改变待生成池和批次查询。
|
||||
- 短信记录的通道筛选使用平台通用可搜索下拉控件，选项来自真实通道接口，显示通道名称及已有通道编码，并向短信记录及导出接口传递精确`channelId`；不得使用静态列表、Mock或浏览器本地数据替代。
|
||||
|
||||
## CMPP客户连接请求诊断日志（2026-08-09）
|
||||
|
||||
- 每一次客户向平台发起的真实CMPP CONNECT尝试，无论账号是否存在、认证是否成功、IP白名单是否命中或应用是否启用，都必须同步写入`OperationLog`，动作使用`cmpp_connection.connect_requested`，并将TCP真实远端IP写入`ipAddress`；未知或恶意账号也必须以请求账号作为资源标识保留，不得因无法关联企业而丢弃。
|
||||
- 连接请求详情保存客户实际发送或由Gateway从报文解析的诊断参数，包括远端IP、`Source_Addr`账号、`AuthenticatorSource`、时间戳、协议版本及原始版本值，并保存认证结果、应用ID和失败原因。标准CMPP CONNECT不传输明文密码，页面必须明确说明这一事实，不得把平台配置的密码或密钥伪造成客户请求密码；仅兼容调用真实携带`password`字段时原样保存和展示该字段。
|
||||
- 上述连接请求日志必须在认证响应返回前持久化，日志写入失败时不得把未经审计的连接当作认证成功。系统与操作日志列表继续直接显示`ipAddress`，并为`cmpp_connection.connect_requested`提供“查看详情”按钮，展示上述结构化参数。
|
||||
- 供应商通道的既有连接操作日志仍保留；客户入站连接使用`cmpp_downstream_connection`资源区分方向。本功能不改变CMPP认证算法、IP白名单、最大连接数或客户连接状态。
|
||||
|
||||
Reference in New Issue
Block a user