在作为运维开发的这段时间，我们主要围绕运维的工作做了些自动化系统，这边就简单分享下我当初大约经历8个月左右的时间，基于运维自动化搭建一些列自动化运维平台。
概述
关于运维发展，可以参考大厂-阿里的发展历程，可以分为五个阶段，分别为L1-脚本运维、L2-工具化运维、L3-平台化运维、L4-数据化运维、L5-智能运维。我们当初运维的整理状态应该在0.5*L2（即半工具化运维😂），可想而知其过程的艰辛。
运维在系统层面的建设，如：Zabbix监控、ZStack虚拟化、Granfana监控、LVS、IDC重建等，这部分工作主要由运维同学在逐步推进。
自动化平台部分建设，主要有：CMDB、持续交付系统、DB平台、DNS系统、配置中心、任务调度、自动化平台、事件平台等，接下来我会针对这个自动化平台部门做一个简单的介绍吧。
CMDB
这个很值得和大家聊一聊的，刚开始时，我们定位是做一个运维 资产平台，只需要做好资产申请管理即可。经过一番前期调研，发现我们原有理解实在是太狭隘了，感兴趣的同学可以去了解下运维现代CMDB建设
以下是引用的话（出处：智能化运维平台的基石），说明CMDB平台如何建设：
1、应用CMDB必须提供统一的应用元数据管理能力。
2、应用CMDB建设的核心诉求是应用生命周期的管理，带来了整个管理的驱动力是最强的，这时候无论变更的频率还有以及对于一致性的要求都是最高的。
3、必须以应用为中心，不是基础资源为中心，这个视角大家要记住。
4、必须要从应用的角度构建IT资源的弹性关系，有两个层次，一个层次是我应用的模型和后端模型表达关系，我可以依赖DB，我可以依赖DNS，我A可能用了DB，我B没有用DB，这是弹性关系。
最后就是系统的选型啦，我们选择的是腾讯开源的蓝鲸CMDB（Tencent/bk-cmdb）
持续交付系统
这个是我们重点建设的系统，这个没有选择开源系统而是自建的（其实是运维老大带过来的😄😄😄），当然这个是DevOps的一个核心环节，后续还会有专篇进行解密的，这边主要介绍几个核心模块吧
- 应用管理：应用申请、配置、查看、权限人员配置
- 容器部署：支持K8s容器部署
- 传统部署：支持物理机，虚机部署
DB平台
两个开源系统纠结吧。
- Yearning
- Archery（最终选择了这个，主要是DBA伙伴决定的）
DNS平台
这个是自建的平台（其实是运维老大带过来的😄😄😄）。
使用 BIND 作为 DNS 服务器，使用 ETCD 来管理 DNS 服务器的 BIND 配置文件，包括 VIEW，ZONE，RECORD 的各个配置文件。
所有的 DNS 服务器的配置文件和数据都是统一从 ETCD 上获取，因此所有 DNS 服务器的配置文件及数据都是相同的，且所有 DNS 服务器角色均为 Master，不存在 Slave。
所有 DNS 服务器会实时监测 ETCD 上的数据，当在平台上对 DNS 进行操作时，只要配置文件发生变化，所有 DNS 服务器都会实时获取到最新的配置文件信息。
配置中心
这个选择了携程开源的 Apollo了，因为公司有相当部分业务使用时PHP，对于Apollo的支持不是那么友好，所以基于这个，还开发了一个Apollo-Agent。
任务调度
这个选新做了三个开源系统的对比：Xxl-job、ElasticJob和Gocron
| Gocron | Xxl-Job | Elasticjob | |
|---|---|---|---|
| Golang | 支持golang job运行可以集成至gin框架原生语言使用较为方便 | 可以支持glue及bean模式有golang客户端也可集成至gin框架原生语言使用较为方便 | 不支持golang job |
| Lumen | 支持php job只限于命令行可以使用php artisan一键启动 | 可以支持glue及bean模式，包括命令行及fastcgi方式支持php artisan一键启动 | 不支持php job |
| Spring | 不支持java任务，只能通过shell调用不能和spring框架集成 | 有spring原生库支持，方便接入 | 有spring原生库支持，方便接入 |
最终选型确定为：Xxl-job，Xxl-job相比ElasticJob和Gocron功能比较健全，没有明显的缺陷，而且Xxl-job相比Elasticjob对golang和php的原生job支持更友好，相比Gocron对于java的job又更友好，比较适合我们这种java和php业务并存的公司技术形态。
另外，在其他一些功能特性上Xxl-job相比Gocron有明显优势：
1、支持任务节点弹性扩容/缩容、故障转移，Xxl-job支持高可用的job调度执行，在业务上云后能发挥更大优势
2、支持任务分片执行以及其他更多高级调度策略，Xxl-job可以将一个任务按照特定路由规则打散在不同任务服务器机器上
3、业务拓扑管理、任务执行报告、任务参数传递，能提供应用维度的任务管理、单个任务的执行周期报告数据，可为后期任务脚本逻辑优化提供建议
与此同时，Xxl-job和Gocron均存在不支持常驻任务，但目前优化后的Xxl-job可以通过集成Goagent支持常驻和命令行模式。
自动化平台
我们选型的自动化工具是：Ansible，这个平台主要是对Ansible的playbook的管理吧，貌似后续使用程度不高。
事件平台
业务故障收集平台
基础依赖-用户中心和消息通知平台
用户中心
运维平台的统一用户中心，对接OA LDAP，同时支持各系统的权限管理配置
消息通知平台
各系统的统一的消息通知平台，支持邮件、企微等通知方式
总结
建设思路
主要是以平台化的思路在进行建设的（即将缺什么就去做什么，或者以经验为主导进行建设），选型基本以业界标准且开源为主，避免重复造轮子。
反思
平台分散，无法做到DevOps所期望的**一站式研发协同平台**，属于DevOps建设过程的一个中间阶段。
总结
后续建设，做好整体的DevOps的整体全景规划，有一个整体的目标和方向，建设过程中可以逐步完善，但是逐步向同一个目标推进，避免系统的分散割裂。