自從系統上了AWS雲端之後，如何透過AWS系統提供的Monitor機制來堅視系統穩定度便成了一門部門顯學，加上系統剛上限難免有不穩定的現象，於是大家便更瘋狂的熱衷於系統監視，除了平常上班下班要看多多上去看Cloud Watch，就連勞工節連假也要排班上去看Cloud Watch，感覺Cloud Watch 根本就是神呀，透過他我們也可以達到無所不知的境界。
這當然是AWS雲端提供的重要便利之處，因為透過這些AWS的Monitor工具，我們確實幾天下來有發現很多不同AP的機器所出現的問題，然後大家每天下班都會針對發現與所採取的行動進行sync up，除此之外，也數度發現有惡意外部攻擊對SSO進行大量Request，這些都是Cloud Watch告訴我們每一台機器所發生的每一件事。
當然，這也沒什麼不好！但是過度濫用這樣的機制就對人不太好了！該怎麼講呢？ 就是有些人對於Cloud Watch所提供的數據太敏感的話，這些資訊就會讓人變得很神經質！而誰會對這些資訊敏感呢？通常都是經理等級的人物，再來就是求表現的認真型Service Owner… 這些人通常沒事做就只會掛心地去看著Cloud Watch上有沒有什麼異常，或者是Cloud Watch有沒有丟出什麼Warning Message via Email，一旦發現，便開始全體總動員，看到人就拉進來問問是怎麼回事？要不要進去Log看有沒有發現？晚一點要報告一下問題點在哪裡。
這對Manager跟Leader來講確實也無可厚非，因為Manager對系統穩定扛最終責任，所以會神經質一點，於是便交待下面的Service Leader找出問題點，Service Leader為求表現自是出動所有團隊成員日也查夜也查總之就是要查出一個點讓他好說嘴，畢竟這代表著他有在認直做事，只是這種從上而下排山倒海而來的一條鞭式Cloud Watch 反應法，最終變成了神經質Cloud Watch作業法，搞得從Manager到Leader再到Member全員陷入神經質狀態，那真是一種災難。
可能我本來就神經大條吧，所以當我看到Cloud Watch CPU在兩點五分十二秒時CPU突然飆到15%然後斷斷續續維持在10%以上1分鐘接著一路太平沒再彈高我的初步判斷一定是按兵不動，也許會去看一下Log有沒有異常，但應該也不致於就斷定那一定有什麼錯誤，我必需把他抓出來！可是換Leader以上的人來看可就不是這樣想了，他們會假定是不是有問題，然後要求你做東做西非得查出個什麼出來，說實話，這樣有意義嗎？
後來吃飯時跟同事交換了一下意見，才知道他那邊也是這種神經質作業模式，大家都耗了一堆時間在收集一個不存在的問題的資料，只是因為Cloud Watch跳起來一下下，說是小心謹慎這實在是杯弓蛇影了！ 所以我開會時就試圖提出這樣的做法必需有個平衡點，白話點叫作應該適可而止，因為這種神經質查法不但無法幫大家找到新問題，更會使大家本來該做的事被延遲，我們應該停止這種花80%的功做不到20%的事的蠢事。
不過Manager畢竟看的點跟我們不一樣，這也不能怪他們，責任愈大想得愈多是自然反應，只是就是苦了下面做事的人而已。
Work hard 不如 Work smart！ 這是研究所老師教我的工作哲學，看似簡單，但其實至今我仍在摸索。不過我想這句話更適用在Cloud Watch的機制上，我們要的是Cloud Watch的預知能力，但不要Cloud Watch帶來多餘的費力，這倒是像一把劍的雙面刃，一不小心傷到的便是自己。
再說Cloud Watch怎麼說也是AWS家的，難道它的Monitor就一定是對的？我從同事那邊聽來一個有趣的看法，倒也覺得這頗符合商業邏輯的！AWS也許就是透過人們對Cloud Watch的恐懼，刻意讓Cloud Watch偶爾數據跳一下，讓你緊張起來，然後再問你需不需要更多工具以降低不穩定性，如此便可以增加自家產品銷量，所以你能夠相信Cloud Watch 百分之百都是對的嗎？ 或許，AWS真的在透過Cloud Watch販賣人類對系統不穩定得恐懼也說不定！不過這只是一個純粹臆測罷了，並不是說AWS會這樣做。
但是過度神經質地觀察Cloud Watch卻是不對的，也許我們要思考的一點是怎樣讓Cloud Watch能為我們工作地更好，而不是怎樣監視Cloud Watch來讓工作更緊繃！ 當系統搬上雲端以後，有很多平常事都將面臨新的挑戰，而這些挑戰還是取決於我們對待系統的哲學是府恰當，雖不能一如既往套用舊模式，但創造可以配合系統在新環境運作方的新思維來應用諸如Cloud Watch的新工具以創造最大工作效益，應該才是我們當下所要積極展開的佈局。
2017年5月2日星期二 :34 PM
留言列表
