SRE

概述 去年有个朋友跟我吐槽：他们公司上了 Prometheus、ELK、Jaeger 三套工具，运维团队 7 个人，每天光处理告警就耗掉 4 小时。某天凌晨支付服务 P0 故障，从告警触发到定位根因花了 42 分钟——根因是一个数据库连接池配置变更导致慢查询堆积，Jaeger 里有完整的 Trace，但没人看；ELK 里有慢查询日志，但没人搜；Prometheus 里有连接池指标的异常波动，但告警被淹没在 5000 条日常告警里。 问题出在哪？工具都上了，数据都采了，但三套系统各自为战，没有形成"可观测性"。这就像你给一辆车装了速度表、油表、温度计，但三个表盘分别放在后备箱、手套箱和引擎盖下面——仪表都在，但你开不了车。 可观测性（Observability）这个词来自控制理论，核心定义很简单：通过系统的外部输出推断系统内部状态的能力。说白了就是——不用进到系统里面去翻代码，光看数据就能回答"系统现在健不健康？出了问题在哪？为什么出问题？" 这篇文章不讲三支柱是什么（Metrics/Logs/Traces 满大街都有文章讲），讲的是从碎片化监控到统一可观测性体系，你需要做哪些架构决策，以及每个决策的踩坑实录。每一条都是我在生产环境中验证过的，不是 PPT 上的理论。 监控≠可观测性：先搞清楚你在解决什么问题 很多人把监控和可观测性混为一谈。这俩不是一回事。 监控（Monitoring） 回答的是"出了什么问题"——CPU 炸了、内存满了、接口超时了。它是预设的、基于已知故障模式的。你提前定义好"CPU > 80% 就告警"，系统照着执行。 可观测性（Observability） 回答的是"为什么出问题"——为什么这个接口突然变慢了？为什么这个 Pod 一直在重启？为什么这个用户的请求失败了？它是探索性的、面向未知故障模式的。你没法提前定义所有可能的故障，但通过 Metrics + Logs + Traces 的关联，你能在出事后快速定位。 举个例子：用户反馈下单失败。 只有监控：你看到订单服务的错误率从 0.1% 跳到 5%。你盯着 Grafana 看了 10 分钟，猜可能是数据库问题，跑去查 DB 日志。发现有个慢查询。但为什么有慢查询？不知道。继续猜。 有可观测性：你看到错误率跳到 5%，点开 Trace 链路，看到请求在库存服务的 DB 查询 Span 耗时 8 秒。点开这个 Span 关联的日志，看到是连接池等待超时。再看 Metrics，发现连接池活跃连接数在 15 分钟前从 5 飙到 50（配置变更后上限改大了，但数据库端 max_connections 没改）。3 分钟定位完毕。 维度 监控 可观测性 核心问题 出了什么问题？ 为什么出问题？ 数据预设 预定义指标和阈值 探索性分析，支持临时查询 故障模式 已知故障模式 未知故障模式也能排查 数据关联 各系统独立查看 Metrics↔Logs↔Traces 互相关联 典型工具 Zabbix、Nagios Prometheus+Loki+Tempo+Grafana 适用阶段 基础运维阶段 微服务/云原生阶段 别被概念绕晕了。记住一点：监控告诉你"病了"，可观测性告诉你"病在哪、为什么病"。如果你的系统是单体应用、部署在 3 台服务器上，监控够了。但如果你的系统是 50 个微服务跑在 K8s 上，没有可观测性，出了故障你就是盲人摸象。...

