在软件开发的过程中，测试环境无疑是一个关键的组成部分，其为开发、测试团队提供一个安全、隔离的环境来验证软件的功能、性能和稳定性。
通常在业务发展的早期，整体的系统复杂度不高，可以依靠几个人或者一个团队维护一个专用的测试环境容器。然而，随着业务的不断成长, 一个业务场景可能会包含成百上千个依赖服务，至此问题变得复杂起来，这也成为许多大公司所面临的痛点。
滴滴作为一家有一定体量的互联网公司，也会遇到类似的问题，本文将介绍滴滴的测试环境选型，及我们如何实现快速、低成本的建设“无限套”测试环境。
为什么做线下仿真环境？
在生产环境中，各个业务线的 RD、SRE、DBA 等角色各司其职，最终构建成一个稳定的系统，然而这个系统并不是一成不变的，通常会伴有高频的需求变更及业务迭代。如果这些改动不经过充分的测试，势必会对生产环境的稳定性造成很大的影响，而测试环境的易用性则极大程度地决定了对这些改动验证的效果。
测试环境很简单 -- All in one
在业务初期整体依赖并不复杂的时候，通常都会采用这种方式——将所有需要用到的服务及依赖都打包到一个测试镜像中，并在镜像中维护一个命令行构建工具来方便 RD、QA 构建测试所需环境，这种方式我们称之为 All in one 模式。
这种模式可以在学习和理解成本都不高的情况下，随时拉取一个自己独享的测试环境，RD 就可以快速迭代需求，互不干扰。
但随着业务发展，当这个容器承载数百个服务的时候，这种模式反而开始制约研发效率，我们经常会听到这样的声音：
-“我花了 1 整天才调通的链路，才 1 周就不能用了？”
-“XXX服务怎么还没有啊？”
-“怎么和线上的路由规则怎么不一样啊?”
-“这次BUG因为测试环境 Redis 和生产环境版本不一致....”
测试环境很复杂 -- Simulation
总结上面的问题，主要原因有三点：维护成本高、使用成本高、仿真度低。
维护成本高：当一个镜像需要承载几百个服务后，需要验证的场景也更多。
需要专门团队维护，验收所有已知场景、配置、基础服务依赖，并能保障定期发版
有新服务增加时，需要及时补充新服务，必须保障时效性
需要维护命令行工具支持各式各样的场景，支持各种编译环境
几乎所有服务之外的环节都需要测试环境独有的知识经验
使用成本高：需要熟悉本环境独有的“坑”。
受限于资源，边界场景覆盖有限，此时需要使用者自行调通
服务间资源抢占严重，导致超时等问题
随着各个依赖服务的正常迭代，只能重新申请环境
仿真度低：与生产环境有较大差异从而无法保障有效验收。
业务侧：
由于都是先上线业务，再定期维护到镜像中，各服务版本势必落后生产环境
由于资源所限，部分业务和生产的逻辑是不一致的，甚至单独维护一套独立的代码
开关城、黑白名单、规则引擎等配置不一致，会导致部分场景很难构造，影响面不好评估
基础平台侧：
与生产环境版本、配置、限制不一致
基础平台的使用和默认行为与生产环境不一致
很自然地，大家会想到，和生产环境保持一致是不是就可以了？于是这就是演变出第二种思路，和生产环境一样的链路，这也就是 Simulation，即仿真模式。
但是这套链路一样的测试环境，需要比较高的基建成本，于是会有人提出在生产环境围出一个逻辑隔离的机房用于测试，也会有人提出的要在线下搭一套完整链路。
这里的线上代指生产环境，线下代表与生产环境隔离的测试环境。
线上还是线下
首先聊聊线上模式，采用的是流量隔离的方式。如果公司有比较扎实的多集群方案，就可以很轻松地圈出一个测试专用的集群，除了仅包含测试流量外其余和生产环境一致，维护成本也会非常低，很多时候甚至可以直接依赖上下游的生产环境，然后通过试账号等策略保持数据的逻辑隔离。
听起来比较美好，甚至不用维护出一套全链路就可以开始使用。不过这套方案的核心问题是会伴随常态的风险，因为待测代码本质上是不稳定的，操作不当极可能会导致线上BUG。比如：将生产环境服务打限流、误删了生产环境缓存之类的操作，这类问题不仅极难定位，且无法从根本上避免。
而在线下架设专门的测试环境是否可以解决上面说到的安全问题？当然可以，但是也会面临很大的挑战，且需要各个方向的支持：
常用基础平台支持线下能力：线下仿真的核心建设工作是需要各个基础平台支持线下环境，并提供一致的能力，比如配置下发、服务发现、日志采集、表结构变更等
各业务方构建稳定服务：需要面对如同套娃般的业务依赖，各个子方向都要像生产环境一样维护测试环境，否则底层的不稳定将会导致大面积的环境不可用
效能平台整合差异化需求：需要将与生产环境差异的操作和行为封闭在该平台统一管控，减轻大家的认知成本
早先滴滴也采用在线上仿真的方案，而一个又一个的偶发线上问题，让我们不得不调整方向，目前正努力建设线下仿真环境。
多个需求怎么办
很显然出于成本和维护的考虑，不可能每个需求都单独起一套环境，退而求其次只能是提供若干套全链路互相隔离的测试环境，然后各个业务自行协商使用。虽然也可以解决比较多场景的问题，但还是会有问题：
维护成本提高：即使本次需求不需要依赖的服务改动，他们依旧需要提供额外的人力配合联调，保障多套环境的稳定
资源使用提高：比如全链路需要 100 个服务，而我的需求只需要改 10 个，但是却必须调通这 100 个服务，同时保障他们和生产环境一致
扩展性降低：扩容一套新测试环境需要比较高的时间和资源成本
而我们希望的多套环境是在仿真方案的基础上，只需要部署和关注本次有改动的服务。
我们的答案 -- OSim (Offline Simulation 即线下仿真环境)
不同业务发展阶段，甚至不同业务线场景，对于测试环境的诉求都是不一样的。核心要解决的问题是统一测试环境的基建规范，提供标准做法(OSim)。
在OSim中，我们只需要各个业务方维护一套稳定的测试环境，基于此环境通过一些非侵入的方案实现无限扩展的能力。在具体的方案中会预留一些机制，可以让上文提到的各种测试环境(包括 All in one 方式)都能顺利接入，也能给予 RD、QA 更自由的开发方式，比如爱折腾的同学可以在本地 IDE 调试开发等。
接下来，我们逐步拆解一套仿真和多套仿真的方案。
什么是仿真环境
一言以蔽之，我们理想的仿真环境，是除了网络不通之外尽可能的和生产环境保持一致，而维护成本仅相当于一个额外集群。而这里的“仿真”就是全方位，这里列举几个我们觉得比较好的实践：
构建与生产环境类似但隔离的各个基础能力，比如服务发现、日志采集、配置下发、MQ、存储等
一些可以完全复用生产环境的能力打通，如接入层配置、监控报警、成本分摊等
线下仿真节点在该服务生产环境的集群节点中共同维护，一起上线 & 回滚，保证代码的一致性
脱敏情况下，尽量复用生产环境的配置类数据减少维护成本，如灰度配置、规则引擎等
要求谁的服务谁负责，不论是基础服务或者是业务服务，线下服务稳定性的保障，问题排查都由生产环境对应的团队维护
看到最后一条，一些同学可能会有抱怨 ：“我日常开发负责生产环境的稳定性已经非常吃力了，还需要再维护测试环境?“，这类抱怨其实不难理解，而且越靠近底层服务的同学越容易有类似的声音，因为对于他们来说，依赖往往不多，随便搭一个测试环境也很容易，而在这套框架下需要成为一个“贡献者”。
但就如前文所讨论的，我们最终态是线下仿真环境用于测试，而这种形式不可能依赖几个人或者一个组织维护。当然，项目最开始试水构建 MVP 的时候依靠某一个小团队统一维护没有问题，但长远看最可持续的方式是每个人对自己的测试环境负责。如果非常难以推动，一方面需要持续提升体验，另一方面也需要从更高的层级去申请和探讨来实现全局的最优解。这些过程不是一蹴而就的，很可能需要反复沟通，接受临时方案，再随着项目影响力扩大持续迭代改进。
这里再强调一下，本方案中，各个业务方只需要维护一套线下环境的仿真度和稳定性即可，这套环境仅仅作为稳定的测试环境供其他团队使用，不允许做不稳定修改或用于业务调试。
以上实践可以比较好的保障仿真度，但相比于生产环境，测试环境会面临更复杂的场景，比如下面即将提到的，多需求并行如何处理。
如何快速部署“无限套”测试环境
有经验的同学应该能察觉到 -- 即使是每个相对独立的子业务方向，每天并行的需求可能就有大几十个，并且很多需求都只需要简单地修改几个模块，如果对每个需求都提供一套仿真环境，维护和资源的成本都是不可接受的，那有没有更好的方案呢？当然是有的，这里先说下我们结论：通过对请求流量染色标记，就可以使得流量在链路中的任何模块上，都能被识别并转发到指定测试分支环境。
在这个方案中，大部分情况我们是公用基准环境的存储，如果确实有定制化需求，也可以通过服务发现将当前环境的存储地址指向有差异化改动的存储。
如下图，本次修改只修改 A、C 服务，那么只需要维护这两个服务，并将当前环境的标记打入测试流量中。如果该服务有对应环境的分支，则转发至分支运行，如果没有，比如 B 服务，则会使用统一的全链路环境 -- 我们称之为基准环境，这也就是上文说的，基准环境是给其他业务方使用的稳定环境。
基于此思路，快速部署“无限套”测试环境最核心的点是：流量染色 + 流量隔离。
流量染色方案
为了能让流量在整个链路中任意模块被转发到指定的测试集群，我们需要对请求的流量增加一个可以透传整个链路的标记，考虑到在所有链路中 trace 拥有最高的透传度，我们可以将集群信息写到 trace 中，比如将字符串 OSim100 对 trace 的指定位置做替换，以下为参考示例：
a5e4b45f09df51b6a9cef38ce4377904 -> osim100f09df51b6a9cef38ce4377904
通过以上方式，就可以让每个服务收到流量的时候都能知道请求需要转发到哪套分支环境，比如链路中任何一个服务接收到包含以上 trace 请求，会判定本服务是否有编号为 100 的分支环境，如果存在则优先将流量转发至该环境，否则由本机消费。
更进一步，如果我们希望将流量转发到本地 IDE 开发这类非规范的环境时，用户注册的名称可能非常长或者不规范，此时可以考虑短摘要的方式，或者如果基建做的比较好可以全链路透传更多内容，染色的方案将变得更简单和直接。
流量隔离能力建设
如果想非侵入的支持以上染色方案流转，需要一些额外的开发量，也正是因为这些能力使得我们在大多数情况下，可以做到业务不改动的情况下，扩展出“无限套”测试环境。这里有一个认同的前提：如果转发服务不能感知到分支，则由基准环境代为处理。
自研 Sidecar 网关
先看下如果不做任何改动，我们不想构建全链路会有什么问题？
上图蓝色测试环境 1，如果只需要修改 B 模块，按图中方式会有两个问题：
如果有回调流量是无法回到当前的 B' 服务
如果 B 服务是类似 Thrift 之类的二进制流量，构造请求会比较困难
上图绿色测试环境2，如果只需要修改 A、C 服务，按图中方式会有一个问题：
即使不需要修改 B 服务，也必须拉取一份额外的 B''，否则流量无法请求到 C''
真实的业务场景流量拓扑无疑更加复杂，需要人为地去区分，这些成本非常高，适用性并不高。于是我们基于前文提到的染色方案，并借鉴 Sidecar 设计模式自研了一个网关服务，用于流量分发，其原理如下：
非侵入的方式支持流量转发会有很多种形式，这里只说一下我们的方案：
修改该服务基准环境在服务发现的端口：8000 --> 8001，这样对于调用方来说，A 和 B 都是 8001 端口，于是所有的请求方都会优先请求到 Sidecar 服务
为节约性能，只有基准环境会部署 Sidecar 网关，该网关会定期更新当前服务所有的基准及分支节点，以便根据流量标记进行转发
所有分支的服务还是会请求到基准所配置的服务发现地址，这里是考虑到部分服务提供的 VIP 可能包含 Rewrite 的等操作，统一请求基准环境可以减少额外维护成本
最终的流量流转方式如下图，目前支持协议：HTTP 1.* & Thrift & Dubbo
MQ 的 SDK 拉取
MQ 的消费有两种类型，其一是通过 HTTP 回调，这种与 Sidecar 一致，但还是有很多业务使用 SDK 拉取的方式，即业务启动就与 MQ 服务建立长连接，而一旦建立长连接之后，就没办法用上述方式干预消息的投递了。所以，针对这种情况我们与 MQ 同学沟通，采用相同的染色分发策略实现了对 MQ 消息投递的分流。
这里简单说明，Dispatcher 为本次新增的服务，会代替 A 服务进行消费，而基础和分支的 A 服务连接到这个服务时会带上环境标记，于是我们就可以在 Dispatcher 中进行流量解析及转发了。同时如果一段时间某个分支的消息一直没有消费，则会投递给基准环境，如图中 A-1 服务不可用时，会由基准的 A 代为消费。
Redis 网关
这里是司乘分单遇到的一个问题，早先 All in one 模式由于人手一个容器，隔离性比较好，进行测试的时候不会出现我的司机接了你的乘客的问题，而大家现在公用基准环境的存储，这种问题出现的频率必然随着使用者的增加而增加。
与 sidecar 部分不同的是，Redis 的协议并没有存 trace 信息的位置，而改动 SDK 去自定义一个协议风险又过高。这种该如何隔离呢?
我们的策略同样是增加一个自研 Redis 代理，处于性能考虑，只加载指定服务节点的 IP 信息，这样就可以获得服务节点所有的 IP -> 环境编号的信息，然后根据建立连接的 Remote Addr 进行匹配，如果确认该来源是属于分支环境，则对 Redis 协议做解析，将 Key 增加 osimXXX_ 的前缀。如此便做到了不需要修改代码就能隔离类似分单场景的情况。
上图 B' 读写 key：value 的操作在 Redis 中实际会被存为 osim100_key：value，与基准环境的 B 隔离开，这样就能对不同环境分别做司乘撮合了。
还有一个点需要注意，以分单为例，一旦测试场景需要分单做隔离，那么针对该存储的读写服务需要同时部署到一套测试集群中，比如上图的 B' 和 C' 需要一起出现在这个分支上，为了方便用户这部分能力已经在环境申请平台上支持。
自调度 & 前端
所谓自调度是一个类似定时任务的服务，比如定时扫库然后发起请求。而前端则是当用户点击后会主动发起请求，这俩其实可以归类为一种，即由服务本身发起调用而不是用户，因此无法在请求的时候就带上染色标记。解决方式也是统一的，需要对代码进行改造，根据当前容器的环境变量可以知道当前所属分支编号，并以相同方式生成染色 trace，这部分是没有办法做到不改动。考虑到线下 trace 的改动即使影响到线上，影响也比较有限，所以整体风险可控。
无法标记的场景
前文提到的种种隔离措施已经可以解决绝大部分场景，并且基本都可以快速横向扩展。但还是有一些场景不能分隔，比如订阅 MySQL 的 binlog 的服务，由于数据存入 MySQL 之后已经没有环境信息了，所以这种场景只能维护多套全链路，这里的全链路指的是消费 binlog 之后的链路而不是前文提到的公司的全链路，所以相比之下体量也还不是很大，尚可接受。
以终为始，我们是如何运营的
以基准仿真和流量隔离为框架构建的 OSim 方案，只需要有一套稳定的基准环境就可以低成本的扩展多套分支环境，很好的支持了多需求并行开发的诉求。不过一旦基准环境出现故障，则很可能阻塞大量正在分支开发业务的进度，因此必须保障好基准环境的稳定性。随着接入的业务接入越来越多，我们面临的稳定性压力也越来越高。
如何运行好日益膨胀的测试环境逐渐成为最核心最困难的事情，运营的核心思路是尽可能复制生产环境的稳定性经验和手段，但一些 OSim 特有的实现，比如流量转发之类，也只能进行额外的定制。后文我们将从指标牵引、制定规范、稳定性方案、明确责任、持续优化这几方面展开说明。
指标牵引
这里套用一句俗套但经典的话：If you can't measure it，you can't improve it（如果你无法度量它，你就无法改进它），测试环境的稳定性远没有读文章所体会的顺畅，指标的设定也不能简单的和生产环境对标，生产环境要求 7 * 24 高可用，而测试环境如果半夜或者周末挂一下，此时如果没有真实影响用户，直接计算不可用时长显然不合适。综合考虑了统计成本和当前人效之后，我们做了一个简化版的指标，供大家参考。
指标设定
生产环境如果出现问题，通常会统计用户受影响量级，所以线下也可以用类似的思路。这里定了两个核心指标：
指标1 - 准出自动化成功率：因为上线过程中的失败会实实在在的影响研发效率，同时休息时用户上线量会很低，依据此评估稳定性比较符合实际情况
指标 2 - 因环境问题导致的项目延期：这个是对第一个指标的补充，因为自动化和实际用户使用还是有些差异
考虑到各个业务线的自动化能力参差不齐，覆盖面和校验程度都无法保障符合预期，所以最终指标 1 在滴滴的实现方式是以最顶层的业务的自动化为准，通过最顶层的用例覆盖依赖到的业务线以实现比较全面的监控。我们推荐各个依赖方自建的自动化统计，但暂不作为全局指标参考。
通过上述指标可以实现对测试环境稳定性的初步评估，虽然和真实情况会有一定的偏差，但结合统计成本还是有比较好的引导效果。
定期复盘通告
针对不同的指标情况，会有一个定级标准，这里环境建设的各个阶段应该都不太一样。比如环境问题阻塞项目一定时间或准出自动化失败一定次数后定级为需要复盘，统一由环境 FT 团队负责拉起复盘并跟进落地需要改机的事项，其余细化场景可以由各业务线自行组织。
同时，每周环境 FT 会以邮件的形式周知本周稳定性核心影响原因及责任方进行通告。
制定规范
规范化是解决系统性问题的良药，也是降低维护成本最有效的方式。目前我们通过多个团队的沟通及实践，整理了几个方向的规范。
环境构建规范
这部分内容在前文的「什么是仿真环境 」这个章节中已经做了一些举例，并建议基准环境以 OSim 规范的形式接入，可减少大量维护成本，但不强制。如果接入方能保障自己的线下服务足够稳定性，且同线上版本时刻保持一致（小时以内同步即可），也可采用自己的方案。
环境职责定位
帮助大家理解整个需求迭代周期中所有的环境分别用于什么场景，比如基准环境需要保持稳定，所以禁止对基准环境进行未经测试的改动，包括但不限于代码、配置、存储等。再比如前文提到的线上仿真，通常情况仅用于回归测试，但也提供了一个出口：当需要应急迭代一些线下能力不完备的场景时，可以走哪些审批流程临时使用。
稳定性运营规范
由于各个业务方业务形式不同，所以该规范更多的是提供通用的稳定性保障手段，明确责任团队，设定稳定性指标并以此为牵引帮助 OSim 能从整体上逐渐趋于稳定。
稳定性方案
既要有指标帮助大家从整体看到稳定性问题出在哪，也需要提供相配套的手段来前置保障环境稳定，而不仅仅依赖后置的复盘等方案。在生产环境中主要从三个层面保障：
基础监控：CPU/Mem/Disk之类的服务基础指标监控
业务指标：监控各个业务场景量级，成功率等可用情况
用户反馈：用户使用时遇到问题的进线
接下来我们从 OSim 角度聊聊这三层如何对应。
基础监控
这里我们会完全复用生产环境的能力，我们将 OSim 基准环境和线上集群部署在同一个节点下，以此来保证完整复用生产环境的基础监控能力，减少额外配置成本。
还有一点，秉承“谁的服务谁负责”的思想，我们会将测试环境的报错也发送到生产报警群中，目的也是让对应的 RD 重视基准环境，不过在这里我们做了一些额外的开发，在 OSim 达到一定稳定性前，暂时会屏蔽电话和短信，稳定后计划和生产环境完全一致对待。
业务指标
仅仅监控基础指标肯定是不够的，经常遇到线上出问题的时候基础指标都正常，但是部分业务场景还是受损，所以线上还需要监控业务场景的成功率，量级等信息来保障业务的稳定。
生产环境中无时无刻都有用户流量，而测试环境的流量场景和请求量都极不固定，但如果我们不做此类监控，即使所有服务基础监控都没有问题呢，也无法确认环境中各个场景的可用情况，最终导致无法准确评估项目使用风险。
好在我们的自动化测试会包含丰富的场景验收，以自动化用例的成功与否判定该场景的可用情况是我们认为比较好的解法。最终巡检方案是在这套环境上定期的执行全量自动化测试，QA 保证自动化会覆盖各个 P0、P1 场景，而我们通过自动化的成功率来验证环境的可用情况，以此来尽可能早的发现故障。
用户反馈
在推广环境的过程中，我们发现另一个与生产环境有出入的情况，即生产环境通常重保核心链路，对应的就是自动化的 P0、P1 场景，而日常迭代开发中最核心的链路往往比较稳定，改动反而较少，而自动化包含所有场景显然是不现实的，因此也必须依靠用户反馈作为补充。
我们的反馈通道通常包括公司统一的客服群，各个业务线和各个基础服务提供方的支持群，如果遇到比较大的项目评估有风险，由 QA Owner 对环境做一次初步评估，有需要的话会拉环境 FT的同学进项目群做一定高优支持，以此来保障项目的如期交付。
通过以上三层的稳定性保障手段，可以比较快地发现问题，从而减少用户受阻时间。
明确责任
考虑到该方案偏向更多的是全局最优解，落实在实际场景中，往往权责利并不完全对等，靠近底层的业务团队责任明显大于利益，越靠近顶层的业务团队利益明显大于责任，而这套方案的目标是全局最优解，所以推广过程中可能需要向上反馈从整体拉起认可，以下是我们粗略的一些分工，用于指导环境接入，使用和维护：
SRE：负责基准环境的运维工作，跟线上保持一致，比如容器出问题、接入层变更等。
业务 RD：需提供稳定线下测试环境，同时有足够手段保障环境的稳定性(比如接入日志采集，CPU/Mem/Disk、Panic、Port探活等系统监控)，尽量复用线上方案，避免重复建设。
业务 QA：负责自动化测试用例失败后的初步定位和分流，同时建设工单，找到对应负责人，统计故障处理时长和故障率，用作稳定性指标，同时也负责对应方向的改进推动。
环境 FT：负责网约车外部的接入和协调工作，比如基础架构，上下游依赖等方案的建设和推进。同时负责稳定性的运营工作，针对核心环境问题复盘、拉齐集团标准化等。
持续优化
为了能持续提升使用体验和稳定性，我们会以主动和被动的方式去了解当前环境最痛的问题，并进行汇总排序以便于最优先的解决最有价值的问题。主动方式比较好理解，就是从全局的角度主观的分析现有方案，以全局最优解的思考方式去持续改进，被动方式主要是靠收集用户反馈，常规来源如下：
各个业务线的 QA 会整理和收敛当前业务线的通用类别问题，并以双周会的形式汇总
每次问题复盘的改进项，整理成通用问题的改进点并跟进完成
客服群中收到的通用痛点问题整理跟进
总结
以上，我们已经展示了 OSim 的接入维护成本，流量隔离方案，以及如何持续运营。相比于之前的 All in one 方案，也基本解决了「测试环境很复杂——Simulation 」中提到的不足。现在，仅网约车业务线就有数百需求并行开发中，线下环境承载了 95+% 需求。这些需求拥有更高仿真度，可以做到开箱即用， 新分支构建成可用状态的时间从原先的小时级降低到 10min 左右。我们已经从这些变化中看到了生产率的提高，对此我们感到非常兴奋，但仍需要在为未来做很多改进。
本地开发
项目开发过程中的体验还需要提升，目前最常用的分支开发，每次代码改动都需要重新部署，调试成本偏高。我们最终的期望是，用户可以轻松的使用本地 IDE 进行开发联调，节约容器资源的同时也能极大的提升研发效率。现在虽然已经提供了类似的能力和工具，但真实使用起来的体验距离目标还有比较大的差距。
链路可视化
流量染色 + 流量隔离的方案虽然巧妙的以非侵入方式解决的多套环境的问题，但同样也会让流量链路变的更复杂，不仅排查网络问题时需要考虑 Sidecar 代理，也会对一些探活摘流策略有影响。最重要的是，这些对于用户来说比较黑盒。如何将黑盒可视化的展示给用户，这也是后续我们需要提升的部分。
自动化支持
自动化用例是一笔宝贵的财富，不仅仅可以用于环境巡检，上线验收，后续也可以用于项目自测、压测、强弱依赖分析等场景。自动化能验收的场景越多，收益越大。
从环境角度我们也在 Sidecar 网关中集成了一些 mock 能力，用于帮助自动化用例验收一些失败场景。使用方式是在请求时做一些特定的 mock 染色，便可以在链路中指定的服务做一些特殊处理，其他用户不受影响。这些特殊处理包括固定响应结果，延时返回，修改请求和修改响应等，现已支持 HTTP 1.* 和 Thrift，但是目前可视化能力不足，用户排查成本偏高；另一方面当用例增多，定位难度也在增加，我们也在积极探索自动化定位根因的一些手段，减少自动化异常用例的排错成本。
END
作者及部门介绍
本篇文章作者方骏达，来自滴滴网约车出行技术团队，出行技术作为网约车业务研发团队，通过建设终端用户体验平台、C端用户产品生态、B端运力供给生态、出行安全生态、服务治理生态、核心保障体系，打造安全可靠、高效便捷、用户可信赖的出行平台。
招聘信息
团队后端、测试需求招聘中，欢迎有兴趣的小伙伴加入，可以扫描下方二维码简历直投，期待你的加入！
研发工程师
岗位描述：
1. 负责相关业务系统后台研发工作，包括业务的架构设计、开发，控制复杂度，提升系统性能和研发效率；
2. 有业务 sense，通过不断的技术研究和创新，与产品、运营一起快速迭代提升业务的核心数据。
测试开发工程师
岗位描述：
1. 构建适用于网约车业务的质量保障体系，制定并推进相关质量技术方案落地，持续保障业务质量；
2. 深入了解业务，与业务中各角色建立沟通，总结业务问题与痛点，全方位为业务创造价值，工作不设固定边界；
3. 通过应用相关质量基础设施，提升业务代码质量和交付效率；
4. 沉淀高效测试解决方案，并能提供通用化方案，支持在其他业务线落地应用；
5. 解决业务质量保障中的难点问题、复杂技术难题；
6. 质量技术领域前瞻性探索。
