一些后端开发术语（设计/开发/通信/故障/监控/服务治理/测试/发布部署/环境/CI/CD）

工欲善其事，必先利其器；士欲宣其义，必先读其书。

一. 系统开发

1.1 高内聚/低耦合

高内聚指一个软件模块是由相关性很强的代码组成，只负责一项任务，也就是常说的单一责任原则。模块的内聚反映模块内部联系的紧密程度。

模块之间联系越紧密，其耦合性就越强，模块的独立性则越差。模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息。一个完整的系统，模块与模块之间，尽可能的使其独立存在。

通常程序结构中各模块的内聚程度越高，模块间的耦合程度就越低。

1.2 过度设计

过度设计就是进行了过多的面向未来的设计或者说把相对简单的事情想复杂了，过度追求模块化、可扩展性、设计模式等，为系统增加了不必要的复杂度。

1.3 过早优化

过早指的不是在开发过程的早期，而是在还没弄清楚需求未来的变化的走向的时候。你的优化不仅可能导致你无法很好地实现新的需求，而且你对优化的预期的猜测有可能还是错的，导致实际上你除了把代码变复杂以外什么都没得到。

正确的方法是，先有质量地实现你的需求，写够testcase，然后做profile去找到性能的瓶颈，这个时候才做优化。

扩展阅读：https://blog.csdn.net/jinzhencs/article/details/50580650

1.4 重构 (Refactoring)

重构（Refactoring）就是通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。

扩展阅读：https://www.jianshu.com/p/520a7d13a7ae

1.5 破窗效应

又称破窗理论，破窗效应（Broken windows theory）是犯罪学的一个理论。此理论认为环境中的不良现象如果被放任存在，会诱使人们仿效，甚至变本加厉。一幢有少许破窗的建筑为例，如果那些窗不被修理好，可能将会有破坏者破坏更多的窗户。最终他们甚至会闯入建筑内，如果发现无人居住，也许就在那里定居或者纵火。

应用在软件工程上就是，一定不能让系统代码或者架构设计的隐患有冒头的机会，否则随着时间的推移，隐患会越来越重。反之，一个本身优质的系统，会让人不由自主的写出优质的代码。

1.6 互不信任原则

指在程序运行上下游的整个链路中，每个点都是不能保证绝对可靠的，任何一个点都可能随时发生故障或者不可预知的行为，包括机器网络、服务本身、依赖环境、输入和请求等，因此要处处设防。

扩展阅读：https://cloud.tencent.com/developer/article/1005918

7持久化 (Persistence)

持久化是将程序数据在临时状态和持久状态间转换的机制。通俗的讲，就是临时数据（比如内存中的数据，是不能永久保存的）持久化为持久数据（比如持久化至数据库或者本地磁盘中，能够长久保存）。

8临界区

临界区用来表示一种公共资源或者说是共享数据，可以被多个线程使用，但是每一次，只能有一个线程使用它，一旦临界区资源被占用，其他线程要想使用这个资源，就必须等待。

9阻塞/非阻塞

阻塞和非阻塞通常形容多线程间的相互影响。比如一个线程占用了临界区资源，那么其它所有需要这个资源的线程就必须在这个临界区中进行等待，等待会导致线程挂起。这种情况就是阻塞。此时，如果占用资源的线程一直不愿意释放资源，那么其它所有阻塞在这个临界区上的线程都不能工作。而非阻塞允许多个线程同时进入临界区。

10同步/异步

通常同步和异步是指函数/方法调用方面。

同步就是在发出一个函数调用时，在没有得到结果之前，该调用就不返回。异步调用会瞬间返回，但是异步调用瞬间返回并不代表你的任务就完成了，他会在后台起个线程继续进行任务，等任务执行完毕后通过回调callback或其他方式通知调用方。

11并发/并行

并行(parallel)
指在同一时刻，有多条指令在多个处理器上同时执行。所以无论从微观还是从宏观来看，二者都是一起执行的。
并发(concurrency)
指在同一时刻只能有一条指令执行，但多个进程指令被快速的轮换执行，使得在宏观上具有多个进程同时执行的效果，但在微观上并不是同时执行的，只是把时间分成若干段，使多个进程快速交替的执行。
扩展阅读：https://www.jianshu.com/p/cbf9588b2afb

二. 架构设计

2.1 高并发 (High Concurrency)

由于分布式系统的问世，高并发（High Concurrency）通常是指通过设计保证系统能够同时并行处理很多请求。通俗来讲，高并发是指在同一个时间点，有很多用户同时的访问同一 API 接口或者 Url 地址。它经常会发生在有大活跃用户量，用户高聚集的业务场景中。

扩展阅读：https://www.jianshu.com/p/be66a52d2b9b

2.2 高可用 (High Availability)

高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，一个系统经过专门的设计，以减少停工时间，而保持其服务的高度可用性。

扩展阅读：https://www.cnblogs.com/shizhiyi/p/7750530.html

2.3 读写分离

为了确保数据库产品的稳定性，很多数据库拥有双机热备功能。也就是，第一台数据库服务器，是对外提供增删改业务的生产服务器；第二台数据库服务器，主要进行读的操作。

2.4冷备/热备

2.4.1冷备
两个服务器，一台运行，一台不运行做为备份。这样一旦运行的服务器宕机，就把备份的服务器运行起来。冷备的方案比较容易实现，但冷备的缺点是主机出现故障时备机不会自动接管，需要主动切换服务。
2.4.2热备
即是通常所说的active/standby方式，服务器数据包括数据库数据同时往两台或多台服务器写。当active服务器出现故障的时候，通过软件诊测（一般是通过心跳诊断）将standby机器激活，保证应用在短时间内完全恢复正常使用。当一台服务器宕机后，自动切换到另一台备用机使用。
扩展阅读：https://cloud.tencent.com/developer/news/316050

2.5 异地多活

异地多活一般是指在不同城市建立独立的数据中心，“活”是相对于冷备份而言的，冷备份是备份全量数据，平时不支撑业务需求，只有在主机房出现故障的时候才会切换到备用机房，而多活，是指这些机房在日常的业务中也需要走流量，做业务支撑。