概述 凌晨一点四十七分，手机震了。告警群炸了。 某出行项目新上线的推荐服务，上线不到 2 小时，3 个 Pod 全部 OOMKilled。内存从 800MB 飙到 2GB 限制值，然后被内核杀掉，Kubernetes 拉起新 Pod，又被杀掉。循环往复，用户请求全部打到降级链路上，P99 延迟从 80ms 飙到 2000ms。 事后复盘，问题出在哪？开发团队写了完整的单元测试，通过了代码审查，跑了压测——但没有人问过一个最基本的问题：这个服务在生产环境到底"准备好了"没有？ “准备好了"这三个字，在 SRE 圈子里有个正式名字：生产就绪审查（Production Readiness Review，PRR）。Google 在 SRE Book 第 32 章把它定义为 SRE 接手服务运维的第一步——只有通过 PRR 评审，SRE 团队才会同意承担该服务的运维责任。 但问题来了。传统 PRR 是一份文档，由 SRE 工程师逐条检查，填表签字。这种做法在服务数量少的时候还行，当一个企业有 50+ 微服务同时迭代时，人工 PRR 就成了发布瓶颈。开发团队抱怨"审批太慢”，SRE 团队抱怨"服务太多审不过来"，最后 PRR 变成走形式——签字盖章，该炸还是炸。 这篇文章讲的是：怎么把 PRR 从人工文档变成自动化门禁，用 7 个维度的可机器检查项替代人工判断，让"准备好"这件事变成 CI/CD 流水线上的一道闸门，而不是会议室里的一场审批会。 生产就绪审查到底是什么 先说人话。 生产就绪审查就是：一个服务在正式承接真实用户流量之前，必须通过的一组检查。检查的核心问题是——“如果这个服务在生产环境出事了，我们能不能发现、能不能定位、能不能恢复”。 这不是代码审查。代码审查关心的是"代码写得对不对"，PRR 关心的是"这个服务放到生产环境能不能活下来、出了事能不能救回来"。一个代码写得很漂亮但没有任何监控告警的服务，代码审查能通过，PRR 不能通过。 Google 的 PRR 模型覆盖几个核心维度：架构韧性、容量规划、监控告警、故障恢复、部署流程、安全合规。我在实际落地时把它扩展到 7 个维度，因为多出来的两个——运维归属和成本可见性——是我踩了坑之后发现不能省的。 维度 核心问题 传统人工检查 自动化门禁 架构韧性 挂一个副本会不会全挂 看部署 YAML 确认副本数 检查 PDB + 拓扑分布约束 资源配额 会不会 OOM 或 CPU 限流 看资源配置 检查 requests/limits + 历史利用率 部署安全 发坏了能不能回滚 问开发"能不能回滚" 检查滚动策略 + 回滚超时 可观测性 出了事能不能发现和定位 看有没有 Prometheus 指标 检查四金信号指标 + 告警规则 故障恢复 数据丢了能不能恢复 看有没有备份 检查备份频率 + 恢复测试记录 安全合规 权限管没管住 看 RBAC 配置 检查 NetworkPolicy + 镜像扫描 运维归属 出了事找谁 看 Wiki 文档 检查服务目录 + Runbook 链接 为什么人工 PRR 会失效 我在某出行项目推进 PRR 的时候，最初用的就是人工审查。SRE 团队写了一份 40 页的检查清单，每次新服务上线前，开发团队填表，SRE 逐条审核。结果三个星期后发现：...

