前记：所谓干一行爱一行，人生处处是《围城》这是人性，但在改变那一刻之前，自应全心全意研究本行，全心投入，不计回报，用心在当下，写到体系就像是前面所有博客的一个帽子，现在把他总结整理出来，希望对你有所启迪。

自动化运维体系是一步步发展过来的，构造自动化运维体系的前提得先了解原始运维体系，原始运维体系好比是本，有了本才知道怎么实现自动化、实现Aiops.......

首先，运维有其业务职能，全部职能梳理规范后形成章程、纲领和体系，互联网最大的特点是“快”和“变”，但不代表没有固定的体系，恰巧有的是应对"快"和"变"的体系，从事一线运维这些年，体会到千象背后是有恒道的，所谓万变不离其宗，运维工作一切围绕高SLA和低成本为目标运转，只是工具在围绕运维体系变来变去而已，从开发的角度理解运维体系就像是算法，实现算法的语言和方式就像是工具，自动化就是工具的升级。

在前期，运维人员在和各部门无数的磨合、探索中慢慢形成了工作体系，也就是运维体系，此体系无形的规范了运维的工作，以及工作该怎么干，运维人员通过这个无形的纲领开展日常工作并保障业务的健康发展，这个阶段可以说是制度为王、制度规范，没有系统的自动化运维平台，有的只是零散的一些大小工具，各种事物基本靠人工、靠制度、靠约束，虽是原始阶段，但也是运维最真实的样子，忙碌而又忙碌，效率总跟不上需求，制度总跟不上执行，与开发的协作总难同一频道，需要大量的运维人力。

再向后发展，为了提高效率的同时解决与开发间的沟通协作问题，提出了DevOps，大家开始做自动化，这个自动化其本质是把运维体系落在一个到多个系统上，通过自动化系统来提高工作效率，同时用系统来实现制度，开发和运维都在一个系统上协作，遵守同样的规则，协作上也高效多了，这个阶段到了技术为王、平台规范，市场上出现了运维开发，出现了SRE，各种问题得到了有效的解决，当然解决的程度取决自动化系统做的优劣，这个就参差不齐了，但出现了这个发展方向。

再向后发展，出现了AiOps......

个人感觉，有两个维度变化很明显，越来越注重技术解决问题，人员需要越来越少，能用技术工具替代的岗位在慢慢被替代，随着自动化平台的成熟稳定，理论上理想的终极状态可能只留"运维平台+应用运维"，其他运维转岗应用运维，应用运维转岗技术运营。

那么如果你恰好接到一个从零开始建设的运维工作，怎么有序规划、快速迭代到自动化运维体系呢？下面我们分两步把他拆开看一看。

一、 规范工作，形成运维服务体系（制度为王）

1、变更规范

     - 上线变更：代码上线、扩容；

     - 配置变更：系统配置、应用配置；

     - 网络变更：网络割接、设备更换；

     - 其它变更：流量调度、服务切换、服务下线...

- 原则：a、制定变更审核流程；

b、制定变更相关方通知（群、邮件）；

c、制定变更回滚策略；

d、遵循测试、单机灰度、机房灰度、全量上线的规则；

e、下线变更要将服务器依赖处理干净，比如说挂着vip、有域名解析。

2、灾备规范

     - 服务灾备：多机器、多机房；

     - 数据灾备：多备份、异地备份；

     - 网络灾备：多线路、多设备；

 - 原则：a、自动切换 > 手动切换；

b、无状态 > 有状态；

c、热备 > 冷备；

d、多机房 > 单机房。

3、预案规范

     - 线路切换：移动、电信、联通、BGP等多线路切换；

     - 机房切换：不同机房切换；

     - 机器切换：不同机器切换、故障机器自动摘掉；

     - 服务降级：无法切换时，如何降低标准继续服务；

     - 数据库切换：主从切换、读写切换；

     - 网络切换：主备线路切换、链路切换；

- 原则：a、域名切换 > 更换IP；

b、自动摘掉 > 手动操作；

