如何與 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 官方部落格