翻譯-高效DevOps的10項實踐

無敵西瓜發表於2014-09-22

原文連結： http://www.drdobbs.com/architecture-and-design/top-10-practices-for-effective-devops/240149363?pgno=1, 作者Scott W. Ambler。

採用這些DevOps實踐可以實現高效協作，平滑運營，更整潔的程式碼等目標。

DevOps已經成為了我們行業最熱門的流行語之一。然而出人意料的是，在更緊密的願景和開發團隊和運營團隊更有效的協作之上，很少有共識DevOps到底意味著什麼。不同組織對DevOps有著不同的定義，其實DevOps有個新興的最佳實踐核心,其更進一步的目標是高度協作以生產更好的軟體。在這裡我考驗了這些實踐。但是坦白說，我並不只從開發人員角度來觀察這些實踐。

我按優先順序從高到低列出了這些實踐條目，後面的實踐往往依賴於前面的實踐。

實踐1：利益相關者的積極參與

DevOps的根本原則是開發人員,運營人員以及支援人員必須定期緊密的工作在一起。言外之意是他們必須互相視對方為重要的利益相關人，並積極爭取一起工作。敏捷社群中一個普遍的實踐是“現場客戶”。這個實踐出自於極限程式設計，它鼓勵開發人員應該與業務人員緊密合作。規範的敏捷團隊將該實踐更進一步，即利益相關的積極參與，這意味著開發人員應該與所有利益相關者一起緊密工作，包括運營人員及支援人員，而不僅僅是業務人員。這是雙向的：運營人員和支援人員也必須願意和開發人員緊密工作。

實踐2：自動化測試

敏捷軟體開發人員被稱為質量感染者，這是因為他們關注於編寫高質量的程式碼，渴望測試越早開始越好。結果，自動化的迴歸測試是敏捷團隊普遍採用的實踐。該實踐有時又被擴充套件為測試先行的方式，比如測試驅動開發（TDD），以及行為驅動開發（BDD）。由於敏捷團隊經常一天多次執行他們的自動化測試集，並且能夠馬上修復發現的問題，所以他們比普通團隊能達到更高的質量。對於運營人員而言，在同意一個解決方案發布到產品環境前，堅持足夠的質量審查，這是件好事情。

實踐3：整合配置管理

要實現以整合的方式來進行配置管理（CM），開發團隊不僅要習慣於在解決方案層級應用CM，還需要考慮自身的解決方案與組織的其餘基礎設施之間的
產品環境配置問題。對於一些開發人員而言這是個不小的轉變，因為他們往往習慣於只考慮當前他們工作的解決方案的CM。在DevOps環境中，開發人員需要擁有企業級視角，在更高的層次看待問題。他們的解決方案如何能在產品環境結合其它資源帶來優勢？其它資源是否能支援被開發的解決方案？言外之意是開發團隊需要了解及管理他們產品的所有範圍的依賴。整合配置管理也使得運營人員瞭解新的釋出潛在的影響，從而更容易決定進行釋出的時間。

實踐4：綜合變更管理

從IT的角度來看，變更管理是一門確保IT基礎設施的演化能對整體組織的支援成功及有意義的藝術。但是對於專案-團隊層級則頗具挑戰。這是因為非常多的技術，甚至相似技術的多個版本會被使用在單個解決方案的開發過程中。由於DevOps引入了與運營有關的企業級問題，綜合變更管理策略會變得越來越複雜，因為需要考慮大量的解決方案能夠在產品環境中同時執行和互動。為了實現綜合變更管理，開發團隊必須與運營團隊緊密合作，來從組織層面瞭解任何技術的改變帶來的影響。該方式依賴於前面的實踐-利益相關者的積極參與，整合配置管理及自動化測試。

實踐5：持續整合

持續整合（CI）是構建及驗證專案的規範，當有程式碼更新被遷入到版本控制系統時，會進行自動化的迴歸測試及程式碼分析。CI是與DevOps相關的性感的敏捷開發實踐之一（至少從開發人員角度來說是如此）。CI確保開發人員以較小的，可以對程式碼缺陷立即反饋的常規步驟來開發一個高質量的可以工作的解決方案。

