用工具堆砌的DevOps 幻觉

在第一届 DevOpsDays结束后，DevOps 运动则如星火燎原之势在全球发展开来。随着 DevOps 思想的不断传播，相对的质疑和批评也从未停止过。以至于到今天对于 DevOps 的定义还是众说纷纭，争论不休。

当人们还在争论 DevOps的时候，一批基于敏捷的工程实践和自动化工具带着 DevOps 的标签走入了人们的视野。人们开始认为 DevOps 就是使用这些工具进行自动化。

在早期的 DevOps实践里，开发和运维仍然是分离的。而在很多企业中，运维部门往往是核心部门，评审应用软件的架构设计和上线要求。于是运维部门开始利用这些被称作为“DevOps”的自动化工具管理设备和应用系统。并且将自己相关的实践打赏了“DevOps”的标签传播开来。

于此同时，开发团队开始采用这些工具构建开发用的测试环境。并将运维需求带入了开发流程中，这促进了內建质量。并且利用持续集成服务器（ Continous Integration Serever） 构建持续交付流水线（Continuous delivery pipeline）来可视化软件交付的进度和流程，并通过流水线完成了自动化部署。持续集成服务器连接了开发和运维！

这就是DevOps？

“同床异梦” 的 DevOps

虽然开发团队和运维团队使用的工具变了，然而事情却没有改变：我们仍然能看到”流程结合在一起，但工作目标仍然分离“的两个团队：运维团队仍然牢牢控制着环境，控制着上线标准和上线流程。通过补充更多自动化的测试和验证手段构建更加严格的控制着变更的入口和出口。开发团队仍然不停的为了满足运维团队制定的更加严格的开发规范更加努力的学习各种工具而不断加班。

运维团队仍然不关心开发团队是否需要帮助，开发团队也依然不了解运维团队在做什么。如果没有 DevOps文化的建立，DevOps 仅仅是“通过自动化工具和手段构建的标准流程”而已。

有人甚至开始把这两个团队融合在了一起，变成了一个团队。这在一定程度上缓解了这种矛盾，但是相互指责却并没有让团队凝聚起来更加具有战斗力。而是变成了一个缓慢而争论不休的“Dev和Ops 法庭”：项目经理或者产品经理成为了法官，Dev 和 Ops 则轮番成为原告和被告。

这不是DevOps !

早期的 DevOps文化：信任和尊重

早在 “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr” 的演讲里，就总结出了 Dev 和 Ops 的合作并不能仅仅只有工具，还需要依托文化把某些行为和价值观带到组织内部。这个演讲很有洞见的总结了 Dev 和 Ops的不同观点和思维模式，并从 Dev 和 Ops 的立场分别给出了促进合作的建议。这其中包括：

尊重：避免成见并尊重他人的经验，观点和责任。不要只是一味的拒绝改变，或者把隐藏细节。对于Dev 来说，当和 Ops 交流的时候，则应该告诉代码对 Ops 工作的影响。

信任：对于 Ops 来说，他们应该相信 Dev 新增加的功能。对于 Dev 来说，他们 应该相信 Ops 对基础设施的改动，而且每个人都应该相信对方已经做到最好。 Ops 应该更加透明，不光需要分享运行指南和故障预案，而且还要给 Dev 能够访问机器的权限。

对失败的健康态度：尽管经过层层严格的测试，失败在很多情况下是无法避免的。但如果能像飞机的安全说明那样制定出应急预案，则可以在失败后尽可能的减少损失。

避免指责：指责会把大量的时间花在问题责任的界定而非问题的解决上。对于 Dev 来说，他们需要时刻记得当他们写下的 代码搞砸了之后，总会有 Ops 半夜第一个被叫醒去解决问题。而对于 Ops 来说，需要给当前的状况有建设性的建议和反馈，而不仅仅是抱怨和指责 。

缺失的 DevOps文化建设 —— 用技术升级粉饰制度问题

