企业官网建设流程全解析

前言

很多人把 CI/CD 和 DevOps 混为一谈，以为做了自动化部署就是"搞 DevOps"。这个理解是不完整的。本篇讲清楚两者的关系——DevOps 是文化理念，CI/CD 是支撑这种理念落地的核心工具实践。理解了这层关系，你才知道为什么有些团队买了 Jenkins 却仍然效率低下。

一、DevOps 的起源与本质

痛点：开发与运维的"墙"

传统组织中，开发（Dev）和运维（Ops）是两个割裂的团队：

开发团队 运维团队 ┌──────────┐ ┌──────────┐ │ 关注功能 │ ──── 扔过墙 ────→ │ 关注稳定 │ │ 追求速度 │ ←── 报故障 ────── │ 追求不挂 │ │ "快上线" │ │ "别搞事" │ └──────────┘ └──────────┘ ↑ ↑ "运维太保守" "开发写的代码太烂"

结果：开发拼命推功能上线，运维拼命挡，互相指责。

DevOps 的定义

DevOps 不是某个工具或技术，而是一套文化理念和实践方法论，核心目标是消除开发与运维之间的隔阂，实现快速、安全的软件交付。

2009年，Flickr 的工程师 John Allspaw 和 Paul Hammond 做了一个演讲 "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr"，被公认为 DevOps 运动的起点。他们的核心观点是：开发和运维不应该是两个对立的团队，而应该是共同为业务目标负责的一个团队。

DevOps 的 CALMS 框架

| 字母 | 含义 | 中文 | 说明 |

|------|------|------|------|

| C | Culture | 文化 | 打破部门墙，共同负责 |

| A | Automation | 自动化 | 重复的事交给机器 |

| L | Lean | 精益 | 减少浪费，小批量快速交付 |

| M | Measurement | 度量 | 用数据驱动决策 |

| S | Sharing | 共享 | 知识、工具、责任共享 |

二、CI/CD 在 DevOps 中的定位

DevOps 实践全景

DevOps 实践体系 ┌──────────────────────────────────────────┐ │ │ │ ┌─────────┐ ┌──────────┐ ┌────────┐ │ │ │ 计划 │ │ 编码 │ │ 构建 │ │ │ │ Plan │→│ Code │→│ Build │ │ │ └─────────┘ └──────────┘ └───┬────┘ │ │ ↓ │ │ ┌─────────┐ ┌──────────┐ ┌────────┐ │ │ │ 监控 │ │ 运维 │ │ 测试 │ │ │ │ Monitor │←│ Operate │←│ Test │ │ │ └─────────┘ └──────────┘ └───┬────┘ │ │ ↓ │ │ ┌─────────┐ ┌──────────┐ ┌────────┐ │ │ │ 反馈 │←│ 部署 │←│ 发布 │ │ │ │ Feedback│ │ Deploy │ │Release │ │ │ └─────────┘ └──────────┘ └────────┘ │ │ │ │ CI/CD 覆盖范围：Build → Test → Release → Deploy └──────────────────────────────────────────┘

CI/CD 是 DevOps 实践中"构建到部署"这段链条的技术实现。它对应 CALMS 中的A（Automation）。

DevOps 各层与工具的对应

| CALMS | 实践领域 | 具体工具/技术 |

|-------|---------|-------------|

| Culture | 跨职能团队 | 无特定工具，靠组织设计 |

| Automation | CI/CD | Jenkins、GitLab CI、GitHub Actions |

| Automation | 基础设施即代码 | Terraform、Ansible、Helm |

| Automation | 容器化 | Docker、Kubernetes |

| Lean | 看板/流程管理 | Jira、Trello、GitLab Issue |

| Measurement | 监控告警 | Prometheus、Grafana |

| Measurement | 日志分析 | ELK、Loki |

| Sharing | 知识管理 | Confluence、Wiki、GitLab Wiki |

| Sharing | 代码共享 | Git、GitLab、GitHub |

**关键认知**：CI/CD 是 DevOps 的必要条件但不是充分条件。做了 CI/CD 不等于做到了 DevOps，但没做 CI/CD 一定没做到 DevOps。

三、文化：DevOps 最难的部分

三个文化转变

1. 共同负责（Shared Responsibility）

传统模式： DevOps 模式： 开发写完代码就交付 开发对代码从编写到运行全权负责 运维负责让代码跑起来 运维提供平台和工具支撑开发自服务 出了问题互相推诿 出了问题一起复盘改进

