Archive for 十二月 21st, 2006
小站生存的第七道關卡
小站生存的第七道關卡
假如你(有)幸必須去經營一個還沒有獨特市場區隔, 卻又還在起步階段的網站.. 面對網絡環境大者恆大的無情競爭, 如何讓小站得以存活, 闖出自己的一片天呢? 基於成功經驗的稀有以及幾乎都無法複製的前例, 在沒有太多可以效法的情況下, 只好來思考如何去避免犯錯誤了? 特別針對幾種常見現象及淺顯道理, 串連起來作反向比對, 整理如下:
(一). 維護網站vs.建置網站:
如果你的老闆還在想著 “把網站建置起來就可以等著賺錢”, 投入規劃時把主要時程及金錢都拿來開發功能或建置內容的話.. 請務必先說服他 “網站的營運及維護才是重點成本” 這件事, 有這樣的認知才能避免網站夭折的命運.. 因為往往就是一開始太浪漫, 接下來太實際, 起初太樂觀, 接著又太悲觀, 不見得是無法獲利, 只是為了沒有足夠的信心(資源)支撐到獲利的開始..
(二). 內容服務vs.功能維護:
如果你的老闆已經開始在重視 “網站後續的營運及維護”, 那麼恭喜你已經過了第一關.. 但是接下來請你努力平衡兩個觀念: 1. 不要把網站視為系統軟體, 不斷提升或開發功能, 什麼都丟給工程師去搞, 忽略它重要的媒體特色。 2. 網站不只是媒體, 行銷或業務人員絕對無法完全駕馭。 看到別人網路上的成功, 一定要釐清其特有市場定位相對於時空環境的複雜因素, 有Google的堅持也不該忘了Yahoo的理念, 任意引用他人的經驗或時下論述的話, 只怕要離失敗不遠了..
(三). 優質服務vs.內容功能:
如何讓網站擁有所謂的優質服務呢? 我想重點並不在於網站的內容或功能的多寡。現在「資訊爆炸, 科技千里」, 單靠內容功能想要突圍是不夠的.. 因為你的用戶早就讓成堆的內容給淹沒, 需求也讓入口網站的免費服務給餵得飽飽.. 想爭取市場定位, 一方面當然必須發揮本身的資源優勢, 在專業領域努力提供具特色甚或客製化的專有內容; 而面臨競業的優質服務, 則往往成就在最不起眼的地方.. 品質差異, 往往是由許多的枝微末節累積而成..
(四). 活動推廣vs.優質服務:
網站的優質服務要提供給誰呢? [...]
Posted: 十二月 21st, 2006 under 文章彙整.
Comments: none
網站初步安全機制的階段考量及建議
一般在擬訂系統安全機制時,受媒體及管理習性的影響,很容易讓人就把焦點集中在防範駭客及內部監控這兩個訴求點上面,所付出的有形或無形成本也最高,偏偏從這樣的考量點上顧問公司卻最容易謀取到最高的利潤,也較能順應管理者基於技術盲點所產生的心理安全需求。
其實安全政策的制定大致上可以由建立軟硬體設備、資料庫、系統技術這三項資源的防護措施作為整體機制的訴求,在安全上區別重要性及機密性則可以從預防設備或資料的毀損及資訊外流兩個方向考量。依照可能發生機率提列如下:
(一) 設備或資料毀損的原因:
(二) 資訊外流的管道:
1. 人為疏失
1. 蜘蛛程式
2. 病毒
2. 內部成員
3. 硬體故障或損耗
3. 駭客
4. 駭客
4. 其他
5. 內部破壞
6. 其他
先從資訊外流的管道來看:
保護觀點基於道德義務要遠甚於資料本身的機密實質,因為對會員資料或Email蒐集而言,不代表沒有其他管道甚或成本更低的資料蒐集方案。關鍵是..
1. 資料對網站的意義?
(1) 資料內的會員對網站是否存在互信或互動。
(2) 會員彼此間是否透過網站存在互信或互動。
(3) 從資料或互動中能夠整理或分析出甚麼樣的訊息?
(4) 對於資料的群組分類等相關定義及經營管理機制。
2. 考量的重點在哪裡?
(1) 流出的資料是否隱含或透漏出任何市場數據或訊息?
(2) 從資料或結構中是否能夠解析出重要的技術Know-How?
(3) 是否暴露網站的優勢或缺陷或弱點?
(4) 是否透露網站的近程階段重點或管理流程或營運方向?
(5) 以上四點是否不須經由系統或資料庫可以更容易取得?
回頭看設備或資料毀損的原因:
有八成以上的資料毀損都是由於人為的作業疏失導致。無關乎技術的好壞,隨著資料庫結構及作業流程的日益複雜,DBA或系統管理人員犯錯的機會也相對不斷攀升.. 日子要過得安穩?買保險或是買再昂貴的設備及系統都無法防止或彌補資料永久消失所造成的傷害,而真正需要的卻僅僅只是資料的備份、儲存而已..
如果設備或資料發生問題,首先真正要擔心的應該是資料救不救得回來?網站的備份機制從問題發生到發現的最大期限及空窗損失(方案1.例1)?多少預算成本才能夠將風險降低到可以容忍範圍?然後才考慮當機或停機對網站使用者所造成的負面影響..
沒有絕對安全的機制也沒有永遠適用的政策:
面對企業的成長及網路環境的變遷,因應不同階段及不同性質需求,任何政策不可能一成不變。一個錯誤的考量,選錯時間或用錯地點,所造成的無形的內耗或未來商機的錯失要遠比駭客或病毒讓系統當機停機兩三天的威力要強大何止千百倍..
以一般網站初期的使用規模及性質,考量階段安全訴求及優先順序如下:
1. 資料庫及結構、系統技術文件、程式碼的永久毀損風險。
2. 建立並維持最新防毒體系,絕對禁止將病毒感染給用戶或合作夥伴。
3. 避免、預防或降低作業疏失所造成的損害。
4. 網站系統及資料庫的穩定性。
5. 網路合法管道的維護,監控非常態瀏覽行為。
6. 系統及資料庫及結構、技術文件、程式碼的安全防護及管理運用。
7. 網站效能的提升。
PS: 防範駭客及內部監控只能算是上列訴求的其中因應措施而已,初期並不合適成為主要訴求點, 更不可能當作是目標的達成。
可行的各項方案:
針對上列訴求,以下方案評估其功能目標、成本效益、重要性及階段性依優先順序提列:
1. 資料庫備份機制(訴求點1、3、6):
規範三種不同週期各別製作備份:
例1. 資料庫及程式碼,每日備份保留一個月。
優缺點:資料發生問題最小損失1天,發現問題的最大期限1個月,否則損失所有相關資料。
圖例: 1/8 1/9 1/10 1/11
—I—x———I—x———I—————I——
7/8 6/9
假設資料庫於8月7日發生毀損,則最後有效備份為8月6日,且該備份將於9月6日遭毀損資料覆蓋,因此如未能在9月6日前發現問題,之前的資料將永遠消失..
例2. 每週備份保留一個月(每月第1份保留一年)。
優缺點:最小損失1週,最大期限1年,否則損失所有相關資料。
例3. 每月備份保留一年(每年第1份永久儲存)。
優缺點:最小損失1個月,沒有最大期限(仍需定期更新儲存媒體)。
PS:圖檔及系統組態建議列為每月或每週備份範圍。
重點在於如何以最少成本降低最小損失同時延長最大期限。 整合上列備存優缺點則:資料最小損失1天,沒有最大期限。
2. 防毒體系(訴求點2、6):
1. 幾乎時刻都有新種或變種新病毒產生,不能即時更新的防毒軟體形同虛設,設立專人統合管理並隨時更新,才能確保整體安全。
2. 建置或購買Email管理系統,避免將客戶或合作夥伴Email存進個人郵件軟體,防止病毒透過電子郵件或通訊錄對外散播,損害網站專業形象。
3. 系統使用者等級(訴求點3、6):
ps. 等級細分主要是基於技術經驗及權責劃分,避免作業疏失,而非考量人品及信任度。
4. DBA機制(訴求點3、4、6、7):
1. 設立DBA專人負責結構建置、資料維護、效能監督設定、安全管控及備份儲存。
2. 資料庫任何結構建置或資料維護均須透過DBA整合評估,知會相關程式或資料處理人員擬定整體作業程序,之後並應隨即相關系統文件作業。
3. 重大異動之前必須先作(月)備份(記錄事由),之後並應隨即作(週)備份。
4. 重大資料關聯及資料互動統籌由DBA以資料庫機制完成,不須要經由程式設計人員為個別界面再作個別設計,減少錯誤發生機會以確保資料系統完整,同時提升程式效能,並降低程式開發、維護、文件製作及新人訓練等相關成本。
5. 建立系統作業、維護、設定等相關程序技術文件或操作手冊,降低系統 維護門檻及人員訓練成本;培養儲備DBA及系統人員,分攤相關事務,避免關鍵事項、資源或管道過度集中,減少作業瓶頸、部門屏障並降低 人事異動風險。
PS: 其實第5項目的考量往往是與其它項目相衝突的,一個安全監控愈嚴密的體系,在這方面的顧慮往往就愈趨明顯..以較傳統的思維來看,人品有疑慮的人員就不應該擺在企業關鍵點上,但就未來而言卻是非常不夠。套用中國微軟的管理理念『人品是企業人才的第一優先考量』..癌細胞就是比正常細胞容易生存,破壞遠比建設容易,組織體系不能只靠權謀制衡過日子,真正需要的是一個能夠協調合作創新的有機體,一個只是不犯錯的企業是沒有能力存活的.. 因此,不能信任就不該任用,考慮監控或督導之前應該先考量其它更重要因素。
5. [...]
Posted: 十二月 21st, 2006 under 文章彙整.
Comments: none