【万字长文】腾讯云新能源汽车客户-混沌工程实战

10月27日，对售后服务经理来说又是一个不眠之夜。腾讯云汽车行业某头部客户的智能化应用--车联网业务故障了60min，期间APP功能完整性、蓝牙钥匙解锁失效；车机的音视频、导航、天气等周边服务不可用。

智能化是新能源汽车产业发展的主流和趋势，车联网业务是其中十分关键的一环，客户对此业务的安全性、可用性十分重视。所以针对此次故障，客户的运维联系腾讯云售后团队，一起做了深入的复盘，一致认为云防火墙产品、客户侧的高可用措施都是具备的，短板在应急体系：当不可避免的故障发生时，应急预案能否成功兜底，大家都没信心。

如何在没有故障时，尽可能贴近真实的验证应急能力呢？我们推荐了混沌工程这一利器。介绍了腾讯云的混沌工程专家服务后，客户当即和我们组成了联合项目，在云防火墙上，实施混沌工程。

经过了两个多月的协作，我们从腾讯云角度、客户业务角度，讨论制定了混沌方案并付诸实施。最终有如下提升：

1、客户的长、短链接场景都更好的利用了腾讯云高防产品的安全能力

2、客户对车联网业务的故障处理时长从60分钟降低到最低4min

3、客户具备了将混沌工程在公司内推广的能力等。

看着如此全面的提升，我想客户对自己核心产品--智能化业务的稳定性信心回来了。。。

1. 客户侧挑战

根据与该客户的沟通，在此场景实施混沌工程，有以下痛点：

1）合作时间窗口小

非自上而下的客户界面联合项目，极易受客户的工作安排影响，导致实际时间窗口很小。就需要我们的混沌方案，在充分覆盖目标系统的基础上，可以把最重要的事项优先执行以取得客户信任。

2）对混沌实验影响敏感

主要合作对象是客户运维，而运维只是客户公司内一环。如果混沌实验造成了较大影响(包括测试环境)，那么整个项目就面临无限延期的可能。

3）实验的长期性

混沌实验方案可重复执行，可长期对系统的能力保鲜。

2. 解决方案整体设计

2.1 业界方法论分析和对比

业界针对混沌实验的设计大概有三种流派：随机注入、专家模式、LDFI。

业界的这几种方式，在腾讯云客户服务的场景，都不符合要求，因为既没有在短时间内帮客户解决客户的诉求，也没有体现腾讯云专家的价值(如下表)。

最终结合对腾讯云产品深度理解、腾讯内丰富的混沌经验、业界的先进经验，输出了《腾讯云专家模式》的方法进行混沌工程建设。

各设计流派对比情况如下：

2.2 腾讯云专家模式具体思路

• 通过全面分析系统(明确目标系统、系统弱点探查)，梳理出最有价值的实验项，弥补时间窗口小的问题
• 基于混沌工程原则设计混沌实验、Gameday设计，最小化混沌实验风险
• 单次实验的报告复盘、持续迭代来提升实验的长期性

2.3 腾讯云专家模式流程图

---

长文预警

下面行文分为两部分：混沌工程设计方法论(3.混沌工程设计方法论)和基于方法论的实战(4.某新能源汽车云防火墙混沌工程实战)。

逐段阅读可深入理解笔者的设计理念并通过实战加深理解。

喜欢看实战的读者可直接跳过方法论部分，先看实战是怎么执行的；然后带着问题再看设计理念，相信也会有不一样的收获。

---

3.混沌工程设计方法论

3.1 目标系统分析

无论要在单组件实施混沌工程，还是在多组件实施混沌工程，他们都服从于一个大前提：目标系统的SLA。

组件可用性能力最后支撑了目标系统的可用性能力，组件应该具备什么能力是目标系统决定的。

所以妥善分析系统边界、组成部分、主要特征、能力要求，然后把这些元素细化到该系统的具体研究对象，是混沌设计的第一步。

3.1.1 系统的运行环境拆解

一个系统运行，可能有如下依赖项：

1. 互联网基础设施：DNS、HttpDNS、运营商网络等；
2. 系统主体：业务服务、负载均衡/服务器/数据库等组件；
3. 外部调用：外部系统调用、第三方调用；
4. 业务链路：自身提供服务的链路等。

对于一个中型微服务系统，单组件就数千个；如果加上上千个微服务，整个梳理工作将十分巨大。

为了做混沌工程，这些信息需要细到什么程度？我们就需要参考下面的系统画像梳理框架。

3.1.2 系统画像梳理框架