在很多管理层看来，这些不可思议的做法颠覆了经典的运维管理经验，看起来很美好而往往和现有的制度存在冲突而难以落地。另一方面，工程师却很向往这样一种梦想的工作环境，可以摆脱那些无意义争斗和约束，做真正有意义的事情。

而在一个对变革抵触，对冒险和失败不宽容的环境下，人们往往倾向于不作为，让事情不断变坏。并寄希望于管理人员。而在这种制度下，管理人员往往倾向于做表面文章，相较于改变现有的制度和习惯，购买技术是最方便，效果最明显，风险最低的手段，这会让一切”看起来很美好“。

而在 DevOps改进中，技术往往是最容易的部分，只要找到供应商或解决方案提供商购买就可以了。然而这并没有解决组织的冲突，只是突击的偿还了一部分技术债务而已。技术仍然是被用来粉饰制度问题的“修正液“。

当你有了 DevOps文化的团队，你无需担心技术水平。因为这样的团队会找到最合适的工具完成目标。但是你拥有了 DevOps 的工具，得到的则是提高效率的组织孤岛。

Netflix就是这样一个例子，Netflix是全球十大视频网站中唯一的收费站点。 尽管仍落后于YouTube和Hulu等在线视频巨头，但Netflix的发展速度远远高于竞争对手。此外，Netflix 在微服务和 DevOps 的实践上一直走在业界的前沿。

早在2009年， Netflix的CEO和首席人才官就做了一份127页的PPT，命名为《自由&责任的文化》，这份PPT在网上被查阅超过了600万次，甚至被Facebook公司的COO桑德伯格称为“硅谷最重要的文件”。

这份 PPT说明了一个重要的问题，保持领先的关键不在于你是否拥有先进的技术（很多技术一开始都没有，都是 Netflix 的员工自己创造），最优秀的员工（很多员工都是其它公司的普通员工），而在于你是否拥有可以留住人才和发挥人才价值的制度。

DevOps文化的特征

那么，DevOps的文化看起来应该是什么样的呢？

在 Martin Fowler 的博客上，Rouan Wilsenach则作为一个观察者进一步从外部特征上描述了DevOps文化。他认为DevOps文化的主要特征是"增加了开发和运维的合作"，为了支持这种合作的发生，需要在团队内部的文化和企业组织的文化上进行两方面的调整。如下图所示：

DevOps 文化

责任共担（Shared Responsibility）

从团队内部讲，责任共担而不是 责任划分 的制度会鼓励合作的发生。责任边界清晰，每个人都倾向于做好分内事，而不会关心工作流上游或者是工作流下游里别人的事。

如果开发团队无需对系统上线后的维护和负责人，他们自然对运维没有兴趣。只有让开发团队全程介入整个开发到运维的流程，他们才能对运维的痛点感同身受，在开发过程中加入对运维的考量。此外，开发团队还会从对生产环境的监控中发现新的需求。

如果运维团队分担开发团队的业务目标和责任，他们就会更加理解开发团队对运维的要求并且和开发团队工作的更加紧密。然而在实践中，合作经常起始于 Dev产生的产品运维意识（例如部署和监控），以及在开发过程向运维团队中学习到的实践和自动化工具。

没有组织孤岛（No Silos)

从组织方面讲，在开发和运维之间没有孤岛（No Silos)是组织调整的必要。适当的调整资源的结构，让运维的同事在早期就加入团队并一起工作对构建合作的文化是非常有帮助的。而“交接”和“审批”并不是一个责任共担的工作方式。这不会导致开发团队和运维团队合作，反而会引起指责的文化。所以，开发和运维的团队必须都要对系统变更的成败负责。当然，这无可避免的会导致开发和运维的分界线会越来越模糊。

一个常见的反模式就是“分离的 DevOps 团队”，它一方面创造了新的孤岛，另一方面组织了 DevOps 文化在整个组织内的传播。

自治的团队（Autonomous teams）

组织另外一个极具价值的转变是自治团队 （Autonomous teams），为了让开发团队和运维团队工作的更有效率，需要让团队能够直接处理变革而不是经过错综复杂的决策过程。这需要信任团队，改变风险管理的方式并创建一个对失败相对宽容的环境。

