1. 课程导论：什么是 Runbook、为什么需要 Runbook 自动化、Prometheus 与 CI/CD 的联动价值
1.1 什么是 Runbook？
Runbook（运维手册）是一套标准化的操作流程文档，用于指导运维或开发人员处理特定系统事件、故障或例行任务。传统 Runbook 以静态 Wiki 或 PDF 形式存在，依赖人工阅读、判断和执行。
| 维度 | 传统 Runbook | 自动化 Runbook |
|---|---|---|
| 载体 | Wiki、PDF、Confluence 页面 | 代码、Pipeline、可执行剧本 |
| 触发方式 | 人工收到告警后手动查阅 | 告警事件自动触发执行 |
| 执行效率 | 分钟级～小时级（依赖人员技能） | 秒级～分钟级（机器执行） |
| 可审计性 | 低（操作记录靠人工填写） | 高（全流程日志、版本控制） |
| 维护成本 | 高（文档易过时、无人更新） | 低（代码即文档，随代码库迭代） |
核心认知： Runbook 的本质是将“专家经验”转化为“可重复执行的步骤”。自动化 Runbook 进一步将这些步骤编码为可被机器调用的指令集，消除人为操作的不确定性。
1.2 为什么需要 Runbook 自动化？
现代微服务架构和 Kubernetes 环境带来两大挑战：告警风暴与操作复杂度。一个中等规模的集群每天可能产生数千条告警，完全依赖人工处理既不现实也不安全。
- 缩短 MTTR（平均修复时间）： 自动化 Runbook 可在告警触发后立即执行诊断、隔离、恢复操作，将 MTTR 从小时级压缩到分钟级。
- 消除人为失误： 疲劳、压力下的误操作是故障扩大的首要原因。自动化执行确保每次操作一致、可回滚。
- 释放人力： 将重复性操作（如重启服务、清理磁盘、扩容副本）交给机器，SRE 专注于架构优化和复杂故障根因分析。
- 合规与审计： 自动化 Runbook 的执行记录天然形成审计日志，满足 SOC2、ISO27001 等合规要求。
常见误区： 不要试图将所有操作都自动化。对于需要人工判断、跨团队协调或涉及数据变更的操作，保留半自动化模式（人工审批 + 自动执行）更安全。
1.3 Prometheus 与 CI/CD 的联动价值
Prometheus 是云原生监控的事实标准，CI/CD 是持续交付的核心引擎。两者联动后，监控数据不再只是“看板上的数字”，而是成为驱动自动化运维决策的信号源。
1.4 典型联动场景速览
| 场景 | Prometheus 告警 | Runbook 动作 | CI/CD 操作 |
|---|---|---|---|
| 磁盘空间不足 | node_filesystem_avail_bytes < 10% | 触发磁盘清理脚本 | 执行清理 Job，完成后更新指标 |
| 服务高延迟 | http_request_duration_seconds > 2s | 调用扩容 Pipeline | K8s HPA 调整副本数，或滚动更新 |
| 证书即将过期 | certificate_expiry_days < 7 | 触发证书续签流程 | 执行 cert-manager 或 Let's Encrypt 自动续签 |
| 错误率飙升 | error_ratio > 5% | 触发回滚决策 | GitOps 回退到上一个稳定版本 |
课程目标： 在本课程中，你将学会如何设计、编码、测试和部署一套完整的 Prometheus + Runbook + CI/CD 联动体系。从 Alertmanager Webhook 接收告警，到编写可执行的 Runbook 脚本，再到集成到 GitLab CI / GitHub Actions / Argo Workflows 等流水线中，最终实现“告警即触发，触发即修复”的自动化运维闭环。