2007年2月12日 星期一
分析與設計02-企業需求
在面對企業內部需求 , 有些系統就必須要考慮到十分周詳與長遠
例如 , 企業上會有些要求 , 例如 , 系統維護人力必須要低 , Down Time 要短 , 還是 Fail over 等等
因應這些需求 , 就會有一些配套的解決方式 ,
例如: Fail over 跟 Down time 的需求就會有 Cluster 或者是 Load Balance 等等解決方案
而系統維護人力要低 , 則必須要從分析跟設計開始著手 , 搭配一些自動化的監控軟體.
這裡面必須要提出來談的是,千萬不要一開始就看所謂的監控log file 這樣的問題點入手 ,
那根本不是有企業等級眼光的人員提出來的 ,
我看過某家公司的某些人員一開始提監控就是提監控 log file , 而不是先提系統該如何被監控 , 哪些事件是要由哪些角色來進行處理 , 這個只能說他們是小孩子在開大車
為何這樣說呢 ? 大型企業一般來說 , 可能會把 IT 的人員角色切的很細 , 管理 Database 的人員 , 管理 AP Server 的人員 , 管理網路的人員 , 管理應用系統的人員.
而大型企業的系統的 log , 有可能一天就是幾千條 , 甚至上萬條紀錄 , 如果你一開始就只是去談 log 的監控而不是由 log 的上游看起 , 那我只能告訴你 , 那是垃圾 , 垃圾進 , 垃圾出.
不相信嗎? 去看一下企業內部的相關管理系統的人員,他們一天可能會收到上百封由監控系統發出alert email ,
你猜猜看那些人員會怎麼看這些mail ,
答案是直接略過 , 為什麼 ?
理由1: alert 太多了 , 所以分不出來 , 那些是真正重要的 , 哪些是不重要的
理由2: alert 沒有足夠明確的訊息 , 管理Database 的人員(或者是管Server的人)不知道要如何進行下一步的處理 , 那些可能只有系統的維護人員才會了解
所以當你要開始規劃公司的監控機制之前 , 請先從系統最上游開始分析 , 要求系統在分析設計時 , 就要把那些錯誤 , 是必需要由哪些角色去處理 , 跟做什麼的全部釐清 , 甚至要把log 也拆離出來 , 商業作業的log跟系統錯誤的log 要切出來.
我看過某公司的某個Enterprise Architect 在規劃監控機制時 , 連腦子動都不動的 , 就談 log file 的監控 , 似乎以為有監控 log file 就能滿足企業的需要 , 結果明明上游(會產生log file 的系統)就是攪和在一起 ,
要記住 不要為了 XX 而 XX.
在這裡來說就是:不要為了監控而監控.要記住監控真正的原意是什麼.
如果你的上游完全沒有訂出事件的類型,錯誤的情況,處理的方式,甚至是切出log 那麼就會發生 , AP Server 管理人員一天會收到 幾百封的mail , 裡面可能是 JDBC Exception , File not found 各式各樣的問題 , 但是管理人員根本沒有辦法去處理.
結果這樣監控的結果等於就是有跟沒有是一樣的.
要記住 不要為了 XX 而 XX.
不要為了 UML 而 UML 了
不要為了 CMM 而 CMM
不要為了 PM 而 PM
訂閱:
張貼留言 (Atom)
沒有留言:
張貼留言