Re: [閒聊] 從標錯價事件看系統程式
※ 引述《daimond (林子大了什麼鳥都有)》之銘言：
: 不太確定這個討論的主旨與本版是否相符..
: 我本身不是學系統程式 所以對這類問題發生層出不窮自然是沒有辦法追根究柢
: 去思考原因
: 但這樣的設定不是基本上可以從系統面去解決嗎？比如說每個產品設定上下值
: 界線，當後續人為因素發生價格低於底線的時候，系統會發出凍結的訊號或乾脆
: 無法輸入，也可稱做防呆？
: 不知道類似的概念能做得到嗎？上下值界線概念在一般生管領域中常聽到，六標準
: 差裡面也有類似的防範手法
可以做是可以做，但是上下限的設定要定多少？上下限會不會自己本身就定錯了？
更別提如果計算的時候都有可能出錯，那怎麼保證上下限的檢查會不會出錯 :p
當然這不是說都不要防護算了，而是很多時候，規劃的好並不能保證以後就不會
出錯，甚至防護措施出錯把原來正常的運作搞垮也是有可能發生。
我是覺得，這些防護有時候不能以 "沒有錯誤" 作為目標，而是要以 "有錯誤發生時，
這個損失是承擔的起" 為目標。
例如 Dell，如果當時有設計遇到那種一下30台以上的單子做防護，或者整個系統突然
交易量變成正常交易量的5倍10倍時啟動緊急機制，趕快call活人來看是發生什麼事的
話，把損失控制在幾百萬幾千萬之內，以Dell的規模就可以當作廣告出貨，而不是像
現實裡面一樣，只能給些限制很多的折價卷來招罵...
我記得前陣子有個旅行社也是這樣，行程的價格key錯，但因為一團頂多30人，整個賠
起來也不會超過百萬，那就賠吧...不過這是運氣好不是系統有防護 :p
蘋果這次也是運氣很好，出包的是教育價，所以真正符合資格需要出貨的數量，我估計
頂多2000~4000之間吧，每台就算賠一萬多，加上一些周邊的排擠效應，整個損失其實
還好 (蘋果手上現金多到可怕...)，所以這次也出貨了。
--
Luna quieres ser madre
y no encuentras querer
que te haga mujer
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 112.104.95.143
推
07/29 19:39, , 1F
07/29 19:39, 1F
→
07/29 20:08, , 2F
07/29 20:08, 2F
→
07/29 20:09, , 3F
07/29 20:09, 3F
→
07/29 20:10, , 4F
07/29 20:10, 4F
→
07/29 20:10, , 5F
07/29 20:10, 5F
→
07/29 20:10, , 6F
07/29 20:10, 6F
→
07/29 22:27, , 7F
07/29 22:27, 7F
→
07/29 22:27, , 8F
07/29 22:27, 8F
→
07/29 23:27, , 9F
07/29 23:27, 9F
→
07/29 23:27, , 10F
07/29 23:27, 10F
推
07/30 09:52, , 11F
07/30 09:52, 11F
→
07/30 09:52, , 12F
07/30 09:52, 12F
→
07/30 09:54, , 13F
07/30 09:54, 13F
→
07/30 10:47, , 14F
07/30 10:47, 14F
→
07/30 10:47, , 15F
07/30 10:47, 15F
討論串 (同標題文章)