智能、互联时代的应用运维——《应用智能运维实践（试读版）》

点击免费下载《应用智能运维实践 试读版 》https://developer.aliyun.com/topic/download?id 1193

在使用信息技术之前 企业的生产经营依赖人工操作、文本记录和口头沟通。发生在20世纪六七十年代的第一次信息技术浪潮推动了企业经营价值链条中的关键活动的自动化。企业应用系统软件实现了从订单处理、财务管理和工程设计到生产资源计划管理的计算机辅助自动化。这是信息技术第一次在企业生产经营活动中发挥巨大的作用 计算机将人工从海量数据采集、处理工作中解放出来 推动了生产力的提升。

在这个阶段 应用稳定性和性能保障等运维活动主要解决企业内部局域网内 面向生产、财务、销售等部门提供服务的软件和硬件系统的故障问题。应用特点是系统架构相对简单、接入用户数量固定、数据增长速度相对稳定。应用软件大多是标准化产品 有厂商提供运维支持 企业运维压力较小。

20世纪八九十年代 互联网的快速发展带动了第二次信息技术浪潮。通过廉价、便捷的接入方式 互联网打通了用户、供应商和企业之间的信息通信交互通道。企业内部信息系统不再只联通、服务于企业内部。企业与供应商、合作伙伴、经销商、最终用户之间的信息交互成了可能。企业支撑经营管理活动的数字信息系统建设不再是购买标准化产品就能够完成了。应用系统开发、运维对企业 尤其是互联网公司的重要性快速提升。应用运维不再只解决标准化产品故障问题 而且要解决复杂多变的网络环境和系统间网状信息交互集成带来的新的问题 这也带动了系统监控类软件的快速发展 其中比较有代表性的是Florian Forster编写的Collectd UNIX系统的软、硬件监控指标采集存储工具 [1]、UC Berkeley开发的Ganglia 用于分布式部署环境下的高性能计算平台的监控 [2]等。网络性能监控分析软件和应用性能管理软件也在这个阶段诞生了。

以智能、互联为主要特征的第三次信息技术浪潮将在提升生产力的同时 改变应用及其运维方式。物联网 Internet of Things IoT 已经开始改变产品或服务的设计、生产、营销、交付和售后支持过程。迈克尔·波特教授预言 第三次信息技术浪潮将“有潜力成为目前为止影响最深远的 相比前两次会激发更多的创新 获取更大幅度的生产收益增长和经济增长”。

企业规划建设面向未来的应用智能运维系统之前 首先要了解未来的应用系统和技术演进趋势。新需求、新技术激发的应用系统交互使用方式和开发运维方式的改变 首先体现在企业交付用户的产品形态上。互联网在已经建立的、面向人与人信息通信的网络的基础上 连接电器、汽车、家居、生产工具等产品 形成物联网。企业生产的产品将逐渐演进成为智能、互联产品。随之改变的人与产品之间的交互方式 以及随之生成的海量数据会推动企业运维方式演进。

如图3-1所示 智能、互联产品演进路线通常可以划分为四个阶段 在第一阶段 通过嵌入计算平台实现智能化控制能力 实现传统产品到智能产品 Smart Product 的升级 在第二阶段 通过植入联网能力 对接云平台服务和其他终端控制设备 产品演化为智能、互联产品 Smart Connected Product 进一步优化用户体验 提升产品能力 在第三阶段 接入了更多第三方信息系统服务 为产品的智能化决策提供了更多信息 进一步扩展了产品的能力边界 这个阶段的产品称为产品系统 Product System 在第四阶段 产品系统进一步与其他产品系统能力对接 成为更庞大的系统联邦 System of Systems 不同产品系统的能力相互融合、放大 产品价值得以提升。例如 农用机械生产商John Deere 和AGCO将拖拉机等农机联网信息化系统 不仅与智能终端设备对接 而且与灌溉、土壤检测施肥、天气预报、农作物价格管理、商品价格趋势预测等第三方产品系统和信息平台对接 以优化耕作流程 提高收益。在智能、互联产品升级之后 农机设备只是整个庞大系统的一部分。多系统通过协作 实现更大的价值。在这个场景下 应用运维不再只围绕独立应用系统解决一个点的问题 而是面向更大的场景 需要复杂的联邦系统协作 需要具备全景监控能力 也需要具备智能化态势感知和风险管理能力的智能应用运维系统的支撑。

图3-1? 智能、互联产品演进路线

总的来说 智能、互联产品包含的三个关键组成部分是物理模块 Physical Components 、智能模块 Smart Components 和连接模块 Connectivity Components 。物理模块指产品物理实体存在的部分 如汽车引擎、轮胎 空调压缩机、电源等。智能模块包括状态数据采集传感器、微处理器、数据存储器、控制系统和软件 对应智能网联汽车就是引擎控制系统、下雨感知自动车窗控制系统、车载娱乐系统和汽车辅助驾驶系统。连接模块包括天线、接口、通信协议和信道等 其中 通信方式通常包含三种 一对一通信 即单个产品与用户、厂商和其他产品通信 如汽车通过OBD OnBoard Diagnostics 接口与故障诊断系统连接 一对多通信 即集中控制系统实时或随需与多个产品连接 如新能源汽车与云端监控系统实时通信以上报电池状态数据 多对多通信 即多个产品之间或产品与多个独立系统之间进行通信 如车与车之间通信、车同时与路侧终端和云端服务通信等。

