新聞發布
管理系統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）。
只要這樣的團隊能認識到運維作為一個規則的重要性和軟件開發一樣重要和有價值時，他們將能夠避免許多痛苦和不必要的（以及非?；镜模╁e誤。
