編者按

本文是 Skytap 內容主編 Noel Wurst 對 DevOps Enterprise Summit （DOES）的不完全綜述，內容包括了 Noel 和一些與會嘉賓的思考，旨在勾畫 DevOps 當下的局勢，以及未來的趨勢。以及 DevOps 的真正價值——DevOps 正幫助越來越多的企業邁向非凡成功之路。本文系 OneAPM聯合高效運維聯合編譯整理。

以下為譯文：

正如 Elisabeth Hendrickson 的閉幕演講的標題「It’s all about feedback」，因此筆者也撰寫了自己的參會感，注以下斜體字是筆者參加演講時現場所記。

Day 1

Gene Kim 在主題演開幕詞中指出，對比2014年的600張售票，本次會議售票激增到1200張，而之所以形成這個局面，主要是因為 DevOps 當下已經切實預備運用於許多大型專案，全世界都在期盼從中獲取價值。

（重新）構建一個工程文化——Target 的 DevOps 實踐

關鍵人物：

Ross Clanton， Director
Heather Mickman，Senior Group Manager

Target 的 Ross Clanton 和 Heather Mickman 對「pre-DevOps」那個過程分享的直率令人感動。摘錄：

「Target 多年前就曾困惑於工程師的重要性。我們知道必須改變現狀……我們在 silos 中巢狀 silos ……單伺服器支撐需要十個團隊才能完成，而 IT 部門處於一片混亂，以至於大部分的開發流程都耗在等待佇列中。」

Ross 說：

「我們得到了很多稱讚，但這還只是剛剛開始——我們正從事著非常有意思的工作，但還有很長的路要走」。

Target 的發言奠定了本次會議的主題，不僅僅是分享其發展和運營團隊的成功，還講述了不久前的糟糕境況。

雖然很多人會說圍繞 DevOps 的原則已是舊談，但成功 DevOps 的舉措所帶來的收穫，讓整個過程中的挫折和失敗也都變得有意義。

企業 DevOps：由 Metrics、Empathy 和 Empowerment 所驅動的轉型過程

Jody Mulkey，Ticketmaster CTO

Jody 用足球來比喻：長久以來，開發和運維都被認為是功能相反的團隊。在足球場上，運維被視為防守，試圖阻止開發者（進攻）的射門。但運維其實也應該歸為進攻，盡一切努力給開發者爭取充足的時間來得分。

從2011年到2014年，Ticketmaster 的開發者人數增加230％，而運維人數只增加了12％。 Mulkey 卻說「這可不是好事」。

修復 bug 的平均時間以前是47分鐘，但現在是3.8分鐘。時下存在更多的挑戰，永遠需要修復錯誤，部門自視為是其他部門的對手，長時間等待。之所以老生常談，因為大多數企業都經歷著這些鬥爭。

Jody 的故事也非常有意思，他談到 Ticketmaster 如何成就「揹負著遺產前行」 ，以及 DevOps 是如何適用於傳統的大型機系統。

Ticketmaster 的售票引擎產生了25億的收入，儘管它首次提交程式碼是在1976年。正是這個系統和團隊的不懈努力支援著 Ticketmaster，使得修復 bug 的平均時間從47分鐘提升到如今的3.8分鐘。

USAA 和 IBM 的 DevOps 及創新

Michael Bueche， AVP IT Operational Excellence， USAA
Dibbe Edwards， VP Development， DevOps for Hybrid， IBM

當引入一個 DevOps 這樣的大型變革到企業時，建議一步步從小處開始，貪多嚼不爛。Michael Bueche 詳細地講述了 USAA 在推向市場前158天的歷程，及產品90天后部署敏捷方法的經歷，以及當前的每週目標。

「我們人類在確定行動或決定之前，會常常經歷一個非常糟糕的時期，以及在獲得結果前。把這種狀態比作‘熱爐’再恰當不過。試想，當你把手放在滾熱的爐子，要多久才能意識到疼痛？

並不需要一個星期。正如一個開發者在生產中出現 bug，而你直到6周後才發現這個問題，那麼找到責任人有多難？甚至即使你找到了，讓開發者回憶當時的問題和原因也很難。縮短反饋迴路非常有必要，也幫助行動對應其結果」——Michael Bueche

Dibbe 說：

「我們必須確保企業中有適用於 DevOps 計劃的可伸縮環境，同時還一直致力於尋求提高的方法。」

在 Michael 分享之前，筆者從來沒有聽說過「熱爐」這個比喻，的確非常適用於 DevOps、敏捷或現代化軟體交付。反饋迴路必須縮短，才能按時完成和防止生產過程的問題。

賦予開發/測試團隊可以按需獨立提供擴充套件性環境的能力，然後再更早更頻繁地進行檢測，獲取 bug 狀態的快照，使開發人員可以很容易地重現 bug 並予以消除。就像 Jez Humble 所說的——先在自己的環境下搞好！

