根據一份報告指出，盡管組建DevOps團隊的比例正在上升，但是在企業中是否應該存在DevOps團隊這一問題上依然存在著分歧。有些人擔心會創造更多的“孤島”（Silos），或是認為DevOps是組織中的每個人都應掌握的方法。另有觀點認為，DevOps團隊是一種轉變為新工作方式的有效途徑。
這份報告是今年六月發布的第六次年度“DevOps狀態報告”（State of DevOps Report），報告是根據采集自27000份調研反饋中的實驗數據而得出的。在報告中指出：
隨著DevOps的演進和擴散，我們注意到，任職于DevOps團隊的員工比例呈逐年遞增。在2014年，在反饋結果的被調查者中有16%的人工作于DevOps團隊。而三年后，這一數字達到了27%。
“DevOps狀態報告”并未對DevOps給出一個明確的定義，但是Matthew Skelton和Manuel Pais在devopstopologies.com上對此話題做了深入的探討。據現有的觀察情況，可使DevOps工作的團隊拓撲結構包括：
開發（Dev）與運維（Ops）間的協作，這是DevOps的“應許之地”（譯者注：“Promised Land”一詞源于圣經，指上帝賜給亞伯拉罕及其族人的土地）。 運維職責的完全分擔。 將運維作為IaaS。 將DevOps作為一種外部服務。 具有過期失效機制的DevOps團隊。 DevOps狂熱者團隊。 SRE團隊（Google的模式）。 由容器驅動的協作。 運維和DBA間的協作。專門設立一個團隊執行DevOps，或是采納了相關的工具，這并不意味著我們正在做一件正確的事情。自CEO以下的每名員工，都需要真正地參與到DevOps工作中。
“DevOps并非某個人的工作，而是每位員工的工作”。這一理念在業界逐漸得到了廣泛的認同，并與DevOps是否或應該體現在職位頭銜上這一問題緊密關聯。正如Threat Stack運維和支持總監Pete Cheslock在“DevOps頭銜毫無裨益”（DevOps in Your Job Title Is Doing You Harm）一文中所說：
事實上，DevOps是一種文化，應該被企業中的方方面面所采納。每個員工都需要擁抱DevOps文化所帶來的變革，而非專屬于某個人。
但是，有人依然認為DevOps（特別是DevOps工程師）應適得其所。SpikeLab的創始人Spike Morelli是一位Google的前員工，并曾任斯坦福大學技術創業MOOC（Technology Entrepreneurship MOOC）的助教。在他看來：
DevOps并非一種職位頭銜，但是DevOps工程師是。其中DevOps用作限定詞。
DevOps是一種方法，而非一種職位頭銜。我們并不會將開發人員稱為敏捷工程師，他們依然是開發人員，只是遵循了敏捷的方法。因此他們的職位并非是去實現敏捷，而是去創建很好的產品。
DevOps應該滲透到組織中，而設立一個DevOps小組在某種程度上會喪失DevOps的意義。DevOps應該嵌入到一個企業的架構之中，而不是作為一種開發過程中的輔助工具。如果DevOps沒有嵌入企業中，我們如何能實踐DevOps？
因此，在DevOps市場中存在著矛盾。事實上越來越多的組織開始支持DevOps團隊，與之形成鮮明對比的是一些觀點認為DevOps團隊是一件壞事。“DevOps狀態報告”的撰寫人對DevOps的增長給出了如下的觀察：
我們認為，這種增長不僅表明了人們對DevOps工作的認可，而且事實上DevOps團隊代表了將整個企業從舊有的工作方式轉換為新的DevOps過程的一種戰略。
這種對DevOps團隊的不利反應并非新近才有。“DevOps狀態報告”的撰寫人之一Jez Humble，他也是《持續交付》（Continuous Delivery）、《精益企業》（Lean Enterprise）和《DevOps手冊》（The DevOps Handbook）等書的作者，曾在2012年宣稱“并不存在所謂的DevOps團隊”：
……DevOps運動意在解決由功能“孤島”組成的組織會導致運作不暢的問題。在嘗試并解決這些問題時，很明顯創建另一個位于開發和運維之間的功能“孤島”是一種不好的（令人啼笑皆非的）問題解決方式。DevOps建議了一些替代策略，用于創建更好的功能“孤島”間協作，或者是完全地消除功能“孤島”并創建跨職能的團隊，或者是以某種方式組合這些方法。
InfoQ與Humble做了核實。時至2017年，他依然秉持此觀點。Humble強烈贊同Streets提出的觀點。但是他相信現在是時候去探討DevOps團隊的問題：
要讓開發人員對他們所創建的系統負起責任，需要開發人員可以得到來自于運維的支持，以了解如何構建可持續部署到那些橫向擴展的不可靠平臺上的可靠軟件。他們需要自身服務于環境和部署，理解如何編寫可測試并可維護的代碼，并需要知道如何打包軟件、實現部署中和部署后的支持工作。在此過程中，需要有人為開發人員提供支持。如果有人想將做這樣事情的人稱為“DevOps團隊”，那么我也不反對。
Puppet產品營銷總監Alanna Brown的觀點是：
一個專職的DevOps團隊，通常是由一些有經驗的運維人員組成，這些運維人員掌握多種技能，包括使用版本控制、編寫作為架構的代碼以及作持續交付。DevOps團隊通常從解決最令人痛苦的事情著手，例如自動化部署等。如果他們取得了成功，那么可以做進一步的發展，并為企業中的其它部門提供共享的服務。
盡管在報告中普遍認為DevOps團隊是一種反模式，但是報告也指出，DevOps團隊和IT企業性能間存在著正向關聯：
在2014年的《DevOps狀態報告》中給出了一個驚喜，那就是16%的被調查者認為自己是專職于在DevOps部門的。這些DevOps團隊成員中有90%的人任職于那些高績效或中等績效的IT企業中。
Pivotal的Michael Coté在敏捷和DevOps團隊的角色和職責上具有豐富的經驗（這里需要澄清一點，Coté的觀點是“DevOps中包括了敏捷”）：
通常我們能看到兩種類型的團隊：一種是“業務能力團隊”，工作針對那些出現問題的實際軟件或服務上（即“應用”）；另一種是“敏捷運維團隊”……
這里，Coté并未介紹敏捷運維團隊所做的工作，但是在他看來，這是圍繞這生產PAAS的平臺工程、站點可靠性和架構的工作。
無論業界是否認同DevOps團隊是推進企業整體DevOps能力的正確方法，現實中DevOps團隊與日俱增。讀者們是否認為DevOps團隊的趨勢將會繼續？更重要問題的是，讀者們是否認為DevOps團隊應該繼續發展下去？
查看英文原文： The Industry Just Can't Decide about DevOps Teams
京公網安備 11010502049343號