扩展阅读：https://www.cnblogs.com/jaychan/p/9242325.html

2.6负载均衡 (Load Balance)

负载均衡，是对多台服务器进行流量分发的负载均衡服务。可在多个实例间自动分配应用程序的对外服务能力，通过消除单点故障提升应用系统的可用性，让您实现更高水平的应用程序容错能力，从而无缝提供分配应用程序流量所需的负载均衡容量，为您提供高效、稳定、安全的服务。

扩展阅读：https://www.cnblogs.com/xybaby/p/7867735.html

2.7动静分离

动静分离是指在web服务器架构中，将静态页面与动态页面或者静态内容接口和动态内容接口分开不同系统访问的架构设计方法，进而提升整个服务访问性能和可维护性。

扩展阅读：https://blog.csdn.net/xuxiaopang0417/article/details/80003044

2.8集群

单台服务器的并发承载能力总是有限的，当单台服务器处理能力达到性能瓶颈的时，将多台服务器组合起来提供服务，这种组合方式称之为集群，集群中每台服务器就叫做这个集群的一个“节点”，每个节点都能提供相同的服务，从而成倍的提升整个系统的并发处理能力。

2.9 分布式

分布式系统就是将一个完整的系统按照业务功能拆分成很多独立的子系统，每个子系统就被称为“服务”，分布式系统将请求分拣和分发到不同的子系统，让不同的服务来处理不同的请求。在分布式系统中，子系统独立运行，它们之间通过网络通信连接起来实现数据互通和组合服务。

2.10 CAP理论

CAP理论，指的是在一个分布式系统中，Consistency(一致性)、Availability(可用性)、Partition Tolerance(分区容错性)，不能同时成立。

一致性：它要求在同一时刻点，分布式系统中的所有数据备份都相同或者都处于同一状态。

可用性：在系统集群的一部分节点宕机后，系统依然能够正确的响应用户的请求。

分区容错性：系统能够容忍节点之间的网络通信的故障。

简单的来说，在一个分布式系统中，最多能支持上面的两种属性。但显然既然是分布式注定我们是必然要进行分区，既然分区，我们就无法百分百避免分区的错误。因此，我们只能在一致性和可用性去作出选择。

在分布式系统中，我们往往追求的是可用性，它的重要性比一致性要高，那么如何实现高可用，这里又有一个理论，就是 BASE 理论，它给 CAP 理论做了进一步的扩充。

2.11 BASE理论

BASE 理论指出：

Basically Available（基本可用）

Soft state（软状态）

Eventually consistent（最终一致性）

BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

2.12水平扩展/垂直扩展

水平扩展 Scale Out
通过增加更多的服务器或者程序实例来分散负载，从而提升存储能力和计算能力。
垂直扩展 Scale Up
提升单机处理能力。垂直扩展的方式又有两种：
增强单机硬件性能，例如：增加CPU核数如32核，升级更好的网卡如万兆，升级更好的硬盘如SSD，扩充硬盘容量如2T，扩充系统内存如128G;
提升单机软件或者架构性能，例如：使用Cache来减少IO次数，使用异步来增加单服务吞吐量，使用无锁数据结构来减少响应时间；

2.13 平行扩容

与水平扩展类似。

集群服务器中的节点均为平行对等节点，当需要扩容时，可以通过添加更多节点以提高集群的服务能力。一般来说服务器中关键路径（如服务器中的登录、支付、核心业务逻辑等）都需要支持运行时动态平行扩容。

2.14弹性扩容

指对部署的集群进行动态在线扩容。

弹性扩容系统可以根据实际业务环境按照一定策略自动地添加更多的节点（包括存储节点、计算节点、网络节点）来增加系统容量、提高系统性能或者增强系统可靠性，或者同时完成这三个目标。

2.15 状态同步/帧同步

2.15.1状态同步
状态同步是指服务器负责计算全部的游戏逻辑，并且广播这些计算的结果，客户端仅仅负责发送玩家的操作，以及表现收到的游戏结果。状态同步安全性高，逻辑更新方便，断线重连快，但是开发效率较低，网络流量随游戏复杂度增加，服务器需要承载更大压力。
2.15.2帧同步
服务端只转发消息，不做任何逻辑处理，各客户端每秒帧数一致，在每一帧都处理同样的输入数据。帧同步需要保证系统在相同的输入下，要有相同的输出。帧同步开发效率高，流量消耗低而且稳定，对服务器的压力非常小。但是网络要求高，断线重连时间长，客户端计算压力大。
扩展阅读：https://www.cnblogs.com/little-fly/p/10034579.html

三. 网络通信

3.1连接池

预先建立一个连接缓冲池，并提供一套连接使用、分配、管理策略，使得该连接池中的连接可以得到高效、安全的复用，避免了连接频繁建立、关闭的开销。

3.2 断线重连

由于网络波动造成用户间歇性的断开与服务器的连接，待网络恢复之后服务器尝试将用户连接到上次断开时的状态和数据。

3.3会话保持

会话保持是指在负载均衡器上的一种机制，可以识别客户端与服务器之间交互过程的关连性，在作负载均衡的同时还保证一系列相关连的访问请求都会分配到一台机器上。用人话来表述就是：在一次会话过程中发起的多个请求都会落到同一台机器上。

扩展阅读：https://blog.csdn.net/li12412414/article/details/81026209

3.4长连接/短连接

通常是指TCP的长连接和短连接。

长连接就是建立TCP连接后，一直保持这个连接，一般会中间彼此发送心跳来确认对应的存在，中间会做多次业务数据传输，一般不会主动断开连接。

短连接一般指建立连接后，执行一次事务后（如：http请求），然后就关掉这个连接。

扩展阅读：https://www.cnblogs.com/gotodsp/p/6366163.html

3.5流量控制/拥塞控制

