[[220216]]

【51CTO.com快譯】引言：在本文中，無論你使用什么工具來部署軟件，為了確保流暢進行，讓我們一起看看用于監(jiān)控的八個方面。

作為軟件開發(fā)人員，我們的最終目標是讓自己的辛勤工作能順利部署到生產(chǎn)環(huán)境中。如今憑借敏捷開發(fā)、DevOps和連續(xù)部署工具，我們已經(jīng)能夠讓此過程變得比以往更快速了！但是，我們需要記住的是：軟件部署更是一個過程，而非單一的事件。因此，作為該過程的一部分，你需要監(jiān)視生產(chǎn)環(huán)境中的各種服務器和應用程序，以確保每一步都能夠平穩(wěn)運行。

在本文中，我們將和你一起討論在軟件部署過程中應該監(jiān)控的八個關鍵方面。

1.了解你的錯誤率

程序錯誤是識別應用程序問題的***道防線。因此，在所有監(jiān)控范圍內(nèi)的服務器上，開發(fā)者需要收集出現(xiàn)的全部錯誤。這些錯誤將有助于準確定位那些在部署新的軟件應用時出現(xiàn)的問題。

當然，在部署過程中，它們還會產(chǎn)生大量的“噪聲”。比如：在部署的環(huán)節(jié)中，應用程序中途被重新啟動是很常見的情況。因此，這些都可能會導致大量的，諸如：SQL連接問題、線程中止異常、以及其他類型的短暫錯誤。

提示：在部署之前，掌握自己應用程序的標準錯誤率是非常重要的。這樣你就可以判斷出在部署之后，各種問題是成上升趨勢，還是仍然保持著正常的錯誤率。

提示：尋找那些你從未見過的、新的應用程序錯誤。有趣的是，那些新產(chǎn)生的、空的引用異常，SQL的超時，或其他出現(xiàn)的錯誤，都會隨著新的部署而浮出水面。所以你需要迅速找到它們，并為修復它們做好準備。

注意：請重點關注那些通過你的代碼本身所記錄下來的、由應用程序異常所產(chǎn)生的HTTP 4XX和5XX的錯誤。

2.比較Web流量和頁面加載時間

你的應用消耗了多少流量？其普通頁面加載時間是多少？這些都是你應該部署之前和之后需要監(jiān)測的關鍵指標。如果你突然碰到了大量的流入或流出數(shù)據(jù)，那么肯定是某處出了問題。

一般情況下，這種高額流量的涌入會意味著：用戶碰到了錯誤，而且無法在你的應用程序中跳轉(zhuǎn)到其他頁面。這同樣會降低你的網(wǎng)站的總體用戶體驗。

有時候你甚至還沒有開始進行部署，這類問題就已經(jīng)在應用程序自我顯現(xiàn)了。例如：如果你的應用程序使用了微服務的架構，或是用到了很多內(nèi)部HTTP的Web服務調(diào)用，那么在新的部署中，對于其他應用程序的下行流量則會有明顯的變化。因此，請留心觀察它們的流量水平，以確保不會發(fā)生顯著的變化。

3.追蹤你的應用性能指標或是客戶滿意度評分

監(jiān)測你的應用程序性能指標或客戶滿意度評分，是掌握其運行狀況的一種非常好的“號脈”方式。Stackify公司的Retrace產(chǎn)品就可以實現(xiàn)對客戶滿意度得分的自動跟蹤。

這些評分是基于各種Web請求的響應效率，即有多少是快速、停滯、緩慢、以及失敗得出的。通過簡單的數(shù)學公式，它可以幫助你了解到軟件的整體性能。可見，請求跟蹤是業(yè)內(nèi)的普遍實踐模式。

使用Stackify，我們的目標是要使評分達到99％。通過那些需要持續(xù)監(jiān)視的指標，你可能會發(fā)現(xiàn)在部署的過程中分數(shù)會略有下降。這并沒關系，只要你能保證在部署之后，分數(shù)能夠恢復到正常水平便可。

4.服務器的數(shù)量、負載和CPU使用率

