SRE实践

概述 SRE 有一句名言：“系统一定会出故障，区别在于你是被它叫醒的还是主动管理它的。” 事件管理不是"出了事再处理"，而是一套从预防、检测、响应到学习的完整工程体系。 从事件分级、On-Call 轮值、事故响应流程、Postmortem 文化、告警治理五个方面，详细梳理如何构建一个可落地的 On-Call 体系。 关于事件管理的系统方法论，可参考 Google SRE Book - Managing Incidents 和 Google SRE Book - Postmortem Culture。 一、事件分级标准 没有分级的事件管理等于没有管理——所有事件都按紧急处理，结果就是没有真正的紧急。合理的事件分级是 On-Call 体系的基石。 P0-P4 事件定义 级别 定义 影响范围 响应时效 示例 P0 生产服务完全不可用 全量用户受影响 立即响应，<5min 核心服务宕机、数据库不可用 P1 核心功能严重降级 大量用户受影响 <15min 支付失败率飙升、API 错误率 >10% P2 部分功能降级 部分用户受影响 <30min 某区域延迟劣化、非核心服务异常 P3 潜在风险 暂无直接影响 <2h（工作时间） 磁盘水位 >80%、单节点故障 P4 优化建议 无影响 下一工作日 告警阈值优化、文档补充 分级原则 分级的本质是资源调度优先级——让有限的人力优先处理影响最大的问题： 以用户影响为准，而非技术指标：CPU 99% 是 P3，但如果导致用户请求超时就是 P1 明确定义，避免模糊：“大量用户"是 30% 还是 50%？需要量化 可自动判定：理想状态下，事件级别应该能通过告警规则自动确定 # 告警分级规则示例 groups: - name: incident-grading rules: # P0: 核心服务完全不可用 - alert: P0ServiceDown expr: up{job="critical-service"} == 0 for: 1m labels: severity: P0 page: true # 触发电话告警 escalation: true # 自动升级到主管 annotations: summary: "核心服务不可用" runbook: "https://wiki/incident/p0-service-down" # P1: 错误率超过 SLO - alert: P1HighErrorRate expr: | sum(rate(http_requests_total{status=~"5....

概述 容量规划是 SRE 的核心职责之一。Google SRE Book 将容量规划视为"前瞻性工作"，强调基于数据预测而非凭经验猜测。一个没有容量规划的团队，要么在高峰期被流量打垮，要么在低谷期浪费大量资源成本。 从指标采集、数据建模、Kubernetes 弹性扩容配置、陷阱规避四个层面，详细梳理容量规划的工程实践。 关于容量规划的系统方法论，可参考 Google SRE Book - Capacity Planning 中关于容量规划与级联故障的讨论。 一、容量规划的核心思想：基于数据而非猜测 容量规划的三个层次 当前容量评估：系统现在能扛多少？水位是多少？ 容量趋势预测：按当前增长趋势，什么时候需要扩容？ 弹性伸缩策略：面对突发流量，如何自动应对？ 容量规划的前提：可观测性 没有度量就没有管理。容量规划的基础是完善的监控体系，需要持续采集以下指标： 指标类别 具体指标 采集工具 CPU 使用率、负载（1m/5m/15m） node_exporter / cAdvisor 内存 使用量、可用量、OOM 次数 node_exporter / cAdvisor 网络 入站/出站带宽、连接数、丢包率 node_exporter 磁盘 I/O IOPS、读写延迟、队列深度 node_exporter 应用层 QPS、延迟分布、错误率 Prometheus / 自定义指标 中间件 连接池使用率、队列长度、缓存命中率 Exporter / 自定义指标 容量水位定义 不是所有指标都同等重要。需要定义关键资源的容量水位： # 容量水位定义示例 capacity_thresholds: cpu: warning: 60% # 60% 开始关注 critical: 80% # 80% 需要扩容 limit: 90% # 90% 紧急扩容 memory: warning: 70% critical: 85% limit: 95% disk_io: warning: 60% critical: 80% limit: 90% connection: warning: 60% # 连接池使用率 critical: 80% limit: 90% 关键原则：水位线不是拍脑袋定的，而是基于压测数据和历史故障分析得出的。如果你的应用在 CPU 85% 时开始出现延迟劣化，那么 warning 就应该设在 70% 以下。...