概述 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....

概述 自动扩缩容是 Kubernetes 最吸引人的能力之一——流量来了自动扩容，流量走了自动缩容，既保证服务质量又控制成本。但"自动"不等于"无脑"，配置不当的扩缩容可能导致：扩容不及时造成服务降级、缩容太激进中断长连接、抖动扩缩导致资源浪费。 K8s 的自动扩缩容体系包含三个层次： 层次 组件 扩缩维度 触发条件 Pod 水平扩缩 HPA Pod 副本数 CPU/内存/自定义指标 Pod 垂直扩缩 VPA Pod 资源配额 CPU/内存历史用量 节点扩缩 Cluster Autoscaler 节点数 Pending Pod 事件驱动 KEDA Pod 副本数 事件源（Kafka/Redis/…） 本文基于 Kubernetes v1.30。参考 Kubernetes 自动扩缩文档 HPA：水平 Pod 自动扩缩容 工作原理 HPA（Horizontal Pod Autoscaler）是一个控制循环，默认每 15 秒执行一次： 1. 从指标 API 获取 Pod 的当前指标值（CPU/内存/自定义） 2. 计算期望副本数 = ceil(当前副本数 * (当前指标值 / 目标指标值)) 3. 与当前副本数比较，决定扩容或缩容 4. 调用 Deployment/ReplicaSet 的 Scale API 修改副本数 核心公式：...

概述 告警是监控系统的"最后一公里"，也是最难做好的一环。一个常见的困境是：服务器上跑着几十个告警规则，每天产生上百条告警通知，值班工程师在微信/钉钉/邮件的轮番轰炸下逐渐麻木——真正紧急的告警被淹没在噪声中，直到客户投诉才发现系统早已出问题。 SRE 的黄金法则是：每一条告警都应该有明确的处理动作。如果一个告警收到后既不需要立即处理，也不需要记录跟踪，那它就不应该存在。从告警疲劳问题出发，详细梳理告警分级、SLO-based 告警设计、抑制与聚合策略、告警度量指标和治理方法，帮助你从"告警噪声"中提取出真正的"信号"。 参考来源：Google SRE Book《Monitoring Distributed Systems》、Prometheus 告警好的实践 一、告警疲劳：问题的根源 1.1 告警泛滥的典型表现 某团队告警统计（一周）： ┌──────────────────────────┬────────┬──────────┐ │ 告警类型 │ 数量 │ 实际处理 │ ├──────────────────────────┼────────┼──────────┤ │ CPU 使用率 > 80% │ 156 │ 3 │ │ 磁盘使用率 > 70% │ 89 │ 2 │ │ Pod 重启 │ 34 │ 5 │ │ HTTP 5xx 错误率 > 1% │ 12 │ 4 │ │ 数据库连接数 > 80% │ 8 │ 1 │ │ 证书即将过期 │ 3 │ 1 │ │ 服务不可达 │ 2 │ 2 │ ├──────────────────────────┼────────┼──────────┤ │ 总计 │ 304 │ 18 │ └──────────────────────────┴────────┴──────────┘ 有效告警率：18/304 = 5....

概述 Pipeline as Code 是 Jenkins 从"拖拽式配置"走向"代码化"的分水岭。把流水线定义写在 Jenkinsfile 中，纳入 Git 版本控制，意味着每次流水线变更都有 diff 可审查、有历史可追溯、有分支可回滚。从 Jenkinsfile 语法到生产级流水线设计，详细梳理 Pipeline as Code 的核心实践。 参考来源：Jenkins Pipeline 官方文档 一、Jenkinsfile 语法 1.1 声明式 vs 脚本式 Jenkins Pipeline 有两种语法风格： 维度 声明式（Declarative） 脚本式（Scripted） 语法 结构化 DSL Groovy 代码 可读性 高，接近配置文件 低，需要 Groovy 知识 灵活性 受限于 DSL 约束 完全自由 输入验证 内置 post、when 等结构 需手动实现 推荐场景 标准流水线、团队协作 复杂逻辑、条件分支多 // === 声明式 Pipeline === pipeline { agent any stages { stage('Build') { steps { sh 'make build' } } } } // === 脚本式 Pipeline === node { stage('Build') { sh 'make build' } } 实践建议：优先用声明式，仅在声明式无法表达的复杂逻辑处用 script {} 块嵌入脚本式代码。...

