运维DevOps体系解析与落地实践(2)

首先，要指定组件的范围，既找到上文我们所说的和开发关联密切的组件，每种组件抽象出操作集合，并把这些操作标准化和脚本化，如下图：

有了这些梳理，接下来就可以进行系统建设，在系统划分时，需要遵循以下两个原则：

• 其一，闭环原则，每个组件层面的操作是个封闭集合，既系统要能囊括这个组件变更的方方面面。
• 其二，横向抽象原则，对于各个组件共性方面进行横向抽象，用一个系统来完成。比如每个组件都会有配置文件的管理，这类就可以抽象出组件的配置中心平台统一管理。

接下来，以配置举例，我们来看看是如何构建这个系统的。

Crab统一配置平台是唯品会针对组件层面做的配置管理平台，每一个组件都由代码和配置两部分组成，我们操作最多的也是对这些配置的修改，但绝大多数配置是不需要修改的，也就是和应用属性无关。以tomcat为例，在众多配置中，只有Server.xml和Context.xml需要进行个性化设置，而在这些个性化设置里，也只有如下参数需要动态调整，如下图：

Server.xml参数表

Context.xml参数表

Crab把这些参数进行key值化，然后抽象出模板的概念。原理如下图：

其中有一些细节需要注意：

• key分为通用型和自定义型，通用型的key基本和业务无关，或者可以说是标准化后的标准，例如服务的端口号，这些由运维把控，全网生产统一，自定义型的key和业务相关，可以交由研发来掌控，当然，这两种类型的key是可以互换的，然而由自定义向通用型过渡是一个比较麻烦的过程，要小心操作。
• 某些场景下，key值会对应多个value，例如同样是php最大进程数，物理机和容器是不同的，同一个应用，在不同的IDC配置也会有不同，这些需要在渲染过程中加入下发者对象才能实现，这种特殊逻辑越少越安全。

如何控制风险?

当系统权限放开到业务开发时，面临的最大问题是风险失控，这里需要强调一点，DevOps并非不要流程，我看过很多DevOps体系丧失流程的概念，效率提升了，却忘记了运维三角型中运维的及格线：质量。

唯品会的体系中是通过风险矩阵来控制变更风险的。我们发现每一次变更其实是由三部分构成的:变更对象、操作类型及执行变更的人，但当我们系统化后，变更执行人的因素会变弱很多，所以一个风险矩阵真正起作用的是变更对象是否是核心，操作过程是常规还是特殊，由历史数据推断操作的风险系数，这样我们就得到一个变更风险矩阵，如下表：

高风险的变更仍然需要人工审核介入，但审核的内容由原来的执行步骤转变为需求是否合理以及操作时间是否合理。ITIL的变更流程依然存在，只不过蜕化为第二层，对用户不可见，蜕化后的系统结构如下图：

如何持续改进?

评价DevOps的指标有两个，一个是整个变更的平均完成时间，这个时间可以分为高风险，中风险和低风险三个纬度，我们目标是降低低风险和中风险的变更时间，高风险一般不做时间要求。另外一个是研发的自助变更率，当然，有些变更必须运维才能完成，这类变更在统计时要排除在外。

总结

DevOps落地过程中最麻烦的是观念转变，既原来运维的工作开发凭什么承担，这就需要前期的宣导培训，最好是让部分开发参与到前期DevOps系统需求中来，让大家看到实实在在的好处，不能为了DevOps而DevOps。

DevOps和ITIL二者理念不同，但关注点相似，并不存在必须舍弃一种的说法，可以在质量和效率之间选取平衡。如果说ITIL需要自上而下贯彻实施，那么DevOps则需要变更的执行者、需求者参与，二者最后会贯穿整个链路。

最后，还是那句话，没有好不好，只有合不合适，只有最合适的，才是最好的。

【编辑推荐】

1. DevOps工程师实际上是做什么的？
2. 2018年值得推荐的10个开源DevOps工具！
3. DevOps性能测试的优秀实践与工具
4. 把运维和开发放一起就是DevOps？还差得远！
5. DevOps对你意味着什么？

（编辑：ASP站长网）