开发者学堂课程【阿里云可观测峰会-行业实践分论坛：阿里云可观测峰会-行业实践分论坛】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/776/detail/13940
阿里云可观测峰会-行业实践分论坛
二、万节点规模云服务的SRE能力建设
带来主题为普prometheus和报警中心的产品SRE事件。
1. 自我介绍
宋傲花名叫繁星，是2021年加入阿里，目前是在阿里云做这个产品的特性。今天呢，会接下来演讲会有一个内部执行这样一个系统作为一个切入点来去分享，是如何去整套提供的一些强大的功能去做自身的稳定性，包括一些应急应急响应相关的一些工作
2.系统架构简介
首先，就是简单介绍一下今天关注这个价格，系统用途，其实是一个实时数据。包括连续发的部署，发布等等。或者KS整套，这套标准包括它里面提供的一些平台相关的，这个路口其实自己开发的一个web ：Sernerless个Sernerless是个部署的时候是基于load ：balance类型的一个问题，这也是相对来说比较大家做一些做系统其实是一个比较长。这样的做法就是通过提供这个资源管理的这样一个图片，去自动的去把为何底层的一个深层的一个绑定之后，通过这个时间只有2%的流量呢，之后呢，开会收到了外部的这个数据上报的。就是当考生的实际感知到了这个数据数据流的上报之后，会从卡性中去把这个数据，把这个数据进行一些进一步的计算处理，并且将最终的处理结果写入，写入存储介质。在这里用存储介质呢，其实是有两种，第一种就是。相对来说比较比较快，但是价格比较高的，这个存储于SD，也就是硬盘，还有一些比较相对来说要求高的数据，让放到文件存储。做一个。像就是系统整个电路中还有一些数据，这个数据，放到SM中进行管理。还有就是还有当中有些总刚才说到这个速度，也是一个总结负责的就是计算计算的结果从存储介质中查询出来并且反馈给最终用户这个是整套系统的一个简要的介绍
目前的现状就是整个这套系统呢其实是呃因为是全球开服就其实是要部署在呃全球将近二十个人当中呢可以从这个图中也可以间接的感受呢就是整个数据读写链路相对来说还是比较长的这个数据其实它会经过经过组件处理就是组建包括一些下层一些托管租赁比如卡还有一些底层存储s的这个这张图片其实比较长并且就是将会相对来说比较复杂包括一些基础设施比如说像ak ：bos ：s这一层调度传输网络等等这些是需要监控起来还有一些云托管的怕什么组件比如说像卡夫卡都是的一些托管组件这也是需要也存这些都是组件，这些组件呢，其实也是需要自己去负责把它维护起来，然后包括一些指标，包括一些日志等等这些东西都要自己去做，这个也是目前做的一些相关工作的这样一个状况。
为了展开整个这套工作呢？其实在这里总结的就是。大概分为三个阶段，三个步骤，首先第一个就是说先把数据收上来，也就是说可观测性数据的一个收集的工作
可观测这个术语中其实大家比较熟悉，就是说它分为这三类数据，首先就是max ：max呢，它其实回答就是一个系统问题的这样一个问题，一个疑问就是说其实问题的范围，或者对其实这三类，三类数据中最大的，一般来说都是用max作为整套系统的监控体系的一个入口，针对做一些异常的道理，或者一些问题的排查，可以快速的找到，就是到底。究竟是不是出问题了？需不需要人为介入去处理？为了回答就是系统的到底是自身什么位置出了问题就要拿出的数据相对来说就会想起很多，就是可以回答，就是组件之间的调用关系，包括每次请求。可以让组件之间的调用的过程中出了问题。找到了具体出题组建之后呢，肯定是需要用到最详细的这个。比如说Java开发的，当然比较熟悉的，比如说像BMW，或者说像一些异常的异常的站姿或者等等，这些都是需要通过日志就反应出来，系统到底是哪里出了问题，哪行代码的，或者说是资源本身，可能有些资源上的使用不可以，或者说有些本身程序。这些其实都需要通过日志去回答，这三类数据，其实认为这都是各司其职的，大家之间并不互相冲突矛盾，其实相辅相成的。
把这三个数据收集上来之后呢，肯定是下一步肯定是需要如何将这些数据完整的去展现出来，然后让问题排查更为高效，也能一眼看到就是说系统到底什么问题，哪里出问题，，大家肯定也非常熟悉，需要配一些大盘，把这个数据可视化展现出来。
最终，就是肯定是找到问题之后，肯定需要一套整套这个流程和工具，怎去把整个这个报警和应急处理这个流程去给它完善起来，其实总结了，就是说整个应急处理，至少对于来讲，目前是有这样一个关注点呢，首先，第一点就是说需要一个分级的告警通知升级这样一个策略，能让快速的去找到相应的同学去处理这个高点，而且如果因为某些个人原因可能无法及时处理的话，还需要这个告警涉及到其同学，并且让们去及时处理。还有就是对于每一个系统当中出现的问题呢，可能需要一些任何标准化处理动作呢，也是需要整流成去保证这件事情。当系统出现故障，并且顺利解决之后呢，肯定是需要事后的统计以及复盘的一些工作，能让系统这样一些故障的话直接教训，然后之后再出现的问题，然后系统更加稳定。最后就是遇到问题之后，肯定是说想把整套运维的动作去工具化平化，就是尽量减少去做一些SSH登录机器去手动超频的一些工作。把整套标准出动工具给它画一下，这个后面所讲到的工作比较关注的这样一些点。
去医院比较完整的这样一个急诊分级处理，包括最后能接种等等这样一个标准化的流程，就是这个流程，也需要很多专业工具支撑。其实这个今天就讲到了整个这样一个思想其实比较接近
第二部分，主要给大家介绍一下来自真实工作中的一些经验，希望能给大家一些帮助，首先就是说的就是要监控，或者说做好一个系统稳定性，第一步，肯定是要收集可观测的数据，这些数据，其实在这个系统的视角，其实就分为三个层次，第一个就是最上层是应用层，其实关心的主要是第一。现在业务接口的健康度怎样，这个健康度，主要是用led这三个黄金的指标去衡量，其实就是activation，这个是关心的，就是说这个呢，主要是指这个接口或者是多少呢，就是说的这个错误率错误数怎样，就是说，每个阶段能够通过这三个指标来定义。一些so，会有一些就是企业作为预算，比如说定义多久可以允许这个服务在多长时间内恢复正常？如果说把这在很快很快就就耗尽吧，就会及时去调整刚才所定义的调低，直到系统优化的足够完善之后，再去把它调整。
还有就比如说像一些衡量，一些对对客户系统的的话，可以用这个APP的，这个公式在行动，今天会详细展开，
其实就是去衡量一个服务，有多少的请求，可以让用户满意的去完成，有多少请求是可以让用户在稍不满意，但是也可以接受的情况下满足，这个的话就是放量这个服务健康度，或者说的体验分数怎样，这是一个比较重要的。还有就是说像一些跟业务相关的情况，比如说一个项目营收，用户数等等，这些都是主要关心的
比如说系统需要一些中间键还有一些底层存储，这些的话。主要其实系统大量应用的卡夫卡，kafka ：client消费位点提交情况，生产者缓冲区占用率怎么样，会不会提前把缓冲区沾满导致消息进不来，端会有一些消费延迟，还有一些平均收到的消息大小这些都是比较关系的和卡夫卡相关的指标。在Broker端其实看Broker水位怎么样像读写流量，磁盘使用率怎么样，这些都是比较关系的，还有像云盘，云盘当中使用到的是像ESSD去做云盘的挂载，挂载到服务上，之后看IOPS怎么样，磁盘是不是写满了，写满了要进行扩容，IOPS也就是云盘的性能是否达到要求，不行的话要及时进行优化，优化本身使用磁盘的方式这些都是比较关系的
基础设施层是比较复杂的，这里主要列举了ECS(k8s ：Node)主要包括CPU内存的水位，像ECS会有一些定时运维事件包括机器重启次数等等这些都是需要关心的，这些这些关键的事情，像KBS核心组件的，比如说，还包括一些调度相关的这些指标。整个KBS这套体系比较相关的。像就比如说是不是一直处于分裂状态，没有资源可以足够的去调动，或者像，可能会因为内存使用不合理会有些OMQ的这种。这种事件出现甚至于说可能会比如说像Java应用，可能本身不怎么够用，反正因为拍摄过程exception会异常退出，会有这个事件产生的，这些都是比较关心的然后还有就是整个系统的流量入口。然后像丢弃连接数，因为这个丢弃连接数其实也是比较重要的指标。比如说系统在在某一个时刻丢弃了非常多的连接，那么相当于这个整个新用户进来，其实是一个不可用的状态，那么这个也是需要及时的去员工介入去处理。这些也是介绍的这些关键的一些指标吧，其实这里只是简单介绍一下，其实在真实运维的场景中，还有很多很多非常复杂的质量，这个其实也是因人而异的，那么希望也可以就是通过这些介绍。可以相当于抛砖引玉，就是能够减少系统中的一些监控的盲区，提升整个系统的这个稳定性
这个是一个更详细的这个总结，首先就是比如说想监控ecs节点，那么需要用node-exporter，其实实际上在开发区里是一个守护进程，就是这个daemonset的这个方式去部署上去。还有包括像一些K8S原生的这些核心组件，那么他本身都是可以通过open ：word的格式去把这个指标报出来。让这个普prometheus去抓取的，比如说apiserver ：Etcd ：coreDNS ：Scheduier等等这些组件，或者说这些功能相关的指标，其实都可以通过Meterics这个节点接口就出来给普prometheus去抓去。还有包括像卡夫卡或者存储组件其实因为用的是阿里的云产品，那么其实就是产品本身提供了一些基础监控插件这都是可以直接去接入，然后包括像CSI存储插件，这个也是需要用的。那么其实AK本身对于CSI存储插件也提供了一些非常核心非常关键的,比如说挂载，挂载率,空间占用率等等这些指标。那么这个也是需要接入的，应用层其实像系统里主要有Java应用，Java员写的应用，包括购物应用，那么Java主要用MicroMeter或者如果spring ：boot，基于spring ：boot框架的话那就直接用three ：wood ：activator去做这样一个监控，像GO应用的话，就直接使用这个prometheus官方的这个go的SDK去做一些买点，接下来就会详细的对这些方面去进行展开
首先刚才讲到的就是说，因为底层基于K8S整个这套体系，那么其实像Mac协议的选型，其实也基本上没有什么prometheus这整个这套标准这套体系更完善的一个选择，那么当然就也就用prometheus清算，然后这块就是当然也可以，prometheus其实本身自己在群里搭一套，其实认为本身如果只想搭起来的话门槛并不是非常高，并且社区里已经有很多像其他等等这些比较成熟的这种一键接入的这种方案，但其实虽然技术难度上讲的开源自建的比例，可能相对来说差，差的不是很大，但是像底下考虑的地方比如说像可靠性，运维成本等等，其实如果用托管的prometheus，其实比自己搭一个开源其实要好很多，像比如说像使用整个这套体系直接在集训安装一个非常轻量级的这种判断，然后将数据中心化的存储在全托管的一个存储在这些，做一些监控、告警、可视化等等，这些都非常方便。那么其实也不需要自建很多开通这项业务向来讲，其实因为后面也会讲到，就是说AK本身提供了一个组件中心的这个功能，可以选择prometheus，其实也是接入了这个中心。你可以通过这个组件中心的非常快速的，就像安装一个手机APP一样，就是可以把整套监控系统给他搭起来。采集能力，存储能力其实这个相信可能之前也都调查过了，就是说像托管当然本身相对来讲肯定是有一些但自己的优化，这从性能来讲其实也是需要去担心
就像刚才说的就是像刚才说ApiServer节点开发核心组件，包括像卡夫卡等等这些，就是prometheus本身呢，就是给提供了一些非常方便的一键接入的。比如说
像开发的技术监控，状态监控了，直接通过K8S这个组件中心去安装起来，就是在自己的这个业务集群里，就是装上了这款prometheus这样一个组件，就像应用一样就可以直接安装，之后其实就可以看到在群里启动了这样一个非常轻量级的第二个特征，然后在的这个守护进程里，可以看到像这样一个第二个组件等，在每个节点上其实都启动了一个notebook，去抓取这些节点的关键信息。
像卡夫卡接入，其实主要讲的是prometheus这个云服务实力，这个云服务实力，其实目前就是也接入了像阿里云的一些非常完整的一些云paas层云产品，因为其实主要也就是把这个产品当中选择接入就OK了，也可以看到就是接触的这些指标也是平时用的比较多的，并不是一些很冷门的指标都是因为经常用的，比如说像这里可以看到，就是像topic本身拍的message的input，然后像这个卡夫卡本身实力及实例级别的，这个Capacity就是这个磁盘使用率，还有包括像本身的这个整个实力的流量，因为就是买卡夫卡时候需要一个归档，如果说归档之后需要做一些生配，不然的话整个消息的生产和消费都会受影响，所以这些指标其实都是经常会用
还有包括像云盘SSD，这个的话就是走这个CSI插件的一个结构，就是说在ACK里面就有一个CSI为什么这样一个组件，这个组件就相当于开源来讲，其实本身它提供了一些可观测性的一些非常强的，可以就是通过这个组件提供信息，去及时的看到那块儿有没有挂上，或者那块盘挂上之后FPS的要求，甚至于说写满了之后，可以对它相对来说也能够及时的去发现这些这些云盘的异常状况，及时处理，介入的话呢，其实本身预置这样一些彩色、彩色照，就是比如说像k ：sf ：class级别的，包括个级别的这个PV的状态可以防御监控。
在应用层其实当然没有什么一键接入的好的手段，肯定得需要去通过应用买点，并且把整个用的这个max接口报出来，给刚才说到的这个prometheus探针进行抓去。Java应用就使用这个Michael先去进行买点，这里简单举了一个实习代码的例子，就是像Michael本身，如果使用Michael，可能也了解，就是本身会有一些GM本身相关的，比如说class的，就是加了多少类，包括GMJM的memory分区memory，包括像线程数，线程运行状况，包括像这边本身的版本信息等等，这些都是非常简单，就就直接几行代码就可以实现把的信息报。还有比如说像一些更有帮助的信息，比如说像进程级别的，或者说进程级别的threat，这些其实也是比较关心的，也通过很简单的方式记录下来的一些信息这些，然后把这些完成之后，当然最后一步就是需要启动一个在内部启动一个server，然后把整个的这个信息呢，通过一个HTTP接口方式给报出来，然后绑定整个端口，然后整个这个买点的整个流程做，当然如果有一些指标里面其实很方便。就把这个Frank的指标，注册到这个全局的prometheus当中就OK。
然后下一步就是说如何让UPS的探针去抓取到这些，刚才暴露这些观点，其实也是通过增加一个swap的方式，这sweater直接通过控制台屏幕的方式，简单的写几行，这个一定要就可以完整的去把整个这个监控，采集存储，包括甚至说后面的可视化就泡汤了其实比较简单
GO应用其实大同小异只是买点方式有些区别，在这里就使用了这个prometheus官方的SDK去买点，这里举一个例子就是说，比如说刚才就是系统里面查询怎么样，就是每套查询的这个时间的分布，怎样会有频繁的这种慢查询呢？就用这个prometheus里面这个直方图类型的这种指标，把每个请求的请求的时间分布记录下来，然后记录一下。然后再买点的时候指定一些常用的这种来去统计，然后surface ：water当然这里也就重复介绍，然后就是把GO应用这种方式写下来，然后在课上就完成了整个这套接入。
当然，还有一些就是其实也提供了一些基于这种ETF，最近比较火的切入这种客观性的实现方案，这个主要用来监控比如说可能这些系统代码不想去改，或者可能可能发布的周期比较长，不愿意弄这个代码，就使用这个无切入的方式，去监控这个系统接口的led就刚才说的这个原理，是通过相等的特征，用EPSEPS方式去通过系统内核的一些Error然后去实现这些信息的抓取和存储，这个也是需要在集群额外安装一个APP，可以看到这个
然后安装了之后，其实看到这个图片
其实每个节点都需要提供一段，这个的作用就是给注册到这个系统，通过ETF的方式注册到这个系统内核当中，然后去抓取整台机器的网络流量，然后就是过滤出想要的Sernerless本身的这个网络中，然后最后去找到想要的信息，比如说可以看到其实可以监控到而且包括一些反应时间的分布等等都非常有信心，
其实还有一个非常重要的就是这个trace ：log，其实主要就是也是用c ：Mo的能力去做一些相关的事情。然后呢像比如说系统的日志，比如说像S本身控制，包括像的一些GM本身的一些资料，还有包括达到S1到的一些信息，通过这个front ：end ：up ：front，也就是一个去采用这样一个特征，然后把日志投递到，做一个长期存储。KS系统事件日志基于这个APP事件中心的这样一个功能去把KF本身的一些关键时间，还包括调度上的一些观点等等这些关键事件给监控起来。
这里也放了几个实际的这个系统的截图，就是像ture相关的其实就是通过这个三层，如果使用会看到这样的控制，这个控制台本身就可以看到每个请求的这个经过这些组件，然后在每两个调用的时候呢，接受多长时间，处理多长时间，然后回应总体耗时等等这些信息就是标准的信息就可以拿到。然后就是可以拿到
举例最终通过在官方里配置一个这个logo的数据源，然后可以非常方便地去除一些关键字，或者甚至于说整个关键字都不输入，然后通过一些套路、标签或者什么都能很快速的找到想要的pud，下面挂着pud日志就是很方便能找到，然后对排查问题很有帮助。
这个事件中心，就是主要关注的像比如说这个截图里关注的就是一个pud重启失败，或者说本身因为镜像问题拉不起来等等，或者说因为OM的问题或者说因为外部请求导致水平过高，它自身重启的这种这种事件通过这个事件中心，这个问题给大家简单解释一下就是里面会有一个这样的这样的一个事件中心的这个工作台，然后就是会在底下看到一些集群中的一些关键的事件，然后可以对一些等级比较高的这种事件进行一个订阅，这个订阅就是用散步的方式，第一步就是填写一些基本规则，然后选择需要哪些模式去匹配这个事情，然后需要在在这个时间匹配的时候，需要把刚才发给什么，这是比较简单的配置方式。这种方式能把关键事件监控起来然后达到提升去响应。
刚才讲到的就是把数据如何给收据，下一步，就是如何打造一个非常高效可用的这样一个数据可视化和问题排查的一些工具。首先就是当prometheus吗？跟官方当然是一个黄金搭档。数据可视化工具选中了这个广泛的作为，这个技术在广泛的配置大盘的时候呢，这里就是总结了一些配置大盘的时候一些，这就是首先第一个就是说每次在加载大盘的时候，需要在每个拍照上控制一些查询的个数，实现课程，避免这个展现了很多非常多的一些时间把这个浏览器下压力大。对于这个问题来讲，一次性显示多时间，其实很有帮助。包括就是说在大盘里配置了很多这种灵活的web，可以灵活地去在在一张大牌上切换各种各样的数据，各种各样的条件，这也是一个，就是让个大盘变得更好用的一种方式，还有就是说可以使用Tr这种强大的功能，你可nsform,Transform让大盘就是一些普通的，比如说像这个可以加想象用电子表格一样让非常灵活的去展现这样的信息，包括有些时候，可能忘了勾选一些任何一次查询的一些开关的话，比如说可能只需要展现一个瞬时的状态，这如果不把这个开关给关上的话，可能会查询非常长时间维持，导致就是大盘的渲染时间变慢，这其实也是之前大盘走过一些弯路，之后就是说完这些理论的东西给大家看一些实际的一些大盘的配置。
就是用来监控这个节点信息，包括一些开发区的，凭着这个大盘其实可以看到，就是它的相对来讲这些。通过不同的颜色一些关键的并且值得去关注的一些信息给标记出来，这个也是用些动态阈值的这些功能，去让这些数字以不同的形式展现出来，这也是一个提升排查的效率一个比较好的方式。包括像就是当这个是office本身自带的一些一些大盘，这个的话就是像点位大盘，
实际的大盘的效果就是比如说想关心一些磁盘的LPS，读写时间，网络流量等等，这些大盘都可以把的信息都展示出来，这些比如说像内存使用率，Cpu使用率等等，这些东西都是比较需要的一些信息。
还有就是一些自己配置，比如说业务上的一些全局的可以打开，通过这个广发托管服务去这些自定义的这个大盘，也是out提供的这种就是介绍的一个功能，就是在云上去托管一块儿的实力，通过这个账号可以直接登录到发到这个界面，还有一些阿里云自己定制的一些特定的功能，这个大盘就是prometheus配了一张大盘，主要关心的就是像一些大的数字呢，就是全局的一些分析，包括成功率等等，错误码分布情况，QS变化趋势比较细腻的信息，比如说像单片，就是因为是一个多副本部署，然后看就是这个覆盖是不是分配的均衡，然后还可以看到这些流量比较大的一个用户可以针对性的处理办法。像比如，条件刚才说到，其实有些时候可能比如说在发展的时候需要在这里就是展现，就是发现了之后指标跟大盘有什么这块儿已经戴上这个版本。通过这个库存拿到这个版本，可以在这个实际的这个拍照中去以这样的形式去展现这个X，也是可以在可以在这选到全球各地并且可以快速的切换到全球任何一个指标。做这件事儿就比较应用的功能。
然后，比如说像集中一下这卡夫卡客户端和服务端的这个监控来源于这个监控机场。这个的话就是一个实际大盘为例，然后可以看出个总监，然后会想依赖这个卡夫卡。通过这样一些指标去监控的就是它本身，包括的博客直接连接数，平均长度，为点提交数据，消费流量等等，这些都是需要监控系统，包括producer端其实有些发送缓冲区的占用率，包括数等等这些信息都给转到大盘上。
还有就是像一些GM相关的，比如说像这个组件用Java编写，当然也要去监控一些GM相关的一些情况，包括像一些GM的情况，看到对内对外然后总的包括OS线上级别的，还有想JC相关的比如说像VCVC等等，包括像一些分带的这些占用或者PC的效果好不好，然后包括像一些Cpu ：usage还包括线程数，线程状态等等，就有一些长期的block县城。这个都是需要关注，包括像比如说像发展，或者说一些动态图，在这个加载类的这个统计中可以看到，就是说有一些持续能持续上升状态。比如说系统里可能会使用到一些direct或者说一些对内存这块可以给进行监控。
还有就比如说像有些使用电子表格去统计一些集群中的一些安装的状态，或者说一些重点客户的状态，这个时候可以使用转发到这些transform的这种功能。去把就把整个大盘打造成一个这种电子版的这种体验，比如说像这个，其实就是这个穿梭穿梭,穿梭就是把应用达到这个电子表格当中，之后就是可以通过这个筛选各种各样字段的达到想要的目的。还有就是当然刚才展现的大部分都是一些指标的信息，还有一些比如说日志的信息就需要通过lockie去在这方面去查询这个数据，举了一个例子，比如说这里会有各种各样的快递查询日志，查询日志本身里面会原始信息都会带很多，比如这次查询的时间，这次查询各种各样的UID等等这些信息，通过这种就是后处理的方式，首先先把先把整个这个日志分享一些日常的方式筛选出来，然后通过一些模式匹配的方式把的信息提取出来，并且这些信息可以像一样去把里面的某些切切出来字段的去做一个大小关系这样匹配，最终还可以将匹配出来的日志进行一个格式的二次处理。这种完整的跑完整个流程之后，就可以集群的大量查询之后找到想要的信息，比如说想知道就是有多少查询语句经常出现查询，就会这个场景去优化的整个这个系统。这也是一些实际的经验
给大家介绍一下，就是报警分级响应机制建设这块的一些经验。然后首先就是在这儿总结了一些就是在配置这个告警。然后建立整个应急响应流程的一些基本的步骤。
首先最开始肯定就是挑一些比较关键的指标，或者用户跟用户体验相关的一些指标分配一些告警出来，然后完了之后呢，肯定需要有人去关注一些告警，肯定要派一些同学去做一些排版什么的。然后之后的话就是在高铁出发的时候会触发告警的一些机制，包括一些整理出来的文档，这些都是去需要人工介入处理这些场景。之后在人工处理好之后还需要做一些复盘，还有整个这套流程机制的这个优化，之后就是把这些优化的经验反过来再去反馈到告警配置当中，这个配置整个就是形成这样一个循环的流程不断优化机制
其实在以前的这些整个流程，其实是有一些不尽如人意的地方，首先第一点就是说有的系统，就是一套自建的这种报警器，通过依赖自己的一个系统，就是放弃任务去检查各种各样的指标，然后去掉一些定的Mac或者说一些其他的系统，然后去发出这样一个告警，其实首先这块儿就是有有这几点就是值得感谢的地方，第一点就是说本身这个告警系统是自建的，稳定性其实是自己需要负责，如果铁路的这个稳定性还不如学校的系统本身的告警系统其实没什么意义。这就是因为随着整个这个集群开服的越来越多，这个配置也是越来越复杂，自己维护这个配置，配置全都生效这是一个挺困难的事情，遇到很大的瓶颈
像排班的话，也是就开始就是这个系统没有发展壮大的可能，两个人大家就是轮着去值班就好，但是后来就随着人越来越多了，其实这个排班如果只依赖手机非常容易就漏掉一些关键的节点就要注意了。
还有像报警出发的时候呢，就是有一些报警的触发条件非常单一，并且就是只是说零或者一这个告警，并且这个告警本身这个信息也很难灵活地去做一些，能够根据整个业务需要做一些达标的处理，分歧的处理等等这些其实之前都没有，还有包括像以前向发出这种信息，其实信息量也是非常非常频繁，就是里面只有一个非常干的这种文字的信息，还有艾特谁这个信息，这个告警的没办法主动去关闭的系统，真的出问题的时候可能会瞬间就把把整个全给抓起来了，所以也没有办法去主动屏蔽掉这种也是一个非常不灵活的。
还有就是当之后做一些复盘优化的时候，有些数据的支撑没有办法根据一些已有的这些告警的统计信息去达到能去教的过程，这也是之前系统中遇到的一些问题。
像之后就是因为整个使用ARMS整套这个产品，ARMS也有一些使用的非常强大的这样一些告警和分级响应这个工具去帮助建立整个这套流程。
首先第一点就是说这个告警模板，这个模板其实意思就是说只需要对对于所有的集群，只需要配置一次这个告警规则，它可以让不同的集群去生效这个告警节点，比如说刚才说到这个架构是ACK等每个人其实都是一个ACK ：class ：class和20个如果像之前如果没有告警模板需要再对每个class里面的指标进行告警，自从有这个模板之后，其实这个工作也就大大节省的时间，可以通过这种告警规则模板方式就把告警分派到全球各个位置非常方便
排班其实就是公司里面也有一个这个排版的功能。就是说让每个月就是说可以动态的去做一些轮班，替班这种工作，就把以前手工的排班去交给这个系统去做其实也是靠谱的，没有什么漏班，错班这种情况出现。
给大家演示一些实际配置的一些告警的，这个Demo其实想说的问题就是说如果想对某些告警打上一些动态的标题，就是说在这个实际出发的时候，就要通过这个ARMS的事件处理和告警分化这些功能就可以，在告警出发之后动态的去给打上一个标记给做一些处理。比如说像这个给你展示，就是说给一些告警打上这个优先级，这种标，打上这个标之后对于比较高的，比如说这期就算觉得比较高的时候，把这个报警等级升级，并且通知策略就是告警需要通知谁，通知策略动态修改也是这样的一个功能。
首先如果为了这个功能，首先要有一个数据源来提供这个达标的依据，这个呢，其实做了这样一个事情，第一个事情就是告警中心，其实这个控制台其实是有一个这个数据源的这个功能，这个数据源其实就是说在在报警的时候一个告警出发的时候可以去调用这个数据源连接这个数据，通过HTTP请求获得这个数据，之后可以就是说从这个ARMS的里面拿到达标的这个结果。这个接口是怎实现的呢？
其实是通过这个LC这个产品去实现，就直接在这个工作其实比较简单也不需要自己去部署一个系统完成这个事，就直接用FC非常清亮去在线去把代码写好，然后这个代码其实主要就是去读ACM这个配置中心一些信息配置
比如说像这个配置项就是指定的，比如说UID，就是外部的用户的这个ID和它本身用户在这个处理优先级这个映射关系，把信息存在这个配置项，然后通过FC去读取这个配置项，然后把这个接口因为这个HTTP的类型的这种函数可以再报一个接口，然后给这个告警动态调用，把这些配置好了之后，其实需要做一件事，需要配置一个事件处理，这个事件处理其实就是刚才这个数据，在这里这个数据源选择这个数据源，然后把想要的信息通过这种匹配更新模式的这种方式，把报警的信息带到刚才看到个接口LID返回的这个LID当中，然后返回这个问题之后，就是说拿到这样一些标记，并且达到这个告警这个事就是能完成的事情。
还有就是说向报警中心，其实刚才说的就是说一个告警，如果只是一段纯文本的其实它的执行效率比较低，也可以通过认领关闭，关注屏蔽等等这些有用的功能，去把整个这个告警的质量去提升上去。这个也是一个告警中心提供一个比较比较有的功能。
还有就是因为报警的是肯定需要复盘，在复盘的时候当然就需要知道每个人处理的告警，这些告警多长时间处理这些告警重新恢复，这个的话在刚才引入了一些认领、关闭、恢复、屏蔽这些机制之后点可以办到，因为实际上在处理的时候，报警中心其实在后台记录一些事件的日志，并且通过这些认证分析提供给这样一些有用的复盘的信息，让每次去review的时候更方便的去用数据去说明一些之前不知道的事情
最后一个就是说刚才整个总说了告警，还有的一些应急响应机制，拿到之后还要去处理，真正的去处理问题当然希望就是一切都在一个白屏化的界面上去点击领取SH到某台机器上，或者说某一个里去敲一个命令，其实当然这块其实也可以自己去拍前台界面，但是这个效率是比较低的，所以其实也是用了转发来去做这个白屏化的这个工具，其实原理就是说在在配置大盘的时候用了一些动态的信息，并且把这动态信息，这个链接的形式去拼接到了这个大盘，然后这样就是可以给大家实际看，就是有各种各样的系统，这个系统之间跳转，其实如果没有这个官方的这个链接拼接的话，可能需要自己手动或者是到一个系统里搜各种东西这个效率非常低的，通过在官方里切入这种链接的方式就说去想要的一些运维的动作都化成这样一些链接之间的跳转，这个对于实际效率提升是非常有帮助，并且整个可以通过官方的一套完整的工具是就把所有的事情都都完成，这件事儿能够标准化的区域不好运动，减少人工出错的可能性。
最后就是总结一下就是说整个这套体系目前还有一些未来即将要去完善的一些工作也需要。给大家一些思路
首先第一点就是说准确度，接手的这个优化，因为刚才说的就是拿到这些告警复盘这些信息，这些信息其实没有想到一个特别好的方式去很高效地利用起来，之后就尝试说通过这个报警的准确度和接受的这样一些信息及时调整不合理的告警力度，而且可能会去尝试都以这种方式，比如说告警在A到B这样一个范围之内是多少等级，然后在B以上等级或者在C以上有多少等级，这个就是告警模式，就是有些数据类型的联动，比如说在排查问题的时候呢，除了刚才说到的这个max ：St和love之外呢，还有一些发来的信息，就比如说像比如说一些信息或者其他的这些信息，这些信息其实可观测数据的联动，其实现在来看还是不太够的，通过将这三列数据和发的联动，其实也可以提升品牌的效率，就是买点成本控制，就说本身其实都算是内部的这种。当然这个买点的成本其实也是需要控制，像大家作为外部客户来讲的话，这个节点成本当然更重要，因为直接关系到整个使用阿里客户使用率的成本。通过就是说会定期的去对监控指标的一些维度，一些发散的维度，比如说像PUD在里面的一些，PUD ：UID等等这些比较发散的维度进行一个针对性的治理，对于一些无用的维度做一些数据清理工作，让这个买点成本控制在一个比较低的水平。
