2@2x-100.jpg

在企业数字化转型的浪潮中，核心业务的上云和迁云无疑是转型过程的重中之重，企业对于数字安全性及等保合规层面的需求也日益强烈，混合云成为诸多大型政府企业客户上云迁云的首选方案。随着企业云上业务的复杂化，云上云下技术栈的多样化，以及云上运维组织规模的扩大化，云上业务的稳定性和连续性面临着巨大的挑战。为了保障混合云场景下客户云上业务的稳定性，阿里云混合云应用监控平台团队旗下的 Sunfire 全景智能化监控平台（以下简称 Sunfire 平台）产品，不断转型升级、推陈出新，走出了一条跌宕起伏的道路。在这条道路上，我们究竟经历了哪些挑战和困难，我们又如何思考和应对？在历经挑战之后，我们又取得了哪些产品技术成果和客户价值？要回答这些问题，我们要先从监控本身谈起。

乱花渐欲迷人眼：我们需要什么样的监控

监控是什么？如果你是一个互联网技术人员，提到监控，你的脑海里也许马上会闪过许多优秀的开源监控工具，从 Nagios，Cacti 到 Zabbix，以及大名鼎鼎的 Prometheus。但监控究竟是什么？怎样的监控才是好的监控？我们或许需要认真思考一番。

01.jpg

散落在边塞沙漠戈壁高地上的烽火台，是我们的祖先为了掌握隐藏在塞外的敌人的行踪而建设的监控体系。从历史回到现实的互联网技术监控领域，从本质上看，监控是对于现实世界实体或对象的测量和检测，测量的结果通过监控数据的方式（可视化地）传递和展示出来，而检测的结果则会以报警（或消息）的形式通告监控的关注者。监控工作作为运维工作的重要组成部分，需要同时关注质量、成本、效率，以期在实践中起到符合预期的效果。伴随这三大挑战的磨砺业界的各种监控系统不断演进，各有千秋。针对混合云客户侧复杂异构的运维环境，从 2015 年开始，Sunfire 平台就在集团 100 多个事业部横跨电商、金融、物流、文娱、云计算等多各业态下的日常监控和双 11 大促的磨练之下不断前行，持续完善和刷新着我们对监控业务和技术的理解。从 2019 年开始，Sunfire 平台开始了商业化的进程，面向混合云客户提供业务、应用、平台全景智能化能力，也积累了诸多客户侧的成功案例。在多种多样的监控工具中，客户之所以选择 Sunfire 平台，一方向是因为 Sunfire 平台具备针对全景监控对象进行指标、链路、日志全栈的监控能力，一方面也是因为 Sunfire 平台突出体现了“通过业务监控能力来发现故障，通过全景监控能力定界故障，通过事件处理能力来辅助恢复故障”的产品思路。而这种理念，特别是以业务监控为故障发现入口的理念，是来源于历年来 Sunfire 平台支持阿里巴巴集团监控的产品技术积累当中，并在每年的双 11 大促和日常监控运营中不断经受洗礼和检验。

淘尽黄沙始见金：Sunfire 平台支持阿里巴巴集团的监控实践

02.jpg

在每年双 11 零点来临之前的夜晚，上万阿里工程师聚集在阿里巴巴的各个园区。而阿里巴巴总部杭州西溪园区的核心作战室里，更是聚集着负责阿里核心技术链路的上百位工程师。他们屏息凝神，注视着核心作战大屏和自己个人电脑上的监控大盘。作战大屏上，双 11 核心的实时交易数字正在秒级刷新，像不断跳动的脉搏一样，展示着阿里巴巴经济体的体量、规模和活力。在作战大屏和大家电脑大盘背后的就是 Sunfire 平台，再过若干分钟，Sunfire 平台会和阿里经济体的核心交易链路一起，经受数百倍于日常的流量冲击。从双 11 基于监控的全局技术指挥延展到日常的故障应急，为了应对海量业务流量、数万技术人员给技术风险带来的挑战，Sunfire 平台在监控体系和监控技术架构设计上，走出了一条和业界不同的道路。

从业务监控出发：双 11 战火洗礼下的监控道路选择

作为一个互联网行业的技术人员，提到监控，我们往往会想起各种针对系统资源和水位的监控，以及对于应用程序性能的监控等，而在 Sunfire 平台中，上面这些内容却并非平台功能的主角。Sunfire 平台是一个以业务监控为主、以应用和资源监控为辅的监控平台。这种监控思路和实践和业界通用做法大相径庭。Sunfire 平台之所以走出一条和业界不同的道路，追本溯源，也许还是和阿里特有的双 11 技术场景和阿里集团技术风险的机制息息相关。

