软件工程师们常觉得，可靠性是个挺现代的挑战。我们张口闭口就是正常运行时间、分布式系统、可观测性、容错机制，仿佛这些词天生就只属于云计算。但看看现实就知道，工程师们解决可靠性问题，其实已经有上百年的历史了。制造车间、土木工程、工业流水线上的前辈们，都面对过同一个根本问题：当个别组件都扛不住的时候，你该怎么让整个系统还能继续跑下去？

不管你是在组装一座桥、生产一辆车，还是在部署一套微服务架构，可靠性从来不是天上掉下来的。它靠的是深思熟虑的设计、不间断的测试，以及愿意从失败里学点东西的心态。技术确实一直在变，但工程学里那些底层原则，倒是一直稳得惊人。

打开网易新闻 查看精彩图片

我们就来看看这些让系统变得可靠的经典原则，无论你面前的是一条工厂流水线，还是一个云原生应用。冗余、根因分析、接近真实的测试、可观测性——这些概念指引了几代工程师，今天在构建现代软件时，它们的分量一点没轻。

一个现代应用，背后可能站着几十甚至上百个服务。每个服务都要靠数据库、API、消息队列、缓存、存储系统还有网络基础设施撑着。这里面任何一个组件出点毛病，故障就能像波浪一样荡过整个应用。制造系统也是同一个道理：一个设计完美的产品，可能就毁在某个装配不到位的零件上，或者在产线上跳过了某些质量检查。

这事儿给软件工程师的启示很直接：可靠性不是去造出什么完美组件，而是要保证整个系统能容忍那些不完美。有经验的工程团队很少会假定一切都会完美运转。他们反复问的是这么几个问题：这个服务要是突然挂掉怎么办？谁能接过来？系统多久能恢复？用户能不能在问题解决前继续干活？围绕着“故障”来设计，往往比死磕“消灭一切故障”要有用得多。

很多重大宕机，追根溯源都是些微小得让人意外的东西。一个配置值写错了。一张证书过期了。重试循环把下游服务给冲垮了。缓存里的数据过时了。API返回了意料之外的响应。单独看哪个都不像灭顶之灾，真正的破坏力，来自于一堆小问题合起伙来，演变成一场系统性崩溃。制造业也遵循一样的规律：一个轻微的组件错位，装配时看着好像没什么大碍，可时间一长，磨损会加剧，效率会下降，最终，就是一场代价高昂的故障。