软件工程师们常常认为，可靠性是一个现代才出现的挑战。
我们谈论正常运行时间、分布式系统、可观测性以及容错能力时，总以为这些概念只与云计算相关。
但实际上，几个世纪以来，工程师们一直在解决可靠性问题。制造工厂、土木工程项目以及工业生产线，都曾面临同一个根本性问题：如何构建那些即便某些组件发生故障也能继续正常运行的系统呢？
无论你是在建造桥梁、生产车辆，还是部署微服务架构，可靠性从来都不是偶然形成的。它源于周密的设计、持续的测试，以及从失败中学习的意愿。
技术虽然发生了变化，但工程原理却始终如一。
在本文中，我们将探讨那些让系统具备可靠性的永恒工程原则，无论这些系统是工厂的生产线，还是基于云技术的应用程序。
你会看到，诸如冗余设计、根本原因分析、真实的测试方法以及可观测性这类概念，几十年来一直指导着工程师们的工作；而这些经验在开发现代软件时同样具有价值。
读完本文后，你将对可靠性有更深入的理解，并掌握一些可以用来设计更具弹性的系统的实用方法。
我们将探讨的内容：
每个系统的可靠性都取决于其中最薄弱的环节
一个现代应用程序可能由数十甚至数百个服务组成。每一个服务都会依赖于数据库、API、队列、缓存系统、存储设备以及网络基础设施。这些组件中的任何一个出现故障，都可能影响到整个应用程序的正常运行。
制造系统的工作原理也是如此。即使产品设计得非常完美，但如果某个部件安装不当，或者在生产过程中忽略了质量检测，产品仍然可能会出故障。
这为软件工程师提供了一个重要的启示：可靠性并非在于打造完美的组件，而在于确保整个系统能够容忍各种缺陷的存在。
经验丰富的工程团队很少会认为一切都会顺利进行。相反，他们会提出这样的问题：
-
如果这项服务不可用，会发生什么？
-
是否有其他组件可以替代它的功能？
-
系统恢复运行需要多快的时间？
-
在问题得到解决之前，用户能否继续正常工作？
以容错为导向进行设计，往往比试图消除所有潜在的故障更为有效。
小缺陷往往会引发大问题
许多严重的系统故障其实都是由一些看似微不足道的小问题引发的。
某个配置值出错，证书过期了，重试机制使下游服务不堪重负，缓存数据失效了，API开始返回异常响应……这些单独来看似乎都不是什么大问题，但当它们同时发生时，就会导致系统整体崩溃。
制造业也是如此。一个安装位置稍有偏差的零件，在初期可能并不会造成什么影响，但随着时间的推移，它可能会加剧部件的磨损、降低效率，最终导致设备发生严重故障。
软件系统也是如此。小的“技术债务”会逐渐累积，直到系统的可靠性受到影响。
正因如此，经验丰富的团队才会重视日常维护工作。重构代码、更新依赖关系、改进基础设施以及进行自动化测试，这些措施虽然不会直接带来新的产品功能，但它们能显著降低运营风险。
可靠性是通过对细节的持续关注才得以建立的。
根本原因分析比追究责任更为重要
当生产系统出现故障时，企业往往会急于找出是谁犯错了。
但更值得思考的问题是：为什么当初会出现这样的错误。
可能是部署环节缺乏必要的防护措施，也可能是监控机制未能及时发现异常行为，又或者是文档资料已经过时了……
也许代码审查过程中遗漏了一些重要的边界情况。
优秀的工程文化更注重系统的改进，而不是指责责任人。
这种理念在各个工程领域都普遍存在。制造企业会花费大量精力研究材料组装中常见的故障原因，因为了解缺陷产生的根源，才能优化生产流程、加强质量检查，从而减少未来的故障发生。
软件团队也能从这种思维方式中受益。每一次生产事故都应被视为改进自动化机制、加强监控、完善文档记录以及优化测试流程的机会，而不仅仅是解决眼前的问题而已。
无责备性的事后分析会促使工程师尽早报告问题，因为他们知道这样做的目的在于学习，而非受到惩罚。
随着时间的推移，这种做法会让系统变得越来越可靠。
冗余是一种投资，而非浪费
乍一看，冗余似乎效率低下：
为什么要运行多个应用程序实例？为什么要维护备份数据库？为什么要把服务部署在多个地区？为什么要存储多份备份数据？
但当故障发生时，这些问题的答案就变得显而易见了。
如果每个关键组件都只有一个实例，那么任何一次故障都会导致整个系统瘫痪。
制造企业之所以会准备备用设备，正是出于这个原因——停机带来的损失往往远远超过维护备用设施所需的成本。
云基础设施也遵循这一原则：负载均衡器会将请求分配到多台服务器上；数据库备份可以减少硬件故障带来的影响；消息队列则能防止短暂的高流量冲击下游系统；多个可用区也能有效避免区域性故障。
冗余虽然会增加成本，但它能显著提升系统的韧性。
企业需要权衡：额外投入的基础设施成本，是否低于可能因此导致的停机损失。
对于面向客户的应用程序来说，答案通常都是肯定的。
测试应模拟真实环境
通过单元测试并不意味着软件就一定是可靠的。
许多生产环境中的故障，都是因为实际运行环境与开发环境存在差异所致：
网络速度会变慢，外部API可能会返回异常响应，数据库也会出现临时性延迟，用户的行为模式也可能超出预期。
要确保软件的可靠性，就必须在真实的环境中进行测试。
集成测试可以验证各服务之间的交互情况；负载测试则能评估系统在高流量下的表现；而混沌工程则会故意引入故障，以此来衡量系统的恢复能力。
灾难恢复演练还能确保备份机制能够真正发挥作用。
制造业在产品上市前也会进行压力测试：让零部件承受极端的温度、振动、压力以及反复使用，从而在问题实际发生之前发现潜在的缺陷。
软件同样应该接受这样的严格测试——只有当测试环境尽可能接近生产环境时，工程师在部署后遇到的意外情况才会减少。
可观测性比猜测更有价值
当生产环境中出现故障时，每一分钟都至关重要。如果没有对系统运行状况的实时了解，工程师就只能依靠猜测来解决问题——而猜测几乎不可能帮助我们迅速解决故障。
<现代的可观测性技术将日志、指标、追踪数据以及警报信息结合起来，从而形成关于系统运行状况的完整画像。
日志记录了发生的具体情况，指标则揭示了性能变化趋势。分布式追踪功能能够跟踪请求在多个服务中的流转过程，而仪表盘能够在客户察觉问题之前显示出异常行为。
这些工具共同作用，大大缩短了故障诊断所需的时间。我们的目标并非收集更多数据，而是获取那些能解答关键运营问题的有价值信息：
-
工程师能否识别出出现故障的服务？
-
他们能否评估故障对客户造成的影响？
-
他们能否确定问题是在何时开始的？
-
他们能否确认修复措施确实解决了问题？
这种可观测性将调试工作转变成了一种工程化流程。
可靠性是一个持续的过程
许多组织错误地认为可靠性只是一次性的项目。他们在系统发生故障后才会加强监控，在发现功能回归问题时才添加自动化测试，在发布失败后才会建立部署流程。
这些改进确实有帮助，但可靠性并不是完成一次就可以忽略的事情。
每一个新功能的加入都会增加系统的复杂性，每一次依赖关系的更新都会改变系统行为，每一次扩展决策都会带来新的运营挑战。
可靠的系统需要持续不断的评估与优化。
工程团队会定期回顾各种故障案例，消除技术债务，提升自动化程度，并更新运营文档，因为昨天的可靠架构可能无法满足明天的需求。
可靠性是与软件本身一同发展的。
优秀的工程是可预测的工程
用户很少会注意到系统的可靠性，没有人会为那些每天都能正常运行的应用程序而庆祝。
人们的注意力往往集中在新功能、产品发布或创新技术上。
然而，可靠性仍然是任何工程组织能够建立起来的最强大的竞争优势之一。
客户信任那些始终可用的应用程序，开发者也喜欢在行为可预测的系统中工作，企业则可以避免因系统故障而带来的财务和声誉损失。
制造业早就明白，质量是在生产的每一个环节中形成的，而不是在最后才进行检测的。软件工程同样遵循这一原则。可靠性源于周密的架构设计、严谨的测试流程、有效的监控机制、持续的学习态度，以及一种将每一次失败都视为改进机会的文化。
无论是工厂车间还是基于云的微服务架构，这个道理都是一样的：强大的系统并不是因为没有故障而存在，而是因为它们能够有效预测故障、妥善应对故障，并从中恢复过来。
技术可能会不断发展变化，但可靠工程的基本原则却是永恒不变的。
希望您喜欢这篇文章。您可以通过在LinkedIn上与我建立联系。