智能模块是对物理模块能力和价值的延伸。例如 空调、热水器系统通过采集的历史数据来分析判断什么时候需要将室温加热到适合的温度、什么时候需要准备好热水。连接模块通过连接云端能力和终端能力 将终端数据存储、计算任务负载卸载 Offload 到云端 通过云端随需即取的计算、存储能力来放大智能模块的价值。这样 终端就不需要集成昂贵、复杂的数据处理分析系统。通过物理模块、智能模块和连接模块的配合协同 产品价值将循环放大 这同时意味着系统复杂度的提升和运维方式的改变。智能、互联技术与行业应用场景结合 衍生出了新一代数字信息系统 见图3-2中的数字化医院应用、数字银行应用等 也为应用运维的智能化建设带来了特殊的复杂性问题。

图3-2? 典型的智能、互联应用

从产品本身的功能和能力看 智能、互联产品区别于传统产品的能力主要体现在四个层级 状态监视、控制、优化和自治 如图3-3所示。每个层级的能力都能在目标场景中体现闭环的价值 并为下一层级能力奠定基础 如状态监视是产品控制、优化和自治的基础。企业在策划升级产品时 不仅要考虑提升产品的用户价值和自身竞争力 同时要为每一层级技术升级带来的运维问题准备解决方案。

图3-3? 智能、互联产品的能力体系

1. 状态监视

监视智能、互联产品的运行状态 采集用户行为和外部环境变化等实时数据 是实现智能化管理、控制、优化、运营和运维的基础。不了解产品在用户目标场景中的使用情况和运行状态 就无法实现进一步的智能化改造。状态监视层级能够实现的能力 运行状态监控、运行环境监控、用户行为监控和异常状态检测。应用系统与终端交互的数据主要是状态变化监控数据和告警事件。可以体现的产品价值有故障告警、发现产品缺陷、挖掘用户场景中的新需求以改进产品设计等。例如 对于新能源汽车 目前国家要求其每10秒给云端车厂和国家平台上报一次监控数据 一旦出现电池状态异常或车辆缺陷导致的驾驶安全风险 云端平台可以及时发现和告警 车厂通过对指定型号的汽车历史数据进行分析 可以挖掘目标用户群的使用习惯和驾驶行为特点 从而优化新款车的设计 或者指导充电桩建设地点的规划。

2. 控制

有了状态监视数据 下一阶段建设的能力目标是对智能、互联产品进行控制。通过实现控制能力 产品不但可以更好地适应目标场景用户的使用习惯 获得之前无法实现的可定制性 而且能够进一步简化用户的操控 提升用户体验。控制层级能够实现的能力 产品功能控制、自定义产品用户体验。应用系统与终端交互的数据除了监控数据 还包括控制指令和指令执行之后的结果反馈。例如 汽车的电子车身稳定装置、加速防滑控制系统、防抱死制动系统、刹车辅助系统等可实现车机端控制 简化用户的操控 某些高端车提供的通过手机App控制锁车、开关车窗和空调等的控制能力提升了用户体验 智能家居厂商在灯泡中加入远程控制能力 使用户能够用手机控制设备开关 甚至按需调节明暗和色彩。

对产品的控制可以通过嵌入终端的代码实现 也可以通过部署在云端的集中控制服务实现。终端代码控制响应迅速 实时性、运行可靠性高 因为程序在终端计算机以独占方式运行 不受外部网络连接和远端服务器性能的影响。但是 其计算能力有限 逻辑固定适应性差。云端控制需要产品终端设备与云端保持网络连接 由云端转发控制指令。这种控制方式将终端控制程序运行卸载到云端 降低了终端的硬件成本 但网络时延导致其实时性差、运行可靠性低。采用哪种方式需要考虑具体的应用场景。例如 对于汽车自动辅助驾驶和自动泊车 用云端控制的话实时性不够 风险较大 而对于远程控制汽车空调 因为调节温度并不需要太高的实时性 没有占用终端计算能力实现的必要 所以 用云端转发手机指令到车端更合适。

3. 优化

状态监视和控制层级建设赋予了产品监视和控制的监控闭环能力 为建设更复杂的优化层级能力打下了基础。有了全面和丰富的监控数据 企业可以利用算法从数据中挖掘有用的信息 指导产品性能、稳定性、能效等的优化。优化层级能够实现的能力 产品功能优化、预防性维护、异常检测、故障修复、用户体验优化和使用习惯预测。对于实现了优化层级能力的智能、互联产品 数据交互包含更易于理解的优化目标和产品状态信息。我们只需要设置优化目标 调节相关参数 系统就能够自动生成优化方案 并向相关责任人反馈执行结果和状态信息。例如 在数据中心场景下 我们可以基于实时采集的基础设施温度、空气流动状态、负载、空调状态监控数据来设计数据中心能效优化系统 自动生成优化方案以控制空调的开启和关闭、调节制冷功率和冷风流向、优化数据中心PUE Power Utilization Effectiveness 指标 对于风力发电机 在实现了对获取电量效率监控和风叶角度控制的基础上 我们可以设计实现通过调整风叶角度来获取最大电能的优化系统。

4. 自治

自治层级的能力整合了状态监视、控制和优化层级的能力 通过智能化进一步解放人脑 从而形成无须人工干预即可应对某些场景特定任务的自治控制系统。自治系统无须人工运维干预。自治层级能够实现的能力 产品自治控制 集群智能协作 自动化配置变更 故障自诊断、自恢复 使用环境自适应和用户使用习惯学习。应用系统与终端的交互数据包含控制程序和执行反馈 如用于修改缺陷或升级自动控制策略的自动控制程序升级包、辅助诊断故障的执行日志等。在指定事件发生时 自治系统能够自动匹配解决方案以应对。例如 在云端部署面向全球提供服务的电商系统 其每天的访问热点地区会随时区变化而变化 当中国地区在白天访问量较大时 处于凌晨的美国地区的访问量就比较低 当美国地区白天的访问量增加时 中国地区的访问量则开始下降 这样就实现了自治控制的云应用 利用遍布全球的云数据中心自动控制热点跟随 当不同地区的访问量增加或降低时 启动或关闭对应地区本地数据中心的负载处理节点以提升用户体验。还有一个具备自治层级能力的智能、互联产品是扫地机器人。利用集成在终端的传感器和计算平台 扫地机器人能够自治地控制地面清洁操作 从而应对障碍物和地形变化。

