軟件生產(chǎn)環(huán)境系統(tǒng)監(jiān)控方案設(shè)計

1、 軟件生產(chǎn)環(huán)境系統(tǒng)監(jiān)控方案設(shè)計 架構(gòu)之家 微信號 itfly8功能介紹 ITFLY8架構(gòu)之家，專注于架構(gòu)知識分享交流，涵蓋項目管理和產(chǎn)品設(shè)計。包括大型分布式網(wǎng)站架構(gòu)（高性能，高可用，緩存，消息隊列.），設(shè)計模式，架構(gòu)模式，大數(shù)據(jù)，項目管理(SCRUM,PMP,Prince2)，產(chǎn)品設(shè)計等作為軟件開發(fā)人員，我們的最終目標(biāo)是讓自己的辛勤工作能順利部署到生產(chǎn)環(huán)境中。如今憑借敏捷開發(fā)、DevOps和連續(xù)部署工具，我們已經(jīng)能夠讓此過程變得比以往更快速了！但是，我們需要記住的是：軟件部署更是一個過程，而非單一的事件。因此，作為該過程的一部分，你需要監(jiān)視生產(chǎn)環(huán)境中的各種服務(wù)器和應(yīng)用程序，以確保每一步都能夠平

2、穩(wěn)運行。在本文中，將討論在軟件部署過程中應(yīng)該監(jiān)控的八個關(guān)鍵方面。1.了解你的錯誤率程序錯誤是識別應(yīng)用程序問題的第一道防線。因此，在所有監(jiān)控范圍內(nèi)的服務(wù)器上，開發(fā)者需要收集出現(xiàn)的全部錯誤。這些錯誤將有助于準(zhǔn)確定位那些在部署新的軟件應(yīng)用時出現(xiàn)的問題。當(dāng)然，在部署過程中，它們還會產(chǎn)生大量的“噪聲”。比如：在部署的環(huán)節(jié)中，應(yīng)用程序中途被重新啟動是很常見的情況。因此，這些都可能會導(dǎo)致大量的，諸如：SQL連接問題、線程中止異常、以及其他類型的短暫錯誤。提示：在部署之前，掌握自己應(yīng)用程序的標(biāo)準(zhǔn)錯誤率是非常重要的。這樣你就可以判斷出在部署之后，各種問題是成上升趨勢，還是仍然保持著正常的錯誤率。提示：尋找那些你

3、從未見過的、新的應(yīng)用程序錯誤。有趣的是，那些新產(chǎn)生的、空的引用異常，SQL的超時，或其他出現(xiàn)的錯誤，都會隨著新的部署而浮出水面。所以你需要迅速找到它們，并為修復(fù)它們做好準(zhǔn)備。注意：請重點關(guān)注那些通過你的代碼本身所記錄下來的、由應(yīng)用程序異常所產(chǎn)生的HTTP 4XX和5XX的錯誤。2.比較Web流量和頁面加載時間你的應(yīng)用消耗了多少流量？其普通頁面加載時間是多少？這些都是你應(yīng)該部署之前和之后需要監(jiān)測的關(guān)鍵指標(biāo)。如果你突然碰到了大量的流入或流出數(shù)據(jù)，那么肯定是某處出了問題。一般情況下，這種高額流量的涌入會意味著：用戶碰到了錯誤，而且無法在你的應(yīng)用程序中跳轉(zhuǎn)到其他頁面。這同樣會降低你的網(wǎng)站的總體用戶體驗

4、。有時候你甚至還沒有開始進(jìn)行部署，這類問題就已經(jīng)在應(yīng)用程序自我顯現(xiàn)了。例如：如果你的應(yīng)用程序使用了微服務(wù)的架構(gòu)，或是用到了很多內(nèi)部HTTP的Web服務(wù)調(diào)用，那么在新的部署中，對于其他應(yīng)用程序的下行流量則會有明顯的變化。因此，請留心觀察它們的流量水平，以確保不會發(fā)生顯著的變化。3.追蹤你的應(yīng)用性能指標(biāo)或是客戶滿意度評分監(jiān)測你的應(yīng)用程序性能指標(biāo)或客戶滿意度評分，是掌握其運行狀況的一種非常好的“號脈”方式。Stackify公司的Retrace產(chǎn)品就可以實現(xiàn)對客戶滿意度得分的自動跟蹤。這些評分是基于各種Web請求的響應(yīng)效率，即有多少是快速、停滯、緩慢、以及失敗得出的。通過簡單的數(shù)學(xué)公式，它可以幫助你了