流量控制
防止发送方发的太快，耗尽接收方的资源，从而使接收方来不及处理。
拥塞控制
防止发送方发的太快，使得网络来不及处理产生拥塞，进而引起这部分乃至整个网络性能下降的现象，严重时甚至会导致网络通信业务陷入停顿。
扩展阅读：https://blog.csdn.net/dangzhangjing97/article/details/81008836

3.6惊群效应

惊群效应也有人叫做雷鸣群体效应，不过叫什么，简言之，惊群现象就是多进程（多线程）在同时阻塞等待同一个事件的时候（休眠状态），如果等待的这个事件发生，那么他就会唤醒等待的所有进程（或者线程），但是最终却只可能有一个进程（线程）获得这个时间的“控制权”，对该事件进行处理，而其他进程（线程）获取“控制权”失败，只能重新进入休眠状态，这种现象和性能浪费就叫做惊群。

扩展阅读：https://www.cnblogs.com/zafu/p/8251849.html

3.7NAT

NAT（Network Address Translation，网络地址转换），就是替换IP报文头部的地址信息。NAT通常部署在一个组织的网络出口位置，通过将内部网络IP地址替换为出口的IP地址提供公网可达性和上层协议的连接能力。

扩展阅读：https://www.cnblogs.com/imstudy/p/5458133.html

四. 故障异常

4.1宕机

宕机，一般情况下指的就是计算机主机出现意外故障而死机。其次，一些服务器例如数据库死锁也可以称为宕机，一些服务器的某些服务挂掉了，就可以这么说。

4.2 coredump

当程序出错而异常中断时，OS会把程序工作的当前状态存储成一个coredunmp文件。通常情况下coredump文件包含了程序运行时的内存，寄存器状态，堆栈指针，内存管理信息等。

扩展阅读：https://blog.csdn.net/starzpc/article/details/78262819

4.3 缓存穿透/击穿/雪崩

4.3.1缓存穿透
缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，进而给数据库带来压力。
4.3.2缓存击穿
缓存击穿是指热点key在某个时间点过期的时候，而恰好在这个时间点对这个Key有大量的并发请求过来，从而大量的请求打到db。
4.3.3缓存雪崩
缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。
与缓存击穿不同的是：存击穿是热点key失效；缓存雪崩是大量的key同时失效。
扩展阅读：http://km.oa.com/group/626/articles/show/375512

4.4 500/501/502/503/504/505

500
Internal Server Error. 内部服务错误，一般是服务器遇到意外情况，而无法完成请求。
可能原因:
1、程序错误，例如：ASP或者PHP语法错误；
2、高并发导致，系统资源限制不能打开过多的文件所致。
501
Not implemented. 服务器不理解或不支持请求的HTTP请求。
502
Bad Gateway. WEB服务器故障，可能是由于程序进程不够，请求的php-fpm已经执行，但是由于某种原因而没有执行完毕，最终导致php-fpm进程终止。
可能原因：
1、Nginx服务器，php-cgi进程数不够用；
2、PHP执行时间过长；
3、php-cgi进程死掉；
503
Service Unavailable. 服务器目前无法使用。系统维护服务器暂时的无法处理客户端的请求，这只是暂时状态。可以联系下服务器提供商。
504
Gateway Timeout. 服务器504错误表示超时，是指客户端所发出的请求没有到达网关，请求没有到可以执行的php-fpm，一般是与nginx.conf的配置有关。
505
HTTP Version Not Supported. 服务器不支持请求中所用的 HTTP 协议版本。（HTTP 版本不受支持）
除了500错误可能是程序语言错误，其余的报错，都大概可以理解为服务器或者服务器配置出现问题。

4.5内存溢出/内存泄漏

内存溢出
内存溢出（Out Of Memory）指程序申请内存时，没有足够的内存供申请者使用，或者说，给了你一块存储int类型数据的存储空间，但是你却存储long类型的数据，那么结果就是内存不够用，此时就会报错OOM,即所谓的内存溢出。
内存泄漏
内存泄漏（Memory Leak）指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。
扩展阅读：https://cloud.tencent.com/developer/article/1446591

4.6句柄泄漏

句柄泄漏是进程在调用系统文件之后，没有释放已经打开的文件句柄。

一般句柄泄漏后的现象是，机器变慢，cpu飙升，出现句柄泄漏的cgi或server的cpu使用率增加。

扩展阅读：http://km.oa.com/group/19143/articles/show/162768

4.7死锁

死锁是指两个或两个以上的线程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都抑制处于阻塞状态并无法进行下去，此时称系统处于死锁状态或系统产生了死锁。

扩展阅读：https://baike.baidu.com/item/死锁/2196938

4.8软中断/硬中断

硬中断
我们通常所说的中断指的是硬中断(hardirq)。由与系统相连的外设(比如网卡、硬盘)自动产生的。主要是用来通知操作系统系统外设状态的变化。
软中断
1.通常是硬中断服务程序对内核的中断；
2.为了满足实时系统的要求，中断处理应该是越快越好。linux为了实现这个特点，当中断发生的时候，硬中断处理那些短时间就可以完成的工作，而将那些处理事件比较长的工作，放到中断之后来完成，也就是软中断(softirq)来完成。
扩展阅读：https://www.cnblogs.com/widic/p/7392485.html

4.9毛刺

在短暂的某一刻，服务器性能指标（如流量、磁盘IO、CPU使用率等）远大于该时刻前后时间段。毛刺的出现代表这服务器资源利用不均匀，不充分，容易诱发其他更严重的问题。

4.10重放攻击

攻击者发送一个目的主机已接收过的包，来达到欺骗系统的目的，主要用于身份认证过程，破坏认证的正确性。它是一种攻击类型，这种攻击会不断恶意或欺诈性地重复一个有效的数据传输，重放攻击可以由发起者，也可以由拦截并重发该数据的敌方进行。攻击者利用网络监听或者其他方式盗取认证凭据，之后再把它重新发给认证服务器。

4.11 网络孤岛

网络孤岛指集群环境中，部分机器与整个集群失去网络连接，分裂为一个小集群并且发生数据不一致的状况。

4.12数据倾斜

