19、软件持续更新：策略、案例与最佳实践

软件持续更新：策略、案例与最佳实践

在当今的数字化时代，软件更新的速度和质量对于企业的成功至关重要。快速将修复程序投入生产是减轻损失的唯一途径，而在部署时间、开发时间和测试时间这三个变量中，部署时间是最容易缩短的。下面我们将深入探讨用户更新决策、不同软件的更新案例以及相关的最佳实践。

用户更新决策模型

用户在决定是否接受软件更新时，通常会考虑以下两个关键问题：
1. 是否真的需要更新 ：这并非总是非黑即白的决策。用户可以选择停留在维护版本以获取安全补丁，同时推迟可能带来更多功能但风险更高的重大升级。例如，Canonical的Ubuntu发行版，每两年发布一次长期支持（LTS）版本，提供五年的公共支持；而早期采用者可以每六个月获得一次临时版本，但这些版本的支持时间较短。
2. 更新的风险有多大 ：对于安全补丁或小版本升级，风险通常较低，可以在进行最少测试后安全投入生产。这些更改通常较小，专门设计为不触及任何外部甚至内部API，并在发布前进行测试，以确保解决安全问题且不会产生不良副作用。对于操作系统升级等情况，由于有重大更改且无法逐一验证是否会造成破坏，操作系统供应商需要花费大量时间进行不同硬件组合的测试、与应用程序供应商合作解决兼容性问题以及进行用户试用。如果更新既存在风险且发布方无法验证其安全性，则需要接收方进行验证测试，这通常是一个困难且成本高昂的过程。

graph TD;
    A{是否需要更新?} -->|是| B{更新风险大吗?};
    A -->|否| C[拒绝更新];
    B -->|低风险| D[接受更新];
    B -->|高风险| E{发布方能否验证安全?};
    E -->|能| D;
    E -->|否| F[接收方验证测试];
    F -->|安全| D;
    F -->|不安全| C;

Java六个月发布周期案例

Java历史上主要版本之间的发布周期很长，平均为1到3年，且发布频率不稳定，经常延迟。从2017年9月的Java 9开始，Oracle改为六个月的功能发布周期，旨在保持创新步伐稳定，使后续版本包含更少功能和更低风险，更易于采用。然而，实际情况并不理想，67%的Java开发人员从未升级到2014年发布的Java 8之后的版本。这背后存在以下两个主要问题：
1. Java生态系统无法适应六个月的发布周期 ：几乎所有Java项目都依赖于庞大的库和依赖项生态系统。要升级到新的Java版本，所有这些依赖项都需要更新并针对新的Java版本进行测试。对于大型开源库和复杂的应用服务器来说，在六个月的时间内完成这些工作几乎是不可能的。此外，OpenJDK支持模型仅为Java版本提供六个月的公共支持，直到下一个功能版本发布。唯一的例外是从Java 11开始每三年发布一次的长期支持版本，这些版本将从商业JDK供应商处获得安全补丁和支持。
2. 价值/成本权衡不佳 ：Java 9的主要特性是引入了新的模块系统，但该系统存在诸多问题。它的实现复杂且具有破坏性，多次延迟发布，最初还与Eclipse基金会针对企业应用发布的竞争模块系统OSGI不兼容。此外，模块化并没有得到广泛需求，要充分实现其好处，需要花费大量工作重写应用程序以实现完全模块化，并且所有依赖项都需要打包为模块。对于大多数企业应用来说，实际好处很小，因此即使升级到支持模块的版本，也很常见地会禁用模块化，回到Java 8及以前的类路径模型。

graph TD;
    A{是否升级到Java 9及以后?} --> B{是否需要模块化等新特性?};
    B -->|是| C{升级成本高吗?};
    B -->|否| D[不升级];
    C -->|低| E[升级];
    C -->|高| D;

持续更新最佳实践 - 自动化测试

自动化测试至关重要。自动化测试越多，测试运行速度越快，就越能安全地采用新功能并将其发布到生产环境中。在Java的案例中，如果能够实现更多的自动化测试，开发人员就能更快地验证新Java版本与现有依赖项的兼容性，从而更安全地进行升级。

iOS应用商店更新模式

