互聯網公司有一個重要工種，叫做"運維"。

"運維"的英文是 Operations，簡寫為 Ops，直譯就是"操作"，指的是各種服務器操作。

簡單說，運維工程師就是管理服務器、保障代碼運行環境的人。

這是很重要的工作，公司理應非常重視。但是實際上這幾年，運維崗位一直在縮減，Ops 工程師被要求轉型 DevOps 工程師。據我知道，很多運維工程師其實很苦惱。

應該怎麼看待這種變化？運維有沒有前途？將來會怎麼發展？

最近，我讀到一篇老外的文章，標題就叫《運維的未來是平臺工程》。

"The future of Ops is platform engineering."

作者系統地回答了上面這些問題，認為運維最終將會消失，演變成一種新的工種----"平臺工程"（platform engineering）。

我覺得他的文章很有啟發，讓我對運維的看法清晰了很多，分享給大家。

一、運維的由來

最早的時候，並沒有運維，程序員同時負責編寫和運行軟件。

但是，編寫軟件和運行軟件，其實是兩種不同的技能：前者需要熟悉代碼，後者需要熟悉服務器。

互聯網軟件發展起來以後，這兩種技能就逐漸分家了。

開發工程師負責編寫代碼，運維工程師負責運行代碼（即保障服務器運行環境）。

二、運維的衰落

事實證明，開發和運維分家是一個巨大的錯誤。

寫代碼的人不瞭解服務器環境，管理服務器的人不瞭解代碼在幹什麼，這樣不利於做出優秀的產品，也不利於排查問題。

因此，有些公司就推動，開發與運維重新合在一起：編寫軟件的人也要負責運行軟件。

這就是 DevOps 的由來，它等於 Dev（開發）+ Ops（運維）。

另一方面，互聯網公司的核心資產和競爭力，更多的是代碼，而不是運維。所以，公司也有意願，把更多的力量投入在開發上，逐步壓縮專門的運維團隊，積極外包儘可能多的基礎設施。

這兩方面因素決定了，運維作為一個單獨的工種，正在逐漸消失。

三、DevOps 的問題

但是，DevOps 實際上沒有辦法取代運維。

越來越複雜的業務，註定了系統和基礎設施也越來越複雜，同時還必須穩定可靠。

普通的開發工程師，根本不可能做到這一點。他既不瞭解所有基礎設施，也達不到專業運維的系統管理水平。

這種情況下，公司就會選擇外包，採購外部的雲服務，把基礎設施外包給專業的雲服務商， 最大化壓縮自身成本。

四、運維的職責

雖然總體上，運維是管理服務器，但是可以細分成兩方面的職責：構建基礎架構 + 管理運行環境。

"構建基礎架構"指的是硬件的採購、安裝、上架、聯網這些工作。

"管理運行環境"指的是保障業務軟件的運行。

DevOps 出現後，"構建基礎架構"這一職責逐漸消失，變成了採購雲服務，"管理運行環境"這一職責則是轉給了 DevOps 工程師。

於是，新的問題出現了：誰負責採購和整合雲服務？

五、平臺工程是什麼

採購合適的雲服務，並不是一件簡單的事情。

雲服務紛繁複雜，各種 API、SDK 和配套工具令人眼花繚亂，即使經驗豐富的運維工程師也不容易說清楚。

因此，需要有專職人員來做出正確決策，選擇一套滿足需要的雲服務，並且負責編寫工具，整合所有采購來的雲服務，供業務開發使用。

這種角色就叫做平臺工程，他負責評估、採購、整合各種雲服務，作為自身的基礎設施，並在外部雲服務基礎上構建自己的平臺，讓開發工程師能夠在其上自助服務，將自己的代碼投入生產。

上面的定義有幾個要點。

（1）基礎設施是外包的，以求成本和開發週期最小化。

（2）平臺工程師負責整合外包的基礎設施，構建成一個平臺。

（3）開發工程師在該平臺上，自主搭建和管理運行環境，自己運行代碼。

六、平臺工程與運維的區別

平臺工程與運維，存在幾個顯著區別。

（1）平臺工程需要開發軟件，包括編寫測試和代碼審核，團隊的運作方式很像開發團隊，有產品經理、甚至設計師和前端工程師。

運維一般不開發應用軟件，最多就是寫一些自動化腳本。

以前，有的工程師寫代碼，有的工程師跑代碼。今後，所有工程師都編寫代碼，並且運行自己的代碼，不管你是開發工程師、DevOps 工程師或者平臺工程師，不同之處只在於按層或功能劃分的職責範圍不同。

（2）平臺工程是雲原生的，所有工作都存在於雲上。

運維不是雲原生的，需要自己管理硬件，只能說是支持雲的。

（3）平臺工程採購雲服務，運維採購的是硬件。

七、運維工程師的出路

隨著傳統的運維角色的消失，現有的運維工程師必然面臨著轉型，不外乎有三種出路可以選擇。

（1）如果喜歡開發業務軟件，可以選擇成為 DevOps 工程師。

（2）如果喜歡開發平臺軟件，可以選擇做平臺工程，專注於基礎設施的整合。

（3）如果更喜歡硬件和底層，可以選擇加入"基礎設施即服務"（IaaS）的雲公司，深入研究基礎設施。

（完）