故障频发？看云原生如何成就体系化稳定性治理
基于实际的业务运维数据统计，30%以上的线上问题可通过稳定性治理提前发现并解决。
——网易杭州研究院技术委员会Core成员 陈谔
文章从云原生技术底座的建设规划以及遇到的挑战出发，介绍了云原生架构下面临风险时的预见洞见与异常事件的根因分析，以及网易数帆在云原生稳定性风险免疫体系的规划与展望。
云原⽣技术底座建设规划及挑战
而继承网易杭州研究院作为集团公共技术团队的经验，我们也认识到，云原生架构转型也不能毕其功于一役，在接入的应用场景增多，业务体量变大的情况下、考验云原生技术平台的成熟度以及配套的云原生应用规范落实情况息息相关。在支撑核心业务线的需求场景过程中，持续不断的优化完善考验着云原生技术平台的设计。
云原生化深度实践引出来的一些编码设计理念的变化，服务网格边车代理，甚至中间件有状态应用的云原生化已经成为较为成熟，成为了一种趋势。
网易在云原生技术转型过程中，经历了早期蜂巢容器化，之后从传统微服务框架演进到服务网格架构，形成双擎多模态的服务网格治理平台，以及基于Istio和Envoy的高性能云原生API网关Hango，从2019年开始尝试将中间件集群云原生化改造，建设了云原生PaaS化的中间件管理平台，2022年，在云原生应用的多中心多活，中间件集群联邦调度等方面建设也有了一些大规模实践。
同时我们也看到国内外频繁出现的云服务稳定性的问题，据中国信通院不完全统计，2021年国内外云服务宕机事件高达20余起。套用冰山理论模型，在咱们企业自身业务上往往存在更多同类问题已经发生或即将到来。特别是一些互联网服务场景涉及民生场景，往往存在不可预测、不可控、时效性高等特性。
从行业趋势来看，云原生底座在多个行业领域里都已经开始建设规划，互联网运营类业务大量投产验证进入了深水区，许多业务应用涉及普惠民生，一旦出现异常，会带来恶劣的社会影响。
在接入业务规模增长所带来的复杂性，排障追踪的困境，故障演练的有效性，对稳定性管控建设，都有极高的需求和要求。
由于云原生应用架构往往基于云计算基础设施，为应对这两方面的问题，我们思考是否能够将云原生的特性应用到业务场景上，用观测性、应用韧性、高可用性、故障自愈的能力消除不确定性对业务系统带来的影响。在网易数帆，从2022年开始，稳定性保障就是云原生演进规划中的重点建设方向。
云原生架构下的风险预见与根因分析
我们总结了内部的经验，学习和参考行业一些领先的实践，参与了信通院制定的稳保相关标准，对齐稳定性保障的目标，也就是降发生和降影响两个大方向，来增强云原生应用架构下的稳定性保障工具体系，应对复杂性和不确定性所带来的风险的能力。
降发生更多关注与事前通过持续巡检、风险评估、故障演练等将异常风险左移，引入时序模型算法实现事前风险预测能力，降低潜在的风险。进而可以动态指导系统架构优化和资源规划。
降影响则更多关注事后快速定位自愈，因此应用深度立体化的监控平台，在故障发生后能快速定位根因，在定位故障特征后可以采取兜底，摘流或自愈策略，把业务影响降至最低。
在稳定性建设过程中，我们梳理了网易内部的相关平台，惊讶地发现，仅在云原生领域就已经有独立团队持续建设的相关平台。包括服务治理、应用多活、可观测性、故障演练、根因分析、风险预见等能力平台。但是随着业务接入规模，业态增多，各个模块独立团队持续建设多年由于缺少体系化规划，发现能力碎片孤岛化严重，甚至存在重复建设。例如深度采集，有kprobe/eBPF多套实现方案；故障演练预案也没有能和根因分析专家诊断经验库对齐，导致故障演练效果大打折扣；例如服务治理该如何有效配置限流熔断降级的阈值规则，都缺乏横向支撑能力。因此，打破能力孤岛，能力整合，就成为我们的第一步目标。
从整个异常事件的生命周期来拆解已有的稳定性保障流程，可以分为事前事中事后，我们希望将不确定性尽量前置左移，也是许多专家们的共识。但是具体怎么做，却有很多角度。
我们将故障演练、全链路压测、引流回放、混沌工程、强弱依赖治理、模糊测试等能力应用在故障演练的多个场景。服务治理也是相对成熟的能力，常用的接口治理，服务治理、限流熔断的规则配置、以及服务鉴权认证、黑白名单的能力。
但是实践当中，我们在已有的质量保障工程，服务治理的能力之上，在面对一些故障场景时仍然无法闭环。比如故障演练的预案如何设计，通用的预案无法满足的场景如何解决？再比如这些都是之前已经建设的平台能力，但是治理规则往往靠感觉，依靠着弹性资源不断摸高测试才能估出来，那么是否有直接推测的办法？服务治理的规则如何设定才是有效的？每个服务、接口、方法的限流到底限多少？按统一的指标？还是各自拍脑袋？熔断治理的标准到底是什么？在监控告警方面也有同样的问题，告警依赖监控，如果监控不完善怎么办？告警该如何配，配置是否有效？在K8s环境中常见的资源、容量导致的调度异常占比很高，能否通过时间趋势计算产生无阈值告警，不需要人为参与配置告警规则，进而做到提前风险预警呢？
基于云原生架构的特性设计了一些新的模块，以满足应对事前降发生的风险预测能力、应对事故发生后的降影响的根因分析故障诊断能力，就成为了我们落地的目标。
在事前阶段，目标是提升系统稳定的时间(MTBF) ，也就是尽可能在不确定的环境中降低故障发生率，因此在架构规划、关键流程标准化的基础上，首先在通过故障演练的持续演练，配合有效的服务治理规则是基础的事情风险保障能力。此外，引入持续巡检，这里的巡检并不是传统的指标监控，而是覆盖关键的中间件配置、系统内核配置等和关键配置类指标，通过风险预见的时间模型算法，对业务系统的容量、安全、性能、架构多个维护进行评估。
在事中阶段，主要的目标降低系统不稳定的时间 (MTTR)，就是发生故障之后能够尽可能快速的定位根因，降低影响范围，快速止血。由于原有监控体系存在孤岛，基于agent的、eBPF的、exporter的来自不同层面的指标日志数据可读性差，出现问题需要排查多个系统，更有甚者还会出现由于无法观测而不了了之的现象。因此这个阶段首先需要通过元数据关联，基于各层级的链路指标绘制多维拓扑，建设立体化监控平台作为可观测能力支撑。
然后针对观测到的异常事件，自动联动调用根因分析流水线，诊断OperatorSet会根据事件特征，在专家经验库进行规则匹配诊断根因。我们分析实际故障场景其实存在大量的类似的故障，而排查和恢复的工作也相当雷同，我们总结了网易内部DBA、SRE资深老专家的经验，持续完善经验库。在发现无法覆盖的场景，也尝试训练运维诊断模型，最近也尝试集成了AIGC技术，将故障特征提取脱敏后进行辅助分析辅助决策。
在云原生应用架构下，因此故障自愈方面，我们需要使多中心多活容灾策略可以有效切换，当然这是另一个相当大的主题。实践当中基于云原生K8s运行的无状态应用有足够的弹性调度，容错自愈的能力，使用最常见的calldown自愈规则能够应对大部分的故障场景，但是在有状态的中间件缓存故障以及服务网格数据层面的故障时没有那么方便了，因此我们专门设计了基于云原生服务网格和中间件场景的故障兜底路由和中间件集群联邦调度能力保证云原生技术底座的自愈能力。
根据前面的需求场景设计，我们围绕着针对风险异常的演练、触发、分析，形成有效的“察打一体” 为目标，横向对齐多个基础技术团队的稳定性保障平台，覆盖云原生稳定性保障的核心场景。提供的保障能力主要拆解为3个能力域， 事前风险预见，事后根因分析，以及支撑能力域立体化监控。
下面我们主要从这3个领域来拆解，分享一下实践思路。
首先站在“可观测性”的角度，虽然各种云服务极大加速了应用迭代，以Docker、Kubernetes为代表的容器相关技术使得应用的运行环境进一步虚拟化，同时微服务化也在分布式的基础上进一步对应用进行拆分。以上的所有技术趋势在加速业务创新的同时，带来了应用复杂度的指数级上升。
从传统APM采集的链路、指标、日志的无法覆盖所有场景，往往是知道了故障的现象，但是无法的定位根因，更有甚者是部分故障都无法观测到，也就无从排查，缺少关键节点的指标支撑。就好像做体检缺少了CT，遇到问题需要SRE、DBA专家凭借经验人肉排查，排障成本高难以标准化。
相比较传统的APM，立体化监控平台在回答应用是否有问题的同时，需要关联应用相关的各层的指标、链路、日志数据快速指向影响应用稳定性的根因，甚至能通过深度指标关联配合时间模型算法 预测出可能出现的异常风险。
立体化监控和传统监控的能力区别，主要在于深度采集指标的支撑，例如应用层监控，基于SDK/agent字节码增强技术，采集应用层调用链黄金三指标等。
而为了保证监控观测的深度，内核层主机层的指标，往往采用基于eBPF内核插桩采集的内核网络指标，配合K8s下的自研exporter采集的经验指标。这个阶段主要的问题是，指标膨胀非常剧烈，许多内核深度指标相当晦涩，可读性差， 依赖专业人员的判断。因此，我们需要把深度指标场景化关联。
我们选择打通横向（链路追踪指标）和纵向（下钻深度指标）之间的关联，通过事件、时间将多个层级链路指标日志绘制多维拓扑，通过时序统计模型进行拟合支撑关联分析和风险预测。
因此，我们整合了应用性能监控APM、以及云底座的包括主机采集哨兵平台、融合内核指标采集eBPF、K8s指标采集工具链Kube-insight 等平台，形成立体化监控平台。以此作为支撑事前风险预见和事后根因分析的基础支撑能力。
有了立体化监控的数据源作为支撑，基于巡检工具进一步优化，实现风险预见，也称为insight，可以解决实际环境中存在的一些典型故障的趋势性异常，即这些将来可能出现的故障当前还未触发， 或是已经触发了但是因为Pod自动重启、业务重试等原因自动恢复，并未影响实际业务SLA。
风险预见本质上是一套巡检引擎，根据典型故障的特征形成特定的巡检规则，引入时序算法模型，来预测趋势未来可能出现的问题。实践过程中，由于同类业务系统例如Java的业务同质性很高，尤其是典型问题编码不规范导致内存泄露，FGC等问题，有明显的特征可以识别此类风险。
我们就列举这个Pod内存持续增长的典型的场景，这个截图是风险预见提出来的一个资源类的风险报告。
这个案例中，我们通过统计学算法从监控数据中提取服务内存使用情况的特征值，排除Pod重启的影响，检测服务Pod的内存在持续且缓慢地增长。由于内存属于不可压缩资源，服务内存需要占用真实的物理资源，虽然没有实际触发业务异常，预测未来可能发生OOMKill的情况。
最终给到运维人员风险报告，会详细说明计算经过，容器内存使用量，Pod上次终止的状态，服务在K8s上的资源配置，以及预测风险可能发生的时间，以及相关的排查建议，并附上监控图表。
我们认为，这是可以提供给业务、运维人员具备可执行可改进的风险报告和改进建议。
这里是一些风险预见能够辅助支持运维运营进行风险预见的型场景，包括服务调用缓慢、服务响应抖动、服务内存分配失效等。
前面阶段我们建设了立体化监控采集云原生应用及K8s的深度指标，但由于指标晦涩复杂，可读性差，整个排障过程仍然需要大量依赖专业SRE、DBA老专家介入诊断。通过分析运维工单排障工时的构成，我们发现其实在云原生场景下大量的人工排障诊断工作都是重复劳动，云平台的自动化工单平台本身就是一个将经验自动化成工具脚本仓库。因此下一步的建设目标，我们将着眼点聚焦到，如何将老专家的人工分析经验固化成自动化诊断分析工具，通过历史故障场景的梳理，识别异常事件、故障的特征，形成诊断经验库，通过核心事件捕捉后，Operator触发相应的排障脚本，自动检索，并自动推送预案或自动化执行。
我们基于网易内部DBA、SA、SRE老专家们大量的运维优化经验，将80%以上故障场景的重复排障流程，和指标特征进行了梳理，形成了专家经验库。
这里分享集成专家经验库的根因分析平台下的应用案例，来自实际业务的两个典型场景。
案例1：K8S Pod异常分析
立体化监控系统发现Pod异常告警，随后业务反馈滚动发布一直无法完成，待删除的Pod始终处于Pod Terrninating状态。研发人员已经根据经验排查了常见的一些原因，但仍然无法解决，初步推断可能是系统或者集群层面因素导致的。
我们通过平台对异常日志与已知容器Bug的匹配发现：(1) Pod历史上新建文件比较多，基本线性增加，但是删除很少；(2) 主机Dockerd当前CPU利用率高，大量执行Unlink删除文件；(3) 未与已知的Bug匹配等。经过分析推导结论为业务创建文件过多一直未删除，在最终清理容器的时候一次性删除，导致耗时很久。随后业务方优化文件清理策略，后续问题彻底解决。
这个分析排障带来了一个额外的价值，就是一般监控只关注内存泄漏，fd泄漏，而对于临时文件不清理的泄漏关注得比较少，一旦遇到了就容易束手无策。
案例2：容器性能瓶颈分析
另一个比较典型的场景，就是通过主动巡检来辅助分析。我们曾在压测过程中发现部分节点上的业务处理能力达到瓶颈，而部分节点上的业务正常，所有业务的启动配置均使用相同参数。我们初步怀疑，是系统环境原因造成的。
我们设计了手动事件触发的方式，通过手动触发执行诊断流水线对系统配置进行扫描和Profiling，对整个K8s集群环境中的标准化参数进行比对。分析后发现该问题是由于节点上文件数等参数配置不合理造成，给出诊断建议：解决Docker启动参数中的 LimitNOFILE、LimitNPROC 参数不一致的问题。
对于稳定性平台在云原生环境中的应用场景，除了无状态的微服务，我们也在较为复杂的中间件类型应用进行了验证，因为Redis、Kakfa、Elasticsearch等有状态的中间件集群的异常往往是影响SLA的源头。
首先针对中间件集群的运行状态、配置规范性进行事前巡检，如图中案例就是基于DBA团队的Redis配置规范，发现了Redis集群中键过期策略配置有问题。
事后针对异常特征进行根因分析，如图中是一个典型中间件异常事件，Redis内存使用率超过80%，我们通过根因分析诊断发现，是Redis集群配置不规范导致的大key风险。
云原⽣稳定性⻛险免疫体系规划与展望
此外，我们也尝试在多中心多活架构设计层面，故障发生后，能够实现大规模流量迁移，特别是对业务接入层和服务层有较多的路由分发策略的适配工作，应用多活也是一个挑战很大的主题，这里就不过多展开。
最后用一张图来总结一下云原生架构下的稳定性保障建设路径。
整体来讲，云原生分布式技术为我们带来的敏捷迭代支撑业务发展的能力。但是基于云原生架构能够额外提供的可观测性，故障自愈能力是被低估的，基于云原生的特性来增强业务系统的稳定性风险保障能力，为接入后的业务提供事前风险预测，事中故障感知自动根因分析，快速止损，事后故障改进追踪能力，实现稳定性建设目标。
云原生稳定性保障的核心价值——可以理解为一套完整的稳定性免疫系统，通过故障演练，将Chaos作为疫苗工厂，稳定性保障平台则为免疫系统；抗体的组成，就是一系列的监控和运维专家经验，加上整个编排、流水线执行系统，我们通过持续巡检，故障演练工具让抗体越来越成熟，使专家规则不仅在特定的互联网大流量业务下有效，也能复制到不同的行业业态中持续发挥风险免疫的作用。
作者简介
朱剑峰，网易数帆云原生资深架构师， 主要负责云原生技术在互联网及金融领域业务的应用实践，以及云原生技术底座平台的设计规划工作。