回滚最佳实践：项目成员发布管理制度设计，常见问题

项目发布后 7 分钟，监控告警连续升高，值班负责人决定回滚；但发布负责人联系不上，数据库变更是否可逆没人确认，上一版镜像虽然还在，却缺少对应配置。团队最终花了 46 分钟恢复服务，其中真正执行回退只用了 9 分钟。这样的故障并不罕见：回滚慢，常常不是因为技术上没有按钮，而是因为发布制度没有规定谁能按、按之前看什么、按完如何验。

我设计和复盘发布流程时，最看重的不是“有没有回滚方案”，而是方案能否在压力下被不熟悉这次改动的人执行。本文围绕项目成员发布管理制度，拆解回滚责任、触发条件、权限边界、数据兼容、演练与复盘，并用明确标注的情景模拟说明不同制度选择的成本。案例中的数字用于解释决策方法，不代表行业统计或任何单一组织的真实数据。

一、核心结论：回滚不是按钮，而是一套可执行的决策制度

1. 制度要回答四个现场问题

发布管理制度经常写“异常时及时回滚”，但这句话没有解决现场最困难的部分：异常到什么程度算需要回滚、谁有权决定、回到哪个版本、回滚后如何证明服务恢复。事故发生时，团队不能再临时讨论制度本身。

我建议制度至少明确四个要素：触发条件、决策权限、执行路径、恢复验证。此外，还要把数据迁移、配置变更、第三方依赖和发布窗口纳入评估。代码回到旧版本，不等于系统回到了旧状态。

对中大型企业来说，项目成员发布管理制度还必须处理跨团队协作：研发可能负责代码，平台团队负责部署，业务方负责验收，安全或数据团队掌握特殊审批权。制度如果只写“开发人员负责”，责任就会在交接点消失。

2. 回滚目标应是恢复业务，不是恢复版本号

版本回退是手段，业务恢复才是目标。一个新版本回滚成功，但订单重复、消息积压、权限配置丢失，不能算故障处理完成。因此，制度应分别定义“停止变更”“恢复服务”“数据核对”“事故关闭”四个状态，避免把一次部署命令的成功当成最终结果。

我的判断是，回滚制度的成熟度不应以流程文档页数衡量，而应以不依赖原发布者时，团队能否在约定时间内完成安全止损来衡量。制度要让人知道下一步做什么，也要明确什么情况下不能贸然回退。

3. 用可验证的目标替代“尽快恢复”

“尽快”无法指导排班、演练或复盘。团队可以将目标拆成可观察的时间点：发现异常到停止继续发布的时间、决策到开始执行的时间、开始执行到核心业务恢复的时间、恢复到完成数据核验的时间。不同系统的重要性不同，不宜套用同一套分钟数。

以下为情景模拟的基准，不是行业标准。假设一个工作日有值班负责人、回滚脚本经过验证、服务无不可逆数据变更，目标可以设为 5 分钟内冻结发布、10 分钟内启动回退、20 分钟内完成核心路径验证。若依赖人工审批、跨时区协作或涉及数据补偿，应另行设定更现实的目标。

二、背景和真实场景：为什么“有版本可回退”仍然会失败

1. 发布现场通常同时承受时间压力和信息不完整

平静时，工程师可以比较日志、查配置差异、问清数据迁移影响；故障时，用户投诉、监控告警、管理层询问和协作群消息往往同时出现。若监控只报“服务异常”，却不区分受影响接口、租户、地域或版本，团队很难判断是局部问题还是全量故障。

我在设计流程时会把现场信息分成三类：已确认事实、待验证假设、已执行动作。例如，“错误率从 0.3% 升至 4.8%”是事实；“新版本连接池配置导致”是待验证假设；“已暂停 20% 灰度流量”是已执行动作。把三类信息混在一起，容易让未经验证的推测变成操作依据。

发布制度还应规定统一的信息记录位置。重要决定不宜只留在即时消息里，因为值班交接、复盘和审计都需要可追溯记录。记录不必冗长，但至少包含时间、操作者、观察到的指标、采取的动作及结果。

2. 回滚的对象不止应用代码

一次发布可能同时改变应用镜像、数据库结构、运行配置、流量路由、缓存策略、消息格式和外部服务契约。只把代码版本写进发布单，意味着其他变化没有纳入回退计划。很多“回不去”的问题，实际发生在代码版本之外。

