《DevOps實戰：VMware管理員運維方法、工具及最佳實踐》——1.2　採用系統思維

本節書摘來自華章計算機《DevOps實戰：VMware管理員運維方法、工具及最佳實踐》一書中的第1章，第1.2節，作者：小特雷弗 A. 羅伯茨（Trevor A. Roberts Jr.）喬希·阿特韋爾（Josh Atwell）埃格勒·西格勒（Egle Sigler）著，更多章節內容可以訪問雲棲社群“華章計算機”公眾號檢視

1.2　採用系統思維

系統思維意味著將涉及軟體發行版本部署的所有團隊當成一個緊密相連的單位，而不是日程安排相互衝突的多個分散團隊。這些團隊包括資訊保安、運營、開發、質量保證（QA）、產品管理等。
在我們的討論中所提到的系統指的是經歷整個軟體開發生命期（規劃、開發、QA、部署和維護）的任何專案，不管這些專案是供內部還是外部消費的。
1.2.1　改變團隊的互動方式
我們將焦點放在第一件應該做的事：成為開發團隊的顧問。和負責定期規劃會議的開發團隊領導（在敏捷的術語中稱為產品負責人和敏捷教練）對話，要求加入他們的一些回憶。主動傾聽可能需要基礎設施採購/部署的任何團隊目標或者可交付成果。下面的幾段強調來自開發團隊的需求/規格示例，說明了在這種會議期間你所能提供的反饋/專業意見。
“我們需要用於客戶原始碼的長期資料儲存。”
開發團隊不一定直接說出他們需要一個新的磁碟陣列，甚至沒有意識到需要採購儲存裝置。但是，對儲存系統的認識會提示你，有必要和儲存主題專家（SME）一起進行容量規劃。
你還需要在開發人員討論使用者資料生命期管理時考慮不同的儲存層次。
“我們需要在生產環境中執行獨立於客戶使用例項的Taao專案例項。”
這立即讓你想起附加虛擬網路或者虛擬防火牆的需求，這能夠使生產和客戶資料流量與內部流量分隔開。你還需要諮詢資訊保安團隊，瞭解提供客戶資料分離保證的審計過程。
“在我們的最後一個發行週期中，程式碼在我的便攜電腦上成功編譯和執行，但是在部署到生產環境時崩潰。”
開發人員可能提出一個在之前的程式碼部署中遇到的問題，提交的程式碼在她的便攜電腦上工作正常，但是在生產部署時發生故障。她的本地開發環境執行的是Ubuntu虛擬機器（VM），和非軍事區（DMZ）中的CentOS伺服器上實施的安全補丁或者防火牆規則不匹配。所以，需要立即打補丁以滿足最後限期（對於開發團隊和運營團隊都是一個漫長的夜晚）。你對Vagrant和Packer等環境構建工具和Puppet、Chef及Ansible等配置管理工具的認識，使你能夠構建一個用於開發人員便攜電腦且匹配生產伺服器規格的標準測試環境。
由於開發團隊領導瞭解了運營團隊在發行週期早期為了緩解開發環境問題所做出的努力，你在協調與此努力相關的一些活動時就會更容易一些。首先，這意味著開發團隊需要確保其成員不會將任務推給其他團隊。（也就是說，“現在是週五下午5點了，我不知道程式碼能不能在生產環境中正常工作，但是無論如何，我都會把它提交到儲存庫！”）
某組織在最近的PuppetConf上發表講話，分享其程式碼部署策略：當程式碼部署到生產環境時，編寫程式碼的開發人員參與更改視窗期的輪班。這樣，如果程式碼中出現任何複雜現象，他們可以立即協助運營團隊查錯和解決。坦率地說，這也使開發人員有動力編寫更好的程式碼，避免在凌晨3點接到電話去修復缺陷。
在繼續之前，對於可能閱讀本書的經理，Jez Humble強烈建議：不要構建新的DevOps團隊！僱用在DevOps方法學上有專業能力的開發人員、QA工程師、運營人員是個好主意，但是建立不同於組織其餘團隊的全新DevOps團隊只會帶來新的“豎井”，可能對你的目標造成反作用。相反，應該像前面提到的那樣，繼續更好地協調各個團隊，使他們像一個團隊那樣思考和行動，而不是各自尋求自己的最大利益。
1.2.2　改變基礎設施部署方法
資料中心的一些擾人而又常見的現象可能妨礙系統的進展：手工製作的“金映像”、雪花伺服器和易碎箱。
伺服器（不管是物理還是虛擬伺服器）部署的常用方法是維護一組包含必要更新、補丁、設定等內容的作業系統配置，人工運用這些配置使系統立刻為部署做好準備。這些配置被稱作“金映像”，傳統上採用ISO形式，已經根據某個執行手冊人工應用補丁。最近，金映像已經採用模板VM的形式儲存。但是，老實說：金映像也可能生鏽！
金映像本身沒有什麼問題。但是，構建它們的方式可能帶來問題。如果人工構建，該過程可能是一個全職工作，必須跟蹤模組更新、安全補丁等，然後重新配置ISO/模板VM供以後使用。必須有一種更有效的方法，也的確有！
使用第4～13章介紹的配置管理技術，可以自動構建映像。隨著伺服器配置更改並登記到Git（第3章中介紹）等儲存庫，Jenkins（參見第18章）等持續整合（CI）系統可以輸出一個更新的金映像。CI系統可以使用Packer等工具生成用於Vagrant、虛擬化管理器和雲提供商的模板VM。
Martin Fowler提出了“雪花伺服器”的思路，雪花伺服器是一臺物理機器或者VM，最初是為了保持標準化的良好願望。但是，不管是為了完成故障報告而進行快速修復、高管要求的特殊專案還是其他原因，這種伺服器都變成高度定製的。這些特殊更改解決了短期問題，但是會造成長期的麻煩。當對這些伺服器上的軟體包升級時會發生什麼？安全補丁甚至作業系統升級又會發生什麼？
如何解決雪花伺服器的問題？首先，我們通過登入到伺服器命令列介面強制避免任何更改；不允許一次性執行前端和軟體包更新工具或者更改配置檔案。所有伺服器更改都只能通過配置管理技術進行。
對於現有的雪花伺服器，必須進行一些乏味而不必要的工作。首先，檢查伺服器配置，以便準確地知道需要修改的配置檔案、需要安裝的軟體包和其他需要包含在配置管理指令碼中的關鍵設定。多次迭代構建和測試伺服器，每次都對配置管理指令碼進行調整，直到測試環境與雪花伺服器完全相同。將更改提交到原始碼庫，就可以擁有一個可在生產伺服器無法恢復時使用的可重複構建過程。
易碎箱這一術語來源於Nassim Nicholas Taleb的《Antifragile》一書，描述了一臺執行關鍵軟體棧的物理或者虛擬伺服器，每個人都害怕接觸它，因為業務可能因此遭遇重大故障。通過許多支援電話/專業服務，這臺伺服器已經達到了一個穩定狀態，糟糕的是，管理該伺服器的SME離開了公司。
如果穩定性確實是個考慮因素，進行物理-虛擬轉換或者虛擬-虛擬遷移到VMware vSphere平臺是個好主意。這樣，你可以利用分散式資源排程器（DRS）、儲存DRS、高可用性（HA）等VMware基礎設施可靠性機制。在伺服器轉換且擁有成功的業務持續性工作流（備份、快照）後，就可以考慮是否可以利用前面雪花伺服器的彌補措施複製這一伺服器。開發和QA工程師就可以很容易地構建一個測試環境而不接觸易碎箱。
1.2.3　改變軟體開發和部署方法
我們已經解決了基礎設施部署的速度和質量問題，那麼團隊如何減少從開發、展示到生產階段程式碼移動引起的缺陷？眾所周知，在開發週期中越早發現缺陷，修復的代價就越低。這就是我們首先要有QA團隊的原因。
但是，如果我們可以在程式碼移交給QA工程師之前就捕捉到缺陷，又會如何？這就是前面提到的持續整合系統的用途所在。我們後面會更詳細地討論CI，基本要點是，當你將原始碼提交到儲存庫時，CI系統可以修改並設定為自動執行對提交程式碼的一系列單元測試。在過程結束時，可以構建一個軟體包並自動分發給QA團隊，實施他們的全面測試。
1.2.4　經常收集和響應有用的系統反饋並相應調整
系統思維的轉變只有在有能力監控和分析系統效能時才能成功。業務的變化節奏似乎是指數級的，消費者對系統響應能力和正常執行時間有更高的預期，被動的問題解決方案不再成為選擇；相反，你的團隊必須在問題發生之前預測到它們，以維護系統穩定性。
日誌分析可能是最重要的工具之一，尤其是在啟用了二進位制程式碼的除錯選項時。如果你的環境由較多的伺服器組成，就應該採用某種形式的自動化日誌分析。這方面的選擇很多，包括VMware vRealize Log Insight、Splunk甚至Logstash、Elasticsearch和Kibana等開源工具（第17章中介紹）。這些解決方案使系統管理員能夠檢查重複的事件與低下的效能關聯。當團隊更加熟悉這些工具，且更擅長識別問題時，系統的實用性就會提升。