1.6 运维自动化系统的实现
挑战自动化的极致场景（可视化），是运维人员对极致的追求。极致的自动化是运维事务全流程的自动化，运维事务全流程自动化是包含了一次应用完整交付所涉及的所有资源的自动化能力，比如说DNS资源、负载均衡资源、数据库资源、服务器资源、配置资源等。下面将列举几个典型的运维自动化系统以供大家参考。
1.6.1 DNS管理系统
DNS是Web形态下的一个重要入口，用户服务的访问严格依赖于这个服务入口。现在一般被称为GSLB（全局服务负载均衡调度），目前是CDN服务中的重要服务节点。实现的目标都是要解决运维从哪里来，到哪里去最快，当目标机房发生故障的时候，如何把服务调度走。
在移动APP大量应用的今天，DNS协议的缺点已经逐渐暴露出来了，DNS解析时间长，另外还经常会被劫持。因为有端的控制，现在逐渐开始走HTTPDNS的服务，通过HTTP服务的方式获取域名对应的IP地址，此时由DNS平台直接对外提供HTTP服务。在有端App的情况下，还可以借助端的数据挖掘技术，识别非权威DNS域名是否存在被劫持的情况。系统需要保持和业务的与时俱进。
这里还需要注意一个问题，内部DNS能否统一管理？理论上是可以的，把单个机房当作单个的view，不过我不建议将两个场景耦合在一起，尽管这样能够实现统一管理。
系统Demo如图1-7所示。
图1-7 DNS管理系统
1.6.2 CMDB管理系统
CMDB管理系统的建设这里就不展开介绍了，感兴趣的读者可以关注微信公众号“互联网运维杂谈”，并参阅《运维平台之CMDB系统建设》一文。
系统Demo如图1-8所示。
1.6.3 名字服务中心系统
“名字服务中心系统”的概念最初来自于Zookeeper，该系统结合实际情况，实现了名字服务中心。把程序接口之间的调用抽象成单个服务之间的调用，在服务中心实现调度的统一注册、鉴权、ACL、容灾容错控制。将其看作线上服务最核心的系统，一点也不为过，并且它还是收益最大的系统，可直接替换掉DNS、LVS，降低线上系统对运维系统的依赖性。
系统Demo如图1-9所示。
图1-8 CMDB管理系统
图1-9 名字服务中心系统
1.6.4 持续部署管理系统
持续部署是应用升级的核心系统，该系统每个月都承担着大量的变更。在系统规划之初，我们就给它设定了清晰的业务管理目标：持续交付的一部分，实现图1-10中的4个维度管理目标；也设定了具体业务的运维目标：升级所有的包和配置，且让业务运维彻底退出业务的变更流程。具体如图1-10所示。
系统Demo如图1-11所示。
持续部署系统是持续交付系统的核心（持续集成、持续测试、持续部署、持续反馈），它是产品发布到达生产环境的关键步骤。在这个平台的建设上，运维人员应该将它作为突破的第一个点。在该平台搭建完成之后，运维就可以从日常的部署事务中解放出来了。
图1-10 持续部署管理系统示意图
图1-11 发布系统
1.6.5 运维调度管理系统
运维调度平台又称为调度编排系统，编排是一种场景化的运维能力封装，是对复杂运维事务的封装。我们在平时的运维过程中能够看到很多复杂的运维场景，比如说容灾切换、故障处理、服务迁移等。这些场景，很多时候都不是单一的动作就能够完成的，往往需要借助多种运维能力组合，如图1-12所示。
在图1-12中，我们把Ops自动化调度下面的服务支撑层分解为三部分：工具平台OpsStore，用来编写日常的运维工具；外部服务，用于公共API对外提供封装；Ops发布，用于提供代码持续部署服务。
一个完整的自动化调度平台应具备能够对接一切服务的能力，例如通过配置管理来初始化内核、通过OpenStack来初始化资源、通过DNS来获取全局调度服务、通过存储来获取存储的服务，甚至还可以通过公有云API来获取外部公有云的资源服务能力，如图1-13所示。
图1-13 自动化调度平台示意图
还有数据库运维管理平台、分布式Cache管理系统等也都有相应的实现，由于篇幅所限，这里就不贴图介绍了。