3. 项目成员制度的重点是交接，而不是层层审批

成员发布管理制度不是把每个人都变成审批人。审批链过长会延迟止损；权限过宽则可能让未经授权的人执行高风险操作。合理做法是按照变更风险配置最少必要的审批和可即时执行权限，并清楚规定紧急情况下的授权方式。

在 100 人以上的组织里，成员可能分属多个项目组，值班人员也未必参与了本次开发。发布记录、操作手册和责任矩阵需要能跨团队理解。以 PingCode 作为项目协作场景示例，团队可以把变更、负责人、风险等级、验收项、发布窗口和回滚链接关联在同一项目记录中；但工具只能帮助保留信息，不能代替团队确定阈值和授权规则。

若团队采用某项目管理平台或其他协作系统，关键不是把每一步做成更多表单，而是确保发布负责人、当班执行人、业务验收人能看到同一份最新计划。工具配置应围绕制度中的真实决策点展开，而不是先堆审批节点再寻找用途。

4. 变更越大，回滚不确定性越高

一个小改动也可能影响关键链路，但变更范围扩大通常会增加依赖、验证项和失败组合。评估不能只看代码行数，还要看影响用户范围、写入数据类型、外部接口变更、发布批次以及回退是否需要人工补偿。

三、常见误区：看起来有回滚方案，现场却无法使用

1. 误区：有上一版镜像就等于可以回滚

镜像存在，只说明软件包没有消失，不代表它能安全运行。旧版本可能读不懂新字段，使用已轮换的密钥，调用已变更的接口，或者依赖已下线的基础设施。回滚前应核对旧版本所需的配置、凭据、数据库结构、外部接口及依赖服务。

我会把“版本可用”拆成三项证据：制品可获取、部署配置可复现、旧版本与当前数据兼容。任何一项无法证明，发布单就不应把简单镜像切换描述为完整回滚方案。

2. 误区：数据库变更可以跟代码一起反向执行

应用代码通常可以重新部署，数据结构却可能已经承载新数据。假设新版本写入一个旧版本不认识的枚举值，即使数据库列仍然存在，旧版本也可能在读取时失败。删除列、收窄字段类型、改变金额精度等操作，更可能造成无法无损回退。

对高风险结构变更，我偏向“扩展，迁移，收缩”的做法：先增加兼容字段或接口，让新旧版本并存；再逐步迁移读写；确认旧路径不再使用后，最后清理旧结构。这样增加了短期维护工作，却减少了故障时必须立即逆转数据的压力。

3. 误区：错误率一过阈值就回滚所有内容

单一指标越线并不必然意味着整个版本有问题。告警可能来自下游服务、低流量样本、测试流量，或某个非核心接口。反过来，整体错误率正常也可能掩盖一个关键业务路径完全不可用。制度应定义指标组合和观察窗口，而不是只列一条全局百分比。

我通常建议把技术指标和业务指标并列：错误率、延迟、资源饱和度属于系统侧；支付成功率、关键任务完成率、积压量属于业务侧。遇到采样不足或信号冲突时，先停止扩大发布范围，再根据影响面决定观察、切流或回滚。

4. 误区：谁最懂代码，谁就应该决定回滚

开发者能够解释实现细节，却未必掌握当前业务影响和生产容量。发布决策需要一个当班负责人整合证据，也需要领域负责人评估业务损失。让最了解代码的人独自承担所有判断，既容易形成单点依赖，也会让其同时处于调查和操作负担之中。

合理分工是：发布负责人组织信息并记录决策；执行人按手册操作；业务或服务负责人确认影响和验收；需要时由事故指挥角色统一协调。小团队可以由一人兼任多个角色，但制度要写清角色而非只写姓名。

5. 误区：回滚完成就可以结束事故

部署命令显示成功，只能证明某一步执行结束。服务是否恢复，要看关键请求、队列积压、数据一致性、外部依赖和用户侧结果。恢复后还要判断是否需要补偿、通知受影响用户、冻结后续发布以及启动复盘。

团队也不应为了尽快“结案”而把未知影响当作无影响。事故状态可以区分为：已止损、服务已恢复、数据核对中、用户影响已确认、复盘待完成。明确状态比一句“已经好了”更有助于跨团队协同。