在探讨监控的思路之前，我们首先需要回顾另外一项阿里技术体系给互联网技术界所做出的创新和贡献：全链路压测。在双 11 的最初几年，阿里核心交易链路面临着巨大流量带来的未知风险。通过微观层面的针对每一个应用、中间件、数据库模块的自检和盘点已经无法完整地保障复杂系统的稳定性，因为在超大流量的冲击之下，究竟哪一个系统会先‘顶不住’已经无法预先通过微观层面的技术分析来识别。因此，阿里技术人创造出了全链路压测体系，通过构造超大规模的流量来对系统进行全局压测，再根据业务指标的影响来决定压测的效果。在业务量和成功率达到极限之后，再通过系统监控发现各个组件的问题。这个通过业务指标判断系统整体极限和瓶颈的方案，需要对业务指标有一套高效的监控机制。同时，这种从宏观业务出发而不是从微观系统应用出发的风险暴露机制，也给监控领域以启示：首先通过关注业务发现问题，再通过关注应用和系统以定界和恢复问题，成为阿里监控体系的基本思想。

03.jpg

在双 11 之外的日常工作中，阿里巴巴集团有一套非常体系化的故障发现、应急、处理机制，而这一机制的总体入口和起点也是业务监控。重视业务，进而重视业务监控，和阿里集团最初的电商属性和重视业务运营的文化相关，我们一直希望通过技术保障让故障带给消费者和商家的伤害尽可能减少。在技术人员和资源有限的情况下，需要首先关注影响业务的技术问题，业务影响面越大的技术问题应该被给予更多的关注和资源投入去解决。

因此，Sunfire 平台坚定地走向了以业务监控为主，以应用、系统监控为辅的监控道路，并在过去持续支持了不断扩大的监控体量和规模，也经受住了历年双 11 流量洪峰和全局应急指挥的双重考验。当然，因为选择了这条监控道路，Sunfire 平台在技术侧也探索和成长出了和业界（特别是开源界）的监控系统不一样的技术架构。

海量监控指标实时计算场景下的监控架构演进

监控系统的功能版块往往可以拆解为数据采集、指标计算、指标存储、报警、数据展示（包括 API）等几大部分，每个部分都有相应的模块提供支撑。在开源世界里，监控系统的目标更多的是针对系统、应用的状态进行监控报警。为了适配不同的监控对象，监控系统往往需要在数据采集层面具备较好的开放性和可集成能力，以适应不同的监控对象数据采集的需求。监控系统一般会通过探针或客户端（Agent）的方式对众多监控对象进行分布式的数据的采集，而报警和展示往往需要将分布于各个监控对象上的指标进行一定程度的汇聚和计算才能进行。针对系统、应用监控，监控系统指标汇聚和计算层面的需求往往相对简单，更多是根据 CMDB 按应用实例或分组、集群等维度对数据进行空间聚合，并按监控时效性进行时间汇聚。而针对业务指标监控，在汇聚和计算层面的需求就变得比较复杂。业务指标的计算更多地依赖服务端程序的日志，而对于日志格式的清洗、日志字段的筛选过滤，以及日志中不同维度进行多维的分组的统计、聚合等操作，则需要一个较为复杂的计算逻辑。因此，一个业务监控系统从技术架构层面来看，更像是一个实时计算系统。

在实时计算领域，我们常常会用到流式计算的模式来实时计算数据指标，而与流式计算相对应，业界还存在着批量计算的模式，二者各有特点，适用于不同的业务场景。Sunfire 采用专为监控场景自研的实时采集 & 计算框架，具有更好的扩展性和更快的响应速度，在架构层面也更加接近于批量计算的模式，但可能达到和流式计算一样出色的时效性，同时兼顾了监控运维中保障数据齐全度的特征。Sunfire 的核心任务调度框架 通过技术创新将日志采集、数据聚合、数据分析和报警在架构上分离。整个架构在任务调度的同时，增加了计算任务的监督和重试，使整个业务流程在架构上获得了较好的局部调整和自愈的能力。在这套架构的支持下，Sunfire 承载了阿里巴巴集团来自 100 多个事业部的 60W+以上的业务指标监控及千万级别的系统、应用监控指标。同时，得益于 Sunfire 强大的实时计算能力和方便的用户配置体验，也有很多用户利用 Sunfire 平台进行实时的业务运营指标计算和统计，来进行业务层面的运营分析和决策。

