編者按：本文作者 Tyler Treat 是一名軟件工程師，他認(rèn)為運(yùn)維的未來(lái)從很多方面來(lái)說(shuō)都跟質(zhì)量保證(QA)的未來(lái)走向相似。未來(lái)，運(yùn)維要使開(kāi)發(fā)者能夠通過(guò)工具、自動(dòng)化和流程實(shí)現(xiàn)自助服務(wù)。傳統(tǒng)的運(yùn)維( Ops)沒(méi)有消失，只是在重組。

云服務(wù)的發(fā)展看起來(lái)讓運(yùn)維人員“丟”了工作，因?yàn)閺膫鹘y(tǒng)意義上說(shuō)，從本地(on-premise)轉(zhuǎn)移到云平臺(tái)意味著運(yùn)維工作在相當(dāng)大程度上外包給云提供商。這正應(yīng)了那個(gè)流行詞—— “無(wú)運(yùn)維運(yùn)動(dòng)”(NoOps)，許多人稱之為 DevOps 的“繼承者”，雖然這個(gè)詞最近這些日子已經(jīng)不是那么響亮了。這使得 Amazon 和開(kāi)發(fā)團(tuán)隊(duì)創(chuàng)建的產(chǎn)品——包括基礎(chǔ)設(shè)施自動(dòng)化，部署自動(dòng)化，配置管理，日志管理以及監(jiān)控和檢測(cè)——之間出現(xiàn)了隔膜，隔膜雖小，但卻至關(guān)重要。

事實(shí)上，運(yùn)維的未來(lái)從很多方面來(lái)說(shuō)都跟質(zhì)量保證(QA)的未來(lái)走向相似。傳統(tǒng)意義上的 QA 正從關(guān)注測(cè)試轉(zhuǎn)向關(guān)注工具。工程師寫(xiě)代碼、單元測(cè)試和集成測(cè)試。測(cè)試在 CI 上運(yùn)行，代碼通過(guò) CD pipeline 和 canary 轉(zhuǎn)出(rollout)來(lái)生產(chǎn)。QA 團(tuán)隊(duì)正在縮小，但是構(gòu)建工具的團(tuán)隊(duì)正在增長(zhǎng)——測(cè)試框架、CI 環(huán)境和 CD pipeline 。QA 能力現(xiàn)在已經(jīng)嵌入發(fā)展團(tuán)隊(duì)中了。經(jīng)由 Microsoft 和 Amazon 等公司普及的SDET 模式是這個(gè)方向的第一步。2014 年，Microsoft 轉(zhuǎn)向了聯(lián)合工程(Combined Engineering)模式，將 SDET 和 SDE(軟件開(kāi)發(fā)工程師)合并成一個(gè)角色，軟件工程師，負(fù)責(zé)產(chǎn)品代碼、測(cè)試代碼和工具代碼。

你們有沒(méi)有注意到 QA 起的作用似乎在悄然消失?跟我合作的或者是我了解的眾多 dev 組織似乎不用 QA 也做得挺好。

同樣的狀況很快也會(huì)發(fā)生在運(yùn)維人員身上。我之前在 Workiva 的基礎(chǔ)設(shè)施和可靠性小組里工作時(shí)，我們將運(yùn)行和基礎(chǔ)建設(shè)工程團(tuán)隊(duì)并入一個(gè)單獨(dú)的團(tuán)隊(duì)，該團(tuán)隊(duì)是由網(wǎng)站可靠工程師組成的，負(fù)責(zé)構(gòu)建和維護(hù)基礎(chǔ)設(shè)施服務(wù)，配置管理，日志管理，集合管理，監(jiān)控等。