对于集群系统，一般缓存是分布式的，即不同节点负责一定范围的缓存数据。我们把缓存数据分散度不够，导致大量的缓存数据集中到了一台或者几台服务节点上，称为数据倾斜。一般来说数据倾斜是由于负载均衡实施的效果不好引起的。

4.13脑裂

脑裂是指在集群系统中，部分节点之间网络不可达而引起的系统分裂，不同分裂的小集群会按照各自的状态提供服务，原本的集群会同时存在不一致的反应，造成节点之间互相争抢资源，系统混乱，数据损坏。

五. 监控告警

5.1服务监控

服务监控主要目的在服务出现问题或者快要出现问题时能够准确快速地发现以减小影响范围。

服务监控一般有多种手段，按层次可划分为：

系统层（CPU、网络状态、IO、机器负载等）
应用层（进程状态、错误日志、吞吐量等）
业务层（服务/接口的错误码、响应时间）
用户层（用户行为、舆情监控、前端埋点）

1. 全链路监控

5.1.1服务拨测

服务拨测是探测服务（应用）可用性的监控方式，通过拨测节点对目标服务进行周期性探测，主要通过可用性和响应时间来度量，拨测节点通常有异地多个。

5.1.2 节点探测

节点探测是用来发现和追踪不同的机房（数据中心）节点之间网络可用性和通畅性的监控方式，主要通过响应时间、丢包率、跳数来度量，探测方法一般是ping、mtr或其他私有协议。

5.1.3告警过滤

对某些可预知的告警进行过滤，不进入告警统计的数据，如少量爬虫访问导致的http响应500错误，业务系统自定义异常信息等。

5.1.4告警去重

当一个告警通知负责人后，在这个告警恢复之前，不会继续收到相同的告警。

5.1.5告警抑制

为了减少由于系统抖动带来的干扰，还需要实现抑制，例如服务器瞬间高负载，可能是正常的，只有持续一段时间的高负载才需要得到重视。

5.1.6告警恢复

开发/运维人员不仅需要收到告警通知，还需要收到故障消除告警恢复正常的通知。

5.1.7告警合并

对同一时刻产生的多条相同告警进行合并，如某个微服务集群同一时刻出现多个子服务负载过高的告警，需要合并成为一条告警。

5.1.8告警收敛

有时某个告警产生时，往往会伴随着其它告警。这时可以只对根本原因产生告警，其它告警收敛为子告警一并发送通知。如云服务器出现CPU负载告警时往往伴随其搭载的所有系统的可用性告警。

5.1.9故障自愈

实时发现告警，预诊断分析，自动恢复故障，并打通周边系统实现整个流程的闭环。

六. 服务治理

6.1 微服务

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通（通常是基于HTTP的Restful API).每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。

扩展阅读：https://www.jianshu.com/p/009d98e30b2a

6.2服务发现

服务发现是指使用一个注册中心来记录分布式系统中的全部服务的信息，以便其他服务能够快速的找到这些已注册的服务。服务发现是支撑大规模 SOA 和微服务架构的核心模块，它应该尽量做到高可用。

扩展阅读：https://blog.csdn.net/u011714033/article/details/94395175

6.3流量削峰

如果观看抽奖或秒杀系统的请求监控曲线，你就会发现这类系统在活动开放的时间段内会出现一个波峰，而在活动未开放时，系统的请求量、机器负载一般都是比较平稳的。为了节省机器资源，我们不可能时时都提供最大化的资源能力来支持短时间的高峰请求。所以需要使用一些技术手段，来削弱瞬时的请求高峰，让系统吞吐量在高峰请求下保持可控。

削峰也可用于消除毛刺，使服务器资源利用更加均衡和充分。

常见的削峰策略有队列，限频，分层过滤，多级缓存等。

扩展阅读：https://www.jianshu.com/p/6746140bbb76

6.4版本兼容

在升级版本的过程中，需要考虑升级版本后，新的数据结构是否能够理解和解析旧数据，新修改的协议是否能够理解旧的协议以及做出预期内合适的处理。这就需要在服务设计过程中做好版本兼容。

6.5 过载保护

过载是指当前负载已经超过了系统的最大处理能力，过载的出现，会导致部分服务不可用，如果处置不当，极有可能引起服务完全不可用，乃至雪崩。过载保护正是针对这种异常情况做的措施，防止出现服务完全不可用的现象。

6.6服务熔断

服务熔断的作用类似于我们家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。

6.7服务降级

服务降级是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。降级往往会指定不同的级别，面临不同的异常等级执行不同的处理。

根据服务方式：可以拒接服务，可以延迟服务，也有时候可以随机服务。

根据服务范围：可以砍掉某个功能，也可以砍掉某些模块。

总之服务降级需要根据不同的业务需求采用不同的降级策略。主要的目的就是服务虽然有损但是总比没有好。

6.8熔断VS降级: 相同点
目标一致：都是从可用性和可靠性出发，为了防止系统崩溃；
用户体验类似：最终都让用户体验到的是某些功能暂时不可用；; 不同点：
触发原因不同：服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；

6.9服务限流

限流可以认为服务降级的一种，限流就是限制系统的输入和输出流量已达到保护系统的目的。一般来说系统的吞吐量是可以被测算的，为了保证系统的稳定运行，一旦达到的需要限制的阈值，就需要限制流量并采取一些措施以完成限制流量的目的。比如：延迟处理，拒绝处理，或者部分拒绝处理等等。

扩展阅读：https://blog.csdn.net/jek123456/article/details/79901035

6.10故障屏蔽

将故障机器从集群剔除，以保证新的请求不会分发到故障机器。

七. 测试方法

7.1 黑盒/白盒测试

黑盒测试不考虑程序内部结构和逻辑结构，主要是用来测试系统的功能是否满足需求规格说明书。一般会有一个输入值，一个输入值，和期望值做比较。

白盒测试主要应用在单元测试阶段，主要是对代码级的测试，针对程序内部逻辑结构，测试手段有：语句覆盖、判定覆盖、条件覆盖、路径覆盖、条件组合覆盖

7.2 单元/集成/系统/验收测试

