简介： 为什么线下环境的不稳固是必然的？咱们怎么办？怎么让它尽量稳固一点？

这篇文章想讲两件事：

• 为什么线下环境 [1] 的不稳固是必然的？
• 咱们怎么办？怎么让它尽量稳固一点？

此外，还会谈一谈如何了解线下环境和线上环境的区别。

如果没有工夫读完全文的话，这里是本文的次要观点：

1. 线下环境不稳固是必然的，在没有实现 TiP 之前，以后咱们能做的是尽量让它稳固一点。
2. 防止过多的抽象应用”环境问题“的说法。
3. 业务利用线下环境的基础设施必须依照生产环境标准运维。一个实现伎俩就是间接应用生产环境的基础设施。
4. stable 层首先要把单利用可用率晋升下来。单利用如果无奈做到 99.999% 或 100% 都是能调通的，链路的稳定性就是缘木求鱼、基本无从谈起。
5. 缩小 dev 环境的问题，次要有四个重点：做好联调集成前的自测；架构上的投入（契约化、可测性）；通过多环境、数据库隔离等伎俩缩小互相打搅；通过继续集成尽早裸露问题，升高问题的影响和修复老本。
6. IaC（Infrastructure-as-Code）是解题的一个关键点。
7. 线下环境是一个场景。要深刻理解线下环境和线上环境这两个不同场景的差别。

以下是注释：

一 线下环境不稳固的偶然性

说起线下环境为什么不稳固，常常会听到大家给出这些起因：

• 为了老本，线下环境的机器不好，是过保机；
• 为了老本，线下环境的硬件资源是超卖的；
• 工具配套不欠缺，线下环境的配置和生产环境没放弃同步；
• 线下环境的监控告警、自愈等没有和生产环境对齐；
• 投入不够，不器重，对问题的响应不及时，流程机制等没建设起来；
• 测试流动会产生脏数据；
• …

其实这些起因中大部分都不是实质问题。换句话说，即使狠狠的砸钱、砸人、上 KPI，即便机器不必过保机、硬件不超卖、工具建设好把配置监控自愈等和生产环境放弃对齐、问题响应机制建设起来，线下环境也还是会不稳固的。因为线下环境不稳固的本源在于：

1. 线下环境外面有不稳固的代码
2. 线下环境不稳固带来的影响小

这两个起因是互相有关系的：咱们须要有一个中央运行不稳固的代码，但咱们怕不稳固的代码引起很大的问题，所以咱们须要这个中央是低利害关系的（low-stakes）；因为这个中央是低利害关系的，所以对它的问题咱们必然是低优先级解决的。

所以，线下环境必然是不稳固的。

之所以 Testing-in-Production（TiP）是一条前途，就是因为 TiP 把这两个本源中的一个（即第二点）给打消了：production 不稳固带来的影响是很大的。但 TiP 注定是一条很漫长且艰巨的路线，因为咱们怕不稳固的代码引起很大的问题。咱们须要首先在技术上有充沛的能力充沛确保不稳固的代码也不会引起很大的问题。这是很有难度的，明天咱们还没有 100% 的信念做到能充沛确保稳固的代码不会引起很大的问题。

既然 TiP 一时半会儿还用不上、施展不了很大的作用，那么接下去的问题就是：怎么办？既然线下环境的不稳固是必然的，那咱们怎么用不太夸大的投入让它尽量稳固一点？

对策还是要有的。否则，线下环境太不稳固了，大家就都放弃了，不必了，间接跳过，间接把还不太稳固的代码部署到预发环境（pre-production）去了。把预发环境当线下环境用，后果就是预发环境也被搞得像线下环境那样不稳固了。这样再倒退上来，预发环境越来越不稳固了，咱们还有中央能够去吗？所以，还是要有一整套对策让线下环境尽量稳固一点。

二 怎么让线下环境尽量稳固一点

1 防止过多的抽象应用“环境问题”的说法

