工作流、事故防呆与协作
Category
production / config 子树。节点定位：把「这件事风险高」翻译成「这件事不容易被顺手做掉」——角色界面、变更分级、权限留痕、防呆与回滚演练。
Definition
复盘配置事故时会发现一个反复出现的模式：出错的动作，往往是流程允许任何人随时执行的。改一个影响全服经济的数值不需要审批，删一行数据没有二次确认，测试环境的入口对所有人开放。这类事故的根子不在能力，而在流程——系统没有把“这件事风险高”翻译成“这件事不容易被顺手做掉”。防呆设计的全部意义，就是把风险等级变成操作阻力。
配置管线的协作面比代码宽得多：策划、程序、运营、测试都在同一条链路上工作，节奏还比代码快。工作流要解决的不是“管住人”，而是让高频变更在缺少充分沟通的条件下依然安全。
Problem
配置事故的根子不在能力在流程：出错动作往往是流程允许任何人随时执行的——改全服经济数值不用审批、删行没有二次确认、测试入口对所有人开放。防呆的全部意义是把风险等级变成操作阻力；回滚要演练而不是备用。
角色与责任界面
配置链路上常见的角色分工，大致是内容编辑、结构维护、发布操作三种责任的组合。分工本身没有标准答案，容易出问题的是责任交界的模糊地带：
- 字段含义谁解释：策划填错常常是因为没人说得清字段的确切语义。
- 结构变更谁批准：加字段影响下游代码，却常常被当成纯策划侧的事。
- 发布谁授权：能编辑的人是否也能直接发布，两者不分离时风险敞口最大。
比较稳妥的做法是把交界处显式化：结构变更走代码侧评审，发布权限与编辑权限分离，字段语义由定义文件回答而不是靠人。责任界面清晰不等于流程变重，多数日常改动仍然走轻路径，只有跨过界面的那部分才进入重路径。
变更分级：不是所有改动都值得一样的流程
审批的意义在于让风险和摩擦相称，而不是一律设卡。一律设卡的结局通常是流程被绕开，反而失去约束力。常见的分级思路是按影响面和可逆性组合：
- 低风险：纯展示文案、不影响数值的编排，编辑后走自动校验即可发布。
- 中风险：普通数值调整，需要一次轻量确认和灰度观察。
- 高风险：涉及经济产出、付费概率、全服开关的改动，需要明确审批和发布窗口。
- 不可逆操作：删除数据、批量修正，通常要求备份先行和双人复核。
分级的价值在于让高频低险的改动保持流畅，把审核资源集中在真正危险的地方。判断一条改动属于哪级，可以在字段定义里声明，而不是每次靠人猜。
权限：谁能动哪张表
权限设计的朴素原则是最小够用，落到配置场景里通常拆成几个维度：
- 按表或按模块授权：负责活动的策划不直接编辑经济表。
- 按环境授权：线上环境的写权限远小于测试环境，且通常只授予发布角色。
- 按操作授权：编辑、审批、发布三种权限分离，至少高风险层级如此。
- 临时授权有期限：活动期间的临时扩权到期自动收回。
权限过松的直接后果是事故敞口大，过紧的后果是借权限成为常态——一旦“先借同事的账号改一下”被接受，权限体系就名存实亡。所以权限粒度要定期校准，让正常工作基本不需要借用。
留痕：排障时的第一手证据
配置出问题时，最常被问的四个问题是：谁改的、什么时候改的、改了什么、为什么改。回答不了这四个问题，排查就从工程活动退化成考古。留痕体系通常要覆盖：
- 每次编辑的作者、时间、字段级差异。
- 每次发布的批次内容、审批人、目标环境。
- 每次生效的加载记录：哪些进程在什么时间加载了哪个版本。
- 审批时的说明文字：为什么改，当时的判断依据是什么。
- 被拦截和被回滚的记录：失败的发布和成功的发布同样有复盘价值。
留痕的难点从来不是技术，而是坚持。说明文字最容易先被省略，而它恰恰是几个月后复盘时最有价值的信息。很多团队的做法是让说明成为提交的必填项，宁可写得短，也不留空白。
常见的防呆设计
防呆手段大多朴素，关键在于是否真的部署在操作路径上：
- 危险操作的二次确认，确认文案写清影响范围而不是一句“确定吗”。
- 发布前的 diff 预览，让操作者看见自己到底要发什么。
- 数值超限的强制理由：超出常规区间的值要求填写说明。
- 批量修改的先行预演：先给出将被影响的行清单，确认后再执行。
- 默认值兜底：缺失字段取安全默认值并告警，而不是加载失败或取零。
- 时间窗口收紧：高危操作只在有人值守的时段开放，深夜自动提高门槛。
防呆的判断标准很简单：如果一次误操作的受害者不是操作者本人，那这个操作就值得加阻力。受害者离操作者越远、越无法察觉，阻力应该越大。
回滚要演练而不是备用
回滚能力几乎每套系统都号称有，真正出事时能不能用，取决于三件事：回滚目标是否明确（回到哪个批次）、回滚路径是否干净（旧数据与新代码是否兼容）、回滚是否被演练过。常见的失效方式包括：
- 只保留了回滚按钮，没保留旧批次依赖的完整数据。
- 回滚路径平时没人走，真用时发现权限、流程、依赖处处卡壳。
- 回滚之后配置与已发生的玩家数据冲突，退回去也跑不平。
定期在测试环境演练一次完整回滚，成本不高，换来的是对“我们能退回去”这句话的真实信心。演练还会暴露一批平时看不见的问题，比如旧批次的导出产物早已被清理。
配置冻结与发布节奏
配置管线的节奏通常和版本节奏咬合：大版本前有冻结期，日常运营期保持高频通道。两个节奏的冲突是协作矛盾的常见来源：
- 冻结期内运营仍要调线上活动，需要区分“影响新版本的改动”和“只影响线上的改动”。
- 大版本上线的当天往往伴随密集配置发布，发布窗口和观察责任要提前排定。
- 节假日运营密集期，审批人不在岗导致发布积压，需要提前安排代理审批。
节奏问题的解法通常不是取消冻结，而是把冻结的颗粒度说清楚：冻结哪些表、放开哪些通道、例外怎么走。说不清的冻结，最后总会被现实打破。
从事故回到流程
每次配置事故都值得问一个问题：同样的误操作，下次怎样才能不被允许或更容易被发现。答案通常不是“下次小心”，而是往流程里加一层具体的东西：
- 加一条校验规则，让这类错误在编辑期就报出来。
- 加一道审批分级，让这类改动不再能静默发布。
- 加一项留痕，让这类问题发生后五分钟内能定位到批次。
防呆清单就是这样一条条长起来的。一个运营了两年的项目，如果它的防呆清单还是空的，通常不是运气好，而是事故没有被认真转化过。
常见误区
- 把所有改动塞进同一条审批流，高频低险的改动被拖垮，大家开始绕流程。
- 编辑、审批、发布权限混在同一批人手里，风险敞口失去制衡。
- 留痕只记操作不记理由，几个月后知道改了什么却不知道为什么。
- 回滚方案停留在文档里，从未演练，出事时才发现退不回去。
- 冻结期一刀切，被运营需求反复突破，冻结名存实亡。
工作流和防呆的本质，是承认高频变更下人的注意力和沟通带宽有限，然后让系统替人守住底线。守住底线的系统看起来处处是约束，真正跑起来时，它换来的是所有人敢快速行动的自由。
Used By
配置权限与审批流设计；变更分级（数值微调 vs 结构变更）；防呆清单（二次确认、冻结窗口、灰度下发）；回滚演练。
Related
关系链：责任界面 → 变更分级 → 权限与留痕 → 防呆 → 回滚演练。上游：config/03（校验拦住错的，防呆拦住危险的）。下游：production/06（发布工作流的配置切面）。
Reference
本页为工程经验归纳。