SRE 与开发团队协作模式：打破壁垒的工程实践

# 嵌入式 SRE 的组织结构示例
产品团队 A
├── 开发工程师 × 6
├── 测试工程师 × 2
├── 产品经理 × 1
└── 嵌入式 SRE × 1（50%-100% 投入）

产品团队 B
├── 开发工程师 × 4
├── 测试工程师 × 1
├── 产品经理 × 1
└── 嵌入式 SRE × 1（50%-100% 投入）

SRE 中心团队（CoE）
├── SRE 技术负责人
├── 平台 SRE（工具和平台建设）
└── 虚线管理所有嵌入式 SRE

# Hub and Spoke 的 RACI 矩阵

| 职责 | Hub SRE | Spoke SRE | 开发团队 | 产品经理 |
|------|---------|-----------|---------|---------|
| SLO 制定 | A（标准制定） | R（执行落地） | C（提供业务输入） | I |
| 监控告警 | R（平台建设） | R（业务规则） | C | I |
| 事件响应 | C（L2 支援） | R（L1 响应） | R（开发参与） | I |
| 故障复盘 | C（质量保障） | A（主持复盘） | R（根因分析） | I |
| 容量规划 | C（工具支持） | R（执行） | C | C |
| 自动化工具 | R（平台开发） | C（需求输入） | C | I |

# 传统模型 vs 平台工程模型

## 传统模型
开发 → 提需求 → SRE 执行 → 开发等待 → SRE 交付
（每次都重复，瓶颈在 SRE）

## 平台工程模型
开发 → 自助使用平台 → 自主完成 → 按需咨询
（一次性投入，长期受益）

# Golden Path 示例：微服务标准化模板
service_template:
  # 代码模板
  scaffold:
    language: go
    framework: gin
    grpc: true
    
  # CI/CD 自动配置
  cicd:
    pipeline: github-actions
    auto_deploy: staging  # main 分支自动部署 staging
    prod_requires: manual_approval
    
  # 可观测性自动注入
  observability:
    metrics: prometheus    # 自动暴露 /metrics
    tracing: opentelemetry # 自动注入 trace
    logging: loki          # 结构化日志自动收集
    
  # SLO 自动生成
  slo:
    availability: 99.9%
    latency_p99: 200ms
    error_budget_policy: auto  # 错误预算耗尽自动暂停部署
    
  # 安全基线
  security:
    image_scan: true
    secret_scan: true
    rbac: least-privilege

#!/usr/bin/env python3
"""
错误预算消耗监控与自动决策框架
当错误预算消耗超过阈值时，自动触发相应的行动
"""

import datetime
from dataclasses import dataclass
from enum import Enum

class BudgetAction(Enum):
    GREEN = "正常发布"
    YELLOW = "发布需 SRE 评审"  
    ORANGE = "仅允许修复性发布"
    RED = "冻结所有非修复性发布"

@dataclass
class ErrorBudget:
    slo_target: float           # SLO 目标，如 99.9%
    window_days: int           # 错误预算窗口，如 30 天
    total_requests: int        # 窗口内总请求数
    error_requests: int        # 窗口内错误请求数
    
    @property
    def availability(self) -> float:
        """当前可用性"""
        if self.total_requests == 0:
            return 100.0
        return (1 - self.error_requests / self.total_requests) * 100
    
    @property
    def total_budget(self) -> float:
        """总错误预算（错误请求配额）"""
        allowed_error_rate = 100 - self.slo_target
        return self.total_requests * allowed_error_rate / 100
    
    @property
    def budget_consumed(self) -> float:
        """已消耗错误预算百分比"""
        if self.total_budget == 0:
            return 0
        return min(self.error_requests / self.total_budget * 100, 100)
    
    @property
    def budget_remaining(self) -> float:
        """剩余错误预算百分比"""
        return max(100 - self.budget_consumed, 0)
    
    def get_action(self) -> BudgetAction:
        """根据预算消耗情况返回行动建议"""
        consumed = self.budget_consumed
        if consumed < 50:
            return BudgetAction.GREEN
        elif consumed < 75:
            return BudgetAction.YELLOW
        elif consumed < 100:
            return BudgetAction.ORANGE
        else:
            return BudgetAction.RED
    
    def summary(self) -> str:
        """生成错误预算摘要报告"""
        action = self.get_action()
        return (
            f"=== 错误预算报告 ===\n"
            f"SLO 目标: {self.slo_target}%\n"
            f"当前可用性: {self.availability:.3f}%\n"
            f"错误预算消耗: {self.budget_consumed:.1f}%\n"
            f"剩余预算: {self.budget_remaining:.1f}%\n"
            f"当前行动策略: {action.value}\n"
            f"窗口: 最近 {self.window_days} 天\n"
            f"总请求: {self.total_requests:,}\n"
            f"错误请求: {self.error_requests:,}"
        )

# 示例使用
if __name__ == "__main__":
    budget = ErrorBudget(
        slo_target=99.9,
        window_days=30,
        total_requests=10_000_000,
        error_requests=8_000
    )
    print(budget.summary())
    print()
    
    # 模拟预算即将耗尽
    budget2 = ErrorBudget(
        slo_target=99.9,
        window_days=30,
        total_requests=10_000_000,
        error_requests=9_500
    )
    print(budget2.summary())

=== 错误预算报告 ===
SLO 目标: 99.9%
当前可用性: 99.920%
错误预算消耗: 80.0%
剩余预算: 20.0%
当前行动策略: 仅允许修复性发布
窗口: 最近 30 天
总请求: 10,000,000
错误请求: 8,000

=== 错误预算报告 ===
SLO 目标: 99.9%
当前可用性: 99.905%
错误预算消耗: 95.0%
剩余预算: 5.0%
当前行动策略: 仅允许修复性发布
窗口: 最近 30 天
总请求: 10,000,000
错误请求: 9,500

