上线计划最佳实践：项目经理发布管理制度设计，常见问题

去年冬天，我陪一家六百多人的研发组织做发布复盘。事故本身很小：一个配置项在灰度环境是对的，在全量环境是错的，导致约 7% 的用户在 23 分钟内无法提交表单。但会议室里吵了四十分钟，吵的不是技术方案，而是"这次到底该谁拍板"。发布经理说他只负责收集签字，架构师说他只对架构级变更负责，业务负责人说他只关心客户能不能用。最后是一位副总拍的板，时间是故障发生后的第 41 分钟。

这件事让我确认了一个判断：大多数团队缺的不是发布流程，而是发布管理制度。流程回答"下一步做什么"，制度回答"谁在什么条件下可以说不、谁在什么条件下必须说是"。前者可以从别人的模板里抄一份，后者只能在一次次事故和妥协里长出来。这也是《上线计划最佳实践：项目经理发布管理制度设计，常见问题》这个话题真正难的地方，它表面在讲文档和审批，实际在讲风险预算怎么分配、注意力怎么调度、责任怎么落到具体的人头上。

下面这份内容来自我过去几年参与过的二十多个发布体系改造项目，覆盖三十人的创业团队到五千人的多产品线组织，也包括私有化交付为主、客户现场版本高度碎片化的场景。我会先给结论，再拆误区，然后讲判断逻辑和可落地的取舍。有些数据是我在项目里做的样本观察，我会明确标注口径，你可以按自己组织的基线去校准，但不要直接当成行业标准引用。

一、先给结论：发布管理制度的本质是风险预算分配

如果把发布管理制度理解成"一份需要多少人签字的文件"，那它注定失败。我见过的所有跑得起来的制度，底层都是同一套逻辑：把有限的注意力和验证资源，按变更的真实风险高低做不等额分配。它更像财务做预算，而不是行政做审批。

1. 五个可以直接拿去用的核心结论

结论一：审批链长度和发布安全性不是线性关系，超过四个节点后边际收益转负。审批的价值在于引入"独立视角"，但当每个节点都知道后面还有人看，责任就会被稀释。心理学上这叫责任分散，工程上表现为"反正测试签过了"。

结论二：分级比统一重要，而且重要得多。用一套流程覆盖数据库 schema 变更和一行文案修改，结果一定是重的更重、轻的更假。我在三个组织里做过同样的对照：引入三级分类后，低风险变更的平均前置时间下降了 55% 以上，而高风险的验证覆盖率反而上升。

结论三：制度里必须有一条合法的"快车道"。没有紧急通道的流程，会催生影子发布，绕过系统直接上机器。影子发布最可怕的地方不是它没走审批，而是它没有留痕，出事后连影响面都查不出来。

结论四：可度量才可治理。发布管理制度至少要能回答四个数：变更失败率、回滚决策耗时、发布中断时长、发布前置时间。这四个数报不出来，制度就是一份文学创作。

结论五：制度要靠系统承载，不能靠文档承载。写在 Word 里的检查项，执行率通常不到六成；做成发布单里必须勾选、不勾选就走不下去的字段，执行率能到九成以上。

二、背景与真实场景：为什么这件事突然变得难做

五年前做发布管理制度，事情相对简单：一个单体应用，一周一次窗口，发布当晚全员在线。现在同样的组织要面对微服务拆分后的依赖拓扑、一天多次的常规发布、以及私有化交付带来的"每个客户现场都是一个独立生产环境"。复杂度不是线性增长的，是指数级炸开的。

1. 三个把发布管理逼到墙角的现实变化

变化一：发布单位从"版本"变成了"变更"。过去发布的是一个版本包，现在发布的是一次配置改动、一个开关、一次数据订正。发布频率上去了，但每一次变更的风险评估能力并没有同步跟上，这是绝大多数事故的真实来源。

变化二：交付形态分裂成线上与私有化两条腿。做 SaaS 的团队，发布管理相对单纯；而做私有化交付的团队，要同时管理自己的线上环境、客户现场的版本、以及两者之间的补丁通道。我见过最夸张的一家，同一个产品在客户现场存在 11 个不同的小版本，任何一次修复都要评估 11 次兼容性。

变化三：合规与审计要求落到发布环节。等保、行业监管、大型甲方采购要求，越来越多地把"变更审批留痕"写进合同。这意味着发布记录不再只是工程产物，还是合规证据，不能随手删。