• 很多同学习惯用“环境问题”、“环境不稳固”来指代线下环境里除了他本人的那个利用之外的所有的问题：
• 物理机和网络的问题是“环境问题”
• 中间件的问题是“环境问题”
• 数据库自身的问题是“环境问题”
• 数据库里的“脏”数据 [2] 是“环境问题”
• 我的数据被他人的利用生产掉了是“环境问题”
• 其余利用的配置配错了是“环境问题”
• 其余利用重启了导致我的调用失败是“环境问题”
• 其余利用里的代码 bug 也是“环境问题”
• …

“环境问题”这个说法太抽象了，过多的抽象应用这个说法是很无害的，因为它会覆盖很多真正的问题。其中的一些问题也是有可能造成生产环境的稳定性和资金平安危险的。过多的抽象应用“环境问题”这个说法的另一个害处是：会造成在大家的意识里“环境问题”是必然存在的、是无奈防止的，导致大家一听到“环境问题”第一反馈就是放弃，放弃排查、放弃抗争、放弃探索、放弃改良优化。

要晋升线下环境稳定性，首先要正本清源，尽量避免抽象的应用“环境问题”这个说法。要尽量用具体一点的说法，比方，“网关配置问题”、“某某利用启动超时”、“数据库查问超时“。这些表象 / 症状背地的起因有很多种可能，是须要咱们去排查分明的，不能“刷墙”。所谓的“刷墙”的意思是：看到墙上有条裂缝，就找一桶乳胶漆刷一道，把裂缝遮蔽掉。“刷墙”的行为的一个例子：某个利用启动失败，就换台服务器再试一试，胜利了就持续干上面的事件，不去探索之前启动失败背地的起因了。

有些时候确实是我的项目工夫太紧了，没工夫排查每一个问题。能够事实一点，如果同样的问题呈现第二次或第三次（例如，同一个利用、同一个我的项目分支，这周遇到两三次启动失败），就要查究一下了。

2 问题拆解

“环境问题”，归根到底，无外乎来自于三个中央：

• 基础设施（中间件、数据库、等等）的问题
• stable 环境的问题
• dev 环境的问题

这里要解释一下什么是 stable 和 dev。线下环境的构造在蚂蚁团体和阿里团体的做法个别是这样的：

• 基础设施之上，首先有一个 stable 环境。
• stable 环境跑的是和生产环境的版本雷同的代码，每次生产环境公布后，stable 也会同步更新。
• dev 环境就是我的项目环境，是 SUT（System Under Test）。每个我的项目有本人的 dev 环境，部署的是这个我的项目的代码，这个我的项目上的同学就在这个我的项目环境里做测试、联调、集成。
• dev 环境不是一个全量的环境，它是“挂”在 stable 上的一个子集。某零碎一共有一百个左右的利用，它的 stable 环境是全量的，但 dev 环境只蕴含这个我的项目波及的利用，测试发动的流量外面蕴含一个标签，测试流量就会被某种路由机制（例如，在蚂蚁用的是 sofarouter）从 stable 环境的利用路由到 dev 环境的利用：

尽管这三趴对“环境问题”会因人而异，但都不可漠视。要晋升线下环境稳定性，必须对基础设施、stable、dev 这三趴三管齐下。

3 对策：基础设施

基础设施的稳固是十分要害的一环。如果基础设施不稳固，就会呈现“排查疲劳”：每次遇到一些奇怪的问题（启动超时、调不通、等等），如果排查下来 10 次有 9 次是基础设施的问题，大家慢慢就不违心排查了（因为不是代码的问题），一些真正的代码问题也会被漏过。

