前言

DevOps的概念如今常被提及，特别是随着微服务及容器化技术普及至大众视线后。它到底是一个新技术呢，还是新瓶装旧酒的一种包装？能给我们带来怎么样的改变？本文尝试初浅解答一二。

几个问题

• 什么是DevOps？定义。
• 为什么会出现此概念，解决了什么问题？ 背景。
• 有什么特点（特性）
• 云和DevOps是什么关系
• 微服务和DevOps是什么关系
• 开发人员，运维如何应对DevOps，各自的职责有何变化
• 最佳实践
• 游戏开发与DevOps如何结合

带着这些问题，我研究和翻看了一些文章，尝试给自己解惑。

What is DevOps

目前并无标准之定义。一个不错的基于目标导向的定义是：

DevOps是一套实践方法，在保证高质量的前提下，缩短系统变更从提交到部署至生产环境的时间。

以上可见，它是一种实践方法，没有引入新的技术，更多的是一种思想的提炼升华。关键词：保证高质量, 缩短时间，部署

Why DevOps

在业务日渐复杂的今天，一个需求的上线，经历的环节多且对人的协作提出不少要求。诸如开发与测试的矛盾，开发与运维的沟通。在敏捷开发，快速迭代，小步快步等理念盛行之下，沟通的摩擦成本已经相当之高，而DevOps的出现寄托了缓解此现象的初衷。总结要点是：

• 发布过程复杂，耗时耗力
• 解决开发与运维配合要求高
• 运维人员技能要求太多，可减少对运维能力项依赖

DevOps有什么特点

关于特点，基于其定义的关键字。我们可以预见一些。

高质量的规约下，自动化的工具及脚本便不可少。所以代码的构建与测试，打包部署的自动化等，均有所要求，于是乎，一个持续部署的流水线及其配套的人力物力便延伸开了。

而对于直接影响生产环境的一种实践，其稳定、安全和可追溯等特性，要求流程的可重复，角色权限的可控制，代码及操作的可审计。

在以上一系列的要求下，所以对于DevOps的实践，我们常说的“基础设施即代码（Infrastructure as code）”。即便停起脚本，各种工具，配置等，都将其纳入版本管理范畴。这样同时也减少了协作成本。

DevOps的一个目标是最大程度减少协作，以缩短推向市场的时间。关于协作的定义，牛津英汉词典里有：

对于复杂个体或活动的不同元素进行组织，以便能够有效地一起工作。

太多的人工交流与协作，特别是同步协作（想想前后端联调，想想美术UI资源的等待期），让快速推向市场目标无法实现。

当然对于协作，实践上也讲究成本与收益。

云和DevOps是什么关系

两者并无必然之联系。在传统的机器或虚拟机下，然后可以进行DevOps的实践。 不过云提供的一些能力（特别是快速弹性），在进行DevOps实践时提供了不少便利，主要有：

• 简单创建和切换（迁移）环境的能力。 这让开发，测试和部署的过程简单了许多。
• 轻松创建虚拟机的能力。资源的管理和更新变得简单。
• 数据库的管理。 业务连续性问题。

微服务和DevOps是什么关系

和云一样，微服务和DevOps也无直接关系。不过DevOps的实践其目标缩短变更时间对微服务架构下的业务变更频率有相当之助力。大概微服务的火热，也大大增加了DevOps真实业务实践案例吧。可以说云助力DevOps，而DevOps助力于微服务。

持续部署并减少协作时间，这个理念和微服务一脉相承呢。

开发人员，运维如何应对DevOps，各自的职责有何变化

DevOps的源头，是人们对Dev和Ops两个角色矛盾的一种实践的探索。在DevOps实践下，各角色的职责较原始合作方式确实有较大变化。例如原本需要开发与运维沟通的一些配置修改，甚至数据库建库建表等，在基础设施即代码下，这块原本的运维职责都转移到开发者身上。开发团队需要交付、支持并维护服务。

那么运维童鞋会失业吗？并不会！只是职责变化了。大概新时代运维：P有这些事儿：

• 硬件供给。 各资源的申请协调。
• 软件供给。除开发团队提供的包、镜像外，其它第三方软件。
• IT功能供给
• 业务连续性
  • 恢复点目标(Recovery Point Objective, RPO)。数据丢失最长容忍时间
  • 恢复时间目标(Recovery Time Objective, RTO)。不能提供服务最长容忍时间。
• 监控及容量规划
• 信息安全。代码侧安全由开发团队负责，而基础信息服务之安全，由运维负责。

有一个新的角色介于两者之间，即DevOps工程师，它们负责DevOps工具链中使用的各种工具的维护。或许在不久各实践DevOps的公司陆续会有此岗位出现。话说先前一般运维工程师(Ops)们是属于运营团队，可能负责一个或多个项目，而未来DevOps工程师们，到底是归属哪个组呢？

最佳实践

讲了What和Why，解决了一些疑问，是时候看一下How了。既然是一个实践，那么，总要知道怎么做。

构建与测试，一般需要一条流水线，从代码提交开始触发。

• 持续集成：在一个阶段与下一阶段之间，有一个自动触发器，直到集成测试。
• 持续交付：使用自动触发器，直到预发布系统。
• 持续部署：部署到生产系统也是自动化的。

测试，单元测试与集成测试是高质量的测试基础。关注消费者驱动契约(CDC)。

测试服务的测试用例是由该服务的所有消费者决定且共同拥有的。

即修改了A服务，并不仅是测试A服务本身，所有依赖于A服务的其它服务，都需要触发跑其自动化测试用例（记得google的工程实践亦有如此约定）。

生产环境的发布测试：

• Beta测试
• 金丝雀
• A/B

部署的方案：

• 蓝/绿部署。 成本高
• 滚动升级。 成本低，但是面临多版本的问题

监控的方案：

• 一般统一日志和指标为中心的发布-订阅架构，统一的存储库
• 维度： 故障、性能（延迟/吞吐量/使用率）、容量、交互（响应）、入侵检测

安全的方案：

• CIA要素。机密性，完整性，可用性。 + 不可否认性。
• 身份管理。认证，授权
• 访问控制。
• 深度防御的理论。

游戏开发与DevOps实践

• 游戏架构的耦合度，决定是否便于采用DevOps。若游戏可无状态，可微服务化，那么比较合适采用DevOps。
• 测试的复杂度（需求变更频次）影响DevOps关键点之一的高质量。
• 游戏的更新机制，线上同时多版本运作的可能性，导致需要对DevOps作变通。

以上。本人的一些思考总结，希望让我们对DevOps有一个初步且较完善的认识。

参考

• 《DevOps软件架构师行动指南》 Len Bass等著
• 网上一些文章