各位社区里潜水的，冒泡的和长期在幕后辛勤保持“池塘”清洁的筒子们！提前给大家拜年啦！祝大家在新的一年里，身体健康，阖家欢乐，学业事业双进步！
大家还记得曾经看过的那部经典的美剧《越狱》以及殿堂级成长类电影《肖生克的救赎》吧？男“猪脚”们为了“脱狱”都找的是监狱容易出现漏洞的最薄弱的环节。参照来看，我们的系统也有最容易出问题的薄弱环节，就是系统内部的不一致性。这种不一致性的产生一般都是由于系统和服务被“任性”的改动所造成的。凭心而论，一般系统在完成和交付之初甲方十分希望、乙方也非常愿意把系统做得尽可能的完美，但是随着系统和服务被越来越频繁的使用，对于其功能和效率的调整和改进的需求也会如寒武纪生命大爆发一般，井喷式的增长。经过多个部门、多种IT角色“简单而粗暴”的修改后，系统虽不会千疮百孔、面目全非，但肯定已是今非昔比，且随时都有不可预料的中断风险了。
所以说，海枯石烂的紧守不变是不可能的。那句很有哲理的话怎么说的来着？“唯一不变的只有变化。”不！唯一不变的还有廉哥和大家的这份漫谈之心哦。我们的漫谈虽然不死板严肃，但是很中立的，记住，哥不是神马Tony老师，从来不会向大家推荐什么厂商或产品的。跑题了，跑题了…那么如何避免持续变更所产生的side effect，实现系统安全性和其易用性的平衡呢？我们还是要依靠管理和控制。
变更管理
马云曾说过一句话：“阳光灿烂的时候，就要修屋顶。”也就是说在还没出问题的时候，我们就要考虑到各种变化和调整的应对了。在前几次漫谈中，我们提到的事件、事故和问题流程的最终结果都可能触发IT服务变更的发生。在企业里，任何变更需求都应当用预定义的流程和工具来规范需求的提交方式并通过自动流转，做到系统能够实时记录以方便日后稽查。
在规范的企业中，变更请求一定要通过变更顾问委员会的审核。而这个委员会成员可以包括企业各种角色的代表，如业务部门用户，IT管理层，运维人员，供应/外包商等。而且具体人员可根据实际变更请求来动态调整。由变更顾问委员会对请求进行主要的风险评估。评估内容包括：提出人的角色、提出原因、变更时间、变更回报、需要的资源、对其他服务的影响等。很多企业管理者总有心存侥幸心理，觉得频繁变更请求的审核既耗时又好力，想攒到一段时间后一起撸，然后呢？就没有然后了。可是歌德老爷子不是说过吗：“今天做不成的，明天也不会做好，一天也不能够虚度。”很多改变是时不我待的，消极被动的态度非但维持不了当前的所谓“不变应万变”，反而会让IT团队甚至管理层感觉压力山大。要知道可能您和“别人家的”健康稳定系统的差别就在这里。
系统的变更往往会引起短暂的服务中断。而无论是功能性的服务变更请求还是计划性的服务中断请求都需要包含：变更程度（普通、标准或紧急），变更类型（硬件、软件、网络、通信设备或文档相关），自测风险程度（低、中或高），影响范围（全部门范围、整个企业范围、多分支机构范围），变更进度和实施计划，所涉及到的配置项数据库（Configuration Management Data Base，前面几期有提到过）里的配置项（CI），结果预期和应急补救预案等。
从安全角度来说，在实施变更之前一定要确立好整个系统的基准线，给系统的当前各种状态来个“快照”，从而成为变更后参考比对的依据。同时在变更过程中，应做好软/硬件版本管理。在实际操作中，可以参考如下变更的流程图。个人认为，套用华为企业的说法，这叫“力出一孔”。
另外，如果涉及到比较复杂或大型的变更，我们在相关的记录文档中还应适当的配上能体现变更步骤和涉及范围的流程图。这样不但能有助于理清变更的思路和波及面，还能供变更后或出现其他问题时进行参考和审计所用。
说到文档化记录，大家应该都有过这样的体验，当我们的智能手机上的APP装了太多时，其实每次我们要找某个需要的APP并不是认真看其图标的样子或下面的名称，而是从颜色及其图案上迅速判断和定位到的。因此记录文档中，我们可以事先规定好用不同颜色来定义不同类型的变更，从而便于我们从庞复的记录中一眼认出或筛选出需要查看的记录。
众所周知，这是一个“快鱼吞慢鱼”的快节奏时代，很多企业的IT决策者脑子里想着马化腾的那句“小步、快跑、迭代、试错”而嘴里念叨着“没时间解释，快上车”不断发布新的产品和服务功能。这种积极的态度是值得肯定和采取的，但是如果不想在发布之后收获莫名的抱怨或是看到老板及用户的那张张扑克脸的话，必要的管控定会为你的“爆款新品”保驾护航。
