昨天晚上在電視上看到這則新聞的跑馬燈,
真的真的覺得不可思議.

各位當時在看到Dell出包時,
會不會覺得資訊大廠怎麼會出這樣的問題?
寫程式雖說是複雜肉眼看不見難控制,
但是簡單的一些寫程式的注意事項,
增加一些內部管理上的步驟,
難道很難嗎?
怎麼又有大公司鬧這種笑話?

大概是很難,
因為Dell出錯不只一次.
就怕以後還會再錯!!

報紙上說的理由是遭駭客入侵,
不過如果真的是駭客, 
可是要拿出證據,
不然, 消保官及消費者不相信你, 
真的會覺得很委屈的,
我試著想有那些可能...

假設這個駭客可能擁有權限帳號密碼得以進入商品上架程式.
說明一下 : 網路購物的程式介面, 有一大堆基本參數設定(基本資料設定), 這些基本參數(資料)設定是有軟體介面的, 可由non-IT人員進行操作及資料建立. 其中一支程式會叫做"商品基本資料建立" or sort of (類似之名), 進入後要最重要的是要選出上架商品及建立售價.

所以一 : 駭客經由介面操作程式, 用data entry的方式將售價改成0, 存檔Save !!

還有一種更厲害的駭客,
他侵入了database,
我講的database, 是SQL-server, Oracle, MySQL這一類的要下SQL command的database.
哇, 這個駭客應該是很有耐心的,
他進入data scheme之後,
要下SQL command來query table資料表,
他必須瀏覽了很多很多的 tables & columns 欄位 (field names),
禮卷這個商品的單價之field name有可能叫coupon price, coupon_price, cpn_prc, gift coupon dollars, gift_coupon_money, ...
最可怕的是它可能只被命名為 C9332.
很難望文生義.
Anyway, 這個駭客找到了這個欄位, 把內容值改成0.

所以二 : 駭客直接進入database, 找到商品售價主檔的table, 找到商品及禮卷商品售價的欄位, 還找到禮卷這個商品正確的代號(比如說12345), 下了command把禮卷商品售價改成0.

還有一種 super 厲害的駭客,
他要先直接進入database, 找到商品主檔或是商品售價主檔的table, 其中之一就好了, 找到商品欄位名稱為何, 還找到禮卷這個商品正確的代號,
他不碰資料庫內容,
他直接動程式,
手法是侵入存放程式的目錄,
找到在網頁上處理購物車的程式叫什麼名字, 比如說 : shop_cart_01
用程式編輯軟體打開shop_cart_01,
在適當的地方多加一段程式碼 : if 商品代號="12345" then unit-price = 0 and sub-total = 0.
很狠, 禮卷單價一率等於0, 不管訂多少數量小計一率等於 0 耶!

所以三 : 駭客直接偷改了購物車程式

如果是上面一二三, 那麼系統裡都會有IP連線的記錄, Login系統的記錄, 存檔的記錄, 修改的記錄, 這些都稱之為LOG.
如果公司沒有做LOG或保留LOG做為證據,
那麼公司不必講理由了,
說是駭客害人其實是理虧的.

到現在我還是不知道Dell內部發生了什麼事情以致於網路購物單價post錯了不只一次.
在一般正常的IT環境, 這種問題只要錯一次, 內部人員就會大大的review程式碼, 不是review程式碼那裡算錯, 而是再加很多防呆關卡讓這種錯降至最低, 怎可能讓它錯不只一次?

要知道, 通常網路購物商品上架的data entry是non-IT 人員做的, 意思就是一般商品經理, 助理或是業務人員之類輸入的, 如果
(1)公司喜歡用年輕人但又不提供充足的教育訓練,
(2)公司沒有兩層關卡制度 : 比如說, 建立或是改完商品單價Save後, 自動會發e-mail給他的主管要求confirm, 主管進入系統從介面上再確認一次商品內容及單價後再Save, 這時候網頁前台才正式post出來. 而且程式會記錄是那一個人(帳號)Save的, 及其年月日時分秒. 意思是只有一位小囉囉業務助理輸入後Save是沒效的, 系統把這個資料當草稿, 要主管再看過用自己的帳號密碼進系統save之後才會連動到前台的post.
(3)爆大量也不會有通知主管的機制, 甚至什麼叫大量也不去定義數字. 有錢一點的公司可以直接從伺服器發簡訊出來, 發e-mail出來也可以. 再不系統一定要有一支程式隨時可印出爆大量的統計表, 不管是假日或是晚上, 要有專職人員(non-IT)定時進去看這支報表的結果.
(4)商品不定義安全庫存量, 難不成禮卷(商品代號="12345")的inventory qty = 64億 或是無限大?