04.jpg

除了业务指标计算的复杂性之外，Sunfire 平台所面临的海量监控对象规模也是推进 Sunfire 平台技术架构演进的重要因素。面对阿里集团超过百万规模的监控对象，以及海量用户访问造成的流量压力，Sunfire 平台的计算调度策略集中体现了‘面向失败的设计’的思想。横跨数十万个来自上百个事业部的业务指标，其流量受到各个行业业态的差异和运营因素的影响，经常会产生局部的计算任务堆积而造成计算热点。Sunfire 平台通过完善的任务调度和错误重试机制保障了指标数据的实时性和完整性，也通过完善的自监控和自运维系统来发现监控平台的潜在隐患，方便地进行保护和降级。同时，面临可以预期的流量高峰，包括电商的双 11、6.18 大促， 高德出行的节假日高峰等，Sunfire 平台可以通过系统化的方式评估每一个业务、应用、监控项所消耗地计算资源和存储资源，同时允许用户标识出监控项的重要程度，并综合化地优化调配资源，为不同级别的监控项提供不同的 QOS 保障，并方便地在异常时刻对不重要的监控项进行降级处理。在业务监控之外，Sunfire 平台也保持了对于阿里集团复杂的应用状态和各中中间件的监控能力，并演化出以应用为中心的各类智能化监控能力和报警能力。

在阿里集团巨大的技术体量和用户规模之下，Sunfire 平台也在质量、成本、效率情况取得了非常好的平衡。Sunfire 平台能够在各种全局故障时刻（甚至是阿里技术体系的全局机房级故障演练时刻）保障自身的稳定性，让数万技术人员能够明确地观测自己业务、应用和系统的状态；而当监控指标下跌时，Sunfire 平台能够明确地判别下跌的原因是业务用量本身的变化，还是系统运维层面的问题。 Sunfire 平台自身的容器规模过万，我们通过不断地技术优化和运营优化，让监控自身的成本可明确度量并逐步降低；在过去的一年，在我们的不断优化下，相同计算规模的资源开销相比之前降低了 10%以上。我们通过自研的任务调度引擎，能够做到在百万级容器规模下计算业务指标（如淘宝秒级的交易笔数等）的时间迟延做到 4.7 秒；辅之以我们经历了多年线上战火洗礼的智能基线算法策略，Sunfire 平台可以在几十秒的时间内全自动地智能化发现线上故障并发出通告，且不依赖任何的人工规则配置。一路走来，Sunfire 平台已经进成为阿里集团技术风险体系的基石，持续支持着集团庞大的技术体系的稳定高效运行。

而今迈步从头越：从支持阿里集团走向服务云上企业客户

从 2019 年开始，Sunfire 平台开始探索监控产品的商业化输出。我们从物流行业入手，尝试将支持阿里集团的监控平台改造为面向企业客户的商业化监控产品。虽然 Sunfire 平台在阿里集团海量规模下的取得成功，但我们转型商业化输出之路却走得很不平坦。

战场从阿里内部转到外部企业，客户从集团技术体系下成长起来的技术人员变成了外部企业的运维、研发团队，Sunfire 平台在阿里集团战场上积累下的一些产品、技术优势突然变得“无用武之地”。首先，在监控理念层面，业界的企业往往将监控理解为系统、应用、中间件等对象的监控，Sunfire 平台更加擅长的业务监控理念在客户那里尚未落地生根。同时，客户在系统、云平台层面的运维职责和应用研发、运维层面的运维职责的割裂，也加大了业务监控落地的难度。其次，Sunfire 平台长于海量集群的规模化监控，而客户本身的体量很难和阿里集团相比，同时企业上云的规模也很难一下子扩展到较大的体量，可能我们能够接触到最大的客户集群规模也只相当于阿里集团规模的几十之一。最后，Sunfire 平台秒级监控能力在外部企业的运维管理需求层面找不到场景：外部企业的指标监控多数是在分钟级，同时部分传统应用和系统向外暴露和产出数据的迟延也达到了数十分钟，这种情况下讨论秒级监控也失去了意义。在企业化监控的战场上，Sunfire 平台引以为傲的优势无从发挥，却又面临着诸多新的挑战。

监控功能版块建设的挑战

05.jpg