6. 误区：制度越严格，发布就越安全

对每项小改动都要求多级会议审批，会把风险控制变成形式负担。成员为了绕过等待，可能选择在流程外操作；审批者也可能因为信息过多而只点通过。制度应按风险分级，而不是将同一套重流程应用于全部变更。

高风险变更需要更充分的验证、明确的值守和更强的审批；低风险、可独立关闭的功能，可以用自动检查、负责人确认和短周期观察控制。把低风险流程做轻，把高风险边界写实，比让所有发布都变慢更有效。

四、专业判断逻辑：怎样决定观察、停止、切流或回滚

1. 先判断影响，再判断原因

事故初期通常无法立即确定根因。此时先问“谁正在受影响、影响有多大、是否还在扩大”，比急着猜测是哪段代码更重要。原因分析可以并行推进，但止损动作要依据已知影响和风险边界。

我会用四个维度做快速判断：影响范围、业务关键程度、变化趋势、可逆程度。影响范围回答有多少用户或服务受影响；业务关键程度说明故障是否阻断核心流程；变化趋势判断问题是稳定还是恶化；可逆程度评估操作能否安全撤销。

2. 设计“观察，冻结，止损，恢复”的决策阶梯

不是每个异常都需要立即回滚，也不是每种回滚都适合全量执行。制度可以把处置分成四档：低影响先观察；信号不清但风险可能扩大时冻结发布；影响明确且可逆时切流或关闭功能；核心路径持续受损时执行回退或应急修复。

1. 观察：确认告警可信、采样充足，比较发布前基线和发布后变化。
2. 冻结：停止后续批次、暂停相关变更，保留当前状态和关键日志。
3. 止损：优先采用范围可控的开关、限流或切流，避免把局部故障扩大为全量操作。
4. 恢复：在回滚、前向修复或数据补偿之间选择，并按预先定义的验证项确认结果。

这个阶梯不是要求每次逐级等待。若核心交易链路大面积失败，团队可以跳过观察等待，直接止损；若数据变化不可逆，则即使应用故障严重，也可能先冻结写入、保护数据，再选择前向修复。制度需要写明可跳级条件和记录要求。

3. 触发条件应同时包含阈值、窗口和例外

可执行的触发条件不应只写“错误率超过 5%”。它还需要说明统计窗口、基线、流量门槛和业务例外。比如，错误率连续两个 5 分钟窗口超过阈值，且请求量达到最低样本要求；若核心交易成功率明显下降，则无需等待窗口结束。

阈值应从系统基线、历史事故和业务容忍度中确定。没有可靠基线的服务，不适合凭空设出看似精确的数值。可以先通过观察期记录正常波动，再逐步设置告警和发布门槛，并通过演练检验阈值是否过敏或迟钝。

4. 权限矩阵要覆盖正常发布和紧急事件

正常流程强调责任可追溯，紧急流程强调止损不被审批阻塞。制度可以规定：当班负责人有权暂停发布；指定执行人可在达到明确条件后启动预授权回退；涉及不可逆数据操作时，必须取得数据负责人确认，或执行预先批准的保护性动作。

所谓紧急授权并非取消控制，而是把控制前置。事后需要补齐决策记录、操作日志和影响评估，但不能让现场人员为了等待形式审批而放任故障扩大。每个团队都应明确谁可以替代缺席角色。

5. 回滚路径应按变更类型分解

发布单中至少要说明代码、配置、数据、流量和异步任务的操作顺序。顺序错误可能把问题放大，例如先恢复应用但消息消费者仍读取新格式，或者先切回流量却让旧版本继续写入新结构。

对复杂发布，可以把回退拆成多个可验证动作：关闭新功能、冻结写入、停止消费者、切回应用、校验数据、恢复流量、检查积压。每一步都要有执行人、成功信号和失败时的下一步，不要只留一句“运行回滚脚本”。

6. 回滚和向前修复不是对立选项

当旧版本兼容当前数据、回退路径清晰时，回滚通常是快速止损的优选。若已产生不可逆数据、回退会丢失用户操作，或新旧版本接口完全不兼容，前向修复和数据补偿可能更安全。选择时应比较预计恢复时间、数据损失风险、影响范围和执行确定性。

