软件可靠性可能看起来像是一个现代挑战，但工程师们解决这类问题已有很长的历史。

在这篇文章中，@manishmshiva 探讨了软件工程师可以从制造业和其他工程学科中学到什么。

你将了解冗余、根本原因分析、真实测试和可观测性如何帮助你构建更有韧性的系统。

https://freecodecamp.org/news/from-manufacturing-to-microservices-universal-lessons-about-reliability/…

从制造业到微服务：关于可靠性的普适经验

来源：https://www.freecodecamp.org/news/from-manufacturing-to-microservices-universal-lessons-about-reliability/ 从制造业到微服务：关于可靠性的普适经验

软件工程师常常认为可靠性是一个现代挑战。

我们讨论正常运行时间、分布式系统、可观测性和容错性，仿佛这些只属于云计算领域。

实际上，工程师们解决可靠性问题已有数百年历史。制造工厂、土木工程项目和工业流水线都面临过同一个根本问题：当单个组件失效时，如何构建仍然能正常工作的系统？

无论是搭建桥梁、制造车辆，还是部署微服务架构，可靠性从来都不是偶然的。它来自于深思熟虑的设计、持续的测试，以及从失败中学习的意愿。

技术变了，但工程原则始终惊人地一致。

在本文中，我们将探讨那些让系统——无论是工厂流水线还是云原生应用——保持可靠的永恒工程原则。

你将看到冗余、根本原因分析、真实测试和可观测性这些概念如何指导了工程师数十年，以及为什么这些经验在构建现代软件时同样宝贵。

到最后，你将对可靠性有更广阔的视角，并收获可以应用于设计更有韧性的系统的实用想法。

我们将涵盖：

