前言

在咨詢的經(jīng)歷中，發(fā)現(xiàn)有些軟件項(xiàng)目經(jīng)常出現(xiàn)線上事故，出現(xiàn)了線上事故之后，第一時(shí)間會(huì)去修復(fù)這個(gè)問(wèn)題，第二時(shí)間，則是問(wèn)責(zé)。

這是一個(gè)很有意思的現(xiàn)象，通常在一些傳統(tǒng)行業(yè)的團(tuán)隊(duì)或者政府背景的團(tuán)隊(duì)中，發(fā)生了線上事故，他們會(huì)啟動(dòng)問(wèn)責(zé)程序，找到事故的負(fù)責(zé)人，并對(duì)他做出相應(yīng)的處罰。

作為程序員，大家都知道，代碼的世界不出錯(cuò)是不可能的。問(wèn)責(zé)在很大程度上會(huì)導(dǎo)致團(tuán)隊(duì)成員不敢寫代碼，不敢上線，不敢觸碰線上環(huán)境的一切東西，最終導(dǎo)致團(tuán)隊(duì)研發(fā)效率下降。

那正確的做法應(yīng)該是什么呢？

這里就給大家介紹一下Blameless Postmortem，中文意思就是無(wú)過(guò)錯(cuò)驗(yàn)尸報(bào)告。

什么是無(wú)過(guò)錯(cuò)驗(yàn)尸報(bào)告？

無(wú)過(guò)錯(cuò)驗(yàn)尸報(bào)告是對(duì)線上事故的書(shū)面記錄，用來(lái)描述:

• 這一線上事故的影響。
• 減輕或解決事故所采取的行動(dòng)。
• 事故的根本原因。
• 為防止該事故再次發(fā)生而采取的后續(xù)行動(dòng)。

無(wú)過(guò)錯(cuò)驗(yàn)尸報(bào)告這個(gè)名字是英文直譯過(guò)來(lái)的，如果覺(jué)得這個(gè)名字過(guò)于血腥，可以叫它無(wú)過(guò)錯(cuò)反思報(bào)告，或者無(wú)過(guò)錯(cuò)事故報(bào)告，或者無(wú)過(guò)錯(cuò)事后分析報(bào)告。但更多的人都習(xí)慣親切的叫它驗(yàn)尸報(bào)告。

之所以強(qiáng)調(diào)無(wú)過(guò)錯(cuò)，是因?yàn)檫@樣的話人們就不會(huì)在寫報(bào)告的時(shí)候由于害怕被問(wèn)責(zé)，從而互相埋怨或者隱藏自己的過(guò)錯(cuò)。

為什么需要無(wú)過(guò)錯(cuò)驗(yàn)尸報(bào)告？

驗(yàn)尸報(bào)告的目標(biāo)是了解所有導(dǎo)致事故的根本原因，記錄事故的經(jīng)過(guò)以供未來(lái)參考，并制定有效的預(yù)防措施以減少事故再次發(fā)生的可能性。

為了使驗(yàn)尸報(bào)告能夠有效地減少重復(fù)事故，總結(jié)過(guò)程必須激勵(lì)團(tuán)隊(duì)識(shí)別根本原因并修復(fù)它們。

同時(shí)，關(guān)注這個(gè)過(guò)程并確保它是有效的則需要組織中各級(jí)的承諾。比如不能出現(xiàn)對(duì)團(tuán)隊(duì)某個(gè)人的問(wèn)責(zé)。

什么時(shí)候需要無(wú)過(guò)錯(cuò)尸檢報(bào)告？

線上事故都會(huì)有嚴(yán)重程度或者影響程度分級(jí)，因此，通常我們只會(huì)對(duì)級(jí)別較高的事故寫尸檢報(bào)告。

我們通常會(huì)在下面兩個(gè)時(shí)間點(diǎn)開(kāi)始寫尸檢報(bào)告：

• 修復(fù)事故期間
• 修復(fù)事故之后

誰(shuí)完成驗(yàn)尸報(bào)告？