2. 失败是学习机会（Blameless Culture）

传统模式： DevOps 模式： "谁干的？追责！" "为什么系统允许这个错误发生？" 找到"背锅侠" 改进系统防止再次发生

3. 持续改进（Kaizen）

传统模式： DevOps 模式： "稳定压倒一切，别改" "每周改进一点，积少成多" 大版本大改动 小步快跑，持续优化

文化转变的实操建议

• **组建跨职能团队**：开发+运维+测试在同一个团队中，向同一个目标负责
• **设立无指责复盘（Blameless Postmortem）**：每次事故后，只问"系统怎么改进"，不问"谁的错"
• **度量团队而非个人**：考核MTTR、部署频率、变更失败率，而非个人KPI
• **让开发接触运维**：轮岗、on-call 轮值、让开发参与部署

**踩坑提示**：很多企业把"成立DevOps部门"当成了DevOps转型。实际上DevOps不是成立一个新部门，而是打破部门墙。新设的DevOps部门反而可能变成新的孤岛。

四、度量：DORA 四大指标

Google DORA（DevOps Research and Assessment）团队提出了一套衡量 DevOps 成熟度的标准指标：

| 指标 | 说明 | 精英团队 | 低效团队 |

|------|------|---------|---------|

| 部署频率 | 多久部署一次 | 每天多次 | 每月1-6次 |

| 变更前置时间 | 从提交到上线多久 | <1天 | 1-6个月 |

| 变更失败率 | 部署导致故障的比例 | 0-15% | 16-30% |

| 平均恢复时间 | 故障恢复速度 | <1小时 | >6个月 |

如何落地度量

# GitLab CI 中收集流水线指标 stages: - build - test - deploy - metrics collect-metrics: stage: metrics script: # 记录流水线执行时间 - DURATION=$((CI_PIPELINE_DURATION / 1000)) # 记录部署成功率 - STATUS=$([ "$CI_PIPELINE_SOURCE" = "push" ] && echo "success" || echo "failed") # 推送到 Prometheus Pushgateway - | cat <<EOF | curl --data-binary @- http://pushgateway:9091/metrics/job/cicd cicd_pipeline_duration_seconds{branch="$CI_COMMIT_BRANCH"} $DURATION cicd_pipeline_status{branch="$CI_COMMIT_BRANCH",status="$STATUS"} 1 EOF when: always # 无论成功失败都收集

# Prometheus 告警规则：变更失败率过高 groups: - name: cicd-alerts rules: - alert: HighDeploymentFailureRate expr: | sum(rate(cicd_pipeline_status{status="failed"}[1h])) / sum(rate(cicd_pipeline_status[1h])) > 0.2 for: 30m labels: severity: warning annotations: summary: "部署失败率超过20%"

五、CI/CD 落地 DevOps 的路线图

阶段一：CI 基础（1-3个月）

目标：让代码频繁安全地合并 ↓ 行动： 1. 选择代码托管平台（GitLab/GitHub） 2. 搭建 CI 工具 3. 编写基础流水线（构建+测试） 4. 建立代码审查流程 5. 度量：代码合并频率、构建成功率

阶段二：CD 持续交付（3-6个月）

目标：随时可发布 ↓ 行动： 1. 容器化应用（Docker） 2. 搭建制品仓库 3. 流水线扩展到自动部署测试环境 4. 建立预发环境 5. 度量：变更前置时间、部署到测试环境的耗时

阶段三：DevOps 全面落地（6-12个月）

目标：快速、安全、可度量 ↓ 行动： 1. 基础设施即代码（Terraform + Ansible） 2. 监控告警体系（Prometheus + Grafana） 3. 自动回滚与金丝雀发布 4. 混沌工程与故障演练 5. 度量：DORA 四指标全部达标

六、本篇要点回顾

1. DevOps 是文化理念，CI/CD 是支撑它落地的自动化实践

2. CALMS 框架：文化、自动化、精益、度量、共享

3. 文化转变最关键：共同负责、无指责复盘、持续改进

4. DORA 四指标衡量 DevOps 成熟度：部署频率、前置时间、失败率、恢复时间

5. 落地三阶段：CI 基础 → 持续交付 → DevOps 全面落地

下一篇预告：CI/CD 入门篇收官，接下来进入 Jenkins 实战篇。我们从《环境搭建：从零部署 Jenkins 主从架构》开始，手把手带你搭建第一个 CI/CD 平台。