DevOps 如何實現精益應用開發

Carmen DeArdo， DevOps Technology Leader， Nationwide Insurance

Carmen 說，Nationwide 也曾考慮過外包軟體交付，頂住了種種壓力，他們證明這是完全沒必要。從減少依賴、等待時間和未計劃的工作中，可以降低大量預算。

Carmen DeArdode 的幻燈片展示了妨礙 Nationwide  Lean 交付的因素，以及與此同時，國外的企業在如何應對。

另一個恰當的運動和軟體類比，筆者認為這個觀點非常恰當：「如果你的團隊缺乏一體化的工具，就像你在完全不瞭解籃球隊的比賽情況下，卻要指導籃球隊的實戰訓練，所以根本無法針對實際問題進行操作。」

筆者確實非常喜歡 Carmen 的演講。超過200個敏捷團隊正在質量和生產方面做出顯著提升，但 Nationwide 仍然處於等待狀態，在各種規模的企業內都普遍感到這種狀態。

那麼，Carmen 和 Nationwide 到底做了什麼呢？他們從未停止推進，「在持續交付中採用 DevOps，在移動端、分散式、主機和其他技術中使用精益和敏捷技術。」

效果如何？

Carmen DeArdo 的幻燈片顯示，在引進精益應用開發後 Nationwide 的收穫。

以上是第1天的內容，根據一起參會的 Skytap 同事所說，某些錯過的其他回憶也同樣令人深省！可以在網上找找我們現場所錄的部落格，視訊中會包含其他會議！

Day 2

在輪渡大廈的 Boulettes Larder 享用了平靜安寧的早餐後，第二天也像第一天那樣，在匆忙的會議中進行。

銀行業務的 Innovation 和 DevOps

Tapabrata Pal， Product Manager， Capital One

Tababrata 說：

「為什麼要開源我們的工具？因為這是正確的做法，它們有助於一個持續實驗和學習的文化，開源令它變得更好。」

這是筆者在 Tapabrata 主題演講中唯一記錄的東西，但不是說其他的內容都不好。

老實說，事實恰恰相反。但他對開源工具的觀點確實令人影響深刻，以及簡單有力的答案，「這是應該做的……因為開源令它變得更好」，引起全場轟動的掌聲，以至於幾乎全場都起立為之喝彩。

Tapabrata 接著指出，Capital One 非常擅於獲得快速反饋，因為他們需要保證員工和客戶都高興。

有資源的團隊被稱為「辦公時間」，無論什麼專案都可以在那裡獲得幫助，以及「客戶之聲」專案可以讓客戶指出瓶頸位置——傳統思想這種情況只會出現在企業內部中。我很喜歡這個主意。

「我不是在構建網路軟體，為什麼要關心持續交付？」討論由 Jez Humble 主持

嘉賓從左到右依次是：Jez Humble、 Gary Gruver、Kathy Herring Hayashi、Hugo Gayosso 和 Anders Wallgren。

「如果你在打造精品，它會很快地融入市場。」因此，發現的錯誤越晚，付出的代價就越昂貴。在嵌入式軟體中，這會變得嚴重得多。汽車、醫療器械對高品質的需求，安全軟體是絕對必要的。”

觀眾提問：「這些變化需要什麼文化？」 「產品是容易投入的，並且IT部門不能只被當作成本中心……它們同樣應該被視作完成業務的根本。」

儘管這個討論專為嵌入式軟體行業設計，但該組的討論仍適用於大型機到移動端，以及介於兩者之間的平臺。這些天每個人都在說，交付生命週期晚期發現 bug 的成本遠遠超過早期，在進入客戶的手中之前。

「構建質量」可能需要嚴重破壞的現狀，無論團隊在這方面有多麼熟悉，「他們一直都做的方式」，多長時間才能負擔得起繼續沿著這條道路的成本?

正如這個小組所說，「IT不能只被看作是成本中心」 。對於軟體交付同樣適用，軟體交付也經常被當作成本中心，或者是獲取功能及釋出的障礙。

對虛擬環境、DevOps、連續檢測以及整個交付過程的其他改變的需求，改變著世人對該團隊的看法，並讓他們對軟體的速度和質量產生實質性的影響力。

迪斯尼的 DevOps ——企業意識

Jason Cox，Systems Engineering Disney Internet Group，Web Operations

這並不容易，但運維就有機會扭轉局面。那麼，如何為你的「DevOps Jedi」尋找成功的契機？

引用自迪斯尼，顯然所指的是開發/測試/運維團隊。

在該會議上，筆者沒有做任何記錄，因為不願意錯過 Jason 的每一句話。顯而易見，他不可思議的星球大戰理論，和前兩個月上映的《星球大戰7》遙相呼應，但即使沒有這部電影，他的演講仍然會讓人耳目一新。

