SRE

概述 SRE 文档化实践：Runbook、架构图与知识库建设是SRE运维工作中的重要技能。在实际生产环境中，掌握这些技术能够有效提升系统的稳定性和运维效率。 为什么需要SRE 文档化实践 随着系统规模的扩大和复杂度的增加，传统的运维手段已经难以满足现代分布式系统的需求。SRE 文档化实践能够帮助运维团队： 快速定位问题：通过系统化的工具和方法，缩短故障排查时间 提升系统可见性：建立全面的监控和可观测性体系 预防故障发生：通过主动发现和修复潜在风险，降低故障率 优化资源利用：合理分配和调度资源，提升系统性能 核心概念与原理 基础概念 SRE 文档化实践的核心在于建立标准化的流程和自动化的工具链。主要包括以下几个方面： 数据收集与处理：从各种数据源收集指标、日志和追踪信息 分析与可视化：通过仪表盘和告警系统展示系统状态 自动化响应：基于预设规则自动执行修复操作 持续优化：根据历史数据和反馈不断改进流程 关键技术点 1. 配置管理 合理的配置管理是SRE 文档化实践的基础。建议使用版本控制工具管理配置文件，确保变更可追溯： # 示例：配置版本控制 # 所有配置文件存放在 Git 仓库中 git init /etc/monitoring cd /etc/monitoring git add . git commit -m "Initial monitoring configuration" 2. 自动化工具选择 根据团队技术栈选择合适的工具： 场景 推荐工具 说明 配置管理 Ansible 无代理，适合中小规模 容器编排 Kubernetes 云原生标准 监控告警 Prometheus + Grafana 开源，社区活跃 日志收集 Loki / ELK 轻量或功能丰富 CI/CD GitLab CI / GitHub Actions 与代码托管集成 实践案例 场景：生产环境故障排查 假设线上服务出现响应延迟，排查步骤如下：...

概述 当你的业务从"服务一个城市"扩展到"服务全国"甚至"服务全球"时，单机房架构会遇到两个硬约束：距离带来的延迟和单点故障的风险。多地域多活架构是解决这两个问题的工程方案。 但多活架构是 SRE 领域最复杂的主题之一——它不是简单的"在两个机房部署服务"，而是涉及数据一致性、流量调度、故障切换、运维复杂度等一系列深层工程挑战。做对了，系统可用性从 99.9% 提升到 99.99%；做错了，多活架构本身就会成为最大的故障源。 从多活架构模式、数据一致性挑战、流量切换策略、容灾 RTO/RPO 设计、跨地域监控到故障切换演练，详细梳理多活架构的可靠性设计。 关于多活架构的深入讨论，可参考 Google SRE Book - Disaster Preparedness 和 AWS - Multi-Region Active-Active Architecture。 一、为什么需要多活架构 单机房架构的局限 单机房架构： ┌── App Server ×N 用户 ──→ DNS/CDN ──→ Load Balancer ─────┼── App Server ×N └── App Server ×N │ ┌─────────┴─────────┐ │ Database (主从) │ └───────────────────┘ 问题： 1. 如果机房断电/网络中断 → 全站不可用 2. 跨地域用户延迟高（北京到广州 ~30ms RTT） 3. 容量受限于单个机房 多活架构的驱动力 驱动力 说明 优先级 容灾 机房级故障时业务不中断 高 低延迟 就近服务用户，降低访问延迟 高 容量扩展 突破单机房容量上限 中 合规要求 数据必须在特定地域存储 视行业 容灾演练要求 监管要求具备跨机房容灾能力 视行业 容灾的关键指标 在设计多活架构之前，必须先明确两个容灾指标：...