c、自动切换 > 手动切换；

d、考虑好雪崩事宜。

4、容量规范

- 系统容量：木桶原理计算系统的上、下行容量、用量、余量；

     - 模块容量：模块的上、下行容量、用量、余量；

- 机房容量：分机房的容量、用量、余量；

- 单机容量：压测单机的容量，一般用于反向计算机房、模块容量；

- 原则：a、制定模块单机容量指标，并记录文档（比如QPS、连接数、在线用户数等），

b、容量要考虑下行（读）、上行（写），考虑存储增量；

c、计算当前模块总容量，收集当前的用量，并对比容量计算余量；

d、系统总容量可以根据木桶原理，找到短板模块后，反向计算出来。

5、告警规范

- 基础监控：CPU、内存、网络、IO；

- 应用监控：进程、端口；

- 业务监控：日志、业务埋点；

- 依赖监控：数据库、依赖接口...

- 原则：a、核心监控收敛成告警，并对告警进行分级，备注告警影响；

b、核心监控形成可排查问题的DashBoard；

c、告警的价值在于实时发现故障，是事中和事后的。

6、巡检规范

       - 系统核心指标DashBoard；

       - 分模块核心指标DashBoard；

       - 基础资源核心指标DashBoard：服务器；

       - 依赖资源核心指标DashBorad：依赖db、依赖接口；

       - 自动化巡检报告；

       - 值班oncall安排；

- 原则：a、DashBoard核心在于收敛、舍得；

b、自动化巡检的必要性在于异常侦测，预防故障，是事前的。

7、权限安全规范

       - 开发、运维、临时权限；

       - 安全上符合安全审计标准。

8、故障管理规范

       - 服务分级，确定各服务用户角度的影响；

       - 制定分级后各服务SLA，制定问题、故障分级标准；

       - 制定故障通知、处理规范；

       - 制定故障复盘，改进措施按时保量完成的规范；

- 原则：a、拥抱故障，但同一故障解决后，不应重复出现。

9、文档、工具规范

       - 统一共享知识文档；

       - 统一共享各种脚本工具；

- 原则：a、理想的情况是“一站式运维平台”，一个平台涵盖所有工具操作。

10、标准化规范：

      - 主机名标准化；

      - 应用软件安装结构标准化；

      - 日志存储标准化；

      - 日志格式标准化；

      - 域名使用标准化；

- 原则：a、主机名尽量能看出更多信息，比如服务、模块、机房等；

b、日志是排查问题的重要信息，一定要标准化，方便手工排查，更是为了以后用工具处理打下基础。

二、 技术实现制度，搭平台，建设自动化运维体系（技术为王）

有了第一阶段的运维体系为基础，就可以考虑用平台工具来实现零散的手工操作、制度规范，理想的情况是“一站式运维平台”解决所有事情，平台后端集成使用开源技术方案作为支撑，对于用户优雅而统一，目前开源项目中尚未找到很好的“一站式运维”产品，下面罗列一下常用的解决某类问题的技术方案。

1、监控告警方案

- Zabbix：https://www.zabbix.com

- OpenFlcon：https://github.com/open-falcon/falcon-plus

- Prometheus：https://prometheus.io

- Grafana：https://grafana.com

2、日志分析方案

- ELKB：https://www.elastic.co

3、安全堡垒机方案

- JumpServer：http://www.jumpserver.org

4、持续集成部署CI/CD方案

- jenkins：https://jenkins.io

- GitLab：https://about.gitlab.com

5、容器技术方案 

- Kubernetes：https://kubernetes.io

6、配管自动化方案

- Puppet：https://puppet.com

- Saltstack：https://www.saltstack.com

- Ansible：https://www.ansible.com

8、一些运管集成方案

- SaltShaker：https://github.com/yueyongyue/saltshaker_api

- 腾讯蓝鲸：https://github.com/Tencent/bk-cmdb

- OpsManage：https://github.com/welliamcao/OpsManage

 ......

查看更多请到博主原创站：运维网咖社（www.net-add.com）