第468章 入口故障公开化与“卖便利”（1/2）

采集入口那次短时抖动，持续时间不到二十分钟。

按技术视角，这甚至不值得上升到“事故”：网络抖动、DNS解析、某台节点GC过高，任何一个都能解释。数科运维那边也给出了同样的说法：

“短时抖动，已恢复。”

但林远盯着的是另一件事——抖动之后，匿名入口立刻出现“我们有办法出M1”的话术。

抖动本身不吓人，抖动成为生意才吓人。

他对陈毅说：“从今天开始，入口不再只是技术组件，它是制度链条的一段。链条一段不透明，就会被卖成门票。”

陈毅点头：“所以你要把入口故障也制度化。”

“对。”林远在白板上写下四条，像给入口挂上公示牌：

故障必须有编号

故障必须有周报

故障期间补签有规则

卖‘出M1’一律视为干扰源

OPS-EVID-01：入口故障与补签规则

当晚，公共接口新增一份运行规则，编号很行政，但目的很简单：OPS-EVID-01｜采集入口可用性与补签规则（试行）。

规则核心三块：

1）故障编号（i_id）强制化

入口错误率＞5%持续5分钟 → 自动生成i_id

i_id包含：开始时间、结束时间、影响范围（地市/区县桶）、影响功能（采集/签名/验真）

i_id必须在SLA周报公开（不写内部IP、不写细节漏洞，只写结构）

2）故障期间“补签窗口”标准化

若M1采集在故障时间窗内完成离线摘要（本地生成），可在恢复后48小时内补绑定nonce并生成发生签名

补签必须携带i_id

超过窗口未补签 → 降级M0，不计入硬证据

3）离线发生包配额与统计

每个项目每周离线发生包使用次数有上限（默认10次，可申请提升但公开统计）

离线使用率过高会触发“网络条件/流程问题”整改工单

防止把离线当后门、把抖动当常态

“这三块把抖动从‘你信我’变成‘你看编号’。”林远说，“只要有编号，谁都没法靠抖动卖便利。”

银行何经理在群里回得很干脆：“i_id是关键。没有编号的故障，银行侧就会把整条链当不稳定输入。”

审计联络也补了一句：“故障公开+补签规则，才能避免‘事后补证’被卖成服务。”

卖便利怎么判？不抓嘴，抓行为

咨询总监又来了——这次他不谈“监控”，谈“服务”：

“林总，有些顾问说‘我们能帮出M1’，也许只是他们熟练流程，并不是插队或造假。你们一刀切判干扰，会不会误伤正常服务市场？”

林远没急着反驳。他只问了一句：“他们‘出M1’靠什么？靠教客户按RFC-022走流程，还是靠绕过流程？”

“当然是教流程。”咨询总监答得很快。

“那就让他把话术改掉。”林远说，“正常服务叫‘教你按流程做’，不叫‘我们能出M1’。‘能出’暗示的是：你不按流程也能出。我们判的不是嘴，是行为——如果出现大量M1集中在故障窗后补签、且来自同一服务商协作席，就不是熟练，是套利。”

陈毅把“便利套利”的判定模型投到屏幕上，像又一套反表演指标：

便利套利信号（venience Arbitrage）

同一服务商协作席在短时间内提交大量“补签M1”，且集中绑定同一个i_id

补签的M1与派单/到场链条缺失（仅有媒体签名，没有工单序列）

离线发生包使用率异常高，且集中在非真实信号差区域

本章未完，点击下一页继续阅读。