软件测试一般分为4个阶段：单元测试、集成测试、系统测试、验收测试。

7.2.1 单元测试

单元测试是对软件中的最小可验证单元进行检查和验证，如一个模块、一个过程、一个方法等。
单元测试粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。

7.2.2 集成测试

集成测试也叫做组装测试，通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。
集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既验证“设计”，又验证“需求”。

7.2.3 系统测试

系统测试时将经过集成测试的软件，作为计算机系统的一部分，与系统中其他部分结合起来，在实际运行环境下进行一系列严格有效的测试，以发现软件潜在的问题，保证系统的正常运行。
系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。

7.2.4验收测试

验收测试也称交付测试，是针对用户需求、业务流程进行的正式的测试，以确定系统是否满足验收标准，由用户、客户或其他授权机构决定是否接受系统。
验收测试与系统测试相似，主要区别是测试人员不同，验收测试由用户执行。
扩展阅读：https://blog.csdn.net/lb838315586/article/details/85099064

7.2.5回归测试

当发现并修改缺陷后，或在软件中添加新的功能后，重新测试。用来检查被发现的缺陷是否被改正，并且所做的修改没有引发新的问题。

7.2.6冒烟测试

这一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。在软件中，“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。

冒烟测试是在软件开发过程中的一种针对软件版本包的快速基本功能验证策略，是对软件基本功能进行确认验证的手段，并非对软件版本包的深入测试。

比如：对于一个登录系统的冒烟测试，我们只需测试输入正确的用户名、密码，验证登录这一个核心功能点，至于输入框、特殊字符等，可以在冒烟测试之后进行。

7.2.7性能测试

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。

7.2.7.1通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。

7.2.7.2压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。

7.2.8基准测试

基准测试（Benchmark）也是一种性能测试方式，用来测量机器的硬件最高实际运行性能，以及软件优化的性能提升效果, 同时也可以用来识别某段代码的CPU或者内存效率问题. 许多开发人员会用基准测试来测试不同的并发模式, 或者用基准测试来辅助配置工作池的数量, 以保证能最大化系统的吞吐量.

7.2.9 A/B测试

A/B测试，是用两组及以上随机分配的、数量相似的样本进行对比，如果实验组和对比组的实验结果相比，在目标指标上具有统计显著性，那就可以说明实验组的功能可以导致你想要的结果，从而帮你验证假设或者做出产品决定。

扩展阅读：https://www.jianshu.com/p/32cde5a205c9

7.2.10代码覆盖测试

代码覆盖（Code coverage）是软件测试中的一种度量，描述程式中源代码被测试的比例和程度，所得比例称为代码覆盖率。

在做单元测试时，代码覆盖率常常被拿来作为衡量测试好坏的指标，甚至，用代码覆盖率来考核测试任务完成情况，比如，代码覆盖率必须达到80%或 90%。于是乎，测试人员费尽心思设计案例覆盖代码。

扩展阅读：https://blog.csdn.net/shenggaofei/article/details/52905428

八. 发布部署

DEV/PRO/FAT/UAT
DEV
Development environment
开发环境，用于开发人员调试使用，版本变化较大。
FAT
Feature Acceptance Test environment
功能验收测试环境，用于软件测试人员测试使用。
UAT
User Acceptance Test environment
用户验收测试环境，用于生产环境下的功能验证，可作为预发布环境。
PRO
Production environment
生产环境，正式线上环境。
扩展阅读：https://www.cnblogs.com/chengkanghua/p/10607239.html

灰度发布

灰度发布是指在升级版本过程中，通过分区控制，白名单控制等方式对一部分用户先升级产品特性，而其余用户则保持不变，当一段时间后升级产品特性的用户没有反馈问题，就逐步扩大范围，最终向所有用户开放新版本特性，灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、修改问题，以保证其影响度。

回滚 (Rollback)

指的是程序或数据处理错误时，将程序或数据恢复到上一次正确状态(或者是上一个稳定版本)的行为。

九. CI/CD

在软件开发中经常会提到**持续集成Continuous Integration（CI）和持续交付Continuous Delivery（CD）**这几个术语。但它们真正的意思是什么呢？

在谈论软件开发时，经常会提到持续集成Continuous Integration（CI）和持续交付Continuous Delivery（CD）这几个术语。但它们真正的意思是什么呢？在本文中，我将解释这些和相关术语背后的含义和意义，例如持续测试Continuous Testing和持续部署Continuous Deployment。

概览
工厂里的装配线以快速、自动化、可重复的方式从原材料生产出消费品。同样，软件交付管道以快速、自动化和可重复的方式从源代码生成发布版本。如何完成这项工作的总体设计称为“持续交付”（CD）。启动装配线的过程称为“持续集成”（CI）。确保质量的过程称为“持续测试”，将最终产品提供给用户的过程称为“持续部署”。一些专家让这一切简单、顺畅、高效地运行，这些人被称为运维开发DevOps践行者。

“持续”是什么意思？
“持续”用于描述遵循我在此提到的许多不同流程实践。这并不意味着“一直在运行”，而是“随时可运行”。在软件开发领域，它还包括几个核心概念/最佳实践。这些是：

