稳定期与向运维团队的交接

一句话总结

稳定期不是修复剩余缺陷的时间，而是让运维组织能够独立运行系统的时间。误解这一点，合同结束后电话仍会不断打来。

为什么这是一个问题

因为紧急的事与重要的事方向恰好相反。上线后故障和咨询大量涌入，每天都被响应工作填满；运维文档和知识转移则不断以“先熬过这一周”为由推迟。

等稳定期结束，SM 负责人会在不了解系统的情况下接手。几个月后凌晨两点的电话，就是最终结果——合同虽然已经结束，但唯一能询问的人还是你。稳定期的成果不应以“发生了多少起故障”衡量，而应以**“没有我们之后，系统能否继续运转”**衡量。

稳定期通常持续 3～6 个月

合同中通常有“稳定期”条款，指上线后一段时间内，由承建方负责故障响应和初期缺陷修复。许多新人会误解这一阶段的性质。稳定期不是“修复剩余缺陷的时间”，而是 “让运维组织能够独立运行系统的时间”。

因此，稳定期要做的工作分为三类。

1. 响应真实故障与咨询（紧急工作）
2. 编写运维文档——操作员手册、故障响应流程、批处理运维指南（重要工作）
3. 知识转移——培训 SM 负责人、共同值班、签署交接确认书（合同义务）

如果只顾紧急工作，稳定期结束那天，SM 负责人仍会一无所知。 六个月后凌晨两点，你就会接到电话。合同结束了，电话却不会结束。

上线后一周实际会发生什么

时间点	典型问题
上线当天上午	登录洪峰——全体员工同时连接。连接池与会话配置是第一道关卡
第 1～2 天	页面错误咨询。大部分是数据问题（代码值缺失、迁移数据异常）
第 3 天	首次夜间批处理结果异常，暴露数据迁移边界条件
第 1 周	首次执行月末/每周业务，“这个页面在哪里？”的咨询激增
第 1 个月	首次月结，出现统计与结算数字不一致的报告

可以看到固定模式：上线后大多数问题不是代码缺陷，而是数据和配置问题。 因此，割接阶段编写的数据验证脚本和配置备份，会贯穿整个稳定期持续使用。

故障响应的标准流程

在现场偏离这个顺序，情况通常会变得更糟。

1. 접수·기록      언제, 누가, 무슨 화면에서, 어떤 메시지
2. 영향 범위 파악  전체인가 일부인가. 특정 사용자/특정 데이터만인가
3. 임시 조치      서비스 복구 우선 (재기동, 우회, 기능 임시 차단)
4. 원인 분석      로그·모니터링·최근 변경 이력
5. 항구 조치      코드/데이터/설정 수정과 배포
6. 재발 방지      모니터링 추가, 검증 로직 추가, 문서 갱신

不要调换第 3、4 步的顺序。坚持查明全部原因后再处置，只会延长故障时间。 不过，执行第 3 步时必须保留证据——如果重启前没有保存线程转储和日志，原因可能永远无法查明。 “先重启就好了”重复三次后，第四次可能连重启也无法解决。

缺陷台账与“缺陷还是需求”的争论

稳定期最大的冲突就是以下对话。

客户——“这个不能用，属于缺陷，请修复。”

承建方——“这不在需求中，属于追加开发。”

这场争论的依据是需求定义书和 RTM。 因此，第一个月制作的文档，会在第八个月保护公司。

缺陷管理台账应这样维护。

• 缺陷 ID / 登记日期 / 登记人 / 现象 / 复现步骤 / 严重度（致命、中、轻）/ 负责人 / 处置日期 / 处置内容 / 判定（缺陷/请求/咨询）
• 判定列是核心。没有判定，所有问题都照单修复，项目就永远不会结束。

严重度标准也应提前达成共识。通常，“致命”表示业务中断，“中”表示可以绕行， “轻”表示使用不便。不同严重度对应不同响应时间（SLA）。

转交给 SM（维护）时必须交付什么

交接确认书中应列出清单，实际工作至少需要以下内容。

• 系统架构图（服务器、端口、账户、路径——必须与实物一致）
• 部署流程和回滚流程（实际完整执行过一次）
• 批处理清单：计划时间、前后依赖关系、失败时的处置方式
• 接口清单：对接系统、负责人联系方式、故障时联系顺序
• 账户清单：数据库、WAS、OS、外部系统（以及密码管理主体）
• 已知问题与临时措施清单——绝不能隐瞒。 反正三周内就会暴露
• 监控项目与阈值

维护阶段的工作是什么

SM 不是“系统坏了就修”的工作。实际工作比例大致如下。

• 40% 变更请求（法律修订、业务规则变化、增加页面）
• 25% 定期工作（批处理监控、月结/季结支持、备份确认）
• 20% 咨询响应
• 15% 故障响应

因此，SM 负责人需要的能力不是“快速开发”，而是 “准确判断影响范围的能力”。知道增加一个列会影响三个对接系统的人，才是优秀的 SM。 这种判断最终依靠接口定义书和表定义书。 文档在项目结束后才真正体现价值。

生产现场中的常见情况

上线第一周的事件顺序几乎是固定的。

当天上午会出现登录洪峰。全体员工同时连接，因此连接池和会话配置是第一道关卡；如果卡在这里，看起来就不只是系统故障，而是整个上线失败。 第 1～2 天会收到页面错误咨询，其中相当一部分并非缺陷，只是“与旧系统不同”。如果全部登记为缺陷，缺陷台账几天内就会膨胀到数百条，真正缺陷反而被埋没。

因此，这一时期最重要的文档是缺陷台账的分类标准。如果每次临时判断属于缺陷还是新需求，每次都会发生争论；如果标准已经存在，判定就只是行政工作。

交接也是如此。最后一周集中进行的培训不会留下多少效果。SM 负责人真正参与并共同处理真实故障的次数，才是交接质量的真正指标。