5、解到軟件的整體性能?？梢姡埱蟾櫴菢I(yè)內(nèi)的普遍實踐模式。使用Stackify，我們的目標(biāo)是要使評分達(dá)到99。通過那些需要持續(xù)監(jiān)視的指標(biāo)，你可能會發(fā)現(xiàn)在部署的過程中分?jǐn)?shù)會略有下降。這并沒關(guān)系，只要你能保證在部署之后，分?jǐn)?shù)能夠恢復(fù)到正常水平便可。4.服務(wù)器的數(shù)量、負(fù)載和CPU使用率就算部署到云端，CPU使用率和整體的服務(wù)器負(fù)載仍然是不可忽視的因素。有時候，略微的代碼變更就會導(dǎo)致CPU使用率和整體性能上的巨大差異。這種現(xiàn)象在那些能夠橫跨多臺服務(wù)器，以進(jìn)行擴(kuò)展的應(yīng)用程序上尤為明顯。比如說：我們對于某處一些代碼的調(diào)整，就會直接導(dǎo)致在另一處整體服務(wù)器數(shù)量的減少。因此，留意你所需要運行應(yīng)用程序的服務(wù)器數(shù)量，

6、以及各臺服務(wù)器上的CPU負(fù)載和它們的使用率是非常重要的。5.數(shù)據(jù)庫和SQL查詢的性能如果應(yīng)用程序用到了SQL數(shù)據(jù)庫，那么你的每一次部署就需要考慮到所用SQL數(shù)據(jù)庫的各種變更因素了，其中包括：新增的SQL查詢和現(xiàn)有查詢的修改等方面。你應(yīng)該持續(xù)跟蹤那些被頻繁使用的SQL查詢和在數(shù)據(jù)庫服務(wù)器上對應(yīng)使用量偏大的資源。記?。河袝r候，就算是對SQL查詢的略微修改，也有可能會導(dǎo)致出現(xiàn)性能上的重要瓶頸！6.各種與應(yīng)用依賴性有關(guān)的性能如今各種應(yīng)用程序之間都有著廣泛的相互依賴性，包括：SQL與NoSQL數(shù)據(jù)庫、緩存、隊列、存儲、以及HTTP的Web服務(wù)等。因此，密切關(guān)注所有這些依賴性的性能狀態(tài)是非常重要的。與此有

7、關(guān)的常見服務(wù)包括：Redis、Elasticsearch以及MongoDB等。同樣地，就算是對應(yīng)用代碼的略微修改，也可能會導(dǎo)致在你的生產(chǎn)環(huán)境中，諸如Redis或HTTP Web服務(wù)的顯著性能變化。因此，在有重大變更發(fā)生的時候，請你留意部署前后的性能差異。7.內(nèi)部通信（Slack）軟件部署成功的一個關(guān)鍵因素就是通信。如果使用Stackify，我們會在很大程度上依賴Slack作為公司內(nèi)部的各種通信的中樞，當(dāng)然也包括所進(jìn)行的部署。我們會有一個#deployments的Slack通道，任何人都可以籍此監(jiān)控部署前、部署中和部署后的準(zhǔn)確狀況。同時，我們也可以在部署的過程中使用Bamboo的自動化Slack

8、警告提醒功能。眾所周知，軟件部署并非簡單的一鍵推送。舉例而言，如果使用Stackify進(jìn)行部署的話，我們必須首先將各種SQL的更改腳本推送到超過1000個數(shù)據(jù)表中。之后，我們還必須在自己的架構(gòu)內(nèi)對10臺不同的Web和后臺服務(wù)的應(yīng)用程序進(jìn)行部署?？梢?，這是一個相當(dāng)耗時的過程。因此，在Slack的各個通道上進(jìn)行有效的通信，將有助于項目組的每個人保持同步。任何人只要想監(jiān)控的某個進(jìn)展，就都可以進(jìn)行隨時追蹤。8.回歸測試在完成了新代碼的推送之后，我們進(jìn)行一些最后的回歸測試是很有必要的。它們既可以是自動化的綜合測試，也可以是我們自己進(jìn)行的快速測試。對我自己而言，即使用到了像Retrace這樣的工具來全程監(jiān)控自己的應(yīng)用程序，我也會自己登錄進(jìn)去，在一些關(guān)鍵頁面上四處點擊一下，以求心理安慰和技術(shù)確認(rèn)。當(dāng)然，許多組織也有自己的一整套流程去驗證發(fā)布，并進(jìn)行回歸測試。他們一般會在QA階段反復(fù)進(jìn)行多輪測試。同時，在告知客戶進(jìn)行各種補丁的部署之前，他們通常也會針對各種bug的修復(fù)效果進(jìn)行重復(fù)性的測試。如果你已經(jīng)有了自動化的測試，那么對于它們的監(jiān)視正好適用于本文所涉及的內(nèi)容。如果沒有的話，請務(wù)必通過Slack的監(jiān)視，來順利