【51CTO.com原创稿件】根据蔡格尼克记忆效应，人们总对那些没完成的任务印象深刻。虽然哥时常将话题岔开到那个“神奇”的云平台项目，但想必大家还是愿意继续回到我们整体设计与治理的主路上吧?好，那就让我们“冷水洗把脸”回来继续聊系统的日常运维方面吧。
大家还记得曾经看过的那部经典的美剧《越狱》以及殿堂级成长类电影《肖生克的救赎》吧?男“猪脚”们为了“脱狱”都找的是监狱容易出现漏洞的最薄弱的环节。参照来看，我们的系统也有最容易出问题的薄弱环节，就是系统内部的不一致性。这种不一致性的产生一般都是由于系统和服务被“任性”的改动所造成的。凭心而论，一般系统在完成和交付之初甲方十分希望、乙方也非常愿意把系统做得尽可能的***，但是随着系统和服务被越来越频繁的使用，对于其功能和效率的调整和改进的需求也会如寒武纪生命大爆发一般，井喷式的增长。经过多个部门、多种IT角色“简单而粗暴”的修改后，系统虽不会千疮百孔、面目全非，但肯定已是今非昔比，且随时都有不可预料的中断风险了。
所以说，海枯石烂的紧守不变是不可能的。那句很有哲理的话怎么说的来着?“唯一不变的只有变化。”不!唯一不变的还有廉哥和大家每周如期而至的这份漫谈之心哦。我们的漫谈虽然不死板严肃，但是很中立的，记住，哥不是神马Tony老师，从来不会向大家推荐什么厂商或产品的。跑题了，跑题了…那么如何避免持续变更所产生的side effect，实现系统安全性和其易用性的平衡呢?我们还是要依靠管理和控制。
变更管理
马云曾说过一句话：“阳光灿烂的时候，就要修屋顶。”也就是说在还没出问题的时候，我们就要考虑到各种变化和调整的应对了。在前几次漫谈中，我们提到的事件、事故和问题流程的最终结果都可能触发IT服务变更的发生。在企业里，任何变更需求都应当用预定义的流程和工具来规范需求的提交方式并通过自动流转，做到系统能够实时记录以方便日后稽查。
在规范的企业中，变更请求一定要通过变更顾问委员会的审核。而这个委员会成员可以包括企业各种角色的代表，如业务部门用户，IT管理层，运维人员，供应/外包商等。而且具体人员可根据实际变更请求来动态调整。由变更顾问委员会对请求进行主要的风险评估。评估内容包括：提出人的角色、提出原因、变更时间、变更回报、需要的资源、对其他服务的影响等。很多企业管理者总有心存侥幸心理，觉得频繁变更请求的审核既耗时又好力，想攒到一段时间后一起撸，然后呢?就没有然后了。可是歌德老爷子不是说过吗：“今天做不成的，明天也不会做好，一天也不能够虚度。”很多改变是时不我待的，消极被动的态度非但维持不了当前的所谓“不变应万变”，反而会让IT团队甚至管理层感觉压力山大。要知道可能您和“别人家的”健康稳定系统的差别就在这里。
系统的变更往往会引起短暂的服务中断。而无论是功能性的服务变更请求还是计划性的服务中断请求都需要包含：变更程度(普通、标准或紧急)，变更类型(硬件、软件、网络、通信设备或文档相关)，自测风险程度(低、中或高)，影响范围(全部门范围、整个企业范围、多分支机构范围)，变更进度和实施计划，所涉及到的配置项数据库(Configuration Management Data Base，前面几期有提到过)里的配置项(CI)，结果预期和应急补救预案等。
从安全角度来说，在实施变更之前一定要确立好整个系统的基准线，给系统的当前各种状态来个“快照”，从而成为变更后参考比对的依据。同时在变更过程中，应做好软/硬件版本管理。在实际操作中，可以参考如下变更的流程图。个人认为，套用华为企业的说法，这叫“力出一孔”。
另外，如果涉及到比较复杂或大型的变更，我们在相关的记录文档中还应适当的配上能体现变更步骤和涉及范围的流程图。这样不但能有助于理清变更的思路和波及面，还能供变更后或出现其他问题时进行参考和审计所用。
说到文档化记录，大家应该都有过这样的体验，当我们的智能手机上的APP装了太多时，其实每次我们要找某个需要的APP并不是认真看其图标的样子或下面的名称，而是从颜色及其图案上迅速判断和定位到的。因此记录文档中，我们可以事先规定好用不同颜色来定义不同类型的变更，从而便于我们从庞复的记录中一眼认出或筛选出需要查看的记录。
总所周知，这是一个“快鱼吞慢鱼”的快节奏时代，很多企业的IT决策者脑子里想着马化腾的那句“小步、快跑、迭代、试错”而嘴里念叨着“没时间解释，快上车”不断发布新的产品和服务功能。这种积极的态度是值得肯定和采取的，但是如果不想在发布之后收获莫名的抱怨或是看到老板及用户的那张张扑克脸的话，必要的管控定会为你的“爆款新品”保驾护航。
发布管理
在企业运营过程中，往往新的或是需要变更的IT服务是以项目实施的形式进行发布的。常规发布的过程包括：发布策略的制定与规划，回退计划，分发与安装，试运行，测试与验收，用户支持与培训。
其中，在发布策略制定阶段我们要多考虑采取分时间和空间的实施计划。如一季度在亚洲区各分公司实施，二季度在欧洲洲区各分公司实施。在充分控制好兼容性的情况下做好新旧系统的共存。一旦发现新系统有影响到其他现有IT服务的时候，可以让用户根据回退方案退回到旧系统应急完成，从而给消除影响争取了时间。比如说新的邮件系统出于安全性考虑，无法让用户发送超级链接，但这并不是所有用户都能马上接受并转变的。这就需要有个用户行为渐变的过程。
而在分发阶段应注意自动与手动互补。无疑，自动分发IT服务(特别是软件)可以保持发布的一致性，且突破了时间和空间的限制，一定程度上减轻了IT人员手动安装的时间和重复劳动。但对于一些自动发布过程中的错误勘测，场景判断以及其他方法的尝试，如某个系统的补丁包，手动安装的优势就很明显。因此企业一般应采取“自动在先，手动攻坚”的互补模式。
在安装阶段应注意“推/拉结合”。“推”是指IT服务由总部服务器推送到各个用户终端电脑上，因为带有一定的强制性，所以一般适用于普遍使用且重要的服务。而“拉”是指各个用户终端电脑从总部服务器获取IT服务(特别是软件)。如病毒签名库的升级包，可以让用户在觉得个人业务不急迫的情况下从总部“拉”过来，而不会影响到其他应用程序的运行速度。当然也有些用户从来不去主动“拉”，这就需要“推/拉结合”了，即对于在规定的一段时间周期后总部勘测到没有进行“拉”操作的用户，就会强制性的“推”送过去进行安装。是不是感觉有点像时下流行的“推塔”游戏?至少我觉得有点像。
在验收阶段，IT部门除了确保只有正确的、被授权的和经过测试的软/硬件版本才能部署到实际的运营环境以外，还应该注意及时更新配置项数据库(有提到了哦)，特别是已知错误知识库的建立。该知识库应当运用普通用户所容易理解的语言来描述问题/错误的状态且避免重复。在内容更新方面，IT部门除了自我维护外，还需定期从软/硬件供应商的知识库接口收集和导入。已知错误知识库里的相关突出内容可以在新的服务发布前夕向全体用户公示，从而合理控制好用户在使用中的期望值和体验度。此外，相应的技术支持和用户培训也是服务发布所必不可少的环节。
总的说来，这次跟大家分享的两个治理和控制方面，是大家工作中经常遇到，理论上也比较容易明白的。正所谓“望远镜能帮你看清前进的目标，却不能缩短要走的路程。”所以真正践行还是需要一个长期坚持的过程。
有周围小伙伴们赞赏我每周一篇的毅力，其实告诉大家吧，哥一直在坚持120法则。我不但在每周固定7天时间上乘以120%，也就是提前8到9天做下一篇漫谈的准备;我还时常和我的朋友圈里的大神们交流，将对每期漫谈的期望值设定为100分，那么我就力争做到120分的水平。够励志吧?要不你也加入我们的朋友圈，大家群聊呗?
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
