DevOps简介

DevOps是一种系统部署方法学，组织可以用它来改善项目部署的深度和质量。

1.1 DevOps原则概述

DevOps包含组织互动和部署工具及实践的变化，主要强调识别和缓解生产力瓶颈。 你也许阅读过Gene Kim所著的《The Phoenix Project》，书中他将DevOps的重要原则归结为DevOps的三条道路：

• 第一条道路：优化从开发到IT运营的工作流。
• 第二条道路：缩短和放大反馈循环。
• 第三条道路：鼓励试验，快速从故障中学习。 这些原则和John Willis及其他DevOps思想领袖所讨论的流行概念CAMS（Culture、Automation、Metrics、Share）（文化、自动化、计量和共享）相符：
• 文化：故障不应该立即引起过失认定，改变团队成员对部署方法和故障响应的思维方式。
• 自动化：人工方法容易招致故障。使用能够以可靠的方式重复、快速部署环境的工具。
• 计量：监控和分析对于成功必不可少，否则，故障的根源分析就不可能实现。
• 共享：个人/团队独占信息，以维持地位或提升团队依赖性的的“摇滚明星”心态在IT文化中站不住脚。这种心态不会提高生产力，而会降低生产力。

1.2 采用系统思维

系统思维意味着将涉及软件发行版本部署的所有团队当成一个紧密相连的单位，而不是日程安排相互冲突的多个分散团队。 这些团队包括信息安全、运营、开发、质量保证（QA）、产品管理等。

1.2.1 改变团队的互动方式

我们将焦点放在第一件应该做的事：成为开发团队的顾问。和负责定期规划会议的开发团队领导（在敏捷的术语中称为产品负责人和敏捷教练）对话， 要求加入他们的一些回顾会议。

1.2.2 改变基础设施部署方法

数据中心的一些扰人而又常见的现象可能妨碍系统的进展：手工制作的“金映像”、雪花服务器和易碎箱。 管理一堆服务器，手动登入每台服务器，手动安装众多软件，手动修改各种配置文件，导致每台服务器如同雪花一样独特，各服务器配置千差万别难以复制。这就是雪花服务器。

1.2.3 改变软件开发和部署方法

基本要点是，当你将源代码提交到存储库时，CI系统可以修改并设置为自动执行对提交代码的一系列单元测试。在过程结束时，可以构建一个软件包并自动分发给QA团队，实施他们的全面测试。

1.2.4 经常收集和响应有用的系统反馈并作相应调整

系统思维的转变只有在有能力监控和分析系统性能时才能成功。业务的变化节奏似乎是指数级的，消费者对系统响应能力和正常运行时间有更高的预期，被动的问题解决方案不再 成为选择；相反，你的团队必须在问题发生之前预测到它们，以维护系统稳定性。

1.3 增进DevOps知识和技能

一旦在系统思维和改进的系统验证上构建了良好的基础，团队对定期试验新功能就会更加自信。DevOps实践使开发人员能够分阶段逐步地投产各种功能。 这样做的好处之一是，开发人员可以利用针对选择的客户的限定发行版本对新功能进行Beta测试，收集基础设施影响和用户接受度方面的指标。 有效的日志分析方法能够在重大问题蔓延之前发行它们。

1.4 小结

我们已经明白了DevOps的概念和对组织的好处，下面我们将更仔细地研究有助于团队成功的一些工具。