新闻发布
管理系统DevOpsGuys 列出了十二个 DevOps 反类型，Jez Humble、Gene Kim、Damon Edwards（以及其他许多人）也说过类似的事情。在这里我增加三个额外的团队结构，关于这三种类型我之前很少见过或听过人提及：全嵌入式/共享运维（Fully Embedded），DevOps 即服务（DevOps-as-a-Service），和临时 DevOps 团队（Temporary DevOps Team）。
DevOps Anti-Types
首先，看待事物的一个有效方式是去观察它不好的一面，这种方式我们称之为“反类型”（在普遍存在的“反模式”之后）。
Anti-Type A：独立谷仓/Dev 和 Ops 分离
这是一种传统的分裂了 Dev 和 Ops 的“抛过墙法”。这意味着 story point（需求点）可以被提前估算（“DONE”意味着功能完整，但是不意味着可以在生产中使用），同时软件的可运维性受损，因为 Devs （开发人员）没有足够的上下文环境去了解功能操作，Ops （运维人员）也没有时间或倾向参与到 Devs 中去共同解决软件上线前的问题。
我们可能都知道这种类型很糟糕，但我认为很多的团队结构实际上更糟糕；至少到目前为止，我们已经意识到这个反类型 A 的问题所在了。
Anti-Type B：独立的 DevOps 谷仓
这种独立的 DevOps 团队通常情况下来自经理或执行官，他们“需要一点 DevOps 的事情”，然后就启动了一个“DevOps 团队”（也有可能有一个人的名字叫做 “DevOp”）。这个 DevOps 的成员会迅速形成另一个团体，让 Dev 和 Ops 分得更开，因为他们要从“无知的 Devs”和“恐龙一样的 Ops”手里保卫自己的角色、技能和工具集。
唯一一个让这种模式可以被理解的情况就是当团队组织为临时的、时间短于十二或十八个月的时候。其目的是让开发人员和运营人员更紧密地联系在一起，并明确授权在这段时间之后，这个团队将变得多余。
Anti-Type C：“我们（开发）不需要 Ops（运维）”
这种团队结构是由开发人员和开发经理的幼稚自大结合而来的，特别是当一些新项目启动的时候。假设 Ops 现在已经成为了过去式 （“我们现在有云了，对吧？），开发人员严重低估运维技能和活动的复杂性及重要性，认为没有这些技能和活动他们仍可以做到，或者只要花费一些空余时间就可以。
当他们的软件变得更复杂，更多的运维活动开始淹没“开发”（即编程）的时候，这种 Anti-Type C 的类型可能终会需要 Type 3（IaaS）或者 Type 4 DevOps topology（DevOps-as-a-Service）。
只要这样的团队能认识到运维作为一个规则的重要性和软件开发一样重要和有价值时，他们将能够避免许多痛苦和不必要的（以及非常基本的）错误。