具有自治能力的智能、互联系统能够应对部分已知故障或突发异常情况 并选择对应的处理策略 从而进一步降低人工参与运维工作的工作量。人工参与监控运维不再需要关注局部组件的具体指标 而只需要掌控全局运行状态和运行效果就行 只有在发生问题时才需要逐级排查问题根源 并调整处理策略。

产品智能、互联化的趋势不但影响着互联网公司和高科技公司的发展战略 而且影响着传统行业 如制造业、医疗、金融等。近几年 宝马、北汽、吉利等车厂信息化建设的速度加快 有些甚至组建了独立的公司和部门做数字化转型 自动驾驶、车与云端实时交互信息、从车端语音控制智能家电 这些已经不是概念了。A.O. Smith公司在热水器产品中植入了传感器 连接云端服务 采集用户的使用习惯数据 结合当地的水质、天气变化 实现了对水温的智能调节 优化了用户关怀服务。迅达电梯PORT科技 Schindler Elevator PORT Technology 公司通过预测电梯的需求模式 计算到达目的地的最快时间及分配合适的电梯 以使乘客快速移动 将等待电梯的时间减少了一半以上。在能源领域 ABB的智能电网技术使其公用事业公司能够分析广泛的发电、变换和配电设备 由ABB及其他公司制造 的大量实时数据 如变压器温度的变化 从而提醒公用事业控制中心可能出现的过载情况 使其进行调整以防止停电。

在智能、互联产品使用场景下 驱动业务的应用系统不再是单纯连接用户和服务的C/S Client/Server 用户端/服务器 架构或B/S Brower/Server 浏览器/服务器 架构。数字信息系统应用与用户交互的终端从单纯的计算机、手机扩展到手表、电视、音响、汽车、门锁、空调、洗衣机等各种与我们日常生产、生活相关的物体。应用服务端也经历了从单体架构、垂直架构、SOA架构、Lambda架构、Kappa架构、云原生架构到微服务架构的演进过程。应用运维的复杂度激增 性能和稳定性保障若只是单纯地采集服务节点状态、代码执行链路或网络运行状态 配置告警策略 已经不能满足实际生产场景的需要了。

3.2 ?技术演进趋势

从技术演进趋势看 虚拟化、云计算、容器、微服务等新技术正在逐渐将应用的业务逻辑与基础设施解耦。虚拟化技术将计算、存储、网络资源从物理硬件设备中剥离出来。云计算技术则将虚拟化资源形成资源池 并以自助的方式向租户交付随需即取的资源。容器技术将应用中间件从操作系统中解放出来。近些年逐渐兴起的微服务技术进一步将应用业务逻辑从中间件中剥离出来。应用本身运行对底层硬件环境的依赖逐渐减弱 映射关系的不确定性和动态性更加明显。这就导致应用运维与传统IT基础设施运维的目标大相径庭。由于更贴近用户和业务 应用运维的重要性和复杂度更高。

目前 金融、航空、汽车等行业都处在数字化转型的前沿 由于应用性能问题导致用户体验下降、企业用户流失和经济损失的案例在逐渐增加 而传统以应用性能管理工具和网络性能管理工具建设为主的应用运维系统的被动响应式风险处理机制已难以应对。实现主动预防的风险处理机制、建设智能化的应用性能管理平台已逐渐成为企业构建面向未来的运维体系的关键。

这些场景之所以能在今天成为现实 主要原因是 一系列新技术的发展和成熟 使得制约应用落地的障碍得以清除。其中 对数字信息系统应用的架构及开发、运维方式产生深远影响的技术如下。

1. 服务器虚拟化、云计算

近年来 首先掀起波澜的是服务器虚拟化、云计算技术的普及应用。创立于1998年的VMware公司推出的VMware Workstation服务器虚拟化软件将操作系统与硬件基础设施解耦 使得软件系统不再与硬件平台绑定。2006年 亚马逊以虚拟化技术为基础推出了首个云计算服务——AWS Elastic Compute Cloud EC2 将数据中心剩余的计算、存储、网络资源以在线服务的方式出售。应用系统部署安装不再依赖特定的硬件和数据中心 软件定义基础设施成为可能。

2. 大数据

数据量的快速增长使得大数据存储分析技术成为研究热点。2006年 基于Google File System论文[3]研发的Hadoop大数据存储分析平台成为行业焦点。有别于传统的结构化关系数据库 Hadoop半结构海量的大数据存储能力和基于MapReduce算法的信息提取能力 为应对智能、互联场景下激增的数据量提供了解决方案。

3. 容器

出现于2008年的Linux操作系统层虚拟化LXC Linux Containers 技术在服务器虚拟化基础之上 通过将操作系统资源隔离 进一步将应用中间件与操作系统解耦 使得应用动态部署、更新、迁移和弹性伸缩控制更加灵活。LXC对应的商业产品Docker的快速普及和应用已经证明了容器技术的商业价值。

4. 微服务

