该自动发现的问题，不要靠人盯

01  /  先定对象

监控四类信号，不是盯着进度条

发布跑起来之后，最没用的动作是盯着进度条。进度条只告诉你程序在跑，不告诉你跑得对不对。真正需要监控的是四类信号，它们各自对应一种会出问题的地方。

四类信号里，第一类是结果，后三类是原因。只看第一类，你知道这一条没发出去，但不知道为什么；只看后三类，你知道有问题，但不知道影响了多少条。两类一起看，才能判断是偶发还是系统性问题。

还有一个容易被忽略的对象：节奏本身。今天发了几条、实际间隔是多少、有没有超出窗口。这些数据不体现在单条结果里，但它们是形态问题的来源。节奏偏了，单条结果往往还都是成功的，等到平台侧有反应时已经偏了几天。

监控的目标不是让人一直看着屏幕，而是让该发现的问题自动浮出来。所以这一页的重点在"看什么、多久看一次、异常怎么处理"，不在工具怎么配。工具侧的字段与记录口径见发布数据台账。

先把这四类信号在心里排个序：发布结果是每天都要看的，拦截原因是每批都要看的，平台状态是异常时才需要细看的，账号状态是每周主动查一次的。频次不一样，处理方式也不一样，这一点在第三节展开。

还有一个更基础的判断：监控系统本身要可靠。如果监控自己会漏报，那看与不看没有区别。验证办法是主动构造一次失败，看告警会不会响、台账会不会记。这个动作建议每月做一次，成本很低。

构造失败的方式可以很朴素：故意填一个会被合规拦下的标题，跑一条，看流程是否停下、是否留下记录、是否产生告警。三步都对，说明监控链路是通的。任何一步没反应，问题在监控侧，不在发布侧。

02  /  唯一口径

台账是唯一口径，其它数字都是参考

两条通道跑同一批计划，最怕的是各记各的账。手机通道一个文件、网页通道另一个文件，出了问题要人工对，对完还不知道哪份是对的。系统的做法是两条通道写同一本台账，由同一个写入模块处理，口径只有一套。

台账里每条记录至少包含这些字段，缺一项后面的核对就断一环。

这五个字段是核对的最小集。任何一项缺失，都会让某一道判断失去依据：没有标题算不出指纹，没有时间戳看不出节奏，没有 item_id 就打不开链接。补字段比补数据容易，所以字段要一开始就定全。

台账还有一个容易被破坏的地方：写入时的口径不一致。比如手机通道写的是本地时间，网页通道写的是服务器时间，两者的时间戳差几个小时，节奏核对就完全错了。同一本账意味着同一套时间基准、同一套字段定义、同一个写入入口，三样都要统一。

台账与实发必须一致。发布之后人工改过标题或价格，就要回写台账；不回写的话，台账记的是旧内容，后面所有的比对都是错的。这一类不一致最难查，因为两边看起来都正常，只是对不上。发现对不上时，先假定台账是错的，用平台上的实际内容去校。

写入失败也要被记录。台账写不进去的时候，很多实现会静默跳过，结果是一条商品发出去了但没有记录，事后完全查不到。正确做法是写入失败当成发布失败处理，重试或者标记异常，不要让"发出去了但没记上"这种情况悄悄发生。

台账还应该支持反查。给定一条商品或一个时间段，能立刻翻出当时的完整记录。反查能力决定了出问题时的定位速度，而这个能力取决于字段是否完整，不取决于用什么工具存。

03  /  看什么

多久看一次：日看结果、周看分布

监控的频次决定了你要花多少时间。频次定得太密，人会疲劳，看到异常也懒得处理；定得太疏，问题积累到不可收拾才发现。可按下面的频次安排。

日看的重点是"有没有断"。当天的条数明显少于计划，说明中间有环节停了；失败条数突然变多，说明某个条件变了。这两种都不需要立刻逐条查，先看失败原因的分类，一类占多数就查这一类。

周看的重点是"有没有偏"。类目占比、时段分布、同款条数，这三项是形态问题的主要来源。它们不会在单条结果里体现，只有拉长到一周才看得出来。占比畸高、时段挤在一段、同款逼近上限，任何一项出现就先减速，不要一边偏一边加。

频次不要随意提高。有人出了问题就把日看改成时时看，看两天累了又回到一周一次。频次不稳定，观察本身也变得不可比。定下来就按这个节奏走，需要临时加密的时候明确写清加密到什么时候结束。

还有一项建议每月做一次：随机抽五条已发布的商品，实际打开链接，核对标题、价格、图片与台账是否一致。抽样核对的成本很低，但能发现"记录正确、实际不符"这一类最难察觉的问题。

抽样的方法要随机。固定查最近五条，你会一直看到刚发的那几条；随机抽，才能覆盖不同时段、不同类目、不同批次。抽到的结果记一笔，全部对上也算信息，说明记录是可信的。