质量內建于开发流程中（building quality into the development process）

DevOps文化的转变带来的一个效果是让新代码进入生产环境更加容易。这使一些未来的 DevOps 文化转变非常必要。为了确保生产环境的变更稳妥。团队需要重视“将质量构建在开发过程中”，这包括很多跨功能的考虑例如性能和安全，持续交付和自我测试的代码会形成一个允许频繁且低风险部署的基础。

反馈（Feedback)

团队也要重视反馈，为了持续改进， Dev和 Ops 就像系统自身一样，紧密的工作在一起。产品环境的监控是一个对于诊断错误和曝光潜在改进的非常有帮助的反馈环。

自动化（Automation）

自动化是 DevOps运动以及促进合作的基石。将测试、配置和部署自动化可以让人们释放出更多的精力，并专注于更有价值的活动，此外还能减少人为失误。而且，自动化脚本和自动化测试可以成为一个活文档，实时跟踪在线系统配置的变更历史。举个例子，通过自动化的服务器配置可以避免在雪花服务器上排除故障和解决问题的工作量浪费。这意味着 Dev 和 Ops 同样可以理解一个服务器的变更是如何配置的了。

营造 DevOps的文化：奖励持续的“改进冒险”

“你无法直接改变文化，但你可以改变行为，行为会变成文化。”

以上一切的发生，都需要从组织内部做出改进。但每个组织有每个组织的特性，改进的方式和方法也不一样。在这样一个变动而开放的时代，没有什么是绝对正确的。每一个改进的尝试都是一场“改进冒险“。

在冒险中，失败并不可怕，可怕的是失去了继续改进的动力。所以我们要鼓励”改进冒险“的行为。

在很多组织中，变革的动力往往来自于上层的压力。而在集权的组织中，一切权力都属于上级管理者。一切权力都属于上级管理者的另外一个意思就是一切责任也都由上级承担。这样会在组织内出现一个“承担高风险和责任”的个人，而非共同分散风险的团队。这是一个脆弱的组织结构，而在这样一个结构下，往往会出现管理人员短视的投机行为，而给整体企业带来更大的风险。

而DevOps不仅仅能通过技术手段降低变更的风险，更是构造一系列的实践和制度来分散这种因高度集中化和集权化所带来的风险。

首先就是要充分给团队授权，让团队能够在有限的风险控制中开展改进。改进是不断小步进行的，如果步子太大，往往适得其反。

其次，就是要有明确的目标和度量方法。“没有度量，改进就无从谈起”，改进之前，一定要设定好度量指标。以跟踪并收集相关的数据。

最后，无论成功还是失败，都需要有产出，让团队通过自我激励的方式持续形成凝聚力。而不要因为一次的失败就全盘否定改进。如同上文提到的，在一个对失败不宽容的文化氛围中。相较于承担风险的改进尝试，人们往往倾向于不作为。

但是，对失败宽容并不意味着不需要为失败承担责任。而是要要从失败中学习到经验，向成功的目标不断的努力。进行下一场“改进冒险”。成功很可能是巧合，但失败必然有原因，避免了那些失败的原因，就有很大的机会走向成功。

营造 DevOps文化的几点提示

文化的改变是困难的，这并不是一个一蹴而就的行为。需要长期不断坚持才会有效果。而带来的收益非常值得。

“文化是你奖励和惩罚的行为”，要对那些符合 DevOps 文化的行为给予奖励，对于那些违反 DevOps 给予一定的警告或处罚。

以好的出发点推测人的行为而不是坏的出发点，这会破坏信任。

经常质疑制度是否有问题，而不是质疑人是否有问题。有问题的行为一定是有问题的制度造成的。

不要吝惜你的表扬和赞美，但请保管好你的刻薄，指责和冷嘲热讽。

对失败的宽容是强调反思和学习，而不是惩罚。

多想想自己能为他人做什么，而不是要求别人做什么。

集体庆祝每一个成功，集体反思每一个失败。（顾宇原创）

