SRE 工具链总览

一句话：SRE 工具链不是一堆工具的堆砌，而是覆盖从监控到告警到故障管理到变更到容量的完整闭环——每个环节有工具支撑，环环相扣。

概述

JD 第 3 条提到”SRE 工具链与稳定性工程建设”。你的 vault 有 CI/CD 工具链、可观测性栈、Terraform 等，但缺少一个把它们串起来的全景视图。本篇做这个串联。

工具链全景图

graph TD
    subgraph 预防层
        IAC[基础设施即代码<br/>Terraform / Pulumi]
        CICD[CI/CD<br/>ArgoCD / Jenkins / GitHub Actions]
        CONF[配置管理<br/>Ansible / Helm / Kustomize]
        SEC[安全扫描<br/>Trivy / Falco]
    end
    
    subgraph 检测层
        MON[监控<br/>Prometheus / Grafana]
        LOG[日志<br/>Loki / ELK]
        TRACE[追踪<br/>Jaeger / Tempo / OTel]
        ALERT[告警<br/>Alertmanager / PagerDuty]
    end
    
    subgraph 响应层
        ONCALL[On-Call<br/>PagerDuty / 飞书]
        INC[故障管理<br/>工单系统 / incident.io]
        RUN[Runbook<br/>自动化操作手册]
        CHAT[协作<br/>Slack / 飞书 / 企微]
    end
    
    subgraph 恢复层
        AUTO[自动化<br/>Argo Rollouts / 自愈脚本]
        DR[灾备<br/>Velero / 跨 Region 备份]
        SCALE[弹性伸缩<br/>HPA / KEDA / Cluster Autoscaler]
    end
    
    subgraph 改进层
        POST[复盘<br/>Postmortem 模板]
        DASH[看板<br/>Grafana MTTR/MTBF]
        CHAOS[混沌工程<br/>ChaosMesh]
    end
    
    subgraph AI层
        AIOPS[AIOps<br/>异常检测 / 告警降噪]
        AGENT[SRE Agent<br/>AI 辅助诊断]
    end
    
    IAC --> MON
    CICD --> ALERT
    MON --> ALERT
    LOG --> ALERT
    TRACE --> ALERT
    ALERT --> ONCALL
    ONCALL --> INC
    INC --> RUN
    RUN --> AUTO
    AUTO --> DR
    INC --> POST
    POST --> DASH
    DASH --> IAC
    AIOPS --> ALERT
    AGENT --> INC

各层工具选型

预防层

环节	工具	用途	已有笔记
IaC	Terraform / Pulumi	基础设施声明式管理	Terraform 基础设施即代码 Terraform 生产级实践
CI/CD	ArgoCD / Jenkins / GitHub Actions	持续集成与持续交付	CI-CD 知识总览 ArgoCD GitOps 实战
配置管理	Helm / Kustomize	K8s 应用配置管理	Helm 与 Kustomize 配置管理
安全扫描	Trivy / Falco	镜像扫描 / 运行时安全	K8s 安全加固实战

检测层

环节	工具	用途	已有笔记
指标监控	Prometheus / VictoriaMetrics	指标采集与存储	Metrics 与 Prometheus 实战
可视化	Grafana	看板与告警	Grafana 可视化与告警
日志	Loki / ELK	日志聚合与查询	日志体系 Loki 与 ELK 对比
链路追踪	Jaeger / Tempo / OTel	分布式追踪	分布式追踪 OpenTelemetry
告警	Alertmanager	告警路由、分组、抑制	SLO SLI 错误预算与智能告警

响应层

环节	工具	用途	关联笔记
On-Call	PagerDuty / 飞书机器人	值班轮换、告警推送	On-Call 体系与值班机制
故障管理	工单系统 / incident.io	故障生命周期跟踪	故障生命周期管理
Runbook	自动化脚本 / Bot	标准化操作步骤	应急预案与故障演练
协作	Slack / 飞书 / 企微	故障响应协作	—

恢复层