微服务 Microservices 技术进一步将业务逻辑和应用中间件解耦。2011年5月 在威尼斯附近举行的软件架构师研讨会上 “微服务”一词被与会者用来特指业界正在普遍探索和实践的一种通用软件架构设计风格。2012年 James Lewis在克拉科夫的一次题为Micro Services Java, the Unix Way的演讲中介绍了这些新想法。他描述了通过“分而治之”的方式使用康威定律 Conway’s law 来构建软件开发团队的一种更敏捷的软件开发方式 并把这种方式称为“微服务”。利用微服务架构和技术 应用业务模块被拆分成独立的微服务节点 以方便复杂系统的多团队协作开发、更新和测试 由于业务模块对应微服务节点的独立部署 其扩展性更高 每个微服务节点可以由不同语言、不同架构实现 支持对接遗留系统服务 业务需求变化导致的对应应用系统的架构重构不影响其他微服务节点。

如图3-4所示为某电子商务应用系统 在传统单体架构中 所有应用的业务代码部署在一个独立的服务节点上 运行在一台应用服务器上 代码耦合度高。一个独立服务对应的开发团队需要在同一个开发框架中使用一样的技术堆栈和开发语言。所有业务访问数据库 需要通过统一的数据访问层接入数据库。一旦需要升级功能、修改缺陷 所有代码需要重新编译发布。而微服务架构将电子商务系统中的服务配送、查询详单、接收订单、结账收款等业务功能解耦 使其成为可以独立开发部署的节点。各服务通过服务发现、注册方式进行管理 并通过接口交互。每个节点可以采用不同的架构、开发语言 可以有自己的数据库。这样 业务逻辑多样且多变、架构复杂的互联网和物联网应用系统 可以通过多团队协作开发来划清任务目标和功能边界 不再局限于一个统一的技术堆栈。虽然微服务架构优点很明显 但并不完美。在解决多团队协作问题的同时 微服务架构也加剧了系统的复杂程度 使系统的运行维护成本激增 数据量增加。

图3-4? 单体架构应用与微服务架构应用的结构对比

5. 人工智能

在计算机科学中 人工智能 也称为机器智能 是机器通过算法实现的智能。人工智能研究领域诞生于1956年达特茅斯学院的一个研讨会上 约翰·麦卡锡 John McCarthy 提出了“人工智能”一词[4] 以区分该领域与控制论 并摆脱了控制论专家诺伯特·维纳 Norbert Wiener 的影响。人工智能技术被认为是推动第三次信息技术浪潮的关键技术。近几年来 人工智能发展迅速 产业界和学术界对相关技术的研究、落地兴趣很浓。随着硬件平台计算能力的提升和算法的突破 人工智能的应用场景越来越多。例如 人脸识别应用于身份认证 图像识别应用于海量图片处理和搜索 异常检测和因果推理分析算法应用于海量机器数据的处理等。

3.3? 应用智能运维系统 企业数字战略的关键支撑

根据Forrest的统计数据 57%的企业用户IT运维部反馈 至少每周会发生一次影响应用性能和可用性的问题 每天都发生问题的比例占到了28%。对于愈加依赖应用来面向用户以实现企业价值、提高工作效率的当今企业来说 这种问题越来越无法忍受。统计数据显示 超过一半的企业认为应用性能问题直接导致业务用户和IT部门效率降低 42%的企业认为应用性能问题直接影响了企业收入。当前 企业应用运维团队的压力主要来自以下两个方面。

1 新需求推动应用数量激增。移动智能终端设备的普及使应用逐渐渗入我们工作、生活的方方面面 企业应用数量激增。企业面向用户、合作伙伴和内部员工建设的应用数量会随产品智能、互联化的深入持续增长。

2 产品数字化导致应用结构愈加复杂 保障应用性能更困难。在技术方面 如混合云、数据分析、物联网、车联网、体域网等新技术的持续演进使得应用结构愈加复杂 保障应用性能更加困难。据统计 超过一半 52% 企业的IT运维部门在监控管理工具上的投入是被动、针对特定问题且分散的。这种投入方式虽然可以有效地解决当前的问题 但由于管理功能单一、分散、碎片化 难以应对未来以应用为核心的新需求和技术演进。随着时间的推移 现有应用运维问题会恶化。因此 采用被动处理方式的应用智能运维系统已不能满足企业快速数字化转型的需要 主动分析定位潜在问题、预防应用性能风险已成为未来应用智能运维系统的发展趋势。

自动化过程是将人手从简单重复的劳动中解脱出来的过程 而智能化过程则通过将经验和思维逻辑固化为算法 将人脑解放出来。对于智能、互联时代的应用运维场景 人工处理的速度已经远远跟不上运维工作量增加的速度 用机器智能解决机器复杂性问题是目前可行的解决方案。

随着信息系统的快速演进 企业对应用运维系统的期望也在上升。Gartner于2018年12月发布的分析报告指出 企业对应用运维能力的需求核心正在从应用请求链路监控、用户数字体验保障向智能运维、业务流程监控、应用全景监控转移 如图3-5所示。

图3-5? 应用运维系统的演进路线

传统以APM平台提供的以应用代码监控分析能力为核心的应用性能监控运维体系 正向以用户数字体验保障为核心的方向演进。大数据、人工智能技术的发展使得监控系统有能力从海量数据中提取有用的信息 实现更符合应用运维需要的业务流程监控和全景监控。

3.4? 商业价值评估 ROI分析

建设能够满足智能、互联时代应用运维需求的智能运维系统 意味着要对原有运维体系的监控数据采集、数据存储、数据分析的工具 以及运维流程和人机交互界面进行全面升级。我们在决策是否值得投入建设时 需要先判断ROI Return On Investment 是否能达到预期。

