資料包括效能指標、監控資料以及通過埋點得到的業務資料，而資料分析是體驗優化的最後一環。
通過資料來量化當前的工作，從而證明工作是否高效，優化是否有效等問題。
量化的工作包括程式碼質量和業務資料。
程式碼質量的資料來源於思維導圖中的效能指標和監控體系，包括 SLA、慢響應、前端錯誤、白屏和首屏時間等，以折線圖的形式描述趨勢變化。
因為我們組維護著大量的 Node 服務，所以指標中就會包含多個伺服器端資料。其中慢響應作為我們組的北極星指標。
所謂北極星指標，也叫第一關鍵指標，是指在產品的當前階段與業務/戰略相關的核心指標，一旦確立就像北極星一樣指引團隊向同一個方向前進。
1）SLA
SLA 是指服務質量保證，參考的指標是異常狀態碼介面佔比，即報 500、502、503 和 504 的介面。
其中 500 是程式碼錯誤，我們可以通過紀錄檔做排查。我們公司要求 SLA 的值要至少達到 5 個 9，即 99.999XX%。
如果要實現 6 個 9，按照我們公司每日的體量，每天只能允許 4 個以內的介面異常，維護成本比較大。
在 500 的錯誤碼中，監控介面佔據了 94% 左右，主要是因為上傳的資料量太大導致報錯，伺服器端限制 1M，最終在上傳時就做大小限制。
還有一個佔據了 6.2% 的錯誤介面主要是邏輯不夠嚴密，邊界條件沒有處理好，修復後就降到了 0。
502 是轉發的後端服務不存在，503 是沒有轉發或服務掛起，如果大量報，可以去找下運維。
504 是由後端服務出問題導致的超時引起的，例如資料庫因為一條耗時的查詢語句而被掛起。
2）慢響應
慢響應是那些響應時間超過 2 秒的介面，在內部又將慢響應分為對外業務慢響應和對內後臺慢響應，主要精力會放到對外業務上。
公司要求對外的慢響應占比要控制在萬分之 2 以內，對內就比較鬆，只要不是很慢，可以操作就行。
造成慢響應的原因有一種是內部邏輯慢，另一種是受呼叫的介面影響而變慢。
第一種就可以我們自己解決，第二種就需要找共同作業組配合解決了。
有一個佔了業務慢響應 67.4% 數量的監控列表介面，屬於前者，在內部會查詢一張 430W 的大表 6 次。
優化手段也很直接，就是減少查詢次數，降到 1 次，慢響應次數一下子減少了 95%。
還有個舉報介面，也屬於前者，這張表也比較大，增加查詢條件，觸發索引，就立竿見影的把速度提上來了。
該慢響應次數一下子減少了 90%。這兩個介面優化後，業務慢響應總佔比從萬分之 0.23 降低到萬分之 0.1。
有一個內容稽核的服務，由於架構缺陷導致優化成本很高，後面直接遷移後，後臺慢響應占比從最高的萬分之 98.13 降低到萬分之 9.79。
3）前端錯誤
前端錯誤就是通過監控系統蒐集到的錯誤紀錄檔，分為指令碼錯誤和通訊異常。
指令碼錯誤就是 JavaScript 的異常，例如用 undefined 當物件讀取屬性。
一個專案中的指令碼錯誤在修復後，從高峰的 4073 降低至246，減少了 93.96%，進一步的保障專案質量。
雖然也能蒐集影象請求的錯誤，但是卻不能獲取到錯誤原因，可能是用了代理或靜態伺服器偶爾的波動。
曾經在內容稽核的頁面，有段時間每日上報的影象錯誤最高達到 28827，之後動態的將影象質量降低 70%，錯誤上報量從降低至 1641。
通訊異常其實也是 500、502 和 504 介面，之前的介面異常數量會包括靜態資源以及內部的服務呼叫。
而此處的通訊異常只包含從使用者端發起的那部分介面，可以簡單理解為其子集，不過有時候發現 502 和 504 的統計兩邊會有略微差異。
4）白屏和首屏時間
白屏就是等待白屏的時間（FP），首屏更確切的說是首次有意義的內容載入時間（FMP）。
之前做過一套效能監控系統，白屏比較好計算，而首屏比較複雜，我們這邊採用最簡單的埋點的方式。
也就是手動的在某個階段記錄首屏時間，比較麻煩的是需要將線上頁面逐個新增，不過也沒多少個，所以還能接受這個笨辦法。
以首屏為例，1 秒內佔 72%左右，2 秒內佔 19% 左右，若以 1.2 秒為邊界的話，那優化的空間還是蠻大的。
初步排查後，發現主要慢在 DOM 解析，這讓我蠻詫異的，經過 Chrome DevTools 的效能分析後，定位到了指令碼尺寸上。
載入的指令碼有點多，並且有一個 chunk-vendors.js 指令碼還比較大，下載時間有點長。
因此在載入和執行時就會延長 DOM 的解析，影響白屏時間。
業務資料大多來源於分佈在頁面各處的埋點，經過資料分析後能得出各類報表，可以直觀的檢視業務是在增長還是下降亦或是持平。
在體驗優化後，檢視下相關資料的前後變化，就能知道此次優化是否成功了。
我們組的工作效率也是業務資料的一部分，但是這塊比較難量化，不可能通過程式碼行數來判別，因此就想到了需求提測率和雙月使用者滿意度評分。
1）需求提測率
公司每雙月會開一次需求討論會，羅列本雙月的需求。
我會以這份列表為基礎，自己再開一份線上列表，記錄所有需求的狀態，並且會將不在此列表中的零碎需求也記錄。
這份列表有 5 列，包括需求名稱、線上BUG數、功能點數量、狀態和備註。
其中狀態又包括設計、提測、上線、延期等，可以一眼就能反映出需求所處的階段。
線上 BUG 數就是字面意思，而功能點數量是 QA 提供的，他們在寫測試用例時就會有這個資料。
不過沒多久，線上 BUG 數和功能點數量沒有維護起來，因為很多管理後臺需求經常都不寫用例，而活動比較常規，結構差不多也就不會細寫。
線上 BUG 數因為每次都比較少的，偶爾會有幾個，所以也就不怎麼寫了。
我的需求提測率是按提測狀態來統計，而不是上線狀態。
因為有時候是需要多端聯調的，經常會碰到共同作業方因為種種原因無法配合聯調或延期。
提測是指 QA 可以驗收需求，所以要說明此處的聯調問題並不是指我們寫好介面，然後等伺服器端給介面。
而是比如我們完成管理後臺的前後端功能，提供資料來源，伺服器端沒有時間處理這批資料，類似於這種場景。
2）雙月使用者滿意度評分
這是一張問卷調查，滿分是 5 分，收集大家對我們組工作的反饋，對當前存在的問題可以做出針對性的優化。
需要填寫所處部門，需求型別（後臺或活動），是否達到預期，維度包括成果、溝通、響應等。
最後還有兩個可選項，就是填寫意見或建議，以及最想表揚的同學及其理由。
若是正面反饋，那自然很好；若是負面反饋，那就要總結。
在實際執行後，發現大家很少會提意見，每次的分值也差不多。
但是每次點名表揚的都比較多，大家對我們組的工作都比較滿意。
3）北極星指標
我們公司每個組都會有北極星指標（例如使用者新增數、XX營收、主動聊天率等），瞭解各個組的指標變化其實就能瞭解公司業務的變化。
公司每個組長都會要求填寫雙月的 OKR，OKR 的內容其實也是圍繞著北極星指標來的，閱讀每週的備註，也能瞭解些業務變化。
如果有條件的話，那些細分下來支撐北極星指標的各類核心指標也可以去了解下。
以會員為例，包括日付費人數、日下單量、首次充值人數、連續包月續訂人數、會員購買 UV 等。
在更好的理解業務後，並且有資料支撐，相信能更容易、更科學的找到真正需要優化的點，做到技術賦能業務增長。