企业应用运维定义
我们把企业内的IT团队做一个初步职责和边界划分：
运维的起始点是拿到开发的代码包开始，然后进行资源环境准备、环境搭建、应用发布，以及一些列的运维支撑保障工作；而从运维团队内部来看，大致从技术栈层面分为几类：
IDC运维：负责操作系统及以下的运维支撑工作，主要提供稳定的网络、存储和服务器。
SA：系统管理员，负责操作系统以上，代码以下的运维管理工作，不过有的公司，由于中间件的运维支撑与应用关联紧密，很多时候SA只负责操作系统和数据库两个内容。
应用运维：核心职能是确保进程和服务可用，同时响应研发、运营人员的诉求，维护新版本的稳定运行，以及提供数据和服务给到运营人员。
应用运维在各个行业里面都非常重要，其发挥的价值深度，对于公司业务支撑保障和与优化辅助，都起着至关重要的作用，但面临的困境也很多。
应用架构多样性、异构化程度大；无论是多年前无法重构的单体架构，SOA架构的应用，微服务架构应用，基于业务中台的架构，还是近几年号召的云原生架构，越大的企业，应用的多样与异构化程度就越大，对于应用运维人员的技术栈要求高，管理复杂度大。
安全和质量级别要求高；无论是新版本发布，灾备切换与演练，应用故障处理还是其他维护场景，都直接影响应用服务的可用性，更不要说因为操作权限很高，可能出现误操作或破坏性行为的风险。
效率要求高；快速发现问题，定位问题和触发预案处置，每一个节点的速度都影响了SLA，因而应用运维主动和被动响应的要求都越来越高，没有自动化手段已经无法解决现有的局面。
无法提供数据分析的增值服务；应用运维拥有核心的日志、配置、监控数据，这些数据往往能通过一些技术手段分析后，提供给运营人员，给他们带来增值服务，而日常繁杂的工作，和缺乏有效的数据分析手段，导致价值没有得到充分发挥。
应用运维自动化设计前提
- 应用的异构化是一个长期存在的状态。
- 应用运维自动化平台具备适应灵活场景的能力，具备很强的扩展性。
为什么需要有这两个约束，最核心的原因是如果企业的业务标准化程度足够高，甚至全部能云原生化，这个时候业务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平台给予所有场景所需的能力。整体设计解决了几个关键问题，异构化的应用如何不侵入做运维、如何做到可持续性建设或足够的扩展性、架构分层带来场景的灵活性、生命周期的工具链满足整体保障与效能提升场景。
作者：张敏
以上，笔者参考和研究一些资料后，以及结合企业经验的一些个人感受和理解，了解更多，请参考：
腾讯蓝鲸平台
https://bk.tencent.com/
嘉为蓝鲸（基于腾讯蓝鲸智云构建）
http://tech.canway.net/
