运维自动化平台深度解码.pdfVIP

【平台篇】运维自动化平台深度解码

自动化运维是一个人让人兴奋且易失控的话题！兴奋是因为我想作一次尝试，把它的全貌和

细节说清楚；易失控是因为涉及点太多，一则怕遗漏，二则怕顾此失彼。带着这份复杂的心

情，我们来一次自动化运维的解析之旅吧。

说实话，一个运维团队的运维能力如何，其实看一个自动化管理系统便知！

********文章较长，索引目录如下*******

一、概述

二、运维自动化的三重境界

三、运维自动化的多维解读

******第一、基于应用变更场景的维度划分

******第二、基于系统层次的维度划分

******第三、基于和业务程序耦合紧密程度的维度划分

四、运维自动化的方法论

******第一、全局驱动

******第二、分而治之

******第三、自底向上

******第四、边界清晰

******第五、插件化

五、运维自动化系统的实现

******第一、DNS管理系统

******第二、CMDB管理系统

******第三、名字服务中心系统

******第四、持续部署管理系统

******第五、业务调度管理系统

六、运维自动系统的API参考实现

七、运维自动化依赖的团队模型

******第一、团队的能力模型

******第二、团队的驱动模型

******第三、团队的技能模型

******第四、参考的运维组织结构

一、概述

在前面的文章中，提到【运维的本质可视化】，在其中着重强调是自动化的可视化和数据

化的可视化。在这个文章中，全面解码看看自动化的极致状态为什么是可视化？在前面的另

外一篇文章【运维平台全体系介绍】中，也讲到运维平台体系的构成，提出“**及服务”的理

念，其中有几部分和自动化密切相关，比如说资源及服务、配置及服务、架构及服务，持续

集成服务，最终都服务于面向业务的可视化调度平台目标上去。让我们再回顾一下平台规划

体系（涉及自动化部分的，我用红色框中）：

二、运维自动化的三重境界

宋代禅宗大师青原行思（六祖门下首座）提出参禅的三重境界：

参禅之初，看山是山，看水是水；

禅有悟时，看山不是山，看水不是水；

禅中彻悟，看山仍然山，看水仍然是水。

这三种境界其实和我们眼中运维自动化的三重境界类似。

自动化第一重界：看山是山，看水是水。开始接触运维自动化的时候，我们看到了很多工

具认为就代表着自动化，比如说早期把expect+ssh封装之后，就以为可以实现批量运维。

看到有人说puppet可以做配置管理，这个时候也就认为puppet可以做配置管理，甚至是

发布管理。这个时期的典型问题，就是以偏概全，对于某个开源自动化工具来说，还没法去

界定它的使用场景和范围，直接影响系统的建设效益。这个时候已经开始知道我们看到的山

不是真正的山，是迷雾环绕的深山。

自动化第二重界：看山不是山，看水不是是水。此时我们知道expect+ssh不够，随着业务

规模的变化，我们需要一个更完整的概念来做发布系统，真正的发布系统要做版本管理、环

境管理、配置管理、还要做他们的生命周期管理等等；puppet真正要做自动化，其实还依

赖OS和应用层很多标准化。对于其他资源对象的管理来说，生命周期的概念都在穿行其中，

比如说DNS、LVS、接口、配置、应用包等等。为了有效标识资源的生命周期状态，需要

用大量的数据来实时反馈。这是运维自动化的更具体了，把一个个的山貌看清楚了。

自动化第三重界：看山还是山，看水还是水。这是一种自动化本质上的追究，站在山顶之

巅，俯览众山，会发出原来如此的感叹：所有自动化的本质都是为了可视化，让所有的人看

到一致的服务，确保结果一致；从底层来说，你会说所有自动化的本质都是指令+文件分发

的组合；你会进一步抽象系统的能力，提供即插即用的机制；结合服务化的需求，进一步云

化所有的运维系统，确保内外一致性的使用。这是化境！

三、运维自动化的多维解读

第一、基于应用变更场景的维度划分

我们增加探讨过所有的运维价值导向最终都是面向业务、面向用户，所以自然而然就需要从

业务的维度进行划分。而运维是有很多种场景的，但从业务的角度来说，核心的几种业务场

景就那么几种，如：业务上线、业务下线、业务扩容、业务缩容、应用升级等五种。我用一

种场景为例带大家把整个流程穿越起来看看，让大家和我一起识别流程的节点到底对接了哪

些系统？那么针对其他的业务场景，你也可以用同类的方法去分析。首先预设架构如下：

1、业务上线。表示一个完整的应用上线，从无到有部署整个业务上线。具体的流程如下：

仔细看其中的流程，我们会发现涉及到多个系统，每个系统完成职能都有不同，这个地方只