Effective Engineer - Measure what you want to improve
July 09, 2017這篇是Effective Engineer - Measure what you want to improve章節的讀書筆記
一個好的評量方式有幾個目的
1.讓你知道你正確的目標 事半功倍 weekly active rate, response time, click-through rate等等 你才知道你的新feature是不是帶領你的product往對的方向前進
2.方便regression 有新的release都可以看那些metric有沒有問題
3.performance measure 一個好的metric還可以讓你知道你系統的表現如何 任何release會影響performance的都要審慎評估能不能上
4.是個很好評估leverage的方式 分子就變成delta metric 分母當然就是時間了
常常問自己兩個問題
是不是有方法去評量我現在做的事
如果我現在做的事沒有改變核心metric 那是代表這件事不值得做 還是某個metric應該要加進來評量？
選對metric很重要
作者提供幾個例子 一個metric的選擇會影響了團隊的走向
1.每個禮拜工作時數 vs 每個禮拜產值: 一開始以為工作越多 越有產值 但其實越後面花的時間邊際效益會下降 bug越來越多 所以評估產值比評估時間合理
2.點擊率和長點擊率: 當初在評估google search的好壞的時候 google選擇了用長點擊率 來看他是不是真的滿足了user的要求 如果只是看點擊率的話 很可能user點了好幾個link進去發現東西不對就出來 google還在沾沾自喜 所以長點擊率比較合理(就是點進去後看了一陣子)
3.Average response time vs P99: P99就是100個request裡面表現最差的那個人的response time 如果你有10000個request那就是第100慢的request的response time
這兩個metric的選擇會大大的影響了團隊進步的走向 如果是想要minimize Average response time, 那你會改動的是你compute的方式 但如果是要minimize P99 那你必須分析你的worst case scenario 而這通常是你的power user(手上有很多data要處理的user)
4.註冊人數 vs 註冊人數增長 後者才看得出一個公司是不是在成長
5.每週活躍用戶 vs 註冊後隨時間活躍用戶 每週活躍用戶 有可能你某個feature上了之後 某些user走了 某些user新加入 這就看不出來 另一個是user加入n個禮拜後的活躍情況 到底user是越用越多還是越用越少
以上例子說明了metric的選擇也會影響之後的團隊行為跟決定
那到底要怎麼選呢 有三個方面
1.Maximize impact: 選對於核心目標有最大影響的metric 通常公司的核心目標都是賺錢 那關於活躍用戶的指標都應該列為candidate
2.actionable: 這本書對於actionable寫得不夠明確 他寫說page views, total registered user等等的不屬於這類 但到底哪一類算呢？我上網找了一些資料 從Eurovps的文章找到了不錯的定義
Metrics that capture information that allow marketers to make informed decisions which lead to more sales and profits.
這篇文章裡面還列出了9個常見的actionable metric 有興趣的可以一看
3.responsive: 能夠快速得到feedback的metric也很重要 要是你做了一個decision一年才知道效果那就有點廢 但要是選了什麼performance gain per min 那也是沒什麼參考價值 noise太多
common sense要有
作者認為 對於所有engineer來說 這個表格要清楚 Latency Numbers Every Programmer Should Know
從memory access 1MB的data比從disk快120倍 比從1G的網路快40倍 等等 這些數字清楚 你可以在build你的系統之前大概知道performance
除了這些 你們公司product的QPS, growth rate等等都要有sense 只需要一些前置作業 就可以讓你的design比其他人更convincing 是個非常合理的投資
data的正確性
即使你完美列出了你想要的metric 要是data/metric的正確性有誤 或是我們習慣用自己喜歡的方式去詮釋資料 那就很容易會誤解 所以還必須要花些時間去驗證資料的正確性 作者給出幾點建議
1.把所有log記下來 之後再決定要不要用
2.build一些即時(real-time)的系統 可以及早發現問題
3.為你的analytics pipeline寫整合測試
4.即使有些data要等一個禮拜或一個月才看得出結論 還是可以盡早用手上現有的資料先看有沒有問題 把validate資料當作開發的一部分
5.用不同的方法去算同樣的metric: 驗算的概念
拿到錯誤的資料比沒有資料還要fail