《DevOps實戰》讀書筆記 Ch01 DevOps概述

DevOps簡介

DevOps是一種系統部署方法學，組織能夠用它來改善項目部署的深度和質量。

1.1 DevOps原則概述

DevOps包含組織互動和部署工具及實踐的變化，主要強調識別和緩解生產力瓶頸。 你也許閱讀過Gene Kim所著的《The Phoenix Project》，書中他將DevOps的重要原則歸結爲DevOps的三條道路：

• 第一條道路：優化從開發到IT運營的工做流。
• 第二條道路：縮短和放大反饋循環。
• 第三條道路：鼓勵試驗，快速從故障中學習。 這些原則和John Willis及其餘DevOps思想領袖所討論的流行概念CAMS（Culture、Automation、Metrics、Share）（文化、自動化、計量和共享）相符：
• 文化：故障不該該當即引發過失認定，改變團隊成員對部署方法和故障響應的思惟方式。
• 自動化：人工方法容易招致故障。使用可以以可靠的方式重複、快速部署環境的工具。
• 計量：監控和分析對於成功必不可少，不然，故障的根源分析就不可能實現。
• 共享：我的/團隊獨佔信息，以維持地位或提高團隊依賴性的的「搖滾明星」心態在IT文化中站不住腳。這種心態不會提升生產力，而會下降生產力。

1.2 採用系統思惟

系統思惟意味着將涉及軟件發行版本部署的全部團隊當成一個緊密相連的單位，而不是日程安排相互衝突的多個分散團隊。 這些團隊包括信息安全、運營、開發、質量保證（QA）、產品管理等。

1.2.1 改變團隊的互動方式

咱們將焦點放在第一件應該作的事：成爲開發團隊的顧問。和負責按期規劃會議的開發團隊領導（在敏捷的術語中稱爲產品負責人和敏捷教練）對話， 要求加入他們的一些回顧會議。

1.2.2 改變基礎設施部署方法

數據中心的一些擾人而又常見的現象可能妨礙系統的進展：手工製做的「金映像」、雪花服務器和易碎箱。 管理一堆服務器，手動登入每臺服務器，手動安裝衆多軟件，手動修改各類配置文件，致使每臺服務器如同雪花同樣獨特，各服務器配置千差萬別難以複製。這就是雪花服務器。

1.2.3 改變軟件開發和部署方法

基本要點是，當你將源代碼提交到存儲庫時，CI系統能夠修改並設置爲自動執行對提交代碼的一系列單元測試。在過程結束時，能夠構建一個軟件包並自動分發給QA團隊，實施他們的全面測試。

1.2.4 常常收集和響應有用的系統反饋並做相應調整

系統思惟的轉變只有在有能力監控和分析系統性能時才能成功。業務的變化節奏彷佛是指數級的，消費者對系統響應能力和正常運行時間有更高的預期，被動的問題解決方案再也不 成爲選擇；相反，你的團隊必須在問題發生以前預測到它們，以維護系統穩定性。

1.3 增進DevOps知識和技能

一旦在系統思惟和改進的系統驗證上構建了良好的基礎，團隊對按期試驗新功能就會更加自信。DevOps實踐使開發人員可以分階段逐步地投產各類功能。 這樣作的好處之一是，開發人員能夠利用針對選擇的客戶的限定發行版本對新功能進行Beta測試，收集基礎設施影響和用戶接受度方面的指標。 有效的日誌分析方法可以在重大問題蔓延以前發行它們。

1.4 小結

咱們已經明白了DevOps的概念和對組織的好處，下面咱們將更仔細地研究有助於團隊成功的一些工具。