Learn DevOps

DevOps 成熟度模型

第一阶段：L1 - Initialized（初始级：手动与无序）

1. People & Culture（人员与文化）

• Awareness of Silos：意识到开发与运维之间的“部门墙”和孤岛效应。
• Identify Pain Points：识别痛点，开始讨论协作改进的可能性。
• Stakeholder Mapping：确定关键利益相关者和改革的潜在支持者。

2. Process & Practice（流程与实践）

• Ad-hoc Processes：流程主要依赖个人经验，缺乏文档化。
• Manual Operations：构建、测试和部署主要依赖手动操作，容易出错。
• Identify Key Value Streams：梳理核心业务应用及其关键流程。

3. Tooling & Technology（工具与技术）

• Source Control Management (SCM)：开始使用 Git 进行基本的版本控制（不仅是代码，也包括配置）。
• Tool Inventory：盘点当前使用的杂乱工具，识别“影子IT”。
• Basic Scripting：鼓励个人使用脚本解决重复性劳动，但这尚未成为团队标准。

第二阶段：L2 - Managed（管理级：项目试点与自动化起步）

1. People & Culture（人员与文化）

• Pilot Teams：组建跨职能的试点小组，打破小范围的孤岛。
• Blameless Post-mortems (Intro)：引入“不指责”的事故复盘文化雏形。
• Communication Channels：建立 ChatOps 或统一沟通渠道（如 Slack/钉钉群组）。

2. Process & Practice（流程与实践）

• Basic CI/CD：在试点项目中建立持续集成（CI）流水线，实现自动构建。
• Shift-Left Security (Awareness)：引入基础的代码静态扫描（SAST），开始关注安全。
• Agile Methodology：引入看板（Kanban）或 Scrum 管理工作流。

3. Tooling & Technology（工具与技术）

• Standardized CI Server：统一 CI 工具（如 Jenkins, GitLab CI）。
• Artifact Management：强制使用制品库（如 Nexus/Artifactory/Harbor）管理二进制包。
• Configuration Management：开始引入配置管理工具（如 Ansible）。

第三阶段：L3 - Defined（定义级：标准化与规模化）

1. People & Culture（人员与文化）

• Cross-functional Teams：开发、运维、测试、安全人员组成全功能的 Feature Team。
• Knowledge Sharing：建立内部技术雷达，定期分享最佳实践和失败案例。
• Defined Standards：制定并推广组织级的 DevOps 规范。

2. Process & Practice（流程与实践）

• Trunk-Based Development：推广主干开发模式，减少长寿命分支。
• Automated Testing：实施分层测试策略（单元测试、集成测试自动化），质量门禁自动化。
• IaC (Infrastructure as Code)：全面实施基础设施即代码（Terraform/CloudFormation）。

3. Tooling & Technology（工具与技术）

• Integrated Toolchain：工具链打通，从需求到部署数据流转透明。
• Containerization & Orchestration：广泛使用容器（Docker）和编排技术（K8s）。
• DevSecOps Pipeline：安全扫描（SAST/DAST/SCA）集成进流水线并强制阻断。

第四阶段：L4 - Optimized（优化级：数据驱动与平台化）

1. People & Culture（人员与文化）

• You Build It, You Run It：团队对服务的全生命周期负责（包含 On-call）。
• Data-Driven Decisions：基于 DORA 四项指标（部署频率、变更时长、失败率、恢复时间）进行考核与改进。
• SLO/SLI Ownership：团队自主定义并维护服务等级目标（SLO）。

2. Process & Practice（流程与实践）

• Progressive Delivery：实施金丝雀发布、蓝绿部署或特性开关（Feature Flags）。
• GitOps：以 Git 为单一事实来源，自动同步基础设施和应用状态。
• FinOps (Cost Management)：关注云资源成本，优化资源使用效率。

3. Tooling & Technology（工具与技术）

• Internal Developer Platform (IDP)：构建内部开发者平台，屏蔽底层复杂性。
• Full Observability：从单纯的监控（Monitoring）升级为可观测性（Logs, Metrics, Traces）。
• Self-Service Capabilities：开发者可自助申请资源、环境和部署。

第五阶段：L5 - Innovated（创新级：智能化与业务价值导向）

1. People & Culture（人员与文化）

• Experimentation Culture：鼓励低成本试错，将技术创新视为核心竞争力。
• Learning Organization：组织具有极强的反脆弱性，能从混沌中学习进化。
• Business Value Alignment：技术目标与业务价值完全对齐。

2. Process & Practice（流程与实践）

