在任何有一定規模的企業內部，一旦推行起來整個SRE的運維模式，那麼對於可觀測性系統的建設將變得尤為重要，而在整個可觀測性系統中，通常我們會分為如下三個方面：
指標監控：即各種指標監控，比如基礎資源指標，服務效能指標，業務的呼叫指標。
日誌：各種裝置以及服務的執行日誌監控。
呼叫鏈：業務層面的呼叫鏈分析，通常在分散式系統中幫助運營、開發以及運維人員快速識別整體呼叫的瓶頸點
一整套的可觀測系統，它能確保你洞察系統，跟蹤系統的健康狀態、可用性以及系統內部發生的事情。對於整個可觀測系統的建設，需要注意如下兩點：
確定質量標準是什麼，並確保系統持續逼近或保持在質量標準極限範圍內
系統地關注這項工作—而不應該只是隨機地檢視一下系統
在整個企業級可觀測系統中，我認為至少應該包括如下幾個特徵：
完備指標採集：可以對接企業內大部分的裝置與技術棧相應的監控指標；同時，支援常見裝置的監控指標體系，可以快速接入監控裝置和指標，避免所有裝置監控都是從頭構建；對於日誌資料的採集支援
海量裝置支援：企業IT系統數量和規模越來越大，因此監控系統比以前需要監控海量裝置監控。
監控資料儲存和分析：監控資料是運維分析、運維自動化和智慧化的基礎，因此海量監控資料儲存以及基於監控資料的視覺化分析是一個監控系統的基本能力。
可觀測系統是整個運維體系的基礎，它需要提供整個運維體系的資料化支援。
因此，一個企業級的可觀測性系統應該是平臺化的。一方面可以透過配置或者開發實現更多 運維指標的接入；另一方面，亦可對接更多的專業運維工具，整合並打通多元的運維資料，為更多運維場景提供資料服務。從整體上，可觀測性系統為企業運維提供了一個數據基礎，讓我們對事故響應以及容量預測等方面更多使用資料而非憑藉以往經驗和拍腦袋做出決策。
故障響應
如果有什麼東西出了故障，該如何提醒大家並做出迴應？工具可以幫助解決這個問題，國為它可以定義提醒人類的規則。故障響應是建立在使用可觀測性系統構建的資料之上，並藉助反饋迴圈，來幫助我們加強對服務的監控。故障響應通常包含如下幾個動作:
關注: 不論是主動發現瓶頸點或異常點，還是透過可觀測性系統被動暴露瓶頸點，我們都應該進行主動關注
交流: 及時將觀察到風險點通知到相關方，並告知影響面以及相關的補救措施
恢復: 三方達成一致後，根據補救措施進行修復相關風險點和異常點
需要注意的是，如果在前期整個可觀測性系統能夠做好，通常故障應當始於一個簡單的告警資訊或一個報障電話，因此，通常情況下，可觀測系統做的足夠好僅能起到追溯和排查的作用，但是無法起到及時發現的作用，此時就需要依賴於各個觀測資料進行計算和評估告警，以及時將相關的告警通知到相關人，以暴露風險點。告警只是整個故障響應的第一個環節，解決的是故障如何發現的問題，而大多數的故障響應工作都是關於定義處理策略和提供培訓的，以便人們在收到警報時知道該怎麼做，通常這部分更多的是過去歷史經驗和運維經歷的總結和沉澱，包括經驗的一些抽象和工具化沉澱，以保證故障響應的效率和普遍化(即不依賴人為經驗)。
而對於整個告警系統來說，需要確保的是告警的有效性，否則，整個報警系統很有可能淪落為垃圾資料製造機，告警有效性意味著需要滿足如下兩個需求：
告警及時性: 系統有問題需要及時透過告警資訊告知運維處理人員及時處理告警;
告警準確性: 只要有告警資訊系統必然出現問題(對於很多企業可能存在大量的無用告警，比如磁碟問題，mem等相關問題，當然這裡涉及到了自動化、業務形態、告警閾值的問題);
在整個運維過程中，我們經常會發現有大量的無關緊要的告警資訊，讓運維人員的注意力迷失在告警海洋當中，而通常非運維領域的領導會關注整個告警的響應程度，因此，抑制和消除無效的告警，讓運維人員不被告警風暴所吞沒，也是告警管理中重點建設的內容。通常情況，在我們的各個可觀測系統構建完成後，可以透過整合到監控平臺中的各種監控資料，應用趨勢預測、短週期檢測、間歇性恢復、基線判斷、重複壓縮等演算法和手段實現告警壓縮收斂，強化告警的有效性。
在任何有一定規模的企業內部，一旦推行起來整個SRE的運維模式，那麼對於可觀測性系統的建設將變得尤為重要，而在整個可觀測性系統中，通常我們會分為如下三個方面：
指標監控：即各種指標監控，比如基礎資源指標，服務效能指標，業務的呼叫指標。
日誌：各種裝置以及服務的執行日誌監控。
呼叫鏈：業務層面的呼叫鏈分析，通常在分散式系統中幫助運營、開發以及運維人員快速識別整體呼叫的瓶頸點
一整套的可觀測系統，它能確保你洞察系統，跟蹤系統的健康狀態、可用性以及系統內部發生的事情。對於整個可觀測系統的建設，需要注意如下兩點：
確定質量標準是什麼，並確保系統持續逼近或保持在質量標準極限範圍內
系統地關注這項工作—而不應該只是隨機地檢視一下系統
在整個企業級可觀測系統中，我認為至少應該包括如下幾個特徵：
完備指標採集：可以對接企業內大部分的裝置與技術棧相應的監控指標；同時，支援常見裝置的監控指標體系，可以快速接入監控裝置和指標，避免所有裝置監控都是從頭構建；對於日誌資料的採集支援
海量裝置支援：企業IT系統數量和規模越來越大，因此監控系統比以前需要監控海量裝置監控。
監控資料儲存和分析：監控資料是運維分析、運維自動化和智慧化的基礎，因此海量監控資料儲存以及基於監控資料的視覺化分析是一個監控系統的基本能力。
可觀測系統是整個運維體系的基礎，它需要提供整個運維體系的資料化支援。
因此，一個企業級的可觀測性系統應該是平臺化的。一方面可以透過配置或者開發實現更多 運維指標的接入；另一方面，亦可對接更多的專業運維工具，整合並打通多元的運維資料，為更多運維場景提供資料服務。從整體上，可觀測性系統為企業運維提供了一個數據基礎，讓我們對事故響應以及容量預測等方面更多使用資料而非憑藉以往經驗和拍腦袋做出決策。
故障響應
如果有什麼東西出了故障，該如何提醒大家並做出迴應？工具可以幫助解決這個問題，國為它可以定義提醒人類的規則。故障響應是建立在使用可觀測性系統構建的資料之上，並藉助反饋迴圈，來幫助我們加強對服務的監控。故障響應通常包含如下幾個動作:
關注: 不論是主動發現瓶頸點或異常點，還是透過可觀測性系統被動暴露瓶頸點，我們都應該進行主動關注
交流: 及時將觀察到風險點通知到相關方，並告知影響面以及相關的補救措施
恢復: 三方達成一致後，根據補救措施進行修復相關風險點和異常點
需要注意的是，如果在前期整個可觀測性系統能夠做好，通常故障應當始於一個簡單的告警資訊或一個報障電話，因此，通常情況下，可觀測系統做的足夠好僅能起到追溯和排查的作用，但是無法起到及時發現的作用，此時就需要依賴於各個觀測資料進行計算和評估告警，以及時將相關的告警通知到相關人，以暴露風險點。告警只是整個故障響應的第一個環節，解決的是故障如何發現的問題，而大多數的故障響應工作都是關於定義處理策略和提供培訓的，以便人們在收到警報時知道該怎麼做，通常這部分更多的是過去歷史經驗和運維經歷的總結和沉澱，包括經驗的一些抽象和工具化沉澱，以保證故障響應的效率和普遍化(即不依賴人為經驗)。
而對於整個告警系統來說，需要確保的是告警的有效性，否則，整個報警系統很有可能淪落為垃圾資料製造機，告警有效性意味著需要滿足如下兩個需求：
告警及時性: 系統有問題需要及時透過告警資訊告知運維處理人員及時處理告警;
告警準確性: 只要有告警資訊系統必然出現問題(對於很多企業可能存在大量的無用告警，比如磁碟問題，mem等相關問題，當然這裡涉及到了自動化、業務形態、告警閾值的問題);
在整個運維過程中，我們經常會發現有大量的無關緊要的告警資訊，讓運維人員的注意力迷失在告警海洋當中，而通常非運維領域的領導會關注整個告警的響應程度，因此，抑制和消除無效的告警，讓運維人員不被告警風暴所吞沒，也是告警管理中重點建設的內容。通常情況，在我們的各個可觀測系統構建完成後，可以透過整合到監控平臺中的各種監控資料，應用趨勢預測、短週期檢測、間歇性恢復、基線判斷、重複壓縮等演算法和手段實現告警壓縮收斂，強化告警的有效性。