DevOps,并不那么遥远

DevOps, Is Not Far Away

Posted by Robin on December 3, 2017

这篇文章发表于Caicloud官方微信公众号:DevOps,并不那么遥远

DevOps Movement

DevOps最早是在2009年被人提出,不过刚开始只是停留在概念上。虽然愿景非常美好,但是真正实施起来非常困难。随着最近几年微服务、容器等技术的兴起, 使得企业对DevOps的需求更加迫切,实施变得更加容易,DevOps才逐渐被接受和重视。

什么是DevOps

DevOps不是简单地等价于Dev + Ops,很多人根据这个缩写产生误解。软件生命周期的管理,不仅仅只有dev和ops两个阶段,也不只是涉及到开发和运维两种类型 的IT人员。软件生命周期应该包括立项、设计、开发、测试、运维等诸多环节,涉及到参与项目的所有人员,例如:项目经理、产品经理、架构师、开发、测试、运维等。 DevOps 应该是贯穿整个软件生命周期,包括立项、设计、开发、测试、运维等诸多环节。

有人提到 DevOps 的第一反应就是 CI/CD,认为搭建好 CI/CD 流水线就实现了 DevOps。毋庸置疑,CI/CD是DevOps在流程管理方面非常重要的组成部分,没有 CI/CD,DevOps就无从谈起。通过搭建CI/CD流水线,将软件生命周期中最核心的三个环节开发、测试和部署规范化、自动化管理起来,实现持续集成和持续部署, 提高软件开发效率和迭代速度。

还有些人认为 DevOps 就是将很多工具组织起来,实现自动化。DevOps 虽然强调充分利用工具实现自动化,但是更重要的是通过规范的流程,将整个工具链打通, 使各团队间更加高效地协同工作。

DevOps Circle

因此,DevOps 是一种强调产品管理、软件开发和运营专员间沟通协作的软件开发和交付流程。它包括三个要素:文化,流程和工具,只要将这三个要素落实,就能真正地实践 DevOps。

DevOps is a software development and delivery process that emphasizes communication and collaboration between product management, software development, operations professionals and close alignment with business objectives. – Wikipedia

为什么需要 DevOps

随着技术的飞速发展,人们对软件服务的要求越来越高。软件必须快速地迭代,才能满足市场不断变化的需求。软件功能的上线速度,一定程度上决定了市场的机会和份额。 然而,这种快速的迭代和发布,势必会让开发和运维间不可调和的冲突变得更加严峻。微服务将不断地取代传统的巨石应用。以前只需要管理一个软件, 微服务化之后可能就需要同时管理几十甚至上百个微服务应用,每个应用都有自己独立的生命周期,同时又依赖于其他服务。传统的软件生命周期管理方式, 已经无法满足如此复杂的需求,必须借助 DevOps 实现敏捷开发。

既然 DevOps 能够帮我们高效地管理软件生命周期,提高迭代速度和生产效率,那么企业应该如何推行 DevOps 呢?主要有两种策略:

自下而上

先成立一个 DevOps 团队,尝试和积累 DevOps 经验,并评估取得的成果。一旦这个 DevOps 团队积累了一套科学合理的经验, 并通过实践检验过这套经验在所在的企业是行之有效的,就可以把这套经验在部门进行小范围进行推广,并不断地优化和改进这套经验,最终推广和普及到整个企业。 这种是比较推荐而且低成本的方式,更加容易取得成功。

自下而上

公司高层必须意识到 DevOps 的意义及其重要性,并有足够的魄力在整个公司强力推行 DevOps,并且已经有一套适合本公司的 DevOps 实践方案, 才能在整个公司自上而下地执行起来。由于这种方式需要的先决条件比较多,风险和成本都比较高,所以不被推荐。

如何实践 DevOps

打造DevOps团队

组建两个披萨团队。两个披萨团队是亚马逊 CEO 杰夫·贝索斯提出的,要控制团队的规模在两个披萨能够吃饱,否则过高的沟通成本,会严重影响项目的进度。

采用 Sprint 控制迭代速度,一般两周作为一个迭代周期比较合适。Sprint 太长,大家前期的积极性不高,绝大部分工作会拖到 Sprint 快结束的时候完成, 同时也不能建立快速反馈、快速交付的机制;Sprint 太短,很多功能没有足够的时间开发和测试,导致软件质量没办法保证。在 Sprint 开始的时候,制定好计划,细分任务。Sprint 过程中通过 Scrum 不断地反馈、评估和调整,对于可能存在的导致项目延期的风险,及时解决。Sprint 结束之后,需要开 Retrospective 会议进行回顾和总结,好的经验继续保持,不好的地方及时改进。

每天整个团队在一起开 Scrum,简单地反馈一下自己做的事情和进度,使团队所有人都清楚彼此正在做的事情。如果遇到影响项目进度的风险,及时反馈并讨论解决方案。 每个成员必须往全栈工程师的方向努力,提升自己综合能力。DevOps 团队的人数比较少,每个人都要负责比较全面的工作,对日常工作中涉及到的其他领域都要有一定的了解。 这样有两个明显的优势:团队组员之间互为 Backup,尽量减少某个人的突发因素,影响到整个项目的进度;大部分工作不依赖别人就能够完成,一定程度上能够减少沟通成本,提高效率。

