第一章 DevOps

世界上最远的距离,不是树与树的距离,

而是同根生长的树枝,却无法在风中相依

——

《世界上最远的距离》 泰戈尔

DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

现状和冲突

传统IT团队按照分工，一般分为产品部或项目部、开发部、质量管理部、运维部。 这是一种很优秀的分工方式，与软件工程的瀑布模型极为吻合，IT团队中的各成员只需要了解各自专业领域的知识技能，通过协作即可完成整个IT项目。但该模式的流水线协作模式逐渐的难以满足IT行业的开发逐渐缩短的迭代效率。不论公司是否承认，只要组织结构还存在这样的职能分工，那么公司仍是一个瀑布流开发模式的组织。

图： 在瀑布模型及该模型下的分工

在瀑布模型中，运维部门承担了软件过程的最后一环，给他们带来了巨大的风险和恐惧：

1. 该软件的体系结构与现有硬件或其他底层平台不吻合。
2. 生产环境的网络安全策略，无法容忍产品的访问策略。
3. 软件需要太多的资源，运维无法满足。
4. 生产环境与开发环境存在不一致，在部署的最后一刻才发现问题所在导致软件无法运行。

当运维环境出现问题时，运维和开发人员之间的冲突和彼此抱怨开始产生，开发人员会重点向产品经理和干系人报告如下问题：

1. 代码在我机器上运行是好好的

2. 我们的代码没问题，都是部署工作做的太糟糕了

3. 这个产品功能我们使用了新技术，但运维说他们无法实现

4. 我需要这样访问数据，但运维说这两个网段不通，不能直接访问

面对这些抱怨和压力，运维和开发产生了一条信息鸿沟。各自的利益诉求开始展现：

冲突：

开发人员和运维人员的冲突，包括业务冲突和软件质量属性冲突。开发人员以业务驱动，响应产品的需求实现和变更，因此他们希望更快的功能发布。而运维人员以非业务驱动，重点考虑软件质量，希望尽可能避免修改，降低软件质量风险。

软件质量属性包括

对于质量属性的要求，在不同的公司和项目中有不同的要求，但相互之间必定存在着相互制约关系，主要体现在：

1. 开发人员不考虑代码对运营环境的影响，在软件设计阶段，不邀请运维人员参与。
2. 开发人员未意识到运营环境的海量数据，上线后导致负载明显上升。运营环境性能明显低于测试环境。
3. 开发人员平常开发过程上使用桌面版操作系统，而运营环境一般使用服务器版本的操作系统。最终移植性上出现问题。
4. 开发人员也许会尝试手工修改系统配置，使代码可用。但最终又未记录到底是什么样的配置或配置组合真正发挥了作用。导致可维护性和移植性问题。
5. 开发人员的开发环境一般为单机或单网段，但生产服务器的网络环境更为复杂。
6. 开发人员使用了某项新技术，或升级了某个服务的版本，但没有评估这次升级会导致服务器或其他产品出现兼容性问题。
7. 运维环境的基础服务过于老旧，由于老服务的限制，无法升级。
8. 运维人员对业务软件内部缺乏了解，难以正确的选择运行环境和发布流程。
9. 开发人员对运营环境缺乏了解，难以正常的对代码进行调整。

而对于这些问题，运维人员往往难以解释，只能在半夜砸着键盘出气，并用24小时全力配合的苦劳精神来配合开发部门，尽力完成发布。

在项目管理上，敏捷软件开发模式的推出，在快速地打破这种严格分工。如何管理运维的执行效率，满足业务迭代需求的快速部署，如何与开发、质量部门合作，成了新的挑战命题。DevOps则希望解决这一个挑战。