将着重与大家分享我们SRE团队改造的背景和实施路径，以及我们SRE系统的框架和思路，以及也会提到个人的一些思考。我们一开始并没有设计出整个框架的思路，而是面临着很多问题，围绕着解决这些问题一步步演进。一、云原生运维改造1、业务背景如果玩过游戏，应该对这个界面不陌生。我们的团队主要负责腾讯内部游戏营销活动的运维支持。线上营销活动除了为玩家提升游戏体验外，还为游戏项目组提供相关的营销活动和运营活动，吸引新玩家、活跃起来，甚至购买道具。和其他商业支持。2.微服务架构这是我们的一种技术架构。从这个技术架构上可以看出，云原生已经成为了大趋势，我们团队95%以上的人都实现了微服务。微服务改变了开发的交付方式，同时也给运维带来了巨大的变化。我个人的感觉是，挑战大于变化。以下6点是我们现阶段面临的最大挑战：1）微服务调用链错综复杂，难以理解，尤其是一些大型活动，需要多个团队协同开发，会涉及数百人微服务相互调用，整个微服务拓扑结构非常庞大，理解框架也比较困难。2）跟踪、指标、日志数据的上报标准不同。每个团队都搭建了很多监控平台或者解决方案，这也是由于一些历史原因造成的。3)无法快速定位业务问题及根源。由于多个团队共同开发大型营销活动，当出现问题时，需要对整个项目链中涉及的所有开发和运维团队进行单独检查。指标监控系统逐步定位问题，势必会拉长问题的整个排查和解决周期。4）上线前难以发现服务性能瓶颈。服务性能瓶颈的发现和处理相对滞后。通常是上线后才发现服务炸了，比如计算资源不足，存储节点IO高，调用下游接口延迟过大等。一系列的问题。5）无法判断节点之间的强弱依赖关系。比如模块A访问模块B，当模块B出现异常时，会影响到调用方的模块A，但是影响的程度无法判断？6）无法准确计算新上线业务能力的评估。当业务在线时，我们无法判断应该给多少服务能力。通常，为了安全起见，会虚报产品运营计划，从而导致运营成本的增加。3、环境的变化如上所述，我们面临着几大问题。接下来说说大环境的变化：2018年腾讯930改革后，公司明确内部业务自研上云。4年多之后，团队面临着两个挑战。主要变化：一是作为公司内部第一批上云团队，我们已经完成了95%的流量上云。在云原生环境下，运维模式也发生了变化，不同于以往的传统运维。模式的区别体现在以下六点：1）资源→资产在传统的资源管理中，我们通常在CMDB中记录设备的IP、性能配置、设备负责人等元数据信息，而资产在云在现代化模式下，它的范围和边界都扩大了，不只是单个设备的信息，它可以是一个负载均衡器，一个MySQL实例，或者任何云端的PaaS服务，我们都把它当作一种资产治疗和管理。2）Monolith→Microservice单体服务的微服务使得服务的治理更加细化。3）管理→治理我认为管理是一维的，而治理是多维的、多维度的。模式发生了很大的变革。4）事件驱动→流水线过去通常是开发提交变更单，运维跟进并发起变更。如果发生异常，它会迅速回滚。DevOps流水线之后，处处实现自动化，从而实现谁开发谁运维的理念。开发可以随意发起更改。一个项目一天可能发起几十个变更任务，效率很高，不再依赖于事件。驾驶。5）DO分离→DO融合以前开发和运维互不干扰，因为有“墙”保护，没必要互相指责。在云原生的背景下，我们要求开发和运维尽可能的融合，也是遵循DevOps的思想。6）业务运维→SRE也对传统业务运维能力提出了更高的要求。除了基本的运维能力之外，还需要扩展能力包括业务理解、工具开发、数据分析，甚至AIOps，也就是我们理解的SRE。第二个变化是整个云原生浪潮中业务研发的转型，包括使用云原生架构实现版本交付。基于一站式DevOps平台，打通研发线的全生命周期管理，贯穿开发和编译的服务。、构建、部署等，实现服务交付的全闭环。此外，还会涉及到版本所需的质量监控、配置和容量管理、日志检索等研发功能，能力非常全面和完善。4.触发转型从上面提到的两大变化来看，作为运维团队的负责人，客观来说对我和团队的影响还是很大的，因为我们是第一批自研的项目在腾讯。云，目前98%的业务已经运行在云上。在这个过程中，我发现我们过去构建了非常完整的传统运维能力，其中很大一部分已经不适用了，包括业务版本的发布、变更、配置管理、流量调度等。、监控方式等；可以看到，运维的很大一部分功能和价值被稀释了，具体体现在系统上云后的运维、基础设施管理、平台PaaS服务维护等功能上。;也逼着我们转型是必须的，也就是转型成云原生的SRE。下面将着重介绍为什么做出这样的选择。综上所述，更贴近业务，更懂业务，实现高可靠保障，提升用户体验，做更专业的运维。比如智能运维。那么如何转型，转型之后要做什么，就是我们接下来需要思考和实践的。2015-2016年左右开始接触SRE，也了解了SRE的一些思路和具体实践。在国内应该算是比较早的一批了。2020年，我们将完成所有业务上云。在这个阶段，我发现了SRE的好处。这个想法很符合我们面临的困惑。经过反复思考，很多想法确实可以解决我们的很多问题，所以我们确定SRE是我们转型的方向。以下是个人对未来运维功能的演进和转型路径的总结。随着云原生技术和架构的不断成熟，势必会带动IaaS、PaaS和DevOps的生态向成熟发展。但是这些方向的发展必然会对传统运维产生很大的冲击，包括系统运维、平台运维和业务运维。这三个岗位都会被削弱，即使不被削弱，大部分职能也会转移到运维外包或者业务研发上。在这样的背景下，我们的运维如何自救？我在这里给出了一个转变的路径。我个人判断一共会经历三个阶段：1）第一阶段：CloudOps（云运维）。云运维其实和传统运维没有太大区别。魏转战云，同时负责云资产采购、环境部署、日常运维等工作。同时，它也关注成本。例如，FinOps关注云的成本。2）第二阶段：SRE将在SRE中保留两个职能：一个是高级运维，保留最专业、最有能力的运维职能。二是工具开发。当很大一部分运维在转型的时候，具有一定开发能力的运维会转移到SRE工具开发的功能上。3）第三阶段：ServiceOps（运维即服务）。在这个阶段，更多专业的运维能力会被打包成服务，交付给企业内部的其他职能团队。专业服务包括SRE即服务和安全即服务。服务、数据即服务等，这些平台或服务都具有一定的智能属性，这是最基本的要求。然后在企业内部进行跨团队赋能，比如对研发团队、测试团队甚至财务团队进行增值赋能。我判断很多公司会在3到5年内进入这个周期。5.目标设定上面说到运维转型的路径，可以看到我们目前处于第二个阶段，即云原生SRE。我们为自己设定了几个核心目标。在团队的计划中，我要求以下5点可以做好：1）服务全链路质量覆盖，定义可量化的SLI和SLO，没有任何盲点。2）提高MTBF（平均无故障时间），降低MTTR（平均修复故障时间）3）将DevOps升级为DevSecOps，关注云成本（FinOps）4）具备多云、多层次的资产编排和治理能力第一，可以提高效率；二是让配送更加规范。比如业务出海，国内的交付能力可以快速复用。这些能力可以沉积在各种布局模板和脚本中，并且可以结合版本管理来追踪变化的细节。5）具备一定的故障预警、根源分析、问题定位能力，通过智能化水平提升我们的质量能力。精炼的中心思想是云上万物皆可编排，再加上我们“三位一体”的可靠性保障体系，这两个方向构成了我们第一阶段的总体目标。6.SRE8指南有了目标之后，我们还需要一些指导原则来告诉我们要做什么。这里我也提炼总结了8点，我们内部称之为SRE8guidelines。今天重点说说核心的三点（蓝框）。其他更多指南可扫描右下角二维码查看。二、SRE工具链建设思路1、SRE系统全景图这是我们的第一个能力全景图。SRE能力主要集中在中间层，包括多级事件编排、MTBF和MTTR。在内部，我们称之为“玄途SRE”系统，并规定：1）事件编排事件编排的最低要求是支持多云，因为我们的业务是跨云的，很多业务部署在北美和东南亚，所以我们需要支持跨云编排。资产编排要求我们能够跨云交付和自动化资产。容器编排主要是k8s工作流的机制。Jobarrangement即任务编排，对容器、虚拟机或云主机进行一系列的功能操作。2）MTBF是平均无故障时间，如何提高MTBF？关于MTBF，我们希望越长越好，为了实现这个目标，我们以前在业务上线前做的前期工作很少，一般都是等问题出现了再被动定位，所以我们尽量按照目前我们面临的实际情况，我们认为混沌实验&全链路压测是现阶段首要构建的能力。3）MTTR是修复故障的平均时间，如何降低MTTR？MTTR追求的目标当然是越短越好。这里我们拆解为故障发现、响应、定位、解决、验证五个环节。同时，我们分析了过去一年团队的数百个故障案例，发现MTTR被拉到最冗长的环节是故障定位。所以在这个阶段，我们就围绕这个环节来做文章，这也是我们着重构建可观测能力的原因。2.底层组织逻辑下面说一下实现这些能力的底层逻辑。首先，解释一下底部。我们将定义SRE中的标准规范、方法和目标。相当于在做上层平台之前，把整个理论体系的基础梳理清楚。实例化。对于中间层的平台化，大家看到的可能是三个独立的平台能力，但是我们把它看成一个整体，相当于把这三个能力构建成一个能力体系。因为我们在实践过程中发现，三种不同能力的任意组合都可以延伸出不同的玩法：可观察性+全链路压测，可以对资源做出精准的评估。可观察性+混沌实验，可以做强弱依赖分析。全链路压测可以作为混沌实验的原子压测。因此，可观测性、混沌实验、全链路压测不是孤立的、独立的，而是一个整体。它们之间可以相互关联，可以产生一些意想不到的应用场景，还有很多有趣的地方。积分等着我们去挖掘。三、SRE工具链搭建实践1、可观察性实践我们接下来要讲的第一个应用就是可观察性。举个很简单的例子，就是我们运维在处理故障时经常遇到的一个典型流程。通常我们接到报警，首先肯定是看Dashboard中哪些曲线图表有明显的异常，然后找出异常在某个时间段内的具体表现，是否是周期性的，是哪个指标发生了异常，则转入下一步链接跟踪，分解这个时间段，某个接口和方法是否延迟或报错，通过跟踪定位。最后一步就是通过日志分析来分析这个函数方法异常的根本原因。定位后即可解决问题。作为一个普通的运维人员，我经常会按照这个套路来定位和解决某个问题。整个过程中使用了指标、日志和跟踪三种能力。事实上，这三种能力构成了可观察性的三大支柱。指标：提供服务性能、业务和运行指标异常告警和可视化报表。Tracking：分布式链接跟踪，记录请求跟踪路径，用于定位特定的服务或方法。日志：服务日志，提供准确全面的系统记录，用于定位问题根源。许多团队分别构建这三种能力。比如指标通常会构建一个Prometheus采集指标，日志会构建一些日志采集组件，在ELK中进行检索。tracking是用Skywalking或Jaeger等工具构建，然后检索整个链路拓扑等。但是observability需要这三种能力的融合，即通过一定的symbol和特定的ID，将这三种能力串联起来形成一个整体，这是可观察性所追求的目标。1）系统架构这是我们的可观测系统技术架构。此架构可能不同于其他行业解决方案。共同点是我们也是基于Opentelemetry完成业务端，采集，上报，传输，计算，存储，应用。一系列的流程，但是我们会把重点放在综合治理上，后面我们也会提到，我们会支持很多治理能力，因为我觉得任何一种服务都需要进行治理，没有治理就不能很好的使用和其效能得以发挥。2）平台能力以下是我们的一些平台能力，包括基础能力和一些我们比较满意的高级能力。全面管控我们目前服务日PV超过7000亿。如果我们全量报的话，可能和业务访问的流量是1:1，甚至更大。我们的最终目标是通过可观察性提高高可靠性，但如果它带来的额外成本抵消了我们带来的价值，那就不合理了。所以我们会做一些控制，比如一定比例的采样，也会做一些操作上的干预，比如当流量达到某个峰值的时候，如果这个时候还开启大量的数据采集，那么可能会对业务造成很大的影响，所以我们需要采取熔断机制进行干预，以保证业务服务的稳定运行。ONE-SDK我们将指标、跟踪和日志集成到一个SDK中以进行报告。目前Opentelemetry官网只是建立了规范，还没有完全实现三者能力的融合和上报。一些开发语言SDK可能已经支持了，比如Golang，更多还在内部联调测试阶段。为了提高收款投资回报率，我们将启用收款管理和控制。当出现极端情况时，我们只收集有价值的数据，比如只收集异常数据，不收集其他数据，因为异常数据可能占不到1%。部分很小。3）综合治理我们的综合治理分为抽样治理和运营治理。①抽样管理头部抽样：在入口处开放抽样，只抽样自定义比例，如2%或10%。尾部采样：先全量上报数据，将数据缓存在缓冲池中，然后处理异常，过滤掉异常数据再入库。冷热数据分离：考虑到后端存储成本高，我们实现了分级（三级），比较热的数据存储在ES中。我们使用Clickhouse作为一周以上数据周期的二级存储，存储1个月以上的数据。我们将数据存储在离线数据仓库中，因此成本越来越低。②运维治理更多的是数据采集干预的手段，比如熔断、降级、限速、染色等。染色是应用特定的标签并定义染色数据的报告规则。比如我只关注某个玩家的登录，然后输入玩家的ID，它只会收集玩家整个生命周期产生的日志，不会收集其他的。下面介绍我们如何实现综合治理。我们使用OpenTelemetry的Collector来实现它。Collector内部有4个核心组件：Receivers：负责接收不同格式的观测数据，包括Zipkin、Jaeger、OpenCensus和Opentelemetry格式。Processors：负责实现处理逻辑，如打包、过滤、修饰、采样等。Exporters：负责将处理后的观测数据以指定的格式重新导出到后端服务。扩展：使用旁路模式作为收集器自身的健康心跳检测等。使用这些组件组装一个或多个Pipelines。这里我们集合了Agent和Collector这两个角色。Agent主要用于接收上报信息。在处理器中，使用了更多的headersampling、fusing、downgrading、limiting等功能。速度、着色等处理，处理后将数据写入Kafka；数据在后台被采集器消费后，我们在采集器中实现了尾部采样、自动补链等逻辑。4）异常检测当我们在采集大量数据后检测到异常点时，我们需要定义告警。很多情况下，会出现指示灯毛刺等故障特征，但实际上并不是故障。为了减少误报，我们结合AIOps技术做了一些探索，并取得了一定的效果。具体思路是这样的：我们收集最近几分钟的Trace和Metric数据，使用训练好的模型推断异常权重，然后通过识别出的异常Trace发出告警，所以可以看出我们的特征模型是很重要，那么如何保证这个模型的准确性呢？有计划供大家学习。我们分为两个阶段：第一阶段是测试阶段，结合压力测试和混沌能力，在源头做流量压力测试和混沌实验。我们模拟CPU吃饱、异常流量或丢包等已知故障原子，结合压测手段，观察服务显示的各项指标数据。这就是我们想要的功能。通过平台自动标注特征可以释放大量人力参与此类工作。但是，再完善的测试环境，也无法在线模拟所有的问题，比如一些我们历史上从未遇到过的未知问题。因此，在第二阶段（即将上线），我们会从现网收集真实数据进行验证，不断扩充和修改特征模型，让模型越来越准确。但是在生产环境中，不可避免地要依赖人工检查Tag。我们使用MatrixProfile的算法。在此之前，我们也统计了业界十几种Trace的异常检测算法，从推理速度、准确率、参数调整可变性等维度进行选择。我们发现MatrixProfile这个算法最接近我们的需求。MatrixProfile的值表示子序列之间的距离。距离越小，序列相似度越高，距离越大，越异常。异常与我们的警报有关。我们目前设置的准确率可以达到83%左右。2.混沌工程实践混沌实验已经被很多公司引入并积极构建，大多是通过模拟真实的网络故障注入来发现服务是否存在异常或者薄弱环节，但我个人认为它的好处不仅限于此，对于就SRE而言，其价值在于一句老话：平时多流汗，战时少流血。我们通常会模拟大量的故障案例，可以从容面对故障，不会惊慌失措。我们在预防、发现、响应、定位等方面积累了很多经验，从而能够快速处理和解决问题，我想混乱的意义应该在于此。1）平台架构这是我们的整体架构。这部分我们和社区合作比较多，比如PingCAP的ChaosMesh。我们也参与了共建，开放了这么多原子，平台能力也很成熟。基本上我们使用的是对上面的编排、钻取、模板等一些能力的封装，官方还自带了一个简单的管理终端，如果要求不高可以直接使用。2）平台能力这是我们的平台能力，分为基础的和高级的。我们平时做的最多的就是红蓝对决。红蓝对抗就是通过攻防不断验证可靠性是否满足要求。有些依赖于分析等能力。我认为对服务优势和劣势的分析非常有价值。很容易感知到，如果A转移服务B，B出现问题是否会影响到A。我们分三步实现：首先，基于可观察性技术，跟踪服务上下游依赖关系。然后向下游服务注入故障，如丢包、超时、响应慢等。最后观察调用方的稳态指标，如QPS、时延是否受到影响，如果受到影响，则有一个强弱依赖，需要开发去修改，比如在调用方做一些访问DB缓存等策略，满足要求后才能上线。3.全链路压测实践最后一个是全链路压测。我觉得它的意义主要有两点：一是上线后能够发现性能瓶颈，因为导致性能瓶颈的因素有很多，比如环境、参数配置不当、数据库、网络等，它是成本太高，无法一一检查，可以通过压力测试发现。二是主要节点的运行保障。容量和负载之间没有线性关系，无法准确判断容量是否足够。你可以通过压力测试知道。1）平台架构这是我们压测的架构。与传统压测不同的是，传统压测只是制造压力源，而当受压服务出现问题时，无法定位具体发生的接口、方法或调用。问题是压测服务是压测平台的黑盒，需要自己开发和定位。这是传统压力测试所面临的问题。我们的解决方案兼容传统的压力测量能力，即流量压力的创造。同时，结合可观察性能力，我们可以检测出整个拓扑中所有环节中的每一个环节、每一个接口、每一个方法、每一个函数的性能瓶颈。可快速定位告警，并进一步跟进，从而快速定位具体的性能瓶颈，并具备下钻分析异常根因的能力。2)平台能力3)业务压测链路拓扑下面说一下全链路压测的一个应用，即业务压测链路拓扑。我们对源头施压，平台可以完整呈现整个观察环节，展示微服务之间的调用关系链，同时实时计算每一层微服务的黄金指标，即时间-consuming,QPS,delay,and放大倍率等等都可以计算出来。放大倍数可用于业务上线前的资源评估。比如链路中的某个节点B放大了5倍，那么可以知道存量为20000核的资源需要放大5倍才能满足要求。未来版本上线时的资源需求。4.总结最后总结一下SRE实践中的几个过程。从项目立项到项目完成，我们在技术和文化两个层面进行落实。1）项目立项：我们会临时组建一个FT团队，包括运维、开发、测试、产品等，运维也会参与技术方案的讨论，定制可观测性报告规范。2）开发：开发需要执行运维制定的规范，上报指标嵌入点。同时，SRE将参与技术架构的评审。3）测试：这个阶段我们会做大量的混沌实验和全链路压测。4）上线：多关注SLI、SLO等指标及其误差预算，OnCall机制是否完备，提前做好故障预案。5）项目总结：回顾总结整个项目从立项到下线的优缺点，积累经验以便复制到下一个项目中。同时，我们将继续完善整个链的SRE工具Panorama。Q&A：如何在全采集和样本采集之间找到平衡点？A：全量采集和样本采集没有区别，跟业务场景有关。其实我们还有一个项目是需要全额的，因为对账需要所有的样品。但除此之外，基本上都是按照一定的比例来做的。一方面，可能需要和业务商量合适的抽样比例，因为我们无法判断是5%还是10%。没有标准，可能早期我们跟研发做projectreview的时候，这个比例其实已经谈妥了。另一方面我们在入口做全量，后端做尾的比例比较高，大概40%左右，也就是入口全部放出来，但是真正的数据不会全部落地后端，只有1%或没有。到达。我觉得tailsampling是有价值的，因为它只是过滤掉异常的，错误的，或者失效的链接等，抓取这个tag保存下来，那么数据量就很小了。但另一种情况是，当一个项目刚刚启动或不同类型的活动和项目需要获取其特性时，相当于前期要求全额，后期关注成本，然后慢慢降低，所以我们把它分成不同的阶段，并调用不同的策略。
