DevOps干货|关于自动化运维的规范要求

前言

总所周知现在互联网化虽然在我们国家也已经二三十年的发展，但是在很多传统的金融公司相对技术还是比较落后，这里面一方面因为体量大，转型存在一定的时间周期，另一方面也是因为牵扯面较大，系统稳定性是第一要务，追求稳比追求新更加值得重视。

一到生产变更ECC会成为一道靓丽风景线，里面开发、运维、业务等齐聚一堂呈现一番热闹景象。我们作为其中一员也是如此，炎炎夏日，为了减少大家“出汗”，提高变更效率和质量，自动化运维再次被提上了日程。。。

什么是自动化运维

现在IT系统的复杂性已经客观上要求IT运维必须能够实现数字化、自动化维护。所谓自动化运维是指通过将日常IT运维中大量的重复性工作（小到简单的日常检查、配置变更和软件安装，大到整个变更流程的组织调度）由过去的手工执行转为自动化操作。

自动化运维是指基于流程化的框架，将事件与IT流程相关联，比如变更自动化主要是将原手工操作改为通过自动化工作流来操作变更，通过启动某业务流程即可完成生产上线动作；再比如事件响应自动化运维，一旦监控系统发生某应用性能超标或宕机，会触发相关事件以及事先定义好的流程，可自动启动故障响应和恢复机制；更加智能化的运维的自动化还要求能够预测故障、在故障发生前能够报警，并自动处理，把故障消除在发生前，将所产生损失减到最低。

怎么用自动化做变更

一提到自动化，迷恋技术的同学就会列出各种技术工具Puppet、SaltStack、Ansible等等，我们主要用的是基于ansible的AWX来实现变更自动化，具体安装以及网上的资料不少，可以自行研习。自从上了自动化，并没有出现“腰不酸，腿不疼，一口气上五楼” 的神奇疗效，原来的变更人员效率虽有提升，但是自动化人员却疲于“奔命”，出现生产变更问题还是偶有发生，所以我们觉得自动化的“术”不是最重要的，重要的是理清“道”，哪些场合使用自动化，怎么使用，使用后怎么检查要提前理清和界定好。

宗旨：生产变更一旦启动自动化流程，自动化平台自身不做任何生产调整，因为存在牵一发动全身风险不可控问题，它是生产的生产；

一、使用场景

适用重复、多节点、规律性的运维动作

• 常规变更

• 改密

• 巡检

• 主备切换

不适用于应急、突发性的动作

• 应急变更变更回退

• 上线个性化变更

• 单主机操作

二、自动化业务流程规范

1.变更后系统是健康的状态是首要的，所以在升级后应当有应用健康状态检查；2.将具体的变更内容形成独立脚本，用以关联不同自动化流程操作步骤；这种适合开发和运维完全独立的团队，因为彼此不了解系统运行的内部机制，如果可以做到开发运维联动，那么做到CI/CD可以更方便快捷；

三、变更介质规范

1.变更的生产介质包里需步骤脚本化，减少人工判断，也是变更审计留痕的基础；

2.做到测试、模拟与生产自动化流程的一致性，否则生产出问题概率很大，因为自动化的前提就是要标准和规范，每一个环境不一致自动化流程就是形式而已。

3.变更脚本在关联自动化流程之前要经得起测试、模拟、生产等不同环境检验，否则存在自动化执行中断的情况；

总结

IT运维从诞生发展至今，自动化作为其重要属性之一已经不仅仅只是代替人工操作，更重要的是深层探知和全局分析，关注的是在当前条件下如何实现性能与服务最优化，比如容器化中对设备的自动增减以及遇到性能瓶颈的扩张节点、性能富裕时的减少节点等（参考之前文章），当然这也与产品结构和规模挂钩，一味的追求新技术可能会得不偿失，找到适合自己的才是最好的。

所以自动化运维不仅需要帮助运维人员完成日常的重复性工作，提高运维效率，而且运维自动化还要求能够预测故障、在故障发生前能够报警，把故障消除在发生前，将所产生损失减到最低，这就是与需要监控系统（参考之前zabbix文章）的结合来推进智能化运维的范畴了，我们将来有机会再讨论。