網際網路公司有一個重要工種，叫做"運維"。
"運維"的英文是 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）的雲公司，深入研究基礎設施。
（完）