概述 在现代软件工程中，SRE（站点可靠性工程）与开发团队的关系是最关键也最微妙的一环。开发追求的是"快速交付新功能"，SRE 追求的是"系统稳定运行"——这两个目标天然存在张力。如果协作模式设计不当，轻则效率低下、互相甩锅，重则线上事故频发、团队信任崩塌。 Google SRE Book 中有一句经典的话：“SRE 的核心矛盾在于，我们需要同时让开发团队快速前进，同时保持系统的可靠性。“这句话至今仍然精准。问题的本质不在于"要不要协作”——答案是显然的——而在于如何协作，采用什么样的组织模型、流程机制和工具支撑，才能让两个目标不冲突甚至互相促进。 将逐步梳理 SRE 与开发团队协作的常见模式、冲突根源、工程化解决方案，以及平台工程（Platform Engineering）等新趋势下的演进方向。内容基于 Google SRE Book、Team Topologies 等权威理论，结合一线生产实践经验。 冲突的根源：为什么 SRE 和开发天然存在张力 激励机制的不一致 SRE 与开发团队冲突的最深层原因，是两者激励机制的天然错位： 维度 开发团队 SRE 团队 核心目标 功能交付速度 系统稳定性 成功标准 发布频率、故事点完成率 SLA 达成率、事故数量 风险偏好 愿意承担一定风险快速上线 倾向于保守，降低变更风险 关注时间窗 短期（当前迭代/季度） 长期（系统全生命周期） 对变更的态度 变更是价值的来源 变更是故障的来源 这种错位不是"谁对谁错"的问题，而是组织分工带来的结构性矛盾。Google 最早提出的 SRE 模型，其实就是试图用工程化手段来协调这种矛盾。 常见的协作失败模式 在实际工作中，以下几种失败模式反复出现： 模式一：SRE 沦为"运维打杂” 开发把代码扔过墙，SRE 负责部署、监控、值班和擦屁股。SRE 没有时间和精力做工程改进，变成了高级运维。这是最常见的退化模式。 模式二：SRE 成为"发布守门人" SRE 拥有生产环境准入权，但缺乏工程能力帮助开发提升质量，只能靠"卡发布"来降低风险。结果是开发把 SRE 视为障碍，SRE 把开发视为不靠谱，信任持续恶化。 模式三：责任模糊的"共同所有权" 所有人对系统可靠性"共同负责"，结果没有人真正负责。事故发生时互相推诿，改进时无人牵头。 模式四：SRE 与开发完全隔离 SRE 团队自成体系，与开发几乎没有日常交流。SRE 对业务上下文缺乏理解，做出的架构决策脱离实际；开发对 SRE 的工作不了解，无法有效配合。...

变更管理在 SRE 中的定位 Google SRE 总结的一条铁律：大约 70% 的线上故障由变更直接引发。无论是代码部署、配置修改、基础设施调整还是依赖升级，每一次变更都在向系统注入不确定性。因此，变更管理不是流程上的繁文缛节，而是 SRE 可靠性工程的第一道防线。 变更管理的核心目标可以归纳为三点： 降低爆炸半径——变更出了问题，影响面应尽可能小。 缩短发现问题的时间——变更后若出现异常，必须能在分钟级甚至秒级感知。 具备快速回滚能力——发现问题后，能在最短时间内恢复到上一个已知正常状态。 实现这三个目标的关键技术手段就是灰度发布与快速回滚。下面逐一展开。 金丝雀发布原理与实现 核心思想 “金丝雀"一词源自矿工带金丝雀下井探测有毒气体的做法。在软件发布中，金丝雀发布指的是：先将新版本部署到极小比例的实例上，引入少量真实流量进行验证，确认无异常后再逐步扩大流量比例，直至全量切换。 与全量发布相比，金丝雀发布的本质区别在于引入了流量比例控制和指标门控两个机制，使发布过程变成一个可控的、可观测的渐进过程。 流量比例控制 典型的金丝雀发布流量推进序列： 5% → 10% → 25% → 50% → 100% 每个阶段之间设置观察窗口（如 5-10 分钟），期间持续采集关键指标。只有当指标满足预设的健康标准时，才推进到下一阶段；否则自动暂停甚至回滚。 指标门控 指标门控是金丝雀发布的"大脑”。通常关注以下几类指标： 指标类别 示例 门控逻辑 错误率 HTTP 5xx 比例 金丝雀错误率 > 基线 1.5x → 自动回滚 延迟 P99 / P95 响应时间 金丝雀 P99 > 基线 + 50ms → 暂停推进 业务指标 下单成功率、支付成功率 成功率下降 > 2% → 自动回滚 资源指标 CPU、内存、连接数 资源使用率异常飙升 → 告警暂停 关键原则：门控指标必须从用户视角出发，而非仅看基础设施指标。一个 CPU 正常但 P99 翻倍的系统，仍然应该触发回滚。...