實踐6：整合部署計劃

從開發團隊角度而言，部署計劃總是需要與該組織的運營人員互動。有些情況下，與運營人員介面的專家被特稱為釋出工程師。經驗豐富的團隊將使開發，運營及支援團隊這些利益相關者一起持續的制定部署計劃。當你採用了DevOps策略，你會很快意識到需要一種跨團隊的方式來完成釋出計劃，因為需要運營人員與整個開發團隊一起工作。對於運營人員來說這不是什麼新鮮事，但是對於只習慣工作於孤立環境的開發團隊來說卻很驚奇。如果你的團隊還沒有這樣做，你需要開始從組織層面來考慮部署時間表。更遠一步，為了支援持續部署，釋出工程師需要增加發布次數，因為敏捷團隊已經可以持續及一致地達到釋出的質量要求。

實踐7：持續部署

持續部署是持續整合實踐的擴充套件。對於持續部署，當整合在一個沙盒中成功完成時，變更會被自動升遷到另一個沙盒中，整合會自動的在這裡進行。自動升遷一直持續，直到有人驗證了所有的變更，特別是開發向運營的過渡期。

持續部署使得開發團隊減少了新功能從被驗證到部署到產品環境的時間，使得業務更具響應性。然而，持續部署增加了運營風險，因為如果開發團隊沒嚴格遵守規範，會增加缺陷被引入到產品環境的潛在風險。在企業級環境中成功的執行持續部署要求實現前面介紹的所有實踐。

實踐8：產品支援

企業級環境中，大多數的應用程式開發團隊工作在已經存在於產品環境的解決方案的新的功能上。他們不僅工作於該新功能，還有解決嚴重的產品問題的職責。開發團隊往往被稱為產品的“第3級支援”，因為他們是解決棘手的產品問題的第三個（也是最後一個）團隊。儘管做第三級產品支援的需要是普遍的，但是看板和規範敏捷交付（Disciplined Agile Delivery， DAD）則是例外，很多敏捷方法只解決傳遞這些影響。該實踐的一個重要的副作用是給予了開發者發生在產品中的此類問題的鑑別能力，提供給他們一種學習機會，從而在設計解決方案時就考慮到相應的問題。

實踐9：應用監控

正如其名稱所示，這是一個運營實踐，監控已經發布到產品的環境的正在執行的解決方案和應用程式。技術基礎設施平臺（比如作業系統），應用程式伺服器，以及通訊服務通常提供監控功能，可以工作於一些監控工具（比如微軟管理終端，IBM Tivoli 監控，以及jManage）。然而，為了監控特定應用程式的功能，比如只給特定使用者使用的使用者介面，儀表化該資訊需要與你組織的監控基礎設施相容，這需要構建到應用程式中。開發團隊需要知道該運營要求，或者，更好的方式是可以訪問一個框架，該框架可以直接提供相應的儀表化。

實踐10：自動化的儀表盤

使用自動化儀表盤的實踐是IT領域的商業智慧（business intelligence， BI）。該實踐分為兩個方面,開發智慧以及運營智慧。開發智慧需要使用開發工具來儀表化產生的指標。例如，你的配置管理（CM）工具已經記錄了誰以及什麼時候遷入程式碼。持續整合工具可能同樣記錄了構建發生的時間，執行了多少個測試，測試執行的時間，構建是成功還是失敗，執行成功的測試數量等。這些原始資料會被分析並顯示在一個自動化的儀表盤中。運營智慧是之前討論過的應用程式監控的一個方面。使用了自動化儀表盤，組織的整體指標開銷將被顯著降低（但是不能完全淘汰，因為不是所有的事情都能被自動化）。自動化儀表盤提供了實時的對組織的管理團隊的洞察。

DevOps與文化息息相關

在討論了這些苛刻的支援DevOps的實踐之後，我需要強調主要的限制成功的因素是能否建立一個貫穿整個IT組織的相互協作的相互尊敬的文化。我的經驗是，當決定採用高效的DevOps策略時，人及他們相互工作的方式是成功的主要決定因素。不幸的是，在組織中帶來文化變遷比採用一些新的實踐要難得多。在接下來的文章中會討論這些。