DevOps在软件开发和交付领域非常流行，许多团队通过DevOps取得了瞩目的成功。但一些DevOps的实践和技术还不够成熟，很多公司还没能从基础的小型团队敏捷开发向更复杂的IT整体架构进军。

团队享受着DevOps带来的成功喜悦，同时也发现自己受到了高层的关注——那感觉真棒！问题是，接下来呢？领导们想要更多。在大型企业的DevOps团队如何把在试验项目上的成功，复制到公司整个业务呢？

当你尝试推广DevOps的时候，有几个步骤可以帮助扩大DevOps的规模。

扩大规模的第一步

当企业的DevOps尝试获得成功时，不难想象负责DevOps的人员会被各种新项目、应用和基础设施的请求所淹没。每天时间有限，现有的员工不可能胜任更多工作，唯一的选择是让更多人具备DevOps的能力，但是如何做呢？

把每个项目的新工作分给新团队并不容易。当公司计划把DevOps扩展到更多更大的项目时，第一步最好是创建一个可以被多个团队复制的流程。另一个关键点是确保早期的主动权，明确节省时间、节约费用和业务结果等方面的优势。一旦开始扩大规模，团队就可以对于给定的措施有着清晰的预期。

一些企业从移动软件团队或者Web运维工作室借鉴取经而获得成功，实现了快速部署、效率管理基础设施。无论是敏捷开发还是探索DevOps，最好都从正规化和标准化开始。

得到上层领导的支持

让DevOps切实可行地在企业推广需要领导层的大力支持，包括C级别的高管们。因为这个级别牵扯到了组织的高层，相比十几年前甚至最近的大型公司，DevOps在企业软件部署领域会引发一系列巨变。

DevOps自身代表了这种变化。幸运的是，我们已经看到了高层对于DevOps的认可，一些DevOps技术和方法论的最大拥护者中也有C级别的高管们。如果缺失了领导层和核心IT的支持，DevOps的推广会非常困难。如果所有的利益相关者成果共享、共同努力，那么这些变化就更容易接受。

比如对开发者、IT运维、业务线的领导以及其他DevOps相关人员进行奖金奖励。企业也非常愿意有一个优秀技术中心、技术审核平台，或者类似内部汇报新技术方法的部门。这是一个发现DevOps拥护者的地方，他们通常会在实现和扩展DevOps的过程中起领导作用。

注意，DevOps的改变对于软件开发者来说并没有那么明显，他们已经谙熟敏捷开发、精益实践、开源软件、透明化和合作机制等等。但是对于IT运维专业的人员来说改变非常巨大，因为他们更习惯于关注时间和响应之上的稳定性和安全性问题。这是管理层非常重要的另一个原因：让开发和运维之间架起桥梁，让有领导经验的人来主导。否则努力只是白费，DevOps只是空谈。

                                                

“利益相关者”的扩展

早期DevOps的重点是让开发团队（包括测试人员）与运维人员更有效地协作。但是在软件交付成功之后，DevOps的利益相关者范围扩大到了安全团队、数据库管理和业务总监。这种倾向让DevOps积累越来越多种功能，包括业务的技术和财务方面，这是一种充分理解DevOps的可执行模型。例如安全，一度被认为是与DevOps让代码迅速走向生产的初衷不太一致。但是现在，它已经变成了企业的发展趋势；Heartbleed或者Shellshock这样的安全问题引发了人们对于DevOps的兴趣，因为它表明了快速响应的需求和好处。

在实践层面，短短数小时内升级机器和系统并覆盖，比在半夜时紧张地更新好得多。DevOps与速度有关，但是也关乎准备就绪，无论是下一个移动设备、应用功能、数据设置、安全事件还是其他的开发内容，它都能提前做好准备。

DevOps的工具

过去几年发展出了很多DevOps相关的技术——Puppet, Chef, Docker, Jenkins等等——不同工具在面对DevOps扩展的实践中有着不同的挑战。

指标应该占据计划日程的首位。公司应该按照证实可行的模型来进行DevOps扩展，达到方案中那些重要的目标，获取明确的时间、成本或者其他优势。如果把关注点从发布周期或者节约成本转移到业务结果或者竞争优势上，效益和实践或许会有所改变。当然后者的指标或许更难验证，但也是可以测量的。

