iT邦幫忙

2021 iThome 鐵人賽

DAY 11
0
DevOps

Dev's Ops 啟程系列 第 11

[Day 11] SRE - 事後檢討,拜託拜託讓我吸個經驗值

從歷史中學習

我們最討厭事件歷史重演QQ
在每次遇到問題後,我們全員都會一起開個檢討會議,當中會提到問題發生的根源,是否會再發生?是否能自動化?是否有介面 or API可以操作解決?
如果會再發生,且能自動化尚未自動化的話,我們就會馬上進行開發,以降低on-call人員的壓力,反之如果無法自動化,就要看是否有介面或者有提供API之類的?可以讓on-call人員操作,並列在定期演練計畫事件內,此事件就會成為歷史事件,以後就可以透過演練歷史事件,去預防去訓練大家,讓大家從歷史中學習。

避免指責,提拱建設性意見

對事不對人,不指責他人,對於問題提出好的解決辦法。


協同合作與知識共享

及時溝通合作,團隊溝通,團隊成長!


建立事後檢討文化

當你的團隊沒有建立過事後檢討的文化時,其實可以自己找幾個人先模擬一次,再度找幾個人再度模擬一次,最後找大家一起參與一次,慢慢的帶領大家有了習慣這種文化,告訴他們檢討的好處,讓他們也想自主的驅動是最棒的。


公開獎勵做正確事的人

主管或團隊成員會在公眾場合獎勵在危機事件處理得恰當的人,對於團隊的氛圍有很大的加分作用。


收集關於事後檢討有效性的回饋

在事後檢討後,請每位成員提供對於此檢討後的回饋與意見,不見得每個人都有會有有效性的回饋,而願意回饋的就是一種對於檢討文化的一種鼓勵,甚至也可能拿到更多更棒的回饋內容唷。


持續改進

任何東西是隨著時間不斷地變化,唯有持續的改進與學習,才能成就我們的系統提升可靠性。


今日小結

每個系統或多或少都會遇到你沒想過的問題,當解決問題後,就要找大家一起討論此問題,讓它成為「我們的經驗值」,而個人的經驗值。如果對於每次的問題只有某個人知道如何解決,那也只有那個人得到了經驗值,相信你不會想要「明明是組隊打怪,而經驗值分配卻是個人的」這種結果。/images/emoticon/emoticon09.gif


上一篇
[Day 10] SRE - ON-CALL
下一篇
[Day 12] SRE - 定期演練計畫
系列文
Dev's Ops 啟程30

尚未有邦友留言

立即登入留言