編者按：本文作者 Tyler Treat 是一名軟件工程師，他認為運維的未來從很多方面來說都跟質量保證（QA）的未來走向相似。未來，運維要使開發者能夠通過工具、自動化和流程實現自助服務。傳統的運維（ Ops）沒有消失，只是在重組。
云服務的發展看起來讓運維人員“丟”了工作，因為從傳統意義上說，從本地（on-premise）轉移到云平臺意味著運維工作在相當大程度上外包給云提供商。這正應了那個流行詞—— “無運維運動”（NoOps），許多人稱之為 DevOps 的“繼承者”，雖然這個詞最近這些日子已經不是那么響亮了。這使得 Amazon 和開發團隊創建的產品——包括基礎設施自動化，部署自動化，配置管理，日志管理以及監控和檢測——之間出現了隔膜，隔膜雖小，但卻至關重要。
事實上，運維的未來從很多方面來說都跟質量保證（QA）的未來走向相似。傳統意義上的 QA 正從關注測試轉向關注工具。工程師寫代碼、單元測試和集成測試。測試在 CI 上運行，代碼通過 CD pipeline 和 canary 轉出（rollout）來生產。QA 團隊正在縮小，但是構建工具的團隊正在增長——測試框架、CI 環境和 CD pipeline 。QA 能力現在已經嵌入發展團隊中了。經由 Microsoft 和 Amazon 等公司普及的SDET 模式是這個方向的第一步。2014 年，Microsoft 轉向了聯合工程（Combined Engineering）模式，將 SDET 和 SDE（軟件開發工程師）合并成一個角色，軟件工程師，負責產品代碼、測試代碼和工具代碼。
你們有沒有注意到 QA 起的作用似乎在悄然消失？跟我合作的或者是我了解的眾多 dev 組織似乎不用 QA 也做得挺好。
同樣的狀況很快也會發生在運維人員身上。我之前在 Workiva 的基礎設施和可靠性小組里工作時，我們將運行和基礎建設工程團隊并入一個單獨的團隊，該團隊是由網站可靠工程師組成的，負責構建和維護基礎設施服務，配置管理，日志管理，集合管理，監控等。
我非常支持通過愿景實現對團隊的領導。發展愿景令人信服，可以使團隊之間達成共識，減少功能孤島和組織孤島的影響，并能夠從內部激勵員工。它能使團隊高度一致又能松散耦合，能夠更好地做出決定。我對運維未來作為組織能力的想法本質上是將合成工程看作是合理結論。跟 QA 一樣，運維能力也應該被嵌入發展團隊中。事實是，沒有運維技能，你不可能在現代組織中成為一名合格的軟件工程師。現如今的運維團隊，應該重新定義他們的愿景。
運維的未來是要使開發者能夠通過工具、自動化和流程實現自助服務，并使他們能夠通過最小的運維干預來部署并運行服務。每個角色都應該朝著脫離它們的工作實現自動化的方向而努力。
ops 提供服務的模式已經窮途末路，并且也過時了。Devs 提出的要求總會超出他們的能力。
正確的模式是要把ops作為力量倍增器：創建自動化，使devs提供自己的集合和基礎設施。
Dev：我的集合崩了！ Op：好的，我知道了，現在是我的問題了——等我來解決。 ——錯誤的模式！
Dev：我的集合崩了！ Op：好的，我知道了。作為領域專家，我來幫你，你來解決，或者是，你可以用工具重配一下。
如果你讓一個老派的運維人員理解說明整個存儲棧，從裸金屬到客戶，并圈出他們所關心的，他們會把整個存儲棧都圈起來，接著就會抱怨，就因為dev團隊正在推出的破爛玩應，他們大半夜的得被叫起來。這種思維方式基本上已經過時了，正是思維方式使得人們都覺得干運維這一行的都是深深厭惡自己，一根接一根不停抽煙。這是由于缺乏同理心而產生的避重就輕、刻薄的想法。如果凌晨兩點出現內存不足的異常，要不要去警告那些沒有遠見或者能力的運維人員去解決這個問題呢？還是說我們應該警告那些對系統相當熟悉的開發者呢？后一種做法似乎是明顯的，但是關鍵在于他們需要被授權獲悉狀況，調試后自動解決。
其實新運維模式本質上應該把運維看作是一個產品團隊，其產品就是基礎設施。就像開發者把 API 作為他們提供的服務，運維把 API 以工具、UI、自動化、基礎設施即代碼、可觀察性和警戒的形式作為他們提供的基礎設施。
@perterbourgon 關于這個話題，我有很多想法，tweet 版本是：我們所知道的 ops 已亡，做基礎設施的人有五年的時間轉移到產品上。
DevOps 在很多方面正讓開發者跟運維人員感同身受。新運維正好相反。殉道者式的運維團隊相當自以為是，他們根本沒有做好足夠的工作將權利和責任轉給開發團隊。用這種新的合成工程的方式，我們迫使開發人員從整體角度，系統地思考問題。常言道：只有工程師直接對自己所建造的系統負責時，他們才能建造出真正可靠的系統，也就是意味著工程師要隨叫隨到，而不是指望其他運行人員。
因著這樣的轉變，老派的、西部狂野式的運維需要消亡。運維一般被看作是守門人，他們也是這么看待自己的。運維正盡可能多地嵌入進程，減緩開發速度，所以當他們開始生產時，開發人員會有近乎完美的可靠系統。一旦該系統歷經千辛萬苦，經受了嚴格指責，投入生產之后，老派的運維需負責運行該系統。
老派的運維通常是偽君子。他們主張嚴苛的 SDLC，然后在維護基礎架構時卻繞過了同樣的 SDLC 。新運維意味著基礎架構即代碼。配置變化即代碼。這兩個哪個也沒能免于開發人員必須遵守的 SDLC。我們編纂變更請求，使用不可改變的基礎架構和 AMI。沒經歷此進程，我們不會把改變推送到真實環境中。同樣地，我們需要對合規性和其他開發人員無法產生共鳴的 SDLC 要求進行編碼，編到工具和進程中。進程記錄并編纂價值。
老派運維總是同精益思維不一致。它完全是中斷驅動——滅火后，一個接一個解決問題。同時，取得平衡非常重要。在集成環境中，使開發者團隊能夠 SSH 登錄進 box 中或者將調試器附加到集合上，會阻止他們正確地調試應用程序嗎？會促進痛苦移位嗎？在運維思維和開發思維間取得平衡是非常必要的。
開發團隊通常認為運維團隊阻礙了創新或者交付。雙方都應該相互理解。貶低運維團隊很容易，但是更多情況下，他們只是想跟上步伐。不用非得采用每個登上 Hacker News 頭條的最前沿的科技，也能創新。另一方面，現代運維組織需要意識到他們幾乎永遠不可能滿足人們的要求了。可持續的發展道路——也是傳播同理心的道路——是打破孤島，共擔責任。這就是運維的未來。隨著運維工作轉移到云，它需要給予開發團隊更多的權利和信任以重塑自身，而不是“閉關鎖國”。
運維長存！
【編譯組出品】編輯：楊志芳
編者按：本文作者 Tyler Treat 是一名軟件工程師，他認為運維的未來從很多方面來說都跟質量保證（QA）的未來走向相似。未來，運維要使開發者能夠通過工具、自動化和流程實現自助服務。傳統的運維（ Ops）沒有消失，只是在重組。
云服務的發展看起來讓運維人員“丟”了工作，因為從傳統意義上說，從本地（on-premise）轉移到云平臺意味著運維工作在相當大程度上外包給云提供商。這正應了那個流行詞—— “無運維運動”（NoOps），許多人稱之為 DevOps的“繼承者”，雖然這個詞最近這些日子已經不是那么響亮了。這使得 Amazon 和開發團隊創建的產品——包括基礎設施自動化，部署自動化，配置管理，日志管理以及監控和檢測——之間出現了隔膜，隔膜雖小，但卻至關重要。
事實上，運維的未來從很多方面來說都跟質量保證（QA）的未來走向相似。傳統意義上的 QA 正從關注測試轉向關注工具。工程師寫代碼、單元測試和集成測試。測試在 CI 上運行，代碼通過 CD pipeline 和 canary 轉出（rollout）來生產。QA 團隊正在縮小，但是構建工具的團隊正在增長——測試框架、CI 環境和 CD pipeline 。QA 能力現在已經嵌入發展團隊中了。經由 Microsoft 和 Amazon 等公司普及的SDET模式是這個方向的第一步。2014 年，Microsoft 轉向了聯合工程（Combined Engineering）模式，將 SDET 和 SDE（軟件開發工程師）合并成一個角色，軟件工程師，負責產品代碼、測試代碼和工具代碼。
你們有沒有注意到 QA 起的作用似乎在悄然消失？跟我合作的或者是我了解的眾多 dev 組織似乎不用 QA 也做得挺好。
同樣的狀況很快也會發生在運維人員身上。我之前在 Workiva 的基礎設施和可靠性小組里工作時，我們將運行和基礎建設工程團隊并入一個單獨的團隊，該團隊是由網站可靠工程師組成的，負責構建和維護基礎設施服務，配置管理，日志管理，集合管理，監控等。
我非常支持通過愿景實現對團隊的領導。發展愿景令人信服，可以使團隊之間達成共識，減少功能孤島和組織孤島的影響，并能夠從內部激勵員工。它能使團隊高度一致又能松散耦合，能夠更好地做出決定。我對運維未來作為組織能力的想法本質上是將合成工程看作是合理結論。跟 QA 一樣，運維能力也應該被嵌入發展團隊中。事實是，沒有運維技能，你不可能在現代組織中成為一名合格的軟件工程師。現如今的運維團隊，應該重新定義他們的愿景。
運維的未來是要使開發者能夠通過工具、自動化和流程實現自助服務，并使他們能夠通過最小的運維干預來部署并運行服務。每個角色都應該朝著脫離它們的工作實現自動化的方向而努力。
ops 提供服務的模式已經窮途末路，并且也過時了。Devs 提出的要求總會超出他們的能力。
正確的模式是要把ops作為力量倍增器：創建自動化，使devs提供自己的集合和基礎設施。
Dev：我的集合崩了！ Op：好的，我知道了，現在是我的問題了——等我來解決。 ——錯誤的模式！
Dev：我的集合崩了！ Op：好的，我知道了。作為領域專家，我來幫你，你來解決，或者是，你可以用工具重配一下。
如果你讓一個老派的運維人員理解說明整個存儲棧，從裸金屬到客戶，并圈出他們所關心的，他們會把整個存儲棧都圈起來，接著就會抱怨，就因為dev團隊正在推出的破爛玩應，他們大半夜的得被叫起來。這種思維方式基本上已經過時了，正是思維方式使得人們都覺得干運維這一行的都是深深厭惡自己，一根接一根不停抽煙。這是由于缺乏同理心而產生的避重就輕、刻薄的想法。如果凌晨兩點出現內存不足的異常，要不要去警告那些沒有遠見或者能力的運維人員去解決這個問題呢？還是說我們應該警告那些對系統相當熟悉的開發者呢？后一種做法似乎是明顯的，但是關鍵在于他們需要被授權獲悉狀況，調試后自動解決。
其實新運維模式本質上應該把運維看作是一個產品團隊，其產品就是基礎設施。就像開發者把 API 作為他們提供的服務，運維把 API 以工具、UI、自動化、基礎設施即代碼、可觀察性和警戒的形式作為他們提供的基礎設施。
@perterbourgon 關于這個話題，我有很多想法，tweet 版本是：我們所知道的 ops 已亡，做基礎設施的人有五年的時間轉移到產品上。
DevOps 在很多方面正讓開發者跟運維人員感同身受。新運維正好相反。殉道者式的運維團隊相當自以為是，他們根本沒有做好足夠的工作將權利和責任轉給開發團隊。用這種新的合成工程的方式，我們迫使開發人員從整體角度，系統地思考問題。常言道：只有工程師直接對自己所建造的系統負責時，他們才能建造出真正可靠的系統，也就是意味著工程師要隨叫隨到，而不是指望其他運行人員。
因著這樣的轉變，老派的、西部狂野式的運維需要消亡。運維一般被看作是守門人，他們也是這么看待自己的。運維正盡可能多地嵌入進程，減緩開發速度，所以當他們開始生產時，開發人員會有近乎完美的可靠系統。一旦該系統歷經千辛萬苦，經受了嚴格指責，投入生產之后，老派的運維需負責運行該系統。
老派的運維通常是偽君子。他們主張嚴苛的 SDLC，然后在維護基礎架構時卻繞過了同樣的 SDLC 。新運維意味著基礎架構即代碼。配置變化即代碼。這兩個哪個也沒能免于開發人員必須遵守的 SDLC。我們編纂變更請求，使用不可改變的基礎架構和 AMI。沒經歷此進程，我們不會把改變推送到真實環境中。同樣地，我們需要對合規性和其他開發人員無法產生共鳴的 SDLC 要求進行編碼，編到工具和進程中。進程記錄并編纂價值。
老派運維總是同精益思維不一致。它完全是中斷驅動——滅火后，一個接一個解決問題。同時，取得平衡非常重要。在集成環境中，使開發者團隊能夠 SSH 登錄進 box 中或者將調試器附加到集合上，會阻止他們正確地調試應用程序嗎？會促進痛苦移位嗎？在運維思維和開發思維間取得平衡是非常必要的。
開發團隊通常認為運維團隊阻礙了創新或者交付。雙方都應該相互理解。貶低運維團隊很容易，但是更多情況下，他們只是想跟上步伐。不用非得采用每個登上 Hacker News 頭條的最前沿的科技，也能創新。另一方面，現代運維組織需要意識到他們幾乎永遠不可能滿足人們的要求了。可持續的發展道路——也是傳播同理心的道路——是打破孤島，共擔責任。這就是運維的未來。隨著運維工作轉移到云，它需要給予開發團隊更多的權利和信任以重塑自身，而不是“閉關鎖國”。
運維長存！
【編譯組出品】編輯：楊志芳
京公網安備 11010502049343號