戳藍字「CSDN雲計算」關注我們哦！
作者 | Daniel Jones責編 | 唐小引封圖 | CSDN 付費自圖蟲創意出品 | CSDN 雲計算（ID：CSDNcloud）
【導讀】開發和運維「一體」的感覺是由開發人員和操作工程師之間的技能組合和實踐的橋接以及自動化（DevOps）工具的實現引起的。世界各地的大型網際網路公司都已採用 DevOps 方法來徹底改進其性能、安全性和團隊動態。然而，DevOps 究竟如何使用才能為企業真正帶來益處，不走入歧途，也是值得大家關注及思考的問題。
DevOps 團隊必須死。
DevOps 團隊的存在滋生了誤導、懶惰和不誠實，在所謂「IT 流行趨勢」的掩護下，這些行為都變成了大家眼中積極的變化。
在洋溢著「流行趨勢」的企業里：
我們符合敏捷方式嗎？符合！我們為接下來三個月的衝刺做好了計劃！
我們有 Kubernetes 策略嗎？有！再過一個月，就可以投入生產了。
我們有 DevOps 團隊嗎？有！我們已聘請了許多 DevOps 工程師，成立了專門的團隊來編寫 YAML，並負責執行 Ansible playbook。
DevOps 團隊是一個非常普通的反模式，為了向公司的高管證明他們走在了流行趨勢的最前沿，他們採用了一套看似高大上的實踐理論，但實際上公司的責任和文化仍然停留在幾十年前的水平。
如果你有一支名為「DevOps」的團隊，那麼可以肯定地說，你根本沒有在實施 DevOps，而且還有可能反其道而行之。
實際的 DevOps
說完了騙點擊量的標題，現在，我可以偷偷地告訴你，我有一些朋友才是 DevOps 工程師。我說的是真的。
讓我們來定義一下 DevOps 的工作究竟是什麼：
你需要編程，你需要運行系統，還會在凌晨 4 點被叫醒。
這就是為什麼我很驚訝有些「DevOps 工程師」的個人資料顯示他們壓根沒寫過代碼。親，你必須停止這種行為。
DevOps 更準確的定義是：
DevOps 是一種實踐，從事該項工作的跨職能團隊需要負責應用程式或服務的整個生命周期，從創建到運營和支持。
因此，在定義哪些不屬於 DevOps 之前，讓我們首先簡要地總結一下 DevOps 的好處。
DevOps 有哪些好處
由於多種原因，真正的 DevOps 可以提高工作流程的效率，縮短產品上市時間並提高質量。
編寫軟體和運行軟體的人員的利益是一致的，因為他們是同一群人。如果系統發生故障，那麼開發人員會在凌晨 4 點被叫醒，那麼他們必然會更加用心地保障質量和可操作性。
同一個團隊內沒有交流障礙，而且代碼變更的成本也較低。由於沒有兩個團隊間溝通的延誤（比如一個團隊在填寫了服務票後，需要等待另一個團隊來實現），因此所有溝通都可以及時傳達。
DevOps 更準確的定義是：
舉個例子：在我撰寫本文之際，我們的一位工程師向我感嘆說，某個類似於 REST 的客戶應用程式需要先提供一些加密數據，然後才能執行操作，否則就會返回錯誤響應。為了生成加密數據，你需要首先運行這個應用，然後訪問一個特殊的端點。因此，我們必須先部署這個應用，然後看著它被標記為不正常，觸發端點，然後再使用加密值重新配置應用，最後再重新啟動應用。我覺得「十二因素」（https://12factor.net/）也沒有專門指出這種情況，但我很確定，如果該應用的開發人員和部署人員是同一撥人，那麼他們可能會想出一種不會過分依賴手動作業的解決方案。
非 DevOps
看看下列非 DevOps 的現象，你們公司中了哪些？
- 有一個名叫「DevOps」的團隊。
- 有一個名叫「DevOps 工程師」的職位。
- 「DevOps 團隊」不負責編寫生產環境中運行的應用程式。
- 如果系統出問題，應用的開發團隊不會在凌晨 4 點被叫醒。
- 應用的開發團隊需要主動請求「DevOps 團隊」處理某些工作。
如果你們公司中了一項或多項，那麼很遺憾：你們的團隊並不是 DevOps！好消息是，你們不是唯一一家有這種問題的公司，「DevOps 工程師」的招聘廣告有成千上萬。
回顧過去，我們曾經稱這些人為系統管理員，或者叫「配置管理員」。這些人對 Linux 有一定的了解，可以將你的代碼放到環境中。如今，如果你是一名精通 Puppet / Chef / Salt / Ansible / kubectl 的系統管理員，那麼恭喜你，現在你就是 DevOps 了，而且你的工資也會上漲 50%！
- 創建 CI 管道 / Jenkins 的工作
- 創建 Git 代碼庫
- 根據代碼創建 Docker 鏡像
- 將代碼部署到環境中
- 為正在運行的實例建立日誌
如果只有請求了才去做，那麼你們就不是 DevOps！
如果你們的行為不是 DevOps，那麼你的老闆就無法獲得應有的好處。你在對公司的高管撒謊，因為他們以為你們採用了 DevOps 這個高端的實踐，而實際上你們只是掛著羊頭賣狗肉。
你們還不如不要 DevOps，因為老闆付了錢給你，而你卻沒有提供相應的專業技能，而且你還破壞了這個術語的名聲，畢竟還有很多人付諸了正確的實踐。
Matthew Skelton 從各個方面深入定義了非 DevOps 的很多細節，還總結出了「反 DevOps」列表（https://web.devopstopologies.com/#anti-types）。Matthew 曾與人合著《Team Topologies》，書中明確指出了如何組建團隊才能實現高效的流程。
客戶經常請求我們幫助他們找出如何更快地交付價值。最常見的阻礙交付價值的因素之一就是流程效率低下，他們花費在等待上的時間甚至超過了實際工作的時間。將開發和運營活動分割開來是造成等待的常見原因。然後濫用「DevOps」這個本來能夠解決問題的術語，給同一個團隊另起一個虛有其表的名字，這無疑是往傷口上加鹽！
我們真的應該幹掉 DevOps 嗎？
不應該。（除非他們是從未來穿越過來的機器人，目的是降低人類的生產力，與此同時人工智慧正在朝著獲得感知能力和奴役人類而加倍努力，如果真的是這樣，那麼我認為我們應該更加果斷的行動。）
我們應該幹掉「DevOps 團隊」這個概念。
我們不應該再稱他們為「DevOps 團隊」。
我們不應該再假裝實踐某個概念，而是真正去實踐。
如果你做不到，那麼就不要對自己和老闆撒謊。
我有一個 DevOps 團隊，現在該怎麼辦？
我們應該確保這些人能夠構建可重複使用的自動化，為開發人員自身提供服務。
這個 DevOps 團隊不應該僅承擔一次性、常規業務的事務處理工作。
他們應該構建一個內部產品，為開發人員提供自助服務。在這個模型中，應該由應用的開發人員承擔起真正的 DevOps 工作，為他們提供在生產中操作應用程式所需的工具：日誌記錄、軟體度量、生命周期控制項等。下圖顯示了「後 DevOps」的模型。
這個 DevOps 團隊不會為 App 開發人員執行「一勞永逸」的任務。他們從 App 開發人員那裡徵求需求，並將需求寫成產品的待開發功能。他們需要為待開發功能構建自動化和可重用的解決方案，方便開發人員執行操作任務。他們需要構建永久的產品，不應該臨時應付服務票。
我們公司將這樣的 DevOps 團隊稱為平台團隊，儘管我認為在科技行業中「平台」和「服務」之類的術語使用過於頻繁。
如果你的「DevOps 團隊」確實承擔起了上述工作，那麼還要稱他們為「DevOps 團隊」嗎？當然應該以他們交付的產品來命名，不是嗎？
做正確的事
不要為流行語和趨勢所迷惑，你應該花點時間思考如何使用這些術語。如果組織不下功夫減少等待時間和縮短生產周期，那麼無論花多少錢聘請 DevOps 工程師都無法改善價值交付。
我們應該停止濫用術語，更不應該在實踐中自欺欺人。
英文：Kill The DevOps Team連結：https://www.engineerbetter.com/blog/kill-the-devops-team/作者：Daniel Jones譯者：彎月
【END】
推薦閱讀
- 集五福，我用Python
- 微軟開源NAS算法Petridish，提高神經網絡遷移能力
- AI 沒讓人類失業，搞 AI 的人先失業了
- 我國自主開發的程式語言「木蘭」是又一個披著「洋」皮的紅芯瀏覽器嗎？
- 小網站的容器化(上)
- 好撲科技技術副總裁戎朋：從海豚瀏覽器技術負責人到區塊鏈，揭秘區塊鏈技術之路
春節加班老鐵求在看！