DevOps - 基础概念梳理

DevOps

DevOps（Development+Operations）强调共同对业务目标负责，以实现用户价值作为唯一的评判标准：保证产品功能及时实现、成功部署和稳定使用；

  • 是一种重视软件开发人员（Dev）和IT运维技术人员（Ops）之间沟通合作的文化、运动或惯例，改善团队之间的协作关系；
  • 是一组过程、方法与系统的统称，包含开发、测试和运维；
  • 用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合；
  • 透过自动化“软件交付”和“架构变更”的流程，使得构建、测试、发布软件能够更加地快捷、频繁和可靠，按时交付软件产品和服务；

总的说来：

  • DevOps 是把人员、流程、产品进行结合，给用户提供持续价值的一个过程，既涉及到人员、流程、工具，也涉及到产品。
  • DevOps 最终目的是给客户提供持续交付的价值，流程包括：产品的规划跟踪、软件开发、构建测试、产品部署、运维、监控和优化。
  • 通常把 DevOps 这些流程通过一个流水线的方式串联起来称为一个 DevOps 的流水线，其核心目标就是持续给用户交付有价值的产品。
  • 创建业务和IT融合的技术架构、实现组织文化转型（良好的跨部门沟通和团队合作的文化氛围），专注于实现业务价值的即时交付

在实际工作中DevOps贯穿了IT价值链的每一个环节的工作流，不仅限于开发和运维之间的协作
DevOps可以理解为由敏捷项目管理、持续交付和运维服务管理这三块组成的一种技术架构

  • 敏捷项目管理部分主要以敏捷项目管理方法论Scrum为主
  • 持续交付部分主要是由自动化工具来实现
  • 运维服务管理部分引用ITIL的基本流程，比如变更管理、配置管理、服务级别管理和业务连续性管理

简而言之，DevOps不仅涉及技术背景，还包括非技术的文化方面。
在软件开发和应用周期中，提供了一个机制或模式来培育“协作”意识，帮助不同角色的成员紧密协作，充分利用现有资源，遵循交付的商业价值，共同对“输出”负责，对质量负责。

DevOps的好处与价值

对于业务与产品而言，DevOps的好处更多基于持续部署与交付。
从组织结构而言，DevOps是部门间沟通协作的一组流程和方法，有助于改善公司组织文化、提高员工的参与感。

  • 代码的提交直接触发：消除等待时间，快速反馈
  • 每个变化对应一个交付管道：使问题定位和调试变得简单
  • 全开发流程高效自动化：稳定，快速，交付结果可预测
  • 持续进行自动化回归测试：提升交付质量
  • 设施共享并按需提供：资源利用最大化

可能的几个关注点

DevOps绝不是推荐一定要在某一方面达到极致，而是从“整体”入手，充分激发“体系”的最佳效率。

  • 虽然真正实现DevOps的成本高昂，但任何时候都是实现DevOps的最佳时机，因为随着业务发展，成本一定是越来越高的；
  • 组织文化上的变革，鼓励不同的个体与部门共同协作，减少“内耗”；
  • 合适的DevOps人员（最起码保证在“向DevOps转换阶段”中，研发人员知晓运维，运维人员了解业务）；
  • 统一的标准、环境、工具、流程，例如：开发/测试环境尽可能地和生产环境保持一致；
  • 自动化和持续交付，简化重复性工作和减少不必要的等待
  • 涉及多个技术支撑：敏捷开发、持续集成&部署、微服务、容器、云环境等；
  • 个体和团队的成效都放在整个产品开发&运维生命周期内来进行评价；

DevOps能力环

DevOps与持续集成、持续交付

DevOps的应用场景往往是一个庞大复杂的背景和流程的场景，大都包含一个持续交付流水线。

  • 开发人员：IDE、Git等开发和编译工具
  • 版本控制系统：分支策略、语义化版本
  • 构建服务器：持续集成、代码质量检查
  • 工件库：存放二进制包
  • 系统的包管理器：编译或测试环境系统上管理二进制包
  • 环境一致性
  • 预发布或生产：预发布环境与生产环境互换（蓝绿发布）
  • 发布管理：在高程度自动化测试的基础上实践自动化或半自动化（人工介入）部署
  • 问题管理系统
  • 。。。。。。
    因此，DevOps 是一个完整的面向IT运维的工作流，以 IT 自动化以及持续集成（CI）、持续部署（CD）为基础，来优化程式开发、测试、系统运维等所有环节。
    DevOps的技术要点由“持续集成/部署“”一线贯穿，主干开发是进行持续集成的前提，自动化以及代码周边集中管理是实施持续集成的必要条件。
    换而言之，DevOps 是持续集成思想的延伸，持续集成/部署是 DevOps 的技术核心，在没有自动化测试、持续集成/部署之下，DevOps就是空中楼阁。

一个完整的过程

  1. 开发团队接到任务，需要完成一个变更
  2. 为了更加顺利地开发，将这个变更分拆为几个小变更
  3. 开发人员在本地开发并且测试，如果使用了测试驱动开发，在编写功能代码之前会先编写测试，然后编写能够让测试通过的实际代码
  4. 开发人员将代码提交到企业内部的Git版本控制系统上
  5. 构建服务器获取这个变更并初始化构建流程，单元测试之后，变更可以被发布到二进制库里
  6. 配置管理系统根据“策略”，在测试环境中安装应用了新的变更
  7. 新安装触发自动化回归测试，测试成功后，质量保证团队开始做人工测试
  8. 人工测试通过后，质量保证团队将“已通过”标识给予这个变革
  9. 变更在预发布环境中进行验收测试
  10. 验收测试完成后，预发布环境被切换成生产环境，而生产环境变为新的预发布环境

典型的CICD流水线过程

  1. 项目开发编写代码，然后把代码推送到 GitLab 里存储，通过 GitLab 的 hook 使 Jenkins 执行一些 CI 的过程，比如做一些单元测试，构建 Docker image
  2. 再把这个 Docker image 调用 helm 部署到开发环境或测试环境
  3. 在测试环境里通过 Jenkins 触发一个集成测试的功能
  4. 完成后就可以把它部署到生产环境
  5. 通过 Kubernetes addon 的方式，把 Prometheus、Grafana 等监控组件部署到集群里，实现一整套从 CI 到 CD 的监控过程

DevOps黄金思维圈

时刻关注正在做什么，尝试识别问题范围，找出解决方案和改善途径。
Why---》How---》What

Why（目的、理念）

持续且快速、可靠的自动交付软件给用户：

  1. 实现价值的持续交付，赢得市场竞争
  2. 提升研发（增值活动）的时间，极大化增值活动产出

How（方法、措施）

  • 建设自动化、可重复、可靠的持续交付流水线（IT服务供应链）
  • 主要包括代码管理、持续集成、自动化测试、自动化部署、基础设施自动化管理等方面的工程能力

What（现象、成果）

  1. 每次代码提交都需要经过流水线验证
  2. 每次部署的版本都经过多环境验证
  3. 部署频率可以得到提升
  4. 周期时间（从代码提交到部署上线）的时间可以到分钟级
  5. 部署失败率低
  6. 部署失败的修复时间短，影响小

初见

一些图示

关系与演进

涉及的工具

DevOps的目标不是单靠一款工具就能实现的。
在各个阶段，每个都有其单独对应的目标。
依赖于组织的选择，有着各种各样的工具可以在相应的背景和趋势下，实现当前业务目标，满足中远期的需求。

posted @ 2018-06-04 23:49  Anliven  阅读(16584)  评论(0)  编辑  收藏  举报