用工具堆砌的DevOps 幻觉

在第一届 DevOpsDays结束后，DevOps 运动则如星火燎原之势在全球发展开来。随着 DevOps 思想的不断传播，相对的质疑和批评也从未停止过。以至于到今天对于 DevOps 的定义还是众说纷纭，争论不休。

当人们还在争论 DevOps的时候，一批基于敏捷的工程实践和自动化工具带着 DevOps 的标签走入了人们的视野。人们开始认为 DevOps 就是使用这些工具进行自动化。

在早期的 DevOps实践里，开发和运维仍然是分离的。而在很多企业中，运维部门往往是核心部门，评审应用软件的架构设计和上线要求。于是运维部门开始利用这些被称作为“DevOps”的自动化工具管理设备和应用系统。并且将自己相关的实践打赏了“DevOps”的标签传播开来。

于此同时，开发团队开始采用这些工具构建开发用的测试环境。并将运维需求带入了开发流程中，这促进了內建质量。并且利用持续集成服务器（ Continous Integration Serever） 构建持续交付流水线（Continuous delivery pipeline）来可视化软件交付的进度和流程，并通过流水线完成了自动化部署。持续集成服务器连接了开发和运维！

这就是DevOps？

“同床异梦” 的 DevOps

虽然开发团队和运维团队使用的工具变了，然而事情却没有改变：我们仍然能看到”流程结合在一起，但工作目标仍然分离“的两个团队：运维团队仍然牢牢控制着环境，控制着上线标准和上线流程。通过补充更多自动化的测试和验证手段构建更加严格的控制着变更的入口和出口。开发团队仍然不停的为了满足运维团队制定的更加严格的开发规范更加努力的学习各种工具而不断加班。

运维团队仍然不关心开发团队是否需要帮助，开发团队也依然不了解运维团队在做什么。如果没有 DevOps文化的建立，DevOps 仅仅是“通过自动化工具和手段构建的标准流程”而已。

有人甚至开始把这两个团队融合在了一起，变成了一个团队。这在一定程度上缓解了这种矛盾，但是相互指责却并没有让团队凝聚起来更加具有战斗力。而是变成了一个缓慢而争论不休的“Dev和Ops 法庭”：项目经理或者产品经理成为了法官，Dev 和 Ops 则轮番成为原告和被告。

这不是DevOps !

早期的 DevOps文化：信任和尊重

早在 “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr” 的演讲里，就总结出了 Dev 和 Ops 的合作并不能仅仅只有工具，还需要依托文化把某些行为和价值观带到组织内部。这个演讲很有洞见的总结了 Dev 和 Ops的不同观点和思维模式，并从 Dev 和 Ops 的立场分别给出了促进合作的建议。这其中包括：

尊重：避免成见并尊重他人的经验，观点和责任。不要只是一味的拒绝改变，或者把隐藏细节。对于Dev 来说，当和 Ops 交流的时候，则应该告诉代码对 Ops 工作的影响。

信任：对于 Ops 来说，他们应该相信 Dev 新增加的功能。对于 Dev 来说，他们 应该相信 Ops 对基础设施的改动，而且每个人都应该相信对方已经做到最好。 Ops 应该更加透明，不光需要分享运行指南和故障预案，而且还要给 Dev 能够访问机器的权限。

对失败的健康态度：尽管经过层层严格的测试，失败在很多情况下是无法避免的。但如果能像飞机的安全说明那样制定出应急预案，则可以在失败后尽可能的减少损失。

避免指责：指责会把大量的时间花在问题责任的界定而非问题的解决上。对于 Dev 来说，他们需要时刻记得当他们写下的 代码搞砸了之后，总会有 Ops 半夜第一个被叫醒去解决问题。而对于 Ops 来说，需要给当前的状况有建设性的建议和反馈，而不仅仅是抱怨和指责 。

缺失的 DevOps文化建设 —— 用技术升级粉饰制度问题