你信不信,
光以上這些點,
可能內部吵幾天,
你推我我推你就搞很久沒有結論.
最後結論可能是要增加預算,
要增加head count才能徹底解決.
預算? 在等(廠商)評估報價!
加人? 在等(人資)招募完成!
哈!  難怪出錯不只一次.

可憐的禮卷訂購客戶,
如果你只買一點點,
那麼可能算對折還是會賣給你,
0元是不可能的. 
會道歉,
但是是從他們的角度去道歉解決事情,
不是從你的角度.
如果你買了很多,
那麼可能算對折(1000元的一半是500元)還要設定一個數量上限,
例如 : 最多一個人10張. 
如果你原來訂購2000張,
對不起, 不算!
公司會用改進來賠償你的bad feeling, but not in full.

即使它的網路購物 IT 人員不是外包是in-house,
要改進也是需要很多時間,
一步一腳印及加班去完成.

IT人員這下子可忙了,
會被要求加改很多程式,
很多控制,
比如說 : 
unit-price is numeric
unit-price can't be null
unit-price can't be zero
unit-price can't be negative
sub-total=unit-price * qty
sub-total can't be zero
sub-total can't be negative
if 商品="12345" then qty can't be greater than NNN
...
讓 IT人員覺得破壞邏輯架構,
不過, 只要管理階層說得出來
說得夠清楚,
IT 人員都會去做.
只要你們不要怪來怪去推來推去罵來罵去改來改去.....

如果我是消費者,
當我一發現是0元禮卷我就會e-mail給web master,
不買.
但是我仍然認為已經買的,
怎麼買的,
就應該怎麼賣,
正常出貨才是王道.

我這樣說,
企業請不要覺得委屈,
商譽, 品牌, 信用不是一日建立起來的,
為了保企業屹立不搖,
把消費者權益放一邊,
0元的禮卷不出貨,
你的損失會是更大.

想也知道,
以後有可能如此之錯還會再發生,
因為造錯的還是那些人事物習慣文化觀念,
"駭客"也會一直存在.

我會覺得企業理虧,
但是我們拿他們沒有辦法.

P.S. 以上推論是本人的猜測不是事實, 且本人及親友完全沒有訂購0元禮卷.

後記 : 後來, 約在2009年12月, 新聞爆出來說告學生下64億筆訂單 Hola禮券案 究責? 避責? 被告的是一位25歲的徐同學，是資訊多媒體應用系的研究生, 有一篇是什麼心態？貪？無聊？研究生狂買64億張０元禮券 , 可以看看.

這則新聞, 被資安相關的網站拿出來"關心".  其實, 這次的事件, 應該是屬於網頁完成後測試沒有做好的問題, 通常軟體測試好之後, 有所謂的 Alpha Test, Beta Test. 以前我工作時, 定義 Alpha Test 為設計者及其工程團隊對自己的作品負責, 在 release 給外部人員測試前的最後一道測試. Beta Test 分為 Beta Test 1 & Beta Test 2. Beta Test 1 測試屬於非設計者及其工程團隊的測試, 如果有將測試外包, 也是屬於 Beta Test 1, 如果請 Product Manager 團隊測試, 也是屬於 Beta Test 1, 總之在公司之內的範圍都算是 Beta Test 1.

Beta Test 2, 是指公司外的(測試外包給外面的公司做不算)的單位所進行的測試, 比如說 : 請OEM客戶用用看.

Well, 每家公司的定義不同.  Hola這次, 我猜是 Alpha Test 沒有做好. Alpha Test Plan裡, 應該要有針對每一個螢幕欄位之極大值及極小值的測試, 如果有測過, 就知道在數量欄位裡若 key 了天文數字後, 系統應該要不容許送出或到下一步了.

軟體測試常常被忽視, 這個新聞應該算是很好的例子.