深入探讨運維驅動的可監控性設計

“外部品質驗收驅動技術債務消除”的理念：

技術債務的形成往往是由于趕進度忽略了非功能品質特性而導緻的，由于内部品質的不佳（設計或代碼品質不高）導緻外部品質的低下。 傳統it領域通常有上線前的驗收測試，如果能夠在驗收測試過程中重點關注非功能需求的實作品質，則可以“由外而内”地驅動開發團隊在開發過程中重視和改善軟體系統的内部品質。

本文來嘗試詳細探讨一下怎麼個“驅動”法！

運維與開發的關注點不同，運維會更多地關注非功能需求。我們從非功能需求中的“可監控性”來展開看看，運維應該如何應用devops思想，驅動開發改善軟體系統的品質。 

一、什麼是可監控性？

首先我們來對可監控性作出定義：

可監控性是指系統的運作狀态、運作關鍵資訊、業務調用過程的透明化程度，資訊的可擷取、可輸出、可轉存儲程度。

系統的可監控性對于運維及時有效地進行故障定位、對于qa和開發進行缺陷定位及調試都至關重要，是以屬于devops技術領域的核心實踐範疇。

裝置、應用在上線以後，不僅要新增監控點，也要調整現有的相關監控。在系統的運作過程中，同樣要對運作的關鍵資訊，特别是業務調用過程加以監控，否則會造成系統故障無法預警，也難以定位問題原因。例如，由于新增程序但是沒有增加監控，導緻程序僵死卻渾然不覺；或者由于沒有針對系統積壓量的監控而導緻資料大量積壓卻沒有及時處理；或者由于關鍵環節沒有輸出監控資訊進而影響客戶感覺。

是以，可監控性可以從“上線變更監控”、“系統運作監控”和“業務感覺監控”這三方面進行規範。

二、監控的變更控制

現在一般稍具規模的系統運維都配備了各種各樣的監控工具，尤其是針對基礎設施（例如：主機、中間件、資料庫等層面）的監控，開源的nagios、zabbix等都實作了不錯的監控功能，新炬也有amp這類自動化運維平台支援廣泛類型的監控。

然而，随着系統的不斷上線變更，在缺乏有效實施devops規範流程的企業中，往往出現裝置、應用在上線變更時沒有明确相關的改動點，運維側沒有及時部署和調整監控的情況。例如，新增了某些裝置、新開啟了某個端口、新加了某個應用程序等，而運維缺乏詳細的變更清單，導緻忽略了監控的調整，後續生産出故障也無法及時定位到。

那麼監控的變更控制如何有效實施呢？我認為應該把監控也納入配置管理進行維護，從管理流程上進行優化：交維時開發需要送出完整的裝置、應用監控變更清單；qa和運維需要組織資源進行檢查驗證和确認，包括變更點的确認檢查、新舊監控點的差異對比，確定每個監控點有對應的監控說明（監控腳本或監控工具配置），確定每個監控點的有對應的監控資訊輸出。

納入監控配置管理的應該包括但不僅限于：

dns域名清單：應用、域名、vip位址、裝置端口、ip位址。 web與app調用關系清單：子產品、web執行個體名稱、app叢集組名稱。 程序清單：程序類型、程序描述、歸屬子系統、主機名、ip、主機使用者、應用部署目錄、日志目錄、監控腳本、啟動腳本、停止腳本。 接口清單：接口類型、程序描述、程序編碼、歸屬子系統、主機名、ip、主機使用者、應用部署目錄、啟動腳本、停止腳本、日志目錄、端口。

三、系統運作可監控性設計的驗收

系統運作的可監控性是指系統運作狀态、業務運作資訊、系統健康資訊的可觀測性、透明程度、資訊擷取的實時程度。

例如：系統定時發出心跳信号，用于判斷程序是否仍在工作。

為了實時監控系統的狀态，保證系統健康運作，系統在開發階段，需輸出系統的運作資料，或提供相關的通路接口，便于維護采集觀測。而運維與開發、qa應該在早期就一起（devops）分析定義和評審系統運作可監控性的需求和設計。

