傳統運維不會消失，它只是在改組。就傳統意義而言，從本地轉移到雲端意味著運維（Ops）基本上外包給了雲服務提供商。這是當下蔚然成風的NoOps潮流，許多人稱NoOps是開發運維（DevOps）的“後續者”，不過這年頭這個詞已淡化了許多。這留下的是亞馬遜和開發團隊構建的產品之間一塊很薄又很重要的部分，涵蓋基礎設施自動化、部署自動化、配置管理、日誌管理以及監控和檢測。

從許多方面來看，運營的未來酷似質量保證（QA）的未來。傳統的質量保證角色正由注重測試轉向注重工具。工程師編寫程式碼、單元測試和整合測試。測試在持續整合（CI）中執行，程式碼通過持續交付（CD）管道和金絲雀部署（canaryrollout）進入到生產環境。質量保證團隊在日漸式微，而構建工具的團隊日益壯大起來，這些工具包括測試框架、持續整合環境和持續交付管道。質量保證能力現在已嵌入到開發團隊中。軟體開發測試工程師（SDET）模式是往這個方向邁出的第一步，微軟和亞馬遜之類的公司推廣了這種模式。2014年，微軟改用組合工程（Combined Engineering）模式，將SDET和SDE（軟體開發工程師）合併為一種角色：軟體工程師，軟體工程師負責編寫產品程式碼、測試程式碼和工具程式碼。

對於運維而言，情況變得一模一樣。我在Workiva的基礎設施及可靠性小組工作期間，我們將運營團隊和基礎設施工程團隊合併為一個團隊，這個團隊實際上由網站可靠性工程師（SRE）組成。該團隊負責構建和維護基礎設施服務、配置管理、日誌管理、容器管理以及監控等。

我是通過願景來領導的忠實擁躉。令人信服的願景能夠讓諸團隊保持一致，儘量減小職能孤島和組織孤島帶來的影響，並且從源頭上激勵和動員人們。它帶來了高度一致、鬆散耦合的團隊，有助於做出決策。對於作為一種組織競爭力的運維的未來，我認為組合工程是合乎邏輯的結果。就像質量保證一樣，運維能力應該嵌入到開發團隊中。事實上，要是沒有運維技能，你在現代組織不可能成為高效的軟體工程師。運維團隊應該重新定義願景。

運維的未來是，讓開發人員能夠藉助工具、自動化和流程，並且讓他們能夠在運維干預極少的情況下部署和運營服務，從而實現自助服務。每個角色都應該努力使工作實現自動化。

如果你讓一個老派的運維人員畫出從裸機到客戶的整個架構，並把他們關心的方面圈出來，他們就會圍繞整個架構畫一個圓圈。然後，他們會抱怨開發團隊交付的拙劣產品害得自己在三更半夜接到反映故障的傳呼。這種過時而破碎的思維方式導致了自我厭惡、不斷抽菸的運維人員這個刻板的形象。這是一種缺乏同情心引起的苦惱。如果某個服務在凌晨2點出現記憶體不足異常，提醒缺乏洞察力或權力來解決問題的運維人員，那有意義嗎？或者說，我們應該提醒非常熟悉該系統的開發人員嗎？後者似乎顯而易見，但關鍵是，他們需要獲得授權，可以瞭解情況，進行除錯，並獨立解決。

NewOps模式而是應該實際上將運維當作其產品是基礎設施的產品團隊。酷似開發人員為服務提供API的方式，運維人員為基礎設施提供API，具體表現為工具、使用者介面、自動化、基礎設施即程式碼、可觀察性和警報等。

在許多方面，開發運維旨在讓開發人員對運維表示同情。NewOps恰好相反。過於自以為是的運維團隊在授權方面做得根本就不夠，將責任推到開發團隊的頭上。有了這種新的組合工程方法，我們迫使開發人員以整體的方式來運用系統思維。常言道：工程師要構建真正可靠的系統，唯一的方式就是他們直接對系統負責――這意味著他們隨叫隨到，而不是另外某個運維人員。

由於這一舉動，原始落後的老派運維需要消亡。運維人員通常是把關人，他們認為自己扮演這種角色。老派運維在構建儘可能多的流程，減慢了開發速度，以至於等到進入到生產環境，開發人員擁有了近乎完全可靠的系統。

老派運維人員往往是偽君子。他們主張奉行嚴格的軟體開發生命週期（SDLC），然後等到維護基礎設施時，卻繞過同樣的SDLC。NewOps意味著基礎設施是程式碼。配置更改是程式碼。這兩個都受到開發人員要遵守的同一SDLC的制約。我們整理變更請求，我們使用不可變的基礎設施和AMI。要是變更沒有經過這個流程，我們不會將變更推送到工作環境。與之相仿，我們需要將開發人員不會感同身受的合規及其他SDLC需求編碼成工具和流程。

老派運維老是與精益理念相沖突。它純粹是中斷驅動的（interrupt-driven）――到處滅火，解決一個又一個問題。與此同時，做到兼顧很重要。讓開發團隊能夠通過SSH連線到裝置，或者在整合環境下將除錯人員與容器連線起來，這是否會打消他們以適當的方式檢測應用程式的積極性？這會不會促進疼痛移位（http://bravenewgeek.com/pain-driven-development-why-greedy-algorithms-are-bad-for-engineering-orgs/）？兼顧運維理念和開發理念至關重要。

開發團隊常常讓運維團隊對創新或交付瓶頸負責。雙方都要有同情心。很容易貶低運維人員，但他們常常只是想努力跟上步伐。你可以創新，不必採用登上Hacker News的每一項最先進技術。另一方面，現代運維組織需要意識到，幾乎總是無法滿足對自己提出來的要求。可持續的方法（即灌輸同情心的方法）就是拆除孤島，分擔責任。這就是運維的未來。由於向雲轉移，運維團隊需要通過授權和委託開發團隊來重塑自我，而不是試圖通過劃清界限來保全自己。

運維已死，運維不朽！