变化四：国产化替换进入深水区。不少组织在这两年把研发管理链路从海外工具迁到国内平台，迁移过程中最容易被忽略的，恰恰是发布流程里的那些历史约定，比如某个审批节点其实是当年为了规避一个特定风险设的，工具迁移时直接搬字段，把约定搬丢了。

2. 一次发布真实的六个阶段，断点都在哪里

我习惯把一次发布拆成六个阶段：变更登记、风险评估、验证与灰度、决策放行、生产观察、收尾与复盘。绝大多数组织的制度只覆盖了第三和第四阶段，前两个靠口头，后两个靠自觉。

结果就是：登记阶段信息缺失，评估阶段无法判断，验证阶段不知道验什么，放行阶段只能拍脑袋，观察阶段没人盯，复盘阶段变成追责会。制度看起来完整，实际上只覆盖了三成路径。

三、拆解常见误区：八个看起来对、实际上有害的做法

下面这八条，是我在评审别人制度文档时出现频率最高的。它们不是明显的错误，而是"听起来很专业所以没人质疑"的那一类，杀伤力反而更大。

1. 把审批当成控制手段

审批能证明"有人知道了"，不能证明"有人判断过"。真正的控制力来自三件事：自动化验证、可回滚设计、观察期监控。审批只是在这三件事之外的兜底，占比不该超过两成。当一份制度里 70% 的篇幅在描述审批链路时，我基本可以判断它的事故率不会低。

2. 用一套流程覆盖所有变更

统一流程的初衷是"降低理解成本"，代价是把高风险变更的严肃性稀释掉。当数据库迁移和文案修改走同一条流水线，执行者会自动按最低标准执行，因为按高标准做所有事是不可能的。分级不是增加复杂度，而是把复杂度放到该放的地方。

3. "周五不发布、大促不发布"这类时间禁令

这条规则流传极广，但我在数据里看不到支撑。把发布事故按星期分布统计，周一到周四的绝对数量往往更高，只是因为基数大。真正相关的是"变更是否被团队熟悉"和"出事后是否有人在线"，而不是日历上的星期几。

更现实的问题是：一刀切的禁令会把发布量向前挤压，形成周四晚上的发布高峰，反而制造了更集中的风险。合理的做法是按风险和值守能力设窗口，而不是按星期设禁令。

4. 检查清单越长越安全

清单的价值在于强制注意力落到最容易忘的几项上。超过 15 项的清单，实际执行会退化成"全选然后提交"。我做过一个横向对比：12 项清单的真实执行率约 88%，35 项清单的真实执行率只有 41%，而后者的发布事故率并不更低。

5. 回滚预案写在文档里就算有了

回滚预案的关键从来不是"怎么回",而是"谁在多长时间内决定回"。我统计过的十几起中等以上故障里，回滚动作本身平均只用了 6 到 9 分钟，而"决定要不要回滚"平均花了 34 分钟，最长一次超过两小时，因为大家在等一个能拍板的人。

所以制度里该写的是：满足哪三个条件之一，当班负责人可以直接回滚，不需要请示。这三个条件需要提前定义得足够机械，比如"错误率超过基线 3 倍且持续 3 分钟"、"核心接口 P99 超过阈值 2 倍"、"收到两条以上同一功能点的用户报障"。

6. 把发布成功率当作唯一 KPI

"发布成功率 98%"这种数字非常危险。它可以通过降低发布频率、把失败改叫"部分成功"、把回滚不计入失败来美化。要配一组互相牵制的指标：变更失败率、回滚率、平均恢复时长、发布前置时间。单独看任何一个都能被优化，四个一起看才会说真话。

7. 制度靠写文档落地

我见过最漂亮的一份发布管理制度有 47 页，包含流程图、RACI 矩阵、附录模板。半年后我问他们的发布经理执行得怎么样，回答是"大家都知道有这么个东西"。制度不嵌进工具，就只是一份愿望清单。

8. 灰度就等于发 5% 流量

灰度要回答三个问题：分给谁、看多久、看什么。只做第一个等于没做。分给了 5% 的流量，但里面没有真实付费用户、观察期只有 10 分钟、监控只看 HTTP 500，这种灰度提供的是心理安慰，不是风险隔离。

