由 DevOps Taiwan 主辦的活動： Monitoring Tools 大亂鬥

準備的時候思考要講什麼，整理以下的觀點：

• 談「武」、還是論「俠」？ (務實、務虛；肉體、靈魂)
• Target Audience (TA) 為什麼來？
• 我能給什麼？

最後我用： 人們不會買你買什麼；他們買你的為什麼 這個角度切入，分享一些觀點、策略、想法、實務經驗，實際講的比較像是心靈雞湯之類的，反而沒啥提太多 CloudWatch，現場的問題與討論是最有價值的，也都跟 SRE 有關係，底下是演講的 Slide：

想了解 CloudWatch 技術細節，參閱 Study Notes - CloudWatch 學習筆記

現場錄影：DevOps Taiwan - Monitoring Tools 大亂鬥

現場的問題

Q: 很大的系統怎麼監控？

原則就是：

1. 分而治之 (Divide and Conquer): 理清楚架構、分群管理
2. Prioritize: 定義 SLI / SLO，然後排優先次序
3. 告警的方法與共識：三個東西要抓住：等級、方法、對象，詳細參考：淺談系統監控與 CloudWatch 的應用 P95-P108

Q: 現場聊到關於『自動化』的看法

現場我答的不是很好，補充一些想法如下：

• 自動化之前，要搞清楚其必要性
• 搞清楚問題的流程、程序，問題出現的頻率
• 自動化程式本身的開發要注意：可測性、可配置性、確認出入輸出、文件、環境與依賴
• 自動化執行結果的驅動性：執行結果要怎麼處理？程式本身的問題誰來處理
• 品質：有沒有 PDCA 循環？Feedback 能否處理？

我類似的心得有很多，請參考這些文章的分享：

• 自動化帶來的問題
• 自動化 XXX 的陷阱
• What is Automation?
• 軟體自動化測試常見的問題

Q: 會後有朋友問「值班」、「MIS被當苦力」

這是 Ops 的經典題，所以 SRE 更重要了，上次的 Serverless All-Star 的演講主題：Ops as Code using Serverless 談了不少，有興趣的朋友可以再翻翻。

另外我提到的 Health Check 的層次，詳細參考：淺談系統監控與 CloudWatch 的應用 P19-P29，大概有以下：

• Light Health Check
• Layer Health Check
• Service Health Check
• Deep Health Check

補充關於監控與人力的調整策略：

現場我回答的時候，少講一個東西：機器總數

• 機器使用率最大化：考量成本的時候，不調整機器總數，Threshold 越高，例如：CPU Utilization 90% 才告警，缺點就是，人工監控密集度高，反應時間短。
• 不考量成本的時候，增加機器總數，Threshold 降低，例如：CPU 60% 就告警，因為機器變多了，人的監控可以稍微緩和一下。

這是 談 出來的，不是對或不對，是看團隊的資源、和公司營運狀況，比較過後的策略。最重要的是：老闆的支持很重要。

感謝

感謝正瑋熱情的邀請，讓我又有機會跟社群的朋友一起討論、分享關於 Ops 的一些事，然後也認識了一些在前線努力的朋友，大家都遇到很多類似的問題，特別是我在 Serverless All-Star 分享的想法，很多朋友在工作上都遇到了，而我只是想把這些問題重新點出來，Feedback 讓大家看到，然後看到這些問題的價值，改變它，希望持續點這把火。

歡迎朋友留言、Feedback 問題給我，或者給我建議，感謝。

延伸閱讀

• 演講：從緊急事件 談 SRE 應變能力的培養 - DevOpsDays Taipei 2018
• 演講：Serverless All-Star - Ops as Code using Serverless - iTHome, DevOps Taiwan
• 演講：淺談系統監控與 CloudWatch 的應用 - AWS User Group Taiwan, AWS User Group Taiwan
• What is Monitoring?
• Observability and Monitoring
• Study Notes - CloudWatch 學習筆記
• Recap What is Ops?