最近我很害怕一件事情，就是运维人员不知不觉地溜达到我背后拍我肩膀，此时此刻我心里仅有一个念头：糟了，又得找我麻烦了。事情缘起上一期的投产，有兴趣的童鞋可以查看之前写的文章《一个系统小 BUG 修复投产居然花了 3 个小时来处理（上）》和《一个系统小 BUG 修复投产居然花了 3 个小时来处理（下）》。

对于业务人员来说，生产上的系统才是他们开展业务的工具，若投产这一步搞砸了的话，投诉就纷涌而来，前期所有的努力都化为乌有，真的是“只看结果不看过程”的残酷事实。当然，想要做好投产环节，除了运气成分之外，还需要一定的措施做保障，以下将逐一分享可以主动做的措施。

做好投产前检查

投产前检查分为两部分：内部检查和交叉检查。

内部检查主要是开发人员的自行检查，检查内容又分为两部分：

a．按照《上线需求清单》检查投产内容是否得到覆盖，是否出现漏缺情况。接着检查是否按规范在投产包内创建应有的目录，比如 sql（用于存放 sql 脚本），script（用于存放 shell、python 等系统脚本），哪怕空目录也没所谓，要严格遵守规范。最后检查投产文件是否按规范命名。

b．按照《投产检查列表 checklist》判断检查项是否通过。

交叉检查主要是开发团队内的复核，表现形式为开发人员交叉检查或内部投产评审。交叉检查最好由了解系统全貌的资深人员或需求分析师进行，否则达不到交叉检查的效果。

写好投产文档

投产文档是用于指导投产人员的操作步骤，其重要性不言而喻。无论是由开发团队还是由运维人员进行投产操作，投产执行步骤都必须严格要求为直接复制粘贴即可执行，或整合为脚本直接执行。除非系统已经非常成熟，投产步骤已经标准化，否则还是建议逐步操作的方式进行，多花点功夫但是心里会更踏实。

投产文档主要分为 5 大块内容，分别为投产基本信息、投产前备份、投产步骤、投产验证及回滚步骤。

a．投产基本信息主要包含投产名称（比如 XX 系统 20210225 版本投产）、投产包名称、投产包 MD5 校验码、投产时间、投产人员及关联上下游系统清单。这里着重说明关联上下游系统清单，因为系统功能投产可能会涉及上下游的改动，比如人力系统功能投产可能会牵扯到上游数仓的供数及下游 ESB（企业服务总线）的接口分发，投产前必须分析清楚上下游的影响，以便投产后进行联调验证。

b．投产前备份相信不用多说了，每个程序猿心里都有一个因备份不当造成的创伤。

c．投产步骤，如上面说的，必须严格要求为直接复制粘贴即可执行，或整合为脚本直接执行。除此之外，还要注明执行所依赖的用户、环境信息，避免执行语句没错，但因为用户环境不对报错。

d．投产验证，投产完成后对内要完成功能性校验，对外要完成业务性校验。验证内容将于第 3 点内说明。

e．回滚步骤，必须对应投产步骤进行逐步回滚，而回滚所用到的代码脚本要与投产前备份的一致。

提前准备验收列表

投产后的验证是投产阶段的黄金时间，因为在验证过程中发现的问题，只要改动不会太大，运维人员都允许睁一只眼闭一只眼的。假如投产期间没有进行验证，过后发现 BUG 要更新的话又得重走一遍上线流程，其麻烦性不言而喻。

验收列表要按照《上线需求清单》进行编写，一个需求理论上分为功能性验收和业务性验收。

a.  功能性验收主要是系统功能验证，由开发人员在投产完成后登录系统验证。功能性验收可以避免出现功能缺陷的低级错误。若投产后造成系统崩溃或核心功能不可用，也可以马上回滚降低影响。

b.  业务性验证主要是业务流程验证或数据准确性验证，由业务人员等待系统投产完成后登录系统验证。业务性验证可以及时发现业务流程缺陷或数据准确性缺陷，让业务人员不会被系统 BUG 杀个措手不及。及时发现缺陷可以选择将系统回滚或提 BUG 在下次投产时解决。

进行投产演练

无论前面的准备功夫做得如何齐全，但人不是机器，难免会百密一疏，所以在正式投产前在准生产环境进行一波投产演练，能尽可能地保证将幺蛾子扼杀在摇篮之中。这点关键是存在一套准生产环境的版本与生产环境的基本一致（服务器 IP 允许不一致）。

以上分享都是投产环节的血与泪教训的总结，请大家务必重视投产环节，别像我一样被运维人员视为“照顾对象”。