一次成功的变更管理 | 平凡的世界，不平凡的运维(2)

"一定要记住那些细节部分，那才是关键之处，这个特别的故事发生在一个男洗手间，你得记住所有的细节，他们是用纸巾抹的手，还是用吹风机吹的"————电影《落水狗》

前言

2015年互联网发生了多起灾难性的运维故障事件，经验表明这些异常往往与变更有关系，造成这些异常的原因很多：人员疏忽、技能缺乏、未准确验证、没有影响度分析等。很多IT企业都忌讳非常规性变更，他们将其当作万恶之首、IT运维的最大敌人。在互联网兴起、强调变化的时代，唯一不变的就是变，变更不能成为阻碍IT发展的障碍。
成功的IT管理需要均衡考虑三大要素，即人员（People）、流程（Process）与工具（Technology），简称PPT。而IT管理的实践往往重流程，忽视相应的工具，从而导致人员无法适应。仅仅考虑流程，将绝大部分时间、精力和资源投入流程上的畸形的应用模式往往产生畸形的效果，要么是流程无法落地应用，要么是运维人员没有精力做技术，期望流程可以解决一切问题。

一、工欲善其事，必先利其器

前面谈到了很多变更控制流程、角色、原则，但要落实下来必须有强大的工具支持，在IT服务项目实施前就要把工具的适用性考虑进去。工具是给人用的，不是用来折磨人的，一定要注意均衡发展。

1．交互表单
用户依据向导来找到自己所需服务的目录，在每个目录下有相应的表单帮助用户准确描述自己的需求。表单由各技术组自行定义，并且依据服务内容的变化同步更新，保证足够的灵活性。表单内的字段分类有必填、可选与自动补全三类，表单与需求系统解耦，以配置文件的方式管理。如图一、图二。
一个需求要在变更主管与用户之间形成交互，对需求的内容进行确认与修正，最后定版进入审批环节。

图一 用户申请需求时需要填写对应的服务表单 图二 每个服务目录表单由服务owner自行定义，并与需求系统解耦

2．精确步骤
要保证每个变更实施的质量一致，就必须对变更步骤进行控制，保证所有的人的执行方式一致。如图三所示。

• 在进行变更设计时要定义好每个操作步骤，在步骤中描述清楚具体的实施方法。
• 步骤内容是动态的，在实施过程中实施人员可反馈、登记信息。
• 步骤之间可按照顺序、分支来执行。
• 步骤定义了明确的实施时间窗口，必须在实施时间窗口当前时间点方可执行。
• 一个变更很可能跨越多个领域的专业人员，在步骤处理人中进行选择。
• 步骤与知识库是关联的，除了说明具体如何操作，还要讲述背后的实现原理。

图三 变更步骤

3．定制模板
对于大多数已经标准化、但步骤复杂的变更，在工具上要考虑模板化，将一个变更序列固化下来，帮助运维人员快速启动一个变更计划。如图四所示。

图四 定义一个变更模板，快速启动变更
4．变更日历
管理人员、运营人员甚至业务员常常会问当天要做哪些变更？变更有没有经过审批，有没有向上级汇报，有没有评估风险，有没有分析出关联应用？面对排山倒海的问题，运维人员常常要悉心整理这些问题，逐条耐心解答，将已知的问题复述多次，极大影响效率很低。变更系统内部需要有变更日历功能将这些信息聚合在一起。如图五所示。 图五 变更日历

每次的变更可能高达60～70个，如何从中找到管理层、需求方所关注的变更？这时需要在变更系统中设计一个人性化检索面板，通过“关联对象”“影响范围”把用户关注的变更全显示出来。如图六所示。

图六 变更关联对象与影响范围

二、刑不上大夫，礼不下庶人

如果按照统一的方法管理一切大小变更，势必运维人员的大部分精力将投在流程之中，对变更提前定义，分出常规、非常规、重要、不重要，从而采用“大夫”与“庶人”的二层标准对待。