在混沌工程初级阶段，我们采用的原则是优先共性：即提炼系统的重要共性部分，不片面追求大而全，共性基本可以解决95%以上问题。

基于这个思路，可以采用如下框架梳理系统的工作环境：

上面这些信息梳理清楚后，我们就可以对系统有一个全面、深刻的认识，知道系统运行的基础组件、核心业务链路、与其他系统间关系、系统基本环境如何改变的、系统能力等，这些信息构成了系统的基本画像，为探查系统弱点提供了物理基础。

3.2 探查系统弱点

这里的弱点不是指脆弱点，而是说系统中潜在会发生故障的地方。我们要能识别出来弱点，然后想办法优化，降低故障概率，减小故障损失到不响系统目标可用性的地步。

所以根据客户资源大都在腾讯云的特点，我们采用下面的方式探查系统弱点：

3.2.1 多样化真实世界的事件

什么情况下，系统会出问题？根据日常工作，大概会在三个方面：

1. 组件故障：包括硬件设备、互联网基础设施、第三方组件等。这里我们基于各产品专家的意见，整理了云产品故障域、高可用评分等，都是我们探查组件故障的通用素材。
2. 业务缺陷：包括资源过度消耗、健壮性缺失等(降级、限流、熔断、重试、超时等)。这里基于客户开放程度和业界最佳实践分析。
3. 配置管理：包括发布变更、clb配置修改、数据库配置修改等。

3.2.2 实验对象梳理：FMEA/STPA

参考奈飞/aws等混沌工程实战比较好的企业，都在使用FMEA/STPA方法论，来作为初期梳理系统弱点的方法。

备注：梳理出来的弱点的改善措施，可以参考下面的目标能力清晰化方法论部分。

FMEA简介

FMEA覆盖系统组件(底层设备、业务程序)故障时，系统的表现、能力分析，关注故障模式。对应上文故障域：组件故障、业务缺陷。具体实施可以参考下表：

针对 梳理框架 - 业务架构图与主链路 部分分析出的主链路的每次请求，我们可以看成是时序的横向链路，所以此处的分析我称为横向分析。

注意：

1. 全面性：从人的视角，观察系统发生了什么；组件故障模式尽可能的全面。可以求助腾讯云高可用专家，也可以跟自己的partner、业务研发讨论；腾讯云针对各种组件的故障模式总结。
2. 优先级：设计时，一定要对严重程度、故障概率、风险程度做详细调研，以保证分析贴合系统的历史运行情况。
3. 故障处理措施：详细列出当前的故障处理措施，实际代表了故障处理能力，便于定义下面的SLA/SLI及后续的实验方案设计、优化调整等。
4. 组件隔离性：针对每个组件的故障模式原因的分析，记得在自己组件内闭环，避免各层组件相互关联，最终整个分析表可读性差。比如Nginx是一个组件，则Nginx延迟的故障模式，原因不应该包含下游realserver延迟。
5. 最终全覆盖：分析出来的项目，建议最终都进行实验操作；故障影响、风险程度都是基于已有线索的假说，并不构成结论。

特别关注的字段：

故障影响，是从业务视角看到的问题。建议不要"发明"自己的故障影响术语，而是参考业界的最佳监控实践，设计故障影响，方便大家理解。建议根据混沌实验的目标不同，选择google的SRE四个黄金指标理论(资源受限、扩容受限的微服场景)、RED方法(prometheus+k8s微服务场景)、USE方法(性能分析)来定义故障影响。

STPA简介

STPA覆盖配置管理异常时，系统的表现、能力分析，关注控制危害。对应上文故障域：配置管理。具体实施可以参考下表：

针对 业务流程与控制结构 部分分析出的、对主链路的组件的管控动作，我们可以看成是瀑布式的纵向链路，所以此处的分析我称为纵向分析。

这里主要是分清楚操作面、控制面、数据面(即被操作组件/系统)，其他的字段参考FMEA分析。

举例：通过腾讯云官网控制台，操作CDB安全组。数据面就是CDB系统，控制面是腾讯云官网，操作面是操作人。潜在故障模式包括不限于高峰期变更、控制台不可用

这里STPA方法，就是分析操作面、控制面的潜在故障模式，影响了数据面的可用性。

3.2.3 目标能力清晰化

为了应对生产上的故障，我们会采取整站高可用建设。下面套用的是某个业界较常用的一个高可用模型：

1. 预防故障发生
2. 预防故障扩散
3. 故障快速发现
4. 故障定位止损
5. 灾难恢复

核心思想是如何在事前、事中、事后三个阶段保证业务受损时间最小化。

