在線問題根據出現時序的分類
做在線服務，有一個重要的指標就是有效時間或者說高可用性（high availability）。而保證這個指標通常的方法中，除了增加一些備份的候選服務（在主服務發生錯誤後，取代主服務的角色），就是最好能夠做到：
- 在用戶出現問題之前，發現問題，並且解決問題
- 在用戶問題出現後，單用戶並未發現出問題前，發現問題，並且解決問題
- 在用戶發現問題後，第一時間找到問題原因，並且解決問題
對應如上的三種場景，以下是結合本人的工作經驗，總結的三種解決方案：
- Proacitive Probe: 主動探測，針對第一場景，用自動化的程序模擬用戶的常用操作行爲，來檢測服務的反饋，如果發現問題，第一時間報警，通知在線服務工程師。這個方案主要針對每次新版本上線時所引入的bug，可以在用戶出現問題前第一時間發現
- Passive Monitor: 被動偵聽，針對第二場景，每個服務端駐留對應的偵聽程序，用於偵聽用戶的日誌和可能的服務反饋，根據設立的規則，發現異常後，第一時間通知在線服務工程師，對於某些意料範圍內的異常，還可以採取一定的修復措施，例如重啓服務等。這個解決方案，可以在用戶發現問題前處理問題，在用戶體驗感覺上，提升了有效時間。
- Log Parser: 強大的日誌查詢，分析工具，幫助在線工程師第一時間定位用戶反饋的錯誤。而且工具中可以集成以前類似問題的相關信息和解決方案，可以是工具中隨着時間的推移，例如大量的已有案例，從而帶有了一定的技能，爲在線工程師提供一些備選解決方案或建議。
在線問題的按難易程度的分類：
SaaS項目的特點是：
- 服務端拓撲結構複雜，包含太多的機器和服務
- 服務端數據龐大且複雜
- 迭代週期快
以上三點，決定了在測試環境中，基本不可能模擬線上的拓撲結構和龐大複雜的用戶數據，這也就意味着很多bug，在測試環境下很難或不可能被發現。而且迭代週期的加快，留給測試人員的時間也很少。所以，很多SaaS項目都引入了“線上測試（test in production）”的概念。而這個概念下，日誌的作用就非常重要和突出了。以下是按照bug出現的場景不同，所帶來的難以程度的不同，以及日誌在其中起到作用，越難解決的問題，越重要。
總結：
對於SaaS項目的質量監控，可以通過如下的一個閉環，來對項目的質量進行把控，每一部分所佔有的比例，需要根據每個項目的具體情況而定。
