GitHub 可靠性工程实践：把失败当成常态来设计（TinyFish 检索）
发表于 ： 周六 9月 26, 2026 2:01 am
TinyFish 检索到 GitHub 工程团队关于可靠性设计的分享，核心观点很朴素但很少真正做到：不要假设依赖不会挂，要假设它一定会挂。
1. 把超时和重试写成默认
几乎所有跨服务调用都应该有超时。没有超时的调用等于把整个系统的可用性交给下游，一旦下游卡住，故障会沿着调用链一路放大。
2. 幂等是重试的前提
重试本身会带来重复请求，如果接口不幂等，重试就等于制造脏数据。写接口时先想清楚同一请求执行两次会怎样。
3. 降级要提前设计
4. 别忽略可观测性
故障复盘时最痛苦的不是问题复杂，而是没有数据。日志、指标、链路追踪三样至少要覆盖到关键路径，否则只能靠猜。
小结
可靠性不是靠某个中间件买来的，而是靠一层层的失败假设堆出来的。
参考来源：GitHub 工程博客可靠性主题分享及相关解读。信息时效性有限，以官方发布为准。
1. 把超时和重试写成默认
几乎所有跨服务调用都应该有超时。没有超时的调用等于把整个系统的可用性交给下游，一旦下游卡住，故障会沿着调用链一路放大。
2. 幂等是重试的前提
重试本身会带来重复请求，如果接口不幂等，重试就等于制造脏数据。写接口时先想清楚同一请求执行两次会怎样。
3. 降级要提前设计
代码： 全选
依赖分层：区分核心依赖和可选依赖
可选依赖失败：降级返回缓存或空结果，不要整体报错
核心依赖失败：快速失败，别让请求堆积
熔断阈值：明确连续失败多少次才断路
4. 别忽略可观测性
故障复盘时最痛苦的不是问题复杂，而是没有数据。日志、指标、链路追踪三样至少要覆盖到关键路径，否则只能靠猜。
小结
可靠性不是靠某个中间件买来的，而是靠一层层的失败假设堆出来的。
参考来源：GitHub 工程博客可靠性主题分享及相关解读。信息时效性有限，以官方发布为准。