我有幸***次與Ticketmaster公司的Victor Gajendran面對面進行交流，而他也將***次出席今年1月21日與22日在加利福尼亞州帕薩迪納召開的SCaLE 14x大會。在此次大會上，他將同與會者們共同探討他的企業如何運用開源機制，以及如何推動各小型團隊成為大型整體項目中的重要組成部分。

我知道，人們肯定期待著您能聊聊企業運營當中所使用的各類免費或者開源技術方案。關于這一議題，您有什么愿意同我們分享的？

事實上，Ticketmaster公司已經擁有近40年的發展歷程，而且其間一直在努力構建適合自己的技術堆棧。我們曾經使用過一系列技術成果，從VAX模擬器到現代Docker容器可謂不一而足。公平地講，我們絕對算得上是一家以開源為基礎的企業。我們的***云基礎設施大部分基于Xen，剩余的小部分負載則由OpenStack負責實現。我們的***操作系統是Linux。我們的軟件交付平臺則包含有大量開源技術成果，例如Git、Jenkins、Rundeck以及Docker等等。

使用免費及開源工具的決策是近些年才制定的，還是說Ticketmaster從很久之前就一直是開源項目的堅定擁護者？

Ticketmaster公司絕對是開源項目的一位堅定擁護者，而且這種指導思路已經持續了很多年。我們堅信規模龐大的開源社區能夠帶來超越各方案供應商的技術問題解決速度。我甚至堅定地認為，正是這種基于開源機制的理念才能夠讓我們具備能夠在票務行業當中保持領先的出色敏捷性。

當您做出決定計劃邁上DevOps道路時，您選擇了怎樣的具體執行方式？雇用一部分在DevOps環境方面擁有實踐經驗的新成員，還是對現有員工進行針對性培訓？

兩種都有。我們的技術團隊擁有超過1000名成員。盡管我們仍在不斷引入新的技術人才，但我們同時也會投入大量資源幫助現有工程師進一步成長，因為他們正是能夠確保Ticketmaster公司不會再度犯下以往曾經出現過的各類錯誤的中堅力量。

對于那些未來有計劃逐步采納DevOps機制的企業，您能否為他們總結出一項最為重要的實施原則？

創建出一套學習文化，確保每位員工都能夠在推進技術界限時都能夠以誠實的態度坦言自己犯下的錯誤且不致以此為恥。

您是如何引導自己將大型任務拆分成眾多小規模任務的？這項工作似乎頗具挑戰！

我們會踐行自身所做出的承諾原則。舉例來說，Ticketmaster公司的一大目標在于以粉絲們喜愛的方式享受娛樂內容。技術部門會將這樣一種承諾“翻譯”成具體工作內容，包括構建相關應用程序以幫助粉絲更輕松地查找并購買賽事及表演門票。現在，TechOps部門則進一步將任務進行拆分，即“進一步提升應用程序的可訪問性與可用性，這樣粉絲們就能夠更積極地使用我們的應用程序。”接下來，各獨立團隊會進一步對任務進行拆分，或者將業務承諾“翻譯”為子承諾。這些子承諾既與規模龐大的“超級”承諾相契合，同時又同該團隊內部的交付框架相適應。這種分散化方式不僅能夠幫助我們充分發揮各團隊的具體作用，同時還調整了整家企業的業務執行方式。

那么誰來負責將任務拆分成更小規模的子任務？這類工作在推行過程中有沒有遭遇過阻力，或者由于拆分結果不夠科學而導致幾個部門間反復踢皮球？

每個層級的***們負責進行任務拆分工作。高層管理團隊與各層級的***們會將高級業務承諾“翻譯”成與各個具體部門相關的承諾，同時認真考慮其實際可行性。通過確保每位成員都能夠與業務/公司總體發展目標的這種適應性與契合性，我們的員工將擁有極為可觀的工作動力。不要誤會，整個推進過程當然也存在著抵觸情緒。然而，由于我們采取了科學的實現方式，因此所有問題都具備可管理性。

您認為Ticketmaster公司的系統當中***挑戰的具體難題是什么？

就是規模化。即使是最出色的問題解決方案，在面對規模化時都有可能出現問題。我們希望能夠利用開源解決方案以令人滿意的敏捷性搞定業務推進中面臨的種種挑戰。但是，我們也必須確保其能夠在經過全面規模化的環境下仍能繼續順利起效。這項挑戰讓我們一直保持警惕，也成為我們不斷審視自身并對流程加以完善的動力所在。

原文標題：Lessons learned (the hard way) doing DevOps at scale

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】