DevOps科普

• 一文收录16张DevOps ”拍照神图”
  image
• 致产品经理： 持续集成、持续交付、持续部署和DevOps
• 基于 Docker、Kubernetes 实现高效可靠的规模化 CI/CD 流水线的搭建
• The Product Managers’ Guide to Continuous Delivery and DevOps
• 如何理解持续集成、持续交付、持续部署？
• 持续集成是什么？

背景

业界为什么会出现DevOps ：

• 开发部门的驱动力通常是“频繁交付新特性”
• 运营部门则更关注IT服务的可靠性和IT成本。
• 两者目标的不匹配，在开发与运营部门之间造成了鸿沟，从而减慢了IT交付业务价值的速度。
• 产品管理、研发、运维、运营分属于不同部门，没有有效拉通
• 缺少全功能团队，设计、开发、测试分工过细，导致效率不高
• 规划、开发、运维、运营各自执行自己的流程，缺少业务集成

互联网：

• 交付周期短，快（AWS一周就可以上线交付一个云服务）
• 简约敏捷
• 试错
• 业务竞争力强
• 过程灵活
• 高效运营
• 互联网服务变动频繁，发布周期短，强调早发布、常发布，注重用户反馈

DevOps的目的：

• 促进研发（应用程序/软件工程）、技术运营（运维）部门之间的沟通、协作与整合，持续交付可靠的软件产品和服务。通过快速反馈提升用户体验和研发效率。
• DevOps是以业务驱动的软件交付方法。从需求到交付生产环境，研发与运维间紧密协的文化运动与实践。DevOps文化更注重沟通，快速获得用户反馈提升创新能力。

定义

• DevOps基于敏捷与精益的理念，从业务和整个价值链角度，推动组织优化软件交付方式，从敏捷的开发，走向敏捷的运维和敏捷的业务。DevOps提倡打破孤岛，促进开发和运维之间高度协同，在实现小批量迭代交付、增量式发布、高频率部署、快速闭环反馈的同时，提高生产环境中软件部署及运行的可靠性、稳定性、可伸缩性和安全性。 DevOps通常指软件行业新兴的专业化运动，是一组文化、流程与工具整合后的统称。

• DevOps解决的业务问题：
  DevOps并非目标，而是实现目标的方法，使用DevOps模式可以发现交付通道中的瓶颈，解决监管障碍、流程复杂、技能不足和组织孤岛问题。

实践

通过小批量持续发布、自动化部署、灰度发布、持续监控和数据分析驱动建立交付通道。通过全功能团队、服务化架构和基础设施即代码增强交付通道

将大任务分解为可以迅速完成的较小任务，以服务化/微服务架构模式进行敏捷交付，细粒度持续向生产环境发布。

自动化部署：以完全一致的方式自动化地将应用或服务部署到Dev、SDV、SIT、类生产、生产等各个环境， 并对部署进行自动化验证。

灰度发布：灰度发布是指在新旧版本之间，平滑过渡的一种发布方式。灰度发布可以减少发布后的质量风险，通过分批次发布将风险控制在可接受的范围内。

持续交付流水线

Alpha -> Beta -> Gamma -> Release

需求 -> 设计 -> 开发 -> 构建（自验，UT） -> 部署（集成测试） -> 验证（类生产） -> 部署 -> 运维（灰度发布，运维监控）

互联网金融

客户体验和市场竞争要求系统响应快速，同时还需保持稳定、可靠

• 建设一个平台；工具化、标准化；多种关键技术；全链路贯通；线上协作；流水线；
• 联结三个角色：开发、测试、运维共同协作，提频繁、高效沟通，打破部门墙，构建全功能团队，
• 打通五个环节：打通需求、开发、集成、测试、运维5个环节，实现顺畅流畅、高效运作、高效交付

最终高质量软件的快速交付。

误解

1. 既然有了DevOps平台，就把所有工作全交给DevOps平台的支持团
   队；
   • DevOps的理念是开发自运维，DevOps平台仅仅是提供自运维的工具和环境，实际的
   运维应该由研发团队自己负责；
2. 希望通过界面操作解决所有问题；
   • 最灵活，最强大的工具，应该是命令行脚本，不应该期望将所有功能都通过UI支持，
   可视化的关注点应该是结果和报表；