我不建议把“必须回滚”写成统一纪律。更稳妥的制度是规定决策标准，并为回滚、关闭功能、切流、前向修复和数据补偿准备相应路径。目标是把影响控制在可接受范围，不是证明某一种操作永远正确。

五、案例与数据观察：把制度落到成员、动作和验证上

1. 情景模拟：一次灰度发布中的决策变化

以下是用于演示的情景模拟：某业务服务先向 10% 流量发布，核心请求错误率在两个监控窗口内上升，关键任务完成率也下降。发布负责人没有继续扩大灰度，而是冻结批次，确认异常集中在新版本涉及的接口；执行人关闭功能开关，随后将流量切回上一版本。

在这个示例中，开关关闭耗时 2 分钟，切回应用耗时 6 分钟，核心路径验证耗时 8 分钟，总计 16 分钟。这个结果依赖提前准备：开关与代码部署解耦、上一版本能兼容当前数据、执行人有预授权、监控能区分版本。只复制“16 分钟”而不具备这些条件，没有意义。

若团队没有开关，数据库已经写入不兼容数据，或者上一版本镜像不可用，同样的故障可能转为前向修复。制度设计应当优先找出这些约束，而不是在事故后把执行人视为流程失败的唯一原因。

2. 观察的核心不是均值，而是差异和尾部

发布复盘常记录平均恢复时长，却容易掩盖少数特别慢的案例。若大多数变更 10 分钟恢复、少数变更需要数小时，平均值会被拉高，但团队仍不知道该优先修复什么。建议同时看中位数、高分位时长、超出目标的比例，以及超时由审批、信息缺失、数据修复还是操作失败造成。

数据分段也很重要。按变更风险、服务类型、发布批次、是否涉及数据库、是否跨团队协作进行分类，能看到哪些条件最容易拖慢恢复。小样本时不要夸大统计结论，应保留案例背景，避免把偶然事件误判为稳定规律。

3. 复盘要寻找制度缺口，而不是只找操作失误

如果执行人找不到脚本，问题可能是发布记录没有链接操作手册；如果没人敢决定，可能是权限矩阵缺少紧急授权；如果旧版本启动失败，可能是兼容性测试没有覆盖回退；如果恢复后数据对不上，可能是验收只看服务状态，没有数据核验步骤。

复盘建议按“触发，判断，动作，结果，缺口”顺序还原事实。每个改进项要有责任人、完成期限和验证方式，例如“在下次发布前完成旧版本兼容演练”，而不是“加强意识”。同一问题重复出现，通常说明修复措施没有嵌入流程或自动化。

4. 用演练数据检验制度是否适合组织规模

演练不必每次都做成全链路灾难模拟。团队可以从桌面推演开始，给参与者一组告警和限制条件，观察他们能否找到负责人、触发阈值、回滚手册和验证标准。随后再对高风险服务做受控实操，验证权限、脚本、制品和数据兼容。

建议记录演练中的发现时间、决策时间、执行时间、验证时间、求助次数、操作错误数和未覆盖依赖。更重要的是记录“若当前是生产事故，哪一步会卡住”。只记录演练是否通过，容易让流程表面合规、现场仍不可用。

六、不同情况下的行动建议：把风险等级变成可执行流程

1. 小团队、低风险变更：先保证简单路径可靠

人员有限、系统依赖较少的团队，不必照搬大型组织的审批体系。应优先建立一个清楚的发布负责人、一名备份执行人、一份可访问的操作手册，以及一条可用的紧急沟通路径。变更前确认旧版本可部署、配置可恢复、关键链路有验证方式。

小团队最容易出现的问题不是缺少复杂流程，而是知识集中在一个人身上。可以安排非开发者或另一位工程师按手册完成一次回退演练，观察说明是否足够清楚。若必须由原作者口头补充，手册还没有真正完成。

2. 多团队依赖、共享服务：先冻结边界，再协调回退

多个团队共同依赖的接口或平台，不能只由单个项目组决定全量回退。制度应明确变更影响通知、兼容期、上下游负责人和协调角色。出现问题时，先停止扩大变更，确认哪些调用方受影响，再决定切流、降级、回滚或前向修复。

接口变更应尽量采用兼容性策略，并设定旧接口的退出条件。若不同团队发布节奏无法同步，发布计划需要列出版本组合与回退顺序。否则，某团队成功回滚可能让另一个团队调用失败。