在很多管理层看来，这些不可思议的做法颠覆了经典的运维管理经验，看起来很美好而往往和现有的制度存在冲突而难以落地。另一方面，工程师却很向往这样一种梦想的工作环境，可以摆脱那些无意义争斗和约束，做真正有意义的事情。

而在一个对变革抵触，对冒险和失败不宽容的环境下，人们往往倾向于不作为，让事情不断变坏。并寄希望于管理人员。而在这种制度下，管理人员往往倾向于做表面文章，相较于改变现有的制度和习惯，购买技术是最方便，效果最明显，风险最低的手段，这会让一切”看起来很美好“。

而在 DevOps改进中，技术往往是最容易的部分，只要找到供应商或解决方案提供商购买就可以了。然而这并没有解决组织的冲突，只是突击的偿还了一部分技术债务而已。技术仍然是被用来粉饰制度问题的“修正液“。

当你有了 DevOps文化的团队，你无需担心技术水平。因为这样的团队会找到最合适的工具完成目标。但是你拥有了 DevOps 的工具，得到的则是提高效率的组织孤岛。

Netflix就是这样一个例子，Netflix是全球十大视频网站中唯一的收费站点。 尽管仍落后于YouTube和Hulu等在线视频巨头，但Netflix的发展速度远远高于竞争对手。此外，Netflix 在微服务和 DevOps 的实践上一直走在业界的前沿。

早在2009年， Netflix的CEO和首席人才官就做了一份127页的PPT，命名为《自由&责任的文化》，这份PPT在网上被查阅超过了600万次，甚至被Facebook公司的COO桑德伯格称为“硅谷最重要的文件”。

这份 PPT说明了一个重要的问题，保持领先的关键不在于你是否拥有先进的技术（很多技术一开始都没有，都是 Netflix 的员工自己创造），最优秀的员工（很多员工都是其它公司的普通员工），而在于你是否拥有可以留住人才和发挥人才价值的制度。

DevOps文化的特征

那么，DevOps的文化看起来应该是什么样的呢？

在 Martin Fowler 的博客上，Rouan Wilsenach则作为一个观察者进一步从外部特征上描述了DevOps文化。他认为DevOps文化的主要特征是"增加了开发和运维的合作"，为了支持这种合作的发生，需要在团队内部的文化和企业组织的文化上进行两方面的调整。如下图所示：

DevOps 文化

责任共担（Shared Responsibility）

从团队内部讲，责任共担而不是 责任划分 的制度会鼓励合作的发生。责任边界清晰，每个人都倾向于做好分内事，而不会关心工作流上游或者是工作流下游里别人的事。

如果开发团队无需对系统上线后的维护和负责人，他们自然对运维没有兴趣。只有让开发团队全程介入整个开发到运维的流程，他们才能对运维的痛点感同身受，在开发过程中加入对运维的考量。此外，开发团队还会从对生产环境的监控中发现新的需求。

如果运维团队分担开发团队的业务目标和责任，他们就会更加理解开发团队对运维的要求并且和开发团队工作的更加紧密。然而在实践中，合作经常起始于 Dev产生的产品运维意识（例如部署和监控），以及在开发过程向运维团队中学习到的实践和自动化工具。

没有组织孤岛（No Silos)

从组织方面讲，在开发和运维之间没有孤岛（No Silos)是组织调整的必要。适当的调整资源的结构，让运维的同事在早期就加入团队并一起工作对构建合作的文化是非常有帮助的。而“交接”和“审批”并不是一个责任共担的工作方式。这不会导致开发团队和运维团队合作，反而会引起指责的文化。所以，开发和运维的团队必须都要对系统变更的成败负责。当然，这无可避免的会导致开发和运维的分界线会越来越模糊。

一个常见的反模式就是“分离的 DevOps 团队”，它一方面创造了新的孤岛，另一方面组织了 DevOps 文化在整个组织内的传播。

自治的团队（Autonomous teams）

组织另外一个极具价值的转变是自治团队 （Autonomous teams），为了让开发团队和运维团队工作的更有效率，需要让团队能够直接处理变革而不是经过错综复杂的决策过程。这需要信任团队，改变风险管理的方式并创建一个对失败相对宽容的环境。