自1990年Tim Berners - Lee创建第一个网页浏览器WorldWideWeb以来，内容更新模式发生了很大变化。早期，桌面客户端应用更新不频繁且需要手动操作，而Web应用可以通过客户端 - 服务器模型动态检索内容并持续更新。2008年，苹果的App Store改变了这一局面，为向手机和其他设备部署丰富的客户端应用提供了一种变革性的方法：
1. 一键更新 ：更新桌面应用通常需要退出运行版本，通过一系列复杂的向导选择（如桌面快捷方式、开始菜单、可选包），安装后还经常需要重启计算机。而苹果将其简化为一键更新，许多情况下还提供批量更新选项。应用更新在后台下载、安装，不会中断用户操作。
2. 仅提供最新版本 ：苹果App Store只提供最新版本的应用，用户无需选择升级到哪个版本，也无需关注版本号。一旦拥有应用，升级无需额外付费，消除了付费桌面应用升级的经济障碍。
3. 内置安全机制 ：安全漏洞是安装补丁的首要原因，但也是不升级的首要担忧。苹果通过集成沙盒模型，限制安装的应用在未获得明确许可的情况下访问数据、联系人、照片、位置、相机等功能。此外，严格的应用审核流程减少了恶意软件和应用病毒，使消费者在升级应用时无需担心安全问题。

graph TD;
    A{是否更新iOS应用?} --> B{更新是否低风险且可信?};
    B -->|是| C[更新];
    B -->|否| D[不更新];

持续更新最佳实践 - 自动更新和频繁更新

1. 自动更新 ：手动更新常常因风险或评估风险所需的时间而被跳过或推迟。最佳的更新方式是自动且安全地进行，无需用户过多干预。如果更新风险低且可信，就无需考虑功能是否值得，因为它可以在无人为干预的情况下完成。
2. 频繁更新 ：大量小而低风险的更新优于单个大而不频繁且对最终用户有风险的更新。应用商店模式鼓励频繁更新，因为小更新更容易通过验证和发布，操作系统也会展示更新的应用，增加用户参与度。

持续正常运行时间的重要性

在云计算时代，服务正常运行时间是企业成功的重要衡量标准之一。许多公司采用软件即服务（SaaS）模式，不仅要交付软件，还要负责软件运行的基础设施。服务的意外中断可能会带来巨大的成本，包括违反服务级别协议、降低客户满意度和保留率。对于构建和支持互联网基础设施的公司来说，正常运行时间尤为重要。

Cloudflare案例分析

Cloudflare是一家为全球企业提供高度可靠内容交付基础设施的公司，承诺比企业自身的基础设施或云计算服务器更快、更可靠地交付内容。然而，多年来，Cloudflare经历了多次生产问题，包括DNS中断、缓冲区溢出数据泄露和安全漏洞，其中有五次是全球性的，影响了越来越多的互联网服务。下面我们将详细分析其三次最近的全球中断事件以及相应的持续更新最佳实践。

2013年Cloudflare路由器规则中断

2013年3月3日UTC时间9:47，Cloudflare所有数据中心出现系统级中断，从互联网上掉线。此次中断是由于部署到Juniper路由器的一条错误规则引起的。该规则旨在防止正在进行的DDoS攻击，攻击数据包大小在99,971到99,985字节之间。但这条规则导致Juniper边缘路由器消耗所有RAM直至崩溃。移除违规规则解决了问题，但许多路由器无法自动重启，需要手动电源循环。

+    route 173.X.X.X/32-DNS-DROP {
+        match {
+            destination 173.X.X.X/32;
+            port 53;
+            packet-length [ 99971 99985 ];
+        }
+        then discard;
+    }

最佳实践建议 ：
- 渐进式交付 ：在分布式系统中，同时将新代码部署到所有生产节点（如路由器）会导致它们同时崩溃。可以使用金丝雀发布，先将更改部署到少数节点进行测试，发现问题后回滚受影响的节点并离线调试。
- 本地回滚 ：重新配置边缘设备可能导致它们失去互联网连接，难以或无法重置。应设计边缘设备存储最后已知的良好配置，在更新失败时恢复到该配置，以保留网络连接以便后续修复。

2019年Cloudflare正则表达式中断

