[淺談] 從DevOps過程開始學習SRE心得 I
搞DevOps也已經有兩三年，整體來看都有一定的架構與流程，不過，還是覺得有點怪怪，在維運與監控部分總是還缺少了一點什麼。扣除人的因素外，因該還有一些可以改進的空間。因此，看了 Site Reliability Engineering這本書，發現有許多觀點是跟現狀滿像的，尤其是在傳統(製造)產業
書中提到
DevOps這個詞是2008年末期開始流行起來，具體意義不斷在演化中，其核心理念是儘早在產品設計和開發過程中結合IT相關技術，強調自動化作業而不是人工操作，並利用軟體工程手段執行系統維運任務。而SRE的諸多核心理念和實務經驗相吻合，可將DevOps視為SRE核心理念通用版本，廣泛運用組織團隊、管理和人員安排，而SRE是DevOps模型在Goolge具體實踐
確實如此，DevOps對於工程方面細節並沒有做很多細節探討或是說該怎樣做，畢竟，DevOps強調在於文化、流程和工具，且其中重點在於Dev和Ops間的溝通。而在Dev方面本身就有許多軟體工程或是相關的知識在支撐開發模式或是開發生命週期，反觀Ops這邊就相關稀少，很多企業這方面可能還是停留在人工作業中，而書中也提到
有統計顯示一套系統的40%~90%成本，其實是花費在建置後的不斷維護過程，業界流行的一個說法是一套系統如果開發完成，佈署在正式環境上，那麼它就是所謂「穩定的」，就不需要那麼多工程師花費精力去最佳化、維護，這其實是錯的」，我們認為這種說法是錯誤的，從這個角度來看，如果軟體工程主要是專注於設計與建構軟體系統，那麼因該有另一種職業專注於整個軟體系統的生命週期管理，從設計一直到佈署，歷經不斷改進，最後順利除役
關於這一點在許多企業中，尤其是企業內部IT最常遇到這樣情況，就是不斷擴建新的系統，久而久之系統則是越來越多，此外，普遍認為開發新系統的價值會大於將舊系統進行最佳化，且普遍主管認知都認為系統上就是會穩定持續執行下去。出問題時候一定是系統沒寫好或是@#$!#。對於想要去修改既有系統、重構或是優化時，這樣的工作項目常常會被認為是最不重要或是沒有價值。也造就大毛病不一定有，但小毛病一堆，IT人員往往變成蠟燭兩頭燒，運氣差一點可能整天都是接不完的On-Call和很多的手動operation。
有時候呢，能找到問題且能處理的事情說不定還不算大事，有些時候，往往問題發生了但根本找不到問題點，又或是必須翻箱倒櫃一番看能不能找到一點蛛絲馬跡發現問題出在哪邊。這都是消耗人力與成本，甚至是時間。
在DevOps 其中一塊Monitor部分，是屬於Ops部分，我認為在SRE裡面把這一塊的做法說明相對是清楚
就如果我在一些場次分享中，我認為傳統企業的IT部分如果要開始執行DevOps，其中監控這一塊反而是相對於其他部分的重要程度是較高的。而怎樣設計好的監控系統，不僅可以降低整體維運成本，既然就可以增加時間與人力開發相關系統(IT部門往往在軟體系統上都是身兼開發與維護)。而在SRE提到監控系統的設計策略是需要通盤考量。這一點是非常重要，一套系統的穩定與可用性不單單只有軟體本身或是Infra，都必須要通盤考量。現代系統的發展已經是軟硬都是相互配合，如果還把Application、Database和Infra三者分開獨立看待，像是Application出問題，就一定Application問題嗎?若這樣思考方式已經是不符合現代系統開發了，因為，有可能問題是出現在Databasec或是任何節點上所導致或衍生，當然也可能是反之。
所以，我個人認為監控因該要能從系統層級往下擴展的監控，而不是採用節點或是局部方式監控。而一套監控系統通常因該有這三種產出
- Alert : 收到Alert的成員需要立即執行某種操作，對已經發生或是即將發生的問題即刻做出回應，以改善目前的態勢。
- Ticket:收到項目的工作成員需要執行某種作業，但非立即完成，通常是系統無法自動解決的問題，但也不會產生立即性的危害，允許在幾天內完成此類操作即可，系統不會收到影響
- Logging:平時沒有人需要關注的日誌訊息，但是日誌訊息已然被蒐集起來作為事後分析使用，除非特殊需要，否則平時沒人會主動閱讀
書中提到
一般傳統的警報策略是著重在某個特定狀況或是監控值，一旦發生特定狀況或是超過監控值就出發E-Mail警報，但這種警報策略的效益是非常有限，一套需要人工閱讀郵件和分析警報內容才能決定是否需要採取某種行動的系統本質就是一種錯誤。監控系統不因該依賴人來分析警報訊息，而是由系統自動分析，只有當需要人為操作，才需要通知負責處理的人
這一點可說對，但也不能完全正確，有些情境還是需要監控值方式去做監控，但這不能只是唯一方式，可以把這方式列為輔助。而至於不依賴人來分析警報，大部分企業的技術力，因該還是省不了這一環，但是確實在AI來臨情況下，是有機會減少人為分析的Case。
個人認為好的監控系統是在Ops工作環節相當重要，尤其當一個團隊內成員是Dev+Ops組成，沒有好的監控，將會導致Dev動能可能會被消耗殆盡
為什麼需要監控，或許大家都知道需要做監控，但是監控到底有甚麼好處，而監控倒底是誰的責任，早期很多人都認為因該是維運人員或是管Infra人員的需要注意。但如前面所說，現在系統複雜性、高流量、維運性與彈性都相對比以前高出需多，個人認為監控已經不只是Ops獨攬，Dev也需要一併介入甚至提出從系統觀點方面的監控策略。有些時候甚至監控指標必須透過程式撰寫才能產生出資料。而建構一套監控系統原因不外乎:
- 分析長期趨勢
- Alert
- 建構監控儀表板
- 臨時性的線上分析或是除錯
監控與Alert可以讓系統在發生故障時後主動通知我們，或者能夠告訴我們即將發生甚麼事情。這些Alert都是需要人員去調查並解決其問題。通常緊急的Alert處理會占用很多人員寶貴時間。所以，當Alert太頻繁，人員就會陷入狼來了效應，懷疑警報的急迫性，久而久之也忽略了警報。甚至過多警報會掩蓋真正發的事件。此外，無效的訊息太多，分析和追蹤問題可能會變慢，故張時間也會被拉長，有效的Alert因該提供足夠訊息，且誤報率因該降低。但是一套新系統其實一開始很難做到這點，這一定採用收斂方式進行，逐步保留到最主要的核心，除了技術層次外，人的層次也很重要，有些人可能認為久久沒收到資訊可能就擔心是否監控系統壞掉，反而增加更多資訊，造成Alert錯綜複雜，不容易辨識。另外，監控系統也不宜設計過於複雜，過於複雜或是沒系統性的監控系統，會導致經常性出問題，難以變更又不容易維護。最常出現在於監控系統是由百家廠商的監控整合，A指標要看A廠商，B指標要看B廠商，C指標又要看C廠商，當三者有關連時候，就無法找到問題。所以，在設計監控系統一定要追求簡化，在選擇檢測對象，也有下列原則
- 能反映真實故障的規則應該越簡單越好，可預測性強，可靠性高
- 不常用的資料蒐集、彙總和Alert設定因該定時刪除
- 只蒐集訊息，沒有任何儀表板呈現或是發送警報的規則，因該定時審閱並刪除
至於，有沒有辦法做到100%監控不遺漏資訊，我認為這是不太可能，就傳統企業來說，能做到99.9%其實就必須要花費相當多成本，採用逐步收斂方式將會是最好步驟，當然，監控系統也是跟一般系統是一樣，必須迭代更新，不是建置好就可以放任它不做處理。
另外有一段話，個人認為很適合用在傳統企業的IT系統觀念上
軟體系統本質是動態且不穩定的，只有與世隔絕的軟體系統才能永遠穩定，只要不再修改程式碼，就不會引入新的Bug，如果底層硬體或是元件遠用不變，這些元件也就不會引入bug，凍結當前使用者群，就永遠不避擴充功能。
而進行測試是可以提升當前軟體品質，但是是否就保證整體是穩定則是不一定。透過SRE的一些工程手法盡力在於系統靈活性和穩定性取的平衡。尤其，每當被要求系統要很靈活、時間快又要穩定，這基本上是不可能，除非是小系統，但小系統終究會變成大系統，也因此如何取得平衡點則是相當重要。在我看來同一個問題點發生是可以檢討與改進，但並非十惡不赦又或是否定一切努力，而在於我們因該要如何從這次錯誤中學習並建立好相關解決方案才是重點。但往往事實都是並非如此，也導致整體問題不一定被解決，反而阻礙人員的進步與改變，最終只會依循或是保守不變才是良策
就目前看來，單SRE提到的監控這一段，對於DevOps執行階段就可以有很大改進空間
最後，整體的衝擊不免也跟企業文化與組織，甚至是主管們認知是有相當關係。怎樣能持續邁進與改善是一大挑戰