一些公司已经通过特殊的工具或者设置实现DevOps标准化，但是多数企业仍然采用混合的技术。考虑到各种工具、设置和实例，DevOps未必是工具链。它更像是一个工具箱，在不同的工作和进程中使用正确的工具，实现自动化和获得效益。

现在企业实现DevOps的主要框架和工具有GitHub、Jenkins、Chef、Puppet、Ansible和Salt。这些工具多数关于简化、自动化以及跟进基础设施管理和软件发布进程。也有一些技术与传统企业IT运维工具和方法交叉，比如ITIL。而最有效实现DevOps的方式是走出传统工具和最佳实践，利用最新的工具和框架。

容器也被证明可以大幅削减开发者的上手时间，提高开发人员的生产力和效率，但是对于IT运维来说也会造成一些困扰。所以任何DevOps技术，企业都应该从小项目着手，证明收益后再逐渐扩大规模。

DevOps与企业文化

扩大DevOps的规模可以更好地实现双赢，但是最好等到初始团队确定其正确性和可行性。其中一个重要的方面是接受和响应失败。DevOps中的失败应该快速发现并解决，而不是打破开发-测试-生产的过程。因此，最好先通过一些失败的演练，这不仅是演示对失败的接受，也展示了最终实现的可能性。

企业应该集中更多的人将现存的应用和服务进行迁移和现代化，转型为“云原生”应用和服务。因此，新技术、新方法和进程必须与现有技术方法进程有所交叉和集成，这也包括人员上的，它可以有效防止开辟DevOps却疏离了现有员工。

下面的图表说明了DevOps要求团队成员扮演不同的角色，同时展示了DevOps的其他利益相关者，从最高管理人员、安全人员到业务团队和部门领导。

DevOps让企业中的个人和团队在软件发布、IT运维上承担的责任更加广泛。随着DevOps实现规模的扩展，企业必须让更多人员和团队努力协作，才能获得速度、效率、响应等收益回报（数人云独家翻译）

DevOps在软件开发和交付领域非常流行，许多团队通过DevOps取得了瞩目的成功。但一些DevOps的实践和技术还不够成熟，很多公司还没能从基础的小型团队敏捷开发向更复杂的IT整体架构进军。

团队享受着DevOps带来的成功喜悦，同时也发现自己受到了高层的关注——那感觉真棒！问题是，接下来呢？领导们想要更多。在大型企业的DevOps团队如何把在试验项目上的成功，复制到公司整个业务呢？

当你尝试推广DevOps的时候，有几个步骤可以帮助扩大DevOps的规模。

扩大规模的第一步

当企业的DevOps尝试获得成功时，不难想象负责DevOps的人员会被各种新项目、应用和基础设施的请求所淹没。每天时间有限，现有的员工不可能胜任更多工作，唯一的选择是让更多人具备DevOps的能力，但是如何做呢？

把每个项目的新工作分给新团队并不容易。当公司计划把DevOps扩展到更多更大的项目时，第一步最好是创建一个可以被多个团队复制的流程。另一个关键点是确保早期的主动权，明确节省时间、节约费用和业务结果等方面的优势。一旦开始扩大规模，团队就可以对于给定的措施有着清晰的预期。

一些企业从移动软件团队或者Web运维工作室借鉴取经而获得成功，实现了快速部署、效率管理基础设施。无论是敏捷开发还是探索DevOps，最好都从正规化和标准化开始。

得到上层领导的支持

让DevOps切实可行地在企业推广需要领导层的大力支持，包括C级别的高管们。因为这个级别牵扯到了组织的高层，相比十几年前甚至最近的大型公司，DevOps在企业软件部署领域会引发一系列巨变。

DevOps自身代表了这种变化。幸运的是，我们已经看到了高层对于DevOps的认可，一些DevOps技术和方法论的最大拥护者中也有C级别的高管们。如果缺失了领导层和核心IT的支持，DevOps的推广会非常困难。如果所有的利益相关者成果共享、共同努力，那么这些变化就更容易接受。

