回滚流程与规范：实施团队发布管理入门指南关键指标

一次发布失败，真正昂贵的部分往往不是回滚命令执行了几分钟，而是团队过了半小时才确认该不该回、谁有权拍板、回到哪个版本，以及回滚后数据是否还能对得上。回滚流程与规范的关键指标，不应只统计“回滚次数”和“恢复耗时”；更应衡量团队能否及时识别风险、能否安全恢复、能否验证业务状态，以及能否把同类故障变得越来越少。本文从实施团队的发布现场出发，给出一套可落地的回滚指标、判断逻辑与演练方法。

文中的示例数字均为情景模拟，用于说明计算口径，不代表行业基准。

一、核心结论：回滚管理衡量的是恢复能力，不是回滚次数

1. 先把回滚定义清楚

我会把回滚定义为：当发布变更使系统或业务状态达到不可接受的风险阈值时，团队通过预先设计的操作，将服务恢复到已知可用状态，并完成业务验证的过程。它可能是代码版本回退，也可能是配置恢复、流量切换、数据修复或功能关闭。

这一定义有意把“执行命令”和“恢复业务”区分开。部署平台显示上一个版本已启动，不等于用户已经恢复正常；接口返回成功，也不等于账务、库存、权限或异步任务没有留下错误状态。只有技术状态和业务状态都通过验证，回滚才算完成。

2. 指标要形成一条可解释的链路

一套可用的回滚指标，至少覆盖四个问题：发布前是否具备回退条件，发布中是否能及时发现异常，触发后是否能快速恢复，恢复后是否能确认业务正确。若只看回滚耗时，团队可能通过缩短技术操作时间改善数字，却没有缩短发现故障的时间，也没有处理数据一致性问题。

不同团队的系统复杂度、流量规模和业务风险差异很大，不宜拿单一数字直接横向排名。更有用的做法是先统一定义，再看同一系统、同一业务链路在一段时间内的变化，并解释变化由什么造成。

3. 指标必须能驱动行动

指标不是为了做一张更好看的发布看板，而是为了让团队在下一次发布前知道该补什么。若“回滚成功率”下降，管理者需要继续追问：是预案过期、依赖未覆盖、数据库不可逆，还是值班人员没有权限？不能追到具体控制点的指标，只能制造讨论，无法降低风险。

我建议每个指标都配四项定义：统计对象、起止时间、成功判定、排除规则。例如“回滚耗时”从异常达到触发阈值开始，到业务验证通过结束；不能从执行脚本开始计时，否则会把监控等待和决策犹豫都藏起来。

二、背景与真实场景：实施团队为什么特别需要回滚规范

1. 实施发布常常不是单纯的软件部署

实施团队交付的变更，往往同时涉及客户环境、基础数据、接口配置、权限策略、批处理任务和现场操作流程。发布内容可能跨多个系统，也可能需要客户管理员、实施顾问、研发和值班人员协同。一个环节延误，就可能让“回退到上一版本”变成一项涉及数据、配置和沟通的联合处置。

例如，一次客户现场升级不仅替换应用包，还调整了字段映射、定时任务和接口认证方式。应用包可以恢复，但如果新版本已经写入新格式的数据，旧版本未必能够读取；如果定时任务已经重复执行，回退代码也不会自动撤销业务副作用。此时，回滚方案必须回答“恢复什么、保留什么、补偿什么”，而不仅是“执行哪个命令”。

2. 常见触发场景有不同的恢复路径

我通常先把触发原因分成四类，因为不同故障需要不同的恢复动作。性能恶化可能适合切回旧版本或关闭新功能；接口异常可能需要恢复配置或切换备用通道；数据错误需要暂停写入、核对影响范围，再决定修复或补偿；权限事故则可能优先撤销权限并保留审计记录，而不是直接回退整次发布。

• 功能故障：关键流程无法完成，常见处理是关闭功能、切流或恢复版本。
• 性能故障：错误率、延迟或资源消耗越过阈值，可能需要限流、扩容或回退变更。
• 数据风险：写入内容错误、重复或不完整，必须先控制继续扩散，再评估修复与补偿。
• 安全与权限风险：优先限制访问、撤销配置并保存证据，避免为追求快速回退破坏审计链条。

