1
2
3
4
5
6
7
8

□ 需求是否有统一的用户故事模板和验收标准（AC）？
□ 迭代中被打断插入的紧急需求占比是否<15%？
□ 看板是否设置了WIP（在制品）限制并严格执行？
□ 每个Sprint的回顾会是否有明确的改进Action并跟踪落地？
□ 需求从提出到上线的平均前置时间是否可度量？
□ 是否有需求积压（Backlog）的定期梳理机制？
□ 团队速率（Velocity）是否稳定且可预测？
□ 是否有需求价值的上线后验证闭环？

1
2
3
4
5
6
7
8

□ 代码提交后是否自动触发构建和单元测试？
□ 流水线执行时间是否<15分钟（从提交到可部署制品）？
□ 是否有明确的分支策略（GitFlow/Trunk-based）并严格执行？
□ 部署到生产环境是否无需人工干预（或仅需审批触发）？
□ 生产部署失败率是否<5%？
□ 是否能在5分钟内完成回滚？
□ 自动化测试覆盖率是否>80%且有质量门禁拦截？
□ 是否使用蓝绿部署或金丝雀发布降低风险？

1
2
3
4
5

# DORA（DevOps Research and Assessment）四大关键指标
部署频率（Deployment Frequency）:  精英团队 → 按需/每日多次
变更前置时间（Lead Time for Changes）: 精英团队 → <1小时
变更失败率（Change Failure Rate）:  精英团队 → <5%
服务恢复时间（MTTR）:              精英团队 → <1小时

1
2
3
4
5
6
7
8

□ 是否有覆盖核心链路的监控大盘和告警规则？
□ 告警是否经过收敛处理，避免告警风暴？
□ 是否有标准化的On-Call轮值机制？
□ 生产事件是否有完整的复盘（Postmortem）流程？
□ 服务是否有明确的SLI/SLO定义？
□ 是否实现了弹性伸缩（HPA/VPA/KEDA）？
□ 变更是否有标准化的风险评估和回滚预案？
□ 是否定期执行混沌工程实验（如故障注入）？

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# Prometheus AlertManager 告警规则示例
groups:
  - name: service_slo
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
          /
          sum(rate(http_requests_total[5m])) > 0.01
        for: 2m
        labels:
          severity: critical
          team: platform
        annotations:
          summary: "服务错误率超过1% SLO阈值"
          runbook: "https://wiki.internal/runbook/high-error-rate"
          dashboard: "https://grafana.internal/d/service-overview"

1
2
3
4
5
6
7
8

□ 应用是否已容器化并使用Kubernetes编排？
□ 服务之间是否有明确的边界定义和API契约？
□ 基础设施是否通过代码管理（Terraform/Pulumi）？
□ 是否采用GitOps方式进行环境配置管理？
□ 安全扫描是否集成到CI/CD流水线中（SAST/DAST/SCA）？
□ 配置和密钥是否通过统一的管理方案（Vault/External Secrets）管理？
□ 服务是否实现了优雅降级和熔断机制？
□ API是否有统一的规范和版本管理策略？

1
2
3
4
5
6
7
8
9

开发者提交代码 → CI构建镜像 → 推送至镜像仓库
     ↓
自动更新Git仓库中的K8s Manifest（image tag）
     ↓
ArgoCD检测到Git变更 → 自动同步至集群
     ↓
Canary Analysis（Prometheus指标检查）
     ↓
通过 → 全量发布 | 失败 → 自动回滚

1
2
3
4
5
6
7
8

□ 团队是否按产品/特性组织而非按职能组织？
□ 开发和运维是否在同一个团队或至少有日常协作机制？
□ 是否有定期的技术分享和知识传播机制？
□ 线上事件复盘是否坚持Blameless原则？
□ 是否有明确的研发效能度量指标并定期Review？
□ 团队是否有自主选择和引入工具链的权限？
□ 改进事项是否进入Backlog并像需求一样被管理？
□ 是否有平台工程团队为产品团队提供自助化能力？

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

                    敏捷开发管理
                        4
                        |
                        |
            5 ----------+---------- 3
           / 组织结构                \
          /                           \
         /                             \
        /                               \
  持续交付 ----------+---------- 应用设计
         3            |            4
                      |
                      |
                   技术运营
                      3

  评分: 敏捷开发管理=L4, 持续交付=L3, 技术运营=L3, 应用设计=L4, 组织结构=L2

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# 使用 matplotlib 绘制雷达图的快速脚本
import matplotlib.pyplot as plt
import numpy as np

