立体运维架构与定位

写在前面

随着越来越多企业应用上云，云上应用的规模与复杂度日趋增长，对云上应用的运维，也提出了新的挑战。华为云AOM服务面向大规模企业应用的运维，在实践中演进并构建了一套完整的面向云上应用的立体化运维系统。

一、常见云上应用的架构

云上应用早期较多的是购买云服务I层资源（多为基础设施如主机等计算资源）自建各种集群，运维人员多以主机监控为中心进行运维，同时自己搭建应用及数据库等监控系统进行应用层和业务层运维。随着容器技术的普及，越来越多的企业转向CaaS和PaaS来管理应用，通过微服务框架开发，业务的实现也更多的使用云上服务，如分布式中间件，函数服务，ai服务等，同时运维也转向云上的运维服务。

一个典型的现代云上应用架构：

经过域名解析阶段后，静态资源命中CDN后直接返回，无命中时会回源去拉取，动态请求直接访问WEB服务，在请求到达四层和七层ELB之前，多数企业应用也会选择WAF来清洗异常流量。

经过ELB后，请求到达业务应用服务器，业务实例多为分布式构架，微服务之间相互调用，一般情况下企业运维人员较多的关注点是应用实例这一层，多为企业自行开发的服务。

持久化层当前各CSP提供的中间件不一样，华为云上用户使用较多的如分布式缓存，分布式数据库等。由于提供动态扩容及较高级别的SLA，越来越多的企业不再需要专业的DBA，转而使用云上的服务，开发上也更加敏捷。

如此多的云服务和各种资源，任何一个环节出现问题，都将导致应用KPI异常，用户体验下降，进而导致企业运营受到影响，而每个使用公有云服务的企业，如果投入大量人力去自建运维系统并且将整个请求的各个环节关联起来，成本会非常高。因此华为云AOM在帮助企业对应用运维的过程中，通过实践构建了一套立体运维体系，帮助企业更好的进行一站式运维。下面章节将为您介绍立体运维的定位及架构。

二、立体运维的定位及架构

立体运维定位：

立体化运维主要是围绕用户应用进行监控，一站式完成用户体验监控，应用性能监控，基础设施监控。

参考以上典型云应用架构，通过将业务请求路径上经过的不同资源进行分层，围绕分层设计不同的专业运维服务子系统，将不同数据在不同子系统上串联协同、关联分析，构筑一个云上的运维平台，从而最大化的实现数据价值，为运维人员提供一个统一的运维中心，达到一站式立体化运维的目的。如下为立体运维分层：

                                              立体运维分层

构建立体运维，除了要覆盖应用的端到端资源以外，重点还要通过多种运维数据进行数据分析，通过多种可视化手段进行友好的界面展示。因此立体运维体系建设包括以下工作：

资源模型化

其实就是将应用依赖的资源接入CMDB，但是云上业务的CMDB与自建数据中心运维有所区别，后者多对应的是SRE（网站可靠性工程师）层面的CMDB，而应用运维管理所需要的CMDB是面向云资源的量身打造的CMDB。主要有以下特征

·          分离业务模型与存量资源模型（后续文章后详细解读）

·          存量模型能表述不同的云服务下的不同云资源

·          支持对云服务内云资源建立映射关系

·          支持对跨云服务的资源建立映射关系

·          支持云资源标签管理（打标签，同步标签，按标签查询）

·          支持历史资源快照

资源模型化这一步是所有数据关联及运维平台化的基础，通过统一的模型将不同资源关联起来后，可以帮助用户快速的找到故障的根因，也能通过关联关系对大量告警进行分析，抑制重复告警等。

数据可视化

良好的可视化界面不但能提高运维人员运维效率，还可以通过直观的展示查看各种资源消耗趋势，帮助企业分析运营走势，预测未来资源使用情况等。应用运维管理数据可视化遵从以下原则进行设计

·          建立左右逢源的资源拓扑图

资源拓扑是指一个资源与其他资源的关联关系，如云主机与ELB及VPC，CDN的关系，通过一个资源拓扑图进行展示。如下

所谓左右逢源是指以一个资源为中心，拓扑图展示其上下各一层的关联资源即可，避免拓扑过大，但又能通过一个资源找到上层或者下层资源。

·          关联资源下钻

建立拓扑后，通过图上的资源链接，可以跳转到选中的另一个资源的拓扑图中去，而新的拓扑图是以新的资源为中心，如此来达到通过关联资源不断下钻的目标，方便运维人员查找问题。

·          云资源快速跳转

一个云资源可能涉及到多个云服务，如ELB实例，涉及ELB服务本身，VPC，CDN，ECS，而各个云服务入口较分散，需要在资源名称增加超链接快速跳转到云服务console。

·          视图模板化

各资源监控数据的展示，由AOM默认提供模板，但同时要支持用户自定义模板，由于运维人员关注的指标或其他数据侧重点不一样，因此要能通过模板支持同一个资源不同视角的查看方式。

·          功能向导化

复杂功能需要通过向导快速指导用户进行设置或配置，以减少用户学习文档或者视频的时间成本。

服务平台化

平台化目标要支持用户通过各子系统通过开放api实现自动化运维。指标，日志，事件告警等数据要支持用户通过接口订阅，转发到外部系统供用户运维平台进行分析，分析结果通过API输入立体运维平台并通过事件驱动平台业务持续分析。

也就是通过数据流，实现平台与用户运维系统的协同，实现流程化自动化。

自动化将会协助用户实现故障自动恢复，如通过数据分析后发现需要扩容，可以通过事件触发或者API调用弹性伸缩子系统进行实例扩容。还可以在资源空闲时缩容以节省企业运营成本。

分析智能化

针对指标数据提供动态阈值计算能力，无需用户设置阈值，通过机器学习进行异常检测，对于大型系统的运维可以有效的降低人工配置成本。同时也避免静态阈值设置不合理需要不断调整的重复工作。

针对日志数据，智能提取模板，分析可变参数与静态文本，通过日志关键字监控，实时掌握应用异常情况。

应用运维管理的整体架构：

以下为应用运维管理整体的架构，主要分为五个子系统，每个子系统通过多个微服务提供不同功能，整体协同实现立体运维目标。

ALM模块负责事件告警的管理及相关性分析，支持用户配置通知策略以及时将告警发送给运维人员。

ALS模块负责分析日志。

INV模块即CMDB模块，实现资源的管理及资源的映射及查询等能力。

AMS模块主要负责指标数据的管理，提供阈值配置能力。

DPA模块主要负责大数据计算及智能化能力，在线和离线分析数据，以事件驱动各子系统运行。

更多信息可查看： https://www.huaweicloud.com/product/aom.html

另外架构图中的底座环境，展示了AOM运维范围，从基础设施到PaaS层应用及容器和VM应用，覆盖了应用运行所依赖各层资源。