这些路径不能用一个“回滚按钮”替代。一个成熟的流程会在预案里写清楚：什么情况回滚、什么情况先止损、什么情况需要业务负责人确认，以及何时必须暂停自动化操作。

3. 多方协作会放大决策延迟

实施现场常见的时间损耗并非来自执行速度，而是来自信息不完整：客户说“系统慢”，实施人员看见接口超时，研发发现数据库连接池已满，业务负责人却还不知道受影响的交易范围。若没有统一的故障时间线和决策角色，团队会在群聊里反复确认同一件事。

因此，回滚指标应当把“异常发现时间”和“回滚决策时间”拆开。前者反映监控和反馈链路，后者反映风险判断与授权机制。两者混在一起，无法判断究竟该改告警、改流程，还是改职责安排。

4. 回滚失败往往在发布前就埋下了

很多所谓的“回滚故障”，表面发生在事故现场，根因却早已存在于发布准备阶段：旧版本没有保留、配置没有版本化、数据库变更不可逆、测试环境缺少客户差异、回滚账号权限不完整，或者预案只写了命令却没有负责人和验证标准。

这也是我判断发布管理成熟度时，优先看“预案是否经过真实演练”，而不是看文档数量的原因。文档可以证明有人写过，演练才能证明团队在真实约束下能执行。

三、常见误区：数字看起来改善，风险未必降低

1. 把回滚次数越少当作越好

回滚次数少可能意味着发布稳定，也可能意味着故障没有被发现、团队害怕回滚、决策授权过慢，或者故障发生后采用了人工修补但没有登记。单看次数无法区分“质量好”和“风险被隐藏”。

建议把回滚次数放在变更总量、变更失败率和故障严重度旁边解释。若发布量增加一倍，回滚次数不变，回滚率可能下降；若团队减少发布，回滚次数下降，却不代表发布能力提升。分母必须明确，统计周期也应与业务节奏相符。

2. 把回滚耗时压缩成一个数字

“十分钟完成回滚”听起来很有执行力，但如果异常在发布后四十分钟才被发现，整体恢复时间仍然很长。相反，某些数据修复需要较长的人工核对，团队可能已经迅速止住风险，只是最终业务校验需要时间。

我建议至少拆成发现、确认、决策、操作、验证五段。每段使用不同起止事件，才能看出改进方向。发现慢要补监控，决策慢要明确授权，操作慢要自动化，验证慢要准备业务校验清单。

3. 把部署成功等同于回滚成功

部署平台显示旧版本运行，只能说明进程或容器回到了某个版本。它不能证明缓存、队列、数据库、外部接口或用户会话状态都已恢复，也不能证明失败期间产生的业务数据已经处理。

回滚成功的判定应覆盖技术健康和业务健康。技术健康可以检查实例状态、关键接口、错误率和延迟；业务健康则要检查核心交易是否完成、数据是否满足约束、异步任务是否积压、客户是否能继续操作。

4. 把所有异常都自动回滚

自动回滚适合信号明确、影响可逆、回退动作已验证的场景。例如新版本错误率持续超阈值，且流量可以安全切回旧版本。它不适合所有数据变更、外部依赖故障或短时噪声告警。错误的自动回滚可能在系统恢复途中再次引入变更，甚至造成双向数据写入。

我的判断原则是：自动化的门槛不在于“能不能写脚本”，而在于输入信号是否可信、动作是否可逆、结果是否可验证。任何一个条件不满足，都应保留人工确认或先执行止损动作。

5. 把复盘写成责任追究或会议纪要

复盘若只记录“加强测试、提高意识、做好监控”，没有责任人、期限、验收条件，就很难改变下次发布。另一方面，如果复盘只寻找个人失误，团队会倾向于少报、晚报，风险反而更难暴露。

有效复盘应从系统条件出发：为什么错误能进入生产，为什么信号没有触发，为什么回滚条件不明确，为什么业务校验缺失。行动项要能验证，例如“为结算接口增加按租户拆分的错误率告警，并在演练中验证告警在五分钟内触发”。

四、专业判断逻辑：建立一套可计算、可解释的指标体系

1. 先统一统计口径和事件时间线

在采集指标之前，先统一“发布”“异常”“回滚启动”“恢复完成”的定义。实施团队最常见的口径冲突，是研发从部署完成开始计时，客户支持从收到投诉开始计时，项目经理从决定回退开始计时。三个数字各自都可能正确，却不能放在一起比较。

