Re: [新聞] 戶政系統大塞車 內政部請IBM抓錯

[ggg12345 (ggg)]

※ 引述《mephiliu (Mephi)》之銘言：
: ※ 引述《ggg12345 (ggg)》之銘言：
: : 這個error message在google網上看見的就類似這種訊息:
: : <WebLogicServer> <BEA-000337> <[STUCK] ExecuteThread: '4' for queue:
: : 即使是 2014 2月 照樣有這種訊息在發問.
: : 這個message說法就是某個thread 在queue 呆太久, 超過設定的default 時限.
: : 這現象就是接近教科書說的 dead lock. 最簡單解法就是 "人工進入"宰掉重跑.
:   可能是我不太懂的關係, 不過我只有在DB的運作裡聽過dead lock......
:   戶政系統的狀況是到200 or 250 的時候, 所有的thread 除了I/O socket以外
:   全部都變成block or wait......至於是200還是250 我還沒有確切的消息, 而這個
:   狀況是kill process也解不了的.

分散式網路下謂 distributed dead lock, 遠端請求是透過本地代理代行. 若發生
死鎖, 遠端索要一部分並企圖透過網路到遠端代理要另一部份, 即使被宰了, 那個
遠端代理未必立即反應即刻釋出遠端索要的. kill 本端 process 未必立即反應在
遠端, 死鎖會拖長很久. 老式的 SUN NFS 在 data lock 下常有此現象. 這跟同機
同file system 管理下立即會解開的反應不同.

: : 新系統與舊系統的差別就反應在最近一系列新公布的規章上.
: : 以結婚/離婚為例, 兩造帶了證件, "同時人到" "任一個戶政所" 都可辦理.
: : 在人工的時代, 女方會先拿證件就其地遷出戶籍, 再拿到夫家戶政所入籍, 同
: : 時依結婚證書登錄雙方關係, 同時更新戶口謄本與身份證.
: : 在電子化之後, 各地形成了分散式資料庫. 理論上, 人工的遷移戶口用男方所
: : 在地的戶政區公所的電子公文對女方所在地請求遷出, 並傳送戶籍謄本, 就能
: : 遠地辦到. 但不論是否集中避免遠近的通訊延遲, 按地區建檔的資料庫還是可
: : 以分區做data parallel的分queue各自處理.
:   電子化以後其實並沒有形成分散式資料庫. 就我所知原來的系統是在離峰時間

老系統是形成 "各自可獨立處理"的 分散式資料庫, 新系統應該是要求要向內政部
請求, 再由內政部號令下去, 所以可以在任一戶政所辦理, 不必在原籍地.

:   跟中心的資料庫進行資料的抄寫. 當然可能有註記的問題. 這一塊可能是用人工調整的

老系統在內政部原來只是複製, 備援與統計.

:   不過起碼在台北市這邊, 戶口的遷移是在遷出地或遷入地任何一方辦理即可. 如印鑑證
:   明等業務更是在臺北市內任一戶政事務所辦理即可.

北市已經是集中在單一data center, 若不集中, 網路也夠快夠普及.
印鑑證明就是識別登錄的ID及要存入的印鑑圖檔證明, 多份取用就是驗明申請人ID,
對ID及其印鑑圖檔複製印出, 蓋關防交給申請人就可. 只要有個單一的ID及圖檔資
料庫就行, ID還可能是公司法人, 另成一套就可, 所以可任一地上網辦理. 第一線
只負責驗明申請人身份及其ID.

: : 不過, 這涉及請求與批准的權限, 直白一點就涉及"越權"與"入侵". 因此, 由
: : 內政部統一發號施令是可避免一堆點對點的來往.
: : 新系統顯然是集中單一權限的概念. 婚姻的登錄規章顯然因新的戶警分立與外
: : 配而改了. 事情變成在任何戶政所都能登錄與更改身份證, 但最近新婚的需要
: : 雙方同時到場驗證. 在某種程度上, 可能這是防止一夫配多妻的狀況發生.
: : 手工時代, 本來從任何一方戶政所憑結婚證書與戶籍謄本, 就可以請求更改身
: : 份證的配偶欄位記錄.
: : 那時是很單純的.譬如女方, 1.查證 男女證書/原謄本記錄. 2.調出女戶籍原本
: : 更新. 3.更新女謄本/身份證.
:   其實我猜測新系統涵蓋舊系統的流程操作部分, 可能直接用Java包4GL就直接做掉了
:   裡面的procedure甚至可能直接用原來的4GL

個人也近乎懷疑是這種套包的想法, 這就是底下這個特意猜測用法的有可能失誤例子.

:   不過這個我完全沒有根據. 只是很好奇新系統幹嘛用informix.
:   戶政作業流程不是電腦改就可以改的, 內政部這邊要先修改作業辦法、作業細則,
:   報行政院院會通過, 公佈以後才能修改. 所以我覺得可以不用扯到戶政的作業流程去,
:   只需要討論戶政系統的作業方式就好.

就是因為都沒有更改, 人工時代是女方拿證書就能就地在籍更改女方.
老系統是電子化但無不同.
新規定雖要男女一併查驗婚姻欄與記錄, 老系統就是遠地查驗另一方,核可後再對本
地的申請方就籍更新, 就改完本地方. 再改遠地方就遠端取得遠端代理在遠端對另
一方的記錄做更新. 也就是各別一個個循序改, 沒有交錯性 concurrent update.