概述 Google SRE Book 中有一条经常被引用的原则：SRE 团队的琐事工作不应超过总工作时间的 50%。这条原则看似简单，但在实践中，很多 SRE 团队的琐事比例远超 50%——有的甚至达到 80% 以上。 为什么 SRE 要如此认真地对待"琐事"？因为琐事是可靠性的隐形杀手： 琐事占用大量时间，让工程师没有精力做真正提升可靠性的事 琐事通常是手工操作，容易出错，反而引入新的故障 琐事导致 burnout，优秀工程师流失 琐事无法规模化——系统增长 10 倍，琐事也增长 10 倍 从 toil 的定义与判定、琐事来源分析、自动化消除路径、50% 上限原则、度量与追踪方法到团队实践，详细梳理如何治理事务性工作。 关于 toil 的系统论述，可参考 Google SRE Book - Eliminating Toil。 一、Toil 的定义与判定 什么是 Toil Google SRE 对 toil 的定义是： 与运行生产服务相关的、手动的、重复的、可自动化的、战术性的、无持久价值的、与服务规模成正比增长的工作。 这个定义包含六个关键特征，缺一不可： 特征 含义 示例 手动的 需要人工操作而非自动执行 手动扩容、手动清理日志 重复的 不是一次性的，会反复出现 每次发布都需要手动修改配置 可自动化的 有明确的规则和步骤，机器能做 手动检查磁盘空间并清理 战术性的 被动响应而非主动规划 救火式处理告警 无持久价值的 做完之后没有产生可复用的产出 手动重启服务（没有改进自愈机制） 与规模成正比 系统增长，工作量同步增长 每增加一台服务器就需要手动配置一次 什么不是 Toil 识别 toil 的同时，也要识别什么不是 toil，避免把有价值的工作误判为琐事：...

概述 在云原生和容器化技术全面普及的今天，Linux cgroup（控制组）作为资源隔离和限制的内核基石，其重要性不言而喻。从 Docker 容器的内存限制到 Kubernetes Pod 的 CPU Requests/Limits，底层都依赖 cgroup 机制。然而，cgroup v1 的多层级架构、控制器行为不一致、线程模型混乱等历史包袱，让运维人员在生产环境中频频踩坑。 cgroup v2 作为对 v1 的彻底重构，采用单一层级树（unified hierarchy）架构，从根本上解决了 v1 的设计缺陷。自 Linux 4.5 引入以来，经过多个内核版本的迭代完善，cgroup v2 在 5.x 内核上已趋于成熟稳定。Ubuntu 22.04+、RHEL 9+、Debian 12+ 等主流发行版已默认使用 cgroup v2，Docker 和 Kubernetes 也已全面支持。 我将从 cgroup v2 的架构原理出发，深入讲解核心控制器的工作机制，结合 systemd 集成、Docker 容器限制、Kubernetes 场景等实战配置，最后覆盖 v1 到 v2 的迁移策略，帮助你在生产环境中驾驭这一关键技术。 cgroup v1 vs v2：为什么要重构 v1 的核心痛点 cgroup v1 在设计之初，每个控制器可以独立挂载在不同的层级树上。这带来了灵活性，但也埋下了大量隐患： 问题维度 v1 表现 影响 多层级架构 每个控制器可挂载在独立的层级树 进程在不同控制器中可属于不同 cgroup，管理视图割裂 线程模型 进程的线程可分散到不同 cgroup 资源计量混乱，难以准确归因 控制器间协调 各控制器独立运作 无法做跨资源的统一策略（如 CPU 和内存的联动） 委派安全 子 cgroup 委派权限粗粒度 容器逃逸风险，安全边界模糊 接口一致性 不同控制器文件命名和语义不统一 运维认知负担高，脚本维护困难 v2 的设计哲学 cgroup v2 的核心设计原则是单一层级树（unified hierarchy）：整个系统只有一棵 cgroup 树，所有控制器挂载在同一棵树上。一个进程只属于一个 cgroup，该 cgroup 上可以同时启用 CPU、内存、IO 等多个控制器。...

