3.6 维护与演化：运营返修与延寿

3.6 维护与演化：运营返修与延寿

发车不是终点，列车要在正线上跑很多年。业界的老话是软件成本的大头在上线之后——维护与演化花掉的钱通常超过初始开发。本节讲维护的四类构成、可维护性怎么在设计期就赚出来、技术债怎么记账，以及什么时候该承认一趟车该退役了。这也是本章的收束：旅程的最后一站，接回下一班列车的始发站。

上线不是终点站

维护不是"修修补补"一个词，它有四类正经业务，构成比例长年稳定：

完善性维护占大头——用户用了才有真需求，上线后的新需求比立项时全部想法还多。预防性维护占比最少，却最常被挤掉：它不响铃、不报警，不做也不会立刻出事，于是永远排在"更急"的事后面。

图 3-5：一趟列车的年度维护账

可维护性是设计期赚出来的

维护难受不难受，上线那天就已经定了。可维护性高的系统有四个可辨识的特征：模块边界清楚（改动范围可预估）、测试托底（改完敢发布）、文档够用（新接手的人两周能定位问题）、监控可观测（线上异常自己说话）。这四条没有一条能靠上线后补课补出来——它们全部诞生在第 3.2 节的设计图纸和第 3.3 节的走查清单里。维护成本高的团队，多半是当年设计期省了评审的团队。

给维护者的实用交接清单：

接手一个系统的头两周，先找齐这五样：
  1）需求基线或功能清单 —— 知道它该干什么
  2）架构图与模块说明   —— 知道它由什么组成
  3）测试套件与运行方式 —— 知道改完怎么自证
  4）部署文档与环境说明 —— 知道它跑在哪、怎么发
  5）最近半年的缺陷榜   —— 知道哪里最容易坏
五样缺两样以上，先补记录再动代码；
边补边修是欠账系统最经济的接手方式。
​

技术债：把拖延记成账

技术债是对"为了赶工期而绕开好设计"的记账说法。债务本身不是恶——为抢节点欠债是正当的经营决策；恶的是欠了不记账。凭空消失的债务不会消失，它化成每次改动变慢、每版缺陷变多的形式计息。记账的载体可以很朴素：债务清单写明欠什么、为什么欠、利息是什么、什么时候还，放进迭代计划当成正经故事排期。

技术债清单 · 云梯平台（节选）
  编号 TD-03
  欠什么：运费计算散落在三个模块，未收敛到规则引擎
  为何欠：上线赶税期，直接在原处加分支
  利息：每次补贴规则变更需改三处，漏改即错账
        —— 过去半年因此产生两起线上缺陷
  还法：收敛到规则引擎，预计 12 人日
  排期：迭代九、迭代十各排 6 人日
​

退役也要被当成正经决策。一趟车该退役的信号：维护成本超过重建成本、原班人马已无人能读懂它、它支撑的业务已萎缩。体面的退役包括数据迁移方案、并行运行期与关站公告——比让它半死不活地挂着便宜得多。

工单分级：维护现场的交通规则

维护活动的日常运转靠一张工单分级表撑住秩序。云梯的四级分法：致命（计费错误、服务不可用）——响应按小时计，优先级压倒一切；严重（核心功能受阻有替代路径）——当日响应，排入当班；一般（非核心功能问题、体验缺陷）——按迭代排期；建议（改进愿望）——进需求池走商业论证。分级表的价值在于把"催得紧的先修"改写成"影响大的先修"——催办音量反映的是嗓门，分级反映的是业务影响。配套一条纪律：任何工单在立案时定级，改级要有记录，"领导打过招呼"不是合法的改级理由。

大修还是重建：一笔算得清的账

老系统改不动时，团队迟早面对"继续大修还是推倒重建"的选择题。云梯的决策演算值得参考：

[演算] 旧结算工具 · 大修与重建的对比
  共同前提：业务要求未来两年新增约二十条规则。

  方案一 大修（在旧系统上收敛规则引擎）：
    直接成本：约 60 人日
    风险：旧代码无测试托底，回归靠人工抽查，
          每次改动需资深成员压阵，机会成本另计
    两年维护预估：年均 90 人日（维持旧有缺陷率）

  方案二 重建（引擎层重写，数据与界面沿用）：
    直接成本：约 110 人日
    风险：切换期双轨并行，需要数据核对专项
    两年维护预估：年均 55 人日（缺陷率随结构改善下降）

  两年总账：大修 240 人日 上下，重建 220 人日 上下，
  但重建的上限收益还包括规则变更响应速度的提升。
  决策：重建，且从变更最频繁的规则层动刀，
  而非整体推倒——界面与数据层继续服役。
​

注意结论的克制：重建不等于全盘推倒，只重建欠账最重的那一层。多数"重建失败"的项目，败在把仍然健康的部分也捆进重建的车头，交付遥遥无期，旧系统还得继续撑着——两头的成本一起付。

缺陷预算：维护期的节奏器

维护团队常被线上问题打乱节奏——计划好的完善性工作总被突发缺陷冲掉。云梯的办法是给每个迭代设缺陷预算：按近三班的缺陷流入量定一个额度（比如每人每班一到两条的修复量），预算内按分级顺序消化，超预算的部分触发两件事——先用燃尽图把冲击显性化，再追流入源头（新版本引回的？某个模块劣化的？）。预算制的妙处在于把"被打断"从情绪问题变成数据问题：连续几个班次超支，说明产品在带病扩张，该减速修车而不是继续加货；预算内平稳，说明系统健康，完善性工作就能安心推进。节奏器一响，调度台就有了干预的依据。

两个高频疑问

问：维护工程师是不是低人一等的岗位？ 这是个昂贵的误解。维护岗直面系统的真实复杂性：诊断能力、影响面判断、与小步改动的风险控制，全是开发新功能用不到的稀缺技能。让新人从维护入手，是行业验证过的高效成长路径——先读懂别人的系统，再设计自己的。

问：线上小修要不要走完整流程？ 流程可以缩，不能跳。紧急修复的简化路径是：单线走查（一位同事实时复核）、修复后补回归用例、复盘时补变更记录。省掉的只是形式的时间，留痕与验证两样实质一样不能少——"紧急"是压缩流程的理由，从来不是取消流程的理由。

本节要点回顾

• 维护分纠正、适应、完善、预防四类，完善性占大头，预防性最常被挤掉也最贵。
• 可维护性四特征（边界、测试、文档、监控）全部在设计期决定，上线后补不了课。
• 接手系统的五样交接清单，缺两样以上先补记录再动代码。
• 技术债必须记账：欠什么、利息、还法、排期，进迭代计划而非凭空消失。
• 退役是正经决策，迁移、并行、公告三件套好过半死不活。

至此一趟列车跑完全程。下一章转到调度台——这趟车该几点发、预算几何、中途怎么盯。