企业应用运维自动化应该如何设计?

应用运维拥有核心的日志、配置、监控数据,这些数据往往能通过一些技术手段分析后,提供给运营人员,给他们带来增值服务,而日常繁杂的工作,和缺乏有效的数据分析手段,导致价值没有得到充分发挥。

2345截图20200908083720.png

企业应用运维定义

我们把企业内的IT团队做一个初步职责和边界划分:

2345截图20200908083720.png

运维的起始点是拿到开发的代码包开始,然后进行资源环境准备、环境搭建、应用发布,以及一些列的运维支撑保障工作;而从运维团队内部来看,大致从技术栈层面分为几类:

IDC运维:负责操作系统及以下的运维支撑工作,主要提供稳定的网络、存储和服务器。

SA:系统管理员,负责操作系统以上,代码以下的运维管理工作,不过有的公司,由于中间件的运维支撑与应用关联紧密,很多时候SA只负责操作系统和数据库两个内容。

应用运维:核心职能是确保进程和服务可用,同时响应研发、运营人员的诉求,维护新版本的稳定运行,以及提供数据和服务给到运营人员。

应用运维在各个行业里面都非常重要,其发挥的价值深度,对于公司业务支撑保障和与优化辅助,都起着至关重要的作用,但面临的困境也很多。

应用架构多样性、异构化程度大;无论是多年前无法重构的单体架构,SOA架构的应用,微服务架构应用,基于业务中台的架构,还是近几年号召的云原生架构,越大的企业,应用的多样与异构化程度就越大,对于应用运维人员的技术栈要求高,管理复杂度大。

安全和质量级别要求高;无论是新版本发布,灾备切换与演练,应用故障处理还是其他维护场景,都直接影响应用服务的可用性,更不要说因为操作权限很高,可能出现误操作或破坏性行为的风险。

效率要求高;快速发现问题,定位问题和触发预案处置,每一个节点的速度都影响了SLA,因而应用运维主动和被动响应的要求都越来越高,没有自动化手段已经无法解决现有的局面。

无法提供数据分析的增值服务;应用运维拥有核心的日志、配置、监控数据,这些数据往往能通过一些技术手段分析后,提供给运营人员,给他们带来增值服务,而日常繁杂的工作,和缺乏有效的数据分析手段,导致价值没有得到充分发挥。

应用运维自动化设计前提

在应用运维自动化设计前,我们需要有两个基本的共同认知,这样才能保障整体的设计规划是有效的。

应用的异构化是一个长期存在的状态。

应用运维自动化平台具备适应灵活场景的能力,具备很强的扩展性。

2345截图20200908083720.png

为什么需要有这两个约束,最核心的原因是如果企业的业务标准化程度足够高,甚至全部能云原生化,这个时候业务API也是服务、函数也是服务。而云自身能提供足够高的可用性和保障功能,其实对于体系化的自动化运维平台需求并没那么强烈了,因为在这种理想化的情况下,场景足够单一了,并不需要适配各种异构化的场景。但是我们都知道,目前实际情况来看,多种架构和类型的应用共存,是一个可能很长期的状态。因而,从设计原则看:

平台化架构:

把应用运维需要的通用能力沉淀下来,然后场景可以保留持续扩展构建的能力,只有这样,才能适配应用运维过程中,各种灵活和自定义的运维场景。

原子化:

丰富应用运维的最小操作单元,然后基于平台可以快速迭代出各类场景,例如有了分发文件、执行脚本的原子,就可以编排出一个简单的应用发布自动化场景。

要覆盖企业应用运维全生命周期:

从应用的上线、运行,到后续一系列运维场景和过程来规划所需的功能和工具;

标准性:

从输入、输出、操作规范、安全控制等方面对运维操作组件进行规范性约束。

基于应用生命周期设计应用运维自动化

我们从应用运维的生命周期来看,大致分为如下几个部分:

2345截图20200908083720.png

应用上线:应用上线前的标准化资源与运行环境准备,以及应用上线过程中的发布与更新操作。

应用上线的资源准备实现资源交付标准化:包括基础资源准备,数据库、中间件、组件资源准备,而且保持标准化的环境部署,如程序路径、组件配置等。

应用上线包括新的版本发布与版本更新:实现批量发布、回滚、发布依赖的自动化。

应用运行:应用上线后,运行过程SLA保障运维服务。

应用巡检:包括OS、DB、组件、进程、模块的功能性、规范性、安全性、性能巡检,从基础组件服务状态、日志关键字来反馈应用整体运行状态。

应用监控:监控应用的可用性、功能模块的可用性、调用链监控和性能监控(APM),整合统一的告警中心服务,实现故障的预警与告警。

应用配置管理:包括应用的配置模型,对象、属性、关联关系,和应用配置文件的版本、配置下发、程序包绑定的管理。

运维流程协同:运维流程基本管理,事件、问题、变更、知识库管理,以及相应协同部门的服务请求,包括运营用户服务目录等。

故障处理:应用运行过程中的故障分析和处理环节,快速恢复应用可用性。

日志分析:实现统一的日志搜集、存储与分析平台,辅助排障人员快速获取到关联日志。

故障定位:基于CMDB的关联关系,确定影响范围,细化故障点;并逐步演进到AIOps智能监控领域,通过多个指标异常检测、知识图谱、故障链传播,实现智能化的快速故障点定位。

