3.4 商业价值评估（ROI分析）
建设能够满足智能、互联时代应用运维需求的智能运维系统，意味着要对原有运维体系的监控数据采集、数据存储、数据分析的工具，以及运维流程和人机交互界面进行全面升级。我们在决策是否值得投入建设时，需要先判断ROI（Return On Investment）是否能达到预期。
比较可行的计算办法是在系统目标场景下挖掘相比于现有方式能够改善、升级的价值点，选择可量化的指标计算ROI。例如，常用的系统可靠性量化指标有故障平均修复时间（Mean Time To Repair，MTTR）、平均无故障工作时间（Mean Time Between Failure，MTBF）、平均失效前时间（Mean Time To Failure，MTTF）[1]和标准化的用户体验指标（Application Performance Index，APDEX）[2]。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评估
有了数据支撑，我们就可以进一步明确建设目标和愿景，并对规划建设的特性优先级和建设成本有相对准确的估计。ROI估算只是第一步，接下来需要梳理目标场景，深入理解系统在实际场景中可以发挥的价值。对场景和实际需求的理解很大程度上决定了系统能否够达到期望效果。总的来说，应用智能运维系统的场景化价值主要有以下几点。
1. 实时感知风险态势，减少应用宕机损失
监控的目的是发现风险，在智能、互联时代，发现风险需要强大的监控系统的支持，著名的监控系统——宙斯盾和彭博终端的核心价值都是在复杂态势中找到风险点。应用运维也类似，在系统复杂度快速增加、接入用户终端设备多样化、系统间交互集成关系更紧密的背景下，应用智能运维系统的全景监控和智能化态势感知能力对企业更加必要，价值也更大。实现风险态势感知的前提是有全面、实时、丰富的监控数据。
信息化建设发展到今天，大、中型规模的企业几乎都会建设IT系统的监控系统来监控应用和应用运行环境状态。常用的监控系统基本上都是针对一个点进行数据采集和风险告警的。例如，网络性能监控工具nTop[3]能够对网络中的网络包进行拆包分析，监控当前网络上信息交互应用的流量异常；开源网络及应用监控工具ZABBIX[4]常用来对IT基础设施和中间件进行监控；应用性能管理工具Pinpoint[5]擅长监控应用请求执行代码链路和追踪分布式事务执行过程异常；Logstash[6]、ElasticSearch[7]是用来对应用日志进行存储分析的常用工具。这些系统的数据采集、存储和风险告警相对独立。一个完整的智能、互联应用系统的部署架构和数据交互复杂，往往需要多种工具联合使用。对于运维人员来说，这些就像一个个数据孤岛，一旦发生异常，多套系统都有可能产生告警，形成告警风暴。要排查和定位问题根源，需要人工登录多个门户查询历史数据，因此系统易用性差，运维工作效率低。
应用智能运维系统首先能解决运维孤岛问题。如图3-6所示，通过搭建由不同类型的存储平台组成的运维大数据湖，将ZABBIX、nTop等的监控数据同步采集到一个集中的存储平台来做数据同构转换、清洗、聚合、统计等分析处理，为状态监控、异常检测、根源问题定位等应用场景提供一致的数据存储。一旦发生异常告警，风险点对应用整体运行态势产生影响，受影响的终端用户和业务流程能很快被定位出来。这样，人工介入处理数据、发现和定位风险的工作量减少，MTTR会有一定幅度的减少。
图3-6 运维大数据湖打通运维数据孤岛
2. 提供专家经验指导，提高应用运维效率
智能化的关键支撑是经验和知识的积累，应用智能运维系统建设区别于其他监控运维系统的关键一点是，在发生异常或出现潜在问题的情况下，其能够通过算法和积累的专家经验来指导风险的发现、定位和处理，辅助决策支持。传统监控运维系统积累专家经验主要依靠告警策略、监控运维仪表盘和报表。告警策略针对时间序列指标数据配置自动探测异常的逻辑，出现问题自动生成告警；监控运维仪表盘和报表通过预定义模板的方式对指定类型的资源、监控场景或故障最常用的指标进行统计分析，并生成对应的可视化界面。开源监控数据可视化平台Grafana[8]专注运维数据可视化，提供了大量根据经验定义的可视化仪表盘模板。利用类SQL查询语句，Grafana将常用指标聚合、统计和展现策略固化为可下载的模板，并通过开源社区的方式让全球用户接入下载或分享自己的仪表盘。
除此之外，知识图谱与运维场景的结合也是解决运维专家经验积累和使用的可行途径。知识图谱（Knowledge Graph）[9]是实现人工智能落地的重要基础，它以结构化的形式描述客观世界中的概念、实体及其关系，将互联网的信息表达成更接近人类认知世界的形式，提供了一种更好地组织、管理和理解互联网海量信息的能力。知识图谱不是一种新的知识表示方法，而是知识表示在工业界的大规模知识应用，它将互联网上可以识别的客观对象进行关联，从而形成客观世界实体和实体关系的知识库，其本质上是一种语义网络。如图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的时间序列数据监控图表遍布公司工程部门，成了最引人注目的部分。
[1]https://wiki.mbalib.com/wiki/MTTR.
[2]https://docs.newrelic.com/docs/apm/new-relic-apm/apdex/apdex-measure-user-satisfaction.
[3]https://www.ntop.org/.
[4]https://www.ZABBIX.com/.
[5]http://naver.github.io/pinpoint/.
[6]https://www.elastic.co/cn/logstash.
[7]https://www.elastic.co/cn/elastic-stack.
[8]https://grafana.com.
[9]https://google.fandom.com/wiki/Knowledge_Graph.