频次安排还有一个隐含前提：数据要能随手取到。如果看一次数要拼三个文件、对四张表，这个频次一定维持不下去。把常用的几个视图做出来，日看看一张，周看看一张，看的时候不需要再做加工。

日看和周看的顺序不要颠倒。日常没看，周看的分布就是残缺的，占比算出来不可信；周看不做，日看到的都是零散的单条，形不成判断。两者的关系是细看与粗看，缺一头都不完整。

04  /  分级

异常分三级，级别决定响应速度

所有异常都当紧急处理，结果是没有一件事被真正处理。分级的作用是把注意力分配到该去的地方，同时保证严重的问题不会因为不显眼而被漏掉。

分级的判断依据不是"看起来严重不严重"，是"影响范围有多大"。一条失败是三级，十条连续失败就是二级，因为连续失败说明某个共享条件坏了。同一件事的数量不同，级别就不同，这一点要在判断时明确。

每一级对应一个响应时限。一级是立即，二级是当批之内，三级是当天内。时限不是为了催人，是为了给"要不要现在处理"一个客观依据。没有时限的分级，最后都会变成"有空再看"。

恢复的动作也要分级。一级恢复要按判据走三条：能正常登录、测试提交能拿到回执、商品页能正常打开；二级恢复要先跑一条验证；三级恢复就是接着跑。恢复动作比异常处理更容易出错，因为人这时候急于回到正常。

分级的记录要留。每次异常记下级别、开始时间、处理动作、恢复时间。一个月后看这份记录，你会知道自己最常遇到哪一级，也就知道该把预防的力气花在哪。与账号相关的判断标准在防封实操里有更细的说明。

分级还有一个副作用值得利用：它把情绪隔开了。看到一条失败时，先给级别，再决定动作，中间那一步判断会让处理变得更冷静。没有分级的团队，遇到问题会一起停下来，遇到小问题也会停下来。

级别可以升级，但要写明依据。三级升二级的条件是连续出现，二级升一级的条件是涉及账号。有了明确的升级条件，判断就不用每次商量。

分级不需要复杂。三级就够，再多没人记得住。真正起作用的是升级条件写清楚了没有，而不是级别分得多细。想不清该归哪一级时，按影响面往高里判一次，代价只是多处理一遍。判低的代价要大得多，一次漏判可能让整批白跑。这个取舍在任何一级都成立。把这条写进规则里，判断就不用再犹豫。

05  /  告警设置

告警要少而准，吵一次就没人看了

告警的失败方式很统一：太多。第一条告警有人看，第十条有人扫一眼，第五十条就没人看了。所以设置告警的第一原则是少，第二原则是准，第三原则才是快。

按这个原则，真正需要立即告警的其实不多：一级异常、二级异常的开始、以及连续失败。其余的都进台账，按频次去看。这样做的好处是，告警响的时候你知道一定有事，不会先怀疑是不是误报。

告警内容要带够定位信息：哪一条、什么时间、什么原因、影响多少条。只报"发布失败"的告警等于没报，因为你还得自己去查是哪条、为什么。告警的价值在于把定位成本前置，不在通知这个动作本身。

还有一条与告警无关但同样重要：告警要有出口。收到告警之后做什么，要写清楚。没有出口的告警会变成一种噪音，收到之后看一眼、关掉，下次还是一样。每一个告警都应该对应一条处置动作，动作写在告警旁边。

告警的渠道也要固定。换渠道的成本比想象中大：人习惯了在一个地方看，换到另一个地方就会漏。固定一个入口，所有异常都往那里去，看的时候不需要回忆"上次那个是不是发到别处了"。

每周回看一次告警本身。这周响了几次、几次是真的需要动作、有没有误报。误报多的规则就收紧，漏报的规则就补上。告警规则和节奏参数一样，是需要定期校准的东西，不是设一次就完事。

06  /  排查顺序

单条失败：六步查下去，不要乱试

单条失败是最常见的异常，也是最容易处理过头的。正确的做法是按固定顺序查，每步只排除一种可能，查到哪一步为止。

六步里最容易跳过的是第二步。很多人一看失败就直接改代码或改选择器，改完再跑，跑通了也不知道原来为什么失败。留着界面树和截图不看，等于把最直接的证据扔掉。

第三步有一个具体的坑值得一提：界面树在 launcher 屏取不到，需要先试压缩模式再退回普通模式。如果不了解这一点，会误判成选择器写错了，然后去改一个本来没问题的选择器。类似的实现细节在手机 APP 自动化通道里有说明。

第六步要克制。改一处、跑一次、看结果，这个循环慢但可靠。一次改五处、跑一次、碰巧成功，看起来快，实际上把问题藏起来了，下次它以另一种形式出现，你还是要重查一遍。

