基礎設施和環境管理

《持續交付 發佈可靠軟件的系統方法》讀書筆記

基礎設施（infrastructure）代表了你所在組織中的所有環境，以及支持其運行的所有服務，如 DNS 服務器、防火牆、路由器、版本控制庫、存儲、監控應用、郵件服務器，等等。

基礎設施不但應該具有自治特性，而且應該是非常容易重新搭建的。這樣的話，當有硬件問題時，就能迅速重建一個全新的已知狀態的環境配置。所以，基礎設施的準備工作也應該是一個自動化過程。自動化的準備工作與自治性的維護相結合，可保證一旦出現問題就能在可預見的時間內重建基礎設施。

環境是指應用程序運行所需的 所有資源 和它們的 配置信息 。用如下這些屬性來描述環境：

爲了減少在類生產環境（production-like environment）中的部署風險，需要精心管 理如下內容：

理解運維團隊的需要

無需證明，大多數項目的失敗原因在於人，而不是技術本身。

對於 “將代碼部署到測試和生產環境中” 這事來說，更是如此。幾乎所有大中型公司都會將開發活動和基礎設施管理活動（也就是常說的運維活動）分交給兩個獨立的部門完成。常常能看到這兩撥人的關係並不是很好。這是因爲往往鼓勵開發團隊儘可能快地交付軟件，而運維團隊的目標則是穩定。

需要謹記的最重要的事情是：所有的項目干係人都能達成一個共識，即讓發佈有價值的軟件成爲一件低風險的事情。根據我們的經驗，做這件事的最佳方法就是儘可能頻繁地發佈（即持續交付)。

文檔與審計

運維主管希望確保其所管任意環境中的任意變更都要被記錄在案並被審計。這樣一旦出了問題，他們可以查到是由哪些修改引起的。

軟件開發團隊的成員也需要熟悉運維團隊掌控的這些系統和流程，並遵守它們。制定軟件發佈時所需遵循的流程也是開發團隊發佈計劃的一部分。

異常事件的告警

運維團隊會有自己的系統來監控基礎設施和正在運行的應用程序，並希望當系統出現異常狀況時收到警報，以便將停機時間最小化。

要在項目一開始就瞭解運維團隊希望怎樣來監控應用程序，並將其列在發佈計劃之中，比如，他們想要如何監控？希望把日誌放在什麼位置？當系統出錯時，應用程序要使用怎樣的方式通知運維人員？

瞭解並滿足運維團隊的監控需求，並把這些需求放到發佈計劃中是開發團隊的責任。處理這些需求的最佳辦法就是像對待其他需求那樣對待它們。主動從運維人員的角度思考，想一下他們會如何應對應用程序——他們是應用程序用戶中非常重要的一部分用戶。

保障 IT 服務持續性的計劃

運維經理要參與組織的 IT 服務連續性計劃的創建、實現、測試和維護。

運維團隊掌管的每個服務都會設定一個 RPO（Recovery Point Objective， 恢復點目標，即災難之前丟失多長時間內的數據是可接受的）以及一個 RTO（Recovery Time Objective，恢復時間目標，即服務恢復之前允許的最長停機時間）。

作爲業務持續性測試的一部分，應該對應用程序數據的備份、恢復以及歸檔工作進行測試，還要獲取並部署任意指定版本的應用程序。另外，作爲發佈計劃的一部分，還要將如何執行這些活動的流程提供給運維團隊。

使用運維團隊熟悉的技術

運維主管希望用運維團隊自身熟悉的技術對其管理的環境進行變更操作，這樣他們就能真正掌控和維護這些環境了。

在每個項目開始時，開發團隊和運維團隊就應該坐下來，討論並決定應用程序的部署應該如何執行。一旦所用技術達成一致，雙方可能都需要學習一下這些技術。關鍵在於兩個團隊都要理解這個部署系統，因爲我們必須使用相同的部署過程對每個環境的修改進行部署，這些環境包括開發環境、持續集成環境、測試環境和生產環境。

部署系統是應用程序的一個部分。與應用程序的其他部分一樣，它也應該被測試和重構，並放在版本控制庫中。如果不這麼做（我們曾看到過這種事情發生），其結果總是留下一堆疏於測試、易出問題且不易理解的腳本，讓變更管理充滿風險和痛苦。

基礎設施的建模和管理

每種環境中都有很多種配置信息，所有這些配置信息都應該以自動化方式進行準備和管理。