质量內建于开发流程中（building quality into the development process）

DevOps文化的转变带来的一个效果是让新代码进入生产环境更加容易。这使一些未来的 DevOps 文化转变非常必要。为了确保生产环境的变更稳妥。团队需要重视“将质量构建在开发过程中”，这包括很多跨功能的考虑例如性能和安全，持续交付和自我测试的代码会形成一个允许频繁且低风险部署的基础。

反馈（Feedback)

团队也要重视反馈，为了持续改进， Dev和 Ops 就像系统自身一样，紧密的工作在一起。产品环境的监控是一个对于诊断错误和曝光潜在改进的非常有帮助的反馈环。

自动化（Automation）

自动化是 DevOps运动以及促进合作的基石。将测试、配置和部署自动化可以让人们释放出更多的精力，并专注于更有价值的活动，此外还能减少人为失误。而且，自动化脚本和自动化测试可以成为一个活文档，实时跟踪在线系统配置的变更历史。举个例子，通过自动化的服务器配置可以避免在雪花服务器上排除故障和解决问题的工作量浪费。这意味着 Dev 和 Ops 同样可以理解一个服务器的变更是如何配置的了。

营造 DevOps的文化：奖励持续的“改进冒险”

“你无法直接改变文化，但你可以改变行为，行为会变成文化。”

以上一切的发生，都需要从组织内部做出改进。但每个组织有每个组织的特性，改进的方式和方法也不一样。在这样一个变动而开放的时代，没有什么是绝对正确的。每一个改进的尝试都是一场“改进冒险“。

在冒险中，失败并不可怕，可怕的是失去了继续改进的动力。所以我们要鼓励”改进冒险“的行为。

在很多组织中，变革的动力往往来自于上层的压力。而在集权的组织中，一切权力都属于上级管理者。一切权力都属于上级管理者的另外一个意思就是一切责任也都由上级承担。这样会在组织内出现一个“承担高风险和责任”的个人，而非共同分散风险的团队。这是一个脆弱的组织结构，而在这样一个结构下，往往会出现管理人员短视的投机行为，而给整体企业带来更大的风险。

而DevOps不仅仅能通过技术手段降低变更的风险，更是构造一系列的实践和制度来分散这种因高度集中化和集权化所带来的风险。

首先就是要充分给团队授权，让团队能够在有限的风险控制中开展改进。改进是不断小步进行的，如果步子太大，往往适得其反。

其次，就是要有明确的目标和度量方法。“没有度量，改进就无从谈起”，改进之前，一定要设定好度量指标。以跟踪并收集相关的数据。

最后，无论成功还是失败，都需要有产出，让团队通过自我激励的方式持续形成凝聚力。而不要因为一次的失败就全盘否定改进。如同上文提到的，在一个对失败不宽容的文化氛围中。相较于承担风险的改进尝试，人们往往倾向于不作为。

但是，对失败宽容并不意味着不需要为失败承担责任。而是要要从失败中学习到经验，向成功的目标不断的努力。进行下一场“改进冒险”。成功很可能是巧合，但失败必然有原因，避免了那些失败的原因，就有很大的机会走向成功。

营造 DevOps文化的几点提示

文化的改变是困难的，这并不是一个一蹴而就的行为。需要长期不断坚持才会有效果。而带来的收益非常值得。

“文化是你奖励和惩罚的行为”，要对那些符合 DevOps 文化的行为给予奖励，对于那些违反 DevOps 给予一定的警告或处罚。

以好的出发点推测人的行为而不是坏的出发点，这会破坏信任。

经常质疑制度是否有问题，而不是质疑人是否有问题。有问题的行为一定是有问题的制度造成的。

不要吝惜你的表扬和赞美，但请保管好你的刻薄，指责和冷嘲热讽。

对失败的宽容是强调反思和学习，而不是惩罚。

多想想自己能为他人做什么，而不是要求别人做什么。

集体庆祝每一个成功，集体反思每一个失败。（顾宇原创）