阿里云云原生 DevOps

第 5 章结尾留了一个问题：技术栈都到位了，团队怎么保证每一次上线都又快又稳？这一章是因果链的最后一环——DevOps。

企业开发过程的困境

传统开发流程里，需求、开发、测试、运维往往是四个割裂的环节，各管一段，中间靠人工交接。这种割裂会带来几个典型问题：

环境不一致导致的"甩锅"——开发说"我这里没问题"，测试说"测试环境跑得好好的"，运维说"生产环境就是不行"，谁都没说错，但问题没人真正负责
发布流程手工、串行，一次上线要人工执行一长串步骤，容易出错，出了问题回滚也麻烦
反馈链条太长：代码写完到真正在生产环境验证效果，中间隔着好几个环节、好几天甚至好几周，出问题很晚才能发现

DevOps 是什么

DevOps（Development + Operations）不是某一个工具，是一种打破"开发"和"运维"之间壁垒的文化和方法论：让写代码的人也对代码上线后跑得好不好负责，用自动化把"改代码 → 测试 → 上线 → 观察反馈"这条链路串成一个持续、快速的闭环。目标很直接：更快、更频繁、更可靠地交付软件。

DevOps 的核心组成：CI/CD

DevOps 落地到具体工程实践，核心是一条流水线（Pipeline），通常拆成两段：

CI（持续集成，Continuous Integration）：每次代码提交都自动触发构建和测试，尽早发现问题——不是等攒够一大批改动才一起测，而是小步快跑、随时验证
CD（持续交付 / 持续部署，Continuous Delivery / Deployment）：通过 CI 验证的代码，随时处于可发布状态（持续交付，中间可能保留人工审核关卡），或者直接自动部署到生产环境（持续部署，全自动无人工介入）

这条流水线把"改代码"到"上线"之间原本需要人工层层审批、手动执行的步骤，变成了一条自动化、可重复、可回滚的链路。

云原生时代，DevOps 面临新的诉求

前面几章讲的容器、Kubernetes、微服务，给 DevOps 提出了新的要求：

应用从几个大单体拆成几百个微服务之后，每个服务都要有自己的 CI/CD 流水线，流水线数量和管理复杂度一下暴增
容器化之后，流水线不再只是"构建代码"，还要把"构建镜像、扫描镜像安全、推送到仓库"（呼应第 3 章的 ACR）也纳入进来
Kubernetes 的声明式 API 天然适合和 CD 结合——用 Git 仓库里的 YAML 作为集群状态的唯一事实来源，一旦 YAML 变化就自动同步到集群，这个理念通常被称为 GitOps

简单说：云原生时代的 DevOps，流水线要覆盖"代码 → 镜像 → Kubernetes 部署"这条更长的全链路，而不只是传统的"代码 → 服务器部署"。

为什么需要"一站式"DevOps 平台

如果需求管理用一个工具、代码托管用另一个工具、CI/CD 又是第三个工具，团队协作的信息还是散落在各处，交接环节并没有真正消失，只是从"人工交接"变成了"在不同工具之间来回切换"。一站式平台把需求、代码、构建、测试、部署、度量这几个环节串在同一个系统里，才能真正形成一个完整、可追溯的闭环。

云效：阿里内部研发协同经验的产品化

和第 4 章 EDAS 一样，云效也不是从零设计的产品，而是阿里巴巴内部数万研发人员每天在用的同一套系统，产品化之后对外开放。

云效覆盖研发全生命周期的产品矩阵，比较核心的几个：

Projex（项目协作）：需求和任务管理，和钉钉组织打通
Codeup（代码管理）：企业级代码托管，配套代码评审、代码扫描、质量检测
Flow（流水线）：自动化的 CI/CD 交付流水线，持续集成、持续验证、持续发布
Testhub（测试管理）：测试用例和测试流程管理
Packages（制品仓库）：构建产出的制品统一存放和分发
Insight（效能洞察）：研发过程的度量数据，帮团队看清楚流水线卡在哪个环节

这些产品串起来，覆盖的正是前面说的"需求 → 代码 → 构建 → 测试 → 制品 → 部署 → 度量"这条完整链路，并且和阿里云其他产品（ACR 镜像仓库、ACK 容器集群、云监控）深度集成，不用自己再拼凑一套工具链。

费用：小于 30 人的研发团队可以免费使用云效全部产品功能（小微企业扶持套餐）。

整个合集的收尾

写到这里，第 1 章推的那条因果链正好完整地走了一遍：环境不一致 → 容器 → 编排 → 微服务 → Mesh 化 → Serverless → 消息队列解耦 → 限流降级和混沌工程 → 可观测性 → 最后是 DevOps 把整条交付链路本身也变成自动化的工程实践。

云厂商认证考的是产品名字，但记产品名字最省力的方式不是死记硬背，而是知道每一个产品对应因果链上的哪一环、解决的是哪一个具体问题。这十篇笔记从头到尾做的就是这件事。