概述 你大概率遇到过这个场景：SLO 定了 99.9%，错误预算也算了，Grafana 仪表盘画得漂漂亮亮。然后某个周五下午，错误预算已经消耗了 87%，产品经理拿着老板的旨意来说"这个功能周一必须上"。你说不行，预算快没了。产品说"那你说什么时候上"。吵了半小时，最后还是上了。周一晚上果然炸了。 这不是个例。我见过太多团队把错误预算做成了"运维的仪表盘"——指标定义了、告警配了、仪表盘画了，但一到决策环节就失效。问题的根源不是技术实现，而是错误预算从来就不是运维一个人的工具。 这篇文章要讲的是：怎么让错误预算从"运维墙上的一张图"变成"产品发版时绕不开的硬约束"。我会拆解三个层面的工作——把技术指标翻译成产品语言、设计三级响应机制让决策有规则可依、用燃烧速率做预测而非等预算花完才慌。每一步都附完整代码和配置，直接拿去用。 在展开之前，建议先回顾 SLO 的基础概念（相关文章：SRE核心理念：SLI、SLO与错误预算）。本文聚焦的不是"什么是错误预算"，而是"怎么让它真正管用"。 一、错误预算为什么在大多数团队形同虚设 1.1 一个典型失败案例 2024 年，我在某电商平台做 SRE 顾问。他们花了三个月搭建 SLO 体系：梳理了 47 个核心服务的 SLI，每个服务定了 99.9% 或 99.95% 的可用性目标，错误预算计算逻辑也写好了。Grafana 仪表盘很专业，每个服务一个面板，剩余预算一目了然。 然后呢？没有任何决策流程绑定到错误预算上。 产品该发版还是发版，发布评审会上没人看一眼预算仪表盘。直到某次大促前两天，订单服务的错误预算已经归零（实际可用性掉到了 99.82%），但促销活动的代码照常合入。结果大促当天流量翻三倍，订单服务 P99 从 200ms 飙到 3.5s，优惠券模块超时连锁崩溃，最终损失了大约 40 万订单。 事后复盘，所有人都在问：错误预算不是已经标红了吗？为什么没人拦住？ 答案很简单：仪表盘是给别人看的，决策是另一些人做的。两者之间没有桥梁。 1.2 三个根因 我复盘过至少 8 个团队的错误预算落地过程，失败模式高度集中： 失败模式 表现 根因 单方面制定 SLO 由运维独自定，产品不知道也不认 缺乏跨团队共识 只监控不执行 仪表盘有，但没有发布门禁代码 没有把预算消耗和发布流程绑定 当惩罚用 预算耗尽=运维要找开发的麻烦 定位错误，预算是共享决策工具不是武器 第三个最致命。错误预算的设计意图——Google SRE Workbook 里讲得很清楚——是给开发和运维一个共同的数据基础，让"要不要发版"从立场之争变成数据决策（来源：Google SRE Workbook）。如果运维把它当武器去卡开发，开发就会想办法绕过——比如把故障时间拆小到不触发阈值，或者在 SLO 计算窗口结束前一天重启计数器。 我的观点：错误预算落地的第一步不是配告警，而是开一次跨团队会议，让产品、开发、运维三方共同签署一份"错误预算策略文档"。这份文档要回答三个问题：预算耗尽时谁有权叫停发布？叫停后恢复条件是什么？预算充足时谁有权加速发布？没有这份共识，任何技术实现都是空中楼阁。 二、把错误预算翻译成产品语言 2.1 产品经理看不懂"剩余预算 13%" 你跟产品经理说"订单服务的错误预算还剩 13%"，他脑子里想的可能是"13% 听起来还有不少啊"。你得换一种语言。...

概述 凌晨三点，手机震了。你看了一眼——P1 告警，订单服务 5xx 错误率飙升。爬起来，开电脑，拉日志，查 Grafana，定位到是上游数据库连接池打满。重启、扩容、恢复，一看表四点半了。第二天早上你顶着黑眼圈开会，会上有人说"昨晚那个告警其实是误报"。 这种感觉，干过运维的人都懂。 On-Call（值班响应）是 SRE 工作中绕不开的一环。但很多团队的 On-Call 做成了"谁被叫醒谁处理"，没有轮值，没有备份，没有交接，更没有疲劳管理。结果是：核心工程师离职，告警群形同虚设，故障响应越来越慢。 这篇文章聊聊 On-Call 排班设计中的 7 个工程决策。不是理论框架，是我这些年从 0 到 1 搭建 SRE 值班体系时踩过的坑、做过的取舍。在之前的事件管理与 On-Call 机制设计中讲过事件响应流程，本文聚焦在"排班本身怎么设计"——轮值周期、主备机制、告警分级、疲劳量化、交接班、新人上岗、补偿与度量。 如果你是刚接手 SRE 团队的技术负责人，或者正在被无序的值班制度折磨，这篇文章应该能帮你少走半年弯路。 一、On-Call 到底在解决什么问题 先说清楚 On-Call 是干嘛的，再说怎么设计。 On-Call 的本质是：在非工作时间，系统出问题时，有人能第一时间响应并恢复。 打个比方：医院急诊科不能晚上关门。医生白天上班，晚上也得有人值班。但值班的医生不是同一个人连值一周不睡觉——那第二天手术手抖就出医疗事故了。所以医院有轮班制度：白班、夜班、备班，轮着来，保证每个班次的医生都是清醒的。 On-Call 的逻辑一样。你的系统 7x24 小时跑着，但工程师不能 7x24 小时盯着。On-Call 排班就是让"正确的人在正确的时间收到告警"，而不是"所有人都收到告警"或者"没人收到告警"。 Google SRE 的 On-Call 原则 Google SRE 在《Google 运维解密》里用三个章节讲 On-Call，核心原则就一条：琐事不能超过工作时间的 50%。 什么是"琐事"（Toil）？Google 的定义是：重复的、可自动化的、战术性的、没有持久价值的工作。比如手动重启服务、手动扩容、手动查日志定位问题——这些都是琐事。On-Call 是琐事最大的来源之一。 一个 SRE 至少要花一半时间做工程项目（写代码、做工具、改架构），否则就是在用人力填系统的坑，越填越深。要保证这个比例，团队至少需要 6-8 人轮值——人少了轮不过来，工程时间被值班吃光。 Google SRE 的 on-call 方法和工具 这篇文章里有一个很清晰的分析：Google 通过 Outalator 工具管理告警的全生命周期，包括聚合、标签、分析、交接报告，让 On-Call 不只是"被叫醒"，而是"被管理"。Outalator 的核心功能包括：...