环节	工具	用途	关联笔记
自动回滚	Argo Rollouts / ArgoCD	自动化回滚与渐进式发布	灰度发布与渐进式交付
灾备	Velero / 跨 Region 备份	K8s 集群备份与恢复	灾备与容灾方案
弹性伸缩	HPA / KEDA / Cluster Autoscaler	自动扩缩容	弹性伸缩策略
自愈	Kubernetes 自愈 / 自定义控制器	Pod 自动重启与恢复	故障自愈与自动恢复

改进层

环节	工具	用途	关联笔记
复盘	Postmortem 模板	无指责复盘记录	无指责复盘与故障分析方法论
度量看板	Grafana MTTR/MTBF	可靠性指标跟踪	MTTR 与 MTBF 体系详解
混沌工程	ChaosMesh / LitmusChaos	故障注入验证	混沌工程与故障注入

AI 层

环节	工具	用途	关联笔记
AIOps	自建 / Datadog Watchdog	智能异常检测与告警降噪	AIOps 实践与智能运维
SRE Agent	kagent / 自建 Agent	AI 辅助故障诊断与修复	SRE Agent 运维落地实践 kagent 详解

工具链建设路线

阶段 1（基础）：监控告警 + CI/CD + IaC
  → 你已完成 ✅

阶段 2（响应）：On-Call + 故障管理 + Runbook
  → 当前缺口

阶段 3（度量）：MTTR/MTBF 看板 + SLO 度量
  → 当前缺口

阶段 4（预防）：混沌工程 + 容量规划 + 变更管理
  → 当前缺口

阶段 5（智能）：AIOps + SRE Agent
  → 有 AI Agent 基础，缺运维场景落地

与已有知识库的串联

graph LR
    subgraph 已有笔记
        T1[可观测性知识总览]
        T2[CI-CD 知识总览]
        T3[Terraform]
        T4[K8s 生态]
        T5[AI Agent 系列]
    end
    
    subgraph SRE工具链
        S1[检测层] -->|由| T1
        S2[预防层] -->|由| T2
        S2 -->|由| T3
        S3[恢复层] -->|由| T4
        S4[AI层] -->|由| T5
    end
    
    S1 --> S5[响应层]
    S5 --> S6[改进层]
    S6 --> S2

自动化运维脚本示例

一键回滚 Runbook

#!/bin/bash
# Runbook: 紧急回滚 ArgoCD Application
# 触发条件: 新版本导致故障，需要快速回滚

set -euo pipefail

APP_NAME="${1:?Usage: $0 <app-name>}"
NAMESPACE="${2:-default}"

echo "=== 开始回滚 $APP_NAME ==="

# Step 1: 确认当前版本
CURRENT_REVISION=$(argocd app get "$APP_NAME" -o jsonpath='{.status.sync.revision}')
echo "当前版本: $CURRENT_REVISION"

# Step 2: 找到上一个健康版本
PREVIOUS_REVISION=$(argocd app history "$APP_NAME" \
  --json | jq -r '[.[] | select(.health.status == "Healthy")] | .[-2].revision')

if [ -z "$PREVIOUS_REVISION" ]; then
  echo "ERROR: 找不到上一个健康版本"
  exit 1
fi

echo "回滚到版本: $PREVIOUS_REVISION"

# Step 3: 执行回滚
argocd app rollback "$APP_NAME" "$PREVIOUS_REVISION"

# Step 4: 等待同步完成
echo "等待同步..."
argocd app wait "$APP_NAME" --sync --timeout 120

# Step 5: 验证服务健康
HEALTH_URL="http://$APP_NAME.$NAMESPACE.svc.cluster.local:8080/health"
for i in $(seq 1 10); do
  if curl -sf "$HEALTH_URL" > /dev/null 2>&1; then
    echo "✓ 回滚成功，服务健康"
    exit 0
  fi
  echo "等待服务恢复... ($i/10)"
  sleep 5
done

echo "✗ 回滚后服务仍不健康，需要人工介入"
exit 1

故障自愈脚本示例

#!/usr/bin/env python3
"""Runbook: Pod CrashLoopBackOff 自愈"""
import subprocess
import json
import time