• Chaos Engineering：主动引入故障（混沌工程），验证系统的弹性和可靠性。
• Value Stream Management (VSM)：全链路价值流管理，消除所有非增值环节。
• NoOps Aspirations：通过极致自动化实现极低运维感知。

3. Tooling & Technology（工具与技术）

• AIOps & Predictive Insights：利用 AI 进行故障预测、自动根因分析和自动愈合。
• AI-Assisted Coding：广泛利用 AI 辅助编码（Copilot）和生成测试用例。
• GreenOps：关注计算能效与碳排放，进行可持续的技术治理。

DORA

DORA（DevOps Research and Assessment，现已被 Google 收购）的评估体系是目前全球公认的 DevOps 效能“黄金标准”。

与传统的通过代码行数、工时或 Bug 数量来考核不同，DORA 通过 6 年以上、涵盖数万名专业人士 的调研数据证明：软件交付效能（Software Delivery Performance）与组织效能（Organization Performance）之间存在直接的正相关关系。

DORA 的核心逻辑在于平衡 “速度（Speed）” 与 “稳定性（Stability）”。它通过 4 个关键指标（Four Keys） 来评估和区分团队的效能等级。

一、 核心评估指标：四大关键指标 (The Four Keys)

DORA 将效能分为两个维度：吞吐量（速度） 和 稳定性（质量）。

1. 速度指标 (Velocity Metrics) - 衡量交付有多快

• 部署频率 (Deployment Frequency, DF)
  • 定义：代码成功部署到生产环境（Production）的频率。
  • 意义：反映了团队响应业务需求的能力。批量越小，频率越高，反馈越快。
• 变更前置时间 (Lead Time for Changes, LT)
  • 定义：从代码提交（Commit）到代码成功运行在生产环境的时间。
  • 意义：反映了交付管道（Pipeline）的效率和摩擦力。时间越短，说明自动化程度越高，等待时间越少。

2. 稳定性指标 (Stability Metrics) - 衡量服务有多稳

• 服务恢复时间 (Time to Restore Service, MTTR)
  • 定义：当生产环境发生故障（如服务不可用）时，恢复服务所需的时间。
  • 意义：反映了团队的监控、响应和修复能力（可观测性、回滚机制等）。
• 变更失败率 (Change Failure Rate, CFR)
  • 定义：导致生产环境服务降级或需要热修复（Hotfix）、回滚的部署占总部署次数的百分比。
  • 意义：反映了代码质量和测试环节的有效性。

二、 如何区分效能等级 (Performance Clusters)

DORA 根据上述四个指标的数据表现，将全球的 IT 团队划分为四个等级：精英 (Elite)、高 (High)、中 (Medium)、低 (Low)。

(注：具体阈值每年根据全球调研数据会有微调，以下为典型的分层标准)

关键洞察：

1. 速度与稳定性不冲突：DORA 数据常年显示，精英团队在速度快的同时，稳定性也更高。这打破了传统认知中的“慢工出细活”或“求快必乱”。精英团队通过自动化测试、小批量发布和快速回滚，实现了又快又稳。
2. 差距巨大：精英团队的部署频率通常是低绩效团队的 973 倍，变更前置时间快 6570 倍，且恢复服务的速度快 6570 倍（基于 2021 年报告数据）。

三、 第五个指标：可靠性 (Reliability)

在 2021 年之后的报告中，DORA 引入了第五个指标，以补充单纯的“交付”视角，转向“运营”视角。

• 运营性能 (Operational Performance)：
  • 定义：服务是否满足了用户设定的可靠性目标（如 SLO/SLA）。
  • 评估方式：虽然团队交付很快，但如果用户经常遇到服务不可用或延迟，那么效能依然是不合格的。这个指标强调了交付不是终点，运行才是。

四、 如何正确使用 DORA 指标？

1. 避免“古德哈特定律” (Goodhart’s Law)：
   • 一旦指标变成了管理层的考核目标（KPI），它就不再是一个好的指标。
   • 错误做法：为了降低“变更失败率”，管理者禁止团队进行变更，或者为了提高“部署频率”，团队就在生产环境刷无意义的空发布。
2. 关注趋势而非绝对值：
   • DORA 的价值在于自我对标。看团队这个月是否比上个月“前置时间”缩短了？“恢复时间”变快了？
3. 识别瓶颈：
   • 如果部署频率低但失败率也低 -> 说明需要加强自动化部署能力，减小批次。
   • 如果部署频率高但失败率极高 -> 说明测试环节薄弱，需要加强自动化测试和代码审查。