大家好 欢迎来到上海库比康我是来自阿里云的基础平台研发工程师我叫彭兰光今天我们的议题是在阿里巴巴我们是怎样先于用户发现和定位KBS咨询问题的我会将我们在阿里巴巴管理大规模ChromeNetflix咨询的稳定性经验分享给大家大家会了解到我们是如何做到快速发现问题定位问题以及解决问题的同时我也会将我们对于稳定性问题的思考一起带给大家因为像初级的ChromeNetflix的同学也会做兼容所以我会尽量讲解的前线易懂一些一定争取让大家有所收获我们先来大致看一下议程首先我会介绍一下业务背景以及我们所面临的挑战换句话说就是为什么要做然后会带来我们的一些思考以及方案的设计和成列接着我会带着我们自言的一套ChromeProb 询解探测体系的两种系统架构优缺点这两种架构会分别适用于不一样的业务场景最后我们会聊聊我们有什么能力有能力快速发现问题了那么发现问题之后我们又能做些什么如果还有时间的话我就会大致讲解一下一个简单的demo那么我们正式开始吧首先我想先向大家自我介绍一下我的团队我们是阿里云云原生用平台的容器服务团队我们的产品有ACK ACI等等我们管理了大规模的Chronetics 职群不仅仅向外部公有云的用户停留Chronetics 服务我们同时还承担了阿里巴巴集团上云阿里巴巴应用全面容器化的工作现在整个阿里巴巴的业务都是跑在我们的Chronetics 职群上并实现云原生和容器化这里有大家耳熟能详的天猫淘宝中间也有高德考拉厄罗蒙我们同时也是阿里云的管控里座各种各样的云服务也运行在我们的集群之上比如说视频云 DataWalksMSE Wave服务引擎 MQ消息兑炼等等同时我们也需要对运行在我们之上的业务的基础设施的稳定性负责现在云原生的架构越来越流行越来越多的产品和应用开始选择云原生架构这里有一张图大致示意了现代云原生应用架构应用生育云上 长育云上各级提供分层的功能这种分层的服务能够让业务和应用专注于业务层屏蔽 平台和基础设施层的复杂概念从稳定性的角度来讲这种应用的架构分层上层应用的稳定性就会开始依赖底层基础设施的支持另外大一桶的机座继位大规模的资源调度优化和在离线混布提供场景也对基础设施团队维护大规模机群的稳定性问题提出了极大的挑战这里有两张形象的图可以展示出云原生应用架构下的业务应用和平台层基础设施之间的关系Commonities 机群是非常复杂的一个单机群的链路组建就有数十个 甚至上百个之多更何况是大规模的多机群管理呢所以说我们看我们自己我们平台层看我们平台层自己是非常复杂的我们有非常多的组建我们ETCD,APSOS,Scheduler,KCM,Load还有各种各样的CRD,各种各样的Operator然后我们还需要管理各色各样架构各不一致的机群我们觉得我们复杂极了但是我们提供给用户的只是一个标准的Commonities服务所以用户看我们只是一个标准的Commonities服务而已它并不需要知道我们内部的各种各样的细节运行在我们的上面的业务同学呢他根本感受不到我们这种复杂因为我们已经把复杂包掉了留给用户的是一个简单的统一接口就像淘宝一样的应用如同这是一个淘宝一样的应用它其实也是非常复杂的它包括购物车搜索交易导购支付系统然后还包括物流系统包括各种大数活动还包括DB的分库分表类传的Memory Catch还包括消息系统甚至包括一些这个叫一粒多活但是提供给用户呢用户可能看到的只是一个按钮提交订单为什么能够做到这样呢是因为我们把复杂留给了自己把简单交给了用户很多时候好的应用开发者它不一定是基础设施专家云原生让业务专注于业务基础设施专注于基础设施同时业务很多时候也只能关心业务自身的稳定性它也没有能力关心或者说是不希望投大量的人力和物力去关心基础设施和平台的稳定性所以关于平台层和基础设施的稳定性的问题呢我们也需要把复杂留给自己把简单留给用户为用户提供稳定的平台层服务同时我们会更加关心全职稳定性和全职可用性这里并不是一个单点的可用性比如说APS Server我做一个很简单的比方即使APS Server它一直是可以用的KSM也一直是可以用的但是业务链路已经挂了业务的破得已经不 running了这有什么意义呢我们可以我们出现了这种情况之后我们还可以向用户说我们为你们提供了可靠的服务吗刚才我已经提到了我们的容器服务是阿里巴巴集团业务以及阿里云容器云服务的底座我们上面跑着各种形式各意的业务比如电上业务中间键二方业务搜索阿里云云底座阿里云云服务等等我们还有数百个字眼和开源组件比如etcd csi poachcni kata open crowds等等等等等等每年有数十万次的组件迭代半根同时我们还需要管理数千个集团数十万台节点甚至有一些大的集群的单集群节点规模已经过万了业务架构更是分繁复杂有单组集群多组集群vc集群联邦集群等等等等同时还有各种再离线混布统一调度应对各种大数活动业务缝织等等并且运行时也存在多种形态比如round C round D系统是这样的复杂任何一个不起眼的细节遗漏或者处理不慎都有可能导致非预期的伤害我们要怎样才能够降低非预期的风险呢另外我们又是如何对形态各异的用户集群运行时的权局稳定性负责的呢如何才能够先于用户发现和定位这些集群中已经存在或者即将发生的问题是保障集群的稳定性建设的众中之中也是kubernetes权局高可用体制的计时下面是我们应对这些问题的一些思考这是一个极度减化的用户发布扩动链路模型虽然说极度减化但是实际上我们仍然可以看出链路还是非常长的还是比较复杂的首先用户他通过发布平台扩动平台到了我们的职群里边的appsrappsr他需要去和etcd做一些读写然后他需要去请求他需要去看那个schedulerwatch到appsr的变化的时候scheduler会做一些变化然后同时controller这边他会去读appsr的一些状态在一个节点上通过kubernetes起一个containerkubernetes启动containerd然后再起一个容器在启动器的过程中还需要调到网络链路、存储链路、CNN、CSI等等这条链路还是非常长非常复杂的所以说我们至于这些复杂的链路我们为了保证保障这一个用户的扩动发布链路它是畅同的我们首先带来了几个预设第一 链路复杂组建众多各组建它是分别迭代升级的组建监控无法无视角的覆盖全部场景第二 即使链路上各组建节点监控的数据都正常也并不能够保证说集群整体链路一定是100%可用的只有经过实际的业务权链路探测才可以确定实际是可用的结论第三 反正法在证明集群不可用的场景下一定忧于矩正法就是哪怕说你这一个链路中的各个组建各个流程 它的监控数就是多么的漂亮多么的绿但是只要用户发布失败了它就确实是发布失败了一定是100%失败了接下来是我们另外在单集群之外我们还需要关注多集群的管理下面是一些多集群管控中的不稳定因素的势力就比如说我们在集群管控层它存在有限流 封控 证书 管控组件版本管控组件配置 密钥和设置混布的参数 应用的 扩大节点的状态等等然后我们的集群的形态又各异不同类型的集群可能形成不同类型的集群组而同一类集群组之间的它的配置是不是一次了比如说我们都是那个电商的集群我们都是或者是我们都是本地生活的集群那么我们的限流配置是不是一致了我们的封控配置是不是一个配了一个没有配或者一个配的高一个配的低比如说我们的证书是否某一个集群的证书是三年而其他的集群的证书它可能只剩两年有消息了比如说我们的管控组件的版本是否有对齐管控组件的配置是否有对齐密钥和设置是不是一致如果这些不一致就有可能在未来的某一天出现某种不一样的就是我们预期之外的错误另外在集群的应用程我们还需要关注破得的规格容器的volume 容器的时趋包括cmdbjvm参数环境辩量健康检查破的状态等等所以我们继续我们继续在多场景的多集群的场景下稳定性管控的复杂度会被放大然后我们接下来带来继续的两个预设第一在大规模集群场景下数据一致性的问题会预加的显现并且可能引发严重的故障成为一个显著的不稳定因素第五集群内的监控告警链路存在自一来风险如果集群故障则监控告警也有可能同时故障接下来我们基于以上预设的一些解决方案一 链路探测也就是模拟广益上的用户行为探测链路是否常通流程是否无异常一句话来说呢就是说你不须试一下你永远不知道你到底行不行哪怕你各个组建监控数据再正常但是链路该不通还是不同就像一个浑身肌肉的状态它能不能打看是看不出来了是打出来的就像这是一个业务发布的一个探测它就可以它的最终的显示的结果是一个喷冰破的掉不出来它的原因呢就是因为中间这条链路点断掉了然后呢其次是一个定向讯解所谓定向讯解就是检查和分析大规模集群的异常指标找到已有或将来可能存在的风险点就像检修管道一样比如说我们有若干个集群比如说我们有若干个集群它分为很多很多集群组然后不同的集群组之间呢它的etcd冷热倍是否配置配置期倍锋控线流配置是否正常workbook版本呢是不是正常混布参数是不是一致包括它的正数有效期是不是快要到期了是不是不到三年或者不到两年或者不到一年不同的集群组之间可能有所差别但是单集群组之间就是同类型集群之间它是有一个转衡的所以我们就可以去定向的做一些讯解接下来我们是关于链路探测的一些常见的场景就像一个游戏策划如果它连自己制作的游戏都不玩它可能发现游戏机制的问题吗把这个游戏做得越来越好吧我们要做到先于用户发现系统问题让我们自己首先就要先成为系统的用户并且一定是使用最多的了解最深的无时无刻不再使用和感知系统状态的用户另外所谓链路探测就是让自己成为自己系统的用户模擬广易上的用户行为去对集群组建链路中的各种等待探测的对象去做探测一定要注意这里的用户并不仅仅指的是狭义上使用系统的同学而是更广易的用户或者我们都可以理解隐身成为依赖下游比如说业务同学他要发布业务那就必然要经过Git系统再到发布系统再到我们的底层的计读设施平台也就是我们的ASI这就是一次全链路的一个探测流程在这里业务同学就是用户探测业务同学就是用户探测对象的就是我们的整个一个全链路包括我们的ASI但是如果我们把etcd看作一个系统服务那么APS Server也就成为了它的广易用户所以我们模拟APS Server请求etcd去做读写监听那么这条链路也就有了意义另外像MSI微服引擎它就操作出Keeper外部用户通过云控制台去创建ACK集群Pass平台操作联邦集群甚至视频的业务发起了一次转码任务这都是一样的道理还有一点要关注的是虽然全链路探测看起来很美但是很多时候全链路探测同时还是非常长的可能等到失败的时候问题已经很大了所以在实现全链路探测的同时拆解链路实现全链路中的短链路探测也是非常必要的也是对全链路探测的一个补充这是关于定向讯检的一些场景比如相比于那个链路探测关注于链路的可能性定向讯检的核心还是在大规模的进行场景下数据一致性是一个非常困难的问题数据不一致就有可能导致某些隐患可能会在未来引发某些不确定性的故障所谓定向讯检就是对整个集群链路中的各项数据指标做以之原因的检查找出不一致数据偏离的点判断是否可能引发风险从而做到防患于未然至未比比如我们这个里边有同一种类型的集群组然后A集群他发现他的阵数有效期不到3年而别的集群的阵数有效期都有3年比如说B集群他的Werpoek版本可能是V2而别的集群的Werpoek版本是V3比如说C集群他的风控线流配置并没有配一个驱逐破的线流但是别的集群他都配了这个驱逐破的线流那么肯定是不符合预计的比如说D集群他的ETCD的冷热背没有配置或者是运行不正常我们也可以先把它检查出来基于上面许许多多的背景预设以及方案我们设计并实现了一套询检探测平台我们取名为CoupperPro这里必须要说明的是我们这套系统并没有开源和现在社区上有类似命名的项目没有任何联系我们早期也曾经考虑使用过社区项目CoupperHealthy并为CoupperHealthy做过一些代码贡献修复过一些严重的代码败最终因为功能上可能不大适用于我们内部的场景因为我们的很多场景还是比较特殊而且群量比较大所以我们最终选择了自研制件首先第一种价格它是一套中型的价格我会有一套中型管控系统用户的用力它会通过这个进向仓库进向的方式来接入使用了我们通用的SDK库制定义询检和探测的逻辑和用力我们会在中型管控系统上配置好集群和用力的关系配置如某用力应该执行在哪些集群组上并做好对应的运行式配置我们支持周期触发手动触发事件触发比如说发布的时候它就会触发发布的后置检查等等用力的触发方式由中型端去统一的配置和调度执行用力触发之后会在集群里边创建一个执行询检探测的逻辑的破的这个破的会执行复询检探测逻辑并在成功和失败之后通过直接回调或者是消息队列一步回调的方式统治中型端中型端会负责告警和用力支援清理的工作我举一个例子比如Kubelet在我们的组建运为平台上做分批发布每批次都会触发一次相关集群的链路探测用力作为后置检查一旦我们发现某次发布的后置检查失败我们会阻断掉用户的当前发布防止伤害扩打同时第一时间告警以及通知相关同事进入排查是否组建新版本不符合预期同时我们也支持第三方的事件回调可以更快地集成进第三方系统之中另外对于某一些需要七成二十四小时不间断的高频次短周期探测用力我们还实现了另外一种常驻分布式架构这套架构使用了一个集群类的Probo Prater监听Probo CR的变化Probo Config CR的变化在探测POD中周而复始地执行的探测逻辑这套架构完美地服用了CruPro Probe中心端提供的告警 更衣分析 发布阻断等等附加功能同时使用了标准的Operator的云元身架构设计常驻体系带来了极大的探测效率优化探测效率优化和提升因为去掉了创建讯件POD和清理数据的开销基本可以做到对集群的七成二十四小时无缝覆盖同时便于对外集成另外还有一个必须要提到一个非常重要的点就是平台只是提供一个平台上的能力支持真正这个东西要起作用还是要看这个平台上构建的用力是否丰富能不能方便的让更多人进来写各种讯件和探测的逻辑和用力就像测试平台它是非常非常重要的但是测试用力它甚至可以说比测试平台更重要这个道理是一样的一些通用的Walkload探测组建探测固然能够发现很多管控链路上的问题比如说我们去建一个Department比如说我们去建一个Staple Set我们固然可以发现很多管控链路上的问题但是更多的问题呢包括业务层上的问题暴露呢实际上是依赖于基础设施和业务层同学的共同努力的从我们的实验上来说测试同学和业务同学也贡献了相当多的检查用力比如说测试同学贡献的ACK的创建删除全链路探测讯件金石确业务全链路扩容用力比如本地生活同学的PASS平台应用检查等等也得到了很多稳定性上的结果和收益现在我们维护的讯件和探测用力大概是有数十个明年应该会破百讯件探测次数是接近三千万次明年应该是会过意然后目前应该是可以提现发现99%以上的进行管控问题和隐患效果是非常好的接下来我们聊聊发现问题之后的事情这里有一个类似于问诊一样的对话患者他发现了问题他说我不舒服了这就是一个发现问题的过程医生参考了各种化验单同时做了信息聚合分类推断告诉患者说你已经24小时没有睡觉了你睡不着的原因是因为你非常的焦虑更因是因为后天就要期末考试了这个就是定位问题的更因然后针对这个更因去解决这个问题他告诉这个患者说不用担心我刚刚收到了消息小学生现在就不需要期末考试了所以这个问题就已经解决了这就是一次问诊的一个对话然后我们要注意的是这个过程一定要快越快越有效你有可能再拖个几天这个患者他就不知了对吧另外来自探测链路的高警内容往往是混沌的他和监控高警的那个链路是有所数据监控的那个链路的高警是有所差异的就像刚才我们说的链路探测的高警很有可能就是一句患者的我不舒服了需要你作为一个医生去做判断为什么他不舒服了更因是什么而数据监控很多时候他本身就代表了一定的原因比如说ETCD OOM他爆出来了那就是ETCD已经OOM了就是ETCD OOM用移有的航廓经验可能是来处理这种链路探测上的一些航廓的问题可能是得不到一个最好的效果的另外快速定位问题和更因分屎它是一个塑状的搜索经验加工和判断的过程也就是如何从一个馄顿的表象推荐出更因核心是逻辑这个和健康体检是不一样的健康体检是列出检查项1 2 3 4 5然后告诉你一堆数字很多时候即使存在了一个体检中心我们会去体检中心体检但是我们仍然还是需要医院的专业医生来为我们解读和判断病情所以说健康体检不等于更因分屎同时更因分屎问题治愈的关键在于专家经验的下层也就是把专家经验下层到系统里边去专家经验的下层带来的最大收益是什么是可付用 可输出你可以想一下如果我们把一个最专业的医生的能力放进系统里边去是不是更方便的可以更方便的为每一个人去分析他的病情这是一个我们苦入Prob的发现问题之后的全流程我们首先会经过一个我们自建的中心化更因分析系统就是如果探测失败之后它就会进入这个更因分析系统在这里我们会聚合分析所有和本事失败相关的信息包括事件 日子 变更 告警 组建升级等等我们会将这些信息做一些聚合分析并对事件做一些关联处理最终通过一个塑状的分析系统初步定位出某次探测失败的原因比如说APS为超时或者ETCD断练等等这里我还想补充一下其实文本联想也是一个很好的根语分析方式我们是可以通过知识学习训练文本识别的方式来联想出这种失败的case最关联的更因的原因这种AIOS的这种工作我们目前只是略加设计并没有在里边探索非常多还是在持续的一些工作当中我们的数据量非常的大我们有非常多的数据所以我觉得这个一定是我们未来可以做的方向之一下边是某一次我们失败的一个告警它经过了更因分析系统之后它发现首先最核心最关联最大的原因可能是APS-2的连接断开了并且当前已经恢复了所以可能是偶发的网络抖动暂时你不用特别关注但是你还是看一下这个制性度有90%另外还有一些可能的原因它都会关联起来比如说某一个组件这次探索它是由某一个组件发布出发的它的发布人是谁你可以观察一下这个发布是不是有对APS-2有某些影响是不是多次List of Watch不符合预期然后把APS-2List of Watch出问题了制性度有50%经过我们初步的定位之后我们会进入二次确认系统做二次的原因确认比如说我们初步定位出了APS-2超时ETCD断连节点故障调息异常等等等等如果APS-2超时我们二次确认过程可能就是再拉一次APS-2的接口看一下现在还超时不超时是不是恢复了如果恢复了我们就普通高情并且告诉用户现在没有事了但是你得关注如果没有恢复那这个就非常严重了我们就需要马上电话告警这个就是非常高约天气因为APS-2挂了就是这个失路如果系统有无法定位的问题的时候并且持续无法定位我们会去也会出发高级别的高级会同时我们会介入增加相关的更应分析识别数也就是更应分析系统需要升级了当我们多次这样做了之后我们就发现我们可以收连90%以上的问题我一直觉得过多的高警是等于没有高警的我非常讨厌那种高警海因为高警海会让人焦虑而且会让人没办法on-call从经验上讲我们构建了这样一套更应分析加20确认加后置检查的系统之后我们的on-call成本下降了90%以上并且还能够持续的下降中态可以说是无人之手大家也可以试试类似的工作可以说是小投入建销大自从这些系统建设起来了之后我们可以很自豪地说我们用很小的精力就可以on-call每一个高警条目真的是每一个高警条目数千个集群数千万只摊车的每一条高警都不会有遗漏最后的最后是一些给on-call人员的小甜品Chart-Ox我们利用了丁丁提供的NRPC机器人构建了一套比较完善的Chart-Ox系统这样之后我们就可以我们的on-call人员就可以很方便地在高警群里边通过聊天的方式操作couplepob相关功能了就比如说从跑摊车用力比如说查询机群状态拉取整男信息查询探测日制继续抓紧紧摸等等等等右边是我们操作他的过一个过程比如说晚上我已经在被窝里了然后这个时候告诉我来一个某一个高警说某个集群他之前出现了某些失败但是当前你回复了你可以关注一下那既然我关注一下我就希望他这个某一个用力某一个常用力他可能周系比较长是一个总统这时候我就希望这个常用力这个全链路的用力再跑一次因为短�路的用力他可能随时都在跑这时候我就告诉机器人说一个我再跑一次他就会语日识别我的语日然后去对这个机群再跑一次跑完了之后我再去通过查询状态看一下这个机群当前你状态怎么样了我们这样就可以方便有时候你晚上下班了或者是在路上或者是在被窝里边我们可以很舒服的去on call一个系统了然后最后一点点时间我来大致讲一个我们普通的一个Yes demo我大概截了一些图首先这是一个组件的发布这个组件发布的发布的最后一步叫后置检查后置检查会检查这个组件发布中的各种问题它后置检查到中间的某一个某一个hook就是用来调用couple pop然后这个地方就是它调用的couple pop的一些探测的一些列表当它触发了这个后置检查发布完成之后触发这个后置检查之后继续里边就会run through弱干的那个许念的pod许念的探测pod当这些pod执行完了之后我们中心端就会看到一个一个记录因为这个通过了然后它的那个整个日制是怎么样比如说它先扩容了扩容了一个那个节点词然后就扩容业务的cronet然后等到cronet等到2然后再下线cronet然后再下线节点词里边的节点如果探测有某些问题它就会告紧这个是更一分析和告紧的一个流程首先它主要原因是记录到当前app sorry已经线流了没有鼓掌你可以持续观察就是app sorrysorry一个普通的一个线流没啥大关系然后其他的可能原因就是说拉举破的成功就可能已经恢复了可能是app sorry压力大也是有可能的像这种问题我们一般会看了之后一般就不用太关注了因为它不是一个很很很很严重的一个问题同时很严重的问题一定会通过刚才的那套更一分析系统来电话告紧出来最后如果某一个职群它出现了某一种问题然后我们希望去做一些插tops比如说我们在外边吃饭或者是在上楼所我们就可以直接对对对对知识人做某些操作比如说知识人说某一个etcd它没有响应了然后这个时候我们先就把这个屏蔽一下屏蔽下之后我们进入排查不然它就有可能会造成一些高进风暴对了然后今天的分享基本上就是如上的那种谢谢大家的收听有什么问题的话可以待会问我谢谢大家