我非常支持通過(guò)愿景實(shí)現(xiàn)對(duì)團(tuán)隊(duì)的領(lǐng)導(dǎo)。發(fā)展愿景令人信服，可以使團(tuán)隊(duì)之間達(dá)成共識(shí)，減少功能孤島和組織孤島的影響，并能夠從內(nèi)部激勵(lì)員工。它能使團(tuán)隊(duì)高度一致又能松散耦合，能夠更好地做出決定。我對(duì)運(yùn)維未來(lái)作為組織能力的想法本質(zhì)上是將合成工程看作是合理結(jié)論。跟 QA 一樣，運(yùn)維能力也應(yīng)該被嵌入發(fā)展團(tuán)隊(duì)中。事實(shí)是，沒(méi)有運(yùn)維技能，你不可能在現(xiàn)代組織中成為一名合格的軟件工程師。現(xiàn)如今的運(yùn)維團(tuán)隊(duì)，應(yīng)該重新定義他們的愿景。

運(yùn)維的未來(lái)是要使開(kāi)發(fā)者能夠通過(guò)工具、自動(dòng)化和流程實(shí)現(xiàn)自助服務(wù)，并使他們能夠通過(guò)最小的運(yùn)維干預(yù)來(lái)部署并運(yùn)行服務(wù)。每個(gè)角色都應(yīng)該朝著脫離它們的工作實(shí)現(xiàn)自動(dòng)化的方向而努力。

ops 提供服務(wù)的模式已經(jīng)窮途末路，并且也過(guò)時(shí)了。Devs 提出的要求總會(huì)超出他們的能力。

正確的模式是要把ops作為力量倍增器：創(chuàng)建自動(dòng)化，使devs提供自己的集合和基礎(chǔ)設(shè)施。

Dev：我的集合崩了! Op：好的，我知道了，現(xiàn)在是我的問(wèn)題了——等我來(lái)解決。 ——錯(cuò)誤的模式!

Dev：我的集合崩了! Op：好的，我知道了。作為領(lǐng)域?qū)＜遥襾?lái)幫你，你來(lái)解決，或者是，你可以用工具重配一下。

如果你讓一個(gè)老派的運(yùn)維人員理解說(shuō)明整個(gè)存儲(chǔ)棧，從裸金屬到客戶，并圈出他們所關(guān)心的，他們會(huì)把整個(gè)存儲(chǔ)棧都圈起來(lái)，接著就會(huì)抱怨，就因?yàn)閐ev團(tuán)隊(duì)正在推出的破爛玩應(yīng)，他們大半夜的得被叫起來(lái)。這種思維方式基本上已經(jīng)過(guò)時(shí)了，正是思維方式使得人們都覺(jué)得干運(yùn)維這一行的都是深深厭惡自己，一根接一根不停抽煙。這是由于缺乏同理心而產(chǎn)生的避重就輕、刻薄的想法。如果凌晨?jī)牲c(diǎn)出現(xiàn)內(nèi)存不足的異常，要不要去警告那些沒(méi)有遠(yuǎn)見(jiàn)或者能力的運(yùn)維人員去解決這個(gè)問(wèn)題呢?還是說(shuō)我們應(yīng)該警告那些對(duì)系統(tǒng)相當(dāng)熟悉的開(kāi)發(fā)者呢?后一種做法似乎是明顯的，但是關(guān)鍵在于他們需要被授權(quán)獲悉狀況，調(diào)試后自動(dòng)解決。

其實(shí)新運(yùn)維模式本質(zhì)上應(yīng)該把運(yùn)維看作是一個(gè)產(chǎn)品團(tuán)隊(duì)，其產(chǎn)品就是基礎(chǔ)設(shè)施。就像開(kāi)發(fā)者把 API 作為他們提供的服務(wù)，運(yùn)維把 API 以工具、UI、自動(dòng)化、基礎(chǔ)設(shè)施即代碼、可觀察性和警戒的形式作為他們提供的基礎(chǔ)設(shè)施。

@perterbourgon 關(guān)于這個(gè)話題，我有很多想法，tweet 版本是：我們所知道的 ops 已亡，做基礎(chǔ)設(shè)施的人有五年的時(shí)間轉(zhuǎn)移到產(chǎn)品上。

