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