如何與 DevOps 爲伍？

DevOps 是一個席捲 IT 界的新術語。但它到底是什麼，南非的公司們如何利用它來加快高品質應用程序的開發速度？國外知名博客做者凱西·吉布森找到了一些答案。

其實 DevOps 這個詞已經火了一段時間了，咱們知道它是不少新時代數字化企業的成功祕訣。可是，在南非公司收穫由 DevOps 帶來的所有好處以前，重要的是理解它的涵義，以及如何最大限度地利用它的優點。

維基百科對 DevOps 的定義爲：「一種強調軟件開發人員和其餘IT專業人士之間溝通，協做（信息共享和對 Web 服務的使用），集成化，自動化和合做測量的軟件開發方法。」「該方法承認軟件開發，質量保證（QA）和 IT 運營之間的相互依存關係，旨在幫助企業快速生產軟件產品和服務，改善經營業績。」這聽起來很像敏捷之類的現有開發方法，但根本的不一樣之處在於： DevOps 積極推動一系列流程和方法，致力於開發、質量保證和 IT 運營之間的跨部門溝通與協做。

DevOps 的一個主要目標是快速應用部署，從而縮短產品上市時間，下降新版本的故障率，縮短崩潰事件的修復時間和平均恢復時間。DevOps 的目標是經過自動化方式方法，最大限度地提升運營流程的可預測性，效率，安全性和可維護性。Chef 的 EMEA 副總裁兼首席企業架構師的賈斯汀·阿巴克爾，解釋說，DevOps是與業務的總體轉型密切相關的。

「經過思考企業運做的方式，咱們才知道要完成什麼任務，」他說。 「事實證實，DevOps 的核心原則是讓公司全員瞭解新的變化和戰略。」讓IT人員瞭解到，如何看待業務的變革正在進行大有裨益。 「實際上，這不僅是關於 DevOps，或西海岸的想法或基於 Web 的企業，」阿巴克爾說。 「全部的業務正在開始改變。」「但每每當你從大網站跳槽到大企業時，會有某個核心因素令人們不但願發生改變。或者，他們忙於應對爲期八週的項目而後永遠再也不改進。」「但你能夠作到這一點，而且你必須這樣作。除非你的運營模式使用 DevOps 方法，不然，你將使公司變得不穩定。若是你認爲公司如今中規中矩且安全可靠，這是一種錯覺。」阿巴克爾說，在已經轉變的企業中，新產品能根據一系列需求快速迭代。「他們不試圖預測未知的將來。快速迭代的能力幫助它下降風險。大家應該有能力進行最佳預測，創造一個最小可行產品，並以此爲基礎快速迭代。」

速度是來自大型 Web 的新的必備條件，阿巴克爾補充道。 「若是你想在更高的速度下操做，就會犯錯誤。但動做更快意味着更快地修復，比起貫穿整個公司的操做流程你更須要這種能力。「讓速度作你的嚮導。」這一切都增長了公司的可靠性，使其愈加牢固，阿巴克爾解釋到。而且，速度是必要的：「若是你不能快速響應，那就等於自說自話。」

在南非，一組 IT 開發者和學者成立了一個 DevOps 工做組，致力於探索 DevOps 的規則，並促進其在當地環境中的使用。

亞當·雅各布，Chef 首席技術官，在該工做組的成立大會上講話，談到 DevOps 是怎樣出現的，並提供了一些使它奏效的忠告。「DevOps 是由從事相關工做的人創建的，對每個人來講都是不一樣的，」他說。 「它來自一段歷時15 年的深網運做經歷，這段經歷最終演變爲一種工做方式。」他解釋說，負責運營大型網站的人逐漸認識到了他們以前學到的 IT 學科知識在新的環境中一無所用。」「隨着時間的推移，咱們意識到，必須創建更強的信任關係，提升自動化程度、更加自力更生。當你遇到問題時，廠商都很樂意賣給你解決方案 —— 對於你的問題，他們總會有答案。但他們並不真正瞭解你的問題，因此你真得靠本身。」IT 公司面臨的挑戰如此難以界定，提出 DevOps 的定義或方法幾乎是不可能的，雅各布補充道。「雖然有一些共同的主題和行爲，但不一樣的定義卻不可勝數，」他說。 「DevOps 不是做爲一個理論概念存在，而是做爲一種生活體驗而存在。」

