我們所謂放一份過來通常是比較靜態的，中心也會考量說有一些靜態的東西有時也會異動，我知道，在5月份的時候。

我們的做法就會比較建議類似像現在的所得，在離線那一邊的DB，在匯入的時候，離線的DB就會匯一份，然後在線上版的DB再匯一份。

如果是正式的申報資料寫回，一定是寫回原來的Oracle DB，但是暫存資料就是在線上版的DB。

HGR只是很簡略做介紹，是不是真的適用，我們真的要花一點時間回頭去看，包括中心要求我們有一些監控服務。

我舉例好了，我想這一個例子回去再想一下是不是會影響，有一些資安要修補或者是什麼的，在國稅的考量上會覺得影響用戶，所以暫時承受這一個風險，而不要修復，但HGR因為資安的狀況，像TLS1.0要關閉，但有一些業務上的考量，國稅局會希望不要關閉，因為會不會跟機器有一些衝突。

這一些細微的東西可能都要逐一跟HGR確認他能夠配合，我們才有辦法……

在機房的盤點上，我想兩週是足夠的，HGR的評估，因為它的東西滿細的，所以兩週不夠。

不包括營運的部分。

（點頭）

在行動版的合約裡面是沒有要求壓測作業，但是我們實際上有做，所以像剛剛中心長官說的，大概是在五萬上下，我們以這樣的量去壓測，因為長期觀察市場使用的狀況，使用者大概是一萬上下而已，假設沒有做任何改變的時候，很難瞬間飆高，以市場使用者的狀況，也就是以五萬上下的量壓測。

這上面還有身分認證元件的設計考量，這不是單一方面關貿配合就可以解決。

我們配合中心研擬方向，再作細節的討論。

其實壓測相關數據，我要再回去諮詢一下，畢竟是我們私底下測的，有一些東西我們要再檢視，像這樣的測法，如果以後是要作正式大量的時候，這樣的測試方法有沒有需要調整的地方。

至於其他承載量問題的話，我想瓶頸的部分還是要回去找原因，畢竟這個跟連線數、點擊方式及動態設計都會有關係。

時間的部分，可能至少給我們兩週的時間，現在同仁都還在忙下稅後的事情。

整個機器都是為了電子報稅購買的，空間設置在中華電信機房。

這個沒有辦法（笑）。

要調。