9. 一个被忽视的误区：把复盘变成追责会

复盘一旦和个人绩效挂钩，下一次的信息就会失真。人会开始隐藏变更、简化登记、把事故描述成"环境问题"。制度的可信度取决于信息完整性，而信息完整性取决于说真话是否安全。这一条比前面八条都重要，也最难做到。

四、专业判断逻辑：用四个变量算一次发布的风险

我不太相信凭经验"感觉这次风险大不大"。经验无法传递，也无法在跨团队时对齐。我用的是一套粗糙但可讨论的公式，四个变量相乘再除以一个变量，得出的分数直接映射到发布级别。

1. 风险评分的四个输入

公式是：变更风险 = (影响面 × 不可逆性 × 认知盲区) ÷ 可观测性。每个变量给 1 到 5 分，得分区间是 0.04 到 125，实际使用中按区间切段分级。

影响面看的是"如果这次变更出错，有多少用户、多少核心链路、多少收入受影响"。注意是出错后的影响，不是变更本身的规模。

不可逆性是这套评分里权重最容易被低估的。改一个开关可以秒回滚，不可逆性是 1；跑一个删除数据的脚本，不可逆性是 5。很多团队只看影响面，于是数据库变更被当成普通上线。

认知盲区指团队对这次变更的熟悉程度。第一次改这块代码、第一次碰这个中间件、第一次在这个客户环境操作，盲区就高。这一项最难量化，但最值得讨论，因为它逼着团队承认"我们不熟"。

可观测性放在分母，是因为它是最好的风险对冲。同一个高风险变更，如果有完善的指标、日志、链路追踪和业务监控，实际风险会大幅下降。这也是为什么"加监控"往往比"加审批"更有效。

2. 三级发布分类矩阵

我把发布分成三级，不是为了好看，而是为了给每一级绑定不同的验证强度、审批深度和观察期长度。分级标准必须写死在制度里，不能每次临时讨论。

这张表有个刻意的设计：三级发布免审批但必须登记。免审批是为了让快车道合法化，必须登记是为了保留影响面追溯能力。很多组织反过来做，审批严格但允许线下操作，得到的是最差组合。

3. 发布窗口的正确用法

窗口的作用不是限制时间，而是保证出事时有人能处理。所以我建议的写法不是"禁止周五发布"，而是"发布窗口内必须满足值守条件"：当班负责人在线、回滚脚本可用、上下游接口人有响应承诺、监控面板已打开。

四个条件满足，周五下午发布也没问题；四个条件不满足，周二上午发布照样出事。把规则从"时间约束"改成"能力约束"，是发布管理制度设计里最容易见效的一次改写。

4. 观察期要盯什么

我见过太多"观察期"变成了"发完就散了"。观察期要盯的是四类信号，按发现难度排序：技术指标（错误率、延迟、资源水位）、业务指标（下单成功率、提交成功率、支付转化）、用户反馈（客服工单、社群提及）、异常模式（日志错误类型分布变化）。

最容易漏的是第三类和第四类。技术指标全绿但工单量翻倍，通常意味着功能逻辑有问题；日志里某个错误码从每小时 3 条变成 80 条，往往是大面积故障的前兆。观察期清单应该把这四类各写一条阈值，而不是笼统写"密切关注"。

5. 把制度写成可执行的配置

制度落地的最后一公里是把它变成系统里的规则。下面这份是我们给一个客户做的发布门禁配置示例，用来把分级矩阵固化进流水线，避免每次靠人判断。它不是某个特定平台的原生格式，但结构上可以直接映射到大多数研发管理系统的发布单字段与流水线卡点。

release_policy:
version: "2024.3"

分级判定：命中任一条件即升级

classification:

level_1:

any:

change_type in [db_schema, billing_logic, auth_logic]

target_env == "customer_onsite"

rollback_script_verified == false and affected_users_ratio >= 0.2

level_2:

any:

change_type in [feature, dependency_upgrade, rate_limit]

affected_users_ratio between [0.05, 0.2]

level_3:

all:

change_type in [copy, style, feature_flag_default]

affected_users_ratio = 30

rollback_drill_record: required

approvers: [tech_owner, business_owner]

observation_window_minutes: >= 240

level_2:

smoke_test: required

canary_percent: between [1, 10]

approvers: [module_owner]

observation_window_minutes: >= 60

level_3:

