开发者学堂课程【阿里云可观测峰会：行业实践】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1060/detail/16102
行业实践
三、友邦人寿和观测体系的设计与落地
整个PPT将分为两部分，前半部分主要是由我给大家介绍友邦人寿的业务架构和特点，会介绍一下当前我们遇到的一些具体的痛点，最后会讲一下我们是如何思考和设计我们的客观的系统去解决我们当前遇到的一些具体的痛点。后半部分由阿里云的妖精去具体的介绍一下，我们是如何实施我们的客观的系统的。
我是来自友邦人寿康所选部门的运营架构负责人，我在保险行业从业近15年，一直从事保险核心系统的架构和研发工作。我服务的企业及国内头部的保险公司有很多海外的保险企业，这些企业分别来自于南美，巴西，南亚的印度，中东，沙特，地中海小岛塞浦路斯以及欧洲的荷兰。近几年我一直花大力气推广和应用云原生技术，从事云原生应用的架构设计工作。下面，我会给大家介绍一下友邦保险、友邦人寿以及我们的业务架构。根据伤员过程中遇到的一些问题和痛点，将展现给大家看，我们是如何思考和设计，我们的可观测系统的落地和实施的。
友邦保险是在香港联合交易所上市的人寿保险集团，覆盖18个市场。友邦保险今日的业务成可追溯至1919年逾一个世纪前上海的发源地。截至2021年12月31号，集团总资产是3400亿美元。友邦保险于1992年在上海设立分公司，是改革开放后最早一批货发个人人身保险业务营业执照的非本土保险机构之一，也是第一家将保险营销员制度都引进到国内的保险公司，2020年6月，友邦获批将友邦保险有限公司上海分公司改建为友邦人寿保险有限公司，2020年7月，友邦人寿正式成为中国内地首家外资独资人身保险公司。我们有友邦APP，在2021年荣获最佳保险科技平台，欢迎大家到国外市场引进我的官网去下载体验有望卓越的服务。
保险业务流程很复杂，大致来讲可以是银行利用各种各样的工具，去发掘用户自身的保险需求，到最后承担，然后引导我们的用户注册并使用我们的有关影响APP，运营和管理这些客户，这里面会涉及到很多的业务和系统。为了进行友邦健康长久好生活的slogan，上映过程中，我们对我们的应用做了大量的微服务化改造，也适应我们快速变化的业务要求和性能要求，并且我们把原来一些在AS400里面的括号程序，做了微服务化的改造，提高了可用时间，为了获得更好的弹性扩容能力，我们采用了容器化的方案，让我们的应用运行在K8S里面，获得了弹性扩容能力和自愈能力。但是这样做，给我们应用带来了系统复杂度的提升，观测微服务的运行，观测K8S的运行成为了我们的一个挑战。还有一部分应用因为历史原因，是外采的，没有源码，我们评估下来，花费太高，不适合做微服务化的改造，但是我们仍然对这部分应用进行了容器化改造，把它们部署进k8s，还有一部分应用，因为各种各样的原因，不是改造，留在了IDC机房。这样我们的服务之间的调用涉及到云上到云上，云上到云下，云下到云上这种很复杂的情况，签约之后给我们实实在在的带来了SLA的提升，但是访问链路，部署复杂度也比原来高了很多，那如何更好地观测应用，成为我们的一个挑战，建设一个好的观测系统，我们认为会面临以下一些痛点。
首先我们面临的第一个痛点是观测复杂度的提升，云原生微服务化虽然给我们带来了很高的ha，但是总体提升了系统的复杂度，这样给我们带来了可观的复杂度的加大。比如我们的保费计算成功率，核保成功率，交单成功率，用户的日活月活，都是散落在各个业务模块里面的，是否可以提供这么一个全局的视角给我们的业务，让我们可以观察到整个保单生命周期里面一些重要业务节点的运行情况，成为了云原生微服化之后我们是迫在要解决的事情，我们还想知道一些研发肽的具体状况，比如构建成功率，这样的话我们可以知道一些研发肽的一些具体情况，到底发生了一些哪些问题。第二个，是技术选型困难，由于一些历史的原因，我们有传统的基于solid的应用，有基于struts的应用，有web service的应用，当然我们也有基于最新的spring boot spring cloud开发的应用，应用技术选型不一，版本各异，导致我们选择可靠的技术和调用，最终方面，面临着很大的困难。，第三个，是统一观测困难有帮。是一家金融公司，我们的开发系统运维，运维是完全分开的，那之前的日志也是完全分开存储和维护的，没有一个办法让这些数据在同一个界面或者是同一个里面去呈现。举个简单的例子，在IDC机房时代，应用如果想知道一些日志，需要登录到具体的服务器上，如果是多实例部署，不知道日志在哪一台上面，需要把所有的日志都拿下来来进行分析，非常不方便。第四个特点是指标质疑，paas层，我们应用层是有非常多的指标，单数据库来，有可能超过有200个指标，怎样才能压缩这些指标，达到人比较容易比较理解跟追踪的一个数量，需要我们不断的去回顾去删减这些指标。最后一个也是最重要的是快速故障定位，在ac集团时代，我们没有一个很直观的方式让应用知道自己的应用资源是不是足够的，虽然我们已经有一些商业的A片工具，但是那个非常昂贵，没有一个很经济有效的方式去让应用查看当前遇到的性能瓶颈。当问题发生的时候，因为只有少量的应用安装了APM，所以我们的调用链是不完整的，无法快速的故障定位。
在了解完自身的系统结构也有特点，以及我们可观测中的一些痛点之后，我们梳理并确立了可观的系统建设步骤，大概分这么四个阶段在。方案设计阶段，我们一直在思考，什么样的可观测系统才是一个好的符合自身需求的。可观测系统我们认为至少要满足五个要求，，服务资源的追踪，可以把服务运行节点上的cpu内存，网络，磁盘和应用指标直接聚合起来，当问题发生的时候，可以很方便观察到是哪个指标出现了异常。
第二个，可以提供服务top N 试图,按照服务的调用量，服务的解决耗时，按照服务的热点排名，这样应用可以很方便知道哪些API是一个热点API，哪些API请求量比较高，哪些API的AR ti比较时间比较长，所以让他们很方便的去规划自身的服务资源。第三个是提供调用链的追踪，从API接收请求到最后一个依赖服务，能够把这些请求串联起来，并且最好是无侵入式可以从垂死很方便的去关联到日志这样的话当问题发生的时候，可以很方便知道当前是哪一个链路出问题。第四个，是调用时长分布，可以观察到服务的上游跟下游，可以观察到异步的一些耗时，当我们重新启动慢的时候，可以很方便观察到到底是当前的服务资源耗时，还是我的依赖服务资源耗时。最后一个是可以关联数据库的操作，帮助应用观察到API的关联circle存在慢SQL reds的查询存在慢查询，Mango存在漫查询等操作。
下面请右京同学介绍我们是如何实施可观测系统的？线上的同学们大家下午好，我叫右京，来自阿里云JS交互技术部的云交付专家，我从2015年开始，一直在前线探索实践和不倒云原生相关的技术工作。右侧，大家可以看一下，这是我们团队提供的原生交付服务，如企业云化，It治理，南京中应用容器化，还有微服务架构咨询和可观测性咨询，最后还有CMH云迁移中心，大家有需要的话可以了解一下。前面客户提到为了满足业务发展需求，在技术层面需要做云原生技术架构的升级和改造，因此我们和客户在应用容器化和可观测性上展开了深度的合作，下面由我来介绍友邦可观测的设计和实施部分，我们结合客户的业务的情况和监控的痛点，通过几十次的讨论和推演，我们最终明确了两个重要的建设思路，首先我们根据业务价值自上而下的设计和观测体系。从业务监控，应用监控和资源监控一直向下推进，在之前讨论的过程当中，我们碰到一个误区是我们是自下熬上设计的，后来发现其他很多企业都存在类似的问题，比如，我们一上来会优先关注一些资源层的指标，那比如像cpu，内存，或者应用系统的一些日志，异常日志等，这样会存在一个什么问题？是我们如果出现问题了，团队会浪费大量的时间和精力在排查一些从来不会导致客户受影响的一些问题，或者客户和老板优先我们发现了一些问题，无疑这个监控系统它是失败的。所以我们首先需要关注和设计跟用户体验或者核心交易相关的一些业务监控，那比如关注投保人数，投保金额的一些指标，来回答我们这个业务是否出问题。其次，我们需要结合业务设计服务的一些像列入追踪，应用性能监控，比如我们把某一个应用的XXAPI接口翻译成业务可读懂，比如像保单生效的接口，处理时间和处理数量，以及这个接口还调用了其他哪些服务，或者依赖了哪些服务，还有一些像比如RBS的一些买车的一些组件，或者MK的一些组件等来最终回答哪里出问题。最后我们需要结合应用的诊断工具，像arms JVM的调优工具，还有应用日志，以及向资源级别的监控，如容器，虚拟机，来最终确认到底是那代码问题，还是底层资源的一些使用问题，资源问题。这样我们从确定事故发生到定位引起事故的原因，进而再确认问题的本身，来提升故障的发现和问题定位的能力。我们再确认了自上而下的可观测体系之后，接下来需要明确可观测的指标范围。基于客户，在前面可观测的痛点里面提到研发过程当中的度量指标它是缺失的，所以，我们认为可观测指标不仅仅是运行态，还得把研发态加入进来。形成应用全生命周期的监控指标体系，，我们先看一下研发态。系统经过原生改造后，比方的CD流水线都是通过警示进行自动化的，为了提升软件的那个研发效率，我们需要抽象出可衡量的一些指标，没有度量就没有改进，比如应用每天能够见次数，构建时长，还有构建成功率，以及部署频率或者部署成功率等。还有行程这些指标的一些基础元数据信息等。那第二块在运行态，我们分为三层，向监控的话，重要性等级依次是升高的，资源监控层，我们主要聚焦在K8S集群的能的节点，磁盘，网络，还有运行pod的一些监控，还有核心云产品，比如像SLB，MK数据库等这些监控指标。应用层的话，我们主要聚焦在应用的健康度，状态码，还有应用性能的监控，比如像RPRKPS，还有错误数，还有am de gi ze等这些性能指标上。那在业务层上，我们主要监控的像一些业务的核心指标，如PV，Uv，包括投保人数，投保金额，还有投保的签单数等，这块是直接影响着监控系统的一个设计的一个成败，或者好坏，因为这是最能够体现业务价值的，也是领导最关心的。
前面，我们可观测性体系和指标范围的建设思路已经明确了，我们接下来需要在架构方案和技术实现上进行设计。大家可以看一下右面的一张图，总体的设计思路，分为三层，第一层是采集层，看左下方的研发肽的数据采集，因为我们要符合有关的技术架构和建设需求，我们选择用Java自己编写流水线的CICD数据采集器。当研发同学在使用产品时进行应用的一个build或者deploy的时候，该采集器能把应用构建的数据和部署的数据那个全部存到数据库里面。另外，在这个采集数据的时候，我们加上了相关关联的一个tag，实现了那个原数据的共享。比如流水线构建的应用名称必须和我们开发时的服务名称是一致的，这样构建失败的时候能够快速知道是哪个应用出错了。第二，我们针对应用的ATM探针社区一般使用字节码增强的吴青路技术，那比如像我们国内做的比较好的sky walking，但是，由于友邦架构的复杂度，比如，他同时会存在是一零年左右的萨克斯架构和现在spring cloud的一个架构，sky walking，他探针不能完全覆盖友邦这种场景。所以我们第一步会考虑arms这种，那同时友邦对于深度性能诊断也是有比较高的要求的，希望能够集成像阿里开源的arms等能力，同时，APM探针，会影响应用性能，所以，我们最终选择了经过双11大规模检验的arm subject。对于各类云产品，中间件容器集群的监控指标采集，我们通过Prometheus的各类export进行采集，Prometheus作为云原生领域监控的一个在社区已经形成共识了。用日志采集，我们主要使用的MS的方式进行采集，相比set car，我们themselves的占用资源较少，工程上也比较简单。第二层是存储层，我们对存储数据员的选型思考如下，研发肽的原数据和pipeline的构建数据存储在买车课里面，因为这部分数据量不大，而且是结构化的。，像那个metrics监控指标的数据，存储在阿里云的promise上的产品上，日志和调用链chasing数据存储在阿里云的SS产品上，因为考虑到业务的增长，未来会产生大量的数据，这两款产品，能够保证监控系统的稳定性和可扩展性，还有高可用性。同时，产品都是service化的，只是按量付费，也不存在磁盘或者空间的浪费。第三层，是最上面的一层叫统一展示层，我们选择使用grafana那进行汇聚和展示，grafana作为一款开源的可视化的爆款产品监控搭配大盘的标配成绩，我们内部在选型的时候讨论意见是高度一致的，另外当时阿里没有出托管的广泛的，我们也选择了自荐，推荐使用8.0以上的一个版本。为了保证运行的高可用，需要多实例部署，并且将配置的数据统一存到数据库里面去。然后根据之前设计出来的监控指标，我们选择对应的数据源编写查询语句，结合丰富的图表进行广泛的丰富的图表进行统一的展示，能做出非常酷炫的大屏。这边重点介绍一下业务监控的实现，我们把采集到es里面的业务日志和应用日志做统计分析，像SS这种circle的查询功能非常丰富，语句编写也非常方便，比如求数据总量，环比，同比等。那之后我们通过SS grafana的插件，集成到grafana里面，这样的业务统计数据，能够在grafana那个表盘上展示出来。
最后，给大家展示一下我们的建设成果，整体通过大瓶中瓶和小瓶的方式形成指挥决策研发仪表盘用性能展示，包括告警推送，多维度的监控的能力，其中左侧的大屏，我们放了业务的核心指标，容器集群的资源利用率，包括service的pod健康度以及连通性等通用指标进行全局的呈现，这一块，给公司的领导和家公司提供决策的支持。右上方的中屏大家可以看到，主要放了流水线的研发效率指标和应用性能的指标，还有全局调用量，帮助研发的同学提升效率和问题定位的一个速度。右下方的那个小屏，通过历史数据的对比，我们设置了报警的阀值，当出现异常时，通过钉钉或者短信报警的方式推送到电脑手机终端，帮助运维的同学能够及时的发现和处理问题。以上是我们整体可观测性建设的设计方案和实施效果。
四、阿里云ACK容器服务生产级可观测体系建设实践
首先介绍我们阿里云容器服务ACK团队负责阿里云公有云上的是k8s云服务。我们在2022年第一季度，在权威机构Forrester发布的公共云容器服务分析师报告中，我们阿里云容器服务ACK团队荣获了比肩Google的全球领导者的能力上限评级，这也是首次有中国科技公司进入该领域的领导者象限。然后可观测能力在分析师的报告中也是占有不可或缺的地位，然后我们ACK的可观测能力也是得到了分析师非常高的肯定，分析师非常不吝啬地使用了excellent，seamless等的词汇，说明我们的可观测能力是非常的杰出的，而且在产品间也是做到了无缝的集成，是很有效很有效率的，为是异常诊断和是服务的业务重磅提供了能力。这个也明了是客观测试构建咱们用户的it系统和运维体系的重要组成部分。那接下来我介绍我整个politician的大纲，首先我们从三个方向来介绍，第一个是介绍我们整个ACK股观测体系的介绍，然后其中介绍整体的全景拍照，以及从是可观测非常经典的三大支柱，logging，tracing，metrics 3个方向，具体的介绍我们ACK刚才体系的组成部分。第二个我会在第一部分介绍的观测体系的过程中，穿插的介绍不同部分的一些常见的实践场景，包括了业务异常的故障诊断场景以及是稳定性的保障场景，以及在生产级的规模集群中稳定性的保障的实践。然后最后一部分我会介绍是利用这是ACK可观测的能力，如何为客户快速的建立他们的boss体系,其中包括是devops和itop 以及最近比较需求比较强烈的aiops体系。
首先看到的是我们ACK观测体系的全景图金字塔，我们ACK的可观测体系可以从上到下分为四层，最上面是最接近用户借物的business monitoring业务监控，其中包括了用户业务的前端，包括前端的流量匹配纠纷，以及前端的是性能、JS的响应速度等的一些监控，以及它的入口流量我们会通过容器服务的ingress dashboard来监测，是ingress的请求，请求量以及请求的状态。然后用户也可以定制他的业务日志，通过容器服务的日志监控来实现他的业务资金监控。第二层是application performance monitoring，这部分包括了用户的应用监控，我们求arms这种APM产品提供用户的，比如Java的providing，还有Tracy等的能力，我们也支持open Tracing和open telemetry协议的多语言的监控方案。再下面是我们容器的主体，是容器的container monitoring，容器层包括了容器的集群资源，容器的状态层，以及容器的集群的稳定性，其中我们使用阿里云Prometheus能够在一张global的大盘中展示不同集群层面的资源应用，然后性能以及水位，其中也包括云资源，由我们的云监控产品提供，即云资源的监控能力。
然后其中容器层也包括了世界体系，以及日志体系，其中是由我们的实验中心和日志中心来覆盖，然后最底层，是我们的基础资源层，Instruction monitoring，其中包括了不同的云资源、虚拟化层、操作系统内核层等。容器层和最下面的基础架构层，我们都可以使用基于ebpf 的无侵入式的架构感知，k8s监控能力来做网络和调用的整体Tracing。
ACK的可观测体系自上而下可以由这四层来拆分，但是每一层都和可观测的三大支柱logging，tracing，metrics有着不同程度的映射。我等下从logging，tracing，metrics 3个经典三大支柱的不同纬度来详细介绍各部分的客观测力。
接下来我们用一个例子来串联一下整个ACK的可观测体系，这是一个用户的异常诊断的案例。这个用户他他有一个线上系统，好在我们ACK几分钟，线上系统是它的流量由朝九晚五的不同业务保存波谷，造成他这个应用会跟随这个不同波峰波谷有产生不同的水位波动。然后这是一个用户他这个业务在早上九点多发生业务流量刚激增的时候出现了一次异常的异常诊断过程，首先他收到了我们第一步容器报警，可以看到它的核心的业务，或者出现了大量的情况，那这个时候用户收到之后可以快速反应，进行止血，对这个核心业务的进行重启或者进行扩容。进行马上的执行，然后用户需要开始找到是这个问题的根因，他首先通过Facebook从入口流量的这个至少下的角度去分析，看到当时确实是出现了这个整个对外业务的访问成功率，下降以及出现是调用有499的是4XX的这么一个返回码的一个请求，说明这次一场是影响的用户业务的，然后再从资源以及负载层面，看到确实是由于它是朝九晚五的流量导致的水位复杂，但是在当天的早上九点的时候会有一个和故障对其的明显的水位的飙升。这也是故障所在中和了上面的这些问题以及是我们第一时间报警出来这个核心业务的后端的定位，然后他结合是下面他的业务日志进行分析，他可以看到当时他的业务确实是出现了异常日志的输出，然后根据他这个异常日志输出加上他使用了我们arms加法的ap pie应用监控，然后他可以看到它的代码堆栈级的电脑关系，然后他定位到当时他的是它是产生了一个缓存的bug，由于他早上九点钟业务量飙升，然后它的缓存引发的bug，最后造成频繁的数据库的读写，这个这样一些反应，他可能出现了数据库的查询，然后最后通过修复bug，然后彻底的闭环了整个异常， 这是一个非常典型的贯穿了整个 ACK 可观测不同能力的一个异常诊断的排查过程，也帮助我们更好地理解是 ACK 整个可观测体系是如何相互工作和相互协调的。
然后首先我先介绍一下是整个异常诊断发现问题最快的一个手段也是我们是 K8S 场景下经常容易被人忽略的一个手段。在 logging 体系里面， K8S 包含了是事件的体系，是事件体系属于 logging 三大支出中 logging 这个分支。在社区的 K8S 中包含了非常成熟的事件体系，社区的 k8s提供了应用层的实践以及 runtime 层的实践。我们 ACK 可观测体系在社区的事件体系之上做了更多的增强，从表层到底层都进行了覆盖和增强，做到了可事件体系的是全覆盖。首先是从最上面的应用 K8S 应用事件，是我们也提供了是用户的灰度发布的异常事件以及是 hpa 等异常行为的事件。然后我们增加了 OPS events ，即集群的管控事件，包括了用户对集群的异常操作以及重要的变更，甚至是成本和预算的超标等。我们接下来提供了是集群核心组件的异常，集群的稳定性很大部分是由集群的核心组件的健康来保证的。我们集群核心组件包括 API server ED CD scheduler， kcm，ccm 等都做了异常事件的增强，如果出现异常事件会第一时间进行触达，然后我们也包括了用户侧核心组件的一些事件，包括了 coding 还有存储等。
runtime 层我们也是做了一些是容器引擎层的增强，包括了 content D kubernetes group 等的异常。然后更底层是不光是容器层，容器的基础资源层包括了操作系统 kernel 也会是整合到我们整体的 ACK 实验体系中。当这个集群中的节点出现了操作系统内核的夯基宕机以及一些操作系统配置的异常时，它的异常时间也会整合到我们的 ACK 事件体系中。当然操作系统有了会有更下层的 infrastructure platform 是我们的云资源的异常，目前也是能够统一整合到 ACK 的事件体系中。所以当您使用一个 ACK 容器服务的集群时，您是可以感知到一直到底层 infrastructure 层的异常事件，这为我们的容器服务的运维保障提供了更强的负感和保障能力。
刚才介绍的是我们非常复杂和庞大的事件体系，在产品能力上，用户是如何使用这些能力的？很简单，我们在 ACK 中提供了开箱即用的事件中心能力，当您在购买了一个集群中之后，可以一键开启事件中心即可享受刚才复杂的事件体系，我们有预置的事件中心大盘会对重要的事件进行突出以及统计。同时我们事件中心也提供了强大灵活应用的数据分析能力，为后面基于事件驱动的 OPS 体系提供了能力基础。然后我们 ACK，K8s 集群，更多的是对资源的生命周期进行管控。我们的事件中心也提供以事件为锚点的资源生命周期的监管控能力。可以看到这下面是一个 POD 的生命周期中最重要的几个时间点的时间事件，我们可以以此进行性能的调试优化，以及对异常获得状态的快速反应。
好的事件体系介绍完后，我们回到它的父类日志体系。logging 在 k8S 中主要的使用场景首先是重要的流量，如 ingress 等。我们在 ACK 的日志中心中默认提供了 ingress 等这种重要场景的默认大盘。您可以在一键接入 ingress 大盘之后，快速地看到您的集群 ingress 的流量，其中包括 PV， UV 还有是应用的异常状态等以及统计，快速清晰，应用易用。
第二个日志的场景是审计场景，集群中的资源经常被不同的账号访问，使用，集群的安全也是日益需要重点关注。然后我们提供了审计日志大盘可以快速的分析集群的资源他的访问和使用轨迹。在未被授权的这些访问中，我们可以进行报警和预警，为集群提供更安全的环境。最后也是最常用的是如何快速的在容器场景接入用户的应用日志。我们提供了云原生的无迁入市的日志获取方式。您只需要通过一个简单的 CRD 或者是在您的 port 上打一个 annotation ，您可以把你的 port 日志采集到我们的日志中心，并享受日志中心的多维的强大的分析能力。
日志体系介绍完，我们来介绍覆盖场景最广的 metric 体系， metric 体系首先它是在做稳定性保障和性能调优时，最常用的体系，水位的指标等都通过大盘直观地为用户进行展示。然后我们也是在产品侧预置了无缝的arms Prometheus大盘的产品体验。您购买了一个 ACK 的 QS 集群之后，可以建的开启Prometheus大盘，我们也预置了重要的场景的Prometheus大盘，这些大盘都是经过 K8S 上面业务运维的成熟经验的沉淀。然后我们的Prometheus方案会涉及到不同的服务，不光是包括容器服务侧，其中包括了最核心的 k8s 的应用网络。然后核心的控制面的指标还包括比如 AI 场景、 GPU 的指标以及存储是 CSI 等，外部存储场景也包括了资源的优化或者是成本的优化指标。然后我们使用统一的Prometheus数据链路方案，能够不光是能够支持容器场景的指标，也支持云产品不同云产品的指标以及甚至云产品上不同中间件的指标，可以做到所有的层级的指标都在统一的Prometheus数据链路中，然后进行统一的大盘展示。然后我们 ACK 的集群控制面的核心组件包括 API server etcdscheduler 、 kcm，ccm 等，也做了这部分托管的核心组件的指标加强 POD 集群不只是负责托管这部分的核心组件，负责维护他们的 SLA ，同时也会暴露透明这些指标性能给到用户，让用户使用的安心。
指标场景是稳定性保障的一个重要知识使能力，这里我们很荣幸的是有这么一个案例，是我们 2ACK 非常荣幸的为 2022 年的冬奥会助力冬奥的系统圆满平稳的运行。我们 ACK 集群中部署了冬奥的多个核心业务系统，包括冬奥的国际官网，然后票场，即比赛场馆的票务系统等，也是为这些多个核心的冬奥系统保驾护航。然后这些多个核心系统多为 Java 系的微服务架构。当真正使用的时候会有近千个 department 的实例。我们是通过引入了压测的方式，首先先合理的进行容量评估，然后在生产的时候同时配合我们为冬奥配置的首屏运维大盘，实时的进行应用和集群稳定性的保障，保证了当时冬奥访系统访问的顺滑。
刚才是稳定性的重保。然后我们第三个场景是生产级的集群如何进行，是集群的稳定性保障。可以看到是很多用户他的生产系统是规模很大的，常常到达了千级别节点的集群的规模了后，用户在集群上的应用有时候会进行密集的大规模的集群资源的访问，这个时候经常会出现集群稳定性的一些问题。我们的 control plan 的指标的增强，为这个这种场景集群稳定性的场景做了更多的保驾护航。这种我举了两个最常见的场景，是用户在这种大规模集群中频繁密集的访问，集训的资源会影响。首先会影响到 API server ，如果出现这种情况， APL server 它的请求数会比较高，会处于一个高位。然后 APS server 的mutating 的请求数也会出现一个高位。这个时候 API server 它的负载是很高的，它可能会出现 drop 请求的是丢弃请求的情况，这是 API server 的一个是降级的特性。这个时候是有可能影响用户业务的发布或者是甚至影响用物的变更。
第二种场景是当这种密集的集群资源访问情况出现的时候，它也可能影响是打满 API server 的 SLB 带宽。可以看到是这种情况出现的时候，是 APL server 的请求延时 rt 会标志高位，可能一次 API 的访问可能出现好几十秒，这个时候是很有可能影响用户的业务的。这种情况 APS server 的只读请求数也会飙升。我们在遇到这种情况的时候，我们提供这种 control plan 核心组件的监控，大盘可以快速的发现这些 API server 的水位和请求响应时间的延时问题，做到问题的快速发现,第二步我们可以根据 API server 的访问日志快速的定位到底是哪个应用出他做了什么动作，导致 API 搜索的水位和资源请求如此的高,最后配合用户为用户定位，最终找到对应应用进行止血，最终闭环问题.这个是生产及规模的一些集群稳定性的保障事件。
这里介绍我们近期推出了Prometheus for ACK PRO 这个是我们Prometheus升级的一个升级服务，它包括了多个数据源的监控，能够在同一张大盘上看到多个数据源的视角，包括了集群事件日志，还有是后续我会介绍的基于 EBPF 的无侵入式的、应用指标、网络指标等，做到一致性的体验。用户可以通过一张大盘,通过关联分析的逻辑从总览到细节，然后通过多数据源这种多角度的可观测能力的不同角度的一些排查，最后达到是可以更好的方便用户进行稳定性的保障以及异常问题的发现。
最后更快速的定位问题，是Prometheus for ACK PRO 这个升级服务，敬请期待。
最后介绍一下 tracing 体系。在 ACK 可观的体系里面，tracing 体系是最终能够定位根因是定位问题根因的能力。首先在 ACK 里面，tracing 体系分为两部分，第一部分是应用层的 tracing ,我们提供 arms APM 能力，其中也支持 open tracing open telemetric 协议。这种协议使我们可以支持多种语言的应用。比如 Java 我们也可以提供无嵌入式的 APM 能力。您只需要在您的POD 上打上一个 annotation 然后您的 Java 应用的 POD 即可享受实时的监控数据服务。您可以看到实时的应用水位以及 jvm 的性能指标。您也可以看到您的应用上下游分布式和微服务的全局调用拓扑图。然后再加上等场景，您还会想受 providing 以及代码堆栈级的调用监控能力。不同语言可以汇聚成同一张分布式调用最终的大图，自上而下的看到您的一次分布式的调用，从而定位诊断问题。
近期我们也推出基于 EBPF 能力的网络层面的吹响能力。通过 EBPF超能技术，我们在内核层面实现了零代码的改动，而且是非常低的性能消耗，一种网络 tracing 的能力，可以看到我们提供了全局拓快扑速定位问题的一个调用链的一个网络拓扑展示以及资源层面的展示。我们也支持后面统一的一张视图，在这张统一的全局架构视图中，我们会集合 metric tracing 和 event log 多个角度进行统一视角的可观测能力观察。
最后我介绍是基于这些可观测能力的利器，我们真正是要帮助用户建立成熟和可靠的 OPS 体系。首先是我们推荐使用事件驱动的 AIOPS 体系，用户可以通过事件来作为统一的驱动数据源进行问题急的发现和触达，以及它的智能化的运维操作的一个桥梁。然后我们在 ACK 事件中心为核心，构造了一个是统一的事件格式的规范，K8S 的事件会以统一的事件配置格式的规范提供给用户。我们最后会以是 K8s 运行层的事件以事件中心为核心，然后其中还包括是比如镜像的一些构建事件，最后通过统一的一个事件处理流给到用户，这些事件会统一的收口输出给用户，用户可以通过订阅这些事件去做这些事件的智能化的运维动作，以及构建它的 chatOPS 是体系。用户可以通过某个应用的业务进行业务事件的推送并且对这个业务事件进行智能化的运维处理，比如智能的扩容或者是缩容等。我们也提供了 ACK 的报警中心，通过统一的报警配置，为用户构建 AIOPS 的体系，帮助用户快速的建立运维的是订阅和收发和问题排障和处理的体系。
接下来介绍我们刚才到是报警中心会为用户提供统一的配置，帮助用户快速的建立在 ACK 场景上的异常诊断的异常规则集。首先我不知道大家有没有遇到过这样的问题，作为一个业务的运维人员，可能最头疼的第一个是我没有能够完全运维整个系统的经验。然后 ACK 报警中心提供了开箱即用的报警能力，沉淀了常用的容器场景异常规则集，开箱即用即可继承这些沉淀过的运维经验。第二个可能比较头疼的问题是我发现了异常，但是处理这个异常的人不是我，我需要快速的匹配这个异常和真正能够处理这个异常的人。所以我们可以通过报警消息的细粒度订阅关系构建 BIOPS 体系。不同的异常可以通过报警中心的订阅配置关系投递到真正能够解决这个异常的人。然后最后是我们无法快速的为一个异常找到处理这个异常的标准处理流程 SOP ，我们目前 ACK 也沉淀了标准的异常以及对应标准异常处理的 SOP 手册。可以看到当你发现一个报警的时候，报警会告诉你这个应用是什么类型的异常。然后我们会对应给用户提供处理这个异常的标准 SOP 修复流程。
最后我介绍最近需求比较强烈的是降本增效，finops 的体系可观测测试数据的来源以提供方。finops体系离不开数据。首先这个事情的背景是在近期降本增效的大环境下，越来越多的用户是遇到了上云以及上云阶段或者是已经上云之后治理阶段的是降本增效的问题。用户会遇到上云之前如何上云难规划，上云了之后，云产品种类丰富以及一个集群用到的资源类型也丰富，计费难，第三个是可能有用户他是高度 SARS 化的应用部署在同一个集群中进行共享。一个应用如何分摊它的成本，分账难。最后是每年都会有新的业务生成，每年都会有新的业务下线，然后集群和资源的使用关系是动态的，如何进行持续的优化和治理，难。最后是这些能力常常都是使用 Excel 表去进行管理，这种老式的方式在云原生的场景下会有丰富的用户应用，有丰富的账单资源类型，管理懒。我们 ACK 提供了云原生企业 it 成本治理的方案，通过多维度的成本分摊和估算的模型，为您的集群的资源进行成本估算和分摊。然后可以通过根因的下钻和趋势的预测进行成本洞察，您的集群上面跑的多个应用业务的成本，可以细粒度的下钻进行成本拆分。容器场景包含了多种场景 AI ，多集群等。集群场景上的成本我们会有成熟的解决方案覆盖，以及我们提供企业云原生的it成本治理的专家服务。首先可以让您的容器场景的计费成本以及分摊模型算得清，接下来我们还推出了内置的应用资源画像以及您应用资源的智能推荐，可以为您的资源推荐您的所需的成本以及进行预算的控制。最后我们会根据不同的场景进行成本优化，如大数据、AI，游戏等。最后场景的支持也是多样化的，包括多云和混合云等都会在统一的财资平面进行展示和统一管理。
非 OPS 体系由于比较新，所以还是比较难理解。我这里举非常实在的例子，中华财险。中华财险这个客户他是在是进行了一个从传统 it 架构到云原生化的一个过程。它是会有千合级别的集群的规模，它的业务是非常多的 SARS 化的，线上业务，具有高度的多株化。然后他也是个金融行业的头部客户，他对业务的稳定性要求非常的高，而且对成本的趋势敏感度也非常的高。他遇到刚才的是容量规划难算清成本难，这些前置资源难发现，以及是这个成本优化和业务稳定性也很难平衡的一些挑战。
我们通过 ACK 的成本治理的解决方案为它进行了不管是压测进行容量规划，还是通过我们 ack 成本分析进行业务分账的账单管理和分析。最后成本分析也帮助他找到了资源的优化以及为它提供了分配资源的优化策略。最后我们容器服务还提供了是细粒度的容器部署以及弹性等策略的一些优化手段。通过这些手段，最后他在整个上云的过程中，在他上云前，整个集群的资源的分配显示率可以达到30%多，这个是比较浪费。然后它可以做到非常是非常好的 10% 以下的集训资源闲置率。这个已经是行业里面非常好。它是一个非常典型的在上云过程中进行成本治理的一个案例。