domains = ['敏捷开发管理', '持续交付', '技术运营', '应用设计', '组织结构']
scores = [4, 3, 3, 4, 2]  # 填入各域评分(1-5)

angles = np.linspace(0, 2 * np.pi, len(domains), endpoint=False).tolist()
scores_plot = scores + [scores[0]]
angles += [angles[0]]

fig, ax = plt.subplots(figsize=(8, 8), subplot_kw=dict(polar=True))
ax.fill(angles, scores_plot, color='blue', alpha=0.25)
ax.plot(angles, scores_plot, color='blue', linewidth=2)
ax.set_xticks(angles[:-1])
ax.set_xticklabels(domains, fontsize=12)
ax.set_ylim(0, 5)
ax.set_yticks([1, 2, 3, 4, 5])
ax.set_title('DevOps能力成熟度雷达图', fontsize=16, pad=20)
plt.tight_layout()
plt.savefig('devops-radar.png', dpi=150)

1
2
3
4
5
6
7
8

典型场景：组织结构=L1，其他域=L2-L3

改进动作：
├── 第1-2周：启动DevOps意识培训，全员对齐目标
├── 第3-4周：组建第一个跨职能特性团队试点
├── 第5-8周：建立每日站会+双周回顾机制
├── 第9-12周：试点团队效能度量（Lead Time + 部署频率）
└── 预期成果：试点团队交付周期缩短30%+

1
2
3
4
5
6

体系化建设重点：
├── 平台工程：建设内部开发者平台（IDP），自助化基础设施能力
├── 效能度量：建立端到端的价值流度量体系
├── 知识沉淀：Runbook标准化、架构决策记录（ADR）、故障案例库
├── 技术创新：混沌工程常态化、AIOps探索、Serverless试点
└── 文化深化：内部技术社区、黑客松、开源贡献

1
2
3
4
5
6
7

# 各等级团队核心指标对比
                  L1-L2        L3          L4-L5
部署频率          月级          周级         日级/按需
变更前置时间      >1月          1周-1月      <1天
变更失败率        >30%          15-30%       <5%
MTTR              >1天          数小时        <1小时
团队满意度        <40%          50-70%       >80%

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# 度量驱动改进示例
metrics:
  - name: 部署频率
    current: 2次/周
    target: 每日1次
    owner: 平台团队
    trigger: "< 3次/周时触发流水线优化Sprint"
    action: "分析流水线瓶颈，优化构建缓存，拆分大模块"

  - name: 变更失败率
    current: 18%
    target: <5%
    owner: QA团队
    trigger: "> 10%时触发质量门禁加强"
    action: "增加E2E测试覆盖，引入契约测试，加强Code Review"

1
2
3
4
5
6
7
8
9

技术债务Backlog示例：
┌──────┬──────────────────────┬──────┬──────────┬────────┐
│ 编号 │ 描述                  │ 等级 │ 影响域    │ 预估工时│
├──────┼──────────────────────┼──────┼──────────┼────────┤
│ TD01 │ 订单服务单点部署      │ P0   │ 技术运营  │ 2周    │
│ TD02 │ 用户服务缺少集成测试  │ P1   │ 持续交付  │ 1周    │
│ TD03 │ 配置硬编码在代码中    │ P1   │ 应用设计  │ 3天    │
│ TD04 │ 数据库未做读写分离    │ P2   │ 技术运营  │ 3周    │
└──────┴──────────────────────┴──────┴──────────┴────────┘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

季度改进计划模板：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
团队名称：[填写]
评估日期：[填写]
当前短板域：[评分最低的域]
目标等级：[当前等级+1]

本季度Top 3改进项：
1. [具体改进动作] → Owner: [人名] → 完成时间: [日期]
2. [具体改进动作] → Owner: [人名] → 完成时间: [日期]
3. [具体改进动作] → Owner: [人名] → 完成时间: [日期]

度量指标：
- 改进前基线：[当前值]
- 改进后目标：[目标值]
- 检查频率：[每周/每两周]

资源需求：
- 人力投入：[人天]
- 工具/平台：[所需工具]
- 培训需求：[培训课程]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━