基础设施层要遵循的准则是：（业务利用的）线下环境的基础设施必须依照生产规范运维。如果一个零碎是运行在私有云上的，那么这个准则就很容易实现，因为线下环境也能够间接运行在私有云上。但有些公司、有些零碎，是运行在自建机房、公有云上的，那最好的做法是撤销“线下机房”，间接把业务利用的线下环境放在基础设施的生产机房去跑（同时做好必要的访问控制和业务数据隔离）。线下环境间接放在基础设施的生产机房跑之后，基础设施团队间接依照运维其余生产机房那样去运维，中间件、数据库、缓存、物理机、网络、机房等所有的监控告警、巡检、公布和变更管控、应急、自愈能力、容量治理、等等都能做到位，稳定性可用率有明确的 metrics 和 SLA。缓缓的，就能造成这样的心智：例如，当线下环境的某个业务利用呈现数据库查问 timeout 的时候，咱们首先狐疑的是利用本人的 SQL 查问语句有问题，而不是狐疑数据库有问题。

4 对策：stable 环境

线下环境不稳定性的时候，工程师的心智是：当我在 dev 环境跑测试遇到谬误的时候，我的第一反馈是“肯定是‘环境问题’”。也就是说，我的第一反馈是“他人的问题”，只有当“他人的问题”都排出后我才会认真的去看是不是我本人的问题（包含我的项目的问题）。

当基础设施层稳固保障好当前，就能造成这样的心智：当某个利用呈现数据库查问 timeout 的时候，咱们首先狐疑的是利用（可能是 stable 的、可能是 dev 的）的 SQL 有问题，而不是狐疑数据库有问题。

当 stable 和基础设施这两趴的稳定性都治理好当前，就能造成这样的心智：当我在 dev 环境跑测试遇到谬误的时候，我的第一反馈是“肯定是咱们的我的项目有问题”。其实明天在生产环境大家就是这样的心智。一次变更、一次公布后，如果呈现问题，做公布做变更的同学的第一反馈都是狐疑是不是这个变更 / 公布有问题，而不是狐疑是不是（生产）环境自身不稳固。做 stable 和基础设施的稳定性治理也要达成这样的心智。

stable 的稳定性治理，最终就是在做一道证明题：拿出数据来，证实 stable 是稳固的（所以，如果有问题，请先排查你的我的项目）。证实 stable 是稳固的数据分两类：

• 单利用
• 链路

单利用就是查看利用是否起来了、是否或者、RPC 调用是否调通（不论业务后果是胜利还是失败，但至多 RPC 调用没有 system error）。它验证的是单个利用是可用的，不论业务逻辑对不对，不论配置对不对，不论签约绑卡能不能 work，至多这个利用、这个服务、这个微服务是 up and running 的。单利用稳定性必须达到 100%，或者至多应该是“五个 9”。这个要求是正当的，因为单利用的稳定性是链路稳定性的根底。如果单利用都没有 up and running，链路性能的可用和正确性就基本无从谈起。

单利用的稳定性度量是很通用的，不须要了解业务场景就能够度量。咱们须要做的事件就是：对指标造成共识，把度量跑起来，而后依据度量数据投入人力，一个个问题的排查解决，把稳定性一点点晋升上来；后续再呈现问题，第一工夫排查解决，让稳定性维持在很高的程度。

链路的稳定性，说白了就是跑脚本、跑测试用例。频率是分钟级也能够，小时级也能够。验证链路的脚本是须要一直的补充丰盛的，当产生了一个 stable 的问题然而验证脚本没有发现，就要把这个问题的场景补充到链路验证脚本（测试用例）外面去。也能够借用测试用例充沛度的度量伎俩（例如，行覆盖率、业务覆盖率、等等），被动的补充链路验证脚本。很多其余测试用例主动生成的技术也能够用上来。

最初，达到的成果就是：用数据谈话。用很有说服力的数据谈话：stable 的单利用都是好的，链路也都是通的，这时候呈现了问题，就应该先狐疑是我的项目（dev 环境）的问题。

顺便说一句：stable 能不能像基础设施那样也间接用生产环境呢？能够的，stable 用生产就是 Testing-in-Production 了。蚂蚁的影子链路压测就是这种做法的一个例子。只不过如果要把这个做法推广到更大面积的日常功能测试、反对更多链路和场景，复杂度和难度会比影子链路压测更高。

5 对策：dev 环境