我们梳理出系统的弱点后，可以针对每个弱点，细化业务/运维/流程等方面具备什么能力以及将要建设什么能力。

针对不具备的能力，则转向高可用建设；针对已具备的能力，设计针对性的实验，通过实验结果的对照、验证我们系统具备的能力，学到新的东西。

3.2.4 组件SLA/SLI

通过FMEA/STPA分析后，目标系统各组件的SLA(故障预算或月度最大故障时长)、SLI(组件关注的故障影响)已经可以明确给出了

SLA：参考整体组件的故障频率、管理措施(变更、容量管理策略)、高可用能力、自愈程度等维度，给出待实验组件的SLA，也称为故障预算

SLI：参考待实验组件的故障模式(弱点梳理部分)，即可看出来该组件的SLI包含哪些。

3.3 设计混沌实验

3.3.1 实验目标

实验目标是cover系统弱点的处理能力的，修复系统弱点能力的基本分类：

1. 预防：验证基础系统的高可用措施、业务程序的健壮性、自愈能力按预期执行
2. 识别：验证系统告警时效、收敛、准确性等
3. 止损：验证运维的恢复能力
4. 预案：验证系统的关键预案可执行性
5. 灾难恢复

实际实验过程中，可以根据实际情况，选择一项或多项作为目标。

3.3.2 实验设计

围绕稳态的假说

上面涉及的目标分类、SLA/SLI/故障处理模型分析，其实都为了同一个目标：最终提升系统的韧性。

所以在制定实验目标时，无论实验重点在哪里，假说一定是以SLA/SLI为牵引目标，最终体现在系统的韧性上面：局部故障时，业务程序可兼容；运维可在SLA/SLI内恢复故障。

由于每次实验，根据参与人员、参与实验的系统/组件、实验背景的异同等，实验目标侧重点也会不一样。

比如某客户最近发生了多次基础设施SLA达标但业务程序原因导致SLA不达标的情况，且参与人主要是开发人员，那实验重点可能就是偏业务程序的健壮性、识别能力、止损能力；目标系统分析则更侧重业务系统的链路梳理、高可用措施细节等。

对于重点验证的能力，建议根据 目标能力清晰化 部分，进行有层次的细化，便于更好的度量目标达成度。

最小化爆炸半径

我们实验，最终的目标还是在生产环境执行。所以实验方案对在线用户的影响、对生产数据的影响，要做一些详细的控制，中间业界推荐的方法就是想办法减小爆炸半径。这里比较直观，最小化爆炸半径可以考虑下面的思路：

自动化执行实验

这里面背后的思考：

1. 手动运行实验是劳动密集型的, 最终是不可持续的
2. 考虑实验的标准化，通过自动程序将实验动作模版化，提升在不同团队的互操作性、重复执行性。

所以我们要把实验自动化并持续运行，混沌工程要在系统中构建自动化的编排和分析。

就需要系统提供相关API与公司内部系统结合或者平台本身支持编排能力。

3.3.3 实验评审

微服务架构下，在高内聚、低耦合的思想下，系统变得愈发复杂，逐渐超出了人类的认知范围。由单一人或小组设计的实验，潜在存在对系统认知不全的情况。

所以，在实验评审时，尽可能根据目标系统的分析，将干系人都约起来，然后进行评审。通过集中式评审，完善实验方案、补齐相关人认知、给支持孤岛提供浮现的机会。

从实际经验来看，大多数时候，可以和GameDay设计一起。

评审维度参考表：

备注：如果实验项关联性很大，可整体评估；如果关联性小或是不同类型的实验项，则分开评估。

3.4 GameDay

3.4.1 GameDay设计

GameDay关键人梳理

Gameday包含两部分：实验处理人(Owners、Coordinators、Reporters、Observers)和故障处理人。

实验处理人主要用途：拉通方案里面的运维、研发、IT等干系人，通过多部门联动、知识互补，评审方案信息准确性、完整度、合理性及可执行性。

故障处理人主要用途：被动接受告警信息，并根据自己掌握的技能，处理告警。

故障处理人员不与Gameday其他角色重合也不参与评审，目的是尽可能真实的反映业务系统的健壮性、运维/开发的故障处理水平，以便发现系统真实的弱点。

信息表可参考下文：

备注：由于方案论证可能持续多次，这里也可以考虑根据实际情况进行再次实验评审

制定执行计划

执行计划主要包括三个部分：前置准备工作、实验执行、收尾工作。主要是让整个实验过程更有

1、前置准备工作。完成实验过程中用到的必要脚本、预先配置调研等工作。参考下表：

