需求
运维是事件驱动，还是自驱动可能是我们在运维工作中不太关注的问题。事件驱动让运维止步于故障，而自驱动让运维不止于建设。持续性的运维建设就需要一套自动化的运维体系，那么我们应该从何入手？
其实前期《运维思考》一系列文章已经给我们答案了，就是从运维框架入手分层建设、打好基础，记住“万丈高楼平地起，勿在浮沙筑高台”。
运维框架
通常讲到运维建设，我们脑海中首先浮现的是“一团麻”，因为这不是一个人、一个岗位的工作，而是一整个团队的工作；所以我们将“这团麻”进行由底层向上可划分为：
IT基础设施层
IT基础设施层，主要由基础运维团队负责，主要包括存储、网络、服务器、安全设备等硬件设施；
数据层
数据层，主要由DBA团队、大数据团队负责，主要包括数据库、缓存、数仓等；
应用层
应用层，主要由应用运维团队负责，主要包括基础服务、业务应用、中间件等；
管理层
管理层，主要由配置管理团队、安全团队、应用运维团队负责，主要包括各种自动化操作、安全管理、监控管理等；
展示层
展示层，主要由各团队综合管理，主要包括各种管理工具、监控工具等；
通过对运维框架的分解，对各种资源的逻辑隔离，让各个团队明确当前运维建设中的现状与不足。 如果我们能做到对运维框架的持续性关注，通过图片就可以明晰的知道哪个团队的不足，以及日后各团队的重点发力方向。
运维依据
如果你觉得运维框架还不够细致，那么针对框架中各个层次的工作拆解就来了，我们在此将其称之为运维依据。
针对这些个运维依据，我们可以展开一些列的针对性措施，如制定规范、自动化流程，如此就能够不断丰富各个团队的制度、规范、流程，何乐而不为？
1.基础设施层
在基础的硬件设施管理之上，比较重点的工作是
网络分区与隔离
网络分区应考虑互联网接入区、普通生产区、数据区、外联区等各个区域，保证各区域的合理接入。
网络隔离对测试、准生产、生产环境各环境进行隔离，避免访问权限混乱。
CMDB资产纳管
CMDB用于管理基础设施层的各项资产，为上层应用提供数据支撑。使用CMDB一定要和业务应用紧密结合，一旦脱离于业务使用，那么CMDB将成为花瓶。
相关场景可参考《运维思索：接地气的运维自动化建设》。
内部dns
通过内部dns可以将应用与IP解耦，一旦ip变更则不需要变更代码，生产环境应该尽量少做此种类型变更操作。
服务器快速上架
为满足业务日益增长的需求，应该具备服务器快速上架、资产实时记录至CMDB等一系列自动化流程。
网络权限变更
根据应用需求，快速登记并开通网络权限。
等等。
2.数据库
数据库除了特有的集群外，可以考虑数据库工单、sql审核优化等流程。
3.系统应用
容量规划
容量规划是指根据业务用户流量增长、现有容量等一定的基础数据之上进行周期性的评估，如果有条件的话可结合压测实际情况，这样数据会更准确。通过容量规划可有效控制服务器规范，避免资源溢出。
环境维护与部署
为避免因环境差异导致的问题，各环境应用部署需要遵循统一的目录规范，统一的自动化部署方式，分离的应用配置文件。
等等
4.配置管理
统一账号管理
所有和用户登录相关的平台、管理工具，尽量接入ldap统一账号管理，这样一个账号可以实现所有系统的统一登录。
自动化配置中心
在此秉承基础设施即代码的思想，通过ansible作为配置中心，在操作系统层面实现系统初始化、环境初始化、组件初始化、自动化备份等中心化管理，各环境交付统一规格的服务器。
流程管理
结合jira等工作流工具实现操作的流程化管理。
等等
5.CI/CD
基于统一的运维规范前提下，CI/CD可以真正的做到将以上各个层面的想法、解决方案进行落地。因此CI/CD能力很大程度上决定了我们自动化运维的高度。
持续集成
代码质量测试、单元测试、打包测试、自动化测试等。
操作系统交付
遵循统一的运维规范，交付统一规格的操作系统，完成对运维平台各个管理节点的资源注册。
版本发布
支持版本平滑发布、回滚、重启等。
自动打包
Android/IOS 自动打包并上传至应用商店。
6.监控系统
系统建设
多维度收集、分析监控数据，实现不同层面的告警；
对于多维度的数据能够进行分析，实现故障自愈；
监控管理
监控并不是只要做到告警进行了，而是要做到告警的准确性，因此对告警级别、告警收敛、故障自愈策略等的管理需要我们进行重点关注。
7.安全防护
通过必要的WAF、IDS、防火墙等安全设备进行安全防护、流量分析外，还要结合安全渗透去主动发现问题。
8.数据分析
通过对应用数据、业务数据、运营数据进行集中分析、展示，帮助我们更好的了解系统运行状况。
总结
通过以上各个层面的运维框架和运维依据，希望大家能够结合实际情况进行头脑风暴，做到不止于此。
当然自动化运维建设不是一蹴而就的，需要结合规范、制度、流程去逐步实现。
记住运维建设是过程，不仅仅是目标，我们需要跟随技术潮流趋势，持续的优化与丰富这个过程。