严格来说，dev 环境的问题不能算是“环境问题”，也不能算是“线下环境稳定性问题”。因为 dev 环境就是被测对象（SUT），既然是还在写代码、联调集成和测试，那咱们的预期就是它是不稳固的，是会有问题的。只不过理论工作中，dev 环境自身的问题也形成了大家对线下环境不稳固的体感。

依据咱们对一些我的项目进行的具体数据分析来分类，在 dev 环境遇到的问题的几个头部类型是：

• 自测没做好。单利用自身就有 bug，而且这些 bug 是在单利用的 unit test 和接口测试中是能够发现的，然而因为各种起因，单利用的自测没做好，这些 bug 留到了在 dev 环境中进行联调集成的时候才发现。
• 架构方面的起因。例如，接口契约问题。一个我的项目里，系分做好当前，上下游两个利用各自依照系分去编码实现，但因为系分做的不够好，或者上下游对系分的了解有差别，两个利用到了 dev 环境放在一起一跑才发现跑不通。这类问题是无奈通过自测来发现的（因为自身的了解就有差别）。另一个比拟常见的架构起因是可测性。
• 烦扰。同一个我的项目中几个同学各自在做联调集成时候的互相烦扰，以及几个我的项目之间的互相烦扰。配置被他人改掉了，数据被他人改掉了，这些状况都很常见。

自测没做好，解法就是要做好自测：

• 单利用的测试要达到肯定的覆盖率和有效性。例如，我之前团队的要求是 A 级零碎的单利用测试（unit test 和接口测试）要达到 90% 以上的行覆盖率、以及变更行的覆盖率 100%，用例的有效性也要达到 90%。
• 单利用的测试要达到很好的稳定性。依据过来在很多中央的工夫和察看，我倡议的规范是”90% 成功率“，这是在“能做失去的”和“够好了”之间的一个比拟好的均衡。比这个高，尽管更好，但难度太高，不适宜大部分的团队；比这个低，稳定性就不够了，就会感触到测试乐音带来的各种问题。“90% 成功率”是一个“苦涩点”。“90% 成功率”的意思是：一个单利用的所有 unit test 和接口测试的整体通过率，跑一百遍，有至多 90 遍是 100% 通过的。
• 单利用的测试也要足够快，一个单利用的所有 unit test 和接口测试要能在 10 分钟内跑完。
• 代码门禁是必须的，是标配。很多其余货色是能够依据具体团队的具体情况有不同的做法的，例如，大库、骨干开发。有些团队能够举出一些正当的理由说“大库模式不适宜我”、“骨干开发不适宜我”。但我不置信哪个团队能举出正当的理由说“代码门禁不适宜我”。

接口契约在软件行业曾经有比拟多的实际了，例如 OpenAPI、ProtoBuf、Pact 等。利用间的接口（包含 RPC 调用和音讯），如果只是在一个文档外面用中文或者英文来形容的，上下游之间就比拟容易呈现 gap。也经常出现接口改变只是通过钉钉说了一下，连文档都没有更新。利用间的接口应该以某种 DSL 来标准的形容，并且在单利用层面依据这个 DSL 形容进行契约测试，这样能大大减少两个利用到了 dev 环境放在一起一跑才发现跑不通的状况。

6 dev 环境：隔离

下面讲到，dev 环境问题的第三个次要起源是互相烦扰。既有同一个我的项目中几个同学各自在做联调集成时候的互相烦扰，也有几个我的项目之间的互相烦扰。我的项目之间的互相烦扰的本源是共享数据库：

过来，stable 环境以及多个我的项目的 dev 环境的代码都是拜访同一个库的，相互影响就是不可避免的。数据的逻辑隔离和物理隔离都能够解决多我的项目间的烦扰：

• 逻辑隔离：多个我的项目的 dev 环境依然和 stable 一起共享同一套库表，然而在表的数据层面减少一些标识列，并且在利用的代码逻辑外面依据这种标识来读写数据。
• 物理隔离：每个 dev 环境别离有本人的库或者表，各自的数据在库或表的层面就是隔离的。相比逻辑隔离，物理隔离有两个长处：1）对利用代码的入侵很小，须要的利用革新工作量很小；2）不同的我的项目可能有不同的数据库表构造。