比较可行的计算办法是在系统目标场景下挖掘相比于现有方式能够改善、升级的价值点 选择可量化的指标计算ROI。例如 常用的系统可靠性量化指标有故障平均修复时间 Mean Time To Repair MTTR 、平均无故障工作时间 Mean Time Between Failure MTBF 、平均失效前时间 Mean Time To Failure MTTF [5]和标准化的用户体验指标 Application Performance Index APDEX [6]。MTBF即平均失效间隔 就是从新的系统在规定的工作环境下开始工作到出现第一个故障的时间的平均值。MTBF越长 表示系统的可靠性越高 正确工作能力越强。MTTR就是从出现故障到恢复之间的这段时间。MTTR越短 表示系统的易恢复性越好。MTTF就是系统平均能够正常运行的时间。系统的可靠性越高 MTTF越长。APDEX是从用户的角度评估系统使用体验的标准化指标。它提供了测量和报告用户体验的标准化方法 将用户体验量化成范围为0 1的满意度评价数值 把最终用户体验和应用性能联系在一起。

以某快销企业为例 其现有面向终端用户的营销平台、冷链管理等生产管理系统、用户关系管理系统和ERP等百余个系统。其应用运维团队有40人 负责日常的应用性能、可用性保障。根据历史数据统计 每年导致应用服务中断的严重故障次数平均为22次。运维人员平均工作负荷为120% 主要是由收到异常告警、需要处理突发事件、加班排查故障导致的。每次出现严重故障的平均故障恢复时间为20小时左右。应用持续稳定运行的时间为219小时。

该企业规划升级现有运维体系 实现应用系统的集中监管 打造具备监控指标集中存储、风险主动探查和根源定位分析能力的应用智能运维系统。通过技术可行性评估 结合历史运维场景 对现有运维流程进行优化估计 量化的ROI数据如表3-1所示。其中 在每年22次历史故障中 通过引入可用性主动拨测机制和全景监控能力 可以提前发现规避的故障有10次 按每次故障损失12万元计算 每年收益达120万元。采用自动化拨测应用关键业务流程的可用性 以及故障信息自动关联辅助根源问题分析 使得人工巡检和分析监控数据的工作量减少了约1/4 应用团队规模可以缩减10人。按人均年成本20万元计算 年收益达200万元。

应用智能运维系统规划建设的主动探伤扫描功能可以每天自动分析应用的潜在风险 降低突发故障导致系统宕机的概率。运维人员加班处理突发问题的时间减少 工作负荷相应地可以降低到90% 节约成本约80万元。由于意外故障导致的宕机次数减少 MTTF可以从平均219小时提升到438小时 对应规避的运营损失 包括最终用户流失、代理经销商业务终止、故障恢复人力成本投入等 总计76万元。相比于现有系统 应用智能运维系统通过整合数据 深度分析和定位影响用户使用的性能瓶颈。应用性能的提升意味着用户体验的优化 APDEX可以从目前的0.75提升到0.92。对于运营部门来说 相关用户转化率有明显的提高 据运营部门估算 这对企业经营带来的可度量收益大概在90万元左右。经过整体评估 企业建设应用智能运维系统每年带来的可量化ROI为736万元。

表3-1? 应用智能运维系统建设ROI评估

指标

运维现状

期望效果

收益/ 万元/年

每年应用严重故障次数

每年22次严重故障

每年12次严重故障

120

应用运维团队人员数量

40人

30人

200

应用运维人员平均工作负荷

120%

90%

80

MTTR

20小时

6小时

170

MTTF

219小时

438小时

76

APDEX

0.75

0.92

90

年收益总计

736

有了数据支撑 我们就可以进一步明确建设目标和愿景 并对规划建设的特性优先级和建设成本有相对准确的估计。ROI估算只是第一步 接下来需要梳理目标场景 深入理解系统在实际场景中可以发挥的价值。对场景和实际需求的理解很大程度上决定了系统能否够达到期望效果。总的来说 应用智能运维系统的场景化价值主要有以下几点。

1. 实时感知风险态势 减少应用宕机损失

监控的目的是发现风险 在智能、互联时代 发现风险需要强大的监控系统的支持 著名的监控系统——宙斯盾和彭博终端的核心价值都是在复杂态势中找到风险点。应用运维也类似 在系统复杂度快速增加、接入用户终端设备多样化、系统间交互集成关系更紧密的背景下 应用智能运维系统的全景监控和智能化态势感知能力对企业更加必要 价值也更大。实现风险态势感知的前提是有全面、实时、丰富的监控数据。

信息化建设发展到今天 大、中型规模的企业几乎都会建设IT系统的监控系统来监控应用和应用运行环境状态。常用的监控系统基本上都是针对一个点进行数据采集和风险告警的。例如 网络性能监控工具nTop[7]能够对网络中的网络包进行拆包分析 监控当前网络上信息交互应用的流量异常 开源网络及应用监控工具ZABBIX[8]常用来对IT基础设施和中间件进行监控 应用性能管理工具Pinpoint[9]擅长监控应用请求执行代码链路和追踪分布式事务执行过程异常 Logstash[10]、ElasticSearch[11]是用来对应用日志进行存储分析的常用工具。这些系统的数据采集、存储和风险告警相对独立。一个完整的智能、互联应用系统的部署架构和数据交互复杂 往往需要多种工具联合使用。对于运维人员来说 这些就像一个个数据孤岛 一旦发生异常 多套系统都有可能产生告警 形成告警风暴。要排查和定位问题根源 需要人工登录多个门户查询历史数据 因此系统易用性差 运维工作效率低。

应用智能运维系统首先能解决运维孤岛问题。如图3-6所示 通过搭建由不同类型的存储平台组成的运维大数据湖 将ZABBIX、nTop等的监控数据同步采集到一个集中的存储平台来做数据同构转换、清洗、聚合、统计等分析处理 为状态监控、异常检测、根源问题定位等应用场景提供一致的数据存储。一旦发生异常告警 风险点对应用整体运行态势产生影响 受影响的终端用户和业务流程能很快被定位出来。这样 人工介入处理数据、发现和定位风险的工作量减少 MTTR会有一定幅度的减少。

