在上一篇中我们分析了在作坊式团队中的责任重叠，也回顾了 DBA 角色的消融。那么，如今我们讲的 DevOps 又是什么角色的消融呢？
我想你已经猜到了，接下来要消融的角色就是运维人员了。那这次又是什么生产力决定了怎样的生产关系的变化呢？实际上，不止是开发人员的生产力的变化，而是包括了运维的生产力在内一起发生了变化。
DevOps = Dev + Ops
视线再次回到上面的作坊式小团队里。以上面那种手工部署的方式，面对少数几台服务器问题还不明显。当业务扩大，用户量迅速在两个月里从 20 万增长到 50 万，服务器也从 3 台增加到了 10 台，服务器数量上的简单增加就让应用程序的部署和日常维护的工作量徒增，维持手工操作带来的错误和其他不可控风险（如偶见的服务器环境问题）让人越来越不放心了。这时候，运维人员们捡起了多年不写的脚本，开始了服务器环境自动化的过程。
另一头，开发人员开始引入持续集成实践来保障质量：单元测试被引入、发布版本也可以自动化了。当他们开始实施端到端自动化测试的时候，猛然发现对服务器环境的准备过程竟于生产环境如此类似。
在小团队里，开发人员和运维人员就坐在隔壁，类似于上学时同桌的你。他们很快决定通过结对编程的方式高效地整合他们的工作，并继续统一的工具链体系来提供在开发阶段和生产环境的各类需求。包括代码编译、创建新服务器、安装依赖软件、部署（迁移）数据库、多环境配置、自动化测试，以及版本发布流程全部都能够在统一的软件上完成了。
那么，这俩同桌，他们是 Dev，还是 Ops 呢？他们共同宣布了一个新词：DevOps。DevOps 让运维工作展现在 Dev 面前，让他们从更广的视角来看待等整个系统，代码不光要写完，还要能够自动地部署到服务器上。DevOps 不是指运维的消失，而是以更高效和可靠的方式在做运维。
朴实地说，DevOps 包括从代码开发开始，到产品部署到产品环境，再到产品在生产环境的运行期间的监控与维护为止的整个过程。这也是大多数人所理解的 DevOps。如果让一个开发人员来用一个词形容 DevOps 的话，他会说自动化。
DevOps 运动
至此，作坊式团队里的 DevOps 故事也就讲完了。我们看到，小团队在组织层面的包袱很小，而在实践层面也比较容易跟上，往往他们的迫切的问题是开发进度太紧，面对技能不足，却没有足够的时间和机会来夯实技能。要解决这些问题，除了团队客观条件亟待改善之外，还有产品思路和发布规划的优化。这对于小的团队说来，只要决策人下定决心，整个团队成功实践 DevOps 并不困难。
那么，情况在其他团队是怎样的呢？
我们来看一下大一些的团队。由于他们并不缺人手，上述过程就会是另一番景象。再回头看一眼上面的过程，我们不难发现有很多风险很大的地方（例如，开发人员自己编译一个新的程序包，直接放到服务器上），而风险则往往是大团队需要尽力去防止的。于是他们有一系列流程管控措施来防止问题出现在生产环境中。他们有独立的需求分析部门，有严格的代码审查流程（甚至团队），专门的版本发布团队或者负责人，以及话语权很高的质量和风险管理体系。
相比而言，大一些的团队，掌握 DevOps 技能并不成为大的挑战——他们有足够的资源可以在短时间里快速构建这些能力，相反，他们更大的挑战却是在团队结构不变的情况，大家各个“专门”的角色如何向 DevOps 实践看齐，并让这种机制持续下去。这正是 DevOps 运动剑峰所指。《凤凰项目》讲了一个 IT 运维经理临危受命，通过三步工作法，以及同事间协作帮助的情况下，拯救了一家历史悠久的汽车配件制造商的故事。这本书还介绍了开发运维模式的 “三步工作法”。
第一工作法是建立从左到右的高效工作流。典型做法是持续自动化构建、集成和版本部署等。第二工作法是在这个工作流的相反方向，从右向左建立逐级的快速反馈流，及早发现问题，谨防问题向更右边流动。典型做法是高效的代码检查，坚守持续集成纪律，测试前移和自动监控机制等。第三工作法是在组织层面，构建快速试错和学习成长的气氛和文化。典型做法是放权和信任、复盘问题和规模化创新等。
这样看来，DevOps 不再只是开发团队的事了，独角戏是唱不持久的。它一定还还涉及到围绕开发团队的其他角色，如与其他开发团队的关系和与非开发部门的协作等，它还涉及到要构建相适应的企业文化，才能让 DevOps 深化和持久地实践下去。
回顾与讨论
在上一篇，我们主要讲了作坊式团队中角色重叠，这种重叠天然是由于他们的天然压力所决定的。于是，事实中不少小团队长年累月地受困于无尽的需求变更，还没来得及思考怎么打造好团队，团队里的力量就在一次次更新的过程被不断稀释得只剩下一团乱象。但如果团队幸运地遇到了懂得打造工程师文化的负责人，那他们反而更能利用优势，在 DevOps 运动中成为最具活力的那一群。
各司其职并通力协作是大型项目的常见做法，人类的各项大型工程一次次成功地实践着这样的经验。然而在 IT 领域这样的协作模式正在受到挑战。近年来，我们发现不少产品是由只有少数人的团队研发的，在短时间取得了巨大的成功。
芬兰的游戏公司 SuperCell 以 5~7 人小团队的模式在短时间里快速地推出不同的游戏，同时收集用户的喜好信息，据此决定进一步投放到这个游戏的资源。如果受不到欢迎，就快速宣布失败、分析教训并用于新游戏的研发。到他们被腾讯以 86 亿美元被收购时，整个公司不超过 200 人。
这些不断踊现的案例让不少大型团队也在思考如何更好地调整姿态来尝试接受 DevOps，让它成为团队的日常风格，从而提升团队效能。不过，作为一个探索性命题，我们不妨再往深想一层：如果说 DevOps 是 IT 开发团队需要考虑的方法论的话，那么对于大型企业来说，组织层面又该怎么办？
上面提到，DevOps 对企业文化是有所期待的，而文化这种一般变起来是相当难的，对于那些暂时还是业务驱动的企业来说尤其如此。显然，这时候，对于改变企业文化来说，DevOps 作为一种驱动力来说是远远不足的。答案在数字化转型体系可以找到，它正是企业组织整体的敏捷性。在这个体系中，它更将学习型组织设定为企业整体的文化。当然，要在更广的层面去转型，更是谈何容易？不过，换个思路来想，IT 团队的 DevOps 相当于自下而上的转型，而企业层面的数字化主动转型则是由上而下的转型。大胆地想象一下，假如数字化转型获得成功，团队的 DevOps 文化会不会自然踊现呢？