1．常规与非常规
大部分服务是提前定义好的，这类服务引发的变更被称为常规变更，变更的实施可以遵循标准步骤和知识库的指引。而除这些常规变更外，也会因其他原因在定义的服务目录之外发起变更，例如IT内部为了降低成本、优化架构等也会对现有资源进行调整，例如网络拓扑的改变、带宽出口的限速等，我们称这类情况为非常规变更。
从风险的角度来看，常规变更的影响和风险较易控制，一般有如下特征：

• 有标准化的变更模板；
• 有知识库指引；
• 重复、日常化、量大；
• 影响和风险较易控制。

而非常规变更的影响范围广、风险较高，缺乏完善的变更模板。一般具有如下特征：

• 缺乏完善的变更模板；
• 需由有资深经验的同事执行；
• 年度计划、一次性或若干次执行；
• 影响范围广、风险较高；

2．优先级
优先级用来说明变更需要得到实施的优先顺序，按照其紧急程度（即变更需要采取多快的速度来执行）来按排优先级，如表一所示。

表一 风险级别

3．风险定级
变更风险等级依据变更影响范围的大小、是否中断服务、是否造成数据丢失、变更复杂度、验证和回退方案等方面评估，分为高、中、低三个技术风险等级。
对于低风险：

• 无须特别关注，无窗口限制，影响范围小；
• 无影响或无关联影响；
• 非生产变更；
• 或有HA、单边影响；
• 或无数据丢失、服务中断；
• 或在维护窗口内。
  对于中风险需严格审批，在窗口内实施。符合下述任何条件之一的为中风险：
• 紧急变更；
• 没有回退和应急方案；
• HA同时实施，服务中断；
• 在服务窗口内；
• 技术不成熟；
• 没有测试过；
• 没有验证方案。

对于高风险，需汇报，沟通窗口，变更序列确认，需验证、监控。符合下述任何条件之一的为高风险：

• 架构变化；
• 新技术引入；
• 没有先例；
• 技能要求高、需厂商参与；
• 复杂度高；
• 影响重要系统（一类）；
• 变更涉及有容量瓶颈对象；
• 无法全面验证；
• 无法充分评估关联影响。
  可以参考表二所列的衡量因素来评估实施变更可能带来的风险，对于已知的变更类型，应事先按衡量因素定义好变更的技术风险等级。

表二 变更风险衡量因数 表二续 变更风险衡量因数

三、Keep it simple， stupid！

如果你已经到了这里，很高兴的告诉你，你已经完成了工具、流程部分，最后是人的要素了。对于运维人员，越简单的规则越适用于执行，因此他们（准确说是我们）只需要记住18个字：走变更、知明细、先配置、分批次、准验证、快升级
1. 走变更
所有需求要全部进入变更流程管理系统中，而不能通过一封邮件、一个电话直接执行。
2. 知明细
清楚我们有哪些服务目录，用户的需求如何与目录匹配，是否有例外需求，变更模板中的每种技术实现的影响是什么，变更的风险级别是什么。
3. 先配置
在变更实施前保证配置先行。例如搭建一个新的网络区域，在实施具体的操作前，先将所有设备信息录入到CMDB中，设置好CI之间的属性与关联，避免配置遗漏、后续无据可查。
4. 分批次
对于变更对象多、涉及面广的变更，要将变更对象分批次、安排多次变更执行。
5. 准验证
实施完成后要有准确的验证方法，做好备份、做好回滚方案。
6. 快升级
中途出现异常，在一定时间内无法解决的，应尽快升级，让相关人等及时知情。

《PaaS实现与运维管理》，一本云计算时代不可多得的运维好书，详述大规模容器与大数据平台运维实践，业内数十位专家一片好评、鼎力推荐。十二月，让我们敬请期待！

PaaS实现与运维管理：基于Mesos+Docker+ELK的实战指南