来自 Gartner 的行业分析报告《2021 Strategic Roadmap for IT Operations Monitoring》指出，不同监控工具分层采集数据造成的割裂和壁垒正在消亡，以 open telemetry 为代表的开放协议进一步将各类监控数据透出和采集的标准推向统一。在云原生可观测性的大旗下，各类应用层的监控工具和产品不断演进，不仅在指标（Metrics)、链路追踪(Tracing)、日志（Logging）三大领域不断分开演进，更多地监控工具也在探索三者的融合。企业客户需要监控系统方便地支持各类的应用形态以及响应的数据暴露方式，包括支持诸多的开源系统的监控。同时，监控对象和监控元数据也需要具备更多的开放性。在此之外，可视化领域的大盘、大屏等专注监控展示的界面的功能需要也是企业级监控。AIOps 领域的智能化监控见诸各种媒体报道，而在企业级场景实际落地并取得最佳实践的产品却并不多见。在企业级监控产品的市场上，针对异构数据采集能力、数据可视化能力、智能化能力等层面的监控功能需求越来越多地出现在企业客户的需求文档和项目标书中。如果不能迅速补齐相应的功能版块，则会在竞标或 PK 的场合无法同竞品平起平坐、参与角逐。

高效低成本交付的挑战

To B 的企业级软件交付的难度和 To C 的互联网产品以及公有云产品不可等量齐观。即使是经过若干年打磨的成熟型通用化产品，也需要付出一定量的定制化开发成本，以让产品的通用能力在企业具体的业务流程和技术环境中发挥使用。针对监控产品来说，企业客户，特别是混合云环境下的企业客户，其组织管理结构和网络架构往往决定了监控类产品交付部署的复杂性。监控对象的组织需要和企业自有的 CMDB 进行打通，这往往又牵扯到云平台本身的 CMDB 和服务发现机制的联动。监控用户的组织结构也需要和企业客户的行政管理结构打通，这才能保障监控报警信息被高效地响应和处理。监控系统中的数据采集和传输，需要在客户复杂的网络环境下高效工作，并兼顾企业级客户数据安全和跨网带宽成本的限制。为了应对和客户上述的挑战，监控产品的输出往往伴随着人力服务成本的输出，用以解决上述的问题。而如果产品本身无法在可交付性和可运维性层面持续优化，让周级别的交付成长缩短到天级或小时时，则产品本身的竞争力就会被大幅度削弱，甚至陷入无法交付的窘境。

监控集成的挑战

和大型互联网企业不同，各个行业的政企客户往往采用传统 IT 架构，及 IT 系统也可能是由不同的组织或供应商开发，研发和运维权责的归属往往情况各异。这就决定了客户现场往往会存在不止一类的监控工具，这些监控工具或为开源工具，或为应用开发商自带的监控工具，或为企业客户自研的监控工具。在企业客户现场存在监控运维领域“八国联军”的情况往往成为常态。而这也进一步加剧了监控数据之间的割裂，增加了企业运维的成本。传统政企客户也希望能够统一技术框架和软件选型，打造“大一统”的局面。但碍于各种原因，推动现有系统进行改造往往十分困难。作为企业级监控产品，如果无法有效地（无侵入式地）和企业客户侧的监控系统进行集成，则可能很难在企业客户侧发挥更大的作用。

面对诸多挑战，Sunfire 平台在保持自身优势的基础上，进行了较大规模的功能和技术架构转型，将从阿里集团监控平台演进成面向混合云场景下的一站式全景智能监控平台。在功能层面，Sunfire 平台做到了符合业界监控平台化产品的主流趋势并具备完整的功能广度深度及开放能力。同时，在监控智能化、时效性以及混合云场景下的安全生产方案支撑层面具备了自己差异化竞争优势。

直挂云帆济沧海：面向混合云的一站式全景智能化监控平台

作为企业级监控平台，Sunfire 平台为客户创造的核心价值是提升客户发现、定界、处理问题的效率，提升客户云上业务的稳定性和连续性。从这个价值出发，我们不仅仅需要通过以业务为入口的监控发现问题，更需要通过分层监控能力来帮助客户定界问题，还需要通过高效的（报警）事件处理、定级和通知协同机制来帮助客户进行应急响应和快恢预案的执行。Sunfire 平台的功能演进，也围绕着这个思路展开。

全景智能化监控能力商业化版本的 Sunfire 平台，在转型之初就将集团版本“以业务监控为主，以应用监控为辅”的设计理念升级为“全景智能化监控”，并在业务、应用及云资源监控及智能化监控层面进行了大量的功能演进和补齐。

06.jpg

07.jpg

