DevOps與持續交付實踐

Sato ：雖然我在職業生涯的大部分時間中都是作為一名開發者度過的，但我在技術方面的第一份有償工作其實是在大學時為學校的Linux網絡擔任系統管理員，這種 背景讓我對于軟件的運維方面始終保有興趣：軟件不僅僅在于編寫代碼，還在于如何讓它運行起來，并且在生產環境中保證持續運行。我在工作中總是幫助我的團隊 診斷構建問題、搭建CI以及部署管理、設置基礎設施、對部署進行自動化。因此我選擇在我的第一本書中涵蓋DevOps的主題是再自然不過了。

Sato：在與客戶開會和交談的過程中，我發現他們雖然能夠理解持續交付與其原則所帶來的益處，但在如何實踐方面卻遇到了一些困難。我的指導風格一直以來都是通過解決問題來傳授知識，如果你對于某個問題有所了解，那么學習一種能夠解決這一問題的技術就變得簡單許多了。

我編寫這本書的目的，是為了與整個社區分享一種在實現持續交付與DevOps方面具有高度實踐性與大量的動手實驗示例的一種嘗試。

Sato ：引入流程的目的通常是作為一種避免重犯之前的類似錯誤的一種途徑。舉一個典型的例子：“ 我們上次在部署 X 系統時出現了一個問題，因為我們忘了更新數據庫配置 ”，為此我們加入了一個新的流程步驟，要求對任何配置方面的改動在白板上進行審查與批準，然后才準許進入生產環境。這種方案的目的是為了避免出現重復性的 問題，但具體的實現方式也帶來了其它問題。流程的增加會降低部署的頻率，因而造成了每次發布中的變更數目的增多，最終提高了引入問題的風險。從系統思考的 角度來看，這是一種惡性循環。

而如果你能夠將精力放到對發布軟件的流程進行自動化，而不是讓流程變得官僚與形式化上，你就能夠打破這一怪圈。而這正是DevOps實踐體現其 能力的良機：你可以更頻繁地部署，因而減少了每次發布中的變更數量，最終降低了每次發布的風險。一旦出現問題，由于變更的面積減少了，要找到問題的根源也 變得容易許多。

Sato ：DevOps是旨在打破開發團隊與運維團隊之間的壁壘的一次嘗試，這兩者對于成功的軟件交付來說都是必不可少的，但他們通常會被劃分在不同的組織單元 中，并有著相互抵觸的目標。在開發者負責交付新特性以及對變更承擔責任時，運維人員則試圖保持所有功能平穩運行，而避免變更正是降低風險的一種有效手段。 DevOps專注于以自動化和評估的方式作為降低風險的手段，并通過收集數據以改進交付流程，但它的本質遠不止于只是一門新的工具這么簡單。

DevOps的本質在于讓不同背景的人共同協作，以實現快速可靠的軟件發布。這一點也是許多人產生誤解的部分：他們沒有努力讓眾人團結在一起，而是創建了一個新的“DevOps團隊”，這種做法等于是在整個組織中建立了一個新的壁壘，反而讓事情變得更糟了。 ThoughtWorks在Tech Radar刊物中就將“分離DevOps團隊”這一實踐歸屬為“把持住” ，以突顯這種方式所帶來的風險。成功的DevOps實施會對公司的整個文化產生影響，其影響力甚至超出了技術的范疇。

Sato ：一個簡單的實踐是 將所有東西放在源代碼控制系統中 ，這樣可使應用程序與基礎設施的變更可審計、可追蹤。同時要通過自動化測試驗證這些變更的質量，通過驗證后才可發布到生產環境中。

為應用程序的 構建與部署過程實現自動化 同樣也是十分重要的，它不僅能加快整個流程的運行，還能夠降低將軟件部署到生產環境時產生人為錯誤的風險。

還有一種實踐是我希望在團隊中實現的，即 搭建一種與生產環境相似的本地環境 。通過減少開發與生產環境的差異，讓開發者能夠更快地找到問題所在。我所見過的會造成問題的差異有這樣一些例子：在Windows機器上開發、而在生產環境中的Linux服務器上部署；基于不同的數據庫系統或應用服務器運行軟件；使用不同版本的庫及依賴。

Sato ：通常來說我把DevOps與持續交付實踐看做是一回事，因為在我進行軟件交付時，這兩者是緊密關聯的。不過，有一種關鍵的實踐會鞏固CD流程，即 部署管道 。它的作用不僅僅體現在通過某個CI服務器對每次代碼變更重新構建并測試你的應用， 部署管道 是整個交付流程的一個模型，包含了從提交到投入生產環境的全部過程。

Sato ：這些實踐中有很大一部分依賴于自動化，它能夠打破我之前所提到的怪圈。自動化會帶來更頻繁的部署與更短的循環周期，這些指標對于理解你的IT組織的績效 是相當有用的。而高績效的IT組織在當今的市場上能夠在競爭中取得先機，因為越來越多的企業依賴于通過技術與客戶聯結在一起。

Sato：傳統的流程需要人們手動地連接到某臺服務器上，對操作系統進行配置，安裝基礎的包，再部署應用程序及其依賴，而這種方式能夠讓你通過代碼表現這 些操作步驟。然后你可以進一步使用Chef、Puppet、Ansible或Salt等工具對設置流程進行自動化。一旦你將基礎設施代碼化，你就能夠使用 版本控制對基礎設施的變更進行追蹤。你還可以在部署管道中加入質量檢查的步驟，以實現將軟件從開發至生產環境的整個發布流程的自動化。

Sato ：持續改進是一種通過科學方式進行的演練，它首先創建某種假說，然后在不斷地實驗中收集數據，以驗證或否決這種假說，這是一個循環式的過程。在 DevOps實踐中，你能夠提高部署的頻率，因而能夠更快地執行這一循環。通過更好的自動化、更好的測試與更好的監控等手段，可以有更多的機會對交付流程 進行重新評估并加以改進。

DevOps實踐能夠為持續改進帶來有價值的數據的地方還體現在監控與指標上，通過對生產環境中軟件的行為的相關數據進行收集，例如有哪些特性被使用過、哪些功能反應遲緩、哪些功能是用戶投入時間最多的，你就能夠改善為客戶交付的軟件或服務。

Sato ： 這方面的優秀資源已經很多了（我的這本書當然也是其中之一 J）。閱讀與觀看演講視頻也是開始學習的好方法，但我覺得通過動手實踐進行學習的方式效果要好得多。從你目前的現狀開始著手，應該有許多地方能夠引入某些 DevOps實踐。以下是可以讓他們進行思考的幾個點子：

• 將所有人都集中在一個房間里，畫出將一行代碼的變更部署到生產環境并投入運行的現有流程。并思考整個過程的周期有多長？如何讓它成為一個非事件？怎樣能夠讓這一過程的運行盡量加快，同時無需對質量進行妥協？
• 部署一個緊急修復的現有流程是怎樣的？它與部署一個“普通”發布的流程是完全不同的嗎？考慮一下能否將它們合并為一個單一的流程，并保證高速與可靠性？