November 7,2007
從這次博客來的個資問題來看網站程式設計的困境
我在前幾天就知道這件事情了, 但不是因為新聞, 當我看到時, 並沒有想到這件事會多嚴重, 畢竟這樣的事, 是蠻常見的, 甚至是屬於真的很難解決的疏失, 甚至我在四年前也犯過相同的錯誤, 而這次就比較嚴重了, 但我想到的是, 以一個網站程式設計師來看這個困境.
類似的事, 在我的工作經驗中, 已經可以超過一隻手可以數的次數了, 而聽過的更是不計其數, 只是這個問題該怎麼解決呢? 我甚至是比較悲觀的說, 這個在網路界是屬於無解的狀況.
在我寫這封信的時候, 剛好有一個朋友是在做資安的, 他還問是不是我捅出來的, 我說若是我就好了, 或許我個性比較隨便, 但若是發生在一個鑽牛角尖的新人的話, 他一定是一個月睡不好覺.
通常發生類似的事, 很多人一定會問 "有沒有事前測試", 這是不用說一定會有, 但這種問題最麻煩的就是無法用少量或一個兩個測試出來的 "Runtime Error", 往往必須發大量或相同的量才能夠發現, 也就是說, 當寫程式的人寫完後, 發給自己, 看是沒問題的, 又發給 PM 看, 也更是沒問題, 但當開始發送大量後, 慘劇就如此發生了....
這種 "Runtime Error" 在程式設計師中是最討厭的, 因為不像是寫錯一樣, 可以知道那邊有問題, 更麻煩的是那時候出問題都無法知道, 有時必須看出問題的結果才能夠知道.
這種問題說穿了就是發信的內容, 相關字串或變數沒有徹底清空所造成的, 當然在執行一兩次是看不出來, 畢竟這種發信程式, 在寫網頁設計師來寫而言, 往往是不會考慮變數或資料清空的問題, 因為網頁程式每隻都只會執行一次, 然後就輸出, 但發信程式不是如此, 會有一個大迴圈, 然後一個迴圈發一次信, 此時原本不管的變數清空問題就發生了.
有人問, 這種事應該必須更撤底的檢查與測試才行, 此時就面臨一個很嚴重的問題, 有多少 EC/ICP 等網站可以有這樣的資源去做測試?
通常一個金融系統, 大約 2~3 年才會更新系統一次, 而每次更新系統動用的人力與週期, 大約是以千萬到億的資源預算來計算, 但很不幸的, 網站更新或製作新系統約是 1 年 30~50 個左右, 每個系統可動用的資源大概不到是百萬的計算, 若是說要有相同的除錯檢查水準是不可能的.
待過類似的公司一定有這樣的經驗, 每天所有的員工要收到數十封到數百封測試信, 當然相關 PM 一定會去看, 雖然是希望所有員工一起檢查, 但真的有可能有那麼多人去看呢? 且事實上這種測試信一定在發送是沒問題的, 因為沒有人會發上幾十封或幾萬封的測試信, 大概用一封就可以看出個所以然.
只是這種案子剛好在這種情況是無解的, 在我週遭最近一次是在兩年前, 因為一個程式 SQL 裏面的變數沒清空, 造成參考值一直複製, 雖然資料錯誤只是造成推薦結果的不準確, 但因為資料量太大, 把整個頻寬給塞爆了, 所有公司內部員工怨聲載道, 但不能因為如此少了一個等號就去怪罪, 但我知道, 寫程式的人是相當不好受的, 更何況是這種影響到外面的狀況.
而像這種大概只會用這麼一次的程式, 跟會用很多次的程式所花的心力是不一樣的, 更何況可能重頭到尾都是那個人獨立寫出來的, 當然我知道此時有人說是否有可能由第二者或第三者來做測試或執行或除錯, 這個可能在台灣這種毛利率很低的文化事業是不太可能的, 更不要說是追求速度的網站, 就我所知金馬影展執行單位交付博客來去負責這次售票, 是不到一個月的, 說要去事前準備是有點困難.
基本上這篇文章我不是要為博客來說話, 而是要為廣大的程式設計師說話, 因為這種事說要靠一個人去獨立避免是很困難的, 任何人都有其茫點, 尤其是像程式這種說一是一的執行方式, 一個閃失就無法執行, 即使能夠執行也不代表正確, 能夠執行一次正確也不能保證之後都沒出問題.
而大家所提到的, 個資問題, 補償問題, 網路劃位問題, 大家可以參考其他篇文章:
1. 金馬執委會針對「博客來會員資料外流事件」公開說明
2. 博客來售票網電子商務：外洩會員資料，毫無隱私權！！
3. 2007台北金馬影展留言版
這些我不在這篇討論, 畢竟我的立場是很奇怪的, 甚至是不應該寫這篇, 但我還是以工程師/程式設計師的角度來寫這篇, 勿怪~~~~
[洗完早後記]
我知道我寫這篇可能很討打, 尤其是對影迷, 雖然我也是唸唸不忘在當時徹夜排隊, 大家一起聊昨晚夢到沒買到票的夢靨時的有趣.....
但這篇要說的是, 要苛責的對像是:
網路大勢 > 廠商 >>>> 程式設計師
也就是, 可以埋怨網路的現實面多些, 但也可以怪罪場商, 請千萬不要對只是寫錯一行指令的程式設計師過多的壓力, 這種錯誤是人人都會犯的, 至少我就犯過, 我想應該這世界上沒有多少無敵工程師能夠寫出無出錯的程式, 即使看過再多遍吧. am 3:32.
在我寫這封信的時候, 剛好有一個朋友是在做資安的, 他還問是不是我捅出來的, 我說若是我就好了, 或許我個性比較隨便, 但若是發生在一個鑽牛角尖的新人的話, 他一定是一個月睡不好覺.
通常發生類似的事, 很多人一定會問 "有沒有事前測試", 這是不用說一定會有, 但這種問題最麻煩的就是無法用少量或一個兩個測試出來的 "Runtime Error", 往往必須發大量或相同的量才能夠發現, 也就是說, 當寫程式的人寫完後, 發給自己, 看是沒問題的, 又發給 PM 看, 也更是沒問題, 但當開始發送大量後, 慘劇就如此發生了....
這種 "Runtime Error" 在程式設計師中是最討厭的, 因為不像是寫錯一樣, 可以知道那邊有問題, 更麻煩的是那時候出問題都無法知道, 有時必須看出問題的結果才能夠知道.
這種問題說穿了就是發信的內容, 相關字串或變數沒有徹底清空所造成的, 當然在執行一兩次是看不出來, 畢竟這種發信程式, 在寫網頁設計師來寫而言, 往往是不會考慮變數或資料清空的問題, 因為網頁程式每隻都只會執行一次, 然後就輸出, 但發信程式不是如此, 會有一個大迴圈, 然後一個迴圈發一次信, 此時原本不管的變數清空問題就發生了.
有人問, 這種事應該必須更撤底的檢查與測試才行, 此時就面臨一個很嚴重的問題, 有多少 EC/ICP 等網站可以有這樣的資源去做測試?
通常一個金融系統, 大約 2~3 年才會更新系統一次, 而每次更新系統動用的人力與週期, 大約是以千萬到億的資源預算來計算, 但很不幸的, 網站更新或製作新系統約是 1 年 30~50 個左右, 每個系統可動用的資源大概不到是百萬的計算, 若是說要有相同的除錯檢查水準是不可能的.
待過類似的公司一定有這樣的經驗, 每天所有的員工要收到數十封到數百封測試信, 當然相關 PM 一定會去看, 雖然是希望所有員工一起檢查, 但真的有可能有那麼多人去看呢? 且事實上這種測試信一定在發送是沒問題的, 因為沒有人會發上幾十封或幾萬封的測試信, 大概用一封就可以看出個所以然.
只是這種案子剛好在這種情況是無解的, 在我週遭最近一次是在兩年前, 因為一個程式 SQL 裏面的變數沒清空, 造成參考值一直複製, 雖然資料錯誤只是造成推薦結果的不準確, 但因為資料量太大, 把整個頻寬給塞爆了, 所有公司內部員工怨聲載道, 但不能因為如此少了一個等號就去怪罪, 但我知道, 寫程式的人是相當不好受的, 更何況是這種影響到外面的狀況.
而像這種大概只會用這麼一次的程式, 跟會用很多次的程式所花的心力是不一樣的, 更何況可能重頭到尾都是那個人獨立寫出來的, 當然我知道此時有人說是否有可能由第二者或第三者來做測試或執行或除錯, 這個可能在台灣這種毛利率很低的文化事業是不太可能的, 更不要說是追求速度的網站, 就我所知金馬影展執行單位交付博客來去負責這次售票, 是不到一個月的, 說要去事前準備是有點困難.
基本上這篇文章我不是要為博客來說話, 而是要為廣大的程式設計師說話, 因為這種事說要靠一個人去獨立避免是很困難的, 任何人都有其茫點, 尤其是像程式這種說一是一的執行方式, 一個閃失就無法執行, 即使能夠執行也不代表正確, 能夠執行一次正確也不能保證之後都沒出問題.
而大家所提到的, 個資問題, 補償問題, 網路劃位問題, 大家可以參考其他篇文章:
1. 金馬執委會針對「博客來會員資料外流事件」公開說明
2. 博客來售票網電子商務：外洩會員資料，毫無隱私權！！
3. 2007台北金馬影展留言版
這些我不在這篇討論, 畢竟我的立場是很奇怪的, 甚至是不應該寫這篇, 但我還是以工程師/程式設計師的角度來寫這篇, 勿怪~~~~
[洗完早後記]
我知道我寫這篇可能很討打, 尤其是對影迷, 雖然我也是唸唸不忘在當時徹夜排隊, 大家一起聊昨晚夢到沒買到票的夢靨時的有趣.....
但這篇要說的是, 要苛責的對像是:
網路大勢 > 廠商 >>>> 程式設計師
也就是, 可以埋怨網路的現實面多些, 但也可以怪罪場商, 請千萬不要對只是寫錯一行指令的程式設計師過多的壓力, 這種錯誤是人人都會犯的, 至少我就犯過, 我想應該這世界上沒有多少無敵工程師能夠寫出無出錯的程式, 即使看過再多遍吧. am 3:32.
引用URL
http://cgi.blog.roodo.com/trackback/4432799
回應文章 
這幾乎是所有程設都會遇到的慘痛經驗~以我們公司來說~
其實QC做的算嚴謹
但畢竟還是少量測試
有時上線偶爾還是會發生問題
又或者開發的Lab環境和線上環境多少也會有差異而導致錯誤的發生~
以上並不是說程設就完全可以撇清責任
只是人非聖賢~這也是難以避免的~
Posted by 熊瓶
at November 7,2007 17:58
我覺得今天許多人的怒氣，有一大半跟博客來在發生問題之後的處理態度有關。我真的開始對週六劃位更憂心了...
Posted by Winnie
at November 8,2007 01:31
對阿
是人都嘛會犯錯
不要老用放大鏡看事情
有時候為了貪一點小便宜洩露的個資比這種次數還多呢
是人都嘛會犯錯
不要老用放大鏡看事情
有時候為了貪一點小便宜洩露的個資比這種次數還多呢
Posted by 梨子蘭
at November 8,2007 09:54
很久不見
今天我也變成一個差點翻桌的使用者了
我想責任最大的應該是金馬執行委員會吧 XD
Posted by siegfy
at November 11,2007 04:24
siegfy:
但這種話不能對外說阿....
所以可以這樣說: "以業界的觀點是成功, 但對使用者的觀點是失敗"...
因為業界的人知道問題是出在那邊... 唉~~
Posted by 黑貘
at November 11,2007 14:18
真是難為工程師了 @@連續出了兩三次狀況，一般的使用者是會受不了的；
但是，從其中得到的經驗確實能成為未來改進的參考，
如果在這之前能夠進行大規模的測試，
或許情況就會不一樣了吧?
不是很忍心苛責博客來，可這次的表現跟過去相比，
對比真的很明顯啊..
Posted by CornGuo
at November 12,2007 03:58
通常一個金融系統, 大約 2~3 年才會更新系統一次, 而每次更新系統動用的人力與週期, 大約是以千萬到億的資源預算來計算, 但很不幸的, 網站更新或製作新系統約是 1 年 30~50 個左右, 每個系統可動用的資源大概不到是百萬的計算, 若是說要有相同的除錯檢查水準是不可能的.
不知道貘兄以上的說法是有什麼直接證據, 業界經驗或只是”想當然爾”??
金融資訊系統其實不如您想像中的預算龐大，您講的更新週期二到三年也是錯誤的，小弟碰巧在金融資訊業服務，對內情略知一二，舉這兩個例，然後以資源不對等作引子，導出程式產品品質的差異為合理，小弟個人覺得真是胡扯
以台灣為例子，因為政府金融法令及政策修改頻繁，加上使用者需求不斷變更，以小弟經手的金融資訊系統而言，幾乎都是處在不斷的修改過程中，從系統上線交付驗收完成開始就不斷的在作變更修改，金融資訊系統一年修改 30 ~ 50 次也不是沒發生過，系統整套或許是千萬或數億來計價，但是別忘了銀行是很摳門的，後續因法令修正或使用者需求變更而造成的系統程式及流程修改，平均單價並沒有您想像中的多，講不客氣一點很多時候甚至是沒有錢可以拿的，金融資訊業也是毛利率很低呀，因此拿這兩個相比然後說金融資訊業除錯水準高事屬應然而博客萊毛利低資源不足犯錯可以理解完全是想當然爾的講不通
基本上我贊同不應該苛責寫那支程式的 pg, 但是負責那個案子的 pm 及博客萊絕對是該死，程式變數應清除而未清除基本上只有兩個解釋"粗心"及"偷懶", 什麼東西用完該清不該清對 pg 來講是 common scense, 沒清也許是因為過去經驗都是如此而沒事所以就沒清，但絕不代表這是一個合格的 pg 應該作出來的事，也不代表博客萊沒有檢查到事屬應當
pg 之所以寫出這樣的 code 完全可以視為管理上的嚴重疏失，pg 犯錯就算了，pm 也未盡到監控的責任，過失殺人也是殺人，絕不是輕飄飄的用"這是大家都會犯的錯"來帶過就好，更毋論這並不是所謂"大家都會犯的錯"
出來吐你槽對我個人沒什麼好處，只不過看的人或許會因為您"想當然爾"的一廂情願想法而被誤導，同時非業界的網友因不瞭解內情也許會覺得您講的沒錯而不會去發現這個基本上乃是管理上的嚴重疏失，不是什麼"大家都會犯的錯"
Posted by YouKnowWho
at November 12,2007 10:09
給事實上我不知道 "YouKnowWho" 的人:
太感謝您跳出來說話了...:)
我的確對金融界狀況不夠了解, 有一個了解的人出來說話就太好了, 因為我都是因為朋友的關係才會知道, 並不是親身體驗..
因為我們一直被金融界的人笑, 說我們的系統是由一群少數人來寫, 且用的是很少的時間與週期, 文件與測試都不夠詳盡, 所以我才會這樣說...
但我大概說一下, 我知道金融界的程式一年改個 30~50 次不算甚麼, 但我說的這邊網路界是一年要開發 30~50 個功能或系統...
我偷偷跟你講一件事情, 像金馬影展從確定主辦後, 離開賣的時間是不到一個月的, 我不知道在金融界有沒有可能從規劃到寫程式, 到測試, 執行, 上線, 是在 10天內完成, ....
這個問題在我開始接觸時就感觸很深, 我知道網路界若要改變這個現實, 人力資源要增加 30% 到 50%, 且時程要延長 50% 到 70%, 我在五六年前還認為這是應該的, 但我要說的網路現實是現在做的是在兩個月前沒想到的, 現在做的半年後也不見得能用, ...
我不否認博客來的管理疏失, 但我只是想說的是這是網路現實結構面, ....
我常說, 一張網路架構圖在網路公司的時效性是三天到五天, 所以通常是須要用的時候再畫, 且當要求者看到的時候事實上已經是不一樣了...
但我承認您說的一句話: "以資源不對等作引子，導出程式產品品質的差異為合理，小弟個人覺得真是胡扯", 這真的是要改變的... 因為我也真的很希望網路公司能夠有 "複數" 人去負責一隻程式, 只是好像都是一個人去擔負 "許多" 系統與程式, ..... 唉~~~
我想你聽到應該很難想像吧, 我也承認是管理的問題, 但管理最主要是安排資源, 我也知道程式一定要 "檢查" 阿, 但事實是只有一個人要在一天內完成時, 真的問題可能是要歸咎為甚麼只有這麼少的時間與人力吧?
btw, 你真的確定我 "YouKnowWho"?
Posted by 黑貘
at November 12,2007 11:43
![[Syndicate this site]](http://blog.roodo.com/_img/rss.gif "Syndicate RSS feed"){kind=small}
![[Syndicate this site]](http://blog.roodo.com/_img/atom.gif "Syndicate ATOM feed"){kind=small}