底下這個是刻意猜測, 過度鎖定的一個可能, 因沒分析寫好又同時男女方同時使用
造成dead lock的一個可能情形. 也就是原本各地可各自循序做的, 變成要經由內政
部號令出來, 內政部同時對男女方的戶籍資料庫同時各對男女發出更新命令, 這兩筆
男女更新是有相關性的查驗, 過度鎖定, 就因各自對鎖定資料次序不同, 就因交錯發
生死鎖. 因為是同時對兩個男女不同所屬資料庫作動, 所以 java 的 serialization
不發揮作用, 又因為向上集中, 男女各自資料庫有可能都在同一 data center, 也沒
有太大的網路延遲, 所以會交錯式concurrent.

 1.查證男女證書 2.向內政部發出配偶欄更新申請. 3.內政部通知更新男女方.
 3a-1.男方戶政機查閱男方, 女方資料庫戶籍, 並企圖鎖住更新.3a-2.更新男方.
 3b-1.女方戶政機查閱女方, 男方資料庫戶籍, 並企圖鎖住更新.3b-2.更新女方.
 最明顯的dead lock 就是互相先等待對方發不了的信息.
 3a-1開了男方,尚未拿到女方. 但同時3b-1卻已開了女方, 正等待男方. 雙方僵持
 直到 default time-limit, 再由3.內政部 重新發出通知.
因為資料集中, 無法怪罪網路延遲, 通知更新的雙方很快又同時發生, 就等
time-out 再重來.

: : 如果 男女方戶政機因不同負載有一方延遲, 就有可能不會互鎖, 就可能過關.
: : 這就形成了time-dependent error, 時有時無, 很難正確查覺.
:   這個例子可能過於簡單, 不過我承認在某些constrain下, 這是有可能造成dead lock
:   的. 只是這個dead lock 只會影響相關的資料, 不會在concurrent 250U的狀況下
:   造成system hang..

當然, BEA-000337 發生的原因有千百種, 但都是發呆或loop(或幹驚天動地的 memory
dump)太久, 超過設定值. 只要多了清不掉, queue 又有限, 塞滿了新的就進不來.

: : stuck 未必來自dead lock, 但只要呆太久超過default值都會出此訊息.
: : 那堆戶政機, 在新規範要求相互查核驗證下, 是會互動回饋的, 機會就有.

當然, 這是純猜測. 假如真是多了要經過內政部發號施令這個部份, 只要是有關聯
關係的查驗項目, 就按老系統循序驗後再去號令, 發生 concurrent access/update
的失誤問題, 反而因事緩則圓的 delay 就避開了.

開超跑的巡鑼警車, 有時就是會無事生非, 這跟用槍條例限制是一樣的.

當然, 開超跑的洋強盜來了, 沒超跑的警車怎麼辦? 這種事當然要先解決問題,
老招區域聯防可先緩解, 有了超跑當然要有,也要會正確的用, 老招新用也得防
失靈誤用.

上面的例可能都不是實況實例, 但出了問題找不出問題徵結, 那這行的不要混了!

→ mephiliu:台北市作業中心不在戶政司, 戶政司主機也不在台北市
主要的疑問在內政部主機在新系統前是複製備援, 但新系統之後是變集中發號施令.
各縣市都有已集中的縣市戶政機.

→ mephiliu:各縣市至少在五年前就有各自的集中主機, 並非新系統才如
→ mephiliu:此. 複製備援我看不懂是什麼意思. 新系統依然是在各縣市
→ mephiliu:主機進行作業. 只是同步模式就得去看設計架構才知道了
從手工改為電子化後是就地的電腦化, 連線到內政部是統計的需要. 此後也就戶警
分立, 警察不直接登載查閱戶籍記錄, 最老的資料就變成影像檔存到內政部. 雲端
化的推動後, 就是研考會為目前組織改造推動的向上集中data center, 戶政可跨區
申請, 不在地投票的要求就跟著來. 再加上網路化後的資安需求, 內政部的角色就
隨雲端需求變成集中管制, 但原來的最新戶籍資料還是在各縣市.

此次之所以無法新舊併存, 應該是做了管制的大變動, 除了新硬體程式換新, 資料
轉移外; 理論上, 部份縣市還是可舊系統合併著跑, 但卻是全面一起換, 應該就是
即使透過網路隔開傳送訊息, 也是加進了不相容的部份, 所以是退不回去了.

因為資安的疑慮, 一切都變得神祕兮兮, 有如諱疾庸醫, 黑箱子做事.

推 luciferii:mephiliu: 發現老師只是跟你東拉西扯了嗎? 推認真
還是要謝謝 mephiliu 很認真的說明.

這個戶政系統從電子化開始到網路互通後, 就有個疑問:資料要不要有同樣一份在
內政部? 現況是部份都會縣市是大量集中在市的幾個中心, 但是要不要再進一步
密集? 還是有幾個同樣資料也可同樣運作的複製型運作(Replicated Server)中心?
或是只做事後(譬如當天之後)向上集中備份? 開始開放對民間或其他單位的查詢與
相互查驗之後, 這個權限自然會收回集中到內政部, 內政部若只有延時落後的備份,
那當然不符需求, 但就近有個完全同樣內容同樣功能的都會區server就變得很有需
要. 也就是容錯複製型的跨地域(不是LAN內)server.
我的猜測是新系統還未完全成為是多個同資料同運作的複製型 server, 可能只接
近部份集中及統一管制號令, 也就是各縣市戶政資料庫降級為純資料中心, 所以舊
系統不能被各地區直接使用.
※ 編輯: ggg12345        來自: 114.37.73.76         (03/23 00:13)
→ mephiliu:你這個說法會有很多問題, 比方說資料複製方向的問題