如果你對將要開發的系統所用技術有最終決定權的話，那麼在項目的啓動階段，你應該回答一個問題：用這種技術做自動化部署和配置軟硬件基礎設置容易嗎？對於系統的集成、測試和部署的自動化來說，使用能夠以自動化方式進行配置和部署的技術是一個必要條件。

假如你無權控制基礎設施的選擇，但還想全面自動化構建、集成、測試和部署的話，你必須解決下述問題：

基礎設施的訪問控制

控制包括以下三方面：

因爲我們相信，應該像對待生產環境一樣對待測試環境，在這兩種環境上要使用同樣的流程。對生產環境和測試環境的變更請求應該執行一個變更管理流程。

對基礎設施進行修改

高效的變更管理流程有如下幾個關鍵特徵：

良好的變更管理的關鍵在於創建一個自動化流程，從版本控制庫中取出基礎設施的變更項進行部署。

加強可審計性的最佳方法是用自動化腳本來完成所有變更。這樣，萬一後來有人想知道到底做了哪些修改的話，就很容易找到了。因此，通常情況下，我們認爲使用自動化方式要優於手工文檔。手工文檔無法保證所記錄的變更是完全正確的，比如 “某人說他做過了什麼事情” 與“他實際上做了什麼”，這之間的差異足以讓你花上幾小時甚至幾天的時間去查找問題根源。

服務器的準備及其配置的管理

服務器的準備

創建操作系統基線有如下幾種方法：

我們不會考慮完全手工過程，因爲它不具有可靠的重複性，所以也沒辦法擴展。

服務器的持續管理

一旦安裝好操作系統後，就要保證任何配置的修改都是以受控方式進行的。也就是說，首先確保除運維團隊之外，沒有人能登錄到這些服務器上，其次使用某種自動化系統來執行所有修改。這些修改包括應用操作系統的服務包（service pack）、升級、安裝新軟件、修改配置項，以及執行部署。

一旦這個系統準備好之後，就能用一個被集中版本控制的配置管理系統對基礎設施中的所有測試環境和生產環境進行管理了。之後，就可得到如下收益：

中間件的配置管理

在操作系統的配置項被恰當地管理起來後，就需要考慮在其之上的中間件的配置管理了。

管理配置項

數據庫模式（schema）、Web 服務器的配置文件、應用服務器的配置信息、消息隊列的配置，以及爲了系統能正常工作需要修改的其他方面都應該進行版本控制。

產品研究

在尋找低成本、低消耗的解決方案時，最好的着手點是絕對確保該中間件產品具有自動配置的選項。細心地讀一下說明文檔，找到這類選項，在互聯網上搜索一些建議，與產品的技術支持人員聊一下，並在論壇或羣組中徵求一下意見。

考查中間件是如何處理狀態的

如果已經確定所用中間件的確不支持任何形式的自動化配置，接下來就要看看是否能夠通過對該產品後臺的存儲方式做版本控制了。

大多數產品會用某種形式的文本文件來爲其存儲配置信息，那麼你將面對的主要問題是該產品如何以及何時讀取相關的配置信息。在那些對自動化提供友好支持的情況下，只要複製這些文件的最新版本到正確的位置就夠了。如果這樣可行的話，就能夠進行下一步工作，將該產品的二進制包與它的配置相分離。

查找用於配置的 API

很多產品會提供某種可編程接口。有些產品會提供一些 API 足以讓你對系統進行配置，滿足你的需求。一種策略是自己爲系統定義一個簡單的配置文件。創建自定義的構建任務來解釋這些腳本，並使用 API 對系統進行配置。

使用更好的技術

理論上，你可以嘗試一些其他方法。例如，自行創建有利於版本控制的配置信息，然後寫一些代碼，通過產品自身的使用方式把它們映射到你所選產品的配置上。

基礎設施服務的管理

經常看到一些已經成功通過部署流水線並正在生產環境中運行的軟件因爲基礎設施服務的問題（比如路由、DNS 和目錄服務）而不能正常工作的情況。

我們有如下幾個建議：

虛擬化

虛擬化有助於減少部署軟件所花費的時間，並用一種不同的方式來降低與部署相關的風險。就在系統的寬度與深度兩方面達到高效配置管理來說，部署領域中虛擬機的使用幫了很大的忙。

虛擬環境的管理

虛擬機技術的最重要特性之一就是一個虛擬機映像只是一個文件。這個文件叫做 “磁盤映像”。磁盤映像的好處在於可以複製它們，並對它們進行版本控制。