就算部署到云端，CPU使用率和整體的服務器負載仍然是不可忽視的因素。有時候，略微的代碼變更就會導致CPU使用率和整體性能上的巨大差異。這種現(xiàn)象在那些能夠橫跨多臺服務器，以進行擴展的應用程序上尤為明顯。比如說：我們對于某處一些代碼的調(diào)整，就會直接導致在另一處整體服務器數(shù)量的減少。

因此，留意你所需要運行應用程序的服務器數(shù)量，以及各臺服務器上的CPU負載和它們的使用率是非常重要的。

5.數(shù)據(jù)庫和SQL查詢的性能

如果應用程序用到了SQL數(shù)據(jù)庫，那么你的每一次部署就需要考慮到所用SQL數(shù)據(jù)庫的各種變更因素了，其中包括：新增的SQL查詢和現(xiàn)有查詢的修改等方面。

你應該持續(xù)跟蹤那些被頻繁使用的SQL查詢和在數(shù)據(jù)庫服務器上對應使用量偏大的資源。

記?。河袝r候，就算是對SQL查詢的略微修改，也有可能會導致出現(xiàn)性能上的重要瓶頸！

6.各種與應用依賴性有關的性能

如今各種應用程序之間都有著廣泛的相互依賴性，包括：SQL與NoSQL數(shù)據(jù)庫、緩存、隊列、存儲、以及HTTP的Web服務等。因此，密切關注所有這些依賴性的性能狀態(tài)是非常重要的。與此有關的常見服務包括：Redis、Elasticsearch以及MongoDB等。

同樣地，就算是對應用代碼的略微修改，也可能會導致在你的生產(chǎn)環(huán)境中，諸如Redis或HTTP Web服務的顯著性能變化。因此，在有重大變更發(fā)生的時候，請你留意部署前后的性能差異。

7.內(nèi)部通信（Slack）

軟件部署成功的一個關鍵因素就是通信。如果使用Stackify，我們會在很大程度上依賴Slack作為公司內(nèi)部的各種通信的中樞，當然也包括所進行的部署。

我們會有一個#deployments的Slack通道，任何人都可以籍此監(jiān)控部署前、部署中和部署后的準確狀況。同時，我們也可以在部署的過程中使用Bamboo的自動化Slack警告提醒功能。

眾所周知，軟件部署并非簡單的一鍵推送。舉例而言，如果使用Stackify進行部署的話，我們必須首先將各種SQL的更改腳本推送到超過1000個數(shù)據(jù)表中。之后，我們還必須在自己的架構內(nèi)對10臺不同的Web和后臺服務的應用程序進行部署?？梢?，這是一個相當耗時的過程。

因此，在Slack的各個通道上進行有效的通信，將有助于項目組的每個人保持同步。任何人只要想監(jiān)控的某個進展，就都可以進行隨時追蹤。

8.回歸測試

在完成了新代碼的推送之后，我們進行一些***的回歸測試是很有必要的。它們既可以是自動化的綜合測試，也可以是我們自己進行的快速測試。對我自己而言，即使用到了像Retrace這樣的工具來全程監(jiān)控自己的應用程序，我也會自己登錄進去，在一些關鍵頁面上四處點擊一下，以求心理安慰和技術確認。

當然，許多組織也有自己的一整套流程去驗證發(fā)布，并進行回歸測試。他們一般會在QA階段反復進行多輪測試。同時，在告知客戶進行各種補丁的部署之前，他們通常也會針對各種bug的修復效果進行重復性的測試。

如果你已經(jīng)有了自動化的測試，那么對于它們的監(jiān)視正好適用于本文所涉及的內(nèi)容。如果沒有的話，請務必通過Slack的監(jiān)視，來順利完成各種最終的回歸測試與驗證。

總結

軟件部署是我們努力工作的一次成果檢驗。但是其錯誤代碼所包含的潛在風險也會讓我們倍感壓力。因此，我們持續(xù)對軟件進行全程監(jiān)控是非常有必要的。通過使用Retrace這樣的解決方案，我們將能夠快速定位新出現(xiàn)的問題，并能量化出錯率、性能等方面的異常。

原文標題：8 Things to Monitor During a Software Deployment，作者：Matt Watson

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】