我建议为每次发布生成一条事件时间线，至少记录发布开始、变更完成、异常首次出现、告警触发、人工确认、决策形成、回滚开始、技术恢复、业务验证完成等时间点。时间戳由自动化系统采集优先，人工补录时注明来源和原因。

2. 将指标分成领先指标和结果指标

结果指标描述已经发生的事，例如发布失败率、回滚成功率、业务恢复时间。领先指标描述团队是否具备降低风险的条件，例如预案评审覆盖率、演练通过率、变更风险检查完成率、数据库兼容性检查覆盖率。

只看结果指标，管理者往往要等事故发生后才知道薄弱点；只看领先指标，则可能出现检查项全部打勾、现场依旧无法恢复的形式主义。更合理的做法是成对观察：演练通过率提高后，实际回滚成功率是否同步改善；预案覆盖率很高但恢复时间没有下降，说明覆盖质量或现场可执行性可能不足。

3. 按风险等级设置不同触发阈值

阈值不应简单照搬其他团队。低风险内部工具可以容忍短时波动，高风险交易流程则需要更低的错误预算。实际设定时，我会结合三个因素：用户影响范围、故障持续时间、数据可逆性。

• 影响范围：是单个客户、一个租户、一个区域，还是全体用户？
• 持续时间：瞬时波动是否会自动恢复，还是持续恶化并扩大影响？
• 可逆性：回到旧版本后，已写入数据能否兼容，外部副作用能否补偿？

可把触发条件写成“信号＋持续时间＋业务范围＋处置动作”，而不是“错误率超过某值就回滚”。例如，关键交易接口错误率连续若干分钟超过基线且影响多个租户，先暂停流量扩张并由值班负责人确认；若同时满足预案中的回退条件，再执行切换。

4. 把服务可靠性目标纳入发布决策

若团队已经定义服务可靠性目标或错误预算，发布决策应考虑当前预算消耗。系统近期已经大量消耗可用性预算时，风险较高的变更应减少、拆小或安排更强的观察和回退能力；当运行稳定且预算充足时，团队可以在受控范围内推进变更。

这不是把错误预算变成“禁止发布”的机械规则，而是让风险承担透明化。实施团队还应把客户合同、业务时段、批处理窗口和现场支持能力纳入决策，避免只看技术指标，忽略客户侧的实际代价。

5. 让每个指标都对应责任角色

指标的负责人不一定是执行人。监控团队可能负责异常发现数据，实施负责人负责预案完整性，研发负责版本兼容与回退能力，业务负责人负责验证关键流程，发布负责人则负责决策记录和复盘闭环。

如果某项指标长期恶化，却没有人有权限改变对应流程，指标就会沦为报表。建立责任映射时，要同时写清数据提供者、指标解释者、行动负责人和验收人，避免所有问题都落到“项目组共同跟进”。

五、案例与数据观察：从一次分批发布看出问题在哪里

1. 情景设定：客户配置与应用版本一起变更

下面是一个明确标注的情景模拟。某实施团队为企业客户升级业务模块，涉及应用版本、字段映射和接口配置。团队将发布拆成三个批次，每批覆盖一部分客户环境。第一批出现接口错误率上升，告警在数分钟内触发；由于旧版本不能直接读取新写入的数据，团队先暂停后续批次，切换流量并核对数据影响，再决定采用兼容修复，而不是立即全量回退。

这个案例的价值不在于给出一条标准答案，而在于说明“回滚”并不总是最安全的动作。若新格式数据已经写入，直接回退应用可能造成更大损害。先停止扩散、确认数据状态、选择兼容版本或补偿方案，可能比一键回退更稳妥。

2. 情景数据：时间拆分比总时间更有诊断价值

若只报告“从告警到恢复用了六十四分钟”，团队可能把重点放在加快操作脚本。拆分之后，真正的改进重点是影响范围核对和数据兼容性演练，而不是单纯优化切换命令。

3. 改进后的第二次演练：不要把模拟结果当成生产承诺

团队在后续演练中补充了三项措施：发布前验证新旧版本的数据兼容；按客户环境预先生成影响清单；把暂停批次和流量切换的权限授予当班负责人。演练的情景模拟结果显示，影响确认从十一分钟降至五分钟，数据核对从二十八分钟降至十四分钟，恢复验证从十九分钟降至十二分钟。