2019年7月2日UTC时间13:42，Cloudflare代理的域名开始返回502“错误网关”错误，持续27分钟。此次中断的根本原因是一个错误的正则表达式，部署到Cloudflare Web应用防火墙（WAF）后导致全球处理HTTP/HTTPS流量的所有核心CPU使用率飙升。

(?:(?:\"|'|\]|\}|\\|\d|
(?:nan|infinity|true|false|null|undefined|symbol|math)|\`|\-|\+)+[)]*;?
(?:nan|infinity|true|false|null|undefined|symbol|math)|\`|\-|\+)+[)]*;?
((?:\s|-|~|!|{}|\|\||\+)*.*(?:.*=.*)))

虽然Cloudflare已经实现了复杂的渐进式交付系统，包括DOG Point - of - Presence（仅供Cloudflare员工使用的新更改第一道防线）、PIG Point - of - Presence（一小部分客户流量进入的环境，可在不影响付费客户的情况下测试新代码）和Canary Point - of - Presence（三个全球金丝雀环境，在更改推广到全球之前作为最后一道防线），但Web应用防火墙因用于快速威胁响应而绕过了这些金丝雀环境，直接部署到生产环境。该正则表达式仅通过了一系列单元测试，未检查CPU耗尽情况就被推送到生产环境。

最佳实践建议 ：
- 渐进式交付 ：此规则并非紧急修复，本可以遵循金丝雀部署流程。
- 可观测性 ：仅依靠用户反馈很难追踪某些问题，应在生产环境中实施跟踪、监控和日志记录。Cloudflare实际上曾实施过生产看门狗，旨在防止正则表达式过度使用CPU，但为了优化WAF以减少CPU使用，几周前移除了该代码。

2020年Cloudflare骨干网中断

2020年7月18日，Cloudflare再次出现生产中断，持续27分钟，影响了其总网络的50%。此次问题出在Cloudflare的骨干网上，该骨干网旨在实现故障恢复能力，但纽瓦克和芝加哥之间的故障导致亚特兰大和华盛顿特区之间的拥塞加剧。尝试修复时，执行的路由更改错误地激活了一条规则，导致亚特兰大吸引了更多流量而不是减少流量。

{master}[edit]
atl01# show | compare
[edit policy-options policy-statement 6-BBONE-OUT term 6-SITE-LOCAL
from]
!       inactive: prefix-list 6-SITE-LOCAL { ... }

from {
    prefix-list 6-SITE-LOCAL;
}
then {
    local-preference 200;
    community add SITE-LOCAL-ROUTE;
    community add ATL01;
    community add NORTH-AMERICA;
    accept;
}

通过对这些案例的分析，我们可以看到，遵循持续更新的最佳实践对于确保软件系统的稳定性和可靠性至关重要。无论是渐进式交付、本地回滚、自动化测试、自动更新还是频繁更新，都能帮助企业减少故障发生的概率，提高用户满意度，从而在竞争激烈的市场中占据优势。在实际应用中，企业应根据自身情况选择合适的更新策略和最佳实践，不断优化软件更新流程，以适应不断变化的市场需求。

软件持续更新：策略、案例与最佳实践

持续更新最佳实践总结

为了更好地理解和应用持续更新的最佳实践，我们将上述案例中涉及的最佳实践进行总结，如下表所示：
|最佳实践|问题描述|解决方案|
| ---- | ---- | ---- |
|自动化测试|手动验证新软件版本与依赖项的兼容性困难且耗时，影响新功能的采用速度|增加自动化测试，提高测试运行速度，以便安全地采用新功能并发布到生产环境|
|自动更新|手动更新常因风险或评估风险的时间而被跳过或推迟|实现自动且安全的更新，无需用户过多干预，在更新风险低且可信时自动完成|
|频繁更新|单个大而不频繁且有风险的更新对最终用户不利|提供大量小而低风险的更新，应用商店模式鼓励小更新，操作系统展示更新应用增加用户参与度|
|渐进式交付|在分布式系统中同时更新所有生产节点可能导致全部崩溃|使用金丝雀发布，先在少数节点部署更改并测试，有问题则回滚受影响节点并离线调试|
|本地回滚|重新配置边缘设备可能使其失去网络连接，难以重置|设计边缘设备存储最后已知的良好配置，在更新失败时恢复以保留网络连接|
|可观测性|仅依靠用户反馈难以追踪某些问题|在生产环境中实施跟踪、监控和日志记录，及时发现并解决潜在问题|

不同软件更新模式对比

我们对Java、iOS应用商店和Cloudflare的更新模式进行对比，以便更清晰地看到它们的特点和差异。
|软件类型|更新周期|更新风险|用户接受度影响因素|最佳实践应用情况|
| ---- | ---- | ---- | ---- | ---- |
|Java|六个月（功能版本），三年（LTS版本）|新功能和模块化引入可能带来较高风险，生态系统适配困难|生态系统适配难度、新特性价值与升级成本的权衡|自动化测试需求高，可借鉴渐进式交付和本地回滚|
|iOS应用商店|频繁|低|更新操作简单、仅提供最新版本、内置安全机制|自动更新和频繁更新优势明显|
|Cloudflare|根据需求不定|高（涉及基础设施）|更新可能导致全球网络中断|渐进式交付、可观测性和本地回滚至关重要|

graph LR
    A[Java] --> B(更新周期长、风险高、适配难)
    C[iOS应用商店] --> D(更新频繁、风险低、操作简单)
    E[Cloudflare] --> F(更新不定、风险高、影响大)
    B --> G{需加强自动化测试等}
    D --> H{发挥自动更新优势}
    F --> I{注重渐进式交付等}

如何选择合适的更新策略

企业在选择更新策略时，需要综合考虑多个因素，以下是具体的步骤和要点：
1. 评估软件类型和用途
- 如果是面向大众的消费级应用，如iOS应用商店中的应用，用户对更新的便捷性和安全性要求较高，适合采用自动更新和频繁更新的策略。
- 对于企业级软件，如Java应用，需要考虑与现有生态系统的兼容性和升级成本，可能更依赖于自动化测试和渐进式交付。
- 对于提供基础设施服务的公司，如Cloudflare，确保服务的持续正常运行时间是关键，应重点关注渐进式交付、本地回滚和可观测性。
2. 分析更新风险
- 低风险的更新可以更频繁地进行，并且可以采用自动更新的方式，减少用户的决策成本。
- 高风险的更新需要更谨慎，采用渐进式交付，先在小范围测试，确保安全后再推广到全量用户。
3. 考虑用户反馈和需求
- 了解用户对新功能的需求和对更新的接受程度，根据用户反馈调整更新策略。
- 如果用户对某些功能需求迫切，可以加快相关更新的频率；如果用户对更新的安全性担忧较大，需要加强安全机制和可观测性。

未来软件更新趋势展望

随着技术的不断发展，软件更新将呈现以下趋势：
1. 更加智能化的更新 ：利用人工智能和机器学习技术，自动分析软件的使用情况、用户反馈和系统状态，预测可能出现的问题，并自动调整更新策略。例如，根据用户的使用习惯和设备性能，智能地选择合适的更新时间和内容。
2. 跨平台统一更新 ：随着多平台应用的普及，用户希望在不同平台上能够实现统一的更新体验。未来的软件更新将更加注重跨平台的兼容性和一致性，提供无缝的更新服务。
3. 与安全防护深度融合 ：安全将始终是软件更新的重要考量因素。未来的更新将不仅仅是修复安全漏洞，还将与安全防护系统深度融合，实时监测和防范新出现的安全威胁。例如，在更新过程中自动检测并清除潜在的恶意软件。

总结

软件持续更新是一个复杂而重要的过程，涉及到技术、用户体验和业务运营等多个方面。通过分析Java、iOS应用商店和Cloudflare等不同案例，我们总结出了自动化测试、自动更新、频繁更新、渐进式交付、本地回滚和可观测性等一系列最佳实践。企业在选择更新策略时，应根据软件类型、更新风险和用户需求等因素综合考虑，选择最适合自己的方案。同时，随着技术的发展，软件更新将朝着更加智能化、跨平台统一和与安全防护深度融合的方向发展。只有不断优化更新策略，才能在竞争激烈的市场中保持优势，为用户提供更好的软件服务。