六步之中，第四步的判断最容易被跳过，因为它需要看拦截原因而不是看错误信息。流程报的是"提交被拒"，拦截原因写在闸门的输出里，两处不在同一个地方。找不到原因时，先去闸门的输出里找，不要在流程日志里反复翻。

排查记录也值得留。同样是"定位不到提交按钮"，第一次查了两个小时，第二次应该十分钟。差别就在有没有把上一次的结论写下来。这类经验不写就丢，写了才积累。

07  /  数据对不上

数字对不上时：先怀疑记录，再怀疑执行

监控做到一定程度会遇到一类麻烦：台账里记的和平台上看到的不一致。这时候的处理顺序很关键，顺序反了会白忙半天。

先怀疑记录，不是怀疑执行。记录出问题的概率比执行高，因为记录涉及路径、权限、编码、并发写入这些环节，每一环都可能悄悄出错。执行出问题通常有明确的现象，记录出问题往往什么都没有，只是数字不对。

• 路径对不对写入的目录是不是你以为的那个。程序的工作目录与配置里的相对路径不一致时，文件会写到别处，读的时候读到旧文件
• 环境变量生效顺序路径解析如果早于环境变量加载，读到的就是默认值。这类问题在本地跑正常、换一台机器就出偏差
• 有没有并发写两条通道同时写同一本账，没有加锁时会互相覆盖，表现为条数少了几条
• 时间基准是否一致本地时间与服务器时间混用，时间戳会整体偏移，节奏核对全错
• 编码是否统一编码不一致会让中文标题变成乱码，指纹计算随之出错
• 是不是自检数据混进来了测试跑批如果写进了生产记录，台账里会多出并不存在的条目

最后一条是真实踩过的坑：自检曾经污染了生产发布记录，根因是路径解析早于环境变量生效，自检写到了生产文件上。之后的处理有三条：写生产数据前先留一份备份；自检进程带标记时向生产写入直接抛错；整轮自检前后对生产文件做哈希比对。三条加在一起，同类问题再没发生过。

这几条经验可以直接借用。凡是"程序自己验证自己"的场景，都要防止验证数据进入生产记录。做法不复杂：写入前判断当前进程的身份，验证进程直接拒绝写生产；写入前留备份，出问题能回到上一个状态；关键文件在操作前后算哈希，不一致就报警。

如果记录侧全部排除，才开始查执行侧。查执行侧的顺序是：看当批日志、看平台实际内容、看是否有重试、看重试是否产生了重复提交。重复提交在台账里表现为同一条商品有两个 item_id，这一类问题要靠指纹去重挡住，不能靠事后清理。

还有一类对不上是时间造成的。台账按写入时刻记，平台按上架时刻显示，两者之间隔着审核与展示延迟，几分钟到几小时都可能。看到"台账有、平台没有"时，先看时间差，不要立刻当成丢失。超过半天还对不上的，才需要按上面的顺序排查。

排查数据问题时，建议先把两侧的原始数据各导出一份，冻结下来再比对。边查边看平台页面，内容会变，比对的前提就不稳了。冻结之后逐行对，差异会自己浮出来，不需要猜。

08  /  周复盘

每周半小时，产出三行结论

监控的目的不是记录，是让下一周比这一周稳。所以每周要有一个收口动作，把看到的东西压成几条能执行的结论。

复盘只看四组数：发了多少条、成功多少条、被拦的原因分布、账号与平台有没有异常。四组数看完，回答三个问题：这周有没有不该出现的失败、失败集中在哪一类、下周要改哪一处。三个问题的答案就是复盘产出，不需要长篇报告。

复盘要落到一个改动上。列了五条待改，等于一条都不改；只留一条，下周才有验证的可能。选哪一条的标准是：改动成本最低、影响面最大。通常这个位置在节奏参数或措辞模板上，不在流程代码里。

结论要能验证。写下"把每日条数从八条降到六条"，下周就能看出失败有没有减少；写下"注意合规"，下周什么也看不出来。可验证的结论都有一个共同点：带具体参数，且下周能被复现。

复盘记录建议和台账放一起，按月归档。三个月后回看，你会看到自己的判断标准是怎么一步步收紧的，这比任何总结都实用。至于具体改哪一处，取决于你卡在哪：节奏问题看发布节奏控制，措辞问题看商品合规检查，账号问题看防封控。

最后一点：复盘不要变成追责。追责的结果是没人愿意记录真实数据，台账失真，监控失效。复盘的对象是规则和参数，不是人。规则改了，同类问题才会真的少。

复盘的产出建议存档而不是只发在群里。发在群里的结论第二天就沉了，存档的结论三个月后还能查。存的地方和台账相邻，回看时不用找。

如果连续几周的复盘结论都是"没有问题"，那要么是监控太粗，要么是数据没看全。稳定的状态也会有小波动，只是不构成问题；一次都看不出波动的，通常是观察的颗粒度太粗，需要把指标拆细一点再看。