频繁发布：持续实践背后的目标是能够频繁地交付高质量的软件。此处的交付频率是可变的，可由开发团队或公司定义。对于某些产品，一季度、一个月、一周或一天交付一次可能已经足够频繁了。对于另一些来说，一天可能需要多次交付也是可行的。所谓持续也有“偶尔、按需”的方面。最终目标是相同的：在可重复、可靠的过程中为最终用户提供高质量的软件更新。通常，这可以通过很少甚至无需用户的交互或掌握的知识来完成（想想设备更新）。
自动化流程：实现此频率的关键是用自动化流程来处理软件生产中的方方面面。这包括构建、测试、分析、版本控制，以及在某些情况下的部署。
可重复：如果我们使用的自动化流程在给定相同输入的情况下始终具有相同的行为，则这个过程应该是可重复的。也就是说，如果我们把某个历史版本的代码作为输入，我们应该得到对应相同的可交付产出。这也假设我们有相同版本的外部依赖项（即我们不创建该版本代码使用的其它交付物）。理想情况下，这也意味着可以对管道中的流程进行版本控制和重建（请参阅稍后的 DevOps 讨论）。
快速迭代：“快速”在这里是个相对术语，但无论软件更新/发布的频率如何，预期的持续过程都会以高效的方式将源代码转换为交付物。自动化负责大部分工作，但自动化处理的过程可能仍然很慢。例如，对于每天需要多次发布候选版更新的产品来说，一轮集成测试integrated testing下来耗时就要大半天可能就太慢了。
什么是“持续交付管道”？
将源代码转换为可发布产品的多个不同的任务task和作业job通常串联成一个软件“管道”，一个自动流程成功完成后会启动管道中的下一个流程。这些管道有许多不同的叫法，例如持续交付管道、部署管道和软件开发管道。大体上讲，程序管理者在管道执行时管理管道各部分的定义、运行、监控和报告。

持续交付管道是如何工作的？
软件交付管道的实际实现可以有很大不同。有许多程序可用在管道中，用于源代码跟踪、构建、测试、指标采集，版本管理等各个方面。但整体工作流程通常是相同的。单个业务流程/工作流应用程序管理整个管道，每个流程作为独立的作业运行或由该应用程序进行阶段管理。通常，在业务流程中，这些独立作业是以应用程序可理解并可作为工作流程管理的语法和结构定义的。

这些作业被用于一个或多个功能（构建、测试、部署等）。每个作业可能使用不同的技术或多种技术。关键是作业是自动化的、高效的，并且可重复的。如果作业成功，则工作流管理器将触发管道中的下一个作业。如果作业失败，工作流管理器会向开发人员、测试人员和其他人发出警报，以便他们尽快纠正问题。这个过程是自动化的，所以比手动运行一组过程可更快地找到错误。这种快速排错称为快速失败fail fast，并且在抵达管道端点方面同样有价值。

“快速失败”是什么意思？
管道的工作之一就是快速处理变更。另一个是监视创建发布的不同任务/作业。由于编译失败或测试未通过的代码可以阻止管道继续运行，因此快速通知用户此类情况非常重要。快速失败指的是在管道流程中尽快发现问题并快速通知用户的方式，这样可以及时修正问题并重新提交代码以便使管道再次运行。通常在管道流程中可通过查看历史记录来确定是谁做了那次修改并通知此人及其团队。

所有持续交付管道都应该被自动化吗？
管道的几乎所有部分都是应该自动化的。对于某些部分，有一些人为干预/互动的地方可能是有意义的。一个例子可能是用户验收测试user-acceptance testing（让最终用户试用软件并确保它能达到他们想要/期望的水平）。另一种情况可能是部署到生产环境时用户希望拥有更多的人为控制。当然，如果代码不正确或不能运行，则需要人工干预。

有了对“持续”含义理解的背景，让我们看看不同类型的持续流程以及它们在软件管道上下文中的含义。

什么是“持续集成”？
持续集成（CI）是在源代码变更后自动检测、拉取、构建和（在大多数情况下）进行单元测试的过程。持续集成是启动管道的环节（尽管某些预验证 —— 通常称为上线前检查pre-flight checks —— 有时会被归在持续集成之前）。

持续集成的目标是快速确保开发人员新提交的变更是好的，并且适合在代码库中进一步使用。

持续集成是如何工作的？
持续集成的基本思想是让一个自动化过程监测一个或多个源代码仓库是否有变更。当变更被推送到仓库时，它会监测到更改、下载副本、构建并运行任何相关的单元测试。

持续集成如何监测变更？
目前，监测程序通常是像 Jenkins 这样的应用程序，它还协调管道中运行的所有（或大多数）进程，监视变更是其功能之一。监测程序可以以几种不同方式监测变更。这些包括：

轮询：监测程序反复询问代码管理系统，“代码仓库里有什么我感兴趣的新东西吗？”当代码管理系统有新的变更时，监测程序会“唤醒”并完成其工作以获取新代码并构建/测试它。
定期：监测程序配置为定期启动构建，无论源码是否有变更。理想情况下，如果没有变更，则不会构建任何新内容，因此这不会增加额外的成本。
推送：这与用于代码管理系统检查的监测程序相反。在这种情况下，代码管理系统被配置为提交变更到仓库时将“推送”一个通知到监测程序。最常见的是，这可以以 webhook 的形式完成 —— 在新代码被推送时一个挂勾hook的程序通过互联网向监测程序发送通知。为此，监测程序必须具有可以通过网络接收 webhook 信息的开放端口。
什么是“预检查”（又称“上线前检查”）？
在将代码引入仓库并触发持续集成之前，可以进行其它验证。这遵循了最佳实践，例如测试构建test build和代码审查code review。它们通常在代码引入管道之前构建到开发过程中。但是一些管道也可能将它们作为其监控流程或工作流的一部分。

例如，一个名为 Gerrit 的工具允许在开发人员推送代码之后但在允许进入（Git 远程）仓库之前进行正式的代码审查、验证和测试构建。Gerrit 位于开发人员的工作区和 Git 远程仓库之间。它会“接收”来自开发人员的推送，并且可以执行通过/失败验证以确保它们在被允许进入仓库之前的检查是通过的。这可以包括检测新变更并启动构建测试（CI 的一种形式）。它还允许开发者在那时进行正式的代码审查。这种方式有一种额外的可信度评估机制，即当变更的代码被合并到代码库中时不会破坏任何内容。

什么是“单元测试”？
单元测试（也称为“提交测试”），是由开发人员编写的小型的专项测试，以确保新代码独立工作。“独立”这里意味着不依赖或调用其它不可直接访问的代码，也不依赖外部数据源或其它模块。如果运行代码需要这样的依赖关系，那么这些资源可以用模拟mock来表示。模拟是指使用看起来像资源的代码存根code stub，可以返回值，但不实现任何功能。

