本文首发于知乎,由嘉为蓝鲸原创。
商业转载请联系作者获得授权,非商业转载请注明出处。
在了解两者的区别前,我们得先明确对二者的定义,总的来说运维工作的目的都是为了保障企业业务连续性,核心在于提供高效、高质量、安全的IT运维服务。
大部分人对“普通运维”的认知应该是指IT的传统运维模式,大量依靠人工的手段去维护企业基础设施和应用运行稳定,基本都包括日常维护、监控保障、变更发布、资源管理、运维流程、服务支持等内容。至于“自动化”这一词,随着现代控制理论和电子计算机的出现,更多的是指将自动控制和信息处理相结合,使得机器设备、系统或过程在没有人或较少人的直接参与下,按照人的要求,经过自动检测、信息处理、分析判断和操作控制来实现预期的目标的过程。
放到自动化运维的维度,更多的是针对特定的运维场景,将运维一线人员长期做的一些周期性、重复性的工作抽离出来,借助自动化工具或平台来替代或协助完成运维工作,提升运维效率降低系统风险,促进运维组织的成熟和能力的升级。
“普通运维”和自动化运维并不存在严格的边界划分,自动化运维是普通传统运维演进的一种更高阶状态。至于为何企业运维部门会大力投入资源做运维的自动化升级,根源在于围绕运维的三个核心(效率、质量、安全),原来的传统运维方式都存在着对应的问题:
就笔者近几年在各个行业内的调研和实践情况来看,企业IT部门的数字化水平和运维部门的工具能力建设都难以支撑或无法完全替代传统运维的全部工作,要实现真正意义上的完全自动化运维还存在包括运维技术和理念、企业内部管理制度和工作规范等等的约束,但传统运维方式向自动化逐步演进的趋势是可以预见的。
2016年互联网行业开始进入所谓下半场,各种“数字经济”“云原生”“大数据”“AI”等概念层次不穷,传统行业特别是金融、能源、政府单位等也开始卷入数字化转型的大潮,从业务端数字化最先开始也即转向O2O、云计算到传统开发架构转向云原生,最终运维也随之主动或被迫迎来属于自己的数字化转型。
其中自动化运维就是数字化转型中很热门的话题之一,在2017-2020年间是各企业/单位纷纷上马各类自动化运维项目最为活跃的时期。但在落地后的一段时间渐渐会发现还是存在种种的问题,比如各工具相对独立无法实现联动,工具扩展性能差,开源工具漏洞无人维护,IT的配置数据不准确等,原本的目的是希望借助自动化工具能提升运维的效率,没想到在某种程度上反而成为制约运维效率提升的原因之一。
近两年来这些企业又开始返工,回来重新修炼“基本功”。在笔者看来要实现从普通运维向自动化运维的升级,必须先做好以下几方面的基本功,否则自动化运维只会昙花一现,无法持续的支撑运维工作,更谈不上提升运维工作的效率和保障业务的数字化转型。那么企业要实现自动化运维之前要做好哪些铺垫呢?
笔者认为运维的数字化转型依次遵循“对象数字化”、“行为数字化”、“运营数字化” 的方式是目前最佳的演进路径。具体来说,建议企业在对运维进行数字化转型或运维升级的过程中,首先将CMDB作为企业IT架构进行数字化描述的基础,只有实现IT架构中每一个对象的数字化,才能实现其状态的数字化,从而实现其可观测性,进而通过操作和服务行为的数字化,实现不同场景下的运维自动化来保障业务的连续性和敏捷性。在此基础上才有可能实现运维的终极目标——构建企业级的技术运营体系,全面支撑企业数字化实现成功。
值得一提的是,并非要求所有企业一定严格按照以上的路径来提升自己的运维水平,建议企业可以根据自身的实际情况在统一的运维平台之上进行建设,一方面对于已有的工具可以尽量整合充分利旧,另一方面对于缺失的能力进行补足和加强。
如果我们企业在前期已经有了相对扎实的基础,比如有比较完善的配置管理系统、监控告警体系和运维流程管理平台再来考虑自动化运维的建设会更加合理,避免出现返工或重复建设的情况,落地的效果和产生的收益也会更显著。笔者认为落地自动化运维要分为以下几个步骤:
企业可组织梳理现在内部的运维工具特别是自动化工具的建设情况,是否具备脚本/命令批量执行、文件下发和数据采集能力,是否具备作业执行包括定时、API调用和作业编排的能力,是否拥有跨区域的平台底座,评估现有人员的配置情况和能力。最简单的方式见下图判断企业目前处于自动化运维成熟度的哪一阶段?
组织一个团队负责自动化基础平台的建设,IT各个部门和组织根据需求自行在平台上开发SaaS工具。既要求发挥多方的积极性,又可以形成很好的合力,兼顾个性化需求和团队共性。这就对平台本身的建设提出极高挑战,要求能够提供统一架构、统一认证、统一调用、统一接入等能力,实现自动化工具的敏捷和快速迭代。
这意味着自动化运维平台的能力层(PaaS)需要将原有的运维能力进行拆分,将公用的能力沉淀下来形成各个原子比如有管控平台、作业平台、标准运维等,有统一接入的接口API Gateway能对接外部的系统和第三方工具(iPaaS),同时具备基于PaaS的开发框架针对不同的运维场景去做运维工具的开发(aPaaS)。正是基于运维平台开发的所有自动化工具才能在平台上能实现天然的交互联动,形成真正统一的自动化运维平台。
绝大部分的运维流程都会同时涉及到各类操作执行流和审批流,因此有必要提前梳理清楚各类运维流程,比如在金融行业都会有非常严格的运维流程要求,一般都会参照像ITIL、ISO20000、ITSS等的标准去建设。对于已完善的流程要梳理哪些环节可以通过自动化手段代替或协助完成,保证涉及的流程节点尽量实现线上化、自动化、标准化,以此提高整个流程的效率。
通过OASR(对象-场景-工具-人员)模型具体分析运维场景,首先明确针对的是哪些运维对象、应用系统和基础架构;其次梳理现有运维的组织架构中人员的构成,针对这些运维对象可以使用哪些运维工具;最后我们对运维操作进行编排和执行,形成自动化运维的场景。按这类方法梳理出来的场景会有很多,在这里我们核心解决日常运维任务、应用发布、灾备切换、资源交付等自动化场景。
针对不同的运维场景,嘉为蓝鲸提供一系列自动化运维解决方案,自动化运维提升的关键在于IT对象执行能力的整合和场景构建。为实现ITOM融合的体系自动化并全面覆盖运维工作,需在执行能力整合达到运维能力原子化的基础上完成跨IT对象的执行编排调度,从单对象的自动化突破到发布、灾切、应用巡检等复合场景的构建。
限于篇幅的原因,在这里笔者提供三个常见的自动化运维场景(应用发布自动化、灾备切换自动化、巡检自动化)供题主参考,后续其他自动化场景可持续扩展。
背景:应用架构不断更新,用户需求激增,应用数量成倍增长,发布迭代的速度越来越快。应用运维确保应用稳定运行,还需同时响应研发、业务诉求,完成版本变更或上线交付,提供相关服务给到业务、运营和测试等外部人员。 产品能力:嘉为蓝鲸应用发布中心支持单体、SOA、微服务、容器化应用的发布与管理;支持程序包、配置文件及其实例化、SQL包、模板集(K8s YAML文件)的发布;支持多应用、多实例、多环境、多集群发布;支持定时、并行、滚动、分批发布、蓝绿发布、灰度发布等方式;可快速发布或回滚,具备灵活的可视化编排引擎。帮助企业高效、快速、规范、稳定地实现自动化部署。
背景:企业对业务中断的容忍度不断降低,业务架构复杂度提升,切换流程也越来越复杂。企业能否顺利完成灾备切换,取决于灾备系统的建设,灾备演练是否充分以及灾备切换步骤是否准确到位。同时企业需要通过实际的灾备切换演练来不断地优化改进灾备预案。 产品能力:嘉为蓝鲸灾备切换自动化提供灵活的流程编排能力,帮助企业实现应用灾备切换及恢复的预案管理和操作自动化,支持一键灾备切换和大屏跟踪展示,能够保证企业定期灾备切换活动的成功进行,同时助力企业数字化转型。
背景:自动化巡检是对网络、服务器、服务/应用的巡检手动操作转变成自动化的形式。通常巡检工作面临如下几个场景的问题:
产品能力:嘉为蓝鲸自动化巡检中心改变运维人员传统重复手动巡检的工作方式,支持用户自定义巡检脚本和巡检对象,覆盖即时性、周期性等巡检场景,根据任务计划实现自动化巡检并生成标准可视化报告,减少巡检工作量并提高巡检有效性,助力运维人员轻松全面掌握IT对象运行状态及潜在风险。