图3-6? 运维大数据湖打通运维数据孤岛

2. 提供专家经验指导 提高应用运维效率

智能化的关键支撑是经验和知识的积累 应用智能运维系统建设区别于其他监控运维系统的关键一点是 在发生异常或出现潜在问题的情况下 其能够通过算法和积累的专家经验来指导风险的发现、定位和处理 辅助决策支持。传统监控运维系统积累专家经验主要依靠告警策略、监控运维仪表盘和报表。告警策略针对时间序列指标数据配置自动探测异常的逻辑 出现问题自动生成告警 监控运维仪表盘和报表通过预定义模板的方式对指定类型的资源、监控场景或故障最常用的指标进行统计分析 并生成对应的可视化界面。开源监控数据可视化平台Grafana[12]专注运维数据可视化 提供了大量根据经验定义的可视化仪表盘模板。利用类SQL查询语句 Grafana将常用指标聚合、统计和展现策略固化为可下载的模板 并通过开源社区的方式让全球用户接入下载或分享自己的仪表盘。

除此之外 知识图谱与运维场景的结合也是解决运维专家经验积累和使用的可行途径。知识图谱 Knowledge Graph [13]是实现人工智能落地的重要基础 它以结构化的形式描述客观世界中的概念、实体及其关系 将互联网的信息表达成更接近人类认知世界的形式 提供了一种更好地组织、管理和理解互联网海量信息的能力。知识图谱不是一种新的知识表示方法 而是知识表示在工业界的大规模知识应用 它将互联网上可以识别的客观对象进行关联 从而形成客观世界实体和实体关系的知识库 其本质上是一种语义网络。如图3-7所示 其中的节点代表实体 Entity 或概念 Concept 边代表实体/概念之间的各种语义关系 如用户 User 拥有某站点 Site 的管理员权限 在用户和站点两个实体之间 会有一条线标识拥有管理权限 has administrator 。

有了积累的专家知识和经验 我们就能够在发生异常且缺少专家指导的情况下 利用应用智能运维系统自动检索和匹配知识库信息 解决疑难问题 为企业降低人工成本。

3. 主动找出故障原因 提前预防和规避风险

有了积累的专家知识和经验 应用智能运维系统能够帮助我们利用这些知识和经验管理风险。具体场景 ①在未发生风险时 通过设定先验条件来推理和判断系统是否可能出现性能瓶颈或故障 若可能 分析问题所在 ②在已经发生了风险告警时 回溯数据到故障点 结合知识和经验推理及分析原因。

第一种场景重点是预防和规避风险 在故障出现之前就能解决问题 对企业的价值更大。例如 电商平台在既定时间进行线上营销活动 从历史数据可以预估确定时间点在线用户数量的大概范围。在线用户数估计值就是先验知识 利用从历史数据中学习得到的知识和经验模型推理分析就可以预判在此负载条件下 哪些指标会出现异常。从指标可以梳理出可能发生的性能瓶颈、潜在故障等 从而指导扩容或配置变更 以便减少应用宕机风险。图3-8为面向汽车故障诊断的概率图模型 Probabilistic Graphical Models 因果推理网络示意。其将每种影响稳定运行的状态指标的取值离散化 然后通过输入先验知识来推理其他指标的后验概率分布 从而判断最可能出故障的点。

图3-7? 知识图谱语义网络模型示意 局部

图3-8? 概率图模型因果推理网络示意

第二种场景是在故障发生时 利用提前学习生成的指定故障因果关系概率图模型 从高维海量监控数据中查找相关信息 辅助定位根源问题 从而缩短MTTR。例如 利用知识库推理分析算法排查应用运行环境指标间的因果影响关系 定位出HTTP错误事件和Java内存使用率指标异常之间的相关性较强 从而可得出Java内存溢出导致应用宕机 进而导致用户HTTP请求错误。

4. 辅助容量规划决策 节约资源采购成本

大多数企业在新应用上线或扩容规划时 对需要准备多少计算、存储、网络资源 资源在应用系统中每个独立部署的节点之间如何分配 都缺少经验和有效的历史数据支撑。建设应用智能运维系统后 企业就可以通过算法分析全量采集的应用历史数据 从而进行决策。

区别于直接采集、分析应用性能管理监控数据和应用运行依赖的基础设施环境监控数据做容量规划分析 应用智能运维系统需要首先将业务流程请求处理链路、应用节点运行状态指标和对应的运行环境状态指标关联 从历史数据中筛选指标波动相关性。有了这些信息 我们能分析出各业务流程的历史峰值 以及在峰值发生时其对哪些服务节点和对应的运行环境状态指标有相关性影响。例如 计算密集型业务的并发量增加 对应节点的CPU利用率会显著升高 因此 我们需要判断对应节点的CPU利用率增加是否会使业务执行时间超时 以及使请求的数量超过服务质量目标的约束。如果通过算法计算发现有指标波动相关性 那么就意味着需要扩充服务节点的计算能力。

图3-9是应用容量规划决策支持样例。我们利用算法预测未来负载的变化趋势 通过历史数据推理分析什么时间段会导致哪种资源利用率增高。计算维度包含了CPU使用率、Java内存使用率、交换空间使用率等常用相关资源的使用率。一旦发现未来某时刻可能负载会增加 则对应的某些资源使用率会不会超标 以及需要额外增加多少资源就都一目了然。

图3-9? 应用容量规划决策支持样例

