线下环境为何不稳定？

• 么办?怎么让它尽量稳定一点?

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

如果没有时间读完全文的话，这里是本文的主要观点：

1. 线下环境不稳定是必然的，在没有实现TiP之前，当前我们能做的是尽量让它稳定一点。

2. 避免过多的笼统使用”环境问题“的说法。

3. 业务应用线下环境的基础设施必须按照生产环境标准运维。一个实现手段就是直接使用生产环境的基础设施。

4. stable层首先要把单应用可用率提升上去。单应用如果无法做到99.999%或100% 都是能调通的，链路的稳定性就是缘木求鱼、根本无从谈起。

5. 减少dev环境的问题，主要有四个重点：

• 做好联调集成前的自测;
• 架构上的投入(契约化、可测性);
• 通过多环境、数据库隔离等手段减少相互打扰;
• 通过持续集成尽早暴露问题，降低问题的影响和修复成本。

6. IaC(Infrastructure-as-Code)是解题的一个关键点。

7. 线下环境是一个场景。要深刻理解线下环境和线上环境这两个不同场景的差异。

以下是正文：

一 线下环境不稳定的必然性

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

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

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

• 线下环境里面有不稳定的代码
• 线下环境不稳定带来的影响小

这两个原因是相互有关系的：我们需要有一个地方运行不稳定的代码，但我们怕不稳定的代码引起很大的问题，所以我们需要这个地方是低利害关系的(low-stakes);因为这个地方是低利害关系的，所以对它的问题我们必然是低优先级处理的。

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

之所以Testing-in-Production(TiP)是一条出路，就是因为TiP把这两个根源中的一个(即第二点)给消除了：production不稳定带来的影响是很大的。但TiP注定是一条很漫长且艰难的道路，因为我们怕不稳定的代码引起很大的问题。我们需要首先在技术上有充分的能力充分确保不稳定的代码也不会引起很大的问题。这是很有难度的，今天我们还没有100%的信心做到能充分确保稳定的代码不会引起很大的问题。

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

对策还是要有的。否则，线下环境太不稳定了，大家就都放弃了，不用了，直接跳过，直接把还不太稳定的代码部署到预发环境(pre-production)去了。把预发环境当线下环境用，结果就是预发环境也被搞得像线下环境那样不稳定了。这样再发展下去，预发环境越来越不稳定了，我们还有地方可以去吗?所以，还是要有一整套对策让线下环境尽量稳定一点。

（编辑：开发网_开封站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!