筆者不清楚這周是否有人更明確地揭示組織中的繁文縟節、官僚機構、silos 和內戰的普遍現狀。

但這顯示出 Jason 的誠實和熱情，他說：「一切都尚待改變」。這讓在座的所有人都摩拳擦掌，想要帶著這份觸動和靈感迴歸自己的團隊。

就像許多人已經多次指出：沒有哪種方式是容易的。DevOps、敏捷方法、持續整合/測試/部署/交付都很艱難。有時說，「隨時都可以開始」，但這遠遠不夠。這些變化帶來的價值並非一蹴而就。

正如 Jason 所說，你需要被啟發。如果缺乏靈感，我強烈建議大家來聽聽 Jason 的演講，或許能激發你的相關思考。

持續交付的架構設計

Jez Humble，Author，Continuous Delivery

「在座的有做持續整合的嗎？」，幾乎所有人，1000名觀眾，都在舉手。「誰可以在發現 bug 的10分鐘內解決故障？」大家笑了笑，放下了手。

「你應該可以通過按鈕就能從釋出轉到生產狀態。每一個構建中的更新，而每一個版本都是候選版本……軟體應該永遠處於可檢驗狀態，並且始終可部署。開發者必須從一開始就關心這些內容。

DevOps 可能無法保證其安全性、可靠性和部署性。你必須儘早地構建這些內容。我們必須追溯到1970年代以來，我們所瞭解軟體開發的一些非常實用的內容。大多數獨角獸也只是效能達標的馬而已。」

關於 DevOps 定義的模糊性問題對筆者而言問題不大，但筆者同樣瞭解對於缺乏具體的、普遍能接受的定義會讓一些人抓狂。所以不足為奇，筆者也很欣賞 Jez Humble 對持續交付（CD）的定義：

也許，正是因為 Jez 根據結果來定義 CD 才使得其如此受歡迎，而並非採用單一指令性的全有或全無方法。

筆者不清楚你們中有多少人是 Jez Humble 的粉絲（我們當中倒是有很多）。然而，正是這種感覺，每次他演講或寫一本新書，整個世界都為之瘋狂。

Day 3

大型機應用程式的測試自動化

Rosalind Radcliffe，Distinguished Engineer，Chief Architect for DevOps and CLM，IBM

Rosalind Radcliffe 拉開 DOES 最後一日的序幕，她用 IBM 公司26年的工程師生涯體驗和通過虛擬化改變大型機系統的方法，很快打動了在場所有人。

相同的方法也用於 Skytap 和許多合作伙伴規定。在必要時，任何受限於硬體的任何開發和測試團隊，都難以獲得甚至不可能獲得訪問。

Rosalind 的主題演講非常出色，她作為是眾多企業演講者的一份子，向所有人證明 DevOps 實踐正在順利地被引入大型主機層面。

永恆的魅力？：容器與軟體供應鏈發生碰撞

Joshua Corman ，CTO， Sonatype
John Willis ，Director of Ecosystem Development， Docker

「IT運維已經迷失了20年時間；是 DevOps 讓我們成功返航」——John Willis

「我想要拯救生命。我們對軟體的依賴程度越來越大，是因為嵌入式的醫療裝置、汽車、家——我想要這些東西運作起來。」——Josh Corman

「我們需要為編碼構建程式碼。如果你並不熱血沸騰，不如選擇離開」——John Willis

如果迪士尼的 Jason Cox 獲得「最佳會議獎」，那應該是實至名歸，尤其是作為星球大戰迷的筆者，但這實際上這份容易也可以頒給 Joshua 和 John 的「永恆的魅力」主題演講。

當 Joshua 說，他不只是熱愛軟體或 DevOps，這是在挽救生命，你會相信他對於這份事業的熱愛。

用2010年在海地和智利的地震來舉例，能看到架構質量之間的差異，Joshua 指出，當海地的7.0級地震導致23萬人喪生時，智利更強的8.8地震只造成279人死亡。

這兩者之間的差距令人難以置信，其中一個原因就是智利嚴格的建築法規，而海地正缺乏這樣的規範。

「我們需要建立程式設計的規範」，Corman 說道。我們對軟體的依賴，可以促進社會交往或幫助移動商務交易，會迅速移動到同時取決於在複雜醫療裝置、汽車內建的軟體。

那些負責保證這些連線裝置正常執行，並防止黑客攻擊和故障的程式碼，更有責任保證工作質量。

關於反饋

Elisabeth Hendrickson，VP of Engineering， Pivotal’s Big Data Suite

「更多的測試者不等於質量更好」，避免：反饋流汙染、誤報警/故障、失真、丟失資訊

從開發者、測試者、運營、軟體的使用者/客戶、安全性到系統本身，DevOps 需要每個來源的快速反饋，並結合我們所聽到的採用反饋的組織所創造的優秀事蹟。

希望筆者的反饋對你有所裨益！