# 生产就绪度评审清单

## 1. 架构与设计
- [ ] 服务架构图清晰，依赖关系明确
- [ ] 单点故障已识别并有消除计划
- [ ] 容量评估完成，瓶颈已标注
- [ ] 故障域分析完成

## 2. 容量与弹性
- [ ] 自动扩缩容配置正确
- [ ] 降级策略已定义并测试
- [ ] 熔断和限流机制就位
- [ ] 背压机制已实现（如适用）

## 3. 可观测性
- [ ] 黄金信号（延迟、流量、错误、饱和度）已埋点
- [ ] 关键业务指标有独立面板
- [ ] 告警规则已配置并经过验证
- [ ] 分布式追踪已接入
- [ ] 日志格式标准化、集中收集

## 4. 变更管理
- [ ] CI/CD 流水线覆盖测试→灰度→生产
- [ ] 灰度发布策略已配置
- [ ] 回滚机制已验证（≤5 分钟）
- [ ] 变更审批流程清晰

## 5. 事件响应
- [ ] Runbook 已编写并经实际验证
- [ ] 值班排班已安排
- [ ] 升级路径明确
- [ ] On-call 工具链就位

## 6. 数据与状态
- [ ] 数据备份策略已实施
- [ ] 数据恢复已演练
- [ ] 数据一致性保障机制就位
- [ ] 缓存失效策略合理

## 7. 安全
- [ ] 认证授权机制就位
- [ ] 敏感数据加密存储
- [ ] 依赖漏洞定期扫描
- [ ] 容器镜像安全扫描

## 8. SLO 定义
- [ ] SLI 已定义并与业务对齐
- [ ] SLO 目标已与干系人确认
- [ ] 错误预算策略已生效
- [ ] 错误预算耗尽时的行动方案已约定

# 统一工具链示例

监控:       Prometheus + VictoriaMetrics（SRE 和开发共用同一面板）
日志:       Loki + Grafana（开发可自主查询）
追踪:       Jaeger（开发可自主排查）
告警:       Alertmanager → 统一通知渠道
部署:       ArgoCD（GitOps，开发自主操作）
事件管理:    PagerDuty / 自建 oncall 系统
知识库:      Confluence / Wiki（统一文档中心）

# DevOps 的方式
开发团队 → 自己搞定所有事情 → DevOps 工程师
问题：认知负荷过高，重复劳动

# 平台工程的方式
平台团队 → 构建自助式平台 → 开发团队消费平台
优势：关注点分离，能力复用，规模化

#!/bin/bash
# DORA 指标采集脚本示例
# 从 CI/CD 系统和监控系统采集 DORA 四指标

# 1. 部署频率 (Deployment Frequency)
# 统计过去 30 天的部署次数
deploys=$(git log --oneline --since="30 days ago" --grep="deploy" | wc -l)
daily_avg=$(echo "scale=1; $deploys / 30" | bc)
echo "部署频率: ${daily_avg} 次/天"

# 2. 变更前置时间 (Lead Time for Changes)
# 统计 PR 从提交到合并的平均时间
lead_time=$(gh pr list --state merged --limit 100 \
  --json createdAt,mergedAt \
  --jq '[.[] | (.mergedAt | fromdate) - (.createdAt | fromdate)] | add / length / 3600')
echo "变更前置时间: ${lead_time} 小时"

# 3. 变更失败率 (Change Failure Rate)
# 统计导致回滚或事故的部署占比
total_deploys=120
failed_deploys=6
failure_rate=$(echo "scale=1; $failed_deploys * 100 / $total_deploys" | bc)
echo "变更失败率: ${failure_rate}%"

# 4. 服务恢复时间 (Time to Restore Service)
# 统计事故从发生到恢复的平均时间
mttr_hours=1.5
echo "服务恢复时间: ${mttr_hours} 小时"

echo "---"
echo "DORA 评级:"
if (( $(echo "$daily_avg >= 1" | bc -l) )) && \
   (( $(echo "$lead_time < 24" | bc -l) )) && \
   (( $(echo "$failure_rate < 15" | bc -l) )) && \
   (( $(echo "$mttr_hours < 1" | bc -l) )); then
    echo "Elite（精英级）"
elif (( $(echo "$daily_avg >= 0.1" | bc -l) )) && \
     (( $(echo "$lead_time < 168" | bc -l) )) && \
     (( $(echo "$failure_rate < 30" | bc -l) )); then
    echo "High（高绩效）"
else
    echo "需要改进"
fi

阶段 1（第 1-3 个月）：建立信任
├── 引入错误预算概念，双方共同制定 SLO
├── 事故复盘开放，开发参与根因分析
├── 运维团队更名为 SRE 团队
└── 建立 SRE 与开发的定期沟通机制（每周同步会）

阶段 2（第 4-6 个月）：工具赋能
├── 建设统一 CI/CD 平台（ArgoCD + GitHub Actions）
├── 开发自助部署到 staging 环境
├── 统一监控告警平台（Prometheus + Grafana）
├── 开发可自助查看监控和日志
└── SRE 编写服务模板（Golden Path）

阶段 3（第 7-9 个月）：责任转移
├── 开发团队承担生产部署操作（SRE 评审而非执行）
├── 开发团队参与 oncall 轮值（SRE 作为 L2 支援）
├── 生产就绪度评审流程上线
└── Runbook 共建机制运行

阶段 4（第 10-12 个月）：平台化
├── 内部开发者平台（IDP）上线
├── 自助式 SLO 定义和告警配置
├── 自动化容量管理和扩缩容
└── SRE 团队专注平台建设（事务性工作 <20%）