干货总览作为一名合格的码农，我们无时无刻不在挥汗如雨地开发新功能，修复bug，提升系统性能。变更发布是产品迭代的必由之路，但变更总是伴随着风险。互联网公司的重大失败往往与变革有关。超过一半的故障是由变更引入的。毫无疑问，减少变更引入的故障可以显着提高服务的稳定性。减少变更引入的故障的基本方法是规范开发流程，提高开发质量，加强QA测试流程，避免问题版本上线，防患于未然。但是由于线上环境和测试环境的差异，有些改动在测试环境下正常，但是在线上环境下就会暴露出故障。这些改动就成了薛定谔的猫，只有上线后才能揭晓是否有故障。因此，在发布过程中，跟踪检查服务的健康状态，及早发现变更引入的故障，成为发布过程中不可或缺的一环，避免系统被卷入重大故障的血案。本文将介绍百度如何对变更版本进行分级和检查，以控制变更失败的范围。分级发布，让故障影响范围在百度可控。我们使用分层发布机制来发布对在线环境的更改。分层发布将变更发布过程拆分为多个阶段，每个阶段只将变更应用于部分机器，并检查相邻两个阶段之间的服务健康度。如果发现服务的健康状况显着下降，则可以中止甚至回滚更改。在这个过程中，大多数故障都可以在最后一个阶段之前发现，因此故障通常只会影响应用了更改的部分机器，从而有效地控制了故障范围。分阶段发布分成的阶段越多，它就越能在更改完全应用之前发现问题。然而，阶段越多越好，因为每个阶段都需要一定的时间来应用更改和检查健康状况。大量的stage必然导致发布时间变长，从而降低发布效率。图1为百度内部分层发布的最佳实践方案。该方案包括5个阶段，分别为沙盒环境、单机房少量机、单机房全量机、其他所有机房少量机、全量机在所有其他计算机室。这种划分方法平衡了失败的风险和变更发布的效率，并在每个阶段制定了相应的失败止损计划，在实践中取得了很好的效果。将变更发布流程拆分为多个阶段是基础，相邻两个阶段之间的服务健康检查是核心。如果每个阶段发布后没有做服务健康检查或者检查方法无效，即使变更发布分多个阶段，最终故障也会波及到所有机器。因此，分级放行检查是否有效，直接决定了故障造成的损失大小。下面将重点介绍如何进行分层发布检查。更快更准确地检测变更潜在隐患1.人工检查，变更发布效率得不到保证人工检查是最容易想到的检查方式。当一个阶段的变更发布完成后，运维工程师会监控平台核心指标的波动，一一检查。如果发现有异常波动的指标，则认为本次变更有问题，暂停甚至回滚本次变更。在百度，运维工程师会查看CPU等系统指标和请求量等业务指标。需要检查的核心指标一般在300个以上，为了保证变更发布的效率，除了机器重启的时间，人工检查一次变更发布的时间通常只有10分钟左右。按照上述分层发布流程，一共有4个checkpoint，也就是说为了保证变更发布的效率，运维工程师需要在0.5（10*60/4/300）以内完成一次指标检查秒。我们知道，在查看指标时，不仅要看当前的波动，还要参考指标的历史波动。人工不可能在0.5秒内完成一个指标的检测。2.基于人工规则检查，阈值选择和更新是难题。每次变更发布后手动检查核心指标，既费时又费力。人工检查的经验能否转化为规则，在变更发布时根据规则进行自动检查？这是基于人为规则的自动检查。首先，根据指标的波动情况，手动为指标设置不同的阈值。当服务变更发布时，会自动启动服务健康状态检查脚本。该脚本会将当时的索引集合值与手动设置的阈值进行比较。变更可能会引入故障，停止变更，通知运维同学处理。对于图2所示的两个指标，请求量指标手动设置的阈值上限为2.2k，下限为1.5k；对于请求失败指标的个数，用户只关心指标的增加，所以指标的上限设置为20个。变更发布后，如果请求量指标在1.5k~2.2k之间波动，则判定指标正常；如果请求错误数超过了手动配置的上限20，则判断索引异常，需要中止变更。检验流程在人工规则检验的基础上实现了自动化，大大提高了变更发布的效率，节省了人工成本。然而，手动规则检查面临两个主要问题：阈值选择和阈值更新。首先，应该设置什么样的门槛，这是一个很难回答的问题。图3(a)是服务错误日志数量的指示器。阈值上限根据经验手动设置为15。发布更改后，发生的错误数。增幅明显，但没有达到人工设定的阈值。因此，本次变更引入的故障无法根据人工规则发现，导致故障波及所有机房，影响服务的稳定性。另外，手动配置阈值也不是一劳永逸的。当指标水位发生变化时，需要更新阈值。图（b）是某项服务的请求量指标。历史请求量经常维持在1.3k，阈值手动设置在1.2~1.4k。随着业务的发展，服务请求突然增加到1.6k，需要手动调整阈值。3、智能巡检，安心修改针对人工规则巡检存在阈值选择、更新困难等问题，迫切需要一种更加智能的巡检方式。我们分析了一些引入故障的变化，发现大部分故障都会导致指标的突变，而运维工程师往往会特别关注发生突变的指标。同时我们也发现，在变更场景下，指标突然发生变化并不一定代表变更引入了故障。例如，当在流量激增期间发布更改时，与流量相关的指标必然会出现峰值。再比如，在释放变更的过程中重启进程时，内存、文件句柄等指标可能会因为资源释放而突然下降。因此，智能检测算法由两部分组成：衡量指标是否发生突变，判断突变是否合理。如果某个指标在变更发布前后发生无法解释的突变，则该指标被视为异常。指标突变是否合理可以从以下两个角度来解释：突变是否是时间因素和重启引起的。由于时间因素的影响会同时作用于发生变化的机器（实验组）和没有发生变化的机器（控制组），因此可以根据控制组排除时间因素的影响；流程重启对指标的影响可以通过历史变化建模来确定。当对照组和历史变化都不能解释指标突变时，则认为指标异常，需要中止变化。智能检测无需手动配置参数，自动智能识别异常突变指标。图4给出了一个具体的例子。每行代表一个指标。对于每一个指标，展示了某一次变更发布前后的波动，对应时间对照组的波动，以及历史上该指标正常的变更发布。波动前后。对于指标①，指标在本次变动发布后出现上涨，但对照组也出现了类似的上涨，因此判断上涨是时间因素造成的，指标变动正常；对于指标②，指标在释放变动后突然下跌，历史正常变动释放后指标会突然下跌，因此判断突然下跌是进程重启导致的，指标变动正常;对于指标③，变化发布后突然增加，而对照组和历史变化发布后均未发生明显变化，即指标突变无法用对照组或历史变化解释，指标是不正常的，这需要中止甚至回滚更改。综上所述，以上是我们让变更发布更加安全高效的方法。智能校验算法是降低故障损失的核心。该算法基于历史变化和控制组，不需要手动配置参数，具有普适性。希望对大家有所帮助。如果您有任何想法和问题，欢迎与我们交流。
