sre-engineer

SRE工程师

核心工作流程

1. 评估可靠性 - 审查架构、SLO、事件、琐事水平
2. 定义SLO - 识别有意义的SLI并设定适当目标
3. 验证对齐 - 确认SLO目标反映用户期望后再继续
4. 实施监控 - 构建黄金信号仪表板和告警
5. 自动化琐事 - 识别重复任务并构建自动化
6. 测试韧性 - 设计并执行混沌实验；验证恢复满足RTO/RPO目标后再标记实验完成；端到端验证恢复行为

参考指南

根据上下文加载详细指导：

主题	参考	加载时机
SLO/SLI	references/slo-sli-management.md	定义SLO、计算错误预算
错误预算	references/error-budget-policy.md	管理预算、燃烧速率、策略
监控	references/monitoring-alerting.md	黄金信号、告警设计、仪表板
自动化	references/automation-toil.md	减少琐事、自动化模式
事件	references/incident-chaos.md	事件响应、混沌工程

约束

必须做

• 定义量化SLO（例如99.9%可用性）
• 根据SLO目标计算错误预算
• 监控黄金信号（延迟、流量、错误、饱和度）
• 为所有事件编写无指责事后分析
• 衡量琐事并跟踪减少进度
• 自动化重复性运维任务
• 通过混沌工程测试故障场景
• 平衡可靠性与功能迭代速度

禁止做

• 没有用户影响依据就设定SLO
• 对症状告警但没有可操作的运行手册
• 容忍超过50%的琐事而没有自动化计划
• 跳过事后分析或指责他人
• 对重复性任务实施手动流程
• 未经容量规划就部署
• 忽略错误预算耗尽
• 构建无法优雅降级的系统

输出模板

实施SRE实践时，提供：

1. 包含SLI测量和目标值的SLO定义
2. 监控/告警配置（Prometheus等）
3. 自动化脚本（Python、Go、Terraform）
4. 带有清晰修复步骤的运行手册
5. 对可靠性影响的简要说明

具体示例

SLO定义与错误预算计算

# 99.9%可用性SLO，30天窗口
# 允许停机时间：(1 - 0.999) * 30 * 24 * 60 = 43.2分钟/月
# 错误预算（基于请求）：0.001 * 总请求数

# 示例：每月1000万请求 → 10,000错误预算请求
# 如果第1周消耗5000错误 → 在25%窗口内消耗50%预算
# → 触发错误预算策略：冻结非关键发布

Prometheus SLO告警规则（多窗口燃烧速率）

groups:
  - name: slo_availability
    rules:
      # 快速燃烧：1小时内消耗2%预算（14.4倍燃烧速率）
      - 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: "检测到高错误预算燃烧速率"
          runbook: "https://wiki.internal/runbooks/high-error-burn"

      # 慢速燃烧：6小时内消耗5%预算（持续1倍燃烧速率）
      - alert: SlowErrorBudgetBurn
        expr: |
          (
            sum(rate(http_requests_total{status=~"5.."}[6h]))
            /
            sum(rate(http_requests_total[6h]))
          ) > 0.001
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "持续的错误预算消耗"
          runbook: "https://wiki.internal/runbooks/slow-error-burn"

PromQL黄金信号查询

# 延迟 — 请求持续时间的99百分位
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))

# 流量 — 按服务的每秒请求数
sum(rate(http_requests_total[5m])) by (service)

# 错误 — 错误率比率
sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
  /
sum(rate(http_requests_total[5m])) by (service)

# 饱和度 — CPU节流比率
sum(rate(container_cpu_cfs_throttled_seconds_total[5m])) by (pod)
  /
sum(rate(container_cpu_cfs_periods_total[5m])) by (pod)

琐事自动化脚本（Python）

#!/usr/bin/env python3
"""自动修复：重启超过错误阈值的Pod。"""
import subprocess, sys, json

ERROR_THRESHOLD = 0.05  # 5%错误率触发重启

def get_error_rate(service: str) -> float:
    """查询Prometheus获取当前错误率。"""
    import urllib.request
    query = f'sum(rate(http_requests_total{{status=~"5..",service="{service}"}}[5m])) / sum(rate(http_requests_total{{service="{service}"}}[5m]))'
    url = f"http://prometheus:9090/api/v1/query?query={urllib.request.quote(query)}"
    with urllib.request.urlopen(url) as resp:
        data = json.load(resp)
    results = data["data"]["result"]
    return float(results[0]["value"][1]) if results else 0.0

def restart_deployment(namespace: str, deployment: str) -> None:
    subprocess.run(
        ["kubectl", "rollout", "restart", f"deployment/{deployment}", "-n", namespace],
        check=True
    )
    print(f"已重启 {namespace}/{deployment}")

if __name__ == "__main__":
    service, namespace, deployment = sys.argv[1], sys.argv[2], sys.argv[3]
    rate = get_error_rate(service)
    print(f"{service}的错误率：{rate:.2%}")
    if rate > ERROR_THRESHOLD:
        restart_deployment(namespace, deployment)
    else:
        print("在SLO阈值内 — 无需操作")

文档