claude-skills 的 SRE Engineer从 SLO/SLI 定义到混沌实验的站点可靠性工程实战【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills本文基于开源仓库 claude-skills 中的sre-engineer专项 Skill系统讲解一套可直接落地的站点可靠性工程SRE方法论从可用性/延迟 SLI 的量化定义、99.9% SLO 的错误预算与燃烧速率burn rate计算到 Prometheus 多窗口告警、Golden Signals 监控面板、Toil 自动化削减再到无指责事后分析blameless postmortem与受安全约束的混沌工程实验。读完本文你将掌握一套开箱即用的 SRE 实践工具箱——包括可直接复制的 PromQL 查询、告警规则、Python 自动化脚本与事故响应流程模板。Skill 定位claude-skills 中的可靠性专家在 claude-skills 的 67 个专项 Skill 中sre-engineer归属于 devops 领域其 frontmatter见 skills/sre-engineer/SKILL.md明确规定了它的职责范围能力描述定义服务水平目标SLO、创建错误预算策略、设计事故响应流程、开发容量模型并为生产系统产出监控配置与自动化脚本。触发场景定义 SLI/SLO、管理错误预算、构建大规模可靠系统、事故管理、混沌工程、Toil 削减、容量规划。触发词triggersSRE、site reliability、SLO、SLI、error budget、incident management、chaos engineering、toil reduction、on-call、MTTR。角色与产出role: specialist专家角色、scope: implementation实施导向、output-format: code以代码为最终产出。关联 Skilldevops-engineer、cloud-architect、kubernetes-specialist同时被chaos-engineer见 skills/chaos-engineer/SKILL.md列为关联依赖——后者专注于混沌实验的设计与故障注入框架二者在韧性验证环节形成互补。从仓库的 SKILLS_GUIDE.md 对该 Skill 的描述Site reliability, incident response, SLO/SLA management及 CHANGELOG.md 中将其归入Operations (3)sre-engineer、chaos-engineer、cli-developer可以看出它是整个仓库在生产系统可靠性运营维度的核心能力模块。核心工作流从可靠性评估到韧性验证的六步循环该 Skill 定义了一条端到端的实施路径每一步都有明确的产出物评估可靠性Assess reliability——审查架构、既有 SLO、历史事故与 Toil 水平定义 SLODefine SLOs——识别有意义的 SLI 并设定合理目标值验证对齐Verify alignment——在继续之前确认 SLO 目标真实反映用户期望落地监控Implement monitoring——构建 Golden Signals 面板与告警自动化 ToilAutomate toil——识别重复性任务并构建自动化韧性测试Test resilience——设计并执行混沌实验在标记实验完成前验证恢复满足 RTO/RPO 目标并端到端验证恢复行为。注意第 6 步的强制性混沌实验不能跑完就结束必须验证恢复行为满足 RTO/RPO 目标后才算完成这与下文 chaos-engineer Skill 中自动回滚 ≤30 秒、闭环改进的安全清单一脉相承。SLO/SLI 管理可靠性的量化起点详细指导见 skills/sre-engineer/references/slo-sli-management.md。SLI服务级指标是对服务行为的量化测量SLO 则是对 SLI 设定的目标阈值。该参考文档给出了四类核心模式。请求型 SLI 与延迟型 SLI可用性 SLI的定义要点是好事件的选取HTTP 200-299 成功且 4XX 客户端错误不计入SLI 的失败因为这不是服务的问题。对应的计算函数def calculate_availability_sli(metrics): Calculate availability SLI from request metrics. successful_requests metrics[http_2xx] metrics[http_4xx] total_requests metrics[total_requests] if total_requests 0: return 1.0 # No traffic 100% available return successful_requests / total_requests延迟型 SLI基于直方图计算快于阈值的请求比例例如99% 的请求在 500ms 内完成def calculate_latency_sli(latency_histogram, threshold_ms500): Calculate latency SLI from histogram. fast_requests sum( count for bucket, count in latency_histogram.items() if bucket threshold_ms ) total_requests sum(latency_histogram.values()) return fast_requests / total_requests if total_requests 0 else 1.0SLO 配置文件参考文档提供了一个完整的 YAML 化 SLO 定义包含服务标识、SLI 查询与目标值# slo_config.yaml - Production API SLO definitions apiVersion: sre/v1 kind: ServiceLevelObjective metadata: service: payment-api environment: production spec: slos: - name: availability description: Users can successfully complete payment requests sli: metric: http_requests_total query: | sum(rate(http_requests_total{status~2..|4.., servicepayment-api}[30d])) / sum(rate(http_requests_total{servicepayment-api}[30d])) target: 0.999 # 99.9% window: 30d - name: latency description: Payment requests complete quickly sli: metric: http_request_duration_seconds query: | histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{servicepayment-api}[30d])) by (le) ) 0.5 target: 0.99 # 99% of requests under 500ms window: 30d注意这里与错误预算策略skills/sre-engineer/references/error-budget-policy.md中的payment-api示例是一致串联的同一个服务既定义 SLO也定义对应的预算消费动作。Golden Signals四个必须测量的黄金信号无论采用何种 SLI 组合每个服务都应监控四个黄金信号参考文档用dataclass建模了它们的组合健康判定dataclass class GoldenSignals: Four golden signals of monitoring. # Latency: Time to service requests (success vs failure) latency_p50_ms: float latency_p95_ms: float latency_p99_ms: float # Traffic: Demand on your system (requests/sec) requests_per_second: float # Errors: Rate of failed requests error_rate: float # 0.0 to 1.0 # Saturation: How full is your service (CPU, memory, disk) cpu_utilization: float # 0.0 to 1.0 memory_utilization: float # 0.0 to 1.0 def is_healthy(self, slo_targets): return ( self.latency_p99_ms slo_targets[latency_p99_ms] and self.error_rate (1 - slo_targets[availability]) and self.cpu_utilization slo_targets[max_cpu] and self.memory_utilization slo_targets[max_memory] )注意一个隐含关系error_rate (1 - availability)即错误率上限 错误预算比例错误预算与监控在这里首次交汇。错误预算与多窗口跟踪的计算模型参考文档给出了两个可直接运行的计算类。SLOTarget把99.9% × 30 天换算为可沟通的时间语言class SLOTarget(NamedTuple): target: float # 0.999 for 99.9% window: timedelta # 30 days property def error_budget(self) - float: return 1 - self.target property def allowed_downtime(self) - timedelta: total_seconds self.window.total_seconds() allowed_seconds total_seconds * self.error_budget return timedelta(secondsallowed_seconds) # 输出Error budget: 0.1% / Allowed downtime: 43.2 minutes per 30 daysMultiWindowSLO则用 1h / 24h / 7d / 30d 四个窗口同时检查合规性并计算燃烧速率burn rate——它衡量的是当前错误率相对于可持续错误率的倍数1.0 即意味着预算消耗速度快于可持续水平class MultiWindowSLO: def __init__(self, target: float): self.target target self.windows { 1h: timedelta(hours1), 24h: timedelta(hours24), 7d: timedelta(days7), 30d: timedelta(days30), } def get_burn_rate(self, current_sli: float) - float: error_budget 1 - self.target current_error_rate 1 - current_sli if error_budget 0: return float(inf) return current_error_rate / error_budget典型 SLO 目标与服务分级参考文档按服务层级给出了常见基准按 30 天窗口换算的月停机时间层级可用性月停机时间P99 延迟Tier 1 关键99.99%4 分 23 秒/月100msTier 2 重要99.9%43 分 28 秒/月500msTier 3 标准99.5%3 小时 37 分/月1000msSLO 评审清单在最终确定 SLO 前逐条核对是否以用户为中心衡量用户可感知的影响、基于当前架构是否可达、SLI 能否被准确追踪、违反时是否必须触发行动、计算口径是否清晰并被各方认可、是否存在配套的错误预算策略。错误预算策略把可靠性变成可消费的货币详细指导见 skills/sre-engineer/references/error-budget-policy.md。错误预算 1 - SLO 目标它代表了可接受的不可靠性是连接可靠性与迭代速度的桥梁。预算健康状态机参考文档用BudgetStatus枚举定义了四个健康档位剩余 75% 为HEALTHY、25%-75% 为WARNING、25% 为CRITICAL、0% 为EXHAUSTED。核心计算类ErrorBudget同时给出预算百分比、允许停机时长与剩余预算比例class ErrorBudget: def remaining_budget(self, actual_sli: float) - float: budget_used 1 - actual_sli total_budget 1 - self.slo_target if total_budget 0: return 0.0 return max(0.0, 1 - (budget_used / total_budget)) def get_status(self, actual_sli: float) - BudgetStatus: remaining self.remaining_budget(actual_sli) if remaining 0: return BudgetStatus.EXHAUSTED elif remaining 0.25: return BudgetStatus.CRITICAL elif remaining 0.75: return BudgetStatus.WARNING else: return BudgetStatus.HEALTHY多窗口燃烧速率告警Google SRE Workbook 模式燃烧速率 当前错误率 / 总错误预算。参考文档内置了业界经典的三个告警窗口配置告警名时间窗口燃烧速率阈值预算消耗含义Fast burn1 小时14.4x2%2 天内耗尽 30 天预算Medium burn6 小时6.0x5%—Slow burn3 天1.0x10%以可持续速率持续消耗对应的判定函数def check_burn_rate_alerts(slo_target: float, current_sli: float): error_budget 1 - slo_target error_rate 1 - current_sli alerts [] for alert_config in BURN_RATE_ALERTS: if alert_config.should_alert(error_rate, error_budget): alerts.append(alert_config) return alerts错误预算策略模板参考文档提供了可直接落地的策略模板error_budget_policy.yaml按剩余预算阈值定义操作状态100%normal_operations正常迭代可在业务时间部署走标准变更评审50%careful_operations加强代码评审、部署需资深工程师审批、部署前做风险评估25%restricted_operations停止非关键功能开发、聚焦可靠性改进、部署需 VP 审批、每日预算复盘0%feature_freeze立即功能冻结、仅允许紧急修复、全员可靠性复盘、所有事故强制 postmortem、每周高管评审直到恢复。同时内置例外规则安全补丁由安全团队批准即可放行关键业务需求需 VP 工程 产品负责人联合批准且必须附带复审。部署决策框架当预算健康与业务诉求冲突时参考文档给出了确定性的should_deploy决策函数预算耗尽时仅允许关键业务变更预算 25% 时高风险变更一律拒绝高优先级业务可谨慎放行预算 25%-75% 时低优先级高风险变更被拒绝其余进入增强评审预算 75% 时正常放行。配套的 Prometheus 查询可以直接复用于监控看板30 天可用性 SLI、错误预算消耗量、剩余预算比例针对 99.9% SLO 用0.001作分母归一化以及归一化到1.0 可持续的燃烧速率。监控与告警从 Golden Signals 到可行动的 Runbook详细指导见 skills/sre-engineer/references/monitoring-alerting.md。核心原则一句话好告警是可行动的而不只是知会的。Golden Signals 录制规则先用 Prometheus recording rules 把原始指标固化为可复用的信号配置在prometheus_rules.yamlgroups: - name: golden_signals interval: 30s rules: - record: service:http_request_duration_seconds:p50 expr: | histogram_quantile(0.50, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service) ) - record: service:http_requests:rate5m expr: | sum(rate(http_requests_total[5m])) by (service) - record: service:http_requests:error_rate5m expr: | sum(rate(http_requests_total{status~5..}[5m])) by (service) / sum(rate(http_requests_total[5m])) by (service) - record: service:memory_utilization expr: | avg(container_memory_working_set_bytes / container_spec_memory_limit_bytes) by (service)SLO 告警规则多窗口燃烧速率主文档 skills/sre-engineer/SKILL.md 给出了最核心的告警示例——Multiwindow Burn Rate告警。其设计思想是快烧窗口1h14.4x与慢烧窗口5m/6h 等同时满足才触发既保证快速感知又抑制瞬时抖动。快烧规则groups: - name: slo_availability rules: # Fast burn: 2% budget in 1h (14.4x burn rate) - alert: HighErrorBudgetBurn expr: | ( sum(rate(http_requests_total{status~5..}[1h])) / sum(rate(http_requests_total[1h])) ) 0.014400 and ( sum(rate(http_requests_total{status~5..}[5m])) / sum(rate(http_requests_total[5m])) ) 0.014400 for: 2m labels: severity: critical annotations: summary: High error budget burn rate detected慢烧规则1x 燃烧速率持续 6 小时15 分钟才确认用于捕捉温水煮青蛙式的持续劣化。每个告警都必须通过annotations链接到对应 runbook。告警 Runbook 模板参考文档强调每个告警必须关联含明确修复步骤的 runbook并给出了ErrorBudgetBurnRateFast的完整模板结构为描述 → 严重级 → 影响 → 分级排查步骤 → 修复手段 → 沟通模板 → 预防措施。其中分级排查与修复命令可以直接执行# 检查当前错误率PromQL rate(http_requests_total{status~5.., serviceapi}[5m]) # 查看最近部署 kubectl rollout history deployment/api # 若由近期部署引起回滚并验证 kubectl rollout undo deployment/api kubectl rollout status deployment/api # 若为流量尖峰扩容 启用限流 kubectl scale deployment/api --replicas10 kubectl apply -f rate-limit-config.yaml沟通环节还提供了 Slack 模板:fire: INCIDENT: Error budget burn rate critical 服务/错误率/影响/ETA/事故文档链接。SLO 监控面板参考文档用 Grafana Dashboard SDK 代码生成一个完整 SLO 面板grafana_dashboard.py包含四个面板30 天可用性 SLI 当前值阈值 0.999 红 / 0.9995 黄 / 1.0 绿、错误预算剩余百分比、1h 燃烧速率1.0 绿 / 6.0 黄 / 14.4 红、以及 Golden Signals 行P50/P95/P99 延迟。告警疲劳抑制参考文档提供了AlertQualityMetrics指标类precision可行动告警占比目标 90%与toil_ratio需要人工介入的告警占比目标 30%。配套的on_call_alert_standards.yaml明确区分值得寻呼page-worthy与不值得寻呼值得寻呼5% 用户受影响、SLO 违反进行中、燃烧速率 10x、安全事件、数据丢失风险不值得寻呼无当前影响的预测性告警、信息性指标、非用户侧问题、缓慢趋势工作时间再处理分级路由critical → 寻呼值班工程师 Slack#incidents 创建事故文档warning → 仅 Slack#alerts 持续 1h 自动建工单info → 仅面板展示。Toil 削减与自动化把重复劳动变成可度量、可消除的项详细指导见 skills/sre-engineer/references/automation-toil.md。Toil 的定义是手动的、重复的、可自动化的、且随服务增长线性扩展的工作。Toil 库存清单与自动化 ROI参考文档用ToilItem建模每一项 Toil周频率、单次分钟数、类别、自动化难度并给出自动化 ROI 评分年度小时数 × 难度系数easy1.0 / medium0.5 / hard0.25按 ROI 排序即可确定自动化优先级class ToilItem: property def weekly_hours(self) - float: return (self.frequency_per_week * self.minutes_per_occurrence) / 60 def roi_score(self) - float: difficulty_multiplier {easy: 1.0, medium: 0.5, hard: 0.25} return self.annual_hours * difficulty_multiplier.get(self.automation_difficulty, 0.1)自愈系统参考文档的SelfHealer实现了健康检查 自动修复 重试 升级的自愈框架注册HealthCheck检查函数 修复函数 最多 3 次重试失败时依次重试仍失败则升级到值班工程师。内置示例包括磁盘空间检查df -h解析 清理 7 天前日志与服务健康检查curl /healthsystemctl restart可作为 cron 或 systemd timer 运行。Runbook 自动化把人工 runbook 转化为AutomatedRunbook每个步骤由描述、命令、是否关键失败即停与可选验证命令组成支持dry_run模式先行演练。参考文档以 Postgres 数据库故障切换为完整示例——停止主库写入 → 等待复制延迟清除 → 提升副本为主库带pg_is_in_recovery()验证→ 更新 Service 指向新主库。容量规划自动化CapacityPlanner基于历史指标时间戳、RPS、CPU/内存利用率用np.polyfit线性回归预测未来 90 天资源使用超过 80% 利用率即给出SCALE UP建议。这直接呼应主文档 MUST NOT DO 中的Deploy without capacity planning。自动化测试与 Toil 削减度量自动化代码本身也必须被测试参考文档用unittestmock subprocess.run覆盖自愈脚本的成功路径与重试路径。同时用ToilTracker按周记录toil_hours / team_hours计算 Toil 百分比与趋势目标从 50% 逐步压到 30%。事故管理与混沌工程在可控范围内验证韧性详细指导见 skills/sre-engineer/references/incident-chaos.md。事故管理回答出事后怎么办混沌工程回答没出事时如何提前验证。事故响应框架Incident数据类记录了事故全生命周期并自动计算三个关键时长指标——detection time开始到发现、MTTR发现到恢复、total duration开始到恢复dataclass class Incident: id: str title: str severity: Severity started_at: datetime detected_at: datetime resolved_at: datetime | None None root_cause: str | None None impact: str | None None property def mttr(self) - float | None: if not self.resolved_at: return None return (self.resolved_at - self.detected_at).total_seconds() / 60事故等级SeveritySEV1 完全中断、SEV2 部分中断、SEV3 性能降级、SEV4 轻微问题。配套的incident_response.yaml定义了完整响应规程发现确认告警 → 加入#incident-response→ 建事故文档 → 定级、SEV1 全动员寻呼主备值班、立即通知 VP、拉战争室、指定事故指挥官与沟通负责人、每 15 分钟更新状态、SEV2 团队响应每 30 分钟更新、三大角色职责incident_commander / communication_lead / on_call_engineer以及恢复流程验证指标正常 → 观察 30 分钟 → 发最终状态 → 48 小时内安排 postmortem → 关闭事故。无指责事后分析模板postmortem 模板Postmortem: [Incident Title]的结构直接规范了 SRE 文化摘要 → 影响时长/用户/营收/SLO 预算消耗百分比→ 时间线表格 → 根因 → 处置 → 检测复盘做得好/可改进→ 带负责人、优先级、截止日期的行动项表格 → 经验教训做得好/没做好/侥幸之处。其核心是无指责所有条目面向流程与系统改进而非追责个人。混沌实验定义与安全约束ChaosExperiment数据类把一次实验固化为五要素hypothesis预期、blast_radius影响范围、rollback_plan回滚方案、success_criteria成功标准、以及should_abort安全判定错误率 10% 或 P99 延迟 2s 立即中止。这与 skills/chaos-engineer/SKILL.md 的安全清单先定义稳态、控制爆炸半径、≤30 秒自动回滚、单变量、生产必须有安全网、闭环改进完全同构。三类故障注入器参考文档给出三种可直接用于演练的注入器实现LatencyInjector用 Linuxtc netem注入人工延迟PodKiller按 label selector 随机删除指定比例的 Pod默认 50%利用 Deployment 控制器自动重建NetworkPartition通过kubectl execiptables DROP阻断服务间流量。安全实验运行器ChaosRunner是带监控的安全执行器实验前强制采集基线指标、业务时间外才可运行business_hours_only默认为 True9-17 点拒绝执行、每 10 秒检查一次安全约束、超时默认 15 分钟自动中止finally块保证无论如何都执行injector.rollback()。这保证了混沌实验可控、可回滚、可度量。Game Day 与混沌成熟度gameday_plan.yaml是定期的混沌演练计划模板包含参与者SRE 团队、后端工程师、值班轮换、目标验证响应流程、监控告警、沟通协议、runbook 缺口、三个标准场景数据库主库故障 → 期望 30s 自动切换API 过载 10x 流量 → 期望限流生效零错误网络分区 → 期望熔断打开优雅降级、成功标准MTTR 30 分钟等与安全措施先在 staging 演练、事前通知 VP、每场景备好中止计划。ChaosMaturity枚举定义了从 NONE0到 CULTURE4的五级成熟度阶梯无测试 → 临时手动测试 → 定期 game day → CI/CD 自动混沌 → 嵌入研发文化。配套的assess_maturity函数让团队可以量化自己的混沌工程水位。使用边界MUST DO 与 MUST NOT DO主文档 skills/sre-engineer/SKILL.md 用强制/禁止两栏划定了该 Skill 的行为边界这既是给 Agent 的执行约束也是读者可对照自检的 SRE 规范清单。MUST DO必须做定义量化 SLO如 99.9% 可用性依据 SLO 目标计算错误预算监控四大黄金信号延迟、流量、错误、饱和度为所有事故撰写无指责事后分析度量 Toil 并跟踪削减进展自动化重复性运维任务用混沌工程测试故障场景在可靠性与功能迭代速度之间取得平衡。MUST NOT DO禁止做无用户影响论证就设定 SLO对没有可行动 runbook 的症状告警容忍 50% 的 Toil 却无自动化计划跳过 postmortem 或追责对周期性任务采用人工流程无容量规划就部署无视错误预算耗尽构建无法优雅降级的系统。输出模板与实战组合拳当实际应用该 Skill 时要求交付五类产出物SLO 定义含 SLI 测量方式与目标值监控/告警配置Prometheus 等自动化脚本Python、Go、Terraform带明确修复步骤的 Runbook可靠性影响的简要说明。将这五类产出与主文档 skills/sre-engineer/SKILL.md 中的端到端示例串联就构成了一条完整的可靠运营闭环先用slo_config.yaml与SLOTarget定义 99.9% SLO 并算出 43.2 分钟/月的停机预算 → 用error_budget_policy.yaml绑定预算档位与发布策略 → 用prometheus_rules.yaml录制黄金信号 → 用多窗口燃烧速率告警替代裸阈值告警 → 告警触发时按ErrorBudgetBurnRateFastrunbook 排查 → 重复的排查动作沉淀为AutomatedRunbook与SelfHealer→ 最后通过ChaosRunner在受控条件下验证韧性再用 postmortem 模板固化教训。整个过程既有量化指标兜底又有自动化兜底正是该 Skill 所倡导的以可靠性为货币、以自动化为杠杆的 SRE 实践路径。在实战中如需对混沌工程做更深入的实验设计与故障注入框架搭建可进一步联动仓库中的 skills/chaos-engineer/SKILL.md涉及监控平台落地如 Prometheus 指标体系可参考 skills/monitoring-expert/SKILL.md大规模基础设施与编排可结合 skills/kubernetes-specialist/SKILL.md。三者与sre-engineer在related-skills字段中相互引用构成 devops 领域的完整能力矩阵。【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考