Re: [新聞] 戶政系統大塞車 內政部請IBM抓錯
※ 引述《chengcti (卡馬請出來面對!!)》之銘言：
: 依照資拓 2/11 的內部公文
: 出問題是因為軟體作業系統 (AIX) & middleware (Weblogic)
: 版本不相容所導致
: 所以??? 不是早就要先 update 過?
: : 不過, 這事究竟是何原因不得而知? 但歷經近30年的經驗實在不該表現這樣!
聽說是兩個牌子的新版軟體不相容, 各自倒退回去, 用舊的相容系統軟體
重新對自己的 Source AP compiling 不就成了?
用開發人員的版本去兜著用, 再跑self testing不就成了?
還是外包太多, 用的版本都不一樣? 這不太可能吧?
→
02/20 17:03, , 1F
02/20 17:03, 1F
推
02/20 19:57, , 2F
02/20 19:57, 2F
→
02/20 19:57, , 3F
02/20 19:57, 3F
推
02/21 00:59, , 4F
02/21 00:59, 4F
就是這幾位大大說的這件事.
mow811236:所以有人有看到IISI發新聞稿推卸責任？ 02/12 17:48
mow811236:是誰把有問題的平台驗收過的？ 02/12 17:50
mow811236:說有問題也不大對，因為那BUG台灣沒能力處理 02/12 17:55
有一說是這樣的:
也就是新版AIX 與新版 Middleware weblogic 對不起來, 懷疑有些
功能沒動作或不對.
mow811236:我看最大的錯誤就是沒拿真實的上線環境去做壓測 02/12 17:56
mow811236:不過這次的事件給台灣各大SI廠商一個警惕 02/12 18:02
mow811236:原廠發出的補丁該上還是要上，沒有天天過年的 02/12 18:05
就扯到團隊有的有patch,有的沒有, 所以對不攏. 也就是sub version不對.
ppttpptt:噗，真的是雖小還是有人指事要換成i公司的solution? 02/12 23:30
yesonline:原廠發的補丁有更新喔, 結果還是當掉了... 02/14 18:36
用tuxedo 還是 queue, 基本上核心也是 queue, 這是distributed transaction
常用的老方法, 使concurrent 變按序排隊, 但如果拆或併了一些queue, 某些地
方沒分析寫好, 因共用資源鎖定, 相互碰上了就會造成死鎖.
若只是version問題, 暫時不patch/update 用舊的就能先過關. 就能先清狀況.
推
02/21 01:36, , 5F
02/21 01:36, 5F
→
02/21 18:36, , 6F
02/21 18:36, 6F
→
02/21 18:36, , 7F
02/21 18:36, 7F
這個戶役政在1986-1993完成時,就是由中央大學資工所的黃教授在III開頭
做的. 後來的連線,通報也是在此基礎下完成, 這系統出了狀況, 怎麼不會
讓人好奇? 以往, 這系統都不支援跨區領取戶口謄本, 也很令人納悶, 還
以為是繳費拆帳問題阻擋了這事.
這次的結婚登記, 就出狀況的報導言, 是有跨區查閱及跨區更新身份證. 顯
然是勇敢的跨出去了!
這樣的bug, 是一題能上教科書的好問題!
→
02/23 01:47, , 8F
02/23 01:47, 8F
→
02/23 02:29, , 9F
02/23 02:29, 9F
→
02/23 02:30, , 10F
02/23 02:30, 10F
去年9月去遷戶口, 只好跟著換身份證, 同區更動可能還是得上報內政部,雖慢得
很難想像但還是可以忍受.
新舊差異不大, 但可能更強調及時通報更新, 才是新系統的特點.
戶政從日據以來, 警察就是假借查戶口年節到訪, 抓通緝犯.
幾個金融犯都是從法院通報到戶政到海關太慢, 有時差得以潛逃. 如今資安/國安
無限上綱, 即時相互通報似乎是新戶政系統的想法, etag 可讓警政即時查詢, 繳
費計扣帳反而是一天後才知, 就可知"即時通報"目的何在?
即時通報要即時反應, 就會即時更新並再通報其他相關單位更新再回報.
這些連鎖的即時異動, 因跨網路而延遲, 若都要連鎖互動, 鎖定時間太長, 就會企
圖分段鎖, 雖有queue 的串列化排隊, 仍然解不了相互不同queue內的程序搶奪相
關資源的鎖定, 若沒有仔細分析就會造成死鎖.
這種 distributed transaction/concurrent transaction 原理現象都會教, III
的老手怎會犯這種錯? 可以平行的不平行就會排隊等候慢得很, 不該平行的沒管
制同步做好亂平行, 那就是造成錯誤甚至相互死鎖. 這種time dependent error
因狀況有隨機性, 要重覆展示不易, 是很難靠一般測試得知的.
→
02/23 10:51, , 11F
02/23 10:51, 11F
→
02/23 10:52, , 12F
02/23 10:52, 12F
→
02/23 10:53, , 13F
02/23 10:53, 13F
→
02/23 10:53, , 14F
02/23 10:53, 14F
→
02/23 10:54, , 15F
02/23 10:54, 15F
event queue 或 message queue 就是 request 送進 queue 排隊, 再由queue送給
對應的 object process 處理 request. 處理的時候可能因被其他 queue service
object/process 鎖定資源, 而得不到 resources 就只有等候. 互等就有可能互鎖.
queue 化並行多進的輸入成串列排隊, 就queue操作言, 空位位置這項資源的更新就
用到 lock 以維持正確同步與更新, 只是這是系統幫應用者寫好.
→
02/23 13:03, , 16F
02/23 13:03, 16F
→
02/23 15:41, , 17F
02/23 15:41, 17F
→
02/23 15:42, , 18F
02/23 15:42, 18F
→
02/23 15:43, , 19F
02/23 15:43, 19F
producer/consumer 對一個有限長度的 queue 做塞進,取出 東東的動作, 如果只限
只有這兩者使用, 對進出位置更新不用到共用變數可不動用到 lock. 但通用的queue
其producer或consumer都非只有一個, 兩個以上的producer使用同一個queue, 對同
一個位置變數更新, 以便存東東的位置值就必須動用到 lock. 只是這是底層系統幫
忙做, 所以看不見. 各別只有一個producer/consumer使用同一個 cycle queue, 若
用共用的queuelength 決定queue empty/full 狀況就會用到 lock 機制.
使用現成的queue感覺不到queue如何有lock operation, 但會用到queue, 就是有調
整處理動作(如producer/consumer)前後次序必要才會擺個queue維持某個次序. 訊息
驅動的異動(Transaction)對更新的對象是否需要考慮同步鎖定, 就在於這些對象是
否皆必經過等效串列化的唯一queue才能取得. 若不是透過這個機制的共用資源就有
自備鎖定的額外必要. 這是如何正確使用串列化等效的問題, 不是使用了queue就都
沒有同步鎖定.
這題是課本都有, 範例一般也都會. 但實況都不是可無限擴張的理想狀況, "有限制"
是經常被忽略的.
→
02/23 19:01, , 20F
02/23 19:01, 20F
→
02/23 19:07, , 21F
02/23 19:07, 21F
那種 multiple input queue 可以不用到 lock 機制 可以實現的? 這是回答.
→
02/23 19:28, , 22F
02/23 19:28, 22F
LOCK 都是 system call 靠 system support 來使用. 該用的地方還是得用.
message queue 只是 確保process間訊息傳遞正常. concurrent acccess 的效率化
還要再依靠等效串列化才有交錯平行處理的效率, 只有排隊執行無法得到交錯平行.
→
02/23 22:14, , 23F
02/23 22:14, 23F
→
02/23 22:14, , 24F
02/23 22:14, 24F
如果queueA送出訊息啟動一個processA去update某個共用變數x及另一個某條件下
才更新的y. a,b,c process都透過 queueA來啟動 processA 更新x但都不更新y,
另一個 p process 則是透過queueA更新x及y, q process 則是為了速度及優先可
直接更新y. a,b,c,p,q 都是進行中的process. 此時, 這個高優先的process q 及
一般的processA要不要對共用的y透過系統支援做 LOCK 以確保正確有效?
→
02/24 10:25, , 25F
02/24 10:25, 25F
這個問法是沒有意義的. 只要產品的功能不能符合需求, 就必須利用底層的系統
支援來自備所要的功能. LOCK 通常是作業系統會提供的支援, AP只要會叫用也是
可以 by-pass middleware 進行自己所要的特異功能.
所以是產品沒提供的功能, 就有可能要自備管理的機制. 內政部擁有警政的軍力,
只要掛起國安的需要, 很多實時監控與通報的"高優先"需求就會介入, 而且還會
要求夾在公開系統中做隱密式的處理. 這種需求是存在的也不用置疑.
→
02/24 17:18, , 26F
02/24 17:18, 26F
→
02/24 17:19, , 27F
02/24 17:19, 27F
這個戶政案的需求, 顯然並沒有完全公開. 承包這個案的是否能全然了解並熟練應
用選定的middleware去完成需求是很難說的, 如果承包者認為需要自備某些道具才
能達成需求, 那就會去自己搭建"自認為"middleware做不到的部份. 只是出了狀況
只能說不夠戒慎恐懼, 太过掉以輕心, 而且還幾乎退不回去原有的水準, 是有夠糟.
這個案應該成為學習檢討的例子, 應該好好深入公開檢討, 軟體業才能有前途.
→
02/25 00:13, , 28F
02/25 00:13, 28F
→
02/25 00:14, , 29F
02/25 00:14, 29F
→
02/25 00:14, , 30F
02/25 00:14, 30F
→
02/25 00:14, , 31F
02/25 00:14, 31F
Java Message System 可以介接到 MQ 使用. 本質上同producer/consumer queue
是一樣的. 任何Transaction update都是read-modify-write, 強制一個個的R-M-W
都排隊一個一個來, 在網路傳送速度的限制下, 每筆異動就變得耗時太長, 太多人
同時要更新異動就很可怕的等候. 串列化等效的平行處理就必須提供, 如果加上分
散式多server複製型備援, 這事就升級到 distributed transaction, 串列化等效
的平行處理及復原是少不了的. 多servers複製型備援可以用data center 及高速
連網組成雲端縮短傳送的準備與處理時間, 但單一資料庫還是變成分散式資料庫,
distributed transaction 還是難以避免. 後者的 read/write delay & commit
這些同步問題還是得自行設計處理. 單靠MQ是解不了這種平行效率的問題.
賣車票的最壞是開車前明明是有空位卻讓想坐車的買不到票, 但賣些自由座站票靠
車上服務人員調整也能緩解問題. 但戶政則是 "老是要人到,驗明正身, 若非在限
時內服務完, 那絕對是怨聲載道, 人人痛恨. 先進與落後就在這些點顯現.
→
02/25 10:26, , 32F
02/25 10:26, 32F
→
02/25 10:27, , 33F
02/25 10:27, 33F
戶政的資料本來只存放在各區公所, 組織精改向上集中, 有些資料因區合併, 集中
在新改的大區, 這很正常. 但內政部在此新系統的角色是甚麼? 各縣市區公所需要
把最新資料備一份到內政部嗎? 有備援顯然是需要的, 但都備援集中到一處嗎? 還
是分更大區相互同步複製備份? 這個架構弄不好就搞死自己了. 現在國際化的網路
教學互動平台, 就已是這樣的系統. 現在不只是用,還要增添新工具新課程, 已有
的要相容, 新的服務要自動銜接上去. 除了及時優先更新這種特異要求外, 可說具
體都有, 這些才不會是用扯的.
※ 編輯: ggg12345 來自: 140.115.50.240 (02/25 15:38)
討論串 (同標題文章)
以下文章回應了本文：
完整討論串 (本文為第 17 之 30 篇)：