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

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

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

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

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

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

Server.xml参数表

Context.xml参数表

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

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

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

如何控制风险?

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

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

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!