DevOps 很火。每个人都想要它。持续交付不再仅适用于阁楼办公室里的酷孩子。拥有悠久“硬件”历史的企业，如 Target、ING 和 Cengage Learning，正在转型为软件公司。他们需要能够以更短的交货时间在市场上进行试验。需要强有力的协作和自动化。
快速说明：初创公司，默认情况下您不会执行 DevOps。仅仅因为你们坐在一起并不意味着你们也不必投入创建和维护精益交付周期的艰巨工作。我曾为大型和小型组织工作过，“X 只适用于初创公司”或越来越普遍的“X 只适用于企业”的观点是虚伪的。这是红鲱鱼的定义。
import random
X = random.choice([
'continuous delivery',
'feature flags',
'blameless postmortems',
'config management', # seriously
'and so on'
])
not_for_us(X)
好了，回到企业。在大型组织中采用 DevOps 的一种常见方法是创建 DevOps 计划，这是一个范围狭窄的项目，旨在快速取得成功并在整个组织中建立良好声誉。分享这一成功是一种触发，鼓励其他团队参与进来。
这种举措通常采用 DevOps 或“skunkworks”团队的形式，这是一个由来自其他团队的手工挑选的高绩效人员组成的跨职能团队。这通常很管用。经过一段尴尬的求爱阶段后，团队成员学会了相互依赖，您完成新项目的时间比您预计的要少得多。它正在生产中，客户正在提交功能请求。
这就是问题所在。您现在必须确定 为什么 该团队如此成功。哪些有效，哪些无效，哪些可以转移到其他团队？您可以在 SDLC 中衡量很多东西，但它们永远不会加起来构成整个画面。将这种成功复制到其他项目是很困难的，需要了解并能够分享组织未来愿景的领导者。当这个愿景不明确时，没有人愿意拆散 DevOps/skunkworks 团队。那里发生了一些你不想搞砸的神奇事情。这就是您扼杀 DevOps 计划的方式。
你通过激励最初的一组工程师发挥创造力并尝试新事物来扼杀你的 DevOps 计划，然后通过分配给他们无限期维护他们的创造的任务来摆脱他们的束缚。这些工程师希望在您组织的其他领域进行创新。您的工程师更注重维护。那很好；将他们置于维护角色。
这不仅仅是一个思想练习。我一直在遵循这种模式的臭鼬工厂团队工作。在几个月的维护模式之后我退出了，看不到尽头。我个人认识很多工程师，他们也在同样的情况下跳槽到新的职位。如果有尽头，我们愿意忍受。工程师不是可以随意调动的工作单位。他们会用脚投票。
回顾一下。你如何扼杀你的 DevOps 计划？