本篇是一個教學文，主要分享 Metrics 這個概念，以及透過範例來介紹如何針對軟體部署以及事件管理來設定實用的 Metrics。
開頭作者先提了一個情境，團隊需要去設計 Metrics 來瞭解「部署後有多少個緊急的Bug需要被修復]
這個概念重要的點在於，如果該數字很高，可能意味者下列情境有問題
1. Quality Control
2. 應用程式開發流程
3. pre-release 的 smoke-testing
4. post-release checks
這類型的緊急問題通常都會團隊帶來重大的負擔，包括維運人員，開發人員以及測試人員都必須要轉換來幫忙修復，嚴重情況可能會導致SLA不如預期，名聲下降，降低預期收入等。
為了定義一個 Metrics，需要準備六個面向的敘述(示範)
1. Definition
定義三個欄位，分別是 ID/Name/Description
ID: xxx
Name: Urgent Bug Fix Count
Description: 軟體發佈後有多少個緊急的bug被修復
3. Justification
每個 Metrics 都必須解釋其為什麼被需要
5. Audience
誰會需要知道這個 Metric
7. Calculation
如何去計算該 Metrics，譬如百分比等。當前範例是總數，所以不需要特別處理
9. Interpretation
針對該 Metrics 去定義什麼叫做 Pass, Failed，以及什麼樣的範圍該稱為 Warning。
同時也要針對該數值的 Minimum/Maximum 去設定。
以上述範例來說
Pass: 0
Fail: > 2
Warning: 1<=count<=2
Minimum: 0
Maximum: 無上限
另外一種做法是可以加入一種獎勵機制，譬如
Gold Star: 0
Pass: 1
Warning: 2
Fail: >2
這樣的話可以給團隊一個鼓勵，如果沒有任何修復時代表做得很好，而不是單純地表示`PASS`，而是一個鼓勵的方式去感謝團隊的努力
11. Reporting
Metrics 的文件也必須要提到
1. Ownership
2. 回報該 Metrics 的頻率
3. 過去的表現如何
4. 當前表現如何
針對多個 Metrics，可以考慮透過分數與權重的方式將全部合併起來一起回報，針對每個 Metrics 的程度來給予不同的權重
詳細的文章概念可以參閱全文
https://marklowg.medium.com/designing-a-metric-for-software-delivery-or-incident-management-bf6a043b013f
