全球頂級專家爲你解讀：什麼是真正的 DevOps？

【編者按】本文是 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 須要每一個來源的快速反饋，並結合咱們所聽到的採用反饋的組織所創造的優秀事蹟。

原文連接：http://www.tuicool.com/articles/YV7vqmV

本文系國內 ITOM 行業領軍企業 OneAPM 工程師編譯整理。咱們致力於幫助企業用戶提供全棧式的性能管理以及 IT 運維管理服務，經過一個探針就可以完成日誌分析、安全防禦、APM 基礎組件監控、集成報警以及大數據分析等功能。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客
本文轉自 OneAPM 官方博客