可是,一般，在成功運用 DevOps的人眼中，的確存在一些共同的宏觀趨勢。

Chef 提出 DevOps 有點像功夫或者說武術。「儘管有數百種不一樣的武術流派，但他們均可以被認定爲武術，」他解釋說。 「顯然，他們並不都是同樣的，它們共享三個基本理念。」 這三個共同的基本要素是基礎，形式和應用。「這三樣東西是共享的。教基礎的方法是相同的，形式也是相同的，並且在現實中應用它們的方法也是類似的，但因不一樣個體而異。這就是你所知道的練武術的方式。」

「你能夠用一樣的方式來類比 DevOps。」雅各布解釋道，DevOps 更可能是關於從新打造經營業務的方式，而不是軟件開發的流程。「無論你喜不喜歡這是咱們如今正在作的——事實上咱們都在實踐 DevOps。如今須要的是集齊全部的專家並讓他們相互協做，令人們組成團隊，完成他們沒法獨自完成的事。」

根本上來講，DevOps 是一種專一於如何創建和運營高效率公司的文化和行業運動，誕生自從業者的經驗，雅各布說。他提醒道，一樣的規則用於低效率的公司將致使不穩定。「值得記住的是，該運動來自網絡的創新者們。當你將它應用到本身的環境中時，須要從中獲取對你有效的部分。DevOps的從業者都相信——而且踐行——一系列準則，雅各布補充說，不採用這些準則的人就沒有擁抱 DevOps」

這些規則以下，他說：

• 以安全，滿意，知識和自由爲設計目標。
• 作 DevOps 服務於人和公司的全部產品。「這始終是一個事實，人們喜歡作這樣的工做，由於這是一個創建更好的產品的好機會。快樂的人創造快樂的的產品就等於快樂的企業…」
• DevOps 的人精幹。「他們消除非增值的行動; 幫助推進; 旨在持續改進，顛覆性的變化，批量和試驗。」
• DevOps 的人會和失敗創建關係。「這是正常的現狀，不是一個要避免的事情; 會感到恐慌意味着你沒有試圖解決這個問題。」
• 無處不在的工做流程自動化。「一旦咱們想要工做，應該創建工做流程並默認其自動化。」
• 多元化。「DevOps 是多元的，一個高機能的團隊也必須是多元的——越是如此越能作到更好; 須要多種多樣的技能。」

DevOps的形式——關注人們實際作了什麼——要求團隊專一於一個比手頭任務更大的目標，雅各布說。 「所以一個工做也許不在於修好網站，而是在於改變這個國家。」DevOps 的形式是這樣的，他解釋說：

