演講：從緊急事件談 SRE 應變能力的培養

DevOpsDay Taipei 2018 兩天半的盛會，今天總算順利落幕。今天我分享了過去工作上，面對緊急事件的心得與歷程，同時彙整了 SRE 的重點，分享了這個在大會中，相對特殊的主題。不同於兩個月前的 AWS Summit，這次我不談技術、也不談高大上的數據、也不用新潮的用語，而只談如何面對 緊急異常 這件事，同時也分享了如何培養應變能力的方法與思路。

Updated 2023/07/19: 本文部分內容收錄在個人著作《SRE 實踐與開發平台指南》 - 2023/08 上市

簡報與摘要

以下是今天分享的 Slide：

從緊急事件談 SRE 應變能力的培養 - DevOpsDays Taipei 2018 from Rick Hwang

演講想表達的概念很簡單：

看見全貌：看到前、中、後
了解架構的重要性、鼓勵探索 > SOP
- SOP 要有，但思考與探索更重要
- 唯有思考，才能真的學到東西，才能見招拆招
溝通、溝通、溝通
標準化、標準化、標準化

這次演講，有很高的成分再強調溝通成本這件事情，因為過去的經驗就發現這是個很嚴重的問題，換到現在公司後，這個問題同樣一再重演，讓我再次覺得，有必要一再的強調。溝通用技術來講就是 協議，像是 TCP/IP ，好的協議，會造就好的運作模式，好的溝通品質會造就資訊有效的傳遞，知識傳遞更精準、更加流暢，企業才不會被絆住。

底下是 Slide 最後總結，給讀者做參考：

全貌與主旨

站內相關文章：

Part I 事件當下的應變

站內相關文章：

Part II 應變能力培養

Part II 架構

Part II 探索

Part II 管理

站內相關文章：

結論

Q and A

SOP 不重要？

不是不重要，而是 思考 過會比照這做更重要。如果能夠自行探索出來，會更好。因為事件當下，很多時候，不是靠 SOP 能解決問題，特別是沒有遇過的。另外就是要培養 逆性工程 思維，這是本來在 Agenda 裡的另外主題，未來有機會再補吧～

音樂圈有個笑話：把譜放在 吉他手 前面，他什麼都彈不出來了；把譜從 鍵盤手 前面拿走，他什麼都彈不出來了。。。照樣照句：把 SOP 從 Ops 前面拿走，他什麼都做不了了；把 IDE 從 Developer 前關掉，他什麼都做不了了。

Ops 只會照 SOP，Developer 只會寫 Code 不懂思考。。。樂譜某種程度代表 SOP，只要照著彈就好。架構則代表音樂框架，即興則代表著逆向思考與基本功的熟練度。

SRE 台灣好不好找？

我的觀察，企業開始有需求，但是市場上人力不多。跟其他朋友聊的想法只能這樣：自己培養，條件就是會寫 Code。另外是很多企業主管其實還搞不清楚 SRE vs MIS vs SE 的差異，很多職缺的描述都只是把 MIS 換成 SRE，但沒考慮到 SRE 跟傳統 MIS 的差異與他的條件。

怎麼訓練新人上線處理事件？

如果資深的人已經可以掌握狀況，那就把處理的機會讓給資淺的人，一定要下水游泳，才能真的學到游泳。

原先預定的 Agenda

投影片做兩天，構思兩週，資料蒐集花了兩個月。點都想好了，剩下的就是怎麼把故事講得精彩。底下是本來寫的 Agenda，因為可以提的東西真的很多，但是時間還是有限，最後就一直砍、一直砍，底下是原本預計的 Agenda:

其實只有完成 50%，跟 AWS 一樣就上了 XDD
有機會再來補齊吧 XDD

結論

最後還是要感謝這次主辦的單位：DevOps Taiwan、Hashicorp User Group Taiwan、台灣敏捷社群、iTHome，舉辦這樣優良的活動，再次推動台灣產業的升級！我也在這次活動中又認識更多新朋友，有了更多的交流，活動最難得的就是與這些朋友一起激盪的想法！未來有機會再碰面！

By the way，事前一直在思考，要不要放音樂，最後想想還是衝了！下次就把吉他代上去吧 XDD
DevOpsDays Taipei 2018 共筆

聽眾的回饋

2018/10/18 收到主辦單位整理的資料，內容是聽眾的回饋，截圖如下：

回饋內容如下 (截圖)：

有正面、有批評，不管怎樣，都謝謝大家回饋給我，其中缺點我也知道，有機會的話我再調整，總之，謝謝大家來聽我分享！

演講：從緊急事件談 SRE 應變能力的培養

簡報與摘要

全貌與主旨

Part I 事件當下的應變