翻譯-高效DevOps的10項實踐

原文連接： 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的根本原則是開發人員,運營人員以及支持人員必須按期緊密的工做在一塊兒。言外之意是他們必須互相視對方爲重要的利益相關人，並積極爭取一塊兒工做。敏捷社區中一個廣泛的實踐是「現場客戶」。這個實踐出自於極限編程，它鼓勵開發人員應該與業務人員緊密合做。規範的敏捷團隊將該實踐更進一步，即利益相關的積極參與，這意味着開發人員應該與全部利益相關者一塊兒緊密工做，包括運營人員及支持人員，而不只僅是業務人員。這是雙向的：運營人員和支持人員也必須願意和開發人員緊密工做。ide

實踐2：自動化測試

敏捷軟件開發人員被稱爲質量感染者，這是由於他們關注於編寫高質量的代碼，渴望測試越早開始越好。結果，自動化的迴歸測試是敏捷團隊廣泛採用的實踐。該實踐有時又被擴展爲測試先行的方式，好比測試驅動開發（TDD），以及行爲驅動開發（BDD）。因爲敏捷團隊常常一天屢次運行他們的自動化測試集，而且可以立刻修復發現的問題，因此他們比普通團隊能達到更高的質量。對於運營人員而言，在贊成一個解決方案發布到產品環境前，堅持足夠的質量審查，這是件好事情。工具

實踐3：集成配置管理

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

實踐4：綜合變動管理

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

實踐5：持續集成

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

實踐6：集成部署計劃

從開發團隊角度而言，部署計劃老是須要與該組織的運營人員交互。有些狀況下，與運營人員接口的專家被特稱爲發佈工程師。經驗豐富的團隊將使開發，運營及支持團隊這些利益相關者一塊兒持續的制定部署計劃。當你採用了DevOps策略，你會很快意識到須要一種跨團隊的方式來完成發佈計劃，由於須要運營人員與整個開發團隊一塊兒工做。對於運營人員來講這不是什麼新鮮事，可是對於只習慣工做於孤立環境的開發團隊來講卻很驚奇。若是你的團隊尚未這樣作，你須要開始從組織層面來考慮部署時間表。更遠一步，爲了支持持續部署，發佈工程師須要增長髮布次數，由於敏捷團隊已經能夠持續及一致地達到發佈的質量要求。ui

實踐7：持續部署

持續部署是持續集成實踐的擴展。對於持續部署，當集成在一個沙盒中成功完成時，變動會被自動升遷到另外一個沙盒中，集成會自動的在這裏進行。自動升遷一直持續，直到有人驗證了全部的變動，特別是開發向運營的過渡期。操作系統

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

實踐8：產品支持

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

實踐9：應用監控

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

實踐10：自動化的儀表盤

使用自動化儀表盤的實踐是IT領域的商業智能（business intelligence， BI）。該實踐分爲兩個方面,開發智能以及運營智能。開發智能須要使用開發工具來儀表化產生的指標。例如，你的配置管理（CM）工具已經記錄了誰以及何時遷入代碼。持續集成工具可能一樣記錄了構建發生的時間，運行了多少個測試，測試運行的時間，構建是成功仍是失敗，運行成功的測試數量等。這些原始數據會被分析並顯示在一個自動化的儀表盤中。運營智能是以前討論過的應用程序監控的一個方面。使用了自動化儀表盤，組織的總體指標開銷將被顯著下降（可是不能徹底淘汰，由於不是全部的事情都能被自動化）。自動化儀表盤提供了實時的對組織的管理團隊的洞察。

DevOps與文化息息相關

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