这些数字只代表同一情景下的内部推演，不是生产事故的保证值。演练可以证明操作步骤和协作关系在指定条件下可用，却不能覆盖所有客户差异、网络故障和第三方系统状态。将演练结果作为承诺前，必须说明适用环境和未覆盖风险。

4. 如何判断改进是否有效

不能因为一次演练变快，就宣称团队的回滚能力已经成熟。我会检查改进是否具备可重复性：不同值班人员能否执行，客户环境差异是否覆盖，预案是否可从发布记录中快速找到，关键操作是否留下审计记录，业务验证是否由相应负责人确认。

然后观察一段时间内的结果指标，例如发布失败率、异常发现时间、业务恢复时间和回滚后复发率。如果演练越来越顺，但生产中的恢复时间没有变化，可能是演练场景过于理想，也可能是生产中的依赖和权限条件没有纳入测试。

六、落地流程：从发布前检查到回滚后复盘

1. 发布前：把可恢复性作为准入条件

发布前检查的目的不是增加签字，而是确认发生问题时团队有可行的选择。风险越高，越需要把预案、验证和授权做得具体；风险低、可逆性强的变更则可使用轻量流程，避免所有发布都被同一套重审批拖慢。

1. 标记变更类型：区分应用、配置、数据、权限、接口和基础设施变更，识别是否存在不可逆步骤。
2. 定义回退目标：写明目标版本、目标配置或止损状态，说明是否保留已经写入的数据。
3. 检查依赖条件：确认数据库兼容、外部接口、队列任务、缓存、权限、证书和客户侧配合条件。
4. 定义触发信号：明确错误率、业务失败、延迟、数据异常或客户影响达到什么条件时采取行动。
5. 指定决策角色：列出当班负责人、技术负责人、业务验证人和必要的客户联系人。
6. 准备验证清单：列出恢复后必须验证的接口、交易、报表、异步任务和数据约束。
7. 确认停止条件：明确哪些情况下不继续回滚，改为暂停流量、关闭功能、数据修复或升级处理。

如果发布工具能够关联预案、变更记录、审批信息和验证结果，执行人员就不必在多个系统中搜索。对中大型组织而言，项目与研发管理平台可以承担流程记录和责任协同，但工具不能代替风险判断。工具里的“已完成”状态必须对应真实证据，而不是单纯点选。

2. 发布中：分批推进并设置观察窗口

分批发布的目的不是把一次发布拆成更多操作，而是限制错误的传播范围。批次应按风险和可观测性设计：先选影响小、代表性足够的环境验证，再逐步扩展；每个批次之间保留观察窗口，确保错误率、业务成功率和数据状态稳定后再继续。

观察窗口不能只有固定时间。若关键任务有夜间批处理、日终结算或定时同步，仅等待十分钟可能看不到问题。团队应结合业务周期设置观察条件，例如关键任务至少完成一次、队列积压回落、核心交易成功率稳定达到目标。

3. 触发时：先止损，再决定恢复路径

出现异常后，第一动作不一定是回滚。若影响仍在扩大，应先暂停后续发布、限制流量、关闭新功能或停止相关任务，避免继续写入错误数据。随后确认影响范围、数据状态和依赖系统，再选择回滚、修复、补偿或维持现状。

处置过程中应保持一条统一时间线。记录谁在什么时间观察到什么信号、做了什么决定、依据是什么、结果如何。这样既能减少多人重复排查，也能在复盘时区分事实与事后推测。

4. 恢复后：业务验证通过才能关闭事件

恢复后至少完成三层验证：基础服务健康、关键技术链路健康、核心业务结果正确。基础服务检查进程、实例和资源；技术链路检查接口、队列和依赖；业务结果检查交易、数据、权限和用户实际操作。

对于实施项目，验证人不应只有技术执行者。若回滚影响客户业务，应由熟悉业务规则的负责人确认关键流程；涉及数据修复时，还应保留修复前后核对结果。未完成业务验证的事件应标记为“技术恢复、业务待确认”，不能提前关闭。

5. 复盘后：把行动项变成可检验的控制

复盘行动至少包括问题描述、责任人、截止时间、验收证据和未完成风险。避免写“完善回滚机制”这类无法验收的任务。可以改成“为配置发布增加上一稳定配置的自动快照，并在下次演练中验证恢复后关键接口正常”。

