Apsara Stack 技术百科 | 混合云全景智能化观测平台Sunfire

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
简介: 在企业数字化转型的浪潮中,核心业务的上云和迁云无疑是转型过程的重中之重,企业对于数字安全性及等保合规层面的需求也日益强烈,混合云成为诸多大型政府企业客户上云迁云的首选方案。随着企业云上业务的复杂化,云上云下技术栈的多样化,以及云上运维组织规模的扩大化,云上业务的稳定性和连续性面临着巨大的挑战。

banner4.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

观测系统的功能版块往往可以拆解为数据采集、指标计算、指标存储、报警、数据展示(包括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平台,在转型之初就将集团版本“以业务观测为主,以应用观测为辅”的设计理念升级为“全景智能化观测”,并在业务、应用及云资源观测及智能化观测层面进行了大量的功能演进和补齐。

3.png
2.png

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

1.png
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平台将从应用(微服务)级的快速恢复能力入手,提供一系列自愈的自动化能力,供应急人员决策执行。未来,也将结合专有云应用架构,提供业务级和子系统级的快恢能力,包括和客户侧预案进行集成的能力,方便运维人员在一站式平台上观测系统并作出决策。

和客户共同成长

从支持第一个外部客户以来,Sunfire平台产品已经输出给了数十家企业客户,落地在超过50个客户混合云现场,观测着超过2万个客户侧云上应用的运行容器(节点)。这些客户遍布能源、政务、证券、金融等多个行业。我们欣喜地看到,Sunfire平台正在帮助客户建立起完整的观测体系,改变之前观测体验残缺或割裂的现状,并让客户更放心地将核心业务和应用放在云平台上运行。
例如,在能源行业的头部企业客户侧,经过半年多的共建,Sunfire平台共接入200+应用服务的观测与管理;实现400+观测指标的部署,涉及100个业务场景,3000+观测对象节点,告警次数5000+。基于Sunfire的事件收敛能力,将日均700+的报警收敛为200左右,降低了客户的运维成本。客户侧的领导每天会基于Sunfire平台的观测告警进行业务及系统情况的梳理及优化方案的制定。2021年的一个早晨,Sunfire平台的观测准确发现客户业务故障,并通过报警通知客户观测中心人员启动应急,后通过回滚客户应用版本后恢复业务。在这样的表现下,客户也给我们发来了表扬信,肯定了我们产品和服务的价值。

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

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


【更多技术干货】
第一期:标准化的云时代:一云多芯
第二期:可运营的行业云,让云上资源跑
第三期:边缘场景智能云化,让云无处不在
第四期:【云+应用】一体化运维之全景智能化观测平台篇
第四期:【云+应用】一体化运维之新一代运维平台演进与实践篇
第四期:【云+应用】一体化运维之数字化业务系统安全工程篇


阿里云混合云(Apsara Stack)建管用一体化的全栈混合云平台,助力企业级客户全栈建云、智能管云、极致用云,致力于成为#政企数智创新的同行者#!
更多产品资讯欢迎访问【阿里云混合云】官网(https://www.aliyun.com/solution/hybridcloud)或加入钉群(32450454)交流。

相关文章
|
存储 运维 Cloud Native
Apsara Stack 同行者专刊 | 政企混合云技术架构的演进和发展
现在,政企客户已进入到用云计算全面替换传统IT基础架构的攻坚阶段,混合云与传统架构的技术产品能力也正在经历全面的比较与评估。阿里云混合云平台首席架构师张晓丹分享IT架构技术深刻洞察,并对政企混合云技术架构的发展进行展望。
1308 1
Apsara Stack 同行者专刊 | 政企混合云技术架构的演进和发展
|
云安全 存储 运维
Apsara Stack 同行者专刊 | 原生混合云 —— 经政企打磨方能赢得政企信任
企业级科技领域的发展就像在海上驾驶航母,相比于朝着正确方向的缓慢行驶,调转方向造成的时间落后会更多。阿里云智能,混合云产品总经理谢宁相信,迎接新浪潮新机遇的最佳实践,不是不断地转动船舵,而是朝着正确的方向全速前进。
389 0
Apsara Stack 同行者专刊 | 原生混合云 —— 经政企打磨方能赢得政企信任
|
存储 运维 安全
Apsara Stack 技术百科 | 如何「场景化」的企业上云
企业上云离不开数据和业务上云,如何在确保安全的前提下,低成本高效率的平滑上云,在云上又能真正解决哪些实际业务问题?混合云君今天给大家讲讲最经典的三个场景~
739 2
Apsara Stack 技术百科 | 如何「场景化」的企业上云
|
存储 边缘计算 运维
Apsara Stack 同行者专刊 | 怀同行之心,筑信任之基,践数智之行
政企云平台处在怎样的历史阶段?数智创新的同行者们面临着怎样的挑战与机遇?在时代巨幕下,政企期待云厂商扮演怎样的角色?阿里云智能研究员、混合云平台总经理刘国华认为,云厂商不仅需要有定力与实力,也需要体会云平台的重量与温度。
507 1
Apsara Stack 同行者专刊 |  怀同行之心,筑信任之基,践数智之行
|
移动开发 Cloud Native 安全
Apsara Stack 技术百科 | 联结良性生态,筑千行百业的数字基石
作为现今IT领域最重要的课题:基础设施云化,离不开与伙伴的携手合作,如何让云上解决方案能充分释放价值的同时形成一个相互依存的自循环生态系统,混合云君来跟你聊聊~
2009 0
Apsara Stack 技术百科  |  联结良性生态,筑千行百业的数字基石
|
云安全 运维 安全
Apsara Stack 技术百科 | 数字化业务系统安全工程
数字化平台已经与我们生活紧密结合,其用户规模庞大,一旦系统出现故障,势必会造成一定生活的不便。比如疫情时代,健康码已经成为人们出门必备的条件,一旦提供健康码服务平台出现故障,出行将变得寸步难行。因此,系统安全问题成为威胁企业正常运行的重大风险,其安全稳定将变的越来越重要。
679 0
Apsara Stack 技术百科  |  数字化业务系统安全工程
|
运维 监控 算法
Apsara Stack 技术百科 | 浅谈阿里云混合云新一代运维平台演进与实践
随着企业业务规模扩大和复杂化及云计算、大数据等技术的不断发展,大量传统企业希望用上云来加速其数字化转型,以获得虚拟化、软件化、服务化、平台化的红利。在这个过程中,因为软件资产规模持续增大而导致的软件开发运维和IT基础设施建设运营压力,也将无法继续采用线性增加的方式来解决,且在DevOps思想的影响与引导下,企业对于改善传统IT运维职责权边界不清晰,操作过程无序、提升运维效率及业务稳定性方面也有着迫切的需求。企业必须加快整个IT架构的转型,在基础设施上云后推动应用往云上迁移,充分利用好购买的云基础设施。
976 0
Apsara Stack 技术百科 | 浅谈阿里云混合云新一代运维平台演进与实践
|
存储
阿里云飞天(Apsara)系统
阿里云飞天(Apsara)系统自制脑图, 我在今年考试低代码开发师高级认证做实操题二时第一次上到了阿里云上,后来又在云栖大会上看到了盘古存储和洛神网络,就很好奇这些神仙在阿里云上干什么呢,于是就去学习了一下整理成了脑图分享给大家一起学习。
681 0
阿里云飞天(Apsara)系统

热门文章

最新文章