事故產(chǎn)生的服務(wù)所屬的交付團(tuán)隊(duì)共同負(fù)責(zé)完成驗(yàn)尸報(bào)告。

但需要選擇一名owner來(lái)主要負(fù)責(zé)編寫報(bào)告，并且這個(gè)owner需要保證下面兩件事情的發(fā)生：

1. 分配不同的人去完成各類的事故調(diào)研工作，最后把結(jié)果匯總給這個(gè)owner。
2. 保證報(bào)告中的改進(jìn)action按照緊急程度安排到后面相應(yīng)的迭代中。

如何跟蹤報(bào)告中的action？

這個(gè)問(wèn)題其實(shí)是緊接上面的第二條。

報(bào)告中的action通常分為兩類：

1. 根本原因改進(jìn)
2. 非根本原因改進(jìn)

對(duì)于報(bào)告中的每個(gè)action：

• 應(yīng)該在對(duì)應(yīng)的團(tuán)隊(duì)的backlog中建卡，并根據(jù)優(yōu)先級(jí)安排進(jìn)相應(yīng)的迭代。
• Owner要負(fù)責(zé)跟蹤卡的完成情況。并記錄到報(bào)告中。

驗(yàn)尸報(bào)告會(huì)議

驗(yàn)尸報(bào)告相關(guān)的會(huì)議有兩種。

1. 一種是在編寫報(bào)告前，用于討論事故的根因。
2. 一種是在報(bào)告完成后，用于向團(tuán)隊(duì)分享報(bào)告內(nèi)容，學(xué)習(xí)成長(zhǎng)。

不管是哪種會(huì)議，都要記住，這個(gè)會(huì)議不是批斗會(huì)，不能在會(huì)議中指責(zé)任何人。

這里的指導(dǎo)原則和retro類似。

實(shí)踐過(guò)程中，我發(fā)現(xiàn)大部分團(tuán)隊(duì)只會(huì)開(kāi)第一個(gè)會(huì)議，在編寫報(bào)告的過(guò)程中，大家基本上都學(xué)習(xí)了，并了解了報(bào)告中的根因。所以大部分團(tuán)隊(duì)都不會(huì)開(kāi)第二個(gè)會(huì)議。

但是不少公司會(huì)開(kāi)另外一種會(huì)議，就是報(bào)告寫完了之后給領(lǐng)導(dǎo)的匯報(bào)會(huì)議，此會(huì)議根據(jù)不同公司的政策不同，可有可無(wú)。

報(bào)告模版

下圖就是一個(gè)完整的報(bào)告模版。

報(bào)告可以是表格的形式，也可以是文檔的形式。有了模版，寫報(bào)告的人就可以照著模版往里面填內(nèi)容了。

驗(yàn)尸報(bào)告

關(guān)于如何識(shí)別根因，Atlassian提供了一種叫5 Whys的分析方法，具體怎么做可以參考這里：

https://www.atlassian.com/team-playbook/plays/5-whys#instructions

總結(jié)

驗(yàn)尸報(bào)告是為了在軟件開(kāi)發(fā)過(guò)程中以及項(xiàng)目交付過(guò)程中能持續(xù)改進(jìn)，有記錄能存檔，并且成為知識(shí)沉淀的一部分。

所以它的形式可以根據(jù)團(tuán)隊(duì)的實(shí)際情況來(lái)。我見(jiàn)過(guò)有團(tuán)隊(duì)用表格來(lái)寫的，像上面模版那樣，也有直接寫卡上的，也有直接開(kāi)會(huì)畫(huà)在白板上然后拍下來(lái)的。

對(duì)于無(wú)過(guò)錯(cuò)驗(yàn)尸報(bào)告，大家在實(shí)踐過(guò)程中有任何疑問(wèn)，歡迎來(lái)找我討論。

參考資料

https://www.atlassian.com/incident-management/handbook/postmortems#what-is-post-mortem
https://www.atlassian.com/incident-management/postmortem/templates