DevOps软件架构师行动指南(一)

此为个人《DevOps A Software Architect`s Perspective -Len Bass, etc》阅读笔记。

DevOps 是一项运动，他设想在开发组和运维组之间没有冲突。

1. DevOps 是什么

1.1 定义

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

• 在部署对系统的变更时（一般是代码形式），质量很重要。保证质量的方式：一在把修改后的代码放到生产环境前必须跑通各种自动化测试用例；二在把变更对外开放之前，先让一小部分用户对生产环境的变更进行测试；三对新部署的代码密切监控一段时间。
• 该定义要求交付机制也是高质量的。
• 两个重要时间周期：一开发人员提交代码的时间；二把代码部署到生产环境的时间。
• 该定义以目标为导向：如果一种实践的目的是 减少开发人员从提交代码到生产环境之间的时间，则无论是否包括敏捷方法、工具和协作形式，都是一种DevOps实践。

1.2 DevOps 生命周期过程（波特价值链标注）

1.3 发布过程

向客户发布新系统或现存系统的新版本是软件开发周期中最敏感的步骤。发布过程包括以下步骤：

• 与客户/ 干系人一起定义发布及部署计划并达成一致意见。
• 确保每个发布包包含的一组相关资产与服务组件之间是相互兼容的。
• 确保在整个转换活动期间都能保持发布包及组件的完整性并在配置管理系统中准确记录。
• 确保所有发布包和部署包都能追踪、安装、测试、验证，以及卸载或者在需要时能够_回滚_(卸载新版本，重新部署旧版本)，如代码中存在错误、内存不足或许可证/ 证书过期。

1.4 DevOps 形式

DevOps 有很多种形式，但各种形式都始终贯穿两个主题：自动化 及 开发团队的职责。

1.4.1 自动化

工具可以执行生命周期过程的每一个步骤需要的操作，针对生产环境或者外部操作规格说明检查操作的有效性，把过程中发生的错误报告给相关人员，并保留操作历史，以用于质量控制、报告和审计等目的。

在工具成为一组过程的中心后，就必须对这些工具进行管理。如工具调用可通过脚本、配置变更或运维终端；若是复杂的终端命令，建议把命令的使用脚本化。

工具可以通过规格说明文件进行控制，如Chefcookbooks, Amazon CloudFormation等。
“基础设施即代码（infrastructure-as-code）”

• 脚本、配置文件和规格说明文件必须遵循与应用代码一样的质量控制。
• 脚本和配置文件也应进行版本控制和错误检查。

1.5 DevOps 与敏捷

规范敏捷交付包括三个阶段，DevOps实践会影响这三个阶段：
、

• 在开始阶段，运维人员考虑的内容将为开发人员增加一些需求。发布计划包含了为功能定优先级、开发与运维人员之间的配合、发布调度和确定运维人员为了支持新发布需要做哪些培训。
• 在构造阶段中，DevOps实践的关键是对代码分支的管理、持续