除了数据库，缓存、DRM 等也须要进行隔离，缩小多个我的项目之间的互相烦扰。做好隔离对晋升稳定性有很大的帮忙。而且，数据库和缓存等的隔离也能大大降低“脏”数据引起的问题。

7 dev 环境：多环境

除了多个我的项目之间的烦扰以外，同一个我的项目中几个同学各自在做联调集成时候，因为大家都在同一套 dev 环境（我的项目环境）上工作，也会呈现互相烦扰。

解决我的项目内互相烦扰的前途是多环境：

IaC（Infrastructure-as-Code）和 GitOps 是实现多环境能力的要害。有了 GitOps 能力（包含 Configuration-as-Code 和 Database-as-Code），能重复疾速创立出一套套新的我的项目环境，并且保障新创建的我的项目环境中的配置都是对的（IaC 也能更好更无效的确保 stable 的配置、二方包版本、CE 版本等和生产环境是统一的）。

8 dev 环境：继续集成

单利用的继续集成曾经是比拟广泛了：在 master 分支和我的项目分支上，每次有代码提交都会触发一次单利用的编译构建和测试（包含 unit test 和接口测试），或者以某个固定周期（例如每 15 分钟或者每小时）定时触发一次，确保该利用的编译构建和测试始终是好的。

多利用的继续集成就是：在我的项目分支上，每次有代码提交、或者每隔肯定工夫，把本我的项目各个利用的我的项目分支最新代码部署到 dev 环境上，并且跑一遍链路级别的用例，确保本我的项目的这些利用的我的项目分支代码还是好的。

在很多团队，明天开发同学的很多受挫感和工夫的节约都与不足我的项目级别的多利用继续集成无关，例如：

• 小李跟我说收单领取曾经跑通了，让我能够开始测结算了。但我明天到我的项目环境里一跑，发现收单有问题。我又去找小李，小李看了一下抵赖是他的问题，他过后只看了行业层的 resultCode 是 Success，没有 check 上游单据的状态是否正确。
• 我两天前曾经把正向流程（例如：领取）跑通了，但明天我要调逆向流程（例如：退款）的时候发现我的项目环境里正向流程又不 work 了。逆向流程的调试被 block 了，我要先花工夫排查正向流程的问题。
• 我的项目环境里正向流程两天前是 work 的，明天不 work 了，从两天前到当初，这个两头正向流程是从什么工夫开始不 work 的？两天工夫，如茫茫海底捞针啊。
• 我是负责上游利用的。上游的同学明天一次次来找我 check 数据，每次他在我的项目环境里发动一笔新的调用，都要来找我让我做数据 check。这事儿我躲也躲不掉，因为上游的同学不了解我的利用的外部实现，要他们了解每个上游利用的数据逻辑也不事实。
• 我是负责上游行业层的，我在我的项目环境里每次发动一笔新的测试交易的时候，我都要挨个儿找上游各域的同学去做数据 check，找人找的好辛苦啊。我也了解他们的难处，那么多我的项目，那么多我的项目环境，那么多人都去找他们做数据 check。
• 我是负责上游行业层的，上游的同学常常来找我，让我帮他们发动一笔交易，因为他们的利用改了代码，他们先晓得新的代码 work 不 work。起初我切实感觉这种要求太多了，写了一个发动交易的小工具，让他们本人去跑。但有些会本人去学着用这个小工具，有些还是会来找我。
• 我是负责上游利用的，我常常要去找上游同学帮我发动一笔。他们被我骚扰的很烦，但我也没方法。他们尽管给了我一个小工具，但很难用，很多参数不晓得怎么填。
• …

做好了多利用的继续集成，这些问题就都解决了：