故障自愈:基于自动化编排引擎,实现常用的故障自动化处理,包括日志清理、服务重启、参数调整等操作编排;未来可扩展引入AIOps,与知识库关联,实现智能预案推荐。

生产操作:应用运维过程中,需要主动性的完成很多变更或周期性的运维操作。

灾备切换自动化:实现企业应用容灾管理的自动化、可视化,让灾备切换与演练成为常态,检验应用灾备架构,和实现灾难的快速恢复。

扩缩容自动化:根据业务类型,实现应用架构、底层资源的容量管理,包括容量分析模型、容量预测、自动扩缩容操作编排。

服务启停:日常运维过程中需要对服务进行批量启停,以及服务依赖编排的启停管理。

其他可以提升运维效率和安全性的工具系统,包括报表、作业、安全加固等场景化的操作管理。

增值服务:指基于运维大数据服务的能力,面向运营人员,提供数据分析服务或工具辅助服务。

数据分析与提取:对接各个业务系统数据、日志数据、指标数据、事件或告警数据,面向运营人员提供数据计算结果服务,辅助运营人员决策、分析和判断。

运营辅助工具:面向运营人员个性化需求,封装底层工具系统和数据服务,提供辅助工具,如用户体验管理、智能扩容建议等。

我们挑几个重点模块,结合基于蓝鲸客户化落地场景,进行阐述说明。

1.应用的配置管理如何建设?

应用的配置管理是应用实现自动化运维的基石,应用的配置管理建设应该涵盖两个方面的内容,一方面是基于业务和应用维度建立CMDB配置管理模型,且配置管理模型是属于企业整体CMDB的一部分,并实现数据导入或自动采集;另外一方面是与CMDB中具体应用模块关联的配置文件管理。

2345截图20200908083720.png

利用蓝鲸CMDB模块,则很便捷的实现应用模型管理,包括应用层级和模型自定义。

2345截图20200908083720.png

2345截图20200908083720.png

基于蓝鲸平台构建应用管理SaaS,实现配置文件管理,并把配置文件管理与应用的模块、主机、资源(软件包等)、程序包进行整体关联,实现配置文件版本管理、批量配置下发、参数提取等管理行为。

2345截图20200908083720.png

2.应用发布如何设计?

企业的应用发布设计需要考虑几个关键要素:应该基于CMDB消费发布过程中的配置信息、配置文件与程序包的管理是为应用发布提供资源服务的、需要依赖比较强大和灵活的自动化编排引擎。

基于蓝鲸平台的工具构建能力,和蓝鲸自动化编排引擎一级saas标准运维,实现企业级灵活的发布场景。把发布过程中的操作原子化,然后封装成相对固化的场景;把发布需要的配置和资源信息,提前基于CMDB和应用管理封装好。

2345截图20200908083720.png

3.应用灾备切换设计?

企业应用灾备切换自动化设计主要考虑几个关键要素:需要原子化对接灾备过程中的各个对象,前端路由切换、数据库、虚拟化、网络等;依然需要强大的编排引擎;灾备演练和切换要做到可视化。

2345截图20200908083720.png

2345截图20200908083720.png

4.数据分析服务如何设计?

运维中产生的数据很多,运维数据的异构化和数据类型特别复杂,包括指标、事件、告警、日志、CMDB等数据,覆盖mysql、InfluxDB、MongoDB、文本文件等多个数据类型,且分散在各个系统中,平台要求具备很强的适配性和灵活性,通过单一Agent和数据管道解决异构化数据接入和适配的问题。

因而运维大数据服务平台应该和业务大数据服务平台单独考虑,运维大数据平台建设需要考虑几个关键因素:数据采集、低门槛的数据开发、数据开发结果可消费。

2345截图20200908083720.png

应用运维自动化设计架构

我们围绕应用运维自动化的生命周期,可以分层来看所需要的能力,包括所有场景都需要的平台能力、对应环节需要的功能模块、其他组合场景模块。

2345截图20200908083720.png

整体架构描述:

从层次上来看:PaaS平台提供工具所需的公共模块能力,例如CMDB、Agent、作业执行等;应用自动化工具链,提供满足企业应用自动化运维生命周期的工具链,并基于平台整体能力实现融合;场景组合SaaS,少量代码拼装出各类灵活的场景,例如节假日值班、应急中心等。

场景是灵活且个性化的,因而需要PaaS化的平台支撑。

iPaaS层:API GateWay(统一接入模块),将配置管理(CMDB)平台、作业平台、数据平台、挖掘平台等原子平台统一接入、集成、驱动和调度,供上层运维场景APP驱动和调用。

aPaaS开发者中心(提供前后端开发框架):开发者中心提供完整的前后端开发框架,当企业在未来出现新的运维需求的时候,企业可以快速利用开发者中心完成相应的运维系统开发,并一键部署。

总结

互联网+的时代,各种应用赋能企业业务普遍,从研发、运维至运营测都面临到应用异构、响应业务的效能要求、安全与质量把控、数字化助力业务的挑战。我们在文章中基于应用生命周期设计应用运维自动化,并利用PaaS平台给予所有场景所需的能力。整体设计解决了几个关键问题,异构化的应用如何不侵入做运维、如何做到可持续性建设或足够的扩展性、架构分层带来场景的灵活性、生命周期的工具链满足整体保障与效能提升场景。

THEEND

最新评论(评论仅代表用户观点)

更多
暂无评论