可靠性工程：不只是"不出故障" 可靠性工程的目标不是追求零故障——那既不现实也不经济。真正的目标是：在故障不可避免的前提下，让系统具备快速发现、自动恢复、持续学习的能力。 Google SRE 提出的核心公式： MTTR << MTBF / (MTBF + MTTR) × (1 - SLO) 这个公式揭示了一个关键事实：当故障间隔（MTBF）远大于修复时间（MTTR）时，系统的可用性自然趋近于 SLO 目标。因此，可靠性工程的发力方向是双重的——延长无故障时间（提升 MTBF）和缩短故障恢复时间（降低 MTTR）。 可靠性层级模型 参考 CMMI 能力成熟度模型的思想，可靠性工程同样存在层级递进关系。从低到高分为五个层级： 层级 特征 典型表现 L1 被动响应 故障发生后人工处理 告警轰炸 → 人工排查 → 手动恢复 L2 监控覆盖 关键指标可观测 仪表盘完备，告警有阈值，但恢复仍靠人 L3 自动化恢复 常见故障自动处理 健康检查自动重启、HPA 自动扩容 L4 主动预防 提前发现风险 压测、容量规划、混沌工程主动注入故障 L5 自愈系统 闭环自适应 故障自动感知 → 诊断 → 恢复 → 学习 大部分团队的真实水平在 L2 到 L3 之间。从 L3 到 L4 的跨越是最关键的——它意味着从"等故障来"转变为"主动找故障"。L5 自愈是理想态，也是持续演进的方向。 层级跃迁的关键 L1 → L2：建设可观测性体系（指标、日志、链路追踪）。 L2 → L3：引入自动化恢复机制（Kubernetes 健康检查、HPA、自动故障转移）。 L3 → L4：引入混沌工程，主动验证系统的弹性。 L4 → L5：建设自愈闭环，将人工经验沉淀为自动化策略。 每一层级的跨越都需要对应的技术投入和组织能力建设，不能跳级。...

概述 监控系统本身也需要被监控。Prometheus 采集了整个基础设施的指标，但如果 Prometheus 自己的配置出了问题、某个 target 掉线了、SSL 证书快过期了、告警规则写得有语法错误——谁来发现这些问题？答案是：一套自动化巡检脚本。本文围绕 Prometheus 生态，构建一套覆盖"拨测→证书检查→配置审计→规则验证→告警模拟→报表生成"的完整巡检工具集。 参考来源：Prometheus 官方文档、Blackbox Exporter 一、批量服务拨测脚本 1.1 基于 Blackbox Exporter 的拨测 Blackbox Exporter 是 Prometheus 官方的黑盒探测工具，支持 HTTP、TCP、ICMP、DNS 等协议。通过 Prometheus API 查询探测结果，可以实现批量服务健康检查： #!/usr/bin/env python3 """ 批量服务拨测脚本 通过 Prometheus API 查询 Blackbox Exporter 探测结果 """ import requests import json from datetime import datetime from typing import List, Dict, Optional from dataclasses import dataclass, asdict import smtplib from email.mime.text import MIMEText import sys @dataclass class ProbeResult: """探测结果""" instance: str module: str # http_2xx, tcp_connect, icmp 等 success: bool status_code: Optional[int] duration: float # 探测耗时（秒） error: Optional[str] last_error: Optional[str] ssl_cert_expiry_days: Optional[float] class PrometheusProber: """Prometheus 拨测器""" def __init__(self, prometheus_url: str, timeout: int = 30): self....

