以規(guī)模化方式推動DevOps工作中的經(jīng)驗(yàn)與教訓(xùn)
譯文我有幸***次與Ticketmaster公司的Victor Gajendran面對面進(jìn)行交流,而他也將***次出席今年1月21日與22日在加利福尼亞州帕薩迪納召開的SCaLE 14x大會。在此次大會上,他將同與會者們共同探討他的企業(yè)如何運(yùn)用開源機(jī)制,以及如何推動各小型團(tuán)隊(duì)成為大型整體項(xiàng)目中的重要組成部分。
我知道,人們肯定期待著您能聊聊企業(yè)運(yùn)營當(dāng)中所使用的各類免費(fèi)或者開源技術(shù)方案。關(guān)于這一議題,您有什么愿意同我們分享的?
事實(shí)上,Ticketmaster公司已經(jīng)擁有近40年的發(fā)展歷程,而且其間一直在努力構(gòu)建適合自己的技術(shù)堆棧。我們曾經(jīng)使用過一系列技術(shù)成果,從VAX模擬器到現(xiàn)代Docker容器可謂不一而足。公平地講,我們絕對算得上是一家以開源為基礎(chǔ)的企業(yè)。我們的***云基礎(chǔ)設(shè)施大部分基于Xen,剩余的小部分負(fù)載則由OpenStack負(fù)責(zé)實(shí)現(xiàn)。我們的***操作系統(tǒng)是Linux。我們的軟件交付平臺則包含有大量開源技術(shù)成果,例如Git、Jenkins、Rundeck以及Docker等等。
使用免費(fèi)及開源工具的決策是近些年才制定的,還是說Ticketmaster從很久之前就一直是開源項(xiàng)目的堅(jiān)定擁護(hù)者?
Ticketmaster公司絕對是開源項(xiàng)目的一位堅(jiān)定擁護(hù)者,而且這種指導(dǎo)思路已經(jīng)持續(xù)了很多年。我們堅(jiān)信規(guī)模龐大的開源社區(qū)能夠帶來超越各方案供應(yīng)商的技術(shù)問題解決速度。我甚至堅(jiān)定地認(rèn)為,正是這種基于開源機(jī)制的理念才能夠讓我們具備能夠在票務(wù)行業(yè)當(dāng)中保持領(lǐng)先的出色敏捷性。
當(dāng)您做出決定計(jì)劃邁上DevOps道路時,您選擇了怎樣的具體執(zhí)行方式?雇用一部分在DevOps環(huán)境方面擁有實(shí)踐經(jīng)驗(yàn)的新成員,還是對現(xiàn)有員工進(jìn)行針對性培訓(xùn)?
兩種都有。我們的技術(shù)團(tuán)隊(duì)擁有超過1000名成員。盡管我們?nèi)栽诓粩嘁胄碌募夹g(shù)人才,但我們同時也會投入大量資源幫助現(xiàn)有工程師進(jìn)一步成長,因?yàn)樗麄冋悄軌虼_保Ticketmaster公司不會再度犯下以往曾經(jīng)出現(xiàn)過的各類錯誤的中堅(jiān)力量。
對于那些未來有計(jì)劃逐步采納DevOps機(jī)制的企業(yè),您能否為他們總結(jié)出一項(xiàng)最為重要的實(shí)施原則?
創(chuàng)建出一套學(xué)習(xí)文化,確保每位員工都能夠在推進(jìn)技術(shù)界限時都能夠以誠實(shí)的態(tài)度坦言自己犯下的錯誤且不致以此為恥。
您是如何引導(dǎo)自己將大型任務(wù)拆分成眾多小規(guī)模任務(wù)的?這項(xiàng)工作似乎頗具挑戰(zhàn)!
我們會踐行自身所做出的承諾原則。舉例來說,Ticketmaster公司的一大目標(biāo)在于以粉絲們喜愛的方式享受娛樂內(nèi)容。技術(shù)部門會將這樣一種承諾“翻譯”成具體工作內(nèi)容,包括構(gòu)建相關(guān)應(yīng)用程序以幫助粉絲更輕松地查找并購買賽事及表演門票。現(xiàn)在,TechOps部門則進(jìn)一步將任務(wù)進(jìn)行拆分,即“進(jìn)一步提升應(yīng)用程序的可訪問性與可用性,這樣粉絲們就能夠更積極地使用我們的應(yīng)用程序。”接下來,各獨(dú)立團(tuán)隊(duì)會進(jìn)一步對任務(wù)進(jìn)行拆分,或者將業(yè)務(wù)承諾“翻譯”為子承諾。這些子承諾既與規(guī)模龐大的“超級”承諾相契合,同時又同該團(tuán)隊(duì)內(nèi)部的交付框架相適應(yīng)。這種分散化方式不僅能夠幫助我們充分發(fā)揮各團(tuán)隊(duì)的具體作用,同時還調(diào)整了整家企業(yè)的業(yè)務(wù)執(zhí)行方式。
那么誰來負(fù)責(zé)將任務(wù)拆分成更小規(guī)模的子任務(wù)?這類工作在推行過程中有沒有遭遇過阻力,或者由于拆分結(jié)果不夠科學(xué)而導(dǎo)致幾個部門間反復(fù)踢皮球?
每個層級的***們負(fù)責(zé)進(jìn)行任務(wù)拆分工作。高層管理團(tuán)隊(duì)與各層級的***們會將高級業(yè)務(wù)承諾“翻譯”成與各個具體部門相關(guān)的承諾,同時認(rèn)真考慮其實(shí)際可行性。通過確保每位成員都能夠與業(yè)務(wù)/公司總體發(fā)展目標(biāo)的這種適應(yīng)性與契合性,我們的員工將擁有極為可觀的工作動力。不要誤會,整個推進(jìn)過程當(dāng)然也存在著抵觸情緒。然而,由于我們采取了科學(xué)的實(shí)現(xiàn)方式,因此所有問題都具備可管理性。
您認(rèn)為Ticketmaster公司的系統(tǒng)當(dāng)中***挑戰(zhàn)的具體難題是什么?
就是規(guī)模化。即使是最出色的問題解決方案,在面對規(guī)模化時都有可能出現(xiàn)問題。我們希望能夠利用開源解決方案以令人滿意的敏捷性搞定業(yè)務(wù)推進(jìn)中面臨的種種挑戰(zhàn)。但是,我們也必須確保其能夠在經(jīng)過全面規(guī)模化的環(huán)境下仍能繼續(xù)順利起效。這項(xiàng)挑戰(zhàn)讓我們一直保持警惕,也成為我們不斷審視自身并對流程加以完善的動力所在。
原文標(biāo)題:Lessons learned (the hard way) doing DevOps at scale
【51CTO譯稿,合作站點(diǎn)轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】