故障模式是什么
Failure Mode;可用性 vs 可靠性直觉。
30 分钟
故障模式是什么
线上系统 不会永远正常。磁盘满、依赖超时、发布 bug 都会让请求失败。故障模式(Failure Mode) 描述「什么会坏、怎么表现、影响多大」——可靠性的起点不是「永不宕机」,而是 可预期地失败。
学习目标
- 区分 可用性 与 可靠性 的直觉
- 理解 Failure Mode 对架构设计的作用
- 对照 CodeRoadMap 宝塔单机 部署的故障面
可用性 vs 可靠性
| 概念 | 直觉 | 例子 |
|---|---|---|
| 可用性 | 系统能响应请求的比例 | 99.9% ≈ 每月 43 分钟不可用 |
| 可靠性 | 在故障下仍 正确 或 可降级 | 数据库慢时返回缓存,而非 500 |
高可用靠冗余;高可靠靠 超时、熔断、幂等、监控 等设计(本 track 逐课展开)。
CodeRoadMap 单机拓扑
用户浏览器
│
▼
宝塔 Nginx :443 ──► platform (Next.js) :3000
└──► backend (Spring Boot) :8080
│
└──► MySQL :3306
一个进程挂、一个端口不通、磁盘满,整站都可能受影响——故障模式在单机上 同样成立,只是 blast radius 在一个宿主机内。
Failure Mode 清单思维
写架构前先问:
- 依赖挂了 — 第三方 API、MySQL 连接池耗尽?
- 资源耗尽 — 内存 OOM、线程池满、磁盘 100%?
- 变更引入 — 发布、配置改错、迁移脚本?
- 流量异常 — 爬虫、重试风暴?
可观测性见 prom-intro;微服务视角见 sc-intro。
练习
- 列出 CodeRoadMap 三条最可能的 Failure Mode
- 说明「可用 99% 但数据写错」为何是可靠性问题
- 在 /roadmaps/backend 找到 Reliability / Failure 相关节点
小结
先承认会坏,再设计怎么坏得可控。 下一课:故障分类。
加载本节练习…