比如对开发者、IT运维、业务线的领导以及其他DevOps相关人员进行奖金奖励。企业也非常愿意有一个优秀技术中心、技术审核平台，或者类似内部汇报新技术方法的部门。这是一个发现DevOps拥护者的地方，他们通常会在实现和扩展DevOps的过程中起领导作用。

注意，DevOps的改变对于软件开发者来说并没有那么明显，他们已经谙熟敏捷开发、精益实践、开源软件、透明化和合作机制等等。但是对于IT运维专业的人员来说改变非常巨大，因为他们更习惯于关注时间和响应之上的稳定性和安全性问题。这是管理层非常重要的另一个原因：让开发和运维之间架起桥梁，让有领导经验的人来主导。否则努力只是白费，DevOps只是空谈。

                                                

“利益相关者”的扩展

早期DevOps的重点是让开发团队（包括测试人员）与运维人员更有效地协作。但是在软件交付成功之后，DevOps的利益相关者范围扩大到了安全团队、数据库管理和业务总监。这种倾向让DevOps积累越来越多种功能，包括业务的技术和财务方面，这是一种充分理解DevOps的可执行模型。例如安全，一度被认为是与DevOps让代码迅速走向生产的初衷不太一致。但是现在，它已经变成了企业的发展趋势；Heartbleed或者Shellshock这样的安全问题引发了人们对于DevOps的兴趣，因为它表明了快速响应的需求和好处。

在实践层面，短短数小时内升级机器和系统并覆盖，比在半夜时紧张地更新好得多。DevOps与速度有关，但是也关乎准备就绪，无论是下一个移动设备、应用功能、数据设置、安全事件还是其他的开发内容，它都能提前做好准备。

DevOps的工具

过去几年发展出了很多DevOps相关的技术——Puppet, Chef, Docker, Jenkins等等——不同工具在面对DevOps扩展的实践中有着不同的挑战。

指标应该占据计划日程的首位。公司应该按照证实可行的模型来进行DevOps扩展，达到方案中那些重要的目标，获取明确的时间、成本或者其他优势。如果把关注点从发布周期或者节约成本转移到业务结果或者竞争优势上，效益和实践或许会有所改变。当然后者的指标或许更难验证，但也是可以测量的。

一些公司已经通过特殊的工具或者设置实现DevOps标准化，但是多数企业仍然采用混合的技术。考虑到各种工具、设置和实例，DevOps未必是工具链。它更像是一个工具箱，在不同的工作和进程中使用正确的工具，实现自动化和获得效益。

现在企业实现DevOps的主要框架和工具有GitHub、Jenkins、Chef、Puppet、Ansible和Salt。这些工具多数关于简化、自动化以及跟进基础设施管理和软件发布进程。也有一些技术与传统企业IT运维工具和方法交叉，比如ITIL。而最有效实现DevOps的方式是走出传统工具和最佳实践，利用最新的工具和框架。

容器也被证明可以大幅削减开发者的上手时间，提高开发人员的生产力和效率，但是对于IT运维来说也会造成一些困扰。所以任何DevOps技术，企业都应该从小项目着手，证明收益后再逐渐扩大规模。

DevOps与企业文化

扩大DevOps的规模可以更好地实现双赢，但是最好等到初始团队确定其正确性和可行性。其中一个重要的方面是接受和响应失败。DevOps中的失败应该快速发现并解决，而不是打破开发-测试-生产的过程。因此，最好先通过一些失败的演练，这不仅是演示对失败的接受，也展示了最终实现的可能性。

企业应该集中更多的人将现存的应用和服务进行迁移和现代化，转型为“云原生”应用和服务。因此，新技术、新方法和进程必须与现有技术方法进程有所交叉和集成，这也包括人员上的，它可以有效防止开辟DevOps却疏离了现有员工。

下面的图表说明了DevOps要求团队成员扮演不同的角色，同时展示了DevOps的其他利益相关者，从最高管理人员、安全人员到业务团队和部门领导。

DevOps让企业中的个人和团队在软件发布、IT运维上承担的责任更加广泛。随着DevOps实现规模的扩展，企业必须让更多人员和团队努力协作，才能获得速度、效率、响应等收益回报（数人云独家翻译）