概述 99.5% 的可用性听起来不错——直到你算一笔账。 一年 8760 小时，99.5% 意味着允许停机 43.8 小时。换算到每个月，差不多 3.65 小时的服务中断。如果是核心交易系统，这 3.65 小时可能就是几十万的订单损失。如果赶在大促期间，损失会翻几十倍。 99.9% 呢？年停机 8.77 小时，月均不到 44 分钟。停机时间砍掉 80%。 0.4 个百分点的提升，背后不是加几台服务器那么简单。我在某出行平台推动过一次这样的改造，从立项到稳定运行在 99.9% 以上，花了整整 14 个月。这期间踩的坑、做的权衡、推翻重来的方案，比写代码本身多得多。 这篇文章不讲理论框架，只拆解我们做过的 6 个关键工程决策，以及 3 个让我后背发凉的踩坑时刻。每个决策都附上我们当时的选型对比和最终方案，你拿去就能对照自己的系统查漏补缺。 可用性的数学本质：为什么 0.4% 这么难 先搞清楚一件事：可用性不是加法，是乘法。 假设你的系统由 3 个服务串联组成，每个服务可用性 99.5%。整个链路的可用性是多少？ 0.995 × 0.995 × 0.995 = 0.9851 ≈ 98.51% 三个"还不错"的服务串联起来，整体可用性直接跌破 99%。年停机从单服务的 43.8 小时暴涨到 128 小时——超过 5 天。 反过来想：如果链路有 10 个服务，每个要达到整体 99.9% 的可用性，单个服务的可用性得是多少？ 0.999^(1/10) ≈ 0.99990 → 99.99% 十个服务每个都得做到四个九。这就是为什么微服务架构下可用性提升的难度呈指数级增长。 关键认知：提升可用性不是给单个服务加机器，而是同时做三件事——减少串联依赖数量、提高单个服务可用性、在关键路径上做冗余和降级。 Google SRE 团队在 The Calculus of Service Availability 中提到一个观点：大多数服务的内部目标应该定在 99....

