文章

概述 在自动化运维中，Ansible Playbook 经常需要处理数据库密码、API 密钥、SSH 私钥等敏感信息。如果这些数据以明文形式存储在代码仓库中，一旦仓库泄露，所有凭据都将暴露。Ansible Vault 作为 Ansible 内置的加密工具，通过 AES-256 对称加密算法保护敏感数据，确保只有授权用户才能访问。 我将从基础概念到生产实践，详细梳理 Ansible Vault 的使用方法、密码管理策略，以及在 CI/CD 流水线中的集成方案。 为什么需要 Ansible Vault 明文存储的风险 在实际运维中，敏感信息散落在多个位置： 位置 常见敏感数据 风险等级 group_vars/all.yml 数据库密码、Redis 密码 高 host_vars/web01.yml SSH 连接密码、BECOME 密码 高 Inventory 文件 ansible_password、ansible_ssh_pass 高 Playbook 变量 API Token、第三方密钥 中 Jinja2 模板 证书私钥、JWT Secret 高 明文存储的风险包括： 代码仓库泄露：Git 历史记录中永远保留明文密码，即使后续删除也能从历史中恢复 合规审计失败：PCI-DSS、ISO 27001 等安全标准要求敏感数据加密存储 团队协作风险：任何有仓库访问权限的人都能看到所有密码 日志泄露：Ansible 执行日志可能输出变量值，导致密码出现在日志文件中 Ansible Vault 的定位 Ansible Vault 不是唯一的密钥管理方案，但它是 Ansible 生态中最直接的选择： 方案 优点 缺点 适用场景 Ansible Vault 内置、零依赖、YAML 原生 单密码加密、无细粒度权限 中小规模团队、快速上手 HashiCorp Vault 动态密钥、租约管理、审计日志 需要额外部署和维护 大型企业、高安全要求 AWS Secrets Manager 云原生、自动轮转 厂商锁定、按量计费 AWS 云环境 SOPS + age 支持多密钥加密、Git 友好 需要额外工具 多人协作、GitOps 场景 参考 Ansible Vault 官方文档 了解完整功能列表。...

概述 性能问题几乎是每个 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 有一句名言：“系统一定会出故障，区别在于你是被它叫醒的还是主动管理它的。” 事件管理不是"出了事再处理"，而是一套从预防、检测、响应到学习的完整工程体系。 从事件分级、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....