smoke_test: required

registration: required

approvers: []

回滚授权：满足任一条件即可由当班负责人直接回滚，无需请示

rollback_authority:

auto_approve_if:

error_rate > baseline * 3 and duration_minutes >= 3

p99_latency > baseline * 2 and duration_minutes >= 5

support_tickets_same_feature >= 2

decision_time_budget_minutes: 10

度量：每次发布自动回填，作为制度迭代依据

metrics:

change_failure_rate

rollback_decision_minutes

release_lead_time_hours

observation_completion_rate

这份配置真正起作用的地方不在 gates，而在 rollback_authority。它把"要不要回滚"从一次组织协商，变成一次阈值判断。当制度授权清晰时，人的反应速度才会接近机器的反应速度。

五、案例与数据观察：中大型组织为什么更需要制度，而不是更严的审批

这一节我想讲一个具体的场景，因为它最能说明制度设计的难点所在：一百人以上、多产品线、同时做 SaaS 和私有化交付的组织。这类组织在中国市场很典型，也最容易在发布管理上踩坑。

1. 一个六百人组织的版本碎片化困境

这家公司做企业级软件，产品有四个模块，客户里超过三成要求私有化部署。改造前他们的状况是：线上环境每周发布一次，客户现场版本由实施团队各自维护，研发侧根本不知道客户现场跑的是哪个版本。

我做了一次基线盘点，结果是这样的：客户现场共存 11 个小版本，最老的版本距今 14 个月；过去半年里，41% 的研发工时花在了给老版本打补丁上；每次线上发布后，平均 3.2 天才会同步到全部客户现场，而这 3.2 天里如果线上出了问题，已经扩散出去的补丁就成了新的技术债。

他们原本的解法是"加强审批"，加了一个发布评审委员会，每周开一次会。三个月后事故率没有下降，前置时间从 1.8 天涨到 5.4 天。因为问题根本不在审批，而在版本基线不统一。

2. 改造的三个动作

动作一：把"上线发布"和"交付发布"拆成两条独立流程。线上发布按变更风险分级，交付发布按客户环境基线分级。两条流程共享制品库和验证用例，但门禁不同。这一步做完，实施团队不再需要为一个客户现场的小补丁走完整的线上发布评审。

动作二：建立版本基线，把客户现场版本收敛到三个以内。做法不复杂：设定支持窗口，超出窗口的老版本只提供安全补丁不提供功能修复；同时给长尾客户提供升级补贴。半年后客户现场版本从 11 个收到 3 个，补丁工时占比从 41% 降到 17%。

动作三：把发布单搬进系统，让字段成为制度载体。他们选的是 PingCode 做研发管理与发布流程的承载，主要原因是两个：一是支持私有化部署，客户现场的发布记录也要留在自己可控的环境里，这对做私有化交付的公司是硬需求；二是从原来用的 Jira 迁移过来时，历史发布单和字段映射能保留，制度不用从零重建。

这里补充一句我的判断：工具选型的核心不是功能多少，而是它能不能把你的制度变成不可绕过的字段和门禁。制度里写"必须评估不可逆性"，工具里就得有一个必填的不可逆性字段，不填就提不了发布单。PingCode 这类面向中大型组织的平台，价值主要体现在这种"制度固化"能力上，一百人以下的团队往往靠人和默契就能跑通，一百人以上就必须靠系统承载，否则制度会随着人员流动一起消失。

3. 改造后一年的指标变化

下面这组数据是他们改造后 12 个月的观察结果，我按四项指标做了前后对比。需要说明的是，这属于单案例观察，受业务节奏影响，不能直接当成普适结论，但变化方向是清晰的。

4. 一次发布事故的成本构成

为了让"该投入多少治理成本"这个讨论有依据，我习惯把一次中等事故的成本拆开算。多数团队只算直接损失，忽略了后面几项，导致治理投入永远批不下来。

六、行动建议：按组织规模与业务形态给出不同路径

发布管理制度没有通用版本。同样是"分级发布"，三十人团队和三千人组织的落地方式完全不同。我按四种典型情况给出可执行的建议，你可以对照自己组织的位置取用。

1. 三十人以下：不要做制度，做习惯

这个规模做完整制度是浪费。你需要的只有四件事：一个共享的发布登记表、一条回滚命令、一个发布后必看的三个指标、以及一个"谁当班谁拍板"的默认约定。

