18页PPT带你深度解读运维自动化

2015年04月04日 信息技术 暂无评论 阅读 2,700 views 次

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

********文章较长,索引目录如下*******
一、概述
二、运维自动化的三重境界
三、运维自动化的多维解读
******第一、基于应用变更场景的维度划分
******第二、基于系统层次的维度划分
******第三、基于和业务程序耦合紧密程度的维度划分

四、运维自动化的方法论
******第一、全局驱动
******第二、分而治之
******第三、自底向上
******第四、边界清晰
******第五、插件化

五、运维自动化系统的实现
******第一、DNS管理系统
******第二、CMDB管理系统
******第三、名字服务中心系统
******第四、持续部署管理系统
******第五、业务调度管理系统

六、运维自动系统的API参考实现
七、运维自动化依赖的团队模型
******第一、团队的能力模型
******第二、团队的驱动模型
******第三、团队的技能模型
******第四、参考的运维组织结构

一、概述
在前面的文章中,提到【运维的本质—可视化】,在其中着重强调是自动化的可视化和数据化的可视化。在这个文章中,全面解码看看自动化的极致状态为什么是可视化?在前面的另外一篇文章【运维平台全体系介绍】中,也讲到运维平台体系的构成,提出“**及服务”的理念,其中有几部分和自动化密切相关,比如说资源及服务、配置及服务、架构及服务,持续集成服务,最终都服务于面向业务的可视化调度平台目标上去。让我们再回顾一下平台规划体系(涉及自动化部分的,我用红色框中):

二、运维自动化的三重境界
宋代禅宗大师青原行思(六祖门下首座)提出参禅的三重境界:
参禅之初,看山是山,看水是水;
禅有悟时,看山不是山,看水不是水;
禅中彻悟,看山仍然山,看水仍然是水。

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

自动化第一重界:看山是山,看水是水。开始接触运维自动化的时候,我们看到了很多工具认为就代表着自动化,比如说早期把expect+ssh封装之后,就以为可以实现批量运维。看到有人说puppet可以做配置管理,这个时候也就认为puppet可以做配置管理,甚至是发布管理。这个时期的典型问题,就是以偏概全,对于某个开源自动化工具来说,还没法去界定它的使用场景和范围,直接影响系统的建设效益。这个时候已经开始知道我们看到的山不是真正的山,是迷雾环绕的深山。

自动化第二重界:看山不是山,看水不是是水。此时我们知道expect+ssh不够,随着业务规模的变化,我们需要一个更完整的概念来做发布系统,真正的发布系统要做版本管理、环境管理、配置管理、还要做他们的生命周期管理等等;puppet真正要做自动化,其实还依赖OS和应用层很多标准化。对于其他资源对象的管理来说,生命周期的概念都在穿行其中,比如说DNS、LVS、接口、配置、应用包等等。为了有效标识资源的生命周期状态,需要用大量的数据来实时反馈。这是运维自动化的更具体了,把一个个的山貌看清楚了。

自动化第三重界:看山还是山,看水还是水。这是一种自动化本质上的追究,站在山顶之巅,俯览众山,会发出原来如此的感叹:所有自动化的本质都是为了可视化,让所有的人看到一致的服务,确保结果一致;从底层来说,你会说所有自动化的本质都是指令+文件分发的组合;你会进一步抽象系统的能力,提供即插即用的机制;结合服务化的需求,进一步云化所有的运维系统,确保内外一致性的使用。这是化境!

三、运维自动化的多维解读
第一、基于应用变更场景的维度划分
我们增加探讨过所有的运维价值导向最终都是面向业务、面向用户,所以自然而然就需要从业务的维度进行划分。而运维是有很多种场景的,但从业务的角度来说,核心的几种业务场景就那么几种,如:业务上线、业务下线、业务扩容、业务缩容、应用升级等五种。我用一种场景为例带大家把整个流程穿越起来看看,让大家和我一起识别流程的节点到底对接了哪些系统?那么针对其他的业务场景,你也可以用同类的方法去分析。首先预设架构如下:

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

仔细看其中的流程,我们会发现涉及到多个系统,每个系统完成职能都有不同,这个地方只是大概的描述了一下。但这个流程一清晰的梳理出来,就知道我们真正要实现一个应用全部上线有多么复杂了。但看完这个图又觉得简单了,因为其实从业务上线的流程来看,我们只需要一个上层的流程调度引擎调加对应的执行器,执行器通过API和底层各个系统对接。所以说之前在框架图中,为什么要求各个专业系统一定要向上提供API,并且要求这个API的风格是一致的。

最复杂的业务上线已经梳理完成之后,其实业务下线就很简单,它是上线过程的逆过程,上线负责装,下线负责拆。

业务上线之后,随着用户活跃度的上升,此时业务的容量会有出现不足的情况,此时就需要进行业务扩容。扩容就很简单,当哪类节点不足的时候,对他进行扩容。至于扩容要做哪些变更,其实都是业务上线的子流程。比如说web层容量不够,那就无非申请机器,安装组件、下发应用包,自动化测试。这个时候需要注意:在业务上线的过程中,我们把很多的配置信息都下放到CMDB中了,但我们选择扩容的时候,就从CMDB把信息读取出来,指导变更。

应用升级,目前持续集成讲的自动化都是在这块。简单来讲,就是升级程序包、升级配置、执行额外指令等等,逃脱不了这几种模式。如果你说的这么简单,是不是我把ssh封装一个UI出来,就可以了。当然不是,这个时候需要你带着运维的理解,需要在底层做一些标准化的工作,否则你提供的是一个工具,完全没有运维的思路,比如说程序运行属主、运行路径、监控的策略等等。另外建设应用发布平台