sre: finish good postmortem

src/feedback/site-reliability-workbook/postmortem-culture.md

@@ -134,7 +134,7 @@ sendToDecom({
 
 無。
 
-### 為什麼文件寫得是糟
+### 為什麼這份文件寫得糟
 
 災難的價值在於好的事後析誤，正因如此，我們花時間去撰寫這份文件，將變得至關重要。
 閱讀者在看這份文件時，應該要清楚事件的脈絡，更重要的是能從事件中學到些什麼。
@@ -495,6 +495,55 @@ IRC 的日誌
 
 > *隱藏的圖片，說明人工和自動化復原的比例*
 
+### 為什麼這份文件寫得好
+
+一份好的事後析誤文件要能快速、精準、和善的。
+
+#### 清晰的段落
+
+各個段落的內容分段清楚而富含細節，例如：
+
+-   詞彙表，讓更多人有機會參與；
+-   後續優化，這個大型事件有很多優化空間，透過分門別類讓他更容易分派工作和權衡；
+-   可量化指標，足夠的數據和圖片，並且附上原始資料的連結。
+
+#### 具體的後續優化
+
+-   權責歸屬，明確指定所屬者和票號；
+-   優先程度，分清優先程度來有效追蹤這些優化實作；
+-   量化實作，例如設計新的告警檢視是否超過 *xx%* 的機器下線了；
+-   分類屬性，例如預防性和緩解型。
+
+#### 不責怪單一人員的行文
+
+文件專注在系統設計的不完善，而非人為操作的失誤：
+
+-   我們沒做好，並沒有人員被點名並責怪；
+-   根因和觸發點，專注在「什麼東西」沒弄好，而非「誰」沒弄好；
+-   後續優化，專注在改善服務，而非改善人員。
+
+#### 足夠的深度和廣度
+
+並非專注在特定團隊的改善，而是透過多的服務的角度來思考：
+
+-   影響，這段在很多不同角度中提出說明，讓他影響範圍更客觀；
+-   根因和觸發點，從系統到程式碼的實作，提供足夠細節的說明；
+-   資料導向的總結，所有的總結都是基於事實和資料，並提供原始資料的連結；
+-   附錄，提供更多圖片讓非專業人員能快速理解差異和影響。
+
+#### 文件撰寫快速
+
+文件撰寫的越早，越精準，這是因為人們的記憶更鮮活。
+除此之外，當事件發生後，所有受影響的工程、主管、投資者，
+都會想要確保事件真的被解決了，否則隨著時間推進，他們會對你的產品有一些各自的想像和不信任。
+
+這篇事後析誤文件在事件發生後的不到一個禮拜，就完成了。
+
+#### 精準的描述
+
+這是一個大型事件，理論上會有很多的資料：原始資料、系統日誌記錄、人員通訊紀錄等等。
+這篇文件透過總結、圖片、和連結來讓 *冗贅性* 和 *可讀性* 之間達到平衡。
+
 ## 結論
 
 歷程大致是：