业主说我们项目经理上线很随意，“爱发就发”！

昨日参加了一个项目会议，在会上用户投诉我们项目经理上线很随意：偷偷地升级，没有知会业主方的负责人，很随意的爱发就发，部署后给个简单的说明，甚至是前后没有任何说明。【上面这一句摘自来自用户的邮件】

 

看来，管理中心在这个方面的要求规范、培训做得不够，是应该好好总结一下。以前只是针对个别同事，把自己的经验告诉他，这样还有很多项目经理，特别是新进项目经理还缺少指引。真的不能等到业主投诉，我们才去改进！何必呢？何苦呢？

 

现将以往针对IT系统部署中除安装配置过程的经验总结，分以下几个部分进行描述：

 

部署前提：

 

注：以下需要项目组建立起配置管理，以便达成以下目标。可以用作自检，检查项目组的版本管理能力。

1. IT系统存在多个运行环境，包括开发环境、测试环境、培训环境到生产环境，这些环境除培训环境可能裁减外，其他不能裁减并且需要保持物理独立；
2. 以上多个环境从左到右，版本越来越低，稳定性越来越高；部署的版本从测试环境开始逐步推向稳定的环境；
3. 任何时间，总可以找到以前部署的版本，包括程序源码、二进制执行程序以及数据库脚本、初始数据等的版本；
4. 任何时间，总可以找到与目前IT系统各个运行环境的版本。保证可以还原包括生产环境在内的相一致的任何运行环境；
5. 部署到培训环境、生产环境的版本总是已经被测试过的、在测试环境部署的版本；
6. 任何一次部署，都由部署人员进行。部署人员可以是第三方的人员，包括业主的IT人员；
7. 除部署人员，任何人不允许知道生产环境包括数据库管理员的管理账号密码；
8. 任何代码的变更，总可以做到追溯历史及原因；
9. 任何时间，都可以找到最近不超过一周的生产环境数据备份；

 

部署原因和判定级别的原则：

1. Hotfix：接收到紧急报障，故障导致生产无法正常运行，涉及的人员占该IT系统的用户群落的比例高，或者涉及的人员对IT系统有重大影响，需要评估，需要对IT系统进行紧急修复Hotfix；
2. ServicePack：常被片面称为补丁，其实往往是针对一段时间用户报障或者自身发现的缺陷进行一次重大的更新，或者针对以往的版本进行功能性、运行性能、可操作性改进，特别追加了新的功能特性，也有人称为ValuePack（增值软件包）；
3. Release：推出新的完整版本，此版本都采用全新的物理环境进行部署，当然如果有旧系统在线，往往需要考虑旧系统的数据迁移；

从上所得，Hotfix的生存生命周期短，但是一般不会频繁部署Hotfix，Hotfix一般由用户驱动，因此Hotfix的部署上线不是计划性的。ServicePack的计划性较强，但是一般也会控制频率，刚上线的系统，部署ServicePack的间隔一般从一个星期一次，逐步修订为两个星期一次，再逐步到一个月一次递减。

 

Hotfix与ServicePack对于IT系统的变化，一般都是Increament增量部署的方式，但是目前如Windows XP SP2这些称呼也在混淆对ServicePack的定位。作为原则：Hotfix只能是也只允许是增量的、部分的修订。道理很简单，举以下两例：

1. 如果你是用户测试1000多个功能点的IT系统，前面已经测试601个功能，但是602的时候，出现问题，导致无法测试下去，怎么办？来个Full更新，谁愿意相信经过你的Full更新后，前面的601个功能都还没有问题！
2. 再譬如，生产系统已经在正常运行运行，只是出了某个功能的特别故障，但是其他功能还在正常运行，如果来个Full更新，你能确认你只是更改了你要修订的部分吗？不要太自负了！

不管是Hotfix、ServicePack还是Release部署，我们很多同事一般只关心software或者hardware的installation或者config，显然被.NET的xcopy部署或者java的war、ear毒害了不少！其实这是开发转型的项目经理的片面理解。xcopy/war这些只是机器层面的问题，不是系统层面的问题，更不是服务层面的问题。

 

这里主要谈谈服务层面的问题，也是这次被用户投诉方面，需要我们进行改进的有关部署中服务层面的经验。以下经验发生在：当决定进行Hotfix/ServicePack/Release部署的时候，做出部署的计划以及方案（时间计划、系统层面的规划部署、机器层面的部署）之后。经常被忽略，但是是非常有用！

 

部署中服务层面的经验：

• 部署公告

1. 编写系统公告，简单阐述系统情况，根据部署计划和方案判定对正常系统使用的影响，如果存在部署导致系统无法继续如常使用一段时间时，请在公告中说明“造成不便，请见谅”等警语，另外需要告知预计何时系统重新正常工作！
2. 如果是HotFix部署，在编写系统公告的正文，需要阐述清楚目前紧急问题影响了那些功能，并且告知暂不要使用此功能，如果有其他可行的代替操作方案，可以在公告的正文中简要阐述并另附附件说明；
3. 如果是ServicePack部署，在编写系统公告中，阐述本次部署还来源于一些同事、部门的建议和反馈，对他们的热心使用以及热忱反馈，表示感谢，并且另附附件说明涉及的问题列表；
4. 如果是ServicePack，则在ServicePack列表中，清晰地说清楚那些是新增功能，那些是修改缺陷，那些功能被取消，那些是修订功能。（读者你能分清楚修改缺陷和修订功能吗？）对于每个变化，如果有来源和出处，请在文章中告知，譬如：来自XXX部门YYY的建议（读者你知道为什么要这么做吗？）；

• 部署公告解除

1. 当部署结果被确认的时候，准备部署结果公告；
2. 如果本次部署上线验证成功，则要在公告中告知部署已经按原定计划，成功执行，根据情况需要，可以再次提供本次更新的功能列表做附件说明；
3. 如果本次部署上线没有成功，则要在公告中告知部署没有完成，并且给出解释（读者为什么我们一定需要解释？），告知下一次的时间将另行通知（不要急着给时间，因为需要好好总结），对给大家造成的工作不便，给予致歉。
4. 如果本次部署上线部分成功，则要在告知那些已经成功，并且那些由于什么原因没有成功，用功能列表分开说明，在公告中还需要致歉。

安装配置过程（Installation and config）属于部署的系统层面问题，包括部署手册、部署Check List、部署纪要或者系统使用手册等，等待后文继续讨论。