在大多数组织中，开发人员负责创建单元测试以证明其代码正确。事实上，一种称为测试驱动开发test-driven develop（TDD）的模型要求将首先设计单元测试作为清楚地验证代码功能的基础。因为这样的代码可以更改速度快且改动量大，所以它们也必须执行很快。

由于这与持续集成工作流有关，因此开发人员在本地工作环境中编写或更新代码，并通单元测试来确保新开发的功能或方法正确。通常，这些测试采用断言形式，即函数或方法的给定输入集产生给定的输出集。它们通常进行测试以确保正确标记和处理出错条件。有很多单元测试框架都很有用，例如用于 Java 开发的 JUnit。

什么是“持续测试”？
持续测试是指在代码通过持续交付管道时运行扩展范围的自动化测试的实践。单元测试通常与构建过程集成，作为持续集成阶段的一部分，并专注于和其它与之交互的代码隔离的测试。

除此之外，可以有或者应该有各种形式的测试。这些可包括：

集成测试验证组件和服务组合在一起是否正常。
功能测试验证产品中执行功能的结果是否符合预期。
验收测试根据可接受的标准验证产品的某些特征。如性能、可伸缩性、抗压能力和容量。
所有这些可能不存在于自动化的管道中，并且一些不同类型的测试分类界限也不是很清晰。但是，在交付管道中持续测试的目标始终是相同的：通过持续的测试级别证明代码的质量可以在正在进行的发布中使用。在持续集成快速的原则基础上，第二个目标是快速发现问题并提醒开发团队。这通常被称为快速失败。

除了测试之外，还可以对管道中的代码进行哪些其它类型的验证？
除了测试是否通过之外，还有一些应用程序可以告诉我们测试用例执行（覆盖）的源代码行数。这是一个可以衡量代码量指标的例子。这个指标称为代码覆盖率code-coverage，可以通过工具（例如用于 Java 的 JaCoCo）进行统计。

还有很多其它类型的指标统计，例如代码行数、复杂度以及代码结构对比分析等。诸如 SonarQube 之类的工具可以检查源代码并计算这些指标。此外，用户还可以为他们可接受的“合格”范围的指标设置阈值。然后可以在管道中针对这些阈值设置一个检查，如果结果不在可接受范围内，则流程终端上。SonarQube 等应用程序具有很高的可配置性，可以设置仅检查团队感兴趣的内容。

什么是“持续交付”？
持续交付（CD）通常是指整个流程链（管道），它自动监测源代码变更并通过构建、测试、打包和相关操作运行它们以生成可部署的版本，基本上没有任何人为干预。

持续交付在软件开发过程中的目标是自动化、效率、可靠性、可重复性和质量保障（通过持续测试）。

持续交付包含持续集成（自动检测源代码变更、执行构建过程、运行单元测试以验证变更），持续测试（对代码运行各种测试以保障代码质量），和（可选）持续部署（通过管道发布版本自动提供给用户）。

如何在管道中识别/跟踪多个版本？
版本控制是持续交付和管道的关键概念。持续意味着能够经常集成新代码并提供更新版本。但这并不意味着每个人都想要“最新、最好的”。对于想要开发或测试已知的稳定版本的内部团队来说尤其如此。因此，管道创建并轻松存储和访问的这些版本化对象非常重要。

在管道中从源代码创建的对象通常可以称为工件artifact。工件在构建时应该有应用于它们的版本。将版本号分配给工件的推荐策略称为语义化版本控制semantic versioning。（这也适用于从外部源引入的依赖工件的版本。）

语义版本号有三个部分：主要版本major、次要版本minor 和补丁版本patch。（例如，1.4.3 反映了主要版本 1，次要版本 4 和补丁版本 3。）这个想法是，其中一个部分的更改表示工件中的更新级别。主要版本仅针对不兼容的 API 更改而递增。当以向后兼容backward-compatible的方式添加功能时，次要版本会增加。当进行向后兼容的版本 bug 修复时，补丁版本会增加。这些是建议的指导方针，但只要团队在整个组织内以一致且易于理解的方式这样做，团队就可以自由地改变这种方法。例如，每次为发布完成构建时增加的数字可以放在补丁字段中。

如何“分销”工件？
团队可以为工件分配分销promotion级别以指示适用于测试、生产等环境或用途。有很多方法。可以用 Jenkins 或 Artifactory 等应用程序进行分销。或者一个简单的方案可以在版本号字符串的末尾添加标签。例如，-snapshot 可以指示用于构建工件的代码的最新版本（快照）。可以使用各种分销策略或工具将工件“提升”到其它级别，例如 -milestone 或 -production，作为工件稳定性和完备性版本的标记。

如何存储和访问多个工件版本？
从源代码构建的版本化工件可以通过管理工件仓库artifact repository的应用程序进行存储。工件仓库就像构建工件的版本控制工具一样。像 Artifactory 或 Nexus 这类应用可以接受版本化工件，存储和跟踪它们，并提供检索的方法。

管道用户可以指定他们想要使用的版本，并在这些版本中使用管道。

什么是“持续部署”？
持续部署（CD）是指能够自动提供持续交付管道中发布版本给最终用户使用的想法。根据用户的安装方式，可能是在云环境中自动部署、app 升级（如手机上的应用程序）、更新网站或只更新可用版本列表。

这里的一个重点是，仅仅因为可以进行持续部署并不意味着始终部署来自管道的每组可交付成果。它实际上指，通过管道每套可交付成果都被证明是“可部署的”。这在很大程度上是由持续测试的连续级别完成的（参见本文中的持续测试部分）。

管道构建的发布成果是否被部署可以通过人工决策，或利用在完全部署之前“试用”发布的各种方法来进行控制。

在完全部署到所有用户之前，有哪些方法可以测试部署？
由于必须回滚/撤消对所有用户的部署可能是一种代价高昂的情况（无论是技术上还是用户的感知），已经有许多技术允许“尝试”部署新功能并在发现问题时轻松“撤消”它们。这些包括：

蓝/绿测试/部署
在这种部署软件的方法中，维护了两个相同的主机环境 —— 一个“蓝色” 和一个“绿色”。（颜色并不重要，仅作为标识。）对应来说，其中一个是“生产环境”，另一个是“预发布环境”。

