如何从零构建你的自动化运维体系？——从制度到技术

素颜马尾好姑娘i 2022-01-13 20:09 286阅读 0赞

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

自动化运维体系是一步步发展过来的，构造自动化运维体系的前提得先了解原始运维体系，原始运维体系好比是本，有了本才知道怎么实现自动化、实现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][https_www.zabbix.com]

**- OpenFlcon：**[https://github.com/open-falcon/falcon-plus][https_github.com_open-falcon_falcon-plus]

**- Prometheus：**[https://prometheus.io][https_prometheus.io]

**- Grafana：**[https://grafana.com][https_grafana.com]

**2、日志分析方案**

**- ELKB：**[https://www.elastic.co][https_www.elastic.co]

**3、安全堡垒机方案**

**- JumpServer：**[http://www.jumpserver.org][http_www.jumpserver.org]

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

**- jenkins：**[https://jenkins.io][https_jenkins.io]

**- GitLab：**[https://about.gitlab.com][https_about.gitlab.com]

**5、容器技术方案 **

**- Kubernetes：**[https://kubernetes.io][https_kubernetes.io]

**6、配管自动化方案**

**- Puppet：**[https://puppet.com][https_puppet.com]

**- Saltstack：**[https://www.saltstack.com][https_www.saltstack.com]

**- Ansible：**[https://www.ansible.com][https_www.ansible.com]

**8、一些运管集成方案**

**- SaltShaker：**[https://github.com/yueyongyue/saltshaker\_api][https_github.com_yueyongyue_saltshaker_api]

**- 腾讯蓝鲸：**[https://github.com/Tencent/bk-cmdb][https_github.com_Tencent_bk-cmdb]

**- OpsManage：**[https://github.com/welliamcao/OpsManage][https_github.com_welliamcao_OpsManage]

** ......**

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

转载于:https://blog.51cto.com/benpaozhe/2391372

[https_www.zabbix.com]: https://www.zabbix.com/
[https_github.com_open-falcon_falcon-plus]: https://github.com/open-falcon/falcon-plus
[https_prometheus.io]: https://prometheus.io/
[https_grafana.com]: https://grafana.com/
[https_www.elastic.co]: https://www.elastic.co/
[http_www.jumpserver.org]: http://www.jumpserver.org/
[https_jenkins.io]: https://jenkins.io/
[https_about.gitlab.com]: https://about.gitlab.com/
[https_kubernetes.io]: https://kubernetes.io/
[https_puppet.com]: https://puppet.com/
[https_www.saltstack.com]: https://www.saltstack.com/
[https_www.ansible.com]: https://www.ansible.com/
[https_github.com_yueyongyue_saltshaker_api]: https://github.com/yueyongyue/saltshaker_api
[https_github.com_Tencent_bk-cmdb]: https://github.com/Tencent/bk-cmdb
[https_github.com_welliamcao_OpsManage]: https://github.com/welliamcao/OpsManage
[www.net-add.com]: http://www.net-add.com/