方法论

概述 SRE（站点可靠性工程）的核心理念是：用工程方法管理可靠性。其中最关键的工具就是 SLI、SLO 和错误预算。 SLI：服务等级指标 SLI 是衡量系统可靠性的量化指标。常见的 SLI 包括： 可用性：成功请求数 / 总请求数 延迟：P99 响应时间 < 200ms 吞吐量：QPS > 10000 正确性：数据一致性校验通过率 选择 SLI 的关键原则：从用户视角出发。用户不关心你的 CPU 使用率，只关心请求是否成功、是否够快。 SLO：服务等级目标 SLO 是 SLI 的目标值。例如： slo: availability: target: 0.999 # 99.9% 可用性 window: "30d" latency: target: 200 # P99 < 200ms window: "30d" 99.9% 的可用性意味着每月允许约 43.8 分钟 不可用。 错误预算 错误预算是 SRE 最精妙的设计： SLO 设为 99.9% → 错误预算 = 0.1% 预算未耗尽：可以发布新功能、做激进变更 预算耗尽：冻结发布，专注稳定性改进 这个机制让"稳定性 vs 迭代速度"不再是口角之争，而是可量化的工程决策。 实践建议 从核心服务开始：不要试图一次性定义所有服务的 SLO 先粗糙后精细：初始 SLO 可以基于历史数据粗略设定，逐步迭代 定期回顾：每月 review SLO 达成情况，调整不合理的指标 自动化告警：基于错误预算消耗速率设置告警，而非固定阈值 总结 SLI/SLO/错误预算构成了 SRE 的度量基石。没有度量就没有管理——这正是 SRE 区别于传统运维的核心。

概述 很多团队把 SRE 理解为"运维换个名字"——招几个会写脚本的人，改个 Title，就算转型了。这种认知忽略了一个根本事实：SRE 是一种工程方法论，不是一套工具链。Google 在 2003 年创建 SRE 职能时，核心理念就是"用软件工程方法解决运维问题"，这从根本上改变了运维的定位、工作方式和文化。 从组织定位、文化差异、工程化实践和度量体系四个维度，系统性地剖析 SRE 与传统运维的本质区别，并给出团队转型路径建议。 一、组织定位：工程师 vs 支撑角色 传统运维的定位困境 传统运维团队通常被定位为"支撑角色"——开发负责写代码，运维负责让代码跑起来。这种分工看似清晰，实则制造了一个致命的对立面： 开发追求"快"：快速上线、快速迭代，功能越多越好 运维追求"稳"：变更越少越好，最好什么都别动 这种目标冲突导致的结果是：开发把运维当作发布的障碍，运维把开发当作故障的根源。最终演变为一个"拉锯战"——开发提需求，运维挡需求，谁的话语权大谁说了算。 SRE 的定位：工程师 SRE 的根本定位是软件工程师，只是专注于"可靠性"这个领域。Google SRE Book 第一章就明确指出： “SRE is what happens when you ask a software engineer to design an operations team.” 来源：Google SRE Book - Introduction 这意味着 SRE 的工作方式是工程化的： 遇到重复劳动 → 写工具自动化 遇到故障 → 做根因分析并修复系统性问题 遇到容量问题 → 建模型、做预测 遇到流程瓶颈 → 优化流程，而非增加人力 具体对比 维度 传统运维 SRE 定位 支撑角色，被动响应 工程师，主动设计 工作内容 工单处理、手动变更、故障排查 系统设计、自动化、可靠性工程 成功标准 系统没出事 系统在 SLO 范围内，错误预算可控 与开发关系 对立面（快 vs 稳） 协作伙伴（共同对 SLO 负责） 二、文化差异：工程文化 vs 经验文化 错误预算 vs 人工兜底 传统运维文化中，“可用性"是一个模糊的概念——领导说"要 4 个 9”，运维就拼命堆冗余、加监控、人工值守。一旦出了事故，就增加人手和流程来"防止再犯"。...

概述 性能问题几乎是每个 SRE 都会遇到的高频场景：用户反馈"好慢"、告警说"P99 延迟超标"、监控显示"CPU 快满了"。但很多团队对性能问题的处理方式是"哪里高了调哪里"——CPU 高了就加机器，SQL 慢了就加索引，延迟高了就加缓存。这种头痛医头的做法短期内可能有效，但长期来看会让系统越来越复杂、成本越来越高、问题越来越难排查。 性能工程（Performance Engineering）与性能调优（Performance Tuning）有本质区别。性能调优是"发现问题→优化"的反应式过程；性能工程是"建立基线→持续度量→主动发现→系统优化"的工程化体系。SRE 的视角不是"让某个接口快 10ms"，而是"建立系统性的性能管理体系，让性能问题在被用户感知之前发现和解决"。 从方法论、分析框架、基线建立、瓶颈定位、优化策略到持续管理，详细梳理 SRE 视角的性能工程。 关于性能分析的系统性方法，可参考 Brendan Gregg - USE Method 和 Tom Wilkie - RED Method。 一、性能工程 vs 性能调优 概念区分 维度 性能调优 性能工程 时机 性能问题出现后 贯穿系统全生命周期 目标 解决当前的性能问题 建立持续的性能管理体系 方法 经验驱动，试试看 数据驱动，详细分析 范围 聚焦特定瓶颈 覆盖全栈（应用→中间件→基础设施） 产出 问题解决 基线、SLO、监控、优化策略 持续性 一次性 持续度量和管理 为什么 SRE 需要性能工程 没有性能工程的团队： 用户投诉"慢" → 紧急排查 → 发现 SQL 慢 → 加索引 → 一个月后又慢了 → 发现是缓存命中率低 → 加缓存 → 又一个月后又慢了 → 发现是连接池不够 → 调连接池 → 循环往复，系统越来越复杂，问题越来越多 有性能工程的团队： 建立性能基线 → 持续监控 → 发现 P99 缓慢上升（用户还没感知） → 主动分析 → 定位到数据库查询模式变化 → 优化查询 → 在用户感知之前解决问题 性能工程的价值：...

概述 很多团队在实践 SRE 时遇到的第一个困境是：知道 SLO 是什么，但不知道怎么设。要么照搬 Google 的 99.99%，要么随便拍一个 99.9%——然后发现这个数字既不反映用户体验，也无法驱动工程决策。 好的 SLO 不是拍脑袋拍出来的，而是从业务目标出发，经过用户旅程分析、指标选择、数值校准、多层级设计、定期评审等一系列工程方法推导出来的。详细梳理 SLO 设计的完整方法论，帮助你建立从"业务目标"到"技术指标"的完整映射链路。 本文假设读者已了解 SLI/SLO 的基本概念。如需补充，可参考 Google SRE Workbook - Service Level Objectives 和本站 SRE核心理念：SLI、SLO与错误预算。 一、SLO 设计金字塔 SLO 设计不是孤立的技术活动，而是从上到下的分层推导过程： ┌─────────────┐ │ 业务目标 │ "我们的服务需要做到什么程度？" └──────┬──────┘ │ ┌──────▼──────┐ │ 用户体验 │ "用户关心什么？" └──────┬──────┘ │ ┌──────▼──────┐ │ SLI 定义 │ "我们怎么衡量用户体验？" └──────┬──────┘ │ ┌──────▼──────┐ │ SLO 目标值 │ "这个指标要做到多少？" └──────┬──────┘ │ ┌──────▼──────┐ │ 告警与行动 │ "不达标时怎么办？" └─────────────┘ 第一层：业务目标 一切 SLO 设计的起点是业务目标，而不是技术指标。业务目标回答的问题是：这个服务对业务的价值是什么？...