凌晨三点告警灯再次亮起。做infra的人对这种场景再熟悉不过——服务抖动、磁盘打满、延迟毛刺一道道告警把我们从睡梦中捞起来。处理完故障问题就结束了吗大多数团队在故障解决的那一刻就散了下次又以同样的方式再踩一次同样的坑。我决定把“infra复盘”做成一个系列而这一篇是“第0篇”它不讲任何具体故障的根因而是先把复盘这件事本身讲清楚复盘到底要盘什么、为什么大多数复盘流于形式以及AI infra、Agent infra这些新词背后infra复盘的坐标系正在发生哪些变化。如果你也是负责基础设施稳定、性能或成本的人无论你是SRE、运维、DevOps还是后端这篇都值得看完。1. 把infra复盘和普通总结分开为什么需要“第0篇”1.1 复盘要回答的四个问题不是“做了什么”大多数团队会把复盘写成“发生了什么—我们做了什么—下次怎么办”三步式流水账。这不能算错但infra复盘要解决的问题比流水账深一层。我自己的经验是一次合格的infra复盘必须回答四个问题用户真实受到的影响是什么而不是我们内部观察到的现象系统的哪个边界最先被突破突破之前的信号有哪些被忽略了我们的应急动作里哪些是真正解决问题的哪些只是缓解表面症状如果同样的事情再来一次系统能否自动避免还是仍然需要人类介入。这四个问题对应的不是“做了什么”而是“为什么当时会那样做”和“系统为什么允许它发生”。比如一次CPU毛刺表象是负载升高但用户影响可能是接口超时而最先被突破的边界可能是连接池线程耗尽忽略的信号可能是早两小时就出现的慢SQL增长曲线。把这条链拉出来才算有资格叫复盘。1.2 复盘的对象是“系统”不是“个人”开始做infra复盘之前先要建立一个共识复盘的对象永远是系统不是个人。不是说人不会犯错而是只有把视角从“谁改坏了”切换到“什么样的流程和系统设计允许一个人在不该出错的环节犯错”才能真正找到可改进的杠杆点。这一点在infra领域尤其重要因为基础设施本身就是由人写代码、人做变更、人值班运维的复杂系统人的失误其实是系统的一部分。我在早期带团队时做过一次容量复盘事故起因是A同学上线时漏掉一个参数当时很多人第一反应是“上线前检查不仔细”。但复盘到最后我们发现真正的问题有两个一是上线模板里那个参数默认值在文档里写错了二是发布流水线没有对目标环境的实例数做预检导致几十台机器同时以默认值启动。如果不把对象定为系统最后得到的只会是“以后认真一点”这种无效结论。1.3 为什么这一篇是“0”而不是“1”这一篇叫“第0篇”是有意的。0比1更精确地描述了infra复盘系列的位置它不是从某个具体事件开始而是从“复盘的元问题”开始。就像写代码前先define一份schema建房子前先画一张地基图第0篇是在建立一种可复用的观察框架之后每一篇具体复盘才有统一的语言。另一个原因是infra复盘太容易变成一次性行为。某次大故障后团队发誓要改进过两个月又忘了。所以“第0篇”也是一份长期约定它定义了我们复盘时使用的术语SLO、错误预算、爆炸半径、复盘产出的格式、以及复盘结果怎么归档成自动化用例。未来不管做十篇还是二十篇每一篇都挂在同一个框架下。这也是为什么我建议所有想沉淀infra复盘的团队先写自己的第0篇再开始处理具体案例。2. 稳定的复盘要先看三张表SLO、容量水位与成本曲线2.1 SLO与错误预算把稳定性从口号变成可判定的指标复盘的第一个落脚点是稳定性。我接触过不少团队一说稳定性就是“服务没挂”但“没挂”的标准是什么接口成功率99%和99.99%背后是完全不同的工程投入。所以第一步永远是定义SLOService Level Objective并且把它拆成可计算的指标。我自己的常用做法是为核心接口定义三个数字——可用性目标、时延P99目标和错误预算消耗速率。错误预算这个概念简单说就是允许你“犯错”的额度比如一个月允许0.05%的请求失败一旦消耗过快就必须冻结新功能发布。复盘的时候不看某一天的抖动而看错误预算消耗曲线的拐点更容易找到真正的结构性风险。举个例子我们曾有个网关服务单看每天成功率都是99.9%SLO达标。但按周看错误预算消耗周一到周五白天消耗极低每天晚上11点后出现一个明显爬升。复盘锁定了夜间批处理任务和网关的连接复用参数冲突。如果不看错误预算的速率这个问题可能还会潜伏很久。稳定性的复盘本质上是给“模糊的稳定”找一个可测量的锚点。2.2 容量水位关键在于拐点而不是平均值容量规划是infra复盘的另一个支柱。很多团队复盘容量问题时喜欢看CPU平均值、内存平均值、磁盘使用率平均值但这三个数字很容易骗人。平均值藏掉了波峰波峰藏掉了拐点。对基础设施来说拐点意味着临界资源即将耗尽比如内存达到80%、连接数达到70%、磁盘剩余小于20%。这些才是需要写进复盘报告的关键水位线。我每次做容量复盘都会拉出近30天的四个时间序列峰值QPS、P99延迟、资源使用率、队列积压长度。把四个序列叠加在同一个时间轴上你会看到故障前几小时哪些指标已经先于用户投诉开始异常。比如队列积压从3分钟前开始上涨1分钟前延迟才开始恶化这时候你就有了一条“预警链”可以反推设计自动化告警。容量复盘里最常犯的错是只准备“扩容”预案而不考虑“临时降级”预案。扩容在虚拟机上容易在物理机采购周期长、预算紧张的场景下往往是来不及的。所以复盘时除了追问“要不要加机器”更要追问“能不能在峰值时关掉非核心功能”。这一点在后面AI infra的场景里会更频繁地出现因为模型训练和推理对容量的吞噬往往是脉冲式的。2.3 成本曲线把“花了多少钱”变成“钱花得值不值”infra复盘的第三个表是成本。以前成本复盘只出现在财务月底我觉得这不够。基础设施成本几乎每周都在变尤其是Kubernetes普及之后实例规格、副本数、存储类型、跨区流量任何一次配置变更都在改账单。复盘时不看成本你会发现稳定性优化和成本优化经常是冲突的。我的建议是建立一个简单的单位成本指标比如“每百万请求的基础设施成本”或者“每分钟平均服务成本”。每次故障复盘都把这个数字带进去看那次故障造成了多少额外成本临时扩容的机器、补偿任务消耗的算力、回滚后空转的资源。别小看这些很多时候一次大故障的隐性成本比一个月正常的资源浪费还多。成本优化不是只盯着低价实例。实际上用量上去了最便宜的往往是“让资源调度器更聪明”比如把不重要的批处理任务挪到低峰期、把测试环境在夜间缩容到零、给Staging环境设置自动休眠。这些动作每次复盘都可以挑一个纳入行动计划。成本复盘不需要做得很复杂但必须形成固定动作而不是月底看账单的时候才拍脑袋。3. 最容易漏掉的暗礁配置漂移、依赖和“变更的人”3.1 配置漂移机器越多越是复盘的盲区infra复盘中稳定性、容量、成本都算主干但真正让复盘深度拉开差距的是那些容易被忽略的暗礁。第一个暗礁就是配置漂移。所谓配置漂移是指实际运行的配置和代码仓库里声明的配置不一致。几十台机器时手工改一改还能接受几百台机器时任何一个控制台手动操作都可能成为下一次故障的火种。我在一次复盘中发现某核心服务的半年前配置被某位同事在控制台上手动改过一个参数导致集群一半节点使用旧配置、一半节点使用新配置流量分配不均最终触发雪崩。代码仓库里的配置完全正常问题全在“仓库之外”。从那以后我们将所有手工配置纳入IaC基础设施即代码管理并且加入定期“配置对账”任务把实际资源与代码声明做diffdiff结果作为每天的自动巡检项。复盘的时候写没写配置漂移是区分“救火记录”和“系统化复盘”的分水岭。你可以这样自查这个故障如果重现在一个全新搭建的环境里还能不能复现如果不能说明有依赖当前环境的“幽灵配置”它才是复盘真正该追杀的目标。3.2 依赖的级联爆炸单点并不总在你自己手里另一个常见盲区是依赖。现在的服务几乎没有单机独立存在的你的服务依赖数据库、缓存、消息队列、对象存储、DNS、CDN甚至依赖另一个团队的另一个服务。infra复盘中完整的依赖拓扑比根因分析还重要。因为很多时候故障源头不在你能控制的服务内而在某个上游或下游的第三方能力上。我印象很深的一次故障根因是某个云服务商的对象存储团队内部切流导致相关读请求P99从5ms涨到800ms我们的批处理任务全部超时。刚开始复盘时我们只盯着自己的重试逻辑后来才发现重试风暴把更下游的数据库连接池打满。其实第三方故障我们无法控制但我们可以控制的是是否对第三方的错误有熔断机制、是否对超时重试有指数退避、依赖方故障时我们的缓存是否足够扛住峰值。复盘依赖问题时我喜欢用“爆炸半径”这个概念这个依赖挂了会影响多少条调用链、多少用户、多少核心业务每次复盘至少记录依赖变更的时间点比如某个依赖的版本升级、注册中心变更、配额调整。这些信息单独看都不起眼但放在时间轴上经常会和故障时间点重合。把依赖变更记录纳入复盘的标准字段之后你会很惊讶地发现能解释掉相当一部分“找不到根因”的悬案。3.3 变更流程里“人”的因素无法被自动化完全取代第三个暗礁是变更流程里的人。很多infra团队已经做了相当完善的CI/CD流水线但“人”依然是最后一道也是最不稳定的一道关卡。复盘时要问这次变更为什么能在自动检查全绿的情况下发布出去是检查项设计得不合理还是检查项覆盖不到业务语义我经历过一次典型事故一条变更涉及的key在配置中心存在两种格式代码里用的是新格式而校验脚本用的是旧格式两边都没错但合到一起就出错。自动检查全绿因为检查脚本没覆盖到这个交叉场景。复盘后我们把配置格式统一为同一个schema并且给校验脚本增加了“新老格式对照”的用例。技术手段能覆盖大多数场景但开发变更、评审变更、执行变更的人他们对变更的理解和沟通质量才是真正决定成败的隐藏因素所以复盘必须保留“人如何做决策”的讨论内容而不是把它剔除。4. 当infra遇到AIAI infra与Agent infra复盘的新变量4.1 AI infra算力、存储和调度的复盘从“请求”变成了“迭代”近两年“AI infra”成了热词它本质上还是infra但复盘对象的变化非常大。传统infra的服务对象是用户请求峰值可控、模型可预测AI infra的服务对象除了在线推理请求还有训练任务、数据管线、模型实验。这些对象的特点是“迭代”驱动——训练一次模型要几小时甚至几天实验一多算力需求就像潮水一样涌来。复盘不能只盯着在线成功率还要盯训练任务的吞吐、GPU利用率、数据加载带宽。我和做AI平台的朋友交流他们说最常复盘的是“GPU资源碎片化”。很多团队买了一批GPU但一部分被闲置、一部分被长尾小任务占住真正的大训练任务反而排不上队。这种问题在传统CPU场景也有但AI infra里更尖锐因为一张GPU卡的价格和调度粒度都更重。复盘的输出往往不是“增加机器”而是“改善调度策略”和“设置任务优先级”。另外存储层的吞吐也经常成为瓶颈尤其是checkpoint保存时大量模型权重同时写入很容易把网络存储打满这类问题传统复盘模板几乎不会覆盖。4.2 Agent infra基础设施响应从“被动”变成“主动”“Agent infra”是更热的新词。我理解这里的Agent指的是基础设施自身的智能化代理它不只是做监控和告警而是能够根据当前状态自动执行补偿动作。比如流量突增时自动扩容磁盘碎片率升高时自动触发清理模型训练中断时自动重启续跑。这样的Agent让infra从“被动响应告警”变成了“主动调节系统”。这对复盘方式的影响非常大。以前复盘人类是唯一的主角我们发现故障、判断根因、执行操作。现在如果Agent参与了应急复盘就必须增加一个维度Agent的决策是否准确、是否产生了误操作、Agent与人类干预之间的切换逻辑是否顺畅。我们遇到过Agent误判流量接口把正常的促销流量当成攻击流量做了熔断最后还得人工解除。复盘时查日志Agent的评分函数给了过高的权重给“丢弃请求数”导致它倾向于丢弃一切看起来异常的请求。这类问题给我们的启示是Agent infra的复盘本质是“决策复盘”和传统的“操作复盘”有本质区别。4.3 面对新范式第0篇里要提前定好的三个约定不管做传统infra还是AI infra复盘框架一致但约定需要更新。我建议在第0篇就提前定好三件事一是所有资源变化必须有时间戳和操作人。不管是人工变更还是Agent自动变更都要能在20分钟内还原出“谁在什么时候改了什么”。没有这个前提复盘就会变成猜谜。二是把所有自动决策都记录成“决策日志”包括触发条件、输入指标快照、执行动作和最终结果。Agent的每次动作都要能被回放就像给审计机制留了后门一样。决策日志是agent infra复盘的基础。三是明确“人工接管”的触发条件和交接规范。Agent执行不了、或者Agent的行为人类不放心时必须有清晰的手动接管路径。这个约定在传统infra里通常写在应急预案里但在Agent infra里它应该被写成一段可以测试的协议。这三条是我看到很多团队在引入AI能力后最容易漏掉的。写到这里有人可能会问Agent会不会取代SRE我的看法是在相当长时间内Agent会替代的是那些重复性的、规则明确的应急操作而复盘、设计、权衡这些带有价值判断的工作仍然需要人。5. 复盘频率和触发条件别把复盘变成形式主义的周会5.1 故障分级只有真正影响用户的故障才做完整复盘不是每个告警都需要正式复盘。infra团队每天告警很多如果每个都开复盘会大家就不用干活了。所以要建立一套故障分级机制。我常用的分级维度是“用户影响”影响超5%核心请求超过10分钟、或者直接造成业务资损、或者核心功能完全不可用的定义为P0必须做完整复盘并出报告影响部分请求、持续时间短但暴露系统性风险的定义为P1做简化复盘记录事实和行动项即可P2以下的告警留到周会讨论。这样能保证复盘资源聚焦在最该关注的问题上。有人可能觉得分级是官僚其实不是。反过来很多团队把所有告警都塞进同一个群里结果大家疲劳轰炸真正的P0反而没人快速响应。分级不是复杂度而是把注意力投给危险信号。另一个原则是分级的指标要在第0篇就定好不要每次都临时主观判断。把“影响范围”“持续时间”“导致资损与否”这三个字段做成告警必填项复盘时自然会积累出高质量的数据。5.2 例行复盘的节奏设计事故驱动 例行巡检只靠事故驱动复盘往往是被动挨打。我建议在事故复盘之外设置固定节奏每双周用30分钟做一次“例行infra巡检复盘”不针对具体故障而是把过去两周的SLO消耗、容量水位、成本曲线、告警高频项全部扫一遍。这种例行复盘更容易发现“还没形成故障的慢性问题”比如某个接口延迟持续缓慢增长、某个集群的CPU在走一条阶梯上升曲线。慢性问题往往比急性故障更危险。具体操作上我会提前准备好一张巡检表包括SLO达成率、错误预算消耗、Top 5告警、近两周变更次数、失败率最高的5个端点、资源使用率Top 5实例。例会不是逐条读指标而是找异常只讨论“为什么这个指标和上两周比明显变了”。这样的例会坚持一年团队对系统的感知能力会明显提升。例行巡检还承担一个功能让每个工程师都能养成“带着数据说话”的习惯而不是凭印象判断系统健康。5.3 复盘会议怎么开才不变成追责会复盘会最怕开成追责会。很多团队开复盘大家准备一大堆截图最后变成谁的错、谁该背锅。要避免这一点会议开场就明确一个事实故障的根因几乎总是在系统设计和流程中而不是某个人的人品。可以定一个简单的会议规则所有陈述必须基于事实和日志不许用“我觉得”“我记得”必须能指出数据来源。如果有人在会上开始指责同事主持人要把话题拉回到“什么样的机制会允许这类错误发生”。还有一个实用技巧复盘会最好是让最熟悉该系统、但没参与当时应急的人主导提问因为他没有当时的情绪包袱更容易问出关键问题。复盘的目的就是把“个体错误”转化为“系统改进的原材料”。如果你发现团队复盘的结论经常落在“某人不够细心”上那复盘会已经偏航了要立刻纠偏。文化上的约束比一张华丽的复盘报告重要得多。6. 把复盘从“开会”变成“用例”输出一份能跑的复盘模板6.1 用5W法串起一次快速复盘而不是直接写报告复盘最怕烂尾。为了不让复盘变成一页PPT我建议先做一次10分钟的5W串讲串讲完再写报告。5W就是What、Why、When、Where、Who再加一个我在infra里常用的元素How big影响范围多大。这个快速串讲的作用是让所有参与者在半小时内对齐事实避免上来就讨论“谁的责任”。具体可以这样组织What——用户或系统表现出的现象是什么Why——这次现象触发了哪些告警、哪些指标先异常When——最早异常时间点是什么我们是什么时候发现的中间隔了多久Where——异常集中在哪个区域、哪个集群、哪类请求Who——哪些系统和团队参与了应急处置How big——影响持续了多久、影响了多少请求、造成了多少额外成本把六个问题答案写在一张共享文档里不需要修饰先保证事实一致。事实一致之后再往里面填根因分析效率会高很多。6.2 把行动计划写成SMART并且指定唯一负责人串讲之后真正有价值的是行动计划。我见过太多复盘报告写着“加强监控”“完善预案”“加强测试”这些全是废话。行动计划必须SMART具体、可衡量、可达成、有相关性和有截止时间。比如“增加连接池耗尽指标的可观测性并把告警阈值设为使用率80%在下一轮发布中灰度上线截止本周五完成。”这种才能落地。同时每条行动计划都必须有且仅有一位owner不要写“相关同学”。Owner要负责推动、同步进展并在下次复盘时汇报完成情况。我自己的习惯是每组行动计划不超过三条。因为一次复盘能真正改变的东西有限列十条只会让每条都被打折。三到五条是上限优先做那些能防止同类故障复发、且成本可控的项。复盘不是年终总结不是动作越多越好而是每个动作都能被验证。6.3 复盘的最终归宿是自动化用例而不是文档我自己最推崇的复盘落地方式是把复盘结论转化为自动化用例。这是什么意思比如某次故障根因是不规范的重试导致下游连接池被打爆那复盘结束后就写一个测试当某个依赖错误率升高到阈值时验证重试次数是否被限制在预设值之内并且把它接入CI/CD流水线。类似的容量类复盘可以转化为“发布前自动检查预计流量峰值是否超过当前水位”配置类复盘可以转化为“配置对账diff有变更时自动卡点”。这样做的优势很明显再也不会出现“复盘报告写得很漂亮但两个月后同类问题又爆发”的情况。因为你的防线已经从人肉记忆变成了代码守卫。传统infra团队能做到这一点AI infra的Agent决策逻辑也一样可以做自动化测试给Agent喂历史故障数据看它的决策是否符合预期。这其实是“复盘驱动测试”的思路值得每个团队尝试。把复盘从文档变成用例才算真正闭环。虽然这一篇是第0篇还没有任何具体事件但我已经把接下来所有要用的框架、指标和落地方式都铺好了。现在可以拿着这个框架去复盘任何一个你手头的历史故障。我个人的体会是第0篇写得越认真后面每一篇具体复盘就越省力反之如果连坐标系都没定那后面更容易扯皮。下一篇我会拿一个真实案例来走一遍这套流程到时候我们再见。