5. 掌控全局业务状态 赋能业务数字化运营

应用智能运维系统通过整合多种运维产品监控数据 利用人工智能算法代替人工来挖掘数据中的信息。这种能力使得企业能够在未来智能、互联时代建设业务逻辑更加复杂的数字信息系统 支撑产品和服务能力升级。全景监控能力对企业的价值主要体现在用户数字体验保障和复杂应用系统的整体健康状态保障两方面。

如图3-10所示 对于运营场景 为了保障用户数字体验 运营人员关注用户侧使用情况和对应的应用侧业务流程的健康状态 对应用本身的服务节点状态和运行环境基础设施运行情况不太关注。因此 全景监控视图需要实时监控关键业务流程的运行状态 一旦出现问题 能够反映其对用户关注的业务的影响。

图3-10? 智能、互联应用全景监控视图样例

在运维对复杂应用系统的整体健康状态保障的场景下 监控重点也要从具体技术组件和运行环境向业务流程转移。微服务化、容器化使得应用本身的部署架构和数据交互关系更加复杂。逐个排查具体节点的运行状态 工作量会非常大。因此 运维思路需要从局部到整体 以业务流程为根节点逐级关联子业务流程和相关服务节点 如图3-11所示。一旦出现故障 运维可以快速评估影响范围 定位根源问题。

图3-11 业务流程与系统技术架构的关联关系

?

?案例 LinkedIn 应用智能运维建设方案

成立于2003年的LinkedIn自始至终以“为更好的工作机会连接用户人脉网络 to your network for better job opportunities ”为经营宗旨。公司信息系统复杂度随业务增长快速增加。截至2015年年底 LinkedIn拥有超过3.5亿用户 系统每秒处理的请求数量过万 触发后端系统查询量达百万级别。

公司工程部主管Prachi Gupta 在2011年一份内部报告中强调了监控系统的重要性 “在LinkedIn 我们一直在强调我们系统网站应用可用性保障的重要性 要保障我们的会员在任何时候都能够使用我们网站上的所有功能。为达到这个目标 我们要能够在问题发生时就探测到故障或性能瓶颈 并及时做出响应。因此我们使用具备时间序列数据展现能力的监控系统来实现分钟级的故障检测和响应。这些监控工具和技术已经被证明是必需的。它们为系统运维工程师检测、探伤、解决问题争取了宝贵的时间。”

2010年 LinkedIn建设了大量监控系统来覆盖应用运行期的方方面面 采集了大量监控指标数据 如图3-12所示。但是 开发工程师、运维工程师如何获取这些数据成了难题 更谈不上分析数据、获取信息了。因此 LinkedIn启动了Eric Wong提出的夏季内部项目 这也促成了InGraphs系统的研发和投产。

Wong写道 “仅仅是获取某些特殊服务的宿主机CPU使用率这种基本指标 都要填写工单 由某些人花费大约半小时时间来整理一份报告”。当时 LinkedIn正在用Zenoss 一款以应用基础设施为核心的监控软件 采集指标数据。Wong解释说 “从Zenoss中获取数据需要逐级浏览响应缓慢的Web页面 所以我写了一些Python脚本来加速这个过程 虽然还得花时间手动配置所要采集的指标 但从Zenoss中抓取数据的过程已经大大简化了”。

图3-12? LinkedIn采集的监控时间序列指标

在持续了一个夏天的研发之后 Wong又陆续研发完善了InGraphs的功能 使得开发工程师、运维工程师可以从中获得需要的监控指标数据 并实现了跨多个时间序列指标数据集计算 每周变化趋势统计 历史数据环比、同比计算和监控指标自定义仪表盘自助选择等实用的功能 如图3-13、图3-14所示。

图3-13 ?InGraphs系统监控效果

图3-14 ?InGraphs多指标历史数据对比

关于研发、完善InGraphs功能和它本身的价值 Gupta表示 “在一个关键的Web-mail服务开始有趋势显现故障时 InGraphs系统及时发现了 并在该应用维护团队意识到问题之前通知了相关责任人 这使得InGraphs监控系统的价值被公司认可”。

从一个初级项目孵化出来的InGraphs系统 目前已经成了LinkedIn运维体系中的关键组成 以至于InGraphs的时间序列数据监控图表遍布公司工程部门 成了最引人注目的部分。

3.5 ?系统关键能力

如果企业无法抵消信息系统趋于复杂化带来的运维风险 数字化营销、数字化生产、数字化管理等战略就是空谈。建设具备全景监控、智能运维能力的应用性能管理系统 保障用户数字体验 提升应用可用性 已成为企业必然的选择。

随着信息系统的快速演进 政府、企业对数字信息系统应用的依赖持续上升 对相应的应用性能、稳定性保障系统建设的关注同步升温。而传统以应用指标采集为主的APM系统已经难以满足云化、容器化、微服务化的复杂应用系统的监控运维需求。某知名IT咨询公司发布的最新分析报告指出 企业对APM 能力的需求核心正在从应用请求链路监控、用户数字体验保障向智能运维、业务流程监控、应用全景监控转移。在此市场背景下 要保障政府、企业未来日趋复杂、多样、高负荷的数字信息系统建设 需要新一代以应用为核心的智能化全景运维平台的支撑。要打造用户体验优先的应用智能运维系统 其需要具备的核心能力如下。

1. 全景视图监控 实时掌控用户数字体验

应用智能运维系统能够自动探测和发现应用从用户端到服务端的端到端全栈拓扑结构、用户操作业务流程和代码执行链路 实时感知潜在风险并通知相关责任人 以全景化的应用监控视图展现用户请求触发的应用行为 监控范围涵盖从用户端到服务端的各环节。一旦出现风险 运维人员可以及时从全景监控视图观察到风险点 并能够下钻到原子指标或代码链路、日志等白盒监控数据 将其发送给开发人员解决处理 如图3-15所示。