复盘还应检查相似系统是否存在同类问题。一次客户环境的兼容性缺陷，可能影响其他租户；一个项目的权限遗漏，也可能是组织级发布模板的缺口。只修当前现场，未必真正消除了风险。

七、关键指标怎么选：不同阶段、不同风险的组合建议

1. 刚开始建立流程的团队

初期不要一次引入几十个指标。先选少量能够形成闭环的指标：预案覆盖率、演练通过率、异常发现时间、回滚成功率、业务恢复时间和复盘行动按期完成率。每项都要有明确口径和数据来源，先连续记录，再讨论目标。

流程刚建立时，故障记录数可能短期上升，因为过去漏报的异常开始进入统计。这不一定是变差，也可能是透明度提高。管理者需要结合严重度、用户影响和发现速度判断，避免用短期数字惩罚主动报告问题的团队。

2. 发布频繁、自动化程度较高的团队

发布频率高时，应把关注点从单次回滚操作转向变更质量和自动保护能力。适合增加按变更类型拆分的失败率、自动回滚触发准确率、错误预算消耗、分批发布拦截率和发布后复发率。

自动化团队特别要防止“自动回滚率越高越好”的误读。触发过多可能代表阈值敏感或监控噪声大；触发过少也可能代表信号缺失。需要抽样回看告警事件，检查自动动作是否正确、是否减少了用户影响、是否引入数据副作用。

3. 数据变更或跨系统实施较多的团队

数据风险高时，核心指标应转向兼容与一致性：数据备份可恢复率、迁移演练通过率、校验差异率、补偿任务完成率、跨系统对账完成时间。单看应用版本回退速度几乎不能代表整体恢复能力。

对不可逆的数据操作，团队应评估是否能采用“扩展，迁移，收缩”的兼容发布方式：先让新旧版本都能读写兼容结构，再逐步迁移数据，最后在确认安全后移除旧结构。这样会增加短期实施工作，却可能显著降低紧急回退时的损失。

4. 客户现场环境差异很大的团队

如果客户环境版本、网络、权限和接口配置差异明显，应记录环境覆盖率和现场依赖完整率。一个在标准测试环境通过的回滚预案，未必能在客户现场执行。可按环境类型分层演练，并把现场联系人、访问权限和维护窗口纳入发布准备。

团队还应把客户沟通纳入恢复流程：谁负责说明影响、何时发送状态更新、哪些信息需要客户确认、是否需要业务暂停。技术恢复与客户恢复是两条并行链路，缺少后者时，用户仍可能因为不知道系统状态而重复操作。

5. 中大型组织：用协同平台记录证据，但不让流程替代判断

在百人以上组织或多实施团队并行的环境中，回滚信息分散在工单、代码库、监控系统、客户群和会议纪要中，容易出现版本与责任信息不一致。可以通过项目管理平台或研发协同平台关联发布任务、变更审批、缺陷、风险项、值班安排和复盘行动。

例如，PingCode可作为中大型企业及百人以上组织的项目协同场景示例，用于承载需求、任务、缺陷和交付过程中的责任关联。是否适用取决于组织现有系统、权限模型、集成能力和合规要求；无论采用何种平台，回滚结论都应链接到监控证据、操作记录和业务验证结果，而不是只保留一个流程状态。

八、不同情况下的取舍：快、稳、可审计不可能同时无限最大化

1. 速度与安全的取舍

快速恢复通常意味着减少确认步骤，但在数据不可逆或影响范围不明时，跳过核对可能让短期故障变成长期数据事故。我的取舍原则是：对可逆、影响有限、信号明确的故障，优先快速自动化；对不可逆、跨系统或影响客户资金与核心记录的变更，先止损再确认，不为“恢复时间数字”牺牲正确性。

团队可以通过预先演练来缩短确认时间，而不是在事故现场删掉确认步骤。把数据校验、影响清单和授权人提前准备好，通常比事后要求每个人“动作更快”更有效。

2. 自动化与人工判断的取舍

自动化擅长重复、信号清楚且结果可验证的动作；人工判断适合信息不完整、业务影响复杂或不可逆的决策。不要把“全自动”当作成熟度的终点。真正成熟的设计会明确哪些动作自动执行、哪些动作需要确认、哪些动作在条件不满足时必须停止。