• 每个系统的可靠性取决于其最薄弱的环节 (https://www.freecodecamp.org/news/from-manufacturing-to-microservices-universal-lessons-about-reliability/#heading-every-system-is-only-as-reliable-as-its-weakest-link)
• 小缺陷变成大问题 (https://www.freecodecamp.org/news/from-manufacturing-to-microservices-universal-lessons-about-reliability/#heading-small-defects-become-big-problems)
• 根本原因分析比找人背锅更重要 (https://www.freecodecamp.org/news/from-manufacturing-to-microservices-universal-lessons-about-reliability/#heading-root-cause-analysis-is-more-important-than-finding-someone-to-blame)
• 冗余是投资，不是浪费 (https://www.freecodecamp.org/news/from-manufacturing-to-microservices-universal-lessons-about-reliability/#heading-redundancy-is-an-investment-not-a-waste)
• 测试应模拟真实情况 (https://www.freecodecamp.org/news/from-manufacturing-to-microservices-universal-lessons-about-reliability/#heading-testing-should-simulate-reality)
• 可观测性优于瞎猜 (https://www.freecodecamp.org/news/from-manufacturing-to-microservices-universal-lessons-about-reliability/#heading-observability-is-better-than-guesswork)
• 可靠性是一个持续的过程 (https://www.freecodecamp.org/news/from-manufacturing-to-microservices-universal-lessons-about-reliability/#heading-reliability-is-a-continuous-process)
• 优秀的工程是可预测的工程 (https://www.freecodecamp.org/news/from-manufacturing-to-microservices-universal-lessons-about-reliability/#heading-great-engineering-is-predictable-engineering)

每个系统的可靠性取决于其最薄弱的环节

一个现代应用可能由几十甚至上百个服务组成。每个服务依赖于数据库、API、队列、缓存、存储系统和网络基础设施。这些组件中任何一个失效，都可能波及整个应用。

制造系统的工作方式非常相似。一个设计完美的产品，如果某个组件安装错误，或者生产过程中跳过了质量检查，依然会失败。

这给软件工程师带来了一个重要教训：可靠性不在于构建完美的组件，而在于确保整个系统能够容忍不完美。

经验丰富的工程团队很少假定一切都会完美运行。相反，他们会问这样的问题：

• 如果这个服务不可用，会发生什么？
• 是否有其他组件可以接管？
• 系统能多快恢复？
• 在问题解决期间，用户能否继续工作？

围绕失效来设计，往往比试图消除所有可能的失效更有价值。

小缺陷变成大问题

许多重大故障都始于一些令人惊讶的小事。

一个配置值不正确。一个证书过期了。一个重试循环压垮了下游服务。缓存变旧了。一个 API 开始返回意外的响应。

这些问题单独来看都不像灾难性的。真正的损害发生在多个小问题叠加，导致更大的系统故障时。

制造业遵循同样的模式。一个稍微错位的组件在组装时可能看起来无害，但随着时间的推移，它会增加磨损，降低效率，最终导致昂贵的故障。

软件系统的行为也类似。小的技术债务 (https://www.ibm.com/think/topics/technical-debt) 会逐渐累积，直到可靠性开始受损。

这就是为什么经验丰富的团队会投资于日常维护。重构、依赖更新、基础设施改进和自动化测试可能不会带来可见的产品特性，但它们能显著降低运营风险。

可靠性是通过对细节的持续关注而建立起来的。

根本原因分析比找人背锅更重要

当生产系统出现故障时，组织往往急于找出是谁犯了错。

更好的问题是：为什么这个错误一开始是可能的？

也许是部署防护措施缺失了。或者监控未能检测到异常行为。或者文档已经过时。

也许代码审查忽略了一个重要的边界情况。

强大的工程文化侧重于改进系统，而不是追责。

这种理念贯穿于各个工程学科。制造公司花费大量精力研究材料组装中的常见故障 (https://constructiondaily.news/common-failures-in-material-assembly-and-how-to-prevent-them/)，因为理解缺陷产生的原因可以带来更强大的流程、更好的检查，以及更少的未来故障。

软件团队也从同样的思维模式中受益。每一次生产事故都成为改进自动化、监控、文档和测试的机会，而不仅仅是修复当前问题。

无指责的事后复盘鼓励工程师及早报告问题，因为他们知道目标是学习，而不是惩罚。

随着时间的推移，这会让系统逐渐变得更可靠。

冗余是投资，不是浪费

乍一看，冗余似乎效率低下。

为什么要运行多个应用实例？为什么要维护多个数据库副本？为什么要在多个区域部署服务？为什么要保留多个备份？

当故障发生时，答案就显而易见了。

如果每个关键组件只有一个实例，那么每个故障都会变成完全停机。

制造工厂经常维护备用设备，正是出于这个原因。停机往往比维持备用容量昂贵得多。

云基础设施遵循同样的原则。负载均衡器将请求分发到多个服务器。数据库副本降低了硬件故障的影响。消息队列 (https://aws.amazon.com/message-queue/) 防止临时峰值压垮下游系统。

多个可用区可以防止区域性故障。

冗余会增加成本，但它极大地提高了韧性。

组织必须决定，额外基础设施的成本是否低于潜在停机成本。

对于面向客户的应用来说，答案通常是肯定的。

测试应模拟真实情况

通过单元测试并不意味着软件是可靠的。

许多生产故障之所以发生，是因为真实环境的行为与开发机器不同。

网络变慢。外部 API 返回意外响应。数据库出现临时延迟。用户产生出没人预料到的流量模式。

可靠的工程需要在实际条件下进行测试。

集成测试验证服务之间的通信。负载测试评估高流量下的系统行为。混沌工程有意引入故障来测量韧性。

灾难恢复演练确保备份程序确实有效。

制造业也在产品交付给客户之前进行压力测试。组件会暴露在极端温度、振动、压力和反复使用中，以便在成为现场故障之前识别弱点。

软件也应该受到同样的审视。测试越接近生产环境，部署后工程师遇到的意外就越少。

可观测性优于瞎猜

当生产问题发生时，每一分钟都至关重要。如果无法洞察系统行为，工程师只能被迫做出有根据的猜测。猜测很少能快速解决故障。

现代可观测性将日志、指标、追踪和告警结合起来，形成系统健康状况的完整画面。

日志解释发生了什么。指标揭示性能趋势。分布式追踪跟踪请求在多个服务间的流转。仪表盘在用户注意到问题之前就暴露出异常行为。

这些工具共同极大地减少了诊断事故所需的时间。目标不是收集更多数据，而是收集有意义的数据，以回答重要的运维问题：

• 工程师能否找出失败的服务？
• 他们能否衡量对用户的影响？
• 他们能否确定问题何时开始？
• 他们能否验证修复确实解决了问题？

可观测性将调试从侦探工作转变为工程工作。

可靠性是一个持续的过程

许多组织错误地将可靠性视为一次性的项目。他们在出现故障后改进监控。他们在发现回归问题后添加自动化测试。他们在一次失败的发布后引入部署流水线。

这些改进是有帮助的，但可靠性不是那种完成一次就可以忘记的事情。

每一个新特性都会增加额外的复杂性。每一次依赖更新都会改变系统行为。每一个扩容决策都会带来新的运维挑战。

可靠的系统需要持续评估。

工程团队定期审查事故、清除技术债务、改进自动化并更新运维文档，因为昨天的可靠架构可能无法满足明天的需求。

可靠性与软件本身一起进化。

优秀的工程是可预测的工程

用户很少注意到可靠的系统。没有人会庆祝一个每天正常工作的应用。

相反，注意力往往集中在新功能、产品发布和创新技术上。

然而，可靠性仍然是任何一个工程组织可以建立的最强大的竞争优势之一。

客户信任始终保持可用的应用。开发者喜欢在行为可预测的系统上工作。企业避免了与故障相关的财务和声誉成本。

制造业早就明白，质量是在生产的每个阶段构建出来的，而不是最后检查出来的。软件工程遵循完全相同的原则。可靠性源于深思熟虑的架构、严格的测试、有效的监控、持续的学习，以及一种将每次失败视为改进机会的文化。

从工厂车间到云原生微服务，这个经验始终不变。强大的系统不是由没有失败来定义的，而是由它们如何预测失败、吸收失败并从失败中恢复来定义的。

技术可能会继续演进，但可靠工程的基础是永恒的。

希望你喜欢这篇文章。你可以通过 LinkedIn (https://linkedin.com/in/manishmshiva) 与我联系。

免费学习编程。freeCodeCamp 的开源课程已经帮助超过 40,000 人找到了开发者工作。现在就开始 (https://www.freecodecamp.org/learn)