概述 Kubernetes Operator 是将人类运维知识编码为软件的范式。它通过 CRD（Custom Resource Definition）扩展 K8s API，通过 Controller 实现自动化运维逻辑。数据库集群管理、消息队列运维、证书轮转……这些原本需要 SRE 手动操作的工作，Operator 可以自动完成。 Operator 的核心思想是声明式 + 控制循环：用户声明期望状态（如"3 个 Redis 副本"），Controller 持续调整实际状态以趋近期望状态。理解这一模式，不仅能开发 Operator，更能深入理解 K8s 本身的设计哲学。 本文基于 Kubernetes v1.30、operator-sdk v1.37、kubebuilder v4.0。参考 Operator 模式文档 Operator 核心概念 CRD 与 Controller 的关系 用户创建 CR (Custom Resource) ──→ API Server 存储 ──→ Controller Watch ↓ Reconcile 循环 ↓ 比较期望状态 vs 实际状态 ↓ 创建/更新/删除资源 ↓ 更新 CR Status 声明式 vs 命令式 模式 示例 特点 命令式 “创建 3 个 Pod” 执行一次就结束，不关心后续状态 声明式 “保持 3 个 Pod 运行” 持续监控，自动修复偏差 Operator 是声明式的——用户声明 spec....

概述 Prometheus 默认是单节点架构，这在生产环境中是一个危险的隐患。一个 Prometheus 实例挂掉意味着整个监控体系失明——你无法在故障期间看到任何指标，告警也会因为规则不评估而完全失效。当数据量增长到单机存储和处理能力的极限时，还会面临写入超时、查询缓慢、磁盘爆满等问题。 本文系统性地分析 Prometheus 高可用和水平扩展方案，从最简单的双副本到 Thanos、Mimir、VictoriaMetrics、Cortex 等远程存储方案，帮助你根据实际场景做出正确的技术选型。 参考来源：Prometheus 官方文档 — HA、Thanos 官方文档 一、单点问题分析 1.1 单点 Prometheus 的风险 ┌──────────────┐ ┌───────────────┐ ┌──────────┐ │ Exporters │ ──→ │ Prometheus │ ──→ │ Grafana │ │ (targets) │ │ (单节点) │ │ Alertmgr│ └──────────────┘ └───────────────┘ └──────────┘ │ ┌──────┴──────┐ │ 本地 TSDB │ │ (15-30 天) │ └─────────────┘ 这个架构的脆弱点： 风险点 影响 发生概率 Prometheus 进程崩溃 监控完全中断，告警失效 中 宿主机宕机 同上，且可能丢失最近数据 中 磁盘故障 历史数据丢失 低-中 磁盘空间耗尽 写入失败，数据丢失 中-高 单机内存/CPU 不足 写入延迟、查询超时 高（数据量增长后） 网络分区 部分 target 无法采集 中 1....

GitOps 核心原则 GitOps 是一种现代化的持续交付方法论，由 Weaveworks 在 2017 年提出。它将 Git 作为基础设施和应用配置的唯一可信源（Single Source of Truth），通过声明式方式实现持续部署。 根据 ArgoCD 官方文档，GitOps 遵循四大核心原则： 1. 声明式系统 基础设施和应用配置以声明式描述（YAML/Helm/Kustomize）存储在 Git 中： # Git 仓库结构示例 infra-repo/ ├── apps/ │ ├── frontend/ │ │ ├── deployment.yaml │ │ ├── service.yaml │ │ └── configmap.yaml │ └── backend/ │ ├── deployment.yaml │ └── service.yaml ├── helm/ │ └── values-production.yaml └── kustomize/ ├── base/ └── overlays/ ├── staging/ └── production/ 声明式描述的核心价值：配置即文档，Git 历史即审计日志。任何环境变更都可追溯、可回滚。 2. 版本控制 所有变更通过 Git 提交记录，天然具备：...

概述 容量规划是 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% 以下。...