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

企业应用运维定义

咱们把企业内的IT团队作一个初步职责和边界划分：

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

IDC运维：负责操做系统及如下的运维支撑工做，主要提供稳定的网络、存储和服务器。

SA：系统管理员，负责操做系统以上，代码如下的运维管理工做，不过有的公司，因为中间件的运维支撑与应用关联紧密，不少时候SA只负责操做系统和数据库两个内容。

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

应用运维在各个行业里面都很是重要，其发挥的价值深度，对于公司业务支撑保障和与优化辅助，都起着相当重要的做用，但面临的困境也不少。

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

安全和质量级别要求高；不管是新版本发布，灾备切换与演练，应用故障处理仍是其余维护场景，都直接影响应用服务的可用性，更不要说由于操做权限很高，可能出现误操做或破坏性行为的风险。

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

没法提供数据分析的增值服务；应用运维拥有核心的日志、配置、监控数据，这些数据每每能经过一些技术手段分析后，提供给运营人员，给他们带来增值服务，而平常繁杂的工做，和缺少有效的数据分析手段，致使价值没有获得充分发挥。

应用运维自动化设计前提

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

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

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

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

平台化架构：

把应用运维须要的通用能力沉淀下来，而后场景能够保留持续扩展构建的能力，只有这样，才能适配应用运维过程当中，各类灵活和自定义的运维场景。

原子化：

丰富应用运维的最小操做单元，而后基于平台能够快速迭代出各种场景，例若有了分发文件、执行脚本的原子，就能够编排出一个简单的应用发布自动化场景。

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

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

标准性：

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

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

咱们从应用运维的生命周期来看，大体分为以下几个部分：

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

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

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

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

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

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

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

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

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

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

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

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

生产操做：应用运维过程当中，须要主动性的完成不少变动或周期性的运维操做。

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

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

服务启停：平常运维过程当中须要对服务进行批量启停，以及服务依赖编排的启停管理。

其余能够提高运维效率和安全性的工具系统，包括报表、做业、安全加固等场景化的操做管理。

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

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

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

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

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

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

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

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

2.应用发布如何设计？

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

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

3.应用灾备切换设计？

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

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

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

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

应用运维自动化设计架构

咱们围绕应用运维自动化的生命周期，能够分层来看所须要的能力，包括全部场景都须要的平台能力、对应环节须要的功能模块、其余组合场景模块。

总体架构描述：

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

场景是灵活且个性化的，于是须要PaaS化的平台支撑。

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

aPaaS开发者中心（提供先后端开发框架）：开发者中心提供完整的先后端开发框架，当企业在将来出现新的运维需求的时候，企业能够快速利用开发者中心完成相应的运维系统开发，并一键部署。

总结

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

做者：张敏

优质文章

域内计算机本地管理员密码管理

腾讯PaaS平台 | 主机名设置错误怎么办？

Redis持久化介绍

4大步骤节省30%浪费，优化企业上云成本从了解云开始！

运维思考 | 你知道CMDB与监控是什么关系吗？