2、实验执行。根据实验设计表，详细记录实验过程中的实际情况。参考下表：

3、收尾工作。实验结束后的操作，包括特殊配置清楚、数据修复等。参考下表：

3.4.2 实验计划公告

从上面梳理的系统对象、实验目标、实验对象、干系人等信息，协商执行时间等，输出实验的计划，说明在什么时间会做什么样的事情。

此步是可选的，根据实际实验规模、实验环境而定，可以考虑将计划在公司内同步，将影响提前周知、潜在有更多人评审的目的。

3.4.3 GameDay执行

GameDay执行，相对清晰。需关注的是：

1. 非故障处理角色，集中办公。可以是在同一个会议室，也可以是在线会议。
2. 实验方案不要按顺序执行，可采用随机挑选的模式执行。目的是担心有故障处理人员通过意外渠道获取详情执行计划，导致学到的运维/开发系统故障处理能力失真的情况发生。

3.5 复盘提升

混沌工程要在一家公司成功，主要有几个要素：

1. 低成本：开始实验，是小部分人带动，大部分人不熟悉，中间有很多低效、冗余工作。从长期来看，最好能针对公司内尽可能多的系统、尽可能多的场景，进行不定期、自动化、无人值守的盲演。
2. 高价值：通过实验，确实能发现团队、流程等高价值缺陷，并能够量化成对系统核心指标的贡献。
3. 认同和文化：公司不同角色会不会自发在软件生命周期的不同阶段采用混沌工程。
4. 成熟度标准：评估混沌工程是否合适的基线，牵引不同团队混沌工程水平。

所以我们在一次实验结束后，可以从上面角度分析，本次实验哪些地方可以优化，发现的哪些知识可以转化成系统能力，如何评价本次实验活动以及如何让更多人任何。

这里推荐采用定期实验报告的形式，将发现的知识进行晾晒。

认同和文化方面，可以考虑采用Kirkpatrick模型

成熟度度量可以参考greemlin的可靠性评分

4.某新能源汽车云防火墙混沌工程实战

4.1 目标系统分析

客户业务主要分布在XX、 YY两个地域，其中：XX地域主要业务是客户智行APP、智慧服务平台(SSP)，客户智行APP可从各大应用商店下载，给车主提供各种APP常见功能，SSP平台给各车主提供配件，售后，充电桩等车辆周边服务；YY地域是车联网业务，主要承载车辆远程启停、车机控制、日志、订阅等服务。两个地域通过云联网打通；两地环境规划、部署架构、运维系统、开发环境基本一致。

一个业务系统故障源，大概来自两方面：组成架构的组件(硬件故障、负载异常、丢包等)发生故障以及对组件的管理动作造成故障。下面分析这两部分的能力现状。

4.1.1 业务架构图与主链路

YY地域车联网业务系统，整体架构图如下：

车联网是经典的互联网业务三层模型，主要的业务链路有：

4.1.2 业务流程与控制结构

目前防火墙规则，都是人工通过控制台增减。

操作面：人工

控制面：官网控制台

数据面：云防产品

4.1.3 系统当前高可用能力汇总

整体具备可用区级及组件级容灾能力，从部署架构上来看，整体SLA是可以达到99.95%。需要关注的是高可用措施按预期执行、配置管理错误以及级联故障。

4.2 探查系统弱点

4.2.1 FMEA分析

通过FMEA(Failure Mode & Effect Analysis)分析法，针对业务的主要四条调用链(横向)涉及的组件自身发生异常时，业务的故障模式、原因进行全面分析，并针对风险程度进行排名，用以确认哪些异常需要优先重点关注：

4.2.2 STPA分析

通过STPA(Systems Theoretic Process Analysis)分析法，针对业务的主要四条调用链(纵向)涉及的组件，在发生非预期变更时，业务的故障模式、原因进行全面分析，并针对风险排名，用以确认哪些变更异常需要优先重点关注：

4.2.3 组件SLA/SLI分析

从上面FMEA/STPA分析可以看出，当前云防故障场景考核的核心指标有两个：该组件的故障恢复时长和SLI-延迟。其中延迟SLI的业务指标是1s

故障预算，参考历史故障频率、管理措施(变更、容量管理策略)、高可用能力、自愈程度等维度，输出如下故障预算表：

最终云防故障的整体故障预算为月度5min

4.3 设计混沌实验

4.3.1 实验目标

1. 验证当云防故障发生时，客户业务系统可兼容、不崩溃，且对用户有恰当引导
2. 验证客户运维可通过恰当的方式在5min内恢复云防故障
3. 验证兜底措施Bypaas功能是否按预期work

