故障是常态，不是意外
在云环境下，资源调度就像一个大型交通指挥中心，要实时安排计算任务跑在哪台服务器上。但和现实中的堵车、车辆抛锚一样，服务器宕机、网络抖动、磁盘出错这些情况每天都在发生。与其指望系统永远不坏，不如从一开始就设计好“出事了怎么办”。
任务失败了，重试就行？
很多人第一反应是：任务挂了就重新调度呗。这没错，但不够聪明。比如一个批量数据处理任务运行到第90分钟突然失败，如果直接扔掉重来，代价太大。更合理的做法是支持断点续传或状态快照（checkpoint），把中间结果存下来，重启时从最近的节点恢复。
像 Apache Flink 这类流处理框架就内置了这类机制：
env.enableCheckpointing(5000); // 每5秒做一次状态快照
env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);调度器怎么知道机器挂了？
靠心跳。每个工作节点定期向调度中心“报平安”，比如每10秒发一次信号。如果连续3次没响应，调度器就标记它为失联，并把上面的任务迁移到健康节点。
但网络抖动也可能导致误判，所以不能一断就切。通常会设置一个“宽限期”，比如等待30秒再行动，避免频繁震荡。Kubernetes 就是这么干的，Pod 失联后先进入 Unknown 状态，等确认死亡才触发重建。
别把所有鸡蛋放在一个篮子里
即使单个节点很稳定，整个可用区（AZ）也可能停电。比如某次大厂故障，就是因为一个机房整体断电，而所有服务都挤在这个机房。
解决办法是跨可用区部署。调度器在分配任务时，要主动打散分布。比如有三个副本，尽量分到三个不同机房。这样即使一个机房挂了，其他两个还能撑住。
预判比补救更重要
有些系统已经开始用预测性容错。通过监控CPU温度、磁盘读写延迟、内存错误率等指标，提前识别可能出问题的机器，主动把任务迁移走，而不是等它真死了再处理。
比如你家路由器连着连着变慢，最后断了。如果能提前发现信号衰减趋势，自动切换到备用线路，体验就好多了。云系统也是一样道理。
配置错了怎么办？
人总会犯错。某次上线把内存配成1MB，结果服务起不来。这时候版本化配置就很有用。每次变更都留档，回滚只要点一下。Terraform 或 Ansible 这类工具就能做到。
另外，灰度发布也是一种容错策略。先放1%流量验证新配置，没问题再逐步扩大。哪怕出事，影响也有限。
小公司也能用的实用建议
不是所有团队都有谷歌那样的技术实力。但基本功可以做好：定期做故障演练，比如随机杀掉一个容器，看系统能不能自愈；关键服务至少两个副本；日志集中收集，出问题能快速定位。
就像你开车不会天天撞，但安全带得系好。云系统的容错机制，就是那根安全带。