AI 辅助：少说漂亮话：基础设施要用事故假设来设计

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 接近阈值前给出趋势提醒。这些机制看起来不锋利，却能持续减少事故概率。

当然，基础设施也不能把所有风险都变成流程。流程太重会让团队绕路，甚至形成新的不确定性。关键是把高风险动作收紧，把低风险动作自动化。该拦的拦住，该快的快起来。稳定不是慢，而是每一步都知道自己承担什么后果。

生产落地补充：从能跑到可维护

从生产落地角度看，这类方案不能只停留在主流程。更关键的是把输入校验、失败分支、资源上限和回滚路径提前写清楚。主流程通常容易在演示环境里跑通，真正暴露问题的是异常输入、依赖抖动、并发放大和权限边界。一篇技术方案如果没有解释这些约束，读者很难判断它能否放进真实系统。

评估时建议先定义三类指标：正确性指标、稳定性指标和成本指标。正确性指标回答结果是否可信，稳定性指标回答失败时是否可控，成本指标回答持续运行是否划算。三类指标要同时进入验收清单，不能只用平均耗时或单次成功率证明方案有效。

五、总结

少说漂亮话，多做能托底的基础设施。用事故假设设计系统，用清单固化经验，用演练验证恢复，用复盘改进平台。生产环境不需要口号，它需要稳定、清楚、可恢复。