业务监控是集团版 Sunfire 平台的拳头功能，我们在原有能力的基础上，在业务链路编排、业务全景大屏以及 API 管理等功能进行了优化和增强。我们将集团版本凌乱的业务监控文件夹结构，演进成纵向的业务树和横向的业务链路，更加清晰地表述了客户业务的层次结构和相互关联。同时，我们在业务指标维度上也提供了多维下钻的能力，帮助客户更好地组织业务监控，发现故障时的影响面。为了满足企业级客户运行指挥和态势感知的需求，我们和体验及前端团队合作，打造了全景监控大屏，能够以美观的方式展示业务层次和链路，以及应用和资源的状态。同时，为满足企业客户二次开发的需求，我们还优化了 Sunfire 平台的 API 体系，提升了 API 的使用、管理效率及安全性。

08.jpg

09.jpg

在应用监控监控层面，我们全面兼容了 prometheus 生态，利用社区的力量，极大程度地提升了应用和开源组件监控的标准化程度。同时，我们也基于探针的方式支持了对于应用状态、应用远程调用的监控能力，更好地支持了细粒度的问题定界和排查。最后，我们通过和开源工具 skywalking 集成的方式，提供了应用链路分析的能力，补全了云原生可观测性中关于链路分析的功能版块，动态地展现和监控应用及接口级的链路。在云资源监控层面，作为阿里云混合云-云效产品团队的一员，Sunfire 平台无缝地集成了对阿里云监控在云实例监控层面的能力，同时全新提供了以应用为视角的云上应用资源水位监控能力。我们还在不断探索应用和云实例之间的拓扑自动发现能力，助力更细力度的问题定界。

10.jpg

以“智能基线”为代表的智能监控策略一直是 Sunfire 平台在 AIOps 领域的优势产品，这套基于时间序列分析和机器学习的智能监控框架经历了阿里集团多年的线上故障发现和定级的磨砺。在商业化版本里，我们将智能基线的时效性提升到秒级，同时将单指标智能基线升级为场景化的“黄金指标”智能检测能力，可以自动地发现诸如“流量下跌”“性能下降”等发生在多个监控项的组合故障场景，且不需要人工实现在监控项上作规则配置。未来，我们的智能化能力还会不断在发现、定界、事件处理等多个维度孵化落地。

伴随着功能演进，Sunfire 平台输出版本的架构也由以实时计算为核心的架构演进为面向云原生可观测性的架构。Sunfire 平台对于 promethes 和 skywalking 两个开源平台的集成，并非只是组合部署，而是将开源软件的架构与 Sunfire 平台进行了有机的融合和增强。我们集成了 prometheus 的指标计算能力，也将其和 Sunfire 平台的任务调度机制及存储能力结合起来，让 promethues 监控具备了高可用和规模化扩展的能力。我们将 skywalking 的服务发现能力和 Sunfire 平台的元数据结合起来，简化了部署配置，也让应用链路和 Sunfire 平台的三层全景联动起来。

在融合架构的支持下，分层全层的智能化监控能力也不只是各层功能的罗列和堆砌，而是被全景框架有机的联系在一起。当问题发生时，Sunfire 平台具备三层横向、纵向的穿透定位能力，帮助客户发现云上应用的问题并辅助定界。

面向混合云客户的一站式监控集成能力

如上文所述，混合云客户侧往往已经存在和伴生了很多监控工具及平台，如何能够和这些企业级平台协作和集成，是考验监控平台落地能力的一个关键因素。Sunfire 平台通过监控数据集成和监控报警集成两个层面来实现对客户侧监控的集成。

Sunfire 的业务监控、应用监控及监控元数据分别具备极强的监控数据集成能力。业务监控的接入能力从单一的日志数据源，演进成为支持本地日志、日志平台服务、数据库（SQL）、应用探针、开源组件（ELK）等多种多样的数据源的接入能力，满足了各类客户的需求。特别是一些无法推动传统应用改造的场景，可以方便地通过多数据源的能力快速实现业务监控接入。应用监控基于 promethues 生态，支持数百种开源组件的监控接入和监控报警及展示能力。只要能够被 prometheus 监控的对象，可以无缝被 Sunfire 接入。同时，Sunfire 的元数据发现能力能够无缝集成 k8s，让基于 k8s 运维的客户侧应用能够一键接入 Sunfire。

11.jpg

对于无法采集或透出时间序列数据的已有第三方监控工具，Sunfire 事件中间支持接入各类监控系统产出的报警事件。事件中心对于这些事件进行解析，并能够结合监控 CMDB 和智能化策略，对事件进行降噪、分类、定级和通告。事件中心可以实现对多个监控来源里针对同一监控对象的报警事件进行统一的收敛和状态跟踪，避免客户运维人员在多个监控平台的报警间来回跳转影响效率。

