前言

运维管理兜兜转转十几余载，大家的运维管理再也不是小米加×××、人工费力拉线扛服务器的传统时代，如你所知，这些年大家张口闭口谈的都是运维自动化如何如何。一千个读者就有一千个哈姆雷特，一千个运维就有一千种运维自动化想法或构建思路，小生不才，今日斗胆来聊聊我眼中“运维自动化”的那些事儿！如有不妥，还请大家给出相应的意见......

 

运维自动化到底干个啥？

据度娘之意，IT运维自动化是将日常IT运维中大量的重复性工作，小到简单的日常检查、配置变更和软件安装，大到整个变更流程的组织调度等，由过去的手工执行转为自动化操作，从而减少乃至消除运维中的延迟，实现"零延时"的IT运维。其本质是运维方式的转变，由手动逐渐演变为自动化操作！那运维自动化应该包含哪几个层面？鉴于IT运维五个维度”效率、稳定、安全、体验、成本”范畴，运维自动化统筹起来就有监控自动化、服务流程自动化、运维操作自动化......

IT监控自动化

监控自动化是运维自动化的起点之一，利用监控自动化平台对各类IT资源（包括服务器、数据库、中间件、存储备份、网络、安全、机房、业务应用、操作系统、虚拟化等）进行实时监控，再做故障根源告警归并处理，以解决特殊情况下告警泛滥的问题，例如机房断网造成的批量服务器报警。当然，监控自动化的范畴很广，除了监控告警响应，系统各个服务如Nginx、Java、PHP、DB或网络等的性能优化、资产关系的梳理以及业务系统的实时健康评估监测也是应该包含在里面。

 

 

服务流程自动化

监控自动化发现了问题就应该接入相应的流程进行处理，这时候故障事件自动触发问题处理跟踪流程，并在自动化工单式流程的指引下通知到相关责任人，并利用知识库自动化完成整个故障处理协调过程。

 

 

运维操作自动化

这个层面的自动化运维工具，主要是把运维一系列的手工执行繁琐的工作，按照日常正确的维护流程分步编写成脚本，然后由自动化运维工具按流程编排成作业自动化执行。简单来说，就是把多个Shell、python、PowerShell、Bat等脚本串在一起执行实现某个特定的操作目的，以此来替代一些日常需要批量或者大量重复性的操作，比如变更、部署、配置下发等操作！


以前，传统的运维方式是由监控系统监控，根据阈值设置产生告警，走工单方式人工处理。现在，使用自动化运维平台，可以让产生的告警和知识关联，自动化处理故障。也就是说，IT运维自动化工具是监控自动化和流程自动化工具的完善和补充，三者结合相得益彰！

 

总体来说，运维自动化不是写写脚本，再用开源软件东拼西凑就完了，这只能叫辅助运维，不叫自动化。据我所知，真正的自动化应该是让运维平台工具帮你’监测——发现——处理——解决问题”，集”自我修复、自我维护”为一体，各模块之间尽量低耦合、可扩展、可插拔，最终实现运维智能化；也应该是真正能帮企业降低IT运成本，使运维管理可视化、可测量、可对比，进而真正将运维人员从繁琐的、例行、容易发生人为事故的工作中脱离出来，做更有价值的运维工作。

 

运维自动化怎么做？

很多运维人员在筹建IT运维自动化架构体系时，妄图一口吃个大胖子，谋求一个完整的系统来自动化完成所有的运维工作，殊不知自动化是一个循序渐进持续发展的过程。我觉得在思考如何做运维自动化之前应该认识到几个根本的原则问题：


标准必备

正所谓无规矩不成方圆，实施自动化前提需要标准规范与流程化。这包括资源标准化、OS的基础配置标准化、基础软件（如Tomcat、JVM）配置标准化、应用配置标准化、流程规范标准化......比如，如Ngnix/JAVA/PHP/MySQL这些常见服务的应用初始化流程、部署更新流程等，可以提前固化下来，做到了标准化，消除了各种差异，才能为后续的自动化开发铺平前进的道路。

与此同时，随着ISO20000、ITIL v3.0的持续推广，它们已成为实际的某种标准，尤其是ISO20000的认证要求，也是企业的普遍需求，而ITIL v3.0包含了对IT运维从战略、设计到转换、运营、改进的服务全生命周期的管理，也为企业的服务流程管理自动化提供了更多思路！

实用为先

大家常说，“公司的系统架构不是设计，而是演变而来的。”一般而言，企业要做运维自动化都不是一蹴而就，也不太可能一次性建好，都是分阶段来做以解决自身实际问题：首先应该明确自身处于“手动支撑 —— 线上标准规范化——运维工具化——平台自动化”的哪个阶段，然后先找准现阶段的痛点，对症下药。

说到实用，不得不提到——CMDB。关于“CMDB是不是运维自动化的基石“，不少运维还在疑惑，到底要不要建立CMDB呢? CMDB即配置管理数据库，一般用于统一管理IT数据、服务器数据资产等。它不仅是硬件和资源的信息记录，更重要是要建立起应用与资源之间的对应关系，并以此为基础，配套着应用配置管理、监控、发布、稳定性等系统的建设，才能最终形成体系化的运维平台，否则只是碎片化的运维模式。当然，这里只是让CMDB只提供最基础的资源信息和应用资源的关联关系，不期望把基础的CMDB做得过重，不然后期会不堪重负！

安全为重

运维安全是企业安全保障的基石，不同于Web安全、移动安全、业务安全，随着自动化运维管理体系的不断融合与统一，运维安全环节任何一个代码、一次部署出现问题往往会比较严重，很多时候说”牵一发而动全身“都不为过。此外，运维自动化平台关联的资源越来越多且复杂，甚至都涉及到了root权限，为广大***朋友创造更多空间，所以加强自身安全防御势在必行。最基本的是加强权限和基线控制，是否针对运维自动化平台的服务器账号做了特殊限制？是否做了超限检查？是否做了关键操作的双保险？是否做了作业执行脚本、数据传输的加密控制？通通都得考虑，而堡垒机、安全审计、防火墙控制等措施更是不在话下了。

运维自动化安全建设牵扯面广，这里就不一一赘述了。还得提醒一点，在运维自动化操作层面，如何缓解自动化操作条件的变化而引发的巨大运维压力，也应该认真考虑。