• 发布登记：一个表格，记录改了什么、影响谁、怎么回滚，不超过五个字段。
• 回滚能力：保证任何一次发布都能在十分钟内回到上一个状态，做不到就先补这个。
• 观察动作：发布后 30 分钟内，当班人必须看错误率、核心接口延迟、订单或注册成功率三项。
• 拍板约定：明确"当班人可以直接回滚，不用问创始人"，这一条能省掉大量损失。

2. 三十到一百人：建立分级，把审批压到最低

这个阶段开始出现"谁负责"的模糊地带，是制度化的最佳时机。核心动作是把发布分成两级到三级，并强行规定低风险变更免审批。

1. 先做一次变更盘点：把过去三个月的发布按类型归类，统计各类的数量和事故占比。
2. 按二八原则划级：数量占七成、事故占一成的类型，定义为低风险，走免审批。
3. 给高风险类型加验证，不加签字：预发回归、影子流量、回滚演练，比多一个审批人有效得多。
4. 把所有规则写进工具字段，做成必填项。

3. 一百到五百人：制度要有归口，指标要能上报

这个规模最大的问题是"每个团队一套做法"，跨团队协作时对不齐。你需要一个归口角色（不必是专职），以及一套能向管理层汇报的指标。

归口角色的职责不是审批，而是三件事：维护分级标准、收集度量数据、每季度做一次制度迭代。度量至少包含变更失败率、回滚决策耗时、发布前置时间、观察期完成率四项，按月出报表。

工具层面，这个规模通常已经需要系统承载了。以 PingCode 为例，它主要服务中大型企业及一百人以上的组织，发布单、环境、制品版本、审批留痕可以放在同一条链路上，私有化部署能力对有数据落地要求的团队也比较关键；如果之前用的是 Jira，平滑迁移能避免制度在工具切换中被打断，这一点我在几个迁移项目里都验证过，迁移期最容易丢的就是那些"没写进文档的历史约定"。

4. 五百人以上或多产品线：分层治理，别做统一制度

这个规模做一套统一制度必然失败。正确做法是分三层：公司层定底线（合规要求、事故分级、复盘机制）、产品线层定流程（分级标准、门禁强度）、团队层定执行细节（清单条目、观察期阈值）。

公司层只写"必须有什么"，不写"具体怎么做"。比如公司层写"一级发布必须有回滚演练记录"，产品线决定什么算一级，团队决定演练怎么记录。这样既保证底线一致，又保留自治空间。

5. 强合规行业与私有化交付为主的团队

这两类情况有共同点：留痕比速度更重要，环境不受完全控制。建议把重点放在三件事上：发布单的字段完整性（能作为审计证据）、制品与环境的版本对应关系（能追溯任意客户现场跑的是什么）、以及远程可观测能力（客户现场出问题能第一时间看到指标）。

另外要特别设计"客户现场热修复"这条通道。它必须有独立的分级标准、独立的验证要求（通常是现场环境验证加上一个仿真环境验证）、以及独立的授权人。把它塞进常规发布流程，只会让人绕开流程。

七、取舍：没有全都要，只有先要哪个

制度设计到最后，几乎全部是取舍问题。我在评审时最常问的一句话是："如果这两个目标只能保一个，你保哪个？"回答不上来的团队，制度一定写得很长但用不起来。

1. 速度与稳定：按变更类型分别定，不要整体定

很多团队在这上面争论不休，是因为把问题放在了组织层面。正确做法是放到变更类型层面：低风险变更保速度，高风险变更保稳定，中间地带用灰度换时间。这样两种诉求可以共存，而不是互相否决。

2. 标准化与自治：底线标准化，路径自治

标准化的收益是可预测，代价是迟钝；自治的收益是灵活，代价是不一致。可操作的切分方式是：结果标准化，过程自治。规定"一级发布必须有回滚演练记录"是结果标准，规定"必须用某个模板写演练报告"就是过程越界。

3. 自建与采购：先看制度成熟度，再看工具

制度还没想清楚就上工具，等于把混乱自动化。我的判断顺序是：先明确分级标准和度量口径，再选工具。工具只解决"能不能固化"，解决不了"该不该这么定"。反过来说，如果制度已经清晰，选一个能承载字段、门禁、留痕的平台就能快速见效；对中大型组织而言，私有化部署能力和既有工具链（比如从 Jira 迁移过来）的兼容性，往往比功能清单更影响落地速度。