概述 凌晨 1 点 47 分，手机震了。告警群弹出 200 多条消息，订单成功率从 99.8% 掉到 92%。值班同学重启服务、回滚版本，折腾了 40 分钟才恢复。 第二天复盘，根因是下午发版时改了一行数据库连接池配置。这个变更走了完整的审批流程——开发提交、测试验证、主管签字、SRE 评审，审批花了 3 天。3 天审批，1 行配置，40 分钟故障。 这不是个案。Google SRE Book 里有个数据：大约 70% 的服务中断是由变更引起的。我在某电商平台做了 6 个月的统计，比例更夸张——82% 的 P1/P2 故障直接或间接跟变更有关。 问题出在哪？传统变更管理靠"人审"，而人审解决不了三个矛盾： 审批者不一定懂代码：签字的人大多是管理者，看不懂配置变更的技术影响 审批再严也挡不住低级错误：3 天审批审查的是流程合规性，不是技术正确性 审批拖慢迭代速度：开发为了过审拆小包、绕流程，反而增加变更频次 Google 的解法很直接：把变更管理从"人审"变成"机器门禁"，用错误预算做自动裁决，用渐进式发布做安全网。本文拆解我在某出行项目落地这套体系的完整过程——从审批流程改造到 Go 代码实现，包含真实踩坑和性能数据。 传统 CAB 模式的困境 CAB（Change Advisory Board，变更顾问委员会）是 ITIL 时代的标准做法。每次变更提交申请，CAB 成员（通常是运维主管、安全负责人、架构师）开会评审，投票决定是否放行。 听起来很合理，实际跑起来全是问题。 人工审批的三个死结 死结一：审批者看不懂变更内容 我见过一个 CAB，5 个审批人里 3 个是管理层。他们审查什么？表单填写是否完整、影响范围评估是否打钩、回滚方案是否写了。至于那行配置改了什么、对系统有什么实际影响——看不懂，也没法判断。 结果就是，审批变成了走过场。表单填得漂亮就过，填得丑就打回。技术风险？全靠开发自觉。 死结二：审批速度和变更质量无关 审批 3 天，不代表这 3 天里有人在做技术验证。实际情况是：变更提交后躺在 OA 系统里等 2 天，第 3 天 CAB 开会 10 分钟过一下就批了。3 天里有 2 天 22 小时是等待时间。...

概述 凌晨三点，你被告警吵醒。爬起来一看：CPU 正常、内存正常、Pod 也在跑，但用户投诉说"系统卡得用不了"。你打开 Grafana 面板，画了一堆曲线，却说不清楚——这到底算不算故障？ 这个场景，我在多个企业客户的 SRE 咨询中反复遇到。核心问题不是监控不够多，而是度量体系设计错了方向：我们一直在监控"系统内部的指标"，而不是"用户感受到的服务质量"。 曾经在一次某出行平台的故障复盘中，团队发现一个讽刺的事实：告警系统在故障发生 12 分钟后才触发，而用户在故障发生后 30 秒就已经开始投诉了。原因很简单——告警基于 CPU 使用率超 80% 触发，但实际故障是数据库连接池耗尽，CPU 才 35%，根本没碰阈值。 可靠性度量的本质，是把"系统稳不稳"这个问题，从主观感觉变成可量化的数字。这篇文章不讲 SLI/SLO 的基础概念（这些在 相关文章：SRE核心理念：SLI、SLO与错误预算 中已经讲透了），而是聚焦于：如何从零设计一套完整、可落地、能驱动决策的可靠性度量体系。 为什么传统监控体系不能回答"系统稳不稳" 先说结论：传统监控体系回答不了"系统稳不稳"，因为它度量的对象错了。 传统监控的三个盲区 盲区一：监控的是资源，不是用户体验 大多数团队的监控面板长这样：CPU 折线图、内存折线图、磁盘 IO 折线图、网络流量折线图。这些指标反映的是"服务器忙不忙"，而不是"用户爽不爽"。 举个真实的例子：某电商平台的订单服务，CPU 使用率常年 70%，运维觉得"不太对劲"，计划扩容。但实际上 P99 延迟 120ms，请求成功率 99.97%，用户体验完全没问题。另一个缓存服务，CPU 才 20%，看起来"很健康"，但缓存命中率从 95% 掉到 60%，导致数据库被打爆，用户实际体验已经很差了。 盲区二：没有"好"和"坏"的量化边界 “CPU 80% 算好还是算坏？"——这个问题在传统监控体系里没有答案。80% 可能是正常的批处理负载，也可能是即将打满的前兆。没有 SLO 的情况下，80% 就只是一个数字，不是判断依据。 Google SRE Book 里有一段话说得很到位：“如果你不能度量它，你就不能管理它。” 但更准确的说法应该是：如果你度量错了对象，比不度量更危险——因为你会基于错误的信号做决策。 盲区三：告警基于静态阈值，不感知业务影响 传统告警的逻辑是"指标超过阈值就报”。问题是，同样的阈值在不同业务场景下含义完全不同： 场景 CPU 80% 含义 是否需要告警 凌晨 2 点批处理任务 正常负载 不需要 大促期间核心交易服务 即将打满 紧急告警 测试环境压测中 预期行为 不需要 生产环境空闲时段 异常进程 需要排查 静态阈值无法区分这些场景，导致的结果就是：要么告警太多（告警疲劳），要么告警太晚（用户已经投诉了才报）。...