• 相信。「你相信什麼東西會在你的領域創造良好的成果？使用主動語態來說，以好的結果爲目的，公開包括 DevOps 規則在內的理念，並將其融入對你的行業或遇到的問題有特殊意義的事情中。」
• 創建一個高度受權的團隊。「他們必須有權限採起行動，在適宜的狀況下作出正確的決定;與關心組織的宗旨並可以分享利益的領袖爲伍。」
• 形式多樣的關係。「認識專業領域之外的人;瞭解他們作什麼，瞭解他們遇到的的問題和擁有的觀點。他們能夠是來自法律，財務或銷售領域。」
• 藉此在重要決定上達成共識。「循環性的計劃，包含批評和反饋。這將有助於解決問題。」
• 有較強的價值主張。「人們是買止痛藥而不是維生素，重點要放在人們須要而非想要的事情上。能區分是一個客戶想要一個功能仍是許多客戶須要一個功能。」
• 創建一個路線圖。「包括願景和反饋。平衡創新與需求，將它們組合成主題，提煉那些爲功能，並向客戶確認他們。須要堅持這個主題，結果也許會保持原樣，但功能將會發生變化。」
• 總要有興奮因素。「包括那些用戶用了並感到愉快的功能。」
• 創建功能迭代。「不是試圖逐漸描繪出蒙娜麗莎，由於在開始以前你就得知道它是什麼樣。而是從一個草圖開始，加點顏色，而後完成它。」
• 管理風險。「經過階段性假設進行小批量工做。請記住，必須且只能經過客戶進行效果驗證。引入短時間收益減小長期風險——這讓短時間路線圖不夠清楚，但減小了一些在長期的風險。」
• 不要擔憂規模。「非必要的時候沒必要擔憂它——並且這一般會比你想的更晚。」
• 執行。「人們會想出新的理論，你須要經過執行挑戰它們。執行老是賽過理論。」
• 證實每星期持續進行。「而且邀請你們給出反饋。」
• 選擇適合這份工做的語言和工具。「咱們都是通曉多門語言的人; 新的語言和工具是這個行業的巨大優點之一。迭代開發和小批量生產會有利於規避風險。」
• 有一個 bug 數據庫。「給錯誤分類和排優先級。」
• 持續集成。「永遠在短時間迭代分支中合併分支到 master。測試是好的，但持續集成更好，當它出現問題能夠及時進行修復。」
• 遵照四眼原則。除非至少有兩我的都發現了問題，不要改變什麼。必須有另外的人時時檢查你的工做。
• 編寫測試。「但一次只寫一個測試，這頗有必要。」
• 持續交付。「你應該摒棄只要你想就能作到的想法。」
• 一個變化的路徑。「在組織中發生變化的方式固定的。若是有一個一致的模式會使增強規則和輔助流程變得簡單。它能夠幫助人們互相幫助，這在執行的層面是靈活的。」
• 代碼通過相同的工做流，不用考慮它是用於應用程序或基礎結構。
• 專一於可用性。「這其中包括正常運行時間，縮短平均診斷時間和平均修復時間。失敗是不可避免的，不一樣的是你如何面對它。」
• 收集 metrics。「能夠從操做系統，網絡，應用程序或進程收集。
• 能力計劃。「你本應在那但可能並無。肯定關鍵 metrics，把它們放在一個圖中，設定一個上限，繪製趨勢線; 而且在須要的時候擴展時間跨度。」
• 只對可行動的人告警。「讓正確的人去關注問題——但數量越少越好; 只通知能夠採起行動解決問題的人。」
• 練習事件響應。「這可能最重要的步驟。第一個響應者是事件指揮者，他們決定作什麼，統籌資源和通訊狀態。這不是排等級，但只能有一個事件指揮者。」
• 事件剖析。「學習不責難的去描述的事件，創建時間表，肯定影響因素，描述對客戶的影響，描述整治任務，並說明任務能夠如何改善響應流程。」
• 使用可擴展系統設計。「自發因素爲本身負責，實現目標的過程當中要有對其餘能對其進行評估質量的因素的明確保證。」
• 爲簡易性，可擴展性和再利用而設計。

一旦被談論起來，關於 DevOps 聲音每每是複雜的，有時甚至是矛盾的，可是雅各布說，堅持技術是安全的。 「記住一個原則，用您的識別能力實踐這種形式，」他建議道。

「在現實世界中，DevOps 是在描述一個涉及整個組織中的利益相關因素，並連續八週進行嘗試的問題。你可以負擔得起投資這八個星期。」

爲了驗證這個規則，雅各布建議企業選擇一個足夠小的垂直問題，就在這八個星期進行一次有意義的迭代。「在第二階段，設置了你的目的，信念和團隊。寫下的目的和信念，受權團隊，並作好準備。下一步驟是作產品開發。 寫下的價值主張；創建關於主題，成果和特色的路線圖；包括一些興奮因素，並確保功能簡單，擁有可擴展和再利用的特性。」

接下來就是功能迭代。 「經過小批量風險管理，選擇語言並進行工做，同時忽略規模，」雅各布說。 「提出理論時，把重點放在執行性上。每週向整個公司展現進度。使用源代碼控制。有一個 bug 數據庫。使用一個變化事件流。讓其餘人監視一切。記得作持續集成而且每次都測試。使用可擴展的系統設計。操做時，專一於可用性，收集 Metrics，規劃能力，對可行動的事件進行告警，堅持事件響應和事件剖析。」交付時須要堅持最終演示並保持可追溯。

「對 DevOps 而言最重要的是，找到屬於本身的方法，」雅各布說。

原文做者 Kathy Gibson，本文由 OneAPM 工程師編譯整理。

Cloud Insight 集監控、管理、計算、協做、可視化於一身，幫助全部 IT 公司，減小在系統監控上的人力和時間成本投入，讓運維工做更加高效、簡單。本文由 OneAPM 工程師翻譯整理，想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。

本文轉自 OneAPM 官方博客