主要SDLC模型
瀑布模型
缺点：不允许返回到以前的开发阶段纠正或实施更改，只能在下一个迭代中进行。
流程：System engineering → Analysis → Design → Code → Testing → Maintenance
迭代/增量模型
适用场景：ERP系统等复杂项目，需求已明确定义、目标确定但未来可能有细微变化的项目。
流程：Initialization → Requirements → Planning → Design → Implementation → Verification → Evaluation → Deploymen
敏捷模型
流行实践方法：Scrum、SAFe、Extreme Programming（XP）、Kanban。
流程：Requirement Analysis → Design Document & Prototype → Development → Testing → If some errors are there, return to previous steps → Next Iteration
devops模型
核心目标：将协同但目标不同的团队聚集，共同实现目标，推动标准化环境、降低新版本失败率、缩短交付时间、加快平均恢复时间
好处：减少交付周期，更快创建新功能，推动创新，提升员工参与度和沟通，确保应用程序更安全稳定；通过CI/CD实现部署频率、交付周期等多方面改进；支持快速实验、原型设计和A/B测试；避免技术债务
流程：PLAN → CODE → BUILD → TEST → RELEASE → DEPLOY → OPERATE → MONITOR
| 对比维度 | 传统开发模式（瀑布式） | DevOps模式 |
|---|---|---|
| 团队协作 | 开发、运维、测试割裂，沟通成本高 | 跨团队协同，共享责任，沟通高效 |
| 开发周期 | 周期长，迭代慢，难以快速响应需求 | 小步迭代，周期短，快速响应需求变化 |
| 部署频率 | 低，通常以周/月为单位，风险集中 | 高，通常以天/小时为单位，风险分散 |
| 问题修复 | 响应慢，需等待下一阶段，修复成本高 | 响应快，实时反馈，修复成本低 |
| 自动化程度 | 低，大量手动操作，易出错 | 高，全流程自动化，稳定性高 |
| 风险控制 | 后期暴露风险，难以提前预判 | 全流程持续监控，风险提前识别与控制 |
devops开发流程
DEV 开发侧流程
| 阶段 | 核心目标 | 图中对应工具 / 说明 |
|---|---|---|
| Plan（计划） | 开发团队根据客户的目标制定开发计划 | 需求文档、任务规划 |
| Code（编码） | 根据PLAN开始编码过程，需要将不同版本的代码存储在一个库中。 | Git（代码版本控制） |
| Build（构建） | 编码完成后，需要将代码构建并且运行 | Maven/Gradle（Java 项目构建工具） |
| Test（测试） | 成功构建项目后，需要测试代码是否存在BUG或错误 | Selenium（自动化测试工具），图中 "瓢虫" 代表缺陷 / BUG 检测 |
OPS 运维侧流程
| 阶段 | 核心目标 | 图中对应工具 / 说明 |
|---|---|---|
| Deploy（部署） | 将应用发布到目标环境 | 火箭图标代表发布动作 |
| Operate（运维） | 保障应用稳定运行 | Ansible（自动化运维）、Docker（容器化）、Kubernetes（容器编排） |
| Monitor（监控） | 实时监控系统状态，收集反馈 | Nagios（监控告警工具） |
Jenkins 是整个流程的 "自动化引擎"，通过 CI/CD（持续集成 / 持续部署）串联起开发与运维，实现从代码提交到部署的全流程自动化
优势：
DevOps 自动化流程可以比人员更快，更可靠地执行重复操作。对于组织而言，让开发人员或其他人员整天构建和部署代码既不可行，也无济于事。使这些重复性任务自动化可以使开发人员腾出精力去做自己最擅长的工作
这样做是允许在几分钟之内构建和部署代码，这仅受组织选择管理其DevOps管道的方式的限制。这意味着从开发功能或错误修正到向最终用户提供更好的体验之间的时间可以大大缩短，从而使用户更加满意。
它还创建了更好的反馈循环。新功能越早交付给用户，组织就越早可以收集反馈和指标并深入了解用户对其产品的喜好。这使组织保持敏捷并为创新提供了更好的环境
devops生命周期：
产品主要包括策划，研发，运营，推出
项目：立项，执行，完工
敏捷、持续集成、持续部署、持续交付都是 DevOps 的一个局部的阶段
三大原则
流动原则
可视化工作流（看板管理）
限制在制品数量（WIP 限制）
自动化流水线（CI/CD）
减少交接和手动操作
反馈原则
全链路监控与告警（Nagios 这类工具）
测试左移（单元测试、自动化测试提前）
生产环境的快速反馈（用户反馈、性能数据）
故障快速定位与恢复
持续学习与实验原则
故障复盘（ blameless post-mortem，不指责复盘）
安全实验环境（灰度发布、金丝雀发布）
持续改进流程和工具
知识共享与跨职能协作
DevOps与CICD
定义：
CICD:实践方法包括持续集成，持续交付，持续部署， 通过自动化实现高频度向客户交付应用
devops：目标通常是在开发环境中自动化CI/CD
区别：
| 维度 | DevOps | CICD |
|---|---|---|
| 核心定位 | 文化，强调协作与共同目标 | 实践方法，强调流程自动化 |
| 关注重点 | 文化、角色、协作 | 流程、工具、自动化 |
| 目标 | 改善客户体验和底线结果，实现持续交付 | 高频度、高质量交付应用 |
| 关系 | CICD是DevOps的关键实践和落地手段 | 是DevOps团队的重要目标之一 |
持续集成（CI）：开发人员的自动化流程，实现开发工作流程自动化，包括代码提交、构建、单元测试、集成测试等。
持续交付：开发人员的更改自动进行错误测试并上传到存储库（如GitHub或Image Registry），由运维团队部署到生产环境；解决开发和运维沟通问题，减少部署工作量。
持续部署：自动将开发人员的更改从存储库发布到生产环境；以持续交付为前提，解决手动流程导致的交付速度慢、运维超负荷问题
核心原则：
协作与沟通: 开发、运维、测试等团队的部门墙，建立跨职能协作机制，通过常态化沟通同步需求、问题和进度，避免信息断层
自动化一切可自动化的流程: 重复、繁琐的手动操作（如代码构建、测试、部署、配置管理等）转化为自动化流程，减少人为失误，提升效率
持续改进: 以软件交付全流程的性能数据为依据，持续优化流程、工具和协作模式
重视反馈： 快速收集软件交付各环节的信息，及时迭代优化产品和流程
安全集成: 安全校验融入DevOps全流程，而非在交付后期介入
Devops与传统开发运维模式的区别：
| 对比维度 | 传统模式 | DevOps模式 |
|---|---|---|
| 团队协作 | 开发、运维、测试分工明确，沟通较少，存在明显部门墙 | 跨职能团队协作，角色融合，信息共享顺畅 |
| 交付周期 | 周期长，通常以月/季度为单位，迭代缓慢 | 周期短，以周/天为单位，支持快速迭代 |
| 部署方式 | 手动部署为主，步骤繁琐，易出错 | 全流程自动化部署，高效且稳定 |
| 问题响应 | 故障发现滞后，排查周期长，修复效率低 | 实时监控，快速发现问题，跨团队协同修复 |
| 安全保障 | 交付后期进行安全测试，易出现安全漏洞导致返工 | 安全集成到全流程，自动化安全校验，提前规避风险 |
| 文档管理 | 依赖人工编写文档，更新不及时，易出现文档与实际不符 | 自动化生成文档，实时同步流程变更，保证文档准确性 |
核心工作流程
DevOps工作流程围绕"持续集成（CI）-持续交付（CD）-持续部署（CD）"核心链路展开，结合协作、自动化和监控反馈，形成完整的软件交付闭环
devops核心优势
提升交付效率：自动化流程减少手动操作，缩短软件交付周期，支持快速迭代和市场响应。
优化交付质量：自动化测试、安全扫描提前发现问题，减少线上故障，提升用户体验。
降低运维成本：批量自动化管理减少重复劳动，跨团队协作减少沟通成本，故障快速修复降低业务损失。
增强团队协作：打破部门墙，提升团队凝聚力，让开发、运维等角色共同为产品质量和交付效率负责