關鍵應用的可觀測效能力設計應該引起關注

我以前比較關注IT基礎設施的可觀測性，因為這些年我們並沒有承擔應用系統開發的工作，更多的注重於IT基礎設施。不過我一直認為資料庫這樣的IT基礎設施與應用軟體一樣，都是程式，因此在IT基礎設施領域的一些方法針對應用軟體也是有效的。複雜的應用系統特別是平臺型的應用系統是十分複雜的，向外可能和網路、安全裝置、客戶端有關;本身又涉及複雜的業務邏輯和元件間的互動協同;向內與IT基礎元件甚至IT基礎設施相關聯。一個稍微大一點的平臺型應用系統，可能比一套分散式資料庫還複雜。

昨天參加了一個系統故障的分析會，最終定位了原因後再來分析問題並不困難，因為一個網路抖動觸發了一系列的問題，最終因為軟體設計方的一些小瑕疵導致了最終的問題。不過整個定位過程十分複雜，因為所涉及的網路、雲平臺、資料庫、中介軟體等環境十分複雜，一個個排查過來，就花了好幾個小時。對於一個關鍵的系統，這種定位速度是無法滿足運營的需求的。開發商十分坦誠的承認了軟體的缺陷是導致問題的根因，並提出了整改的方案。不過這並不能徹底的杜絕類似問題的發生。下一次另外一個BUG導致了新的問題的時候，還是需要如此冗長的排查過程。

這個平臺系統對於客戶來說十分關鍵，今後數百個大大小小的系統都要使用這個平臺，幾個小時的故障排查無法滿足使用者的SLA，因此如何提高問題排查的速度，甚至實現故障自愈是十分關鍵的。雖然目前使用的一些排查手段都可以做成自動化工具，不過哪怕所有的排查都自動化了，解決故障所需的時間仍然太長了。怎麼才能解決這個問題呢?

二十年前我曾經參與了某銀行的大前置IPP的研發，設計了IPC、多優先順序佇列、服務路由等模組，並親自動手編寫了共享記憶體管理模組。因為IPP是CORE BANKING的核心元件之一，因此在設計這個模組的時候在IPC層面做了大量的統計指標、故障偵測和故障自愈的設計。系統執行的狀態可以透過大量的統計資料得以反饋，而一些已知故障都能夠被後臺程式發現並實施預設的自愈程式，因此這套系統從出廠後就相當穩定。

從上面的案例可以看出，要想讓應用系統執行得更穩定，或者說要提高應用系統的業務連續性，應用的可觀測性至關重要。如果在設計階段，就能夠像資料庫等IT基礎設施一樣，設計大量的可觀測性介面，將日誌、指標、跟蹤能力原生態的實現出來，那就會大大的提高應用的可用性，也可以大大縮短應用故障時的故障定位時間。

應用的可觀測效能力來自於四個方面，日誌告警自不必說，所有的應用系統都會有各種日誌，應用軟體如果不能認認真真的寫日誌，那就喪失了快速定位問題的能力。不過應用系統的日誌更為複雜，不僅僅要考慮應用系統本身的日誌，還要關注其執行環境中的各個IT基礎設施的日誌，一個統一日誌工具是必不可少的。除了統一採集日誌外，還要實時的分析和處理日誌，將日誌中的關鍵資訊變成結構化的資料，以便於後續的自動化分析預警與根因定位。

指標體系是目前大多數應用系統中欠缺的東西，針對應用系統的特點，編制一套可用於故障分析與預警的指標體系其實相當重要。應用系統的指標一定要實用，要選擇能夠反映出系統執行健康狀態的資料作為指標。僅僅有指標還不夠用，還需要透過指標構建一系列的健康模型與故障模型。當某些現象發生時，可以自動告警。當故障發生時，也可以透過模型快速找到診斷路徑。

完成指標與模型後，就可以根據異常檢測、基線等方法發現其中的異常，並且動態生成各種運營事件，並透過各種規則引擎和演算法對這些事件進行聯動分析，從而對系統進行十分全面的健康分析與隱患預警。

在金融、證券、網際網路等企業中，平臺型的應用系統的可觀測性做得相對來說比較到位，而大多數傳統企業的系統中，這方面是比較薄弱的。隨著企業數字化轉型的深入，關鍵的平臺型應用會越來越多，其可靠性要求也越來越高，在系統中做好可觀測效能力設計也就越來越重要了。