DevOps之初探

1. 我最喜欢的DevOps模式一

通常，在软件开发项目中，开发都会用完所有计划中的时间用于开发功能。这样会导致无法充分解决IT运维的问题，于是他们就在定义，创建和测试数据库、操作系统、网络、虚拟化等代码依赖的方面直接抄捷径，以此节省时间。

所以这就是开发和IT运维以及次优结果之间的永恒的紧张关系的主要原因。后果很严重，比如不适当的定义和指定环境、无法重部署、代码和环境的不兼容等等。

在这种模式下，我们会再开发过程的早期提出环境要求，并强制代码和环境必须被一起测试的策略，一旦使用敏捷开发方法，我们可以做到非常简洁和优雅。

按敏捷的要求，在每个迭代结束后，我们就会发布能运行且可被部署的代码，通常时间为两周。我们将修改敏捷迭代周期策略，不仅仅只交付能运行且可被部署的代码，同时在每个迭代周期的早期，还必须准备好环境用于部署这些代码。

由此，我们不再让IT运维负责创建生产环境的规格要求，取而代之的，建立一个自动化的环境创建流程，这种机制不仅仅只创建生产环境，同时也包括开发和QA环境。

通过使得环境早期即可用，甚至可能早于软件项目开始之前，开发和QA可以在统一和稳定的环境中运行和测试他们的代码，从而控制不同环境之间的差异。

此外，通过保持不同阶段（例如，开发、QA、集成测试、生产）尽可能小的差异，在生产部署之前，我们就能发现并修复代码和环境之间的互操作性问题。

理想情况下，我们建立的部署机制是完全自动化的。可以使用像Shell脚本、Puppet、Chef、Soaris Jumpstart、Redhat Kickstart、Debian Preseed等等很多工具来完成。

2. 我最喜欢的DevOps模式二：

BrowserMob前CEO，Patrick Lightbody曾经说过，“当我们在凌晨2点叫醒开发工程师来解决问题时，缺陷被修复的比以前更快了，这真是一个惊人的反馈回路”，

这是我最喜欢的引用之一。

它强调了问题的关键点，开发一般会在周五的5点提交代码，然后高高兴兴的回家，而IT运维则要花费一整个周末来收拾残局。更糟的是，缺陷和已知错误在生产上不断递归，迫使IT运维不停的救火，而根本原因从不被修复，造成这种现象的原因就是开发总是关注开发新功能。

第二种模式的一个重要要素就是缩短和放大反馈回路，使得开发更贴近客户体验(包括IT运维和最终用户)

注意这里的对称性，模式一讨论的尽早让环境统一并可用即是将IT运维嵌入到开中发，而模式二则为将开发嵌入到IT运维中。

我们将开发嵌入进IT运维的问题升级链中，可以将他们放在三级支持中，甚至使开发对整个代码的部署成功负责。要么回滚，要么修复缺陷，直到服务恢复。

我们的目标不是让开发取代IT运维，相反，就是想确开发看到他们工作和变更的下游变化，激励他们以IT运维的视角来更快的解决问题，从而达到一个全局的目标。

3. 我最喜欢的DevOps模式三：

在开发和IT运维之间DevOps价值流中，另一个经常发生的问题就是不够规范。这方面的例子是，每个部署都带有其特殊性，因此也使得每次部署后的环境带有特殊性，一旦这样的事情发生，那么这个组织里就没有针对流程配置的控制。

在这种模式下，我们定义可重用且可跨多个项目的部署流程，敏捷方法里有个很简单的解决方案。就是将部署的活动变成一个用户故事。例如，我们为IT运维构建一个可重用的用户故事，叫做“部署到高可用环境”，这个用户故事定义了明确的构建环境的步骤、需要多长时间、需要哪些资源等等。

那么这些信息可以被项目经理用来集成部署内容到项目计划中去。例如，如果我们知道在过去的3年时间里，“部署到高可用环境”用户故事被部署了15次，每次的平均部署时间为3天，加或减一天，那么我们对自己的部署计划将会非常有信心。

此外，我们还可以因部署活动被合适的集成到软件项目中而获得信心。

我们也得认识到有些特定的软件项目要求特别的环境，且其不被IT运维官方支持，我们可以允许这些被生产允许的环境中的例外，但是被IT运维部门外面的人提供支持的。

通过这种方法，我们即获得了环境标准化的好处（比如，减少生产差异，环境更一致，IT运维的支持和维护能力增加），又能再允许的特殊情况下，提供业务需要的灵活性。