【.com原稿】根据蔡加尼克记忆效应，人们总是对未完成的任务印象深刻。虽然我经常把话题转移到“神奇”的云平台项目上，但是大家还是愿意回到我们整体设计和治理的主路上来的，对吧？好吧，让我们“用冷水洗脸”，继续说系统的日常运维。还记得经典美剧《越狱》和成长神片《肖生克的救赎》吗？男性“猪脚”总是在监狱中寻找最容易出现漏洞的薄弱环节，以求“出狱”。作为参考，我们的系统也有一个最容易出问题的薄弱环节，就是系统内部的不一致。这种不一致通常是由对系统和服务的“故意”更改引起的。平心而论，在一个通用系统的完成交付之初，甲方是非常希望的，乙方也非常愿意把系统做的尽可能的完善。但是，随着系统和服务的使用越来越频繁，对其功能调整和效率提升的需求也会像寒武纪的生命大爆发一样呈井喷式增长。经过多部门、多IT角色的“简单粗暴”修改，虽然系统不会千疮百孔，彻底改变，但绝对不是以前的样子，随时都有不可预知的中断风险。因此，不可能一成不变。这句很有哲理的句子怎么说？“唯一不变的就是变化。”不！唯一没变的就是莲哥和大家的周聊如期而至。我们的闲话虽然不死板、不严肃，但很中性。请记住，我不是托尼先生，我绝不会向您推荐任何制造商或产品。题外话，题外话……那么如何避免持续变化带来的副作用，在系统安全性和易用性之间取得平衡呢？还是要靠管控。变革管理马云曾说过：“天高地厚，必修屋顶”。也就是说，在出现任何问题之前，我们必须考虑各种变化和调整。在之前的漫谈中，我们提到了可以触发IT服务更改的事件、事故和问题流程的最终结果。在企业中，任何变更需求都应该使用预定义的流程和工具来规范需求的提交，并通过自动流转，让系统实时记录，方便日后审计。在监管良好的企业中，变更请求必须由变更咨询委员会审查。该委员会的成员可以包括企业中各个角色的代表，如业务部门用户、IT管理人员、运维人员、供应商/外包商等，具体人员可以根据实际变更需求进行动态调整。请求的主要风险评估由变更咨询委员会执行。评估内容包括：提议者的角色、提议的原因、变更时间、变更返回、需要的资源、对其他服务的影响等。很多业务管理者总是有一种侥幸心理，认为频繁的changerequest的review费时费力，想积攒一段时间一起工作，然后呢？不会再有了。可歌德先生不是说过：“今天做不好，明天也做不好，一天也不能虚度”。许多变化并不等着我们。》，反而会让IT团队甚至管理层感到很大的压力。要注意，这可能是你的健康稳定系统和“别人的”的区别。系统变更往往会导致短暂的服务无论是功能性服务变更请求还是计划性服务中断请求，都需要包括：变更程度（正常、标准或紧急）、变更类型（与硬件、软件、网络、通信设备或文件），以及自评估风险程度（低、中、高）、影响范围（部门范围、企业范围、多分支范围）、变更进度和实施计划、涉及的配置项数据库（ConfigurationManagementDataBase，在之前的issues中提到配置项（CI），结果预期和应急补救计划等。从安全的角度来看，在实施变更之前，必须建立整个系统的基线，以及必须拍摄系统当前状态的“快照”，这将成为更改后比较的基础。同时，在变更过程中，要做好软件/硬件的版本管理。在实际操作中，可以参考下面修改后的流程图。我个人认为，套用华为的话，这就是所谓的“实力出洞”。此外，如果涉及到比较复杂或规模较大的变更，还应适当增加流程图，在相关记录中反映变更的步骤和涉及的范围。这不仅有助于理清变更的思路和范围，也可以作为变更后或出现其他问题时的参考和审核。说到文件记录，大家应该都有过这样的经历。当我们的智能手机上安装了太多的应用程序时，其实每次我们想要找到我们需要的应用程序时，我们都不会仔细看它的图标或下面的名称，而是通过颜色和图案快速判断和定位.因此，在记录文档中，我们可以预先定义不同类型的变化，用不同的颜色表示，这样我们就可以一眼就从复杂的记录中识别或筛选出需要查看的记录。众所周知，这是一个“快鱼吞慢鱼”的快节奏时代。不少企业IT决策者想起马化腾那句“小步快跑、迭代试错”，口口声声“来不及解释，上车”，不断发布新的产品和服务功能。这种积极的态度值得肯定和采纳，但如果你不想在发布后收到莫名其妙的抱怨，或者看到老板和用户的扑克脸，必备的控绝对是你“爆款新品”的保驾护航。发布管理在企业运营过程中，新的或变更的IT服务往往以项目实施的形式发布。常规发布流程包括：发布策略制定与规划、回滚计划、分发与安装、试运行、测试与验收、用户支持与培训。其中，在制定发布策略的阶段，更要考虑分时空的实施方案。比如第一季度在亚洲区所有分行实施，第二季度在欧洲区所有分行实施。在充分控制兼容性的同时，做好新旧系统的共存。一旦发现新系统影响了现有的其他IT服务，可以允许用户根据回滚计划紧急完成返回旧系统，为消除影响争取时间。例如，新的邮件系统出于安全考虑不能让用户发送超链接，但并不是所有用户都能立即接受和更改。这需要逐渐改变用户行为。在配送阶段，要注意自动与人工的互补。毫无疑问，IT服务（尤其是软件）的自动化分发可以保持发布的一致性，并突破时间和空间的限制，在一定程度上减少IT人员手动安装的时间和重复。但是对于自动发布过程中的一些错误排查、场景判断等尝试，比如某个系统的补丁包，手动安装的优势是显而易见的。因此，企业普遍应采用“先自动后人工攻关”的互补模式。在安装阶段应注意“推/拉组合”。“推送”是指将IT服务从总部服务器推送到各个用户终端电脑。因为是强制性的，所以普遍适用于常用和重要的服务。而“拉”就是每台用户终端计算机从总部服务器获取IT服务（尤其是软件）。比如病毒库的升级包，可以让用户在觉得个人业务不急的时候，从总部“拉”出来，不影响其他应用的运行速度。当然，也有一些用户从不主动“拉”，这就需要“推/拉结合”。推”安装。是不是感觉有点像现在流行的“推塔”游戏？至少我觉得有点像。在验收阶段，除了保证只有正确的、授权的、经过测试的软件/硬件版本可以部署到实际运行环境，IT部门也要注意及时更新配置项数据库（已经提到），尤其是错误知识库的建立。知识库应该描述状态用普通用户容易理解的语言描述问题/错误，避免重复。在内容更新方面，IT部门除了自行维护外，还需要定期从企业的知识库界面收集导入。软件/硬件供应商，可在新服务发布前夕向所有用户公布已知错误知识库中的相关突出内容，合理控制用户预期和使用经验。此外，服务发布也离不开相应的技术支持和用户培训。总的来说，这次给大家分享的治理和控制这两个方面，是大家在工作中经常遇到的，理论上也比较容易理解。俗话说，“望远镜可以帮助你看清目标，但不能缩短你要走的距离”。所以真正的修行还是需要一个长期坚持的过程。我身边有朋友很欣赏我每周写一篇文章的毅力。事实上，让我告诉你，我一直坚持120法则。我不仅把每周固定的7天乘以120%，也就是提前8到9天为接下来的漫游做准备；如果定为100分，那我会努力达到120分的水平。足够的灵感？不如加入我们的朋友圈，一起来群里聊聊吧？【原创稿件，合作网站转载请注明原作者及出处为.com】
