devops已經成為了我們行業最熱門的流行語之一。然而出人意料的是，在更緊密的願景和開發團隊和運營團隊更有效的協作之上，很少有共識devops到底意味著什麼。不同組織對devops有著不同的定義，其實devops有個新興的最佳實踐核心,其更進一步的目標是高度協作以生產更好的軟體。在這裡我考驗了這些實踐。但是坦白說，我並不只從開發人員角度來觀察這些實踐。
我按優先順序從高到低列出了這些實踐條目，後面的實踐往往依賴於前面的實踐。
devops的根本原則是開發人員,運營人員以及支援人員必須定期緊密的工作在一起。言外之意是他們必須互相視對方為重要的利益相關人，並積極爭取一起工作。敏捷社群中乙個普遍的實踐是「現場客戶」。這個實踐出自於極限程式設計，它鼓勵開發人員應該與業務人員緊密合作。規範的敏捷團隊將該實踐更進一步，即利益相關的積極參與，這意味著開發人員應該與所有利益相關者一起緊密工作，包括運營人員及支援人員，而不僅僅是業務人員。這是雙向的：運營人員和支援人員也必須願意和開發人員緊密工作。
敏捷軟體開發人員被稱為質量感染者，這是因為他們關注於編寫高質量的**，渴望測試越早開始越好。結果，自動化的回歸測試是敏捷團隊普遍採用的實踐。該實踐有時又被擴充套件為測試先行的方式，比如測試驅動開發（tdd），以及行為驅動開發（bdd）。由於敏捷團隊經常一天多次執行他們的自動化測試集，並且能夠馬上修**現的問題，所以他們比普通團隊能達到更高的質量。對於運營人員而言，在同意乙個解決方案發布到產品環境前，堅持足夠的質量審查，這是件好事情。
要實現以整合的方式來進行配置管理（cm），開發團隊不僅要習慣於在解決方案層級應用cm，還需要考慮自身的解決方案與組織的其餘基礎設施之間的產品環境配置問題。對於一些開發人員而言這是個不小的轉變，因為他們往往習慣於只考慮當前他們工作的解決方案的cm。在devops環境中，開發人員需要擁有企業級視角，在更高的層次看待問題。他們的解決方案如何能在產品環境結合其它資源帶來優勢？其它資源是否能支援被開發的解決方案？言外之意是開發團隊需要了解及管理他們產品的所有範圍的依賴。整合配置管理也使得運營人員了解新的發布潛在的影響，從而更容易決定進行發布的時間。
從it的角度來看，變更管理是一門確保it基礎設施的演化能對整體組織的支援成功及有意義的藝術。但是對於專案-團隊層級則頗具挑戰。這是因為非常多的技術，甚至相似技術的多個版本會被使用在單個解決方案的開發過程中。由於devops引入了與運營有關的企業級問題，綜合變更管理策略會變得越來越複雜，因為需要考慮大量的解決方案能夠在產品環境中同時執行和互動。為了實現綜合變更管理，開發團隊必須與運營團隊緊密合作，來從組織層面了解任何技術的改變帶來的影響。該方式依賴於前面的實踐-利益相關者的積極參與，整合配置管理及自動化測試。
持續整合（ci）是構建及驗證專案的規範，當有**更新被遷入到版本控制系統時，會進行自動化的回歸測試及**分析。ci是與devops相關的**的敏捷開發實踐之一（至少從開發人員角度來說是如此）。ci確保開發人員以較小的，可以對**缺陷立即反饋的常規步驟來開發乙個高質量的可以工作的解決方案。
從開發團隊角度而言，部署計畫總是需要與該組織的運營人員互動。有些情況下，與運營人員介面的專家被特稱為發布工程師。經驗豐富的團隊將使開發，運營及支援團隊這些利益相關者一起持續的制定部署計畫。當你採用了devops策略，你會很快意識到需要一種跨團隊的方式來完成發布計畫，因為需要運營人員與整個開發團隊一起工作。對於運營人員來說這不是什麼新鮮事，但是對於只習慣工作於孤立環境的開發團隊來說卻很驚奇。如果你的團隊還沒有這樣做，你需要開始從組織層面來考慮部署時間表。更遠一步，為了支援持續部署，發布工程師需要增加發布次數，因為敏捷團隊已經可以持續及一致地達到發布的質量要求。
持續部署是持續整合實踐的擴充套件。對於持續部署，當整合在乙個沙盒中成功完成時，變更會被自動公升遷到另乙個沙盒中，整合會自動的在這裡進行。自動公升遷一直持續，直到有人驗證了所有的變更，特別是開發向運營的過渡期。
持續部署使得開發團隊減少了新功能從被驗證到部署到產品環境的時間，使得業務更具響應性。然而，持續部署增加了運營風險，因為如果開發團隊沒嚴格遵守規範，會增加缺陷被引入到產品環境的潛在風險。在企業級環境中成功的執行持續部署要求實現前面介紹的所有實踐。
企業級環境中，大多數的應用程式開發團隊工作在已經存在於產品環境的解決方案的新的功能上。他們不僅工作於該新功能，還有解決嚴重的產品問題的職責。開發團隊往往被稱為產品的「第3級支援」，因為他們是解決棘手的產品問題的第三個（也是最後乙個）團隊。儘管做第**產品支援的需要是普遍的，但是看板和規範敏捷交付（disciplined agile delivery， dad）則是例外，很多敏捷方法只解決傳遞這些影響。該實踐的乙個重要的***是給予了開發者發生在產品中的此類問題的鑑別能力，提供給他們一種學習機會，從而在設計解決方案時就考慮到相應的問題。
正如其名稱所示，這是乙個運營實踐，監控已經發布到產品的環境的正在執行的解決方案和應用程式。技術基礎設施平台（比如作業系統），應用程式伺服器，以及通訊服務通常提供監控功能，可以工作於一些監控工具（比如微軟管理終端，ibm tivoli 監控， 以及jmanage）。然而，為了監控特定應用程式的功能，比如只給特定使用者使用的使用者介面，儀表化該資訊需要與你組織的監控基礎設施相容，這需要構建到應用程式中。開發團隊需要知道該運營要求，或者，更好的方式是可以訪問乙個框架，該框架可以直接提供相應的儀表化。
使用自動化儀錶盤的實踐是it領域的商業智慧型（business intelligence， bi）。該實踐分為兩個方面,開發智慧型以及運營智慧型。開發智慧型需要使用開發工具來儀表化產生的指標。例如，你的配置管理（cm）工具已經記錄了誰以及什麼時候遷入**。持續整合工具可能同樣記錄了構建發生的時間，執行了多少個測試，測試執行的時間，構建是成功還是失敗，執行成功的測試數量等。這些原始資料會被分析並顯示在乙個自動化的儀錶盤中。運營智慧型是之前討論過的應用程式監控的乙個方面。使用了自動化儀錶盤，組織的整體指標開銷將被顯著降低（但是不能完全淘汰，因為不是所有的事情都能被自動化）。自動化儀錶盤提供了實時的對組織的管理團隊的洞察。
DevOps 的實踐體會
devops 的實踐體會 0.devops 介紹 devops development和operations的組合詞 是一組過程 方法與系統的統稱，用於促進開發 應用程式 軟體工程 技術運營和質量保障 qa 部門之間的溝通 協作與整合。可以把devops看作開發 軟體工程 技術運營和質量保障 qa ...
devops實踐指南 最終的DevOps招聘指南
devops實踐指南 招聘合適的人並建立成功的團隊絕非易事。與候選人交談時，要考慮許多方面，從文化適應性和團隊動力到技能，知識和解決問題的能力。最終的devops招聘指南 本指南為求職者和招聘經理提供有關devops招聘狀態的建議，策略和資訊。招聘devops人才提出了自己的挑戰。首先，您的招聘團隊...
高效會議的「八項原則」
開會，是管理工作的一種重要方法。他對集思廣益，消除誤解，做出決策，有其重要意義。但現在，許多會議成為了一種形式，一種 累贅 有的會議議題繁多，只議不決 有的會議拖拉嚴重，形成了效率低下的 大尾巴會 有的會議，參加人數眾多，無多大關係 陪綁 的現象嚴重。有的會議成為了領導 一言堂 失去了會議的意義 總...