构建DevOps文化

  • 共享精神

整个团队、部门、甚至公司,成为一个利益共同体,共享成功,同时共担责任。在 Retrospective 会议的时候,可以分享成功和失败经验,定期举行知识分享, 共同成长,使整个团队的综合实力不断增强。

  • 加强沟通协作

随着软件的要求越来越高,一个系统或软件已经不可能由一个人单独完成,必须涉及到各种不同角色的人来共同完成。那么,其中的沟通和协作就非常重要,往往决定了软件成功与失败。

  • 自动化

一切能够自动化地尽量自动化,最大限度地减少重复劳动,释放人去做更加有创造性的事情。

搭建自动化流程

自动化的软件生命周期的管理,主要可以分为3个阶段:

  • CI(Continuous Integration):持续集成

通过 Webhook 或者定时触发器,自动将软件从源代码构建成可以发布的包或者 Docker 镜像。 一般包括如下流程:代码检出、单元测试、集成测试、静态代码分析、代码覆盖率检查、构建和推送包或者 Docker 镜像。 在这个阶段,可以对各流程的结果进行严格控制,从而保证构建出来的软件的质量。CI 阶段比较强调的是各流程状态、结果的可视化, 例如:流水线执行到哪个阶段、该阶段成功或者失败、查看执行日志、测试报告、静态代码分析和代码覆盖率检查结果。

  • CD(Continuous Delivery):持续交付

经过在一系列环境中的部署和测试,最终将合格的软件版本发布到生产环境中,真正发挥软件的价值。 环境一般包括系统集成测试环境、用户验收测试环境、性能测试环境以及生产环境,根据实际情况,环境的名称不一样,可能叫 Staging 环境、预生产环境等。 CD 阶段存在的挑战,主要包括:不同环境对应的配置如何管理;采用何种发布策略,保证线上服务不中断的情况下稳定发布; 如果发布失败,如何进行回滚;微服务间如何进行注册和发现。

  • CO (Continuous Operation):持续运营

通过平台提供的日志收集、监控告警、自动伸缩、健康检查等功能,保证线上环境的安全、可靠运行,达到我们设定的 SLA(ServiceLevel Agreement)。 CO 相对于 CI 和 CD,是比较新的概念,通过对线上系统的监控,达到服务的自治和自愈的目标。它需要完善的平台来支撑,因此运维人员需要向 SRE 的方向发展, 最终摆脱“背锅侠”的命运。

如何评估 DevOps 效果

DevOps 的目标是通过定义软件的开发和交付流程来实现软件的价值,因此,可以通过如下指标来衡量 DevOps 效果:

  • 部署频率: 能够由原来的几个月或者几周部署一次,缩短到几天甚至几小时部署一次。
  • 部署成功率: 追求快速部署的同时,也要保证部署的质量。可能九十九次成功发布带来的收益,都弥补不了一次失败发布带来的损失。
  • 问题修复时间: 用户反馈的系统缺陷,多长时间能够被解决。
  • 业务交付时间: 市场或者用户提出的需求,多长时间能够被满足。
  • 自动化率: 被自动化的工作占所有工作的比率。自动化不仅能提高效率,而且能最大限度地避免人为错误带来的损失。
  • 故障恢复时间: 系统出现问题,多长时间能够响应和恢复。

当 DevOps 遇上 Docker

DevOps 的工具链非常丰富,仅 Jenkins 就提供了 1000 多种插件,基本满足各种各样的需求。在众多工具中,不得不提一下最近几年红的发紫 Docker。 Docker 提出的口号是“Build,Ship,Run”,它解决的软件生命周期的这三个阶段,跟 DevOps 中 CI/CD 的目标不谋而合。 Docker 技术的出现,能够帮 DevOps 完美地解决如下问题:

  • 环境问题: Docker 能够非常快速、廉价提供环境,这些环境占用的资源非常少,而且用完之后可以立即释放资源。使 DevOps 再也不用为各种构建环境、测试环境发愁了。
  • 环境一致性问题: Docker 镜像包含了软件运行所需要的所有信息,任何时候、任何地方都可以通过同一 Image 快速启动完全相同的的容器。DevOps 过程中,能够彻底摆脱环境不一致问题带来的困扰。
  • 交付物: Docker 提供了简单、标准的统一交付物。Docker Image 作为唯一的交付物,方便、快捷地在流水线的各个阶段间流转,避免了语言、框架、不规范导等因素导致交付物的多样性。
  • 容器生态圈: 除了上面 Docker 自身的优势以外,Docker 还带来了一个庞大的容器生态圈。基于这个生态圈提供的容器引擎、编排、镜像仓库、监控等丰富工具,DevOps 实践起来会更加地游刃有余。

如果说几年前,DevOps 听上去非常美好,但是离我们非常遥远的话,那么现在是实践 DevOps 的最佳时机。一方面快速的市场变化,迫使我们转向敏捷开发模式;另一方面容器技术的快速发展,又帮我们扫清了 DevOps 的各种障碍。所以,本着精益思想,搭上容器这股热潮,DevOps 就并不那么遥远。

References