北京
一个运行了数月的生产级自动化流程，某天早上突然只处理了50条客户记录，而平时这个数字是1万。剩下的9950人没收到付款提醒，两天后催收团队才发现——已经有人逾期了。
问题不在发送环节，在输入环节。上游系统出了bug，导出文件缩水了200倍，而自动化流程照单全收，没有任何拦截机制。
这是Salesforce Marketing Cloud（SFMC）用户的一个真实案例。解决方案是一个叫Verification Activity的功能，专门用来给数据量设一道安全闸。
Verification Activity只做一件事：检查数据扩展（Data Extension）的行数，如果不在预设范围内，就停止整个自动化流程。把它插在导入和发送之间，流程变成：导入文件→验证行数→通过才发送。验证失败时，后续步骤全部中止，同时向指定邮箱发送告警。
配置时需要设定上下限。这个银行案例里，付款提醒数据扩展的阈值设为8000到15000行。低于8000说明上游可能导出失败，高于15000则可能是数据重复或异常膨胀，两种情况都触发拦截。
阈值设定是个权衡。太紧会误伤正常波动——比如月末和月中客户量本就不同；太松又失去意义，"0到100万之间都接受"等于没设防。一个实用经验：取过去30天的实际行数最小值和最大值，各向外扩展25%作为缓冲。这样既能拦截灾难性故障（空文件、10倍膨胀），又不会因正常方差频繁告警。
告警接收方也有讲究。建议同时覆盖：客户方的业务团队（他们需要知道上游作业失败）、SFMC侧的技术负责人、以及一个共享邮箱或分发列表——单人邮箱会在休假时漏掉关键信息。Verification Activity的告警配置独立于自动化流程的运行完成通知，需要单独设置。
文件类自动化的故障模式其实高度可预测：上游作业报错导出零条或部分结果、时区计算错误导致重复加载昨日数据、表结构变更使导入活动读到空列、源系统在文件生成期间宕机。没有验证机制，流程会忠实地向所有成功导入的数据发送邮件，问题往往要事后才能暴露。
这个案例的教训很直接：任何依赖外部文件输入的自动化，都应该在行数层面设一道基本校验。不是相信上游永远正确，而是为"上游会出错"提前准备止损点。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