概述 凌晨三点，手机狂震。打开一看，告警群已经炸了——支付服务 P99 延迟从 50ms 飙到 12 秒，错误率突破 80%。更要命的是，故障像多米诺骨牌一样连锁反应：用户服务超时 → 鉴权失败 → 库存服务重试风暴 → 消息队列阻塞 → 支付回调全部超时。监控大屏上三十秒内全部变红。 这不是某家公司独有的惨案。微服务拆得越细，服务间调用链越长，一个局部故障就越容易演变成全局雪崩。我曾在某新能源物流平台治理 50+ 微服务时，亲历过三次类似事故，最后一次最严重——一个下游搜索服务的数据库连接池打满，导致上游所有依赖搜索结果的服务线程池连锁耗尽，整条交易链路瘫痪 17 分钟。 那次事故后我们花了两周时间重做限流熔断降级体系。最终把 P99 从 200ms 压到 170ms，更重要的是，之后再没出现过级联故障。这篇文章把我踩过的坑、做过的架构选型、以及生产环境真正有效的配置经验一次讲透。 先说清楚三者的关系——很多人混着用，但它们解决的问题不同： 防护手段 解决什么问题 类比 作用位置 限流（Rate Limiting） 流量超过系统承载能力 超市收银台只开 3 个窗口，排满了就不让进了 入口处 熔断（Circuit Breaking） 下游服务故障，防止故障蔓延 保险丝，电流过大自动断电 调用链中间 降级（Degradation） 核心功能不可用时提供替代方案 停电了用应急灯，虽然不亮但能看见 业务逻辑层 三者配合使用：限流挡在前面控制输入，熔断在中间切断故障传播，降级在尾部保证用户体验不至于完全崩溃。 雪崩效应：为什么微服务比单体更容易崩 单体应用里，方法调用是进程内函数调用，微秒级完成。微服务拆开后，每次调用都变成了网络请求——网络可能抖动、DNS 可能解析慢、TCP 三次握手有开销、序列化反序列化要时间。一个用户请求从网关进来，经过 5-7 层服务调用是常态。 故障传播路径 看一个真实的调用链： 用户请求 → API Gateway → 订单服务 → 用户服务（鉴权） → 库存服务（扣减） → 优惠券服务 → 支付服务 → 第三方支付网关 假设第三方支付网关变慢了（比如响应从 100ms 变成 5 秒），会发生什么？...

