AI 辅助少说漂亮话基础设施要用事故假设来设计一、好基础设施应该先承认会失败基础设施文章里经常出现很多漂亮词高可用、弹性、智能、自治、无感。但生产环境不认这些词它只看故障发生时系统能不能撑住。节点会坏网络会抖证书会过期镜像会拉失败配置会写错下游会超时。基础设施设计的起点是承认这些都会发生。务实的基础设施不是永远不出问题而是问题发生时影响可控、定位清楚、恢复有路。用户最好感受不到它的存在一旦感受到说明某个托底机制没有做好。二、事故假设把可能失败的点摊开mindmap root((基础设施故障假设)) 计算 节点宕机 CPU 抢占 OOM 网络 DNS 异常 跨区抖动 入口限流 发布 镜像错误 配置漂移 回滚失败 数据 备份不可用 容量耗尽 恢复超时把失败点写出来并不悲观。相反它让团队能提前设计探针、告警、限流、回滚、备份和演练。很多事故复盘最后都会发现问题不是没人懂技术而是没人提前问“如果这里坏了怎么办”。三、清单示例上线前问几个硬问题下面是一份简化的上线检查清单。release_checklist: rollback: image_available: true config_versioned: true database_change_reversible: false observability: metrics_ready: true logs_with_request_id: true alerts_owner_defined: true capacity: requests_limits_set: true load_test_done: true degradation_plan_ready: true清单不是形式主义。它把隐性经验变成显性要求。特别是 database_change_reversible 这种字段如果答案是否定的就要设计补偿方案而不是假装风险不存在。基础设施越关键越不能依赖“应该没问题”。四、工程边界不要把复杂性转嫁给业务基础设施团队常说“业务自己配置一下就行”但如果每个业务都要理解底层细节平台就没有真正托底。平台应该提供安全默认值、清晰错误提示、标准接入方式和可观测面板。业务可以理解原理但不应该为每个底层坑付学费。取舍在于平台边界。平台包得太多会限制业务特殊需求平台包得太少所有团队重复踩坑。务实做法是先覆盖 80% 常见路径标准服务模板、标准发布、标准告警、标准日志、标准回滚。剩下 20% 特殊场景通过扩展点处理。基础设施最怕既没有标准又没有自由只剩一堆口头约定。最后事故复盘要回到系统改进。不要只写“加强意识”“以后注意”。要产出具体动作增加告警、修复模板、补充演练、调整超时、补文档、限制危险操作。复盘如果不能改变系统下一次事故还会换个名字回来。事故假设还要进入日常开发。比如新服务接入时平台可以自动检查是否配置了探针、资源限制、日志 request_id、PDB 和告警联系人发布系统可以阻止没有回滚方案的高风险变更容量平台可以在磁盘或 GPU 接近阈值前给出趋势提醒。这些机制看起来不锋利却能持续减少事故概率。当然基础设施也不能把所有风险都变成流程。流程太重会让团队绕路甚至形成新的不确定性。关键是把高风险动作收紧把低风险动作自动化。该拦的拦住该快的快起来。稳定不是慢而是每一步都知道自己承担什么后果。生产落地补充从能跑到可维护从生产落地角度看这类方案不能只停留在主流程。更关键的是把输入校验、失败分支、资源上限和回滚路径提前写清楚。主流程通常容易在演示环境里跑通真正暴露问题的是异常输入、依赖抖动、并发放大和权限边界。一篇技术方案如果没有解释这些约束读者很难判断它能否放进真实系统。评估时建议先定义三类指标正确性指标、稳定性指标和成本指标。正确性指标回答结果是否可信稳定性指标回答失败时是否可控成本指标回答持续运行是否划算。三类指标要同时进入验收清单不能只用平均耗时或单次成功率证明方案有效。五、总结少说漂亮话多做能托底的基础设施。用事故假设设计系统用清单固化经验用演练验证恢复用复盘改进平台。生产环境不需要口号它需要稳定、清楚、可恢复。