def get_crashloop_pods(namespace: str = "") -> list:
    """获取 CrashLoopBackOff 状态的 Pod"""
    cmd = ["kubectl", "get", "pods", "-o", "json"]
    if namespace:
        cmd.extend(["-n", namespace])
    
    result = subprocess.run(cmd, capture_output=True, text=True)
    pods = json.loads(result.stdout)
    
    crash_pods = []
    for pod in pods.get("items", []):
        for cs in pod["status"].get("containerStatuses", []):
            state = cs.get("state", {})
            waiting = state.get("waiting", {})
            if waiting.get("reason") == "CrashLoopBackOff":
                restart_count = cs.get("restartCount", 0)
                if restart_count >= 5:  # 重启 5 次以上才处理
                    crash_pods.append({
                        "pod": pod["metadata"]["name"],
                        "namespace": pod["metadata"]["namespace"],
                        "container": cs["name"],
                        "restart_count": restart_count,
                    })
    return crash_pods

def heal_crashloop_pod(pod_info: dict) -> bool:
    """尝试自愈 CrashLoopBackOff Pod"""
    pod = pod_info["pod"]
    ns = pod_info["namespace"]
    
    # Step 1: 获取最近日志
    logs = subprocess.run(
        ["kubectl", "logs", pod, "-n", ns, "--tail=50", "--previous"],
        capture_output=True, text=True
    ).stdout
    
    # Step 2: 判断故障类型
    if "OOMKilled" in logs or "out of memory" in logs.lower():
        # OOM: 尝试增加内存限制（需要 RBAC 权限）
        print(f"[{pod}] OOM detected, attempting to increase memory limit")
        # 这里可以调用 kubectl patch 或更新 Deployment
        return "oom"
    
    if "connection refused" in logs.lower():
        # 依赖不可达: 检查依赖服务
        print(f"[{pod}] Connection refused, checking dependencies")
        return "dependency"
    
    # 未知原因: 触发告警 + 创建工单
    print(f"[{pod}] Unknown crash reason, escalating")
    return "unknown"

if __name__ == "__main__":
    while True:
        crash_pods = get_crashloop_pods()
        for pod_info in crash_pods:
            result = heal_crashloop_pod(pod_info)
            # 根据结果决定后续动作
        time.sleep(60)

工具链建设优先级

优先级	工具/能力	现状	目标
P0	监控告警全覆盖	✅ 已有 Prometheus + Grafana	补充 SLO 燃烧率告警
P0	CI/CD + 自动回滚	✅ 已有 ArgoCD	补充一键回滚 Runbook
P0	On-Call + 告警路由	❌ 缺失	建 Alertmanager → 飞书/企微 → PagerDuty
P1	故障管理工单	❌ 缺失	选型 + 落地
P1	MTTR/MTBF 度量	❌ 缺失	建 Grafana 看板
P1	弹性伸缩	❌ 缺失	HPA + KEDA 落地
P2	混沌工程	❌ 缺失	ChaosMesh 试点
P2	AIOps 异常检测	❌ 缺失	时序异常检测试点
P3	SRE Agent	有 kagent 基础	运维场景落地

关联知识

• SRE 稳定性工程总览 — 本篇是工具层面的总览
• 可观测性知识总览 — 检测层底座
• CI-CD 知识总览 — 预防层 CI/CD
• Terraform 生产级实践 — 预防层 IaC
• SLO SLI 错误预算与智能告警 — 检测层告警
• MTTR 与 MTBF 体系详解 — 改进层度量
• 故障生命周期管理 — 响应层流程
• On-Call 体系与值班机制 — 响应层值班
• 应急预案与故障演练 — 恢复层预案
• 弹性伸缩策略 — 恢复层弹性
• 混沌工程与故障注入 — 改进层混沌
• SRE Agent 运维落地实践 — AI 层
• AIOps 实践与智能运维 — AI 层

参考资源

• CNCF Landscape: https://landscape.cncf.io/
• SRE 工具链白皮书（各家云厂商）
• OpenSRE: https://github.com/open-sre

状态

• 工具链全景图
• 各层工具选型
• 建设路线
• 自动化脚本示例
• 建设优先级