在全景智能化监控的框架和监控集成能力的加持下，Sunfire 平台已经具备了故障发现、定界、处理的全生命周期能力，能够更好地作为安全生产解决方案的核心产品在客户侧落地。

面向安全生产解决方案的服务化能力

在政企客户数字化转型的过程中，往往会面临规模不断增大、技术栈越来越复杂以及组织和人员日渐膨胀的局面。这些都给云上数据化业务的稳定性和连续性带来不小的风险。为了系统性应对和管控这些风险，阿里云混合云平台和中国信通院一起，推出了业内首个数字化安全生产标准 《基于云计算的数字化业务安全工程要求》。基于此标准，我们也推出了面向企业客户的安全生产解决方案，全面解决混合云客户云上业务稳定性管理领域的问题。作为安全生产解决方案的核心产品，Sunfire 平台除了全景化智能监控能力和事件处理能力之外，还将支持安全生产范围内的故障定级、定界、快恢能力。

12.jpg

基于阿里集团业务故障定级规范的经验，结合混合云平台的特点及客户的需求，我们创新性地提出了云平台和客户侧应用业务一体化定级的理念。通过全景监控框架和云平台监控产品的集成，我们将针对云底座、云实例、云产品、云上应用、云上业务五类监控对象的监控报警作为输入，基于云产品的高可用架构、云产品之间的依赖关系以及应用级别等结构化基础数据，产出平台、应用、业务三个序列的统一定级结果，方便客户基于故障级别确定影响面和决定应急协同的人员规模。基于全景智能监控框架和监控集成能力所涵盖的监控数据，我们基于业务、应用链路和云资源拓扑等多种元数据，结合自研的各类智能化定界分析算子（包括但不限于业务上下游流量分析、业务多维下钻分析、应用链路分析、云实例状态分析等），提供主动式的故障定界产品能力。帮助客户明确故障的影响面，以及锁定故障根因的范围，帮助客户确定快速恢复业务的方式。一旦出现问题，平台的第一选择并不是查找问题原因，而是尽可能地执行快速恢复的预案。Sunfire 平台将从应用（微服务）级的快速恢复能力入手，提供一系列自愈的自动化能力，供应急人员决策执行。未来，也将结合专有云应用架构，提供业务级和子系统级的快恢能力，包括和客户侧预案进行集成的能力，方便运维人员在一站式平台上观测系统并作出决策。

和客户共同成长从支持第一个外部客户以来，Sunfire 平台产品已经输出给了数十家企业客户，落地在超过 50 个客户混合云现场，监控着超过 2 万个客户侧云上应用的运行容器（节点）。这些客户遍布能源、公安、政务、证券、金融等多个行业。我们欣喜地看到，Sunfire 平台正在帮助客户建立起完整的监控体系，改变之前监控体验残缺或割裂的现状，并让客户更放心地将核心业务和应用放在云平台上运行。

例如，在能源行业的头部企业客户侧，经过半年多的共建，Sunfire 平台共接入 200+应用服务的监控与管理；实现 400+监控指标的部署，涉及 100 个业务场景，3000+监控对象节点，告警次数 5000+。基于 Sunfire 的事件收敛能力，将日均 700+的报警收敛为 200 左右，降低了客户的运维成本。客户侧的领导每天会基于 Sunfire 平台的监控告警进行业务及系统情况的梳理及优化方案的制定。2021 年的一个早晨，Sunfire 平台的监控准确发现客户业务故障，并通过报警通知客户监控中心人员启动应急，后通过回滚客户应用版本后恢复业务。在这样的表现下，客户也给我们发来了表扬信，肯定了我们产品和服务的价值。

当前，我们已经和深度使用的客户一起，在监控领域一起探索智能监控、根因定界等领域的技术能力。我们可以期待，在不久的将来，这些能力会伴随着我们的产品功能在客户侧落地，取得更好的效果。

放眼当下，Sunfire 平台作为阿里云混合云平台的标准化产品能力，将会落地到越来越多的政企客户的监控实践当中，助力客户保障云上业务稳定性，让客户更加放心地用好云。展望未来，Sunfire 平台作为连接 IT 系统和企业业务的重要枢纽，扮演着平衡业务质量和 IT 成本的重要角色。在数字化转型的洪流中，Sunfire 品平台将和客户一起成长，为企业的数字化治理发挥更大的作用。