2. 运维大数据可视化 自助定义监控视图

应用智能运维系统能够支持自助、实时提取监控数据 定义可视化监控仪表盘视图 设置仪表盘间的跳转关系。监控视图可让海量运维数据更易理解 风险监控更及时、更直观。图3-16所示为可视化运维监控大数据仪表盘样例 只有通过全可视化界面实现信息的高效人机交互 才能满足未来应用运维的需要。

图3-15 从用户端到服务端的应用监控全景

图3-16 可视化运维监控大数据仪表盘样例

3. 应用全栈集中监管 全方位掌控应用的运行状态

应用智能运维系统能够提供对应用360度全方位、全栈的监管能力 不但能够对应用进行请求、事务、线程及代码级的深入分析 而且支持对应用依赖的应用服务器、数据库、虚拟化环境、云环境及主机、网络、存储等基础设施进行监管 帮助用户了解并掌控应用的性能、健康状态、风险及用户体验。

4. 聚合监控指标数据 简化日常应用性能管理工作

为简化对海量监控指标的监管工作 应用智能运维系统以聚合指标指示关键应用性能指标。通过指标聚合 应用智能运维系统将海量应用性能指标转换为容易理解、管理的应用健康状态、用户体验指标等指标 并通过仪表盘实时更新。这些指标反映了应用运行的全局状态 避免了人工筛查指标数据 定义了大量、复杂的告警策略 从而提高了管理效率。

5. 管理用户体验 追踪用户实时、历史在线状态

保障良好的用户体验是应用性能管理的最终目标。应用智能运维系统支持实时监控APDEX 帮助用户掌控应用的用户体验变化情况。为实现更高效的敏捷管理 应用智能运维系统以用户体验保障为核心 提供能够追踪用户实时和历史在线状态、请求响应时间、请求异常状态等关键指标的驾驶舱式集中监管仪表盘。

6. 辅助性能优化 智能分析运行缓慢的业务流程

应用系统支撑企业运营的各环节 每个业务流程都对应众多的服务及功能调用 一旦某业务运行缓慢 会直接导致企业运转效率下降 甚至停滞。因此 在出现问题时 定位瓶颈所在并解决问题的及时性直接关系企业的营收指标。应用智能运维系统能够通过分析海量运维数据 查找指定时间段内运行缓慢的业务请求及对应的应用执行线程 快速定位应用性能瓶颈所在 从而提高解决业务响应缓慢问题的工作效率。

7. 应用白盒监控 深度分析应用性能风险的根源问题

在应用系统性能异常时 应用智能运维系统能够通过自上而下、逐层钻取应用堆栈的方式分析根源问题 生成指定时间段内的详细性能分析结果视图 见图3-17 。分析结果视图涵盖应用行为、性能指标、异常日志、内存用量分析等几乎所有应用运行期的关键运维数据 这些数据可以帮助用户快速排查、分析应用性能异常的原因。

8. 变被动处理为主动防御 提前规避应用性能风险

要从根本上扭转当前企业面临的应用性能管理被动 甚至有时近乎失控的局面 首先需要变被动解决风险告警为主动解决潜在问题及风险。有别于其他APM产品 应用智能运维系统致力于打造主动防御型应用性能管理体系 使企业能够提前发现风险 防患未然。基于概率图模型构建的指标间因果影响关系及推理分析模型 可使应用智能运维系统分析和处理海量数据 并通过自主研发的运维数据深度学习技术 从应用性能历史数据中分析最小粒度的指标 计算运维数据间的复杂概率分布 然后基于数据自动生成关联关系、影响程度等信息 从而生成可进行预测分析的数学模型。利用此模型 应用智能运维系统能够在给定时间范围或预期负载条件下发现潜在问题及风险 提升用户体验 减少由应用稳定性、性能问题带来的经济损失。

9. 预测应用性能变化趋势 优化应用资源配置

通过分析运维数据 生成对应用性能、负载及容量未来变化趋势进行预测的预测分析模型 应用智能运维系统能够帮助企业提前发现应用资源配置存在的问题 定位如CPU、物理内存、Java内存、物理磁盘、网络等资源存在的资源超配或资源配置不足问题 如图3-18所示。除此以外 应用智能运维系统能够借助预测分析模型计算提升或降低某种资源配置对关键应用性能指标 如请求响应时间、APDEX等 的影响程度 从而帮助运维人员找到最优的资源配置方案 在保障应用性能的同时提高资源使用率 节约成本。

图3-17 应用性能分析结果视图

企业在规划、构建面向智能、互联时代的应用智能运维系统的过程中 需要摒弃传统以网络、资源、设备为核心的被动运维理念 实现以应用为核心的主动式、智能运维管理平台 实现对应用性能的全方位监控和预测分析。在此过程中 应用智能运维系统能够帮助应用运维人员应对未来的复杂应用系统运维挑战 构建更加简单、高效的智能运维平台 以适应未来数字化驱动的新型互联网企业发展的需要。

图3-18 应用资源使用量容量规划截图

本章小结

应用是驱动企业对接“互联网 ”、“工业互联网”和“工业4.0”等国家战略的引擎 是否能有效解决应用性能管理问题关系成败。智能、互联场景下的应用智能运维系统以简单、智能、全可视化的理念重构了企业应用运维流程 相信其在提升企业用户数字体验、大幅度降低运维成本的同时 能为企业带来前所未有的数字化运维新体验。

?

本文转自网络，原文链接：https://developer.aliyun.com/article/785108
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！