在这些实例的前面是调度系统，它们充当产品或应用程序的客户“网关”。通过将调度系统指向蓝色或绿色实例，可以将客户流量引流到期望的部署环境。通过这种方式，切换指向哪个部署实例（蓝色或绿色）对用户来说是快速，简单和透明的。

当新版本准备好进行测试时，可以将其部署到非生产环境中。在经过测试和批准后，可以更改调度系统设置以将传入的线上流量指向它（因此它将成为新的生产站点）。现在，曾作为生产环境实例可供下一次候选发布使用。

同理，如果在最新部署中发现问题并且之前的生产实例仍然可用，则简单的更改可以将客户流量引流回到之前的生产实例 —— 有效地将问题实例“下线”并且回滚到以前的版本。然后有问题的新实例可以在其它区域中修复。

金丝雀测试/部署
在某些情况下，通过蓝/绿发布切换整个部署可能不可行或不是期望的那样。另一种方法是为金丝雀canary测试/部署。在这种模型中，一部分客户流量被重新引流到新的版本部署中。例如，新版本的搜索服务可以与当前服务的生产版本一起部署。然后，可以将 10％的搜索查询引流到新版本，以在生产环境中对其进行测试。

如果服务那些流量的新版本没问题，那么可能会有更多的流量会被逐渐引流过去。如果仍然没有问题出现，那么随着时间的推移，可以对新版本增量部署，直到 100％的流量都调度到新版本。这有效地“更替”了以前版本的服务，并让新版本对所有客户生效。

功能开关
对于可能需要轻松关掉的新功能（如果发现问题），开发人员可以添加功能开关feature toggles。这是代码中的 if-then 软件功能开关，仅在设置数据值时才激活新代码。此数据值可以是全局可访问的位置，部署的应用程序将检查该位置是否应执行新代码。如果设置了数据值，则执行代码；如果没有，则不执行。

这为开发人员提供了一个远程“终止开关”，以便在部署到生产环境后发现问题时关闭新功能。

暗箱发布
在暗箱发布dark launch中，代码被逐步测试/部署到生产环境中，但是用户不会看到更改（因此名称中有暗箱dark一词）。例如，在生产版本中，网页查询的某些部分可能会重定向到查询新数据源的服务。开发人员可收集此信息进行分析，而不会将有关接口，事务或结果的任何信息暴露给用户。

这个想法是想获取候选版本在生产环境负载下如何执行的真实信息，而不会影响用户或改变他们的经验。随着时间的推移，可以调度更多负载，直到遇到问题或认为新功能已准备好供所有人使用。实际上功能开关标志可用于这种暗箱发布机制。

什么是“运维开发”？
运维开发DevOps 是关于如何使开发和运维团队更容易合作开发和发布软件的一系列想法和推荐的实践。从历史上看，开发团队研发了产品，但没有像客户那样以常规、可重复的方式安装/部署它们。在整个周期中，这组安装/部署任务（以及其它支持任务）留给运维团队负责。这经常导致很多混乱和问题，因为运维团队在后期才开始介入，并且必须在短时间内完成他们的工作。同样，开发团队经常处于不利地位 —— 因为他们没有充分测试产品的安装/部署功能，他们可能会对该过程中出现的问题感到惊讶。

这往往导致开发和运维团队之间严重脱节和缺乏合作。DevOps 理念主张是贯穿整个开发周期的开发和运维综合协作的工作方式，就像持续交付那样。

持续交付如何与运维开发相交？
持续交付管道是几个 DevOps 理念的实现。产品开发的后期阶段（如打包和部署）始终可以在管道的每次运行中完成，而不是等待产品开发周期中的特定时间。同样，从开发到部署过程中，开发和运维都可以清楚地看到事情何时起作用，何时不起作用。要使持续交付管道循环成功，不仅要通过与开发相关的流程，还要通过与运维相关的流程。

说得更远一些，DevOps 建议实现管道的基础架构也会被视为代码。也就是说，它应该自动配置、可跟踪、易于修改，并在管道发生变化时触发新一轮运行。这可以通过将管道实现为代码来完成。

什么是“管道即代码”？
管道即代码pipeline-as-code是通过编写代码创建管道作业/任务的通用术语，就像开发人员编写代码一样。它的目标是将管道实现表示为代码，以便它可以与代码一起存储、评审、跟踪，如果出现问题并且必须终止管道，则可以轻松地重建。有几个工具允许这样做，如 Jenkins 2。

DevOps 如何影响生产软件的基础设施？
传统意义上，管道中使用的各个硬件系统都有配套的软件（操作系统、应用程序、开发工具等）。在极端情况下，每个系统都是手工设置来定制的。这意味着当系统出现问题或需要更新时，这通常也是一项自定义任务。这种方法违背了持续交付的基本理念，即具有易于重现和可跟踪的环境。

多年来，很多应用被开发用于标准化交付（安装和配置）系统。同样，虚拟机virtual machine被开发为模拟在其它计算机之上运行的计算机程序。这些 VM 要有管理程序才能在底层主机系统上运行，并且它们需要自己的操作系统副本才能运行。

后来有了容器container。容器虽然在概念上与 VM 类似，但工作方式不同。它们只需使用一些现有的操作系统结构来划分隔离空间，而不需要运行单独的程序和操作系统的副本。因此，它们的行为类似于 VM 以提供隔离但不需要过多的开销。

VM 和容器是根据配置定义创建的，因此可以轻易地销毁和重建，而不会影响运行它们的主机系统。这允许运行管道的系统也可重建。此外，对于容器，我们可以跟踪其构建定义文件的更改 —— 就像对源代码一样。

因此，如果遇到 VM 或容器中的问题，我们可以更容易、更快速地销毁和重建它们，而不是在当前环境尝试调试和修复。

这也意味着对管道代码的任何更改都可以触发管道新一轮运行（通过 CI），就像对代码的更改一样。这是 DevOps 关于基础架构的核心理念之一。