运维自动化与标准规范化：解析、设计及实现

本文主要介绍我们的运维自动化系统如何设计与实现的，在介绍运维自动化时，首先需要先探讨一下运维标准规范化与自动化关系，因为这是大多数运维自动化的必经之路，也是很多运维体系成长的必经之路。

一、运维标准化、规范化、流程化

要做运维自动化，首先要落实运维体系的标准化、规范化、流程化。否则，如果不规范标准化，很难具体实施运维自动化。

在开发运维自动化系统过程与执行中，会有很多事情无法开展，或很难执行下去。

1.1 对于运维自动化与标准规范化的认识

对于运维自动化、标准规范化的认识与理解。

不同企业圈子，每个人的理解总会有差异性，但总体方向应该是一致的：我们需要运维自动化、标准化，因为它能促使我们的工作更加高效、智能、有规则，有预见性……对于运维自动化，标准规范化的认识，这里举例说明两种极端类型。

极端类型一：极端排斥流程标准及自动化，认为这是噱头，不干实事，不出成果。

这种类型的人做事貌似风风火火，思考规划10分钟，边想边干1整天，结果到了明天再重来——典型地边计划边实施边填坑，结果是又忙又乱又出错。

其实这种类型的问题就出在：事前没有规划好，事中没有实施好，事后没有总结好，无规矩不成方圆。

针对该类型，我们的观点是：标准规范与自动化是当前主流运维成熟进阶的必经之路。

流程标准很重要，必须要执行与持续完善，这是运维自动化以及公司运营一切的基础。

看过复杂的航空线路图，航海线路图，铁路交通图吧！是不是会感叹标准化与自动化的重要性。

运维工作也是一样的道理，例如在实际项目过程中，你要上新业务买设备，则需要提出技术需求，找财务、上级会签审批，然后还得招投标(内部邀标)， 签合同，收到货得付款，设备入库备案，初始化设备，自动化部署系统，自动化部署应用，自动采集信息与告警……等等，正是这些规范流程，运维自动化才使我们 的运维工作高效能、高质量、低风险。

极端类型二：极端追求标准流程。例如还是上述购新业务及采购设备流程。该类型的人做事非常规范细致：

while (true): {

调研;

开会;

统计需求;

提交审批;}

如此一遍又一遍的死循环，必须做到极致。如此结果是今年的需求，明年服务器才到货，后年业务才上线，为了部署一次性就全面全部OK，就费尽穷举一切可能，但凡有例外，就认为不是自动化，标准化。

这样做貌似流程规范做到了天衣无缝，但其结果往往是人算不如天算，因为时间事情随时在变，最后在实际生产中还是会有意外尴尬事情发生……

针对该类型，我们的观点是：流程规范是最佳实践方法论，但不是目的。

从哲学角度，这个世界不完美，因此2/8原则与持续性改进应该是思考与解决事情的一种最佳实践。流程标准固然很重要，但是流程标准目的是为了很好地执行并解决事情，而不是要卡死、堵死一系列意外。

我们没必要纠结于高大全的标准与自动化，我们需要从运维需求出发，痛点出发，持续改进与解决运维实际问题。

例如，在做自动化部署过程，总会有一些例外的情况。例如批量部署salt minion，由于系统版本，安装批次不一样。导致有些salt安装因没有依赖包而部署失败。

这就要考虑，自动部署环节是要考虑增加更多状态部署细节，还是保留一个精简的状态部署方案。

或许对于一个例外问题，例外分析与解决，而不是为了这一个例外而变动所有的全体。记住，不要认为搞个运维自动化系统，部署一个saltstack，puppet工具就能解决所有运维问题。

1.2 运维自动化与标准规范化的关系

任何一个企业运行都有很多配套的公司流程标准，否则很多事情将一团乱麻，根本无法推行，运维自动化也不例外，实施自动化前提需要标准规范与流程化。

比如，如果系统版本，主机名，IP不统一规范，则可能会导致saltstack部署执行，zabbix自动化发现，日志监控部署，应用部署等一系列问题。

没有良好的标准与自动化解决方案，运维人员常会背黑锅

运维自动化需要规范标准化，当然运维自动化又促进规范标准化。运维自动化，标准化需要落实，不能空谈，不能只说不练，有“法“不依。

标准要深入人心，融入日常行为思想中，达到个人与集体的潜移默化间的一致性、共通性。例如，我们总会碰到一些不规范的程序员，随意往线上部署了一段代码，搞得系统缓慢，最后由运维人员背黑锅。

标准与自动化往往是由业务、IT环境需求驱动的

诸如上述，运维自动化与标准化往往是由业务，IT环境驱动的，逐步优化完善出来的，或者是被动逼出来的。比如，由于业务增长迅速，系统(应用)环境需求天天都有很多。

那你还是手工一台台系统(应用)部署么，或许就算键盘敲到手抽筋仍然没完成业务需求，这时突然你又发现部署的代码不一致…..此时估计整个人都快要”疯掉了”，或许此时你对运维自动化，标准规范化的理解与需求会透彻骨子里。

标准与自动化需要持续性改进优化

运维自动化不是一蹴而就，而是逐渐持续性优化改进(ITIL理念)和实施的。

没有任何一个企业创立之初，其IT架构就非常高大上，上来就构建全球机房，初始就设计一个超级高性能，高安全的系统，立刻满足上亿的UV请求……这些或许没必要，也几乎不可能。