SRE 实战手册(零)|从零搭建 SRE 实验台(保姆级实操) 📅 2026/7/17 2:26:30 SRE 实战手册零从零搭建 SRE 实验台保姆级实操配套《SRE 实战手册》系列见README.md。本篇把 8 篇博客里讲原理的部分落成一步一步能复现的实操手册。读完你将在4 台普通 ECS上拥有一套能演示SLI/SLO → 错误预算 → On-Call → 故障恢复 → 复盘完整闭环的 SRE 实验台。所有代码在本仓库deploy/下生产级 Prometheus/Grafana 配置也已备好。一、我们要建什么┌─────────────────────────────────────────────┐ │ ecs-584a-0001 (监控控制面) │ │ sre_monitor:9090 ──抓取──► 4 节点 /metrics │ │ incident_console:9099 ◄── webhook 告警 │ └─────────────────────────────────────────────┘ │ 私网 192.168.0.0/24 ┌───────────┼───────────────┬───────────────┐ 0002:8080 0003:8080 0004:8080 (0001 自己也跑一份) 悦购 Demo 悦购 Demo 悦购 Demo4 台 8C16G ECSUbuntu 24.04同 VPC私网互通省公网带宽。每台跑一个零依赖的悦购电商Demo在/metrics暴露 RED 指标。监控面用sre_monitor.py零依赖5Mbit 也能秒级跑想用真 Prometheus 也行配置已给。二、准备环境开 4 台 ECS同可用区、同 VPC建议 8C16G 起。记下每台公网 IPSSH 用和私网 IP监控抓取用。安全组放行监控面节点需放行9090 / 9099入站你本地浏览器看仪表盘/告警台用业务节点放行8080。本地准备一个能 SSH 批量执行的工具本仓库的ssh_helper.py是范例已把节点信息与凭据外置公开仓库里已剔除该文件请自行补全或用手动ssh。三、分发代码到各节点把deploy/下这些文件传到每台机器的/opt/sre-lab/demo_app.py sre_monitor.py incident_console.py error_budget.py deploy.sh fault.sh prometheus.yml alertmanager.yml slo_rules.yml # 生产参考可选提示sre_monitor.py是实验台实际运行的监控器prometheus.yml等三份是生产级等价配置带宽够时USE_PROM1启用。四、部署监控控制面0001# 在监控节点执行mkdir-p/opt/sre-lab# 先把上面文件放进去bash/opt/sre-lab/deploy.sh monitor ecs-584a-0001deploy.sh monitor会启动incident_console.py→ On-Call 告警台:9099收 Alertmanager 形状 webhooksre_monitor.py→ 轻量监控器:9090抓 4 节点、算错误率/燃烧速率、越阈值就 webhook 告警本机一份demo_app.py:8080看到sre_monitor :9090 - 200、incident_console :9099 - 200、demo :8080 - 200即成功。五、部署业务节点0002/0003/0004# 在每个业务节点执行NODE 名换成对应节点bash/opt/sre-lab/deploy.sh app ecs-584a-0002bash/opt/sre-lab/deploy.sh app ecs-584a-0003bash/opt/sre-lab/deploy.sh app ecs-584a-0004六、验证 SLO / 错误预算等 1~2 分钟让监控窗口积累样本看实时状态curl-shttp://127.0.0.1:9090/status# 健康基线应类似error_rate≈0.02%, burn_rate≈0.2×无告警纯数学算预算无需监控组件python3 /opt/sre-lab/error_budget.py math--total1000000--errors600--slo0.999# 错误率 0.06%燃烧速率 0.6×预算剩余 40%SLO 定义回顾结账成功率 ≥ 99.9%30 天窗口错误预算率 0.1%快燃阈值 14.4×、慢燃 6×。七、故障演练注入 → 发现 → 恢复 → 复盘1) 注入故障模拟 30% 结账失败fornin0002 0003 0004;dossh$nbash /opt/sre-lab/fault.sh inject 0.3;done2) 发现On-Call约 1 分钟内sre_monitor算出燃烧速率越过 14.4×CheckoutBudgetBurnFast触发critical 寻呼打开http://0001公网IP:9099/→ 看到活跃 critical 告警与起始时间/opt/sre-lab/incidents.log记录[PAGE][critical] ... 燃烧速率 18.5×实测数据健康基线 error_rate≈0.02%/burn≈0.2× → 注入后冲到 error_rate≈14%/burn≈140× → 22:38:19 critical 寻呼。3) 恢复恢复业务优先不查根因fornin0001 0002 0003 0004;dossh$nbash /opt/sre-lab/fault.sh recover;done约 3 分钟监控窗口滚动后告警自动 resolved控制台回到无活跃告警。4) 复盘套用docs/incident-postmortem-template.md黄金三问发生了什么 / 为什么 / 学到什么 可验证行动项。八、生产化可选但强烈建议实验台为教学最小集生产落地三件事1) 用真 Prometheus Grafanadeploy.sh monitor设USE_PROM1并备好二进制即启用见prometheus.yml/alertmanager.yml/slo_rules.yml。导入本仓库deploy/grafana-dashboard.json到 Grafana左侧Dashboards → New → Import → 上传 JSON数据源选你的 Prometheus。仪表盘含结账成功率(对照 99.9% 红线)、错误率、燃烧速率、QPS、各节点错误数、p99 延迟、节点存活。5Mbit 小带宽提醒Prometheus 二进制 ~110MB直连 GitHub 下载会极慢实测 2 分钟仅 2MB。用国内镜像或内网分发也因此本实验默认用sre_monitor.py代替。2) 进程托管改成 systemd把sre_monitor.py/incident_console.py/demo_app.py写成.service单元开机自启、崩溃重启比nohup循环更稳。3) On-Call 通道接真实通知incident_console.py的 webhook 入口可以对接企业微信/钉钉/电话如接入钉钉机器人或电话网关把模拟寻呼变成真寻呼。九、与博客系列对照你想深入的点看哪篇SRE 是什么、误区01可用性≠稳定性02选 SLI、定 SLO03错误预算机制04落地 SLO 的现实褶皱05On-Call 与恢复优先06复盘黄金三问07组织架构与协作08十、排错速查监控面端口不通检查 0001 安全组是否放行 9090/9099pgrep -af sre_monitor看进程在不在。错误率一直是 0Demo 没起来curl 127.0.0.1:8080/healthz应返回 200tail /opt/sre-lab/demo.log。注入后不告警窗口没攒够样本等 1~2 分钟确认fault.sh inject写到了/tmp/fault_ratefault.sh status查看。告警不解除监控窗口 120s 内含故障样本等窗口滚动约 2 分钟自然回落。本教程对应的全部代码与本文引用的配置文件均在仓库deploy/与docs/下并已推送到 GiteeLiaCin/sre-handbook。