概述 每个做过线上运维的人大概都经历过这个场景：凌晨三点被告警吵醒，一通操作止血恢复，第二天组织复盘，会上列了十几条改进措施，会议纪要发到群里，大家纷纷表示"收到"。然后呢？一个月后你翻出来看，真正落地的大概只有两三条，其余的全躺在某个文档里吃灰。更扎心的是，半年后类似故障又来了一次，复盘会上一翻历史记录，好家伙，上次就提过改进建议，就是没人跟进。 这不叫复盘，这叫走过场。 改进项跟踪（Action Items Tracking）解决的就是这个问题——把复盘会议上产出的改进清单，变成有负责人、有截止日期、有验收标准、能被持续追踪直到闭环的工作项。说白了，复盘的价值不在会议本身，而在会议之后的那三个月里，这些改进项到底执行了没有、执行到位了没有。 Google SRE Book 里有一句话大意是：复盘没有 action items 的故障，等于白复盘。但我觉得这话还差半句——有 action items 但没跟踪，一样白复盘。 这篇文章聊的就是改进项跟踪这件事怎么做。从改进项的分类和生命周期讲起，到跟踪工具选型，再到自动化提醒和度量指标，最后给一套可以直接落地的实践方案。 改进项是什么：从模糊建议到可执行任务 改进项不是建议 很多人把"改进项"和"建议"搞混了。复盘会上有人说"以后上线要多测试一下"，这是建议，不是改进项。改进项必须是可执行、可追踪、可验收的具体任务。 一个合格的改进项需要回答五个问题： 要素 说明 反面示例 正面示例 做什么 具体的行动内容 “加强监控” “为订单服务的下游调用增加超时熔断，超时阈值设为 3 秒” 谁来做 明确到具体责任人 “研发团队” “张三（订单服务 owner）” 什么时候完成 有明确的截止日期 “尽快” “2026-08-15 前” 怎么验收 可验证的完成标准 “优化好” “Prometheus 中出现 order_downstream_timeout_total 指标，且在压测环境验证熔断生效” 优先级 P0/P1/P2 分级 不标注 “P1：影响范围是全量用户，需在两周内完成” 缺任何一个要素的"改进项"，本质上都是空头支票。你没法跟踪一张空头支票。 改进项的分类 根据改进的对象和执行周期，改进项可以分为四类： 1. 技术修复类（Technical Fix） 直接改代码或配置就能解决的问题。比如修复一个 bug、补一段熔断逻辑、加一个监控指标。这类改进项执行周期短，通常几天到两周搞定。 示例： - 修复 order-service 的 N+1 查询问题（P0，2 天内） - 为 payment-gateway 增加限流中间件（P1，1 周内） - 将 Redis 连接池从 lettuce 换成 jedis 并配置合理超时（P2，2 周内） 2....

概述 凌晨三点，核心交易系统挂了。值班同学手忙脚乱地翻 Runbook，DBA 说不是数据库的问题，网络组说链路正常，开发说代码没改。三个团队互相甩锅，故障恢复时间拖了 47 分钟。 这是很多公司运维现状的缩影。问题不在于人不努力，而在于没有一个工程化的可靠性团队来拆解问题。 SRE（Site Reliability Engineering）这个概念是 Google 在 2003 年提出来的。Ben Treynor Sloss 带着一帮软件工程师，用写代码的方式解决运维问题，而不是靠堆人力。(Google SRE 书 里把这个故事讲得很清楚) 但"建一个 SRE 团队"这件事，远比"招几个 SRE 工程师"复杂。这篇笔记记录的是从零搭建 SRE 团队的实战经验——岗位怎么设、人怎么招、能力怎么评、团队怎么带。不讲理论框架，讲踩过的坑和跑通的做法。 为什么要建 SRE 团队，而不是继续用传统运维 先说清楚一个根本问题：SRE 和传统运维到底有什么不同？ 传统运维团队的核心模式是"人肉运维"——出了问题靠经验排查，日常操作靠手动执行，知识靠师傅带徒弟口口相传。人越多，能覆盖的系统越多，但效率不会提升。真正的问题在于，这种模式下，运维工作量随系统规模线性增长，而人不可能无限招。 Google 的做法是用软件工程的方法替代重复性操作。SRE 团队里，每个人花在纯运维操作上的时间不超过 50%，剩下时间必须用来做工程化改进——写自动化工具、设计监控系统、优化部署流程。Google 在《SRE: Google 运维解密》中明确要求 SRE 团队的琐事（Toil）占比不得超过 50%，这叫"50% 规则"。(Google SRE Book - Eliminating Toil) 对比如下： 维度 传统运维团队 SRE 团队 核心能力 操作执行、经验排查 编码、系统设计、自动化 工作模式 被动响应 主动工程化 知识传承 口口相传 Runbook、文档、代码 团队规模与系统规模 线性增长 边际递减 考核导向 处理工单数量 可靠性指标 + 自动化覆盖率 故障处理 救火为主 事后复盘 + 系统性改进 一句话总结：传统运维是"用人力扛系统"，SRE 是"用代码养系统"。...