• 因为用例都自动化了，发动交易和做 check 都不须要再求爷爷告奶奶的刷脸找人了。
• 因为用例都自动化了，发动一笔新的交易和验证各域的数据是否正确 都曾经都自动化在用例的代码里了，无论是上游还是上游的同学，都只有跑这些用例就能够了，不须要理解小工具的参数怎么填，也不会因为疏漏少 check 了数据。
• 因为用例都自动化了，所以能够高频的跑，能够每个小时都跑一次，或者能够每 15 分钟就跑一次。这样，一旦前两天曾经跑通的性能被 break 了，我马上就晓得了。
• 因为用例高频的跑了，一旦前两天曾经跑通的性能被 break 了，我马上就晓得了，而且问题排查也很容易聚焦。比方，如果这个性能始终到上午 9:30 还是好的，然而从 9:45 开始就开始失败了，那我就能够聚焦看 9:30-9:45 这段时间前后总共几十分钟工夫里产生了什么、谁提交了新代码、谁改了数据或配置。

…

做好了多利用的继续集成，其余的益处还有：

• 因为用例高频的跑了，一个用例一天要跑几十次，就很容易暴露出用例自身或者利用代码的一些稳定性问题。比方，有一个链路，从昨天到明天在本我的项目的多利用继续集成外面跑了几十次，其中有几次失败了。但从昨天到明天，这个链路没有相干代码和配置改变。所以尽管失败的比例小于 10%，我还是要排查一下，排查后果发现了一个代码的 bug。如果放在过来，没有这种多利用的继续集成，一个链路跑了一次失败了，第二次通过了，我很难判断第一次失败到底是“环境问题”，还是真的代码有 bug。
• 因为用例在我的项目分支里高频的跑了，我就有一个参考物。如果一个用例在我的项目分支里是一只稳固 pass 的，但明天在我的集体分支代码上失败了，有了继续集成的后果作为参照物，我就很快能判断进去这很有可能是我的集体分支的代码有问题。
• …

三 线下环境和线上环境的区别

线下环境和线上环境的区别是什么，不同的人有不同的答复。有的说线下的容量没有线上大，有的说线下没有实在用户，有的说线下短少生产的实在数据，等等，各种答案都有。线下环境和线上环境还有一个很实质的区别是：它们是两个不同的场景。

线下环境是一个场景。

咱们做业务架构，先要搞明确业务场景，而后能力正确的设计业务架构和技术实现。数据的读和写是高频的还是低频的，数据块是大而少的还是小而多的，读取数据的时间段上有没有显著的峰谷，数据写入后是否会批改（mutable vs. immutable）等等，这些都会影响咱们的架构和技术实现计划。

线下环境也是一个场景，一个和生产环境有不少差别的场景[3]：

1 基础设施层面

中间件

一个配置值、一个开关值，在线上的改变是低频的，大部分状况下一天可能也就推个一两次，但在线下可能每天会有几十次、几百次，因为推送一个配置一个开关可能是测试的一部分。这个差别就是场景的差别。

服务器

服务器重启，在生产环境里是一个低频事件，很多利用只会在公布的时候重启一次，两次重启间的距离个别都是数天。但在线下环境，重启的频率可能会高很多。

数据库

在生产环境，库的创立和销毁是一个低频事件，然而在线下，如果搞了继续回归和一键拉环境，线下环境数据库就会有比生产高的多得多的库创立销毁操作。

数据失落

生产环境，咱们是不容许数据失落的。所以，数据库（例如蚂蚁的 OceanBase）和 DBA 团队花了大量的心血在数据失落场景上。但在线下，数据失落是齐全能够承受的。这个差别，对数据层的架构和技术实现意味着什么？例如，数据库在生产环境是三正本、五正本的，在线下不能反对单正本，能不能很容易的在单服务器、单库级别配置成单正本。

代码版本

生产环境，一个零碎，最多同时会有几个不同的代码版本在运行？线下环境呢？这个差别，意味着什么？

抖动