概述 传统的可靠性保障思路是"尽量不出故障"——加监控、加告警、加冗余。但这种被动防御有一个根本缺陷：你不知道系统在故障发生时的真实表现，直到故障真正发生。 混沌工程反其道而行之：主动、可控地注入故障，在故障变成事故之前发现系统的弱点。 它不是搞破坏，而是一种科学的实验方法——提出假设（“系统应该能承受某节点故障”），设计实验（杀掉一个节点），验证假设（服务是否仍然正常），发现弱点（如果服务异常了）。 Netflix 的 Chaos Monkey 开创了这一领域，如今混沌工程已经成为 SRE 体系的重要组成部分。从原理、实验设计、爆炸半径控制、Kubernetes 实战到常态化实践，详细梳理如何把混沌工程从"概念"落地为"日常实践"。 关于混沌工程的原则，可参考 Principles of Chaos Engineering 和 Chaos Engineering Book。 一、混沌工程的原理 核心思想 混沌工程的核心思想是： 在正常流量期间，通过有意注入故障来验证系统的弹性，从而在故障变成事故之前发现并修复弱点。 这与传统的测试有本质区别： 维度 传统测试 混沌工程 目标 验证"代码是否正确" 验证"系统是否能承受故障" 环境 测试环境 生产环境（或接近生产的预发环境） 故障来源 预定义的测试用例 真实模拟的故障场景 发现时机 开发阶段 运行阶段 关注点 功能正确性 系统弹性 为什么要在生产环境做 混沌工程最反直觉的一点是"在生产环境注入故障"。为什么不 在测试环境做？ 测试环境无法复制生产的复杂性：生产环境的流量模式、数据量、网络拓扑、依赖关系与测试环境完全不同 测试环境的故障不会造成真实影响：没有压力，就不会暴露在压力下才出现的问题 只有在生产环境才能验证完整的恢复链路：告警是否触发？On-Call 是否响应？自动恢复是否生效？ 当然，直接在生产环境做混沌实验需要严格的控制——这正是"爆炸半径控制"要解决的问题。 混沌工程的四条原则 根据 Principles of Chaos Engineering，混沌工程遵循以下原则： 围绕稳态行为定义"正常"：先定义系统的正常状态（SLI/SLO），再注入故障看是否偏离 假设稳态在对照组和实验组中都保持：一部分流量/节点不注入故障（对照组），一部分注入（实验组），对比差异 在真实环境中实验：生产环境或接近生产的环境 自动化持续运行：不是一次性实验，而是持续自动化运行 混沌工程的收益 chaos_engineering_benefits: direct_benefits: - "提前发现系统弱点和单点故障" - "验证告警和恢复机制是否有效" - "提升团队对故障的响应能力" - "验证架构设计假设是否成立" indirect_benefits: - "建立团队对系统弹性的信心" - "驱动架构改进（从'看起来能扛'到'验证过能扛'）" - "减少真实故障的 MTTR（因为已经演练过类似场景）" - "培养'故障不可避免'的工程文化" 二、从 Chaos Monkey 说起 Netflix 的混沌工程演进 Netflix 是混沌工程的开创者，其演进路径值得参考：...