DevOps 在很多方面正讓開(kāi)發(fā)者跟運(yùn)維人員感同身受。新運(yùn)維正好相反。殉道者式的運(yùn)維團(tuán)隊(duì)相當(dāng)自以為是，他們根本沒(méi)有做好足夠的工作將權(quán)利和責(zé)任轉(zhuǎn)給開(kāi)發(fā)團(tuán)隊(duì)。用這種新的合成工程的方式，我們迫使開(kāi)發(fā)人員從整體角度，系統(tǒng)地思考問(wèn)題。常言道：只有工程師直接對(duì)自己所建造的系統(tǒng)負(fù)責(zé)時(shí)，他們才能建造出真正可靠的系統(tǒng)，也就是意味著工程師要隨叫隨到，而不是指望其他運(yùn)行人員。

因著這樣的轉(zhuǎn)變，老派的、西部狂野式的運(yùn)維需要消亡。運(yùn)維一般被看作是守門(mén)人，他們也是這么看待自己的。運(yùn)維正盡可能多地嵌入進(jìn)程，減緩開(kāi)發(fā)速度，所以當(dāng)他們開(kāi)始生產(chǎn)時(shí)，開(kāi)發(fā)人員會(huì)有近乎完美的可靠系統(tǒng)。一旦該系統(tǒng)歷經(jīng)千辛萬(wàn)苦，經(jīng)受了嚴(yán)格指責(zé)，投入生產(chǎn)之后，老派的運(yùn)維需負(fù)責(zé)運(yùn)行該系統(tǒng)。

老派的運(yùn)維通常是偽君子。他們主張嚴(yán)苛的 SDLC，然后在維護(hù)基礎(chǔ)架構(gòu)時(shí)卻繞過(guò)了同樣的 SDLC 。新運(yùn)維意味著基礎(chǔ)架構(gòu)即代碼。配置變化即代碼。這兩個(gè)哪個(gè)也沒(méi)能免于開(kāi)發(fā)人員必須遵守的 SDLC。我們編纂變更請(qǐng)求，使用不可改變的基礎(chǔ)架構(gòu)和 AMI。沒(méi)經(jīng)歷此進(jìn)程，我們不會(huì)把改變推送到真實(shí)環(huán)境中。同樣地，我們需要對(duì)合規(guī)性和其他開(kāi)發(fā)人員無(wú)法產(chǎn)生共鳴的 SDLC 要求進(jìn)行編碼，編到工具和進(jìn)程中。進(jìn)程記錄并編纂價(jià)值。

老派運(yùn)維總是同精益思維不一致。它完全是中斷驅(qū)動(dòng)——滅火后，一個(gè)接一個(gè)解決問(wèn)題。同時(shí)，取得平衡非常重要。在集成環(huán)境中，使開(kāi)發(fā)者團(tuán)隊(duì)能夠 SSH 登錄進(jìn) box 中或者將調(diào)試器附加到集合上，會(huì)阻止他們正確地調(diào)試應(yīng)用程序嗎?會(huì)促進(jìn)痛苦移位嗎?在運(yùn)維思維和開(kāi)發(fā)思維間取得平衡是非常必要的。

開(kāi)發(fā)團(tuán)隊(duì)通常認(rèn)為運(yùn)維團(tuán)隊(duì)阻礙了創(chuàng)新或者交付。雙方都應(yīng)該相互理解。貶低運(yùn)維團(tuán)隊(duì)很容易，但是更多情況下，他們只是想跟上步伐。不用非得采用每個(gè)登上 Hacker News 頭條的最前沿的科技，也能創(chuàng)新。另一方面，現(xiàn)代運(yùn)維組織需要意識(shí)到他們幾乎永遠(yuǎn)不可能滿足人們的要求了。可持續(xù)的發(fā)展道路——也是傳播同理心的道路——是打破孤島，共擔(dān)責(zé)任。這就是運(yùn)維的未來(lái)。隨著運(yùn)維工作轉(zhuǎn)移到云，它需要給予開(kāi)發(fā)團(tuán)隊(duì)更多的權(quán)利和信任以重塑自身，而不是“閉關(guān)鎖國(guó)”。

運(yùn)維長(zhǎng)存!