深度解读运维自动化
说实话，一个运维团队的运维能力如何，其实看一个自动化管理系统便知！ios
********文章较长，索引目录以下*******web
1、概述数据库
2、运维自动化的三重境界后端
3、运维自动化的多维解读api
******第1、基于应用变动场景的维度划分架构
******第2、基于系统层次的维度划分app
******第3、基于和业务程序耦合紧密程度的维度划分负载均衡
4、运维自动化的方法论框架
******第1、全局驱动运维
******第2、分而治之
******第3、自底向上
******第4、边界清晰
******第5、插件化
5、运维自动化系统的实现
******第1、DNS管理系统
******第2、CMDB管理系统
******第3、名字服务中心系统
******第4、持续部署管理系统
******第5、业务调度管理系统
6、运维自动系统的API参考实现
7、运维自动化依赖的团队模型
******第1、团队的能力模型
******第2、团队的驱动模型
******第3、团队的技能模型
******第4、参考的运维组织结构
1、概述
在前面的文章中，提到【运维的本质---可视化】，在其中着重强调是自动化的可视化和数据化的可视化。在这个文章中，全面解码看看自动化的极致状态为何是可视化？在前面的另一篇文章【运维平台全体系介绍】中，也讲到运维平台体系的构成，提出“**及服务”的理念，其中有几部分和自动化密切相关，好比说资源及服务、配置及服务、架构及服务，持续集成服务，最终都服务于面向业务的可视化调度平台目标上去。让咱们再回顾一下平台规划体系（涉及自动化部分的，我用红色框中）：
2、运维自动化的三重境界
宋代禅宗大师青原行思（六祖门下首座）提出参禅的三重境界：
参禅之初，看山是山，看水是水；
禅有悟时，看山不是山，看水不是水；
禅中彻悟，看山仍然山，看水仍然是水。
这三种境界其实和咱们眼中运维自动化的三重境界相似。
自动化第一重界：看山是山，看水是水。开始接触运维自动化的时候，咱们看到了不少工具认为就表明着自动化，好比说早期把expect+ssh封装以后，就觉得能够实现批量运维。看到有人说puppet能够作配置管理，这个时候也就认为puppet能够作配置管理，甚至是发布管理。这个时期的典型问题，就是以偏概全，对于某个开源自动化工具来讲，还无法去界定它的使用场景和范围，直接影响系统的建设效益。这个时候已经开始知道咱们看到的山不是真正的山，是迷雾环绕的深山。
自动化第二重界：看山不是山，看水不是是水。此时咱们知道expect+ssh不够，随着业务规模的变化，咱们须要一个更完整的概念来作发布系统，真正的发布系统要作版本管理、环境管理、配置管理、还要作他们的生命周期管理等等；puppet真正要作自动化，其实还依赖OS和应用层不少标准化。对于其余资源对象的管理来讲，生命周期的概念都在穿行其中，好比说DNS、LVS、接口、配置、应用包等等。为了有效标识资源的生命周期状态，须要用大量的数据来实时反馈。这是运维自动化的更具体了，把一个个的山貌看清楚了。
自动化第三重界：看山仍是山，看水仍是水。这是一种自动化本质上的追究，站在山顶之巅，俯览众山，会发出原来如此的感叹：全部自动化的本质都是为了可视化，让全部的人看到一致的服务，确保结果一致；从底层来讲，你会说全部自动化的本质都是指令+文件分发的组合；你会进一步抽象系统的能力，提供即插即用的机制；结合服务化的需求，进一步云化全部的运维系统，确保内外一致性的使用。这是化境！
3、运维自动化的多维解读
第1、基于应用变动场景的维度划分
咱们增长探讨过全部的运维价值导向最终都是面向业务、面向用户，因此天然而然就须要从业务的维度进行划分。而运维是有不少种场景的，但从业务的角度来讲，核心的几种业务场景就那么几种，如：业务上线、业务下线、业务扩容、业务缩容、应用升级等五种。我用一种场景为例带你们把整个流程穿越起来看看，让你们和我一块儿识别流程的节点到底对接了哪些系统？那么针对其余的业务场景，你也能够用同类的方法去分析。首先预设架构以下：
一、业务上线。表示一个完整的应用上线，从无到有部署整个业务上线。具体的流程以下：
仔细看其中的流程，咱们会发现涉及到多个系统，每一个系统完成职能都有不一样，这个地方只是大概的描述了一下。但这个流程一清晰的梳理出来，就知道咱们真正要实现一个应用所有上线有多么复杂了。但看完这个图又以为简单了，由于其实从业务上线的流程来看，咱们只须要一个上层的流程调度引擎调加对应的执行器，执行器经过API和底层各个系统对接。因此说以前在框架图中，为何要求各个专业系统必定要向上提供API，而且要求这个API的风格是一致的。
最复杂的业务上线已经梳理完成以后，其实业务下线就很简单，它是上线过程的逆过程，上线负责装，下线负责拆。
业务上线以后，随着用户活跃度的上升，此时业务的容量会有出现不足的状况，此时就须要进行业务扩容。扩容就很简单，当哪类节点不足的时候，对他进行扩容。至于扩容要作哪些变动，其实都是业务上线的子流程。好比说web层容量不够，那就无非申请机器，安装组件、下发应用包，自动化测试。这个时候须要注意：在业务上线的过程当中，咱们把不少的配置信息都下放到CMDB中了，但咱们选择扩容的时候，就从CMDB把信息读取出来，指导变动。
应用升级，目前持续集成讲的自动化都是在这块。简单来说，就是升级程序包、升级配置、执行额外指令等等，逃脱不了这几种模式。若是你说的这么简单，是否是我把ssh封装一个UI出来，就能够了。固然不是，这个时候须要你带着运维的理解，须要在底层作一些标准化的工做，不然你提供的是一个工具，彻底没有运维的思路，好比说程序运行属主、运行路径、监控的策略等等。另外建设应用发布平台的目的，就是要让测试、Production环境的运维变动可控。
是否是以上几个运维场景的自动化要一次所有作完呢？不是，是有前后和主次之分。对于以上的运维场景，我在当前我负责的游戏运维中下作过统计，数据以下：
A、持续部署的数量，一个月2000次左右
B、其余场景的分布状况.一个月上线一次、下线两次、扩容一次左右。
有了这个数据，咱们建设一个自动化系统的时候，就能识别先作什么后作什么。固然不一样的企业有不一样的实际，仍是要找到核心痛点。不是一上来就建设完整的业务变动系统，见效不快，且容易让项目收益不大，而遇到很大的阻力。
第2、基于系统层次的维度划分
给出这样的分层体系图，实际上是为了让你们更好的识别系统的职责和范围，下层干上层的活，上层干下层的活都是越界，越界带来的是耦合。举个例子，系统服务层puppet（或者chef）配置管理，在网上看到的不少资料都说能够来作发布，就是说能够作应用服务层的事情。后来我看过几家公司，用puppet来作应用服务层的发布，最后都走不下去，应用包的需求变化太大，靠puppet编写factor的模式来适应全部的场景，基本上是不可能，因此说它适合的是系统配置管理。以上说的就是一种越界！
第3、基于和业务程序耦合紧密程度的维度划分
这点很是重要，这个划分实际上是肯定系统建设的Owner，避免让运维团队承担过多的系统建设职能，而让运维能力提高缓慢。那怎么来判断和业务程序的耦合紧密程度？个人准则就很是简单，程序直接调用的就是紧耦合，相似api/SDK类的后端服务，好比研发建设；程序不直接使用的就是松耦合的就是运维来建设。
那有一种状况，咱们不少应用程序中,DNS和LVS服务也在程序调用链中存在，怎么办？在个人方案中，绝对不容许内部服务走DNS和LVS。咱们都知道DNS和LVS的服务对于服务异常的处理（DNS无状态、LVS是七层能力弱），远远达不到线上服务的要求，因此要坚定拒绝。若是他们真的要使用，第一告诉他们业务风险；第二，故障产生的时候，须要让研发参与处理。另外这也是系统的边界没划清楚，是让运维组件去承担业务上应该具有的容灾容错功能，会给后面的运维系统建设增长不少没必要要的功能。
我这边的分类就很简单，以下：
4、运维自动化的方法论
第1、全局驱动
不管是从所有的自动化管理平台规划，仍是某个平台的规划，都但愿你们都能找到一个全局的立足点。好比说咱们当时成立持续部署服务平台的时候，你们把全局目标一说，开发、测试、运维很快就达成共识了。目前这个平台建设完成以后，运维已经完全的退出发布变动流程之中，真正实现了让运维变成的审核者。
第2、分而治之
在上面的几个维度看到了不少系统，咱们发现每一个系统都要建设的话，其实周期和难度都很大。因此须要分而治之，特别是线上架构组件的管理系统，更须要随着组件的交付一块儿交付管理能力。以前我也表达过相似的观点，全部只交付组件，不交付管理能力的研发都是耍流氓。由于从运维的角度来讲，愈来愈多这样低价值的交付产品，会致使运维不堪重负。而让运维从头去构建这个管理，则须要花费运维不少的时间去了解，让系统建设周期拉长。举个例子，好比说某个分布式cache服务，作的很差的，经过读取日志而后对其监控，作的好的，给你开启一个管理端口，从端口中读取状态信息。这就大大下降的系统的复杂度（不用日志采集和处理组件了）。
分而治之，其实就是让不一样的团队作不一样的事情，不要所有压给运维；其次不一样的时期建设不一样的系统，不要在同一时刻作不少系统，避免战线过长。固然若是有不少运维研发人员来讲，另当别论哈。
第3、自底向上
自底向上，实际上是让你们找到一个更清晰而具体的系统建设目标来展开工做。从系统分解上，来规避你们被一个庞大而模糊的目标带入歧途。若是一上来，咱们就说要作一个全自动的运维管理系统，很容易让运维研发团队迷失方向。因此这个地方能够把全局和最终目标设定在哪儿（全自动化），而后从底下逐步构建地基，作框架，最后再盖一个完整的房子。
第4、边界清晰
边界有两个维度，一个是管理边界；一个是职能边界。第一个边界是从Owner者的角度出发的，谁产生服务，谁就是owner，管理统一都是运维。好比研发提供一个统一分布式消息队列服务，Owner是研发，他应该对可运维性负第一责任，不要让运维去承担这个服务的webAdmin管理系统建设任务。其次是职能边界，深层次的理解是组件的功能范围。有时候对运维架构师的考验就在这儿，好比说让LVS去承担业务异常的容灾和容错切换，不合适；让DNS跨过LVS层，负责对后端服务异常的自动容错处理，也不合适。没有把职能界定清楚，会致使系统作不少无用功。
第5、插件化
插件化的思惟无处不在，但咱们面对纷繁复杂的管理对象时，咱们进行抽象，提供管理模式，具体的实现交给用户，这个咱们平常所见的运维系统中常常能够简单。好比说nagios就是一种插件化的采集思路。对于配置管理来讲，puppet也是采用这个思路。到咱们最上层的调度管理系统来讲，可让运维本身去编写本身的执行器，特别是和业务紧密相关的，但最终运维整形控制权仍是交给平台。而个人经验是，在【应用服务层】和【架构服务层】，不要引入插件化的管理方案，过多的插件化部署，会让咱们生产环境的管理最终混乱不堪，最终失控。因此提供类SSH界面的运维发布和部署平台，是没有任何运维价值的。
5、运维自动化系统的实现
挑战一个自动化的极致场景（可视化），是运维人对极致的追求。接下来，我会拿几个典型的运维自动化系统供你们参考。
第1、DNS管理系统
简介：DNS系统传统web形态下的一个重要入口，用户服务的访问严格依赖这个服务入口。如今外面通常都叫GSLB（全局服务负载均衡调度），目前是CDN服务里面的重要服务节点。实现的目标都是要解决运维从哪里来，到那里去最快，当目标机房故障的时候，如何把服务调度走。概念图以下：
在移动app的今天，DNS协议的缺点已经逐渐暴露出来了，DNS解析时间长，另外还常常被劫持的。由于有端的控制，如今逐渐开始走httpDNS的服务，经过http服务的方式获取域名对应的IP地址，此时由DNS平台直接提供http服务对外。在有端APP的状况下，还能够识别非本身权威DNS域名是否存在被劫持的状况下，这个能够借助端的数据挖掘技术。此时系统须要保持和业务的与时俱进。
这个地方还有一个问题要注意的，内部DNS是否是能够统一管理？理论是能够的，把一个一个机房当成一个个的view，不过我不建议两个场景耦合在一块儿，虽然可以实现。
系统Demo：
第2、CMDB管理系统
简介：在以前的【运维平台之CMDB系统建设】，我有全面的体系化介绍，再也不细述。
系统Demo：
第3、名字服务中心系统
简介：概念最初来自于zookeeper，咱们结合咱们的实际，实现了名字服务中心。把程序接口之间的调用抽象一个一个的服务之间的调用，在服务中心来实现调度的统一注册、鉴权、acl、容灾容错控制。说这是线上服务最核心的系统，一点不为过，而且是收益最大的系统，直接替换掉DNS、LVS。我后面挑一个专门的章节来介绍这个系统，以便给大家的线上服务架构提供参考。
系统Demo：
第4、持续部署管理系统
简介：持续部署，是咱们应用升级的核心系统，每月承担着大量的变动。在系统规划之初，咱们就给他设定了清晰的业务管理目标：作持续集成的一部分，实现四个下图的四个维度管理目标；也设定了具体业务运维目标：结果全部的包、配置升级，且让业务运维完全的退出业务变动流程。以下：
系统Demo：
这个界面实现了最复杂的配置管理职能。
第5、业务调度管理系统
简介：面向业务的调度管理系统，是一个流程调度引擎+执行器来完成的，目前咱们当前正在实现中。其实你们能够看看云编排服务，基本原理相似。
Demo（09年左右实现的一键化变动系统），以下：
还有数据库运维管理平台和分布式cache管理系统......都有相应的实现，这个地方不贴图介绍了。
6、运维自动系统的API参考实现
全部底层的系统对外提供服务都是经过API暴漏的，供各个系统使用。接口的使用须要经过受权得到，建议这个受权能够基于系统级别，也能够到接口级别，而不是统一开放的模式。另外接口内须要有相应的一些权限控制，避免底层服务被任意操做。
能够仿照AWS的接口实现方式，统一实现API的接口开放访问地址，同时协议统一（http、https），协议可使用Get的方式进行访问。
7、运维自动化依赖的团队模型
我从能力模型、驱动模型和技能模型三个角度来阐述运维团队和我的的能力要求，最后给出一个参考的组织结构。
第1、团队的能力模型
在我带过的应用运维团队中，我都会从如上三个方面的能力对组员提出要求。
业务运维。在咱们的考核体系中放的比重愈来愈低，由于这块能力要求愈来愈低。平常的变动、扩容、故障定位、运维规划对人的能力要求都很是的低，这些工做都能模式化且平台化，能够减小对人的倚重，
运维研发。我但愿每一个应用运维人都有运维研发的能力，但现实是不可能的。但对于一个应用运维团队和一个运维部门来讲，运维研发的配备必不可少。在应用运维团队内部，可让有研发能力的人迅速承担面向业务运维平台的建设或者参与到部门的运维系统建设中，能够50%时间参与研发。运维研发能力是让团队价值迅速达成的保证，没有研发能力的运维不是一个好运维（包括我本身）。
技术研究。运维是个技术团队，须要经过技术体现价值，当找到好的技术就想着如何应用到业务上，给用户带来价值，好比说用户体验提高，成本减小等等。
这个时候有个问题，应用运维团队里面的人也会运维研发，而后又有专职的运维研发团队？那他们的职责分工如何解决，在工做上是否会存在重复建设？个人回答是这样的：
首先，能够把运维研发初期定位在公共服务平台研发上，好比说DNS、LVS、配置管理、监控系统、CMDB、数据分析平台等等。
其次，运维研发还须要制定相应的运维研发规范，代码规范、UI规范、测试规范等等，让全部参与运维研发的人统一遵照，包括应用运维研发的组员。
最后，说一下应用运维小组内的研发能力该如何发挥的问题。其实在不少运维团队中，运维都是跟随业务，一则可让应用运维研发人员开发面向业务的运维系统，他们最懂该业务的需求，实现本身想要的；另一种更好的操做方式，让应用运维小组内的研发人员50%时间参与到以运维研发牵头成立的虚拟研发小组中。一则能够进一步提升应用运维的研发水平；另能够提升运维研发对业务运维的理解，同时提升带队做战的能力。
关于运维研发和应用运维的比例该设置成多少？2:1吧，这也是初步拍的。你们也能够自检一下，本身的运维团队到底设置了多少运维研发人员？另外运维研发配备是否足够，能够周期性看看运维团队取得的进步，特别是效率、质量维度。
第2、团队的驱动模型
团队的驱动力不一样，带来结果的就彻底不一样。为何不少运维人员都说本身很苦逼，这个地方能够看看究竟是什么在引导着你在作运维工做？传统的维护，都是集中在第一和第二阶段，而进入到高阶运维体系以后，咱们须要迅速切换到价值驱动、用户驱动的维度上来。有了用户驱动和价值驱动，对运维的效率、质量都有了更高的要求，反向驱动咱们必须走自动化和平台这条道路。
第3、团队的技能模型
在BAT很早就实施了职业通道体系，对于运维人员的成长有明确的要求和衡量体系，在此我就不详细介绍了。下图是腾讯的高级应用运维工程师的技能要求雷达图，供你们参考：
第4、参考的运维团队组织结构
不必定要按照这个结构明确设置运维小组，可是运维的职能差很少是这样。我还有另一个建议，最好公共服务研发团队最好和运维团队放在一个组织结构下，会有利于公共化服务的推广，而公共服务化对运维的效率影响是最大的。
至此，自动化平台的深度解码已经完成。从多个层面带你们了解运维自动化，其实仍是但愿给你们带去一点借鉴意义。大胆的往前走吧，一切都有可能，惟独那些实现不了，都是咱们人的问题，别无其余。