概述 在现代微服务架构中，一个看似简单的用户请求可能穿越数十个服务节点。当故障发生时，SRE 工程师面对的第一个问题往往不是"怎么修"，而是"影响范围有多大"。如果无法快速回答这个问题，故障恢复就会被拖延在无休止的排查中。 服务依赖地图（Service Dependency Map）和故障域分析（Failure Domain Analysis）是解决这一问题的工程方法论。前者解决"谁依赖谁、怎么依赖"的认知问题，后者解决"故障会扩散到哪、爆炸半径多大"的控制问题。两者结合，构成了 SRE 可靠性工程的基础设施。 从依赖拓扑的发现方法出发，深入分析故障域的识别与隔离策略，最后给出爆炸半径控制的工程实践方案。 服务依赖的复杂性本质 微服务架构下的依赖特征 单体应用时代的依赖关系是显式的、编译期的——通过 import 语句和函数调用就能完整描绘依赖图。微服务架构彻底改变了这一范式： 维度 单体应用 微服务架构 依赖发现方式 代码静态分析 运行时流量观测 依赖类型 函数调用 HTTP/gRPC/消息队列/事件总线 依赖稳定性 编译期确定 运行时动态变化 依赖可见性 IDE 可直接跳转 需要专门工具发现 故障传播路径 进程内异常栈 跨网络级联故障 依赖数量级 几十到几百 几百到几千 依赖关系的分类体系 并非所有依赖都具有相同的风险等级。一个成熟的依赖地图必须对依赖关系进行分类标注： 按调用方式分类： 同步调用：HTTP REST、gRPC、数据库查询。调用方阻塞等待响应，是级联故障的主要传播路径。 异步调用：消息队列（Kafka、RabbitMQ）、事件总线。调用方不阻塞，但消费端故障可能导致消息积压。 共享资源依赖：共用数据库、缓存集群、存储卷。资源竞争可能引发间接故障。 基础设施依赖：DNS、服务发现、配置中心。这类依赖故障影响面极广，属于关键路径。 按关键性分类： 强依赖：被依赖方不可用时，调用方无法完成核心功能。例如订单服务依赖库存服务。 弱依赖：被依赖方不可用时，调用方可降级运行。例如商品详情页依赖推荐服务。 条件依赖：在特定场景下才触发的依赖。例如促销活动期间才调用的优惠券服务。 # 依赖分类标注示例 class DependencyType: SYNC_HTTP = "sync_http" SYNC_GRPC = "sync_grpc" ASYNC_MQ = "async_mq" SHARED_DB = "shared_db" SHARED_CACHE = "shared_cache" INFRA_DNS = "infra_dns" INFRA_SERVICE_DISCOVERY = "infra_sd" class DependencyCriticality: STRONG = "strong" # 不可降级 WEAK = "weak" # 可降级 CONDITIONAL = "conditional" # 条件触发 # 依赖关系数据结构 class ServiceDependency: def __init__(self, caller, callee, dep_type, criticality): self....

概述 每一个故障都是一次免费的学习机会——前提是你有机制从中提取经验。Postmortem（事后复盘）不是写检讨书，不是找替罪羊，而是一套结构化的工程方法，用于把故障中的经验转化为系统性的改进。 Google SRE 的核心信条之一是：“Blameless postmortem”——无指责复盘。复盘的焦点永远是"系统为什么失败了"而非"谁搞砸了"。这不是温情主义，而是工程理性：如果人们在复盘时感到威胁，他们就会隐藏信息，而你将永远无法看到故障的真正根因。 从复盘文化的意义、blameless 原则、根因分析方法、复盘模板、改进项跟踪到组织文化障碍，详细梳理如何把 Postmortem 从"走流程"变成"真学习"。 关于 Postmortem 文化的系统方法论，可参考 Google SRE Book - Postmortem Culture 和 Google SRE Workbook - Postmortem。 一、为什么需要 Postmortem 文化 故障不可避免的工程现实 分布式系统的故障不是"如果"的问题，而是"何时"的问题。一个典型的微服务架构可能有上百个服务节点、数十个依赖系统、跨多个可用区部署，组合复杂度呈指数级增长。在这个复杂度下，以下场景几乎必然发生： 网络分区导致服务间调用超时 配置变更引发级联故障 依赖的第三方 API 限流或不可用 数据库连接池耗尽 某次发布引入了边界条件的 bug 问题不在于故障是否发生，而在于：同一个故障是否会重复发生。 不做复盘的代价 没有 Postmortem 文化的团队，通常会陷入以下循环： 故障发生 → 紧急修复 → 松一口气 → 不了了之 → 类似故障再次发生 这个循环的代价远比你想象的大： 维度 代价 重复故障 同类根因未消除，故障反复发生，MTBF 无法提升 知识断层 关键排查经验留在个人脑中，人员流动后经验丢失 信任消耗 团队反复犯类似错误，管理层和用户信任持续下降 个人压力 无制度保障，值班人员独自承担心理压力，加速 burnout 改进无追踪 修复措施停留在口头和聊天记录中，无跟踪无验收 做 Postmortem 的工程价值 一个成熟的 Postmortem 体系能带来三个层面的价值：...

概述 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 区别于传统运维的核心。