可以把处置设计成分层模式：系统自动暂停后续批次；值班人员确认影响范围；达到明确条件后自动切流；业务负责人完成关键流程验证。这样既利用自动化缩短止损时间，也保留高风险决策所需的判断。

3. 统一标准与客户差异的取舍

标准流程能够降低学习成本，但实施项目的客户差异不能被模板抹平。建议统一最低控制要求，例如必须有恢复目标、负责人、触发条件和验证清单；同时允许按系统风险和客户约束增加特定步骤。

如果每个客户都使用完全不同的回滚方案，知识无法复用；如果所有客户都被强行套用同一预案，现场条件又可能不匹配。比较稳妥的方式是“标准骨架＋环境差异附录”：主体流程统一，差异配置由发布记录明确标注。

4. 指标透明与绩效压力的取舍

指标透明有助于发现系统性问题，但若回滚次数直接用于个人绩效，团队可能推迟回滚、降低故障等级或避免发布高风险变更。指标首先应服务于风险治理和学习，再讨论如何用于绩效管理。

我更愿意将团队评价放在可控行为上，例如预案质量、风险披露及时性、演练完成度和复盘行动兑现率；对发布失败率等结果指标，则结合变更复杂度、业务风险和历史趋势解释。任何单一指标都不适合直接替代专业判断。

九、常见问题：实施团队建立回滚规范时怎么落地

1. 小团队是否需要完整指标体系

不需要一开始就建设复杂看板。小团队可以先用一份发布记录和一份事件复盘表，记录异常发现、决策、操作、验证四个时间点，并确认每次发布都有回退目标和业务检查项。等数据稳定后，再增加失败率、复发率和演练覆盖等指标。

2. 没有发生过回滚，是否还要演练

要。没有真实回滚记录，无法证明预案能执行。演练可以在测试环境、影子环境或低风险客户范围开展，重点验证权限、依赖、数据兼容、操作顺序和业务检查。演练后要记录未覆盖条件，不能把“演练通过”解释为所有故障都能恢复。

3. 数据库变更无法直接回退怎么办

先判断是否能通过向前修复、补偿任务或兼容版本恢复，而不是强行执行逆向脚本。发布设计阶段可采用先扩展结构、完成迁移、观察稳定后再收缩旧结构的渐进方式。若涉及业务数据，恢复方案必须经过数据负责人和业务负责人确认，并保留核对证据。

4. 回滚后服务正常，但客户仍然投诉怎么办

这通常说明技术健康与用户体验之间存在差距，或故障期间已经产生了持续影响。团队应检查用户操作是否需要重试、数据是否需要补偿、缓存和异步任务是否恢复，以及客户侧配置是否同步。事件关闭条件应包括客户影响处理，而不仅是监控曲线恢复。

5. 如何判断回滚流程是否成熟

不必依赖主观等级。可以随机抽取几次发布和演练，检查新接手的值班人员是否能在规定时间内找到预案、解释触发条件、执行授权步骤、完成业务验证并留下记录。若流程只能由少数熟手完成，说明它仍然依赖个人记忆，不能算稳定的组织能力。

十、总结：把“退得回去”升级为“恢复得正确”

回滚流程的价值，不是让团队更频繁地回退，而是让团队在变更风险超出承受范围时，有证据、有权限、有路径地停止损害，并尽可能快速地恢复业务。真正需要持续追踪的，不只是回滚次数和操作耗时，而是预案是否可执行、异常是否及时发现、决策是否清楚、数据是否安全、业务是否验证，以及同类问题是否反复发生。

我的核心判断是：回滚能力的上限，不由最后那条命令决定，而由发布前的兼容设计、现场的信息质量和恢复后的业务验证共同决定。先把事件时间线和成功口径统一，再选少量关键指标；用演练暴露权限、依赖和数据问题；根据系统可逆性决定自动化边界；最后把复盘行动落实到可验收的控制措施。

下一步可以从最近一次变更开始：补齐异常出现、告警、决策、操作和业务验证的时间点；明确这次恢复究竟恢复了什么；再选出一个最耗时或最容易误判的环节，安排一次针对性演练。与其先追求一张完整的回滚看板，不如先证明团队能在真实约束下安全地恢复一次。