3. 涉及数据库或数据迁移：优先保护数据完整性

对数据结构和批量迁移，回退决策首先要确认写入状态、迁移进度、幂等性和恢复点。若无法证明逆向迁移不会丢数据，不应为了满足“快速回滚”而执行反向脚本。可选动作包括暂停写入、切换只读、回到兼容版本、重放日志或制定补偿任务。

发布审批应要求列出迁移前后结构、预计数据量、失败中断处理方式和验证查询。大规模迁移最好分批执行，记录每批边界，确保中途停止后能够判断已完成范围，而不是只能全量重跑或全量撤销。

4. 高敏感、高可用服务：建立分级授权与独立验证

金融、身份权限、医疗或关键基础设施等高影响场景，不能只依靠开发团队自我确认。制度可能需要独立审批、双人复核、变更窗口、只读保护和数据审计。具体要求取决于适用法规、合同义务和组织安全政策，不能用通用模板替代合规审查。

高可用服务还要避免把回滚动作本身变成新的风险。切流前确认备用容量，关闭功能前确认依赖关系，回退后由不同于执行人的人员复核关键业务结果。对不可逆操作，应提前准备补偿和对外沟通方案。

5. 夜间、节假日或关键人员缺席：为“无人可问”设计

制度必须假设原作者可能不在线。发布包应包含变更摘要、风险点、回滚步骤、验证命令、依赖联系人和升级路径。紧急情况下，值班人员应能先执行预授权止损动作，而不是翻阅长文档寻找谁批准。

对较少发布但风险高的系统，应确保值班人员定期接触操作流程。很久不演练的回滚手册，即便看起来完整，也可能因凭据过期、资源名称变化或平台升级而失效。

6. 发布过程已出现异常，但根因不明：先控制变量

如果监控信号不完整，建议先冻结下一批发布，保存日志与当前配置，减少同时变更的变量。不要一边改配置、一边重启、一边切流，否则结果变化后很难判断哪个动作有效，甚至会丢失定位证据。

当异常影响范围可控且指标稳定时，可以设定短观察窗口并明确退出条件；若指标持续恶化、影响核心业务或出现数据风险，应优先采取止损措施。观察不是拖延，必须有负责人、截止时间和明确的升级条件。

七、不同情况下的取舍：没有一种回滚方案适合所有系统

1. 立即回滚与短时观察的取舍

立即回滚的好处是尽快停止已知风险扩散；代价是可能引入二次故障，或撤销本来无关的变更。短时观察能积累证据，但也可能让损害继续扩大。判断关键是影响趋势、核心业务敏感度和回退安全性，而不是团队是否希望“再看看”。

如果故障持续扩大且回退路径经过验证，优先止损；若只有低可信度告警、影响轻微且可控，可以设置明确观察窗口。观察到期仍不能排除风险时，要有升级动作，不能把“继续观察”无限延长。

2. 全量回滚与局部切流的取舍

全量回滚通常操作路径简单、收益直接，但影响面大，也可能撤销健康区域的有效变更。局部切流或关闭功能更精准，却要求系统具备细粒度路由、开关和可观测性。若操作能力没有演练过，复杂的局部控制可能比简单回退更危险。

团队应按既有能力选择，而不是追求看起来先进的策略。可以先确保一个可靠的整体回退，再逐步建设按租户、地域或功能分区的止损能力。

3. 回滚与前向修复的取舍

回滚适合旧版本兼容当前数据、问题由新版本引入且回退可验证的场景。前向修复适合数据已不可逆改变、回退会造成更大损失，或故障原因可快速明确修复的场景。两者都需要评估操作风险和预计恢复时间。

不要仅根据“修复补丁看起来很小”就选择前向修复。故障状态下新改动仍需测试、审查和验证；同样，不能因为回滚命令存在就忽视数据兼容。应比较执行确定性，而非代码改动看起来多少。

4. 强审批与预授权的取舍

强审批提高关键变更的可控性，却增加等待和沟通成本。预授权能缩短止损时间，但必须把适用条件、授权对象、操作范围和事后审计写清楚。对于可逆、影响范围清楚的动作，可以预授权；对于不可逆数据操作或大范围权限变更，通常需要更强控制。

最佳做法往往不是二选一，而是把紧急止损权限与最终事故关闭权限分开。值班人员可以先停止扩大影响，后续再由相关负责人完成数据核验、用户影响确认和正式结案。