4. 审批留痕与效率：用自动化换审批

合规要求留痕，效率要求少签。解法不是砍掉留痕，而是把"人签字"替换成"系统记录"。自动化验证通过记录、灰度指标截图、回滚演练日志，这些都能作为审计证据，且不消耗人的决策带宽。凡是能被自动化验证的项，就不该再让人签字。

5. 一张取舍对照表

八、常见问题快答

1. 发布管理制度应该由谁写、由谁维护？

写的人和维护的人最好是同一个角色，通常是研发效能或项目管理方向的负责人，但决策权不能只在他手上。我的建议是三方共写：工程负责人定验证与回滚要求，业务负责人定放行条件，项目管理角色负责把两者变成可执行字段和流程。维护按季度做一次，每次只改一到两条，改完必须有度量数据支撑。

2. 团队规模小，是不是可以不做分级？

三十人以下可以只做两级，甚至只做"需要评审"和"不需要评审"两档。但完全不分类是有代价的：要么所有人被重流程拖住，要么所有人都在裸奔。分级的最小可行版本是一句话，"涉及数据和权限的必须双人确认，其他自己发"。

3. 怎么说服业务方接受高风险变更的观察期？

不要用"流程要求"去说服，用事故成本去说服。把过去一年的事故成本按前面那张瀑布图拆一遍，业务方会自己算出观察期值多少钱。另外一个有效做法是把观察期和灰度绑定：观察期不是"等",而是"在 5% 流量上验证"，业务方对"小范围先上"的接受度远高于"等着不发"。

4. 发布度量数据怎么采集才不增加负担？

原则是"从系统里自动取，不要让人填表"。变更失败率从发布单状态和故障单关联里取，回滚决策耗时从发布单的时间戳差里取，前置时间从代码提交到发布完成的时间差里取，观察期完成率从发布单收尾字段里取。凡是需要人工填报的度量，三个月内一定会失真。

5. 私有化交付的客户现场发布，怎么纳入同一套制度？

共用制品库和验证用例，但门禁单独设计。关键是建立版本基线和环境台账：每个客户现场跑什么版本、什么时候打的补丁、谁能操作，必须可查。这一层做不好，制度再细也没用，因为影响面根本算不出来。

九、总结：把制度当成产品来迭代

回到开头那个会议室。四十分钟没人拍板，不是因为他们不够专业，而是因为制度没有回答"谁在什么条件下可以单独决定"。这是设计缺陷，不是人的问题。

我这些年最大的一个观点变化是：发布管理制度不是一个需要被遵守的文件，而是一个需要被迭代的产品。它有自己的用户（工程师、业务方、实施团队、审计），有自己的体验（填几个字段、等多久、被卡在哪），也应该有自己的版本号和更新日志。

判断一份制度好不好，我不看它写得多完整，只看三件事：低风险变更能不能在十分钟内发出去；高风险变更有没有明确的、不需要开会就能触发的回滚条件；以及出事之后，能不能在半小时内查清楚这次变更影响了哪些用户。三件事都成立，制度就是活的；有一件不成立，剩下的条款再漂亮也只是装饰。

下一步怎么做，我给一个可以直接执行的顺序：

1. 花两天做一次变更盘点，把过去三个月的发布按类型归类，标出各类的事故占比。没有这个底数，后面所有讨论都是猜。
2. 用影响面、不可逆性、认知盲区、可观测性四个变量，给每一类变更打一次分，划出三档。这一步只需要一张表，不需要工具。
3. 把"回滚授权"这一条先落地。它投入最小、见效最快，通常能在下一次事故里就把决策时间从半小时压到十分钟以内。
4. 选一个能承载字段和门禁的平台，把分级规则、必填项、观察期收尾做成不可绕过的系统约束。中大型组织尤其如此，人一多，制度只能靠系统活着。
5. 建立季度迭代机制，每次只改一到两条，用度量数据决定改哪条。别一次改十项，那等于没改。

最后提醒一句：任何制度都会在落地三个月后开始走形，因为人会找到最省力的路径。这不是失败，这是信号，说明某条规定和实际工作方式冲突了。看到走形，不要加强检查，先问一句"为什么大家要绕开它"，答案通常就在那儿。