一、什么是 DevOps
DevOps = Development (开发) + Operations (运维) ，不是一个工具、不是一门技术、不是一款软件，是一套理念、方法论、工作文化与实践集合 ，目标是打破开发团队和运维团队之间的壁垒 ，实现软件快速、稳定、持续、高质量交付。
传统模式痛点
传统 IT 分工：
- 开发 (Dev)：负责写代码、实现功能，希望快速上新功能、频繁发版
- 运维 (Ops)：负责服务器、部署、稳定性、故障，害怕频繁上线，越稳定越好
双方目标天然冲突：开发要快，运维要稳，形成著名的墙（Wall of Confusion）
开发写完丢给运维，运维部署环境各种报错，互相甩锅、上线慢、故障多、迭代周期长
DevOps 核心思想：开发、测试、运维、产品紧密协作，整条软件交付链路打通，共同对线上业务负责
二、DevOps 核心理念
- 文化 Culture 最重要一层，优先改变思维。打破部门墙、责任共担、不要 "我的代码、你的服务器"，所有人共同对最终线上结果负责。
- 自动化 Automation 尽可能把重复工作交给工具：构建、测试、打包、部署、回滚、监控自动化，减少人工操作失误。
- 精益 Lean 消除流程浪费，缩短交付周期，小步快跑，不要一次性开发超大版本再上线。
- 度量 Measurement 一切可量化：发布频率、故障恢复时长、失败率、部署耗时，用数据驱动改进。
- 共享 Sharing 文档、经验、故障复盘、技术方案全员共享，知识透明。
口诀：文化先行、工具落地、流程保障、数据度量、持续优化
三、DevOps 八大能力域
CALMS 是 DevOps 最经典定义，5 个维度
- C‑Culture 文化：协作、无指责故障复盘、共同担责
- A‑Automation 自动化：交付流水线自动化
- L‑Lean 精益：减少等待、减少批量、小增量交付
- M‑Measurement 度量指标：收集交付、质量、运维数据
- S‑Sharing 共享：信息透明，知识共享
四、DevOps 完整生命周期
很多人误区：DevOps ≠ CI/CD CI/CD 是 DevOps 最重要工具实践，DevOps 范围更大，覆盖软件全生命周期 完整 DevOps 闭环：规划 → 开发 → 构建 → 测试 → 发布 → 部署 → 运维 → 监控 → 反馈，循环迭代
1. 规划 Plan
产品需求拆分、任务排期、迭代规划 工具：Jira、Trello、飞书项目、禅道
DevOps 提倡小需求、短迭代，避免大版本
2. 开发 Develop
程序员编码、版本控制
- 代码管理：Git
- 分支策略：GitFlow / TrunkBased (主干开发，DevOps 最推荐) 主干开发：所有人日常合并到主分支，通过功能开关控制功能是否启用，避免长期独立分支
3. 持续集成 CI
CI：持续集成 含义：多人开发，频繁（每天多次）把自己代码合并到主干仓库，自动做构建 + 单元测试 解决问题：很久才合并一次代码，最后爆发大量代码冲突 流程：代码提交 → 触发流水线 → 拉取代码 → 编译打包 → 自动单元测试 主流 CI 工具：Jenkins、GitLab‑CI、GitHub Actions、Azure DevOps、Tekton
4. 持续测试 CT
自动化测试嵌入流水线
- 单元测试、接口自动化、UI 自动化、性能测试、安全扫描 不等到最后人工全量测试，代码变更就立刻做自动化校验 工具：JUnit、Postman、Selenium、JMeter、SonarQube (代码质量扫描)
5. 持续交付 CD
CD 第一层含义：持续交付 Continuous Delivery 含义：代码经过 CI + 自动化测试之后，随时可以一键部署到生产环境 代码包时刻处于可上线状态，但是否点发布按钮由人手动决定 持续交付 = 产出随时可部署的软件包
6. 持续部署 CD
CD 第二层含义：持续部署 Continuous Deployment 持续交付的进阶版：全部自动化，通过流水线自动部署生产，不需要人工点击 只有质量足够高、自动化测试覆盖率足够高的团队敢做持续部署
关系总结CI < 持续交付 < 持续部署
- CI：代码合并自动构建测试
- 持续交付：包已经准备好，可随时上线（人工确认上线）
- 持续部署：全自动直接上生产
7. 运维 Operate
服务上线之后的日常运维工作 环境管理、配置管理、资源调度 工具：Docker (容器打包)、K8s (Kubernetes 容器编排)、Ansible
8. 持续监控 & 反馈 Continuous Monitoring
线上运行状态实时监控，并且把问题快速反馈回开发 监控 4 大类
- 基础设施监控：CPU、内存、磁盘
- 应用性能监控 APM：接口耗时、异常、报错
- 日志监控：程序日志
- 用户体验监控 工具：Prometheus+Grafana、ELK (Elasticsearch+Logstash+Kibana)、SkyWalking 反馈闭环：线上出问题 → 告警 → 快速定位 → 开发修复 → 再次走流水线发布
五、DevOps 常用技术栈
| 阶段 | 代表工具 |
|---|---|
| 需求 & 项目管理 | Jira、禅道、TAPD |
| 代码仓库 | Git、Gitee、GitLab、GitHub |
| CI 流水线 | Jenkins、GitLab CI、Github Actions |
| 代码质量 | SonarQube |
| 制品仓库 (存包) | Nexus、Harbor (镜像仓库) |
| 容器打包 | Docker |
| 编排部署 | K8s(Kubernetes) |
| 配置管理 | Ansible |
| 监控告警 | Prometheus、Grafana、AlertManager |
| 日志收集 | ELK、Loki |
| APM 链路追踪 | SkyWalking、Pinpoint |
工具只是载体！没有上面 DevOps 文化，买再多工具也做不成 DevOps
六、4 个经典部署策略
用来保障频繁发布同时保证稳定性
- 蓝绿发布 Blue‑Green 线上同时运行两套完全一样环境：蓝 (旧版本)、绿 (新版本)。新版本全部部署在绿环境，验证没问题，流量一次性全部切过去。 优点：回滚极快；缺点：双倍资源成本
- 金丝雀发布（灰度发布 Canary） 先切一小部分流量到新版本，观察一段时间，没问题再逐步全量放量 风险最低，企业最常用
- 滚动发布 Rolling Update 一台一台服务器逐步升级版本，不停机。K8s 默认策略
- 功能开关 Feature Toggle 代码提前合并上线，功能默认关闭；后台配置打开功能，不用重新发版。主干开发必备技术
七、DevOps 和敏捷、SRE 的区别
- 敏捷 Agile ：偏向开发侧，解决需求迭代、快速交付软件；敏捷只管怎么快速做出软件
- DevOps ：打通开发 + 运维整条链路，解决软件怎么稳定快速上线、运维；敏捷是 DevOps 基础
- SRE 站点可靠性工程 ：谷歌提出，偏向运维侧，用软件工程方式做运维，保障线上稳定性；SRE 可以看作 DevOps 运维方向的高级实践
简单一句话：
敏捷：怎么更快做出来 DevOps：怎么做出来并且安全快速上线跑起来 SRE：上线后怎么长期稳定运行
八、DevOps 带来的收益
- 缩短版本交付周期，从按月发布 → 按周 / 按天甚至一天多次发布
- 减少上线故障，自动化提前发现问题
- 故障恢复速度大幅提升
- 开发运维矛盾减少，沟通成本下降
- 线上稳定性提升，业务响应速度变快