如果有虛擬化基礎設施，那麼就可以創建一個已準備好的服務器的磁盤映像，把它作爲所有具有相同配置的服務器的模板。這些模板組成了基線，一個已知處於良好狀態的環境版本。在這個版本上，其他所有配置和部署都可以正常運行。

虛擬環境和部署流水線

部署流水線的目的是，對應用程序做的每個修改都能通過自動化構建、部署和測試過程來驗證它是否滿足發佈要求。

用虛擬環境做高度的並行測試

虛擬化提供了一種絕好的方法來處理多平臺測試。只要爲應用程序可能運行的每種平臺創建虛擬機，並在其上創建 VM 模板。然後在所有這些平臺上並行運行部署流水線中的所有階段（驗收、容量和 UAT) 就行了。現代持續集成工具對這種方法都提供直接支持。

可以使用同樣的技術讓測試並行化，從而縮短代價高昂的驗收測試及容量測試的反饋週期。假設所有的測試都是獨立的，那麼就可以在多臺虛擬機上並行執行它們。

雲計算

在雲計算中，信息存儲在因特網中，並通過因特網上的軟件服務進行讀取和使用。雲計算的特徵是：通過擴展所使用的計算資源（比如 CPU、內存、存儲等）來滿足需求，而只需要爲自己所使用的這些資源付費就行了。雲計算既包括它所提供的軟件服務本身，也包括這些軟件所用到的軟硬件環境。

雲計算的大體上分爲三類：雲中的應用、雲中的平臺和雲中的基礎設施。

雲中基礎設施

雲中基礎設施是最高層次的可配置性，比如 AWS。

AWS 提供了很多基礎設施服務，除了著名的名爲 EC2 的虛擬機託管服務以外，還包括消息隊列、靜態內容託管，流媒體託管，負載均衡和存儲。利用這些服務，幾乎可以對系統進行完全控制，但也要做一些工作把這些東西綁定在一起。

雲中平臺

雲中平臺的優點：

基礎設施和應用程序的監控

確切瞭解生產環境中正在發生什麼事情是非常關鍵的，原因有三。首先，如果有實時的商業智能（BI），業務人員可以更快地從他們的策略得到反饋，比如產生了多少收入，這些收入來自哪裏。其次，當出了問題時，需要立即通知運維團隊有事情發生，並利用必要的工具追溯事件的根因並修復它。最後，出於計劃目的，歷史數據也非常重要。

收集數據

收集什麼樣的數據？監控數據的來源可能有以下幾個：

記錄日誌

日誌也是監控策略的一個必要組成部分。操作系統和中間件都會有日誌，對於瞭解用戶的行爲和追蹤問題根源非常有用。

應用程序也應該產生高質量的日誌。尤其重要的是注重日誌級別。大多數日誌系統有幾個級別，比如 DEBUG 、INFO 、WARNING 、ERROR 和 FATAL 。

建立信息展示板

就像使用持續集成的開發團隊那樣，運維團隊也應該有一個大且易見的顯示器。如果有任何突發事件，都可以在上面高亮顯示。當出問題時，就可以查看細節找到問題原因。

你能監控的信息有數千種之多，所以提前規劃一下，讓運維信息展示板不要太雜亂還是非常必要的。

行爲驅動的監控

就像開發人員通過寫自動化測試做行爲驅動開發來驗證應用程序的行爲那樣，運維人員也能寫自動化測試來驗證基礎設施的行爲。

小結

在本章中提出的建議以及描述的那些策略肯定會增加創建部署流水線的複雜性。它們可能會迫使你找出一些具有創造性的方法來解決第三方產品對配置管理的侷限性問題。但是，如果你正在創建一個大而複雜的系統，並有很多配置點，還可能會使用了很多種技術，那麼這個方法就可以拯救你的項目。

假如比較容易做到基礎設施的自動化，而且成本很低，那麼誰都會想這麼做，最好能直接創建一個生產環境的副本。答案顯然就不必說了。可是，假如它是免費的，那麼誰都會這麼做。因此，對於在任何時刻都能完美重建任何環境的能力，我們唯一在意的問題就是它的成本。因此，在免費和非常高的成本之間的平衡點在哪兒纔是值得我們考慮的。

確保從項目一開始就有基礎設施管理策略，並讓開發團隊和運維團隊的干係人蔘與其中。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/RUWK1PZO3YzQXWYPSSxRHw

猜你喜歡