“抖动”是很难防止的，业务利用个别都有一些专门的设计可能容忍线上的基础设施层的一些”抖动“。因而，在生产环境场景里，基础设施层面每天抖 N 次、每次抖 10-20 秒，不是一个太大的问题。但这样的抖动在线下环境就是个比拟大的问题：每次抖动，都会造成测试用例的失败。这并不是因为这些用例写的不够“强壮”，而是有很多时候测试用例就是不能有防抖逻辑的。例如，如果测试用例有某种 retry 逻辑，或者测试平台会主动重跑失败的案例[4]，那么就会 miss 掉一些偶发的的 bug[5]。在线下环境里，咱们宁肯承受每周有一次 30 分钟的 outage（不可用），也不违心承受每周几十次的 10-20 秒抖动。一次 30 分钟的 outage，大不了就间接疏忽掉那段时间的所有测试后果。而每周几十次的 10-20 秒抖动意味着大量的测试乐音[6]，意味着要么是大量的额定的排查老本，要么是漏过一些问题的可能。

2 业务利用层面

业务数据

线下的数据模式和生产是不一样的。因为执行测试用例，线下的营销零碎里的以后营销流动的数量可能比生产要高一个数量级。所以营销利用要在技术层面解决好线下这个场景，如果一个营销利用会在启动的时候就加载所有的以后流动，可能就会在线下呈现很长的启动工夫。

数据的生命周期

我始终提倡的一个准则是“Test environment is ephemeral”，也就是说，线下环境的存在工夫是很短的。存在工夫短，要求 create 的成功率高、工夫短，但对数据清理要求比拟低。存在工夫长的，就要求 upgrade 的成功率高，对 create 的要求很低，对数据完整性和测试数据清理的要求十分高。持续推演上来，要做好测试数据清理，须要什么？基建层有什么技术计划？业务层须要做什么？业务层是否须要对数据进行打标？测试数据清理这件事，是放在业务层做（基建层提供原子能力），还是在基础设施层做（业务层依照标准打标）？这就是一个架构设计问题。这样的问题，要有顶层设计、架构设计，要针对场景进行设计，不能有啥用啥、对付将就。

业务流程

生产环境入驻一个商户，会通过一个人工审批流程，这个流程兴许会走两三天，有六七个审批步骤。这在线上是 OK 的，因为线上的商户入驻是绝对低频且可能承受较长的解决周期的。但在线下，因为要执行自动化的测试用例，而且要确保测试用例是“自蕴含”的，商户的创立就会是高频，而且必须疾速解决的。所以在技术层面，针对线下环境的场景，要可能“短路”掉审批流程（除非自身要测试的就是审批流程）。相似的流程还有网关的映射配置，线上的网关配置是低频的，但线下的网关配置是高频动作，而且会反反复复。

3 其余

问题排查

线上环境是有比较清楚的基线的，比拟容易把失败的交易的链路数据和胜利的交易的链路做比拟。这个做法在线下环境同样无效吗？如果不是，为什么？是什么具体的线下环境的场景差别导致的？又比如说，对日志的需要，线上线下有差别吗？

权限模型

线下数据库的权限，如果读和写的权限是绑定的、申请权限就是同时申请了读和写，就会很好受。因为工程师为了更好的做问题排查，心愿申请上下游利用的数据库读权限，但他们只须要读权限，不须要写权限。如果读写权限是绑定的，即使他们只须要读权限，也要通过繁琐的申请审批，因为波及了写权限，写权限如果不足管控，容易呈现数据常常被改乱掉的状况。读写权限申请的时候是绑定的，这在线上环境的场景下兴许是 OK 的，因为生产环境要跑 DML 自身是有工单流程的，不容易呈现数据被改乱掉的状况。但读写权限绑定在线下就不适合了。从架构和设计层面说，读写权限绑定是因为 ACL 的模型自身没有反对到那个颗粒度。

咱们始终说，做技术的要了解业务。比方，做领取零碎的，要深刻理解不同的领取场景的差别（比方，代扣、协定领取、收银台、…），能力无效的进行架构设计和技术危险保障。例如，代扣场景，没有 uid。这意味着什么？没有 uid，意味着灰度引流的做法会不一样，精准灰度的做法可能会不一样，新建机房的切流计划也会不一样。

