本文主要介绍我们的运维自动化系统如何设计与实现的,在介绍运维自动化时,首先需要先探讨一下运维标准规范化与自动化关系,因为这是大多数运维自动化的必经之路,也是很多运维体系成长的必经之路。
要做运维自动化,首先要落实运维体系的标准化、规范化、流程化。否则,如果不规范标准化,很难具体实施运维自动化。
在开发运维自动化系统过程与执行中,会有很多事情无法开展,或很难执行下去。
对于运维自动化、标准规范化的认识与理解。
不同企业圈子,每个人的理解总会有差异性,但总体方向应该是一致的:我们需要运维自动化、标准化,因为它能促使我们的工作更加高效、智能、有规则,有预见性……对于运维自动化,标准规范化的认识,这里举例说明两种极端类型。
极端类型一:极端排斥流程标准及自动化,认为这是噱头,不干实事,不出成果。
这种类型的人做事貌似风风火火,思考规划10分钟,边想边干1整天,结果到了明天再重来——典型地边计划边实施边填坑,结果是又忙又乱又出错。
其实这种类型的问题就出在:事前没有规划好,事中没有实施好,事后没有总结好,无规矩不成方圆。
针对该类型,我们的观点是:标准规范与自动化是当前主流运维成熟进阶的必经之路。
流程标准很重要,必须要执行与持续完善,这是运维自动化以及公司运营一切的基础。
看过复杂的航空线路图,航海线路图,铁路交通图吧!是不是会感叹标准化与自动化的重要性。
运维工作也是一样的道理,例如在实际项目过程中,你要上新业务买设备,则需要提出技术需求,找财务、上级会签审批,然后还得招投标(内部邀标),签合同,收到货得付款,设备入库备案,初始化设备,自动化部署系统,自动化部署应用,自动采集信息与告警……等等,正是这些规范流程,运维自动化才使我们的运维工作高效能、高质量、低风险。
极端类型二:极端追求标准流程。例如还是上述购新业务及采购设备流程。该类型的人做事非常规范细致:
while (true): {
调研;
开会;
统计需求;
提交审批;}
如此一遍又一遍的死循环,必须做到极致。如此结果是今年的需求,明年服务器才到货,后年业务才上线,为了部署一次性就全面全部OK,就费尽穷举一切可能,但凡有例外,就认为不是自动化,标准化。
这样做貌似流程规范做到了天衣无缝,但其结果往往是人算不如天算,因为时间事情随时在变,最后在实际生产中还是会有意外尴尬事情发生……
针对该类型,我们的观点是:流程规范是最佳实践方法论,但不是目的。
从哲学角度,这个世界不完美,因此2/8原则与持续性改进应该是思考与解决事情的一种最佳实践。流程标准固然很重要,但是流程标准目的是为了很好地执行并解决事情,而不是要卡死、堵死一系列意外。
我们没必要纠结于高大全的标准与自动化,我们需要从运维需求出发,痛点出发,持续改进与解决运维实际问题。
例如,在做自动化部署过程,总会有一些例外的情况。例如批量部署salt minion,由于系统版本,安装批次不一样。导致有些salt安装因没有依赖包而部署失败。
这就要考虑,自动部署环节是要考虑增加更多状态部署细节,还是保留一个精简的状态部署方案。
或许对于一个例外问题,例外分析与解决,而不是为了这一个例外而变动所有的全体。记住,不要认为搞个运维自动化系统,部署一个saltstack,puppet工具就能解决所有运维问题。
任何一个企业运行都有很多配套的公司流程标准,否则很多事情将一团乱麻,根本无法推行,运维自动化也不例外,实施自动化前提需要标准规范与流程化。
比如,如果系统版本,主机名,IP不统一规范,则可能会导致saltstack部署执行,zabbix自动化发现,日志监控部署,应用部署等一系列问题。
运维自动化需要规范标准化,当然运维自动化又促进规范标准化。运维自动化,标准化需要落实,不能空谈,不能只说不练,有“法“不依。
标准要深入人心,融入日常行为思想中,达到个人与集体的潜移默化间的一致性、共通性。例如,我们总会碰到一些不规范的程序员,随意往线上部署了一段代码,搞得系统缓慢,最后由运维人员背黑锅。
诸如上述,运维自动化与标准化往往是由业务,IT环境驱动的,逐步优化完善出来的,或者是被动逼出来的。比如,由于业务增长迅速,系统(应用)环境需求天天都有很多。
那你还是手工一台台系统(应用)部署么,或许就算键盘敲到手抽筋仍然没完成业务需求,这时突然你又发现部署的代码不一致…..此时估计整个人都快要”疯掉了”,或许此时你对运维自动化,标准规范化的理解与需求会透彻骨子里。
运维自动化不是一蹴而就,而是逐渐持续性优化改进(ITIL理念)和实施的。
没有任何一个企业创立之初,其IT架构就非常高大上,上来就构建全球机房,初始就设计一个超级高性能,高安全的系统,立刻满足上亿的UV请求……这些或许没必要,也几乎不可能。