四、運維前移 – 系統運作可監控性需求分析與設計

在需求階段就應該作出系統運作可監控性的要求（運維前移），否則會造成以下問題：

1、如果需求沒有明确需要包含哪些可監控性的要求，那麼設計開發人員就不會在實作系統時加入可監控性的設計以及監控通路接口的實作。例如，業務積壓量的記錄和統計，這樣的話，後續運維過程中，一旦發生大量的業務積壓量，運維收到投訴，前端使用者通路緩慢、業務無法處理，但是也無從知道是否是業務積壓，積壓量有多少，故障範圍無法精确定位，瓶頸無法快速查找！

2、營運人員需要的業務處理量資訊，例如，業務通路量、高峰通路量、業務分類統計等資訊，也無法便捷地擷取到，對營運分析不利；另外，qa或測試人員如果想做業務性能模組化、業務等級劃分等工作也沒有精确的參考資料。

3、無法真正做到開發運維一體化，系統運維缺乏實時透明化的資料（對開發人員有意義的資料），例如系統出錯監控資訊缺乏，導緻開發無法及時響應故障診斷分析和處理；而反過來說，這些資料的缺失，其實是因為需求、設計階段就沒有考慮進去！

五、傳遞運維 – 系統運作可監控性的驗收驗證

交維的時候，qa和運維應該對系統運作可監控性設計對應的實作進行驗證檢查和确認驗收。系統運作的可監控性驗證應該包括但不限于以下内容：

心跳信号：系統定時發出簡單的消息（資料包），用于判斷程序是否仍然在工作。 登入量：系統記錄用戶端的登入資訊，包括登入賬号、登入時間、ip位址等，用于統計使用者數。 處理量：系統記錄業務處理資訊，包括業務類型、發生時間、處理時間、處理賬号、程序編号等，用于統計已經處理的筆數。 積壓量：系統記錄等待處理資訊，包括業務類型、發生時間等，用于統計等待處理的筆數。 錯誤量：系統記錄業務處理失敗資訊，包括業務類型、發生時間、報錯時間等，用于統計處理失敗的筆數。

我們可以把它們大緻分成幾類：

運作狀态類：例如，心跳信号等。 業務運作資訊類：例如，登入量、處理量、積壓量等。 系統健康狀态類：錯誤量等。

那麼，檢查驗收的具體方法呢？我覺得主要從完整性和有效性兩方面來檢查驗收：

通過對照需求、設計對系統運作可監控性的要求，對監控點的完整性進行檢查，例如，如果對系統的業務運作資訊有監控要求，那麼就看具體的要求有哪些，逐一對照系統實際的監控輸出，看該有的監控資訊是否都有，這個可以通過qa或測試進行冒煙測試、主業務流程的測試的同時，對日志檔案、監控接口通路、資料記錄表等監控資訊輸出位置進行檢查。 對于某些可監控性的檢查，例如系統健康狀态類，需要注意檢查其有效性，通過在驗收測試環境或準釋出環境中模拟錯誤的出現，例如網絡故障、程序故障等，觸發業務處理失敗，檢視相關監控點的輸出有效性，確定業務類型、錯誤發生時間等關鍵資訊得以儲存、友善統計分析。

對于某些檢查驗證，盡量形成自動化腳本（例如shell腳本、python腳本等），或借助自動化工具（例如soapui、selenium、robotframework等）實作，舉部分例子如下：

某系統的心跳信号的檢查，通過腳本發送心跳檢查通路接口的資料包，接收響應資料包，檢查程序是否工作。 某系統依賴ftp服務，通過腳本模拟使用者ftp登入，擷取傳回資訊，檢查是否提示正常登入。 某接口機屬于叢集，需要檢視某個節點狀态，檢查執行shell腳本：

六、業務感覺可監控性設計的驗收

業務感覺可監控性是指業務處理過程的關鍵環節資訊的可觀測性、透明程度、資訊擷取的實時程度。