线下环境也是相似的情理。线下环境也是一个场景。这个场景和生产是不同的场景。每一层（SaaS、PaaS、IaaS）都要粗浅的了解不同场景的差别，能力无效的把不同场景都保障好。如果一个利用、一个平台，它的设计和实现只思考了 X 场景、没有思考 Y 场景，那么它在 Y 场景下就会遇到这样那样的不难受，也会使得 Y 场景下的客户不称心。

充沛了解“线下环境”这个场景，把这个场景纳入到架构和技术实现的思考中，有助于让线下环境尽量保持稳定。

四 结语

总结一下下面所说的一些关键点：

1. 线下环境不稳固是必然的，在没有实现 TiP 之前，以后咱们能做的是尽量让它稳固一点。
2. 防止过多的抽象应用“环境问题”的说法。
3. 业务利用线下环境的基础设施必须依照生产环境标准运维。一个实现伎俩就是间接应用生产环境的基础设施。
4. stable 层首先要把单利用可用率晋升下来。单利用如果无奈做到 99.999% 或 100% 都是能调通的，链路的稳定性就是缘木求鱼、基本无从谈起。
5. 缩小 dev 环境的问题，次要有四个重点：a）做好联调集成前的自测；b）架构上的投入（契约化、可测性）；c）通过多环境、数据库隔离等伎俩缩小互相打搅；d）通过继续集成尽早裸露问题，升高问题的影响和修复老本。
6. IaC（Infrastructure-as-Code）是解题的一个关键点。
7. 线下环境是一个场景。要深刻理解线下环境和线上环境这两个不同场景的差别。

Note[1] 线下环境：这里次要讲的是互联网利用的分布式系统的线下环境。也就是通常说的“服务端”的线下环境。这是阿里团体和蚂蚁团体外面波及技术人员最多的一类线下环境。
[2] 其实，很多”脏“数据一点都不”脏“。很多时候，”脏“数据只不过是之前其他人测试和调试代码留下的数据，但这些数据的存在使得前面的执行后果不合乎咱们的预期。例如，我要测试的是一个文件打批性能，这个性能会把数据库外面尚未清理的领取都捞进去、写到一个文件里。我创立了一笔未清算的领取，而后运行打批，我预期后果是文件外面只有一条记录，但打进去理论有两条记录，不合乎我的预期。这种状况其实是我的预期有问题，是我的测试用例外面的 assert 写的有问题，或者是我的测试用例的设计、我的测试架构的设计有问题，也有可能是被测代码的可测性（testability）有问题。
[3] 这些场景的差别，兴许有人会把它们都归结为“可测性”。这样说也不是没有情理，因为测试就是线下环境最大的一个作用。但咱们还是不倡议把线下环境这个场景就间接说成“可测性”，因为“可测性”是一种能力，能力是用来撑持场景的，这就如同“可监控”是一种能力，“可监控”这种能力是用来撑持线上环境这个场景的。
[4] 咱们是坚定拥护测试平台提供主动重跑失败用例能力的，因为主动重跑对品质是无害的。主动重跑会覆盖一些 bug 和设计不合理的中央，长此以往这些问题就会积攒起来。
[5] 偶发 bug 也能够是很重大的 bug。已经有过一个 bug，这个 bug 会以 1 /16 的几率呈现。最初排查发现，起因是这段业务利用代码在解决 GUID 的时候代码逻辑有问题（而 GUID 是 16 进制编码的）。过后的 test case 只有 rerun 一下，大概率就会通过（有 15/16 的通过几率）。
[6] 有乐音的测试，比没有测试 还要蹩脚。没有测试，是零资产。有乐音的测试，是负资产。有乐音的测试，要额定搭进去很多排查的工夫，而且还会侵害大家对测试的信念（相似“狼来了”）。

作者：开发者小助手_LS
原文链接
本文为阿里云原创内容，未经容许不得转载