《DevOps实践指南》：DevOps啊哈时刻：对现状生厌离心 #devops四书

​

一、高绩效组织，不同IT部门合作有更好的技术和人文方法

Gene Kim从1999年以来，一直在研究高绩效技术组织，最早的一个发现是：IT运维、信息安全和开发等不同职能部门之间的良好合作是成功的关键。Gene依然清楚地记得第一次看到由于这些部门目标相左导致恶性循环的场景。

在2009年的Velocity会议上，Gene看到了这样的演讲——介绍了在架构、技术实践和文化方面并举的革新（我们现在称之为DevOps）所产生的惊人效果。当时，他非常兴奋，因为它就是我们一直在寻找的那个更好的方法。

二、自动化的强大力量

Jez Humble在2004年加入了ThoughtWorks咨询公司，参与的第一个项目涉及大约70人。刚开始的时候，工作非常紧张。但几个月后，就从需要花两个星期的手动部署，进步到了只用一个小时的自动化部署。在正常的工作时间段里，我们也可以使用蓝绿部署模式，以毫秒为单位来发布或者回滚业务的应用。

三、运维部署持续改进的力量

Patrick Debois 2007年，我与几个敏捷团队一起，做一个数据中心迁移项目。他们有着高生产力——能够在很短的时间里做很多的工作。

在接下来的一个项目中，开始在运维工作中试验看板方法（Kanban），并看到了团队的显著变化。后来，在2008年的多伦多敏捷大会上，基于这个实践发表了一篇IEEE论文，不过当时它并没有在敏捷社区里引起广泛的共鸣。

在2009年的Velocity会议上，听了John Allspaw和Paul Hammond所分享的“每日10次部署”的演讲以后，确信其他人英雄所见略同。

四、XX即代码的力量

John Willis 2008年，听Luke Kanies（Puppet Labs的创始人）在O'Reilly开源大会的配置管理分会场里介绍了Puppet软件，完全被“基础设施即代码”（infrastructure as code）的理念所折服了。Luke相信运维人员的工作模式可能会变得像开发人员一样，他们必须在源代码控制系统里维护系统的配置，并在工作中使用持续集成/持续交付（CI/CD）的模式。

在2009年O'Reilly的Velocity会议上，听了Andrew Clay Shafer关于敏捷基础设施的演讲。在演讲中，Andrew展示了一幅形象的插图，图中的开发部门和运维部门之间存在一堵高墙，以此隐喻工作被两个部门踢来踢去。他将此称为“混乱之墙”（the wall of confusion）。

这个后来所谓DevOps的东西已然融入了血液。