恰当恢复方式定义：

备注：Bypaas是腾讯云的产品能力，开启Bypaas意味着访问联路将绕行该防火墙，该墙的所有规则失效。

云防产品总共有三个墙：VPC墙、NAT墙、互联网墙。在客户整站故障时，精准定位到具体的错误并解决的处理能力，显然优于Bypaas某个防火墙；Bypaas某个防火墙即可解决的处理能力，显然优于Bypaas所有防火墙。

4.3.2 实验设计

以上2、4、5、16的故障注入方法、注入点一样；3、18的故障注入方法、注入点一样；合并的主要原因：2、3、4、5涉及组件级故障，需通过腾讯云底层模拟，爆炸半径过大，不利于发现客户业务能力、运维能力缺陷。

仅选择四个业务链路注入故障，是因为这四条链路可以代表客户整体的形态。

随着后面实验方法、模式、可观测性及小规模实验暴露出来的问题，客户侧都熟悉且改善后，可考虑提高实验覆盖的业务场景、组件、爆炸半径

此处隐藏了低优先级的实验项

4.3.3 最终设计方案

4.4 Gameday

4.4.1 Gameday设计

备注：故障处理人员不在Gameday关键角色也不参与评审，目的是尽可能真实的反映业务系统的健壮性、运维/开发的故障处理水平。

客户场景做法：

1. 故障处理人员需单独留出时间参与gamenday
2. 仅被通知gameday时间段，混沌实验用例的执行顺序、注入目标、注入方法不会同步给他们
3. 如果注入故障后，系统的故障时间超过预定的故障预算，则由协调员直接执行终止实验的能力，以保证业务稳定性

4.4.2 执行计划

执行前准备、执行计划、收尾工作有较多的客户侧信息且与执行部分信息重叠，此处略。参考生命周期中的模版

4.4.3 Gameday执行

下面是执行过程中，关于执行计划的执行记录。

4.5 实验总结

4.5.1 实验价值

发现6项客户侧改进事项；2项云产品改进事项；2条GameDay经验总结。

业务系统表现

符合预期

1. 核心链路(如访问cdb)的业务兼容性仍需加强，本次给cdb注入故障，发现智行APP业务整体受损符合预期，但用户体感强烈。
2. 在云防故障场景下，大部分业务场景，业务侧均没有扩大化，仅是当前能力不可用，且对用户有较好的提示。
3. 建议业务在出错默认页面、友好提示方面增加投入
4. 业务监控方面，监控粒度不够细，导致故障定位仍需人工排查时间。

运维处理能力

不符合预期

1. 部分时效不达标。
2. 故障处理没有流程化、标准化，仍依靠个人能力处理，导致故障时长不稳定。

云防火墙Bypass能力

不符合预期

1. VPC墙Bypaas后路由错乱，导致idc到云联网路由环路
2. NAT墙Bypaas后，长链接业务有2min+时间不可用

4.5.2 问题及经验总结

5.小结

本文主要介绍和客户共建混沌工程的阶段，如何界定待实验系统、提炼业务指标、设计混沌实验、Gameday及实验总结的重点内容。

需要注意的是，本文推荐先通过FMEA/STPA方法论全面弱点探查，再开展混沌实验。

这样做，一方面可以通过混沌工程解决系统紧要问题，体现混沌工程价值；另一方面也通过具体的实战提升客户侧的混沌工程能力。

等这些能力具备后，可以考虑引入更多系统、更多场景，提升客户公司内对混沌工程的认同，构建混沌工程文化。

最后再考虑建设混沌工程标准化、混沌成熟度等，将混沌工程引入软件生命周期的更多环节。

另外，笔者能力有限，文章中的思路、方法难免有错漏，还请各位混沌工程大佬不吝赐教，共同碰撞出优秀的实践案例。

后面也会逐步针对提到的每个关键技术，做深入的分享。

6.参考资料

LDFI参考：https://people.ucsc.edu/~palvaro/molly.pdf

Kirkpatrick模型：https://kirkpatrickpartners.com/the-kirkpatrick-model/

greemlin的可靠性评分：https://www.gremlin.com/blog/how-gremlins-reliability-score-works/

云防火墙原理：云防火墙 相关概念-产品简介-文档中心-腾讯云

FMEA/STPA案例：https://d1.awsstatic.com/events/reinvent/2019/REPEAT_1_Designing_for_failure_Architecting_resilient_systems_on_AWS_ARC335-R1.pdf

腾讯云混沌平台：混沌演练平台_故障演练平台- 腾讯云