用工具堆砌的DevOps 幻觉（上）

第一届 DevOpsDays结束后，DevOps 运动则如星火燎原之势在全球发展开来。随着 DevOps 思想的不断传播，相对的质疑和批评也从未停止过。以至于到今天对于 DevOps 的定义还是众说纷纭，争论不休。 当人们还在争论 DevOps的时候，一批基于敏捷的工程实践和自动化工具带着 DevOps 的标签走入了人们的视野。人们开始认为 DevOps 就是使用这些工具进行自动化。

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

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

这就是DevOps ？

目录 [隐藏]

• “同床异梦” 的 DevOps
• 早期的 DevOps文化：信任和尊重
• 缺失的 DevOps文化建设 —— 用技术升级粉饰制度问题
• DevOps文化的特征
• 营造 DevOps的文化：奖励持续的“改进冒险”
• 营造 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文化的主要特征是"增加了开发和运维的合作"，为了支持这种合作的发生，需要在团队内部的文化和企业组织的文化上进行两方面的调整。如下图所示：

file

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

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

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

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

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

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