例如：訂單流程涉及訂單錄入、優惠組合接口的查詢、支付接口的調用等關鍵環節，由唯一的辨別串聯，還原客戶的一筆完整業務交易過程，并将相關資訊輸出、存儲、統計分析。

七、運維前移 – 業務感覺可監控性需求分析與設計 

為了實作端到端的統一監控，提升客戶感覺，在系統開發階段，需在系統間、子產品間調用時，以及業務處理過程的關鍵環節中輸出足夠的監控資訊。而運維與開發、qa應該在早期就一起（devops）分析定義和評審系統業務感覺可監控性的需求和設計。

特别是，由于目前各層級之間的調用基于服務接口或函數，沒有辨別調用來源的唯一性，導緻一筆業務調用中的各環節無法串接成一個整體。是以，為串聯業務辦理過程的各個處理環節，應用軟體需要輸出可以用于串聯前後端處理環節的标簽。

目前比較火的apm工具，是從後端通過技術手段實作業務感覺、使用者體驗、業務流串聯分析，例如，借助中間件的jvm動态插樁分析，擷取java代碼調用流程，往資料庫送出的sql語句，由sessionid等标簽串聯并還原成客戶的業務調用流程。

這種方式無疑減輕了開發和運維在業務感覺體系設計方面的工作量，但是不可避免地會碰到一些技術上的問題，例如某些元件的開發技術不支援，資訊無法擷取，導緻串聯斷流。

是以，我建議還是要從根本上解決問題，在開發設計過程中就考慮業務感覺的可監控性設計，有了這樣的基礎資訊，後續運維自己開發統計分析平台或借組apm這類工具支撐業務感覺監控，都會友善很多！

八、傳遞運維 – 業務感覺可監控性的驗收驗證

交維的時候，qa和運維應該對業務感覺可監控性設計對應的實作進行驗證檢查和确認驗收。

業務感覺的設計需要重點考慮節點輸出和資訊完整性兩個方面：

1

節點輸出

每筆業務調用的所有服務或程式均需要輸出相關的監控資訊，如web應用、中間件、背景服務、其他應用程式等。這樣才能在運維過程中接到業務失敗投訴的時候，快速定位問題原因，出現故障的位置！

2

資訊完整性

監控輸出的資訊包括但不限于以下内容：可用于串聯各處理環節的标簽、使用者号碼、管道來源、操作工号、調用時間、響應時長、成功或失敗、詳細封包。其中特别是業務處理失敗時，要求必須輸出詳細的異常資訊，日志内容清晰完整，輔助定位問題原因。  

是以，對業務感覺可監控性的驗收驗證也要對照需求和設計，重點檢查節點輸出資訊的全面性，以及輸出資訊的完整性。

另外，對監控資訊的輸出性能（時效性）也要進行檢查，例如：延遲時間不高于3分鐘。

其次，對監控資訊存儲的方式也要做合規檢查，例如：

監控資訊支援的存儲方式完整性檢查（監控資訊支援檔案、資料庫表等多種儲存格式）。 監控資訊存儲正确性檢查。

最後，還要對開啟業務感覺監控對系統性能影響進行驗證評估。

例如：在驗收測試環境或準釋出環境進行兩輪測試，第一次不開啟業務感覺監控，第二次開啟，對比兩次測試的性能結果，確定業務感覺監控資訊的輸出不對系統的處理能力帶來較大的影響（例如：處理能力和資源消耗損失在3%以内） 

九、小結

本文從可運維性角度，結合運維前移的理念，強調需求設計階段對非功能需求中的運維可監控性進行詳細考慮的必要性，并提出交維階段對可監控性設計和實作的驗收驗證方法、技術和工具的應用方法。

作者介紹   陳能技

【dba+社群】原創專家，新炬網絡首席apm架構師。

14年開發測試與品質架構經驗，擅長devops及apm、docker、持續內建、持續傳遞在企業中的落地實施。

著有《軟體性能測試診斷分析與優化》、《軟體自動化測試成功之道》、《深入淺出性能測試與loadrunner實戰》等書。

<b></b>

<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2016-04-12</b>