5. 自动化与人工复核的取舍

自动化可以减少手工差错、缩短执行时间，但错误自动化也会更快扩大影响。自动回滚适合触发信号可靠、动作范围明确、恢复结果可自动验证的场景；当监控存在采样偏差、涉及数据补偿或依赖状态复杂时，自动化宜先停止扩大发布并提示人工判断。

建议分阶段建设：先自动生成发布证据和检查项，再自动暂停灰度或关闭可控开关，最后才考虑自动执行全量回滚。每个自动动作都要有审计记录、停止条件和人工接管方式。

八、项目成员发布管理制度模板：从原则落到发布单

1. 发布前必须完成的最小信息集

发布信息的目标不是收集越多越好，而是确保执行者不必临时追问关键事实。每个发布单至少应包含变更范围、风险等级、负责人和备份人、发布窗口、验证项、依赖团队、停止条件、回退路径及数据影响。

• 变更说明：说明改了什么、影响哪些服务、用户或业务路径。
• 风险评估：标记是否涉及数据结构、权限、外部接口、批量任务或基础设施。
• 发布计划：列出批次、观察窗口、流量范围和暂停条件。
• 回退信息：说明目标版本、配置恢复方式、数据兼容判断和操作手册链接。
• 验证标准：明确技术指标、关键业务结果和数据核对方式。
• 责任安排：记录发布负责人、执行人、验收人及缺席时的替代角色。

2. 发布中必须有人持续负责判断

发布开始后，责任不能随着执行命令交给自动化系统。发布负责人需要确认每个批次结果、观察窗口和继续发布的条件；执行人负责按计划操作并报告异常；验收人负责核对业务结果。规模较小的团队可以兼任，但应避免“谁执行、谁宣布一切正常”成为唯一验证方式。

发布负责人还应维护一份简明时间线，记录每次扩量、告警、决策与操作。这样一旦需要回退，团队能知道当前系统处于什么状态，而不是从聊天记录中拼凑。

3. 发布后必须完成恢复验证和闭环记录

验证项应与变更风险相匹配。普通页面变更可能检查页面可用性和错误率；交易链路则需要核对端到端成功率、重复提交、资金或库存一致性；异步任务要检查积压和重放结果。只看服务进程健康，不足以证明业务已恢复。

发布结束后记录结果：成功、部分成功、回退、前向修复或中止。若发生异常，还要记录影响范围、恢复时间、数据影响、根因置信度和改进项。未知事项应标注待核实，不要用确定语气掩盖不完整证据。

4. 制度落地的四周推进法

如果组织尚无成熟制度，我通常建议先选一个高频、影响可控的服务试点，而不是一次性给所有团队下发厚重规范。第一周收集现有流程和最近发布问题；第二周建立风险分级、角色和最小发布单；第三周演练高风险路径；第四周依据演练发现调整阈值和自动化。

1. 盘点：找出最常见的发布类型、故障类型、系统依赖和关键联系人。
2. 定级：以影响范围、数据可逆性和依赖复杂度制定低、中、高风险类别。
3. 试运行：选择少量项目执行新流程，记录审批等待、执行耗时和信息缺口。
4. 演练：安排非原作者按手册回退，验证说明、权限和制品是否可用。
5. 修订：删除无价值审批，补齐阻塞点，再扩展到其他服务。

使用协作平台时，可以把风险级别、发布责任人、验收项和回退方案做成结构化字段，并将变更记录与任务、缺陷及版本关联。工具的价值在于减少重复抄写和信息丢失；若流程字段无人维护，系统只会生成更整齐的过期信息。

九、结语：回滚制度真正保护的是团队的决策能力

回滚不是对失败的惩罚，也不是发布流程里的一个勾选框。它是一种在信息不完整、时间受限、影响可能扩大的条件下，保护用户和业务的决策能力。制度真正成熟时，团队既知道何时应该回退，也知道何时不应盲目回退。

如果你准备开始改进，下一步不必先购买工具或重写全部流程。先挑选最近一次影响较大的发布，逐分钟还原发现、授权、执行和验证过程；找出最耗时的一步，再安排一次由非原作者参与的回滚演练。能被陌生值班成员安全执行的方案，才称得上真正的回滚方案。