小編說：devops 領域在近年來變得流行而普遍。由開發（developers）和運維（operations）組成的“共同協作”，歸根結底，就是為了提高産品品質。
本文選自《devops實踐》，透過本文您将了解如何在大規模靈活背景和不同的靈活開發周期中使用devops。
devops簡介
在定義上，devops是一個涵蓋着幾條線的領域。它既非常實用又貼近實踐。但與此同時，你需要了解的不僅有技術背景，還有非技術的文化方面。
devops由開發（developments）和運維（operations）兩個單詞組成。這個雙關語已經揭示了devops的本意，那就是鼓勵不同的軟體開發部門共同協作。
devops這個詞的起源和devops運動的早期還是很清晰的：patrick debois是一名在it行業的許多領域裡很有經驗的軟體開發工程師兼顧問。他本人對于開發和運維之間的對立感到相當不爽。他試圖在會議中引起大家對這個問題的興趣，但是一開始并沒有什麼效果。
在2009年，o'reilly velocity大會上有個深得好評的演講：“每日至少十次部署：開發和運維在flickr的合作”。patrick随即決定在比利時根特市組織一場名為devops之日的活動。這次，感興趣的人變多了，這場大會獲得了成功。“devops之日”這個名字引起了共鳴，而這場大會也延續了下來。在twitter和大多數論壇裡，devops之日被簡稱為devops。
devops運動的根源寫在了靈活軟體開發原則裡。在2001年，有些人想要改進一成不變的軟體開發模式，并尋找新的工作方法，他們編寫了靈活宣言。下面是靈活宣言裡被奉為經典的摘錄：
“個體和互動 高于 流程和工具 工作的軟體 高于 詳盡的文檔 客戶合作 高于 合同談判 響應變化 高于 遵循計劃 也就是說，盡管右項有其價值，我們更重視左項的價值。”
由此可見，devops可以說是與第一條原則密切相關的——“個體和互動 高于 流程和工具。”
顯然這能夠給工作帶來好處——那為什麼我們還要強調這麼明顯的事呢？如果你在大型企業裡工作過，你就會知道事實上經常是反着來的。哪怕是看起來沒什麼障礙的小企業，裡面的各個部門也很容易就築起高牆。
devops，想要強調個體和互動是非常重要的，并且這個技術很可能有助于拆除企業裡的部門牆。看起來可能有點兒反直覺，因為第一條原則更青睐于互動而不是工具。但是我認為使用任何工具都能起到多種效果。隻要工具用得适當，就能幫我們得到所有想要在靈活中獲得的東西。
舉個非常簡單的例子，一個選擇系統過去經常有缺陷。通常，開發團隊和測試團隊會用不同的系統來處理任務和缺陷。這樣的事不僅在團隊中導緻了不必要的摩擦，并且把本應一起工作的雙方隔離開了。而運維團隊很可能又會用第三種系統來處理伺服器的部署請求。
另一方面，有devops觀念的工程師，會立即意識到所有的三個系統都是相似的工作流程。三個團隊裡的每個人應該都有使用一個相同系統的可能性，也許隻需要為不同的角色展示不同的界面就可以了。因為三個系統變成了一個，是以會帶來減少維護成本的長期利益。
devops的另一個核心目标是自動化和持續傳遞。簡單來說，自動化一切可重複的乏味的工作，把更多時間留給人與人之間的交流，這才能産生真實的價值。
多快才算快？
devops化的轉變必須要快。在高層次上，我們需要考慮搶占市場；在低層次上，我們需要盯緊任務。這也是持續傳遞運動的思路。
就像靈活的很多東西一樣，devops和持續傳遞雖然有許多概念名稱不同，但是它們都有着相同的含義。它們隻不過是一枚硬币的正反面而已，在概念上并沒有什麼争議。
devops工程師緻力于讓公司的流程更快、更有效，并且更可靠。隻要有可能，就取代那些容易出錯的重複性人力勞動。
盡管如此，在devops實踐過程中很容易忘記最終目标。要是幹得太慢，對任何人來說都沒什麼用。相反，我們必須把傳遞增加的商業價值牢記在心。
例如，增進企業内部各角色的交流就有很明顯的價值。你的産品負責人可能想了解開發的進度并渴望能夠先睹為快。這樣的話，在測試環境上做到快速并有效地增量傳遞，将會非常有幫助。像産品負責人這樣的利益相關者，當然還有品質保證團隊，都能夠在測試環境上跟上開發的節奏。
另一種觀點是這樣的：如果你曾經感覺到自己因為不必要的等待而注意力不集中，那麼你的流程或工具有問題。如果你在程式編譯時看機器人打氣球的視訊，那麼你的編譯時間太長了！
在團隊等待部署這件事上也一樣。當然了，整個團隊白白呆着比一個人開銷大多了。
機器人打氣球的視訊很有意思，不過開發軟體也很讓人興奮！我們應該通過消除不必要的開銷來關注創造潛能。
雷射機器人 vs 團隊生産率
靈活之輪
靈活開發中有幾個不同的周期，從投資級的周期，到scrum和看闆周期，再到持續內建周期。根據你使用的靈活架構的不同，工作的側重點也都有些許不同。看闆所強調的24小時周期在營運團隊裡比較流行。而采用scrum靈活流程的開發團隊，scrum周期通常是2到4周。在大規模靈活架構（scaled agile framework）中，長周期也非常普遍，稱為項目增量（program increments），可以持續數個scrum sprint周期。
devops要能夠支援這些周期更好地運轉。在devops的思想下這再正常不過了：在靈活的企業中跨部門協作。
devops在短周期中能帶來明顯的實質效益，而這些效益會讓長周期變得更有效率。俗話說不積跬步，無以至千裡；不積小流，無以成江海。
下面是一些靈活周期可以從devops獲益的例子：
devops工程師維護的部署系統，讓scrum周期最後的傳遞更快、更有效。而傳遞每2到4周就會周期性地發生。
在經常手動部署的企業裡，部署一次可能需要好幾天。像這樣在部署上沒有效率的企業可以從devops觀念中獲益良多。
看闆的周期是24個小時，是以很顯然如果我們想要在看闆方法上取得成功，部署的周期需要快得多。
一旦代碼送出到代碼庫，取決于變更集的大小，一個設計良好的持續傳遞流水線大約隻需要幾分鐘就可以把送出的代碼部署到生産環境。
靈活不隻是形式
由于在量子實體上的成就，richard feynman在1965年獲得了諾貝爾獎。他注意到科學家中的一個普遍現象，那就是他們覆寫了科學的全部邊界，可是就偏偏漏掉了一些關鍵性因素。他把這種現象稱為“草包族科學（cargo cult science）”。這來源于美拉尼西亞南部海島上的草包族（cargo cult）。草包族這個說法是在第二次世界大戰時，因島上的土著居民觀察到飛機給他們送貨而産生的——戰争結束之後，貨物就不再送來了。土著們便開始模仿以前觀察到的美軍的行為，比如修模組化拟機場，幻想飛機能是以再次回來。
草包族的一架靈活飛機
如果我們隻是早上站個會，喝點咖啡，聊聊天氣，這并不是靈活或者面向devops的方式。如果我們的puppet隻有運維團隊才知道怎麼用，這也不是devops流水線。
我們是否正在做正确的事？是否還在正确的路上？時刻關注我們的目标并經常問自己，是件非常重要的事情。這是靈活思考的中心。然而，在實踐中顯然非常困難。很容易以草包族的方式而告終。
每當建構部署流水線的時候，舉個例子，留神我們為什麼要在第一時間建構它們。最終目标是讓人們可以更快、更容易地和新系統互動。它幫助不同角色的人們更有效率地溝通，而不用改變太多。
另一方面，如果我們建構的流水線隻是幫助了一個組的人們達成他們的目标，比方說運維組的人，那麼對于達成最終目标來說，我們已經打了一場敗仗。
雖然沒有科學根據，但值得記住的是靈活周期，比如scrum的sprint周期，一般都會有辦法來應對這種狀況。scrum裡，這種辦法被稱為sprint回顧會議。在會上，團隊一起讨論在上個sprint大家什麼做得好以及什麼可以做得更好。在這上面花點時間來保證你每天的工作都是在做正确的事情。
一個常見的問題是，spring回顧會議的結果并沒有真正地被執行。很不幸，這可能是由于你和企業的其他部分溝通不暢的問題導緻的。是以，這些問題在回顧會議上虐你千百遍，但是從來沒有得到解決。
如果你意識到你的團隊正處于這種情況，你将會從devops方法中獲益，因為它強調企業内部的協作。
總結一下，嘗試使用靈活方法提供的機制。如果你正在使用scrum，請使用sprint回顧會議機制來捕獲潛在的改進空間。話雖如此，這些方法不是教條，找出适合你的方法。
devops和itil（資訊技術基礎架構庫）
這一部分說明了在一個大整體中，devops和其他的工作方式怎麼共存并互相适應。
devops在靈活或者精益企業的許多架構裡都能協作得很好。大規模靈活架構，或者說safe®，都特意提到了devops。自從devops在靈活環境中誕生以來，各種各樣的靈活實踐和devops之間就幾乎從來沒有過分歧。然而，itil有些不同。
itil，資訊技術基礎架構庫（information technology infrastructure library），是很多大型成熟企業采用的一種實踐。
itil是個扮演了軟體生命周期中許多角色的大型架構。devops和持續傳遞認為我們傳遞到生産環境的變更集應該小而頻繁，乍一看，itil的觀點似乎與之相反。然而這并不是事實。遺留系統通常是單塊系統，在這些系統中，經常伴随着複雜變更，需要有一個像itil一樣的流程來管理它們。
如果你正在一個大型企業裡工作，那麼很可能你正在和這樣的大單塊遺留系統一起工作。
還有，許多itil描述的實踐可以直接轉換成相對應的devops實踐。itil規定了配置管理系統和配置管理資料庫，這些類型的系統也是devops必不可少的一部分。
總結
本文概述了devops運動背景。探讨了devops的曆史和它在開發和運維中的起源，以及靈活運動。我們也了解了在大型企業中itil和devops如何共存，同時還讨論了怎樣來避免草包族的反模式。你現在應該能夠回答如何在大規模靈活背景和不同的靈活開發周期中使用devops。我們會逐漸地過渡到更傾向于技術和實踐的主題，更多内容請見《devops實戰》一書。