我們準時開始。

謝謝政委，首先跟政委報告一下，本中心陳主任今天另有要公，所以沒有辦法參加本次會議。有關上次會議決議由本中心提供說帖部分，已事先呈給政委辦公室，不知道政委有沒有看過？

有看過。

原則上如技術面沒有問題，我們就按照說帖來做。但依據關貿公司提供的壓測報告，我們發現並不是像上次開會討論時預期的，上次會議政委提出是壓兩百萬的量，但關貿目前壓測的情境是六百加六百(1小時)，所以數值顯然差距很大，有關於Mac線上版要整合行動版的這一件事，中心的意見是一定要非常有把握且周全規劃，我們希望關貿在壓測上能夠做得落實一些。

經統計今年的綜所稅網路申報是三百八十六萬餘件，至於Mac電腦在臺灣市佔率，我們查無相關資訊，但據瞭解全球Mac電腦的市佔率約9%，以此推估Mac版需求大概是三十八萬人，我們估計四十萬人好了，一般壓測是做二至三倍，所以是一百二十萬左右，因此我們期待關貿在這一方面壓測做得落實，然後看看設備負載能力及有沒有可能再橫向擴充，以及橫向擴充設備有沒有一些限制，另是需要成本多少，我們可以一併考量。

確定未來採行方向後，我們再來配合修改說帖。

兩個澄清：第一個，也就是這個分母，四十萬也好或者是一百二十萬也好，可以報稅的時間是三十天？

是。最少是三十一天，申報期間是5月1日至31日，今年到6月1日，多了一天，也就是三十二天。

謝謝。

所以我們是除以三十一天，之前壓測的結果，剛剛講得是多少？

初估是兩萬，請關貿的同仁解釋一下。

我回應一下，我們收到Mac是加上行動版的人下去做，我們有收到兩個需求的數據，一個是以六十萬戶下去做壓測，後來我們又收到一個更高的數據，好像是為了符合一、兩百萬人。

假設全部的人都來？

對。並不是沒有落實，六十萬戶一壓下去，現有的機器到一個瓶頸，所以沒有辦法再往下做。

瓶頸多大？

可以做到一天兩萬件……一小時……等一下，我看一下。

分母是小時？

對。

不過還是有其他的瓶頸在，並不是現在的機器就做得到，我們透過這一次的壓測去檢視整個系統的設計有沒有瓶頸存在。

我們知道瓶頸會存在於報表的產出，會到PDF檔，我相信各位都有看過我們的壓測報告，平均反應的時間會比較長，再來是可能到達我們所呈現情境一的數量之後，後面其實表現就不是很好了。

所以我們再看到AP的CPU使用率，所以假設要符合六十萬戶的申報量，其實還是要再從報表去作改變，還有看報表改變之後的CPU使用會不會下降。

因為以現在CPU測出來的使用率來講，並不是現在一般營運狀況可以接受的，已經超過90％了。

所以變成我們現有的資源……

也就是滿載。

對，但一般正常營運不會讓它滿載，以現行手頭上可以測試的資源，我們發現六十萬戶就遇到瓶頸了，所以在昨天跟中心的討論也有說，原本希望報表的設計其實是利用html網頁呈現給他而已，這個是要再請國稅局或者是賦稅署考量這樣收執的留存，是不是可以被認定跟認可。

如果可以解決報表問題的話，當然還是要再去測，我們預期CPU使用率是會下降的，如果是這樣的話，我們以現在壓測的機容規格來看，我們會覺得這樣子是比較能夠容納60萬戶。

至於要容納更高或者是全部的申報戶，以現在手頭上的設備是沒有辦法進行這樣的壓測。

ok，我們來看一下數學。一小時兩萬，這個是滿載，不太能接受，一小時一萬左右，比較是還保留PDF報表的情況下，算是比較合理的，我們直接除以二。

可以看到螢幕左邊、右邊，三十一天、一百二十萬，等於是一天四萬，如果要一萬的話，也就是四分之一天，假設只有半天會報稅，也就是三小時。所以如果平均流量的話，其實左邊的狀況比較好

政委不好意思，我打斷一下。

通常報稅量並不是平均的概念，我們發現網路申報的時間，尖峰量有時在白天十一點，晚上也有一些尖峰量，以天來講，可能第一天或者是最後幾天，所以量不是三十一天平均，因此我們估的時候，一定要考量尖峰時間……

我們這邊既然用一小時當單位，我們知不知道同一小時最多同時上來報稅成功，而產生報表的數字？

有。

也就是最尖峰的那一小時，到底有多少人run？

兩萬五、兩萬六。

平均來講以白天來算，一天平均是三千，但是這個是平均值，但最高值是兩萬六？

對，一小時。但是這個是……

這個是極值。

所以目前這邊反應一小時承載兩萬六是承載不來的，但是一小時1萬是還可以的，我們目前是這個狀況嗎？

對。

離尖峰值，大概是我們差三倍的距離。

這個是所有的部分。

對，這個是後來要的，較高的數字，意思是我們現在推出一個新的服務，即使用Windows的人，看到這一個新的服務也跑來用用看。

即使是這樣，一小時也是兩萬六？

對，目前。

還好。我們希望它的效能是到達三倍，並不是到達幾百倍。可以這樣理解嗎？

對，政委再報告一下，目前Windows使用離線版的人數是99％，其實絕大多數都是使用Windows離線版……

……但那是因為Mac不能用……

……對，本中心經過評估，也有跟賦稅署、國稅局協商，是不是有可能離線版還是維持現狀？

當然。

就是在這樣的環境。

我們目前Web行動版是獨立的兩台server在做，做壓測僅就其中一台。

我們確定幾個原則，本來有離線版的需求，本來報稅好好的，並沒有要倒流到這一個，我剛剛講的是，如果大家看到新東西想要試試看，在Windows先不下載離線版，先玩玩看線上版，我們好像也沒有道理阻止它，不然就換他來連署了（笑）。我的意思是理論上只有四十萬人明年會來用新的系統，但是並不能預防四百萬人會來用的情況，並不是說我們發說帖四百萬人都來用，不是這個意思。

第二，你們有準備一套Mac本來會中毒、Oracle不支援、原廠不用、IE沒有辦法裝的說帖，剛剛談的保留是這個說帖下去了，會壓得太死，會變得明年無論如何都要把線上版上線，剛剛聽到的意思是不是這樣？

應該這樣講，我們具體考量Mac的Web版能不能立刻下架？是不是有保留的必要？

上次討論的時候，也考量可能會有一種聲音是Mac版報稅環境都已經建好了，今年好不容易都按照本中心宣導，也下載了Java元件，結果明年報稅的時候，我們又跟他說……也許他沒有接觸到我們一連串陸續的宣導，所以看到的時候發現為什麼去年弄好，今年又來新的一套，要重新處理。好不好用是見仁見智，有人覺得習慣就好用，要他接觸新的就感覺卡卡的。

所以我們考量Mac Web版要不要保留的問題，除涉及到資安面的部分外，未來我們新版設計必須非常友善。

你們的說帖裡面，倒沒有用易用性當理由，我們也不能之後忽然拿來當理由，要前後一致。

一個是作業系統商不支援的部分，到明年這個狀況只會更壞，不會更好。對使用者來講全部都裝起來，到明年的Mac新系統軟體升級了，所以又會升級到新版，那個已經不支援Java Applet技術了。即使今年環境都做好了，到明年的Mac升級之後，還要降級他的Java。

而且我們現在很難去預測，降級Java是不是一個可能的操作，或者是一般使用者是否做得到這一件事。

所以今年環境裝好了，明年要回到今年的環境，也要費一番功夫，這個並不會增進易用性。

我們以Windows的比喻來講。民眾已經升級到IE最新版了，但為了報稅，國稅局說「希望您下載IE6來開報稅網站，雖然微軟早就已經說IE6不支援了，但我們的網站只有IE6可以運行」，這個好像有太多問題。我們不應該跟民眾講這個。

所以，即使原本習慣本來介面的民眾，我們就是以「資安」跟「作業系統不支援」為原則。

到最後線上版假設出了什麼大災難，到最後完全不能用，我們的備案是什麼？就是「請他借一台Windows電腦」。

即使去借一台Windows電腦，在資安、支援上，也比降級瀏覽器的Java Applet技術來得好，這個是我個人的判斷。

如果有不同的想法，或者是關貿很希望維護本來程式的話，也可以提出（笑）。

我們的default也是這樣，Mac Web版下架停止服務，未來修正的版本或跟整合行動版非常ok的話，我們的疑慮應該就可以解除。

好，那是不是可以把說帖做一點修改？也就是裡面本來提到「會變成跨平台的介面」，我們現在這一個就不寫那麼死，我們可以說會研發進一步的方法，就是沒有資安疑慮的方法。

至於，最後deliver的方式是大家都能用線上版的經驗，或者是我們收斂出來，線上版必須導流，Windows不能來用。或者是最壞的狀況，也就是要借一台Windows電腦。

我們公開說帖把這三個保留，都不要寫死，但不會撤銷Java下架的決定，這樣好不好？

好，謝謝政委。

另外再補充，特別讓政委瞭解，目前行動版跟一般PC版不是完全一樣，例如像有自用住宅重購退稅或者是要申報基本稅額者，因為使用件數很少，所以目前在行動版的部分，是沒有支援有這一些所得類別的納稅義務人，這個第一點。

第二，整個頁籤的行動版跟PC版不太一樣，行動版是七個頁籤，PC版有十個頁籤，特別提供給政委參考。

在協作會議的時候，這個有提出來，本來是有寫，後來因為手機上沒有外接鍵盤，沒有辦法打那麼多字，所以就暫時省略。

但是其實本來就有寫出來，所以這個並不是額外開發，這個是介面設計的問題，也就是可能要偵測正在用的電腦或者是裝置到底有沒有鍵盤，有的話，顯示一些鍵盤可以打的，沒有的話，就看用什麼方式，這個是接下來協作工作坊可以設計的部分。

這裡我想要釐清的是：這個缺少是有意為之，並不是還沒來得及開發。

曾經有討論到是不是要提供給行動版用，但以行動裝置要鍵入這一些資料的話，是不太好用的，所以就沒有開發；但是撇開這個部分，還是有頁籤上的不一樣，PC版多三個頁籤。

頁籤的部分，會在後續的工作坊對焦，看要如何加回來。

所以關於說帖的部分，大家還有沒有想要說的、詢問及分享的？顧問這邊？

（搖頭）

說帖就對外，也就是Java Applet版本，因為資安跟支援兩大原因，明年就不會看到，但是「跨平台」這個先不要寫那麼死，說不定到最後測出來還是只有Mac跟Linux跑去用線上版。

所以說我們會研發出支援行動裝置、又沒有資安疑慮的解決方法。講到這一步可以吧？跨平台的部分就先不用寫，這樣可以嗎？

壓測的部分我看了。剛剛講的是兩台電腦，這邊只用一台在進行測試？

其實行動版原來建構的這兩台主機上，其實總共有三個服務，一個包括PDF下載，另外還有包括附件上傳，還有剛剛所講的稅額試算的下載。

試算PDF下載，在我們的壓測期間其實已經下稅，所以沒有影響。

可是在那個當下，其實營所稅的附件上傳還在進行，所以無法終止服務，我們必須保留一台對外仍然提供服務，所以我們才會只做了一台壓測。

未來真的要開放的話，我們壓測出來的數據，是以這一台主機完全是for線上版去使用所壓測出來的數據，可是這個數據不等於你日後再加上兩個服務的數據。

所以當然我們也會比較建議的是，這樣一個新的服務，如果假設不影響整體國稅申報為前提的話，我們會比較建議是一個獨立的機器來做這樣比較新的服務。

澄清一下，行動版產出PDF原本是在兩個不同的機器上跑？

產出PDF報表這一段，其實也是藉由兩台機器做成的報表伺服器產出的。

這兩台機器如果變成四台機器，上次的會議裡面有一個具體需要釐清的是，你們的程式要改多少，所以才能支撐在四台或六台機器上運作？

這個後來有評估嗎？

如果以現行功能的話，要保留PDF報表的話，要增加報表伺服器，其實程式是多增加布版的調整。

所以不用改程式？

對。但是還有一個前提是要開放所有申報用戶量，有一些程式必須會後檢視跟調整，原因是並不是只有用到這兩台主機，像暫存，像還有一些基本的資料戶號、IDN跟參數檔，以現行的系統來講，我們是會回頭查詢原來離線版DB裡面的參數資料。

一旦是要大量開放的時候，我們就要再檢視是不是有一些參數，必須兩邊做維護，以避免要不斷回到另外一邊而產生的效能問題，我覺得這個是要看到底需求上想要開放到什麼程度。

這個比較像是快取性質的東西，IDN跟DB在報稅期間會經常變更嗎？

（搖頭）

我理解，基本上是唯讀的。程式運行的邏輯是相同的，只是指向資料庫的位置，現在換到本機，而不是換到外面，可以這樣說？

（點頭）

這樣看起來都還好。現在很確定給你們四台或者是六台用來產生PDF，假設把流量負載平衡掉了，也沒有要改回html報表，對不對？感覺上是這樣。

理論上報表主機充足的話，不見得要改回去，如果開放量越大，其實耗損的資源會越大，幾百萬跟六十萬戶還是有差別。

理解。

因為現在有一個想法，盡可能用租用主機的方法做，假設用租用主機那一條路通的話，就是租那一個月而已，而不是永遠買資本，那六台永遠都要維護。如果用租用預算資源角度算的話，其實租一個月的十台機器不算什麼錢，比起你們用人工去改程式，那才是最昂貴的成本，所以如果能夠用錢來租資源解決，我覺得會比較容易。我不知道這邊的想法是？

不好意思，我想請教一下，如果是租用資源的話，以目前現行架構，也就是PDF的架構，機器商跟租用商是不是可以橫向擴充？關貿可以講一下嗎？

就是我剛剛所說的，好比像現在政府網路裡面租了六台給你們，你們要多久可以把現在一台或者是兩台的架構放在這上面來測？

其實昨天中華電信有提供所謂的租賃方案，在昨天的討論跟評估當中，看起來提供的是比較一般標準的環境，是不是能夠符合中心所要的SLA跟資安的policy，我們討論出來，好像還沒有辦法完全貼近。

差在哪裡？

之前也有給你們HGR環境設備的文件，HGR設備跟他們現在用的設備DB的軟體都不一樣，所以軟體是不是也會遇到要改？因為剛開始政委講的租設備，我有兩個想像，一個是用雲端租，一個是他們也可以去外面租設備，我不知道他們用哪一個租，也就是租來的設備跟平台及base是不是一樣的？

這個是完全不同的事情。

您剛剛提的是作業系統，也就是版本是否一樣？硬體的配置，也就是不管是記憶體或者是計算資源是否一樣？

但底下硬體跟OS都是可以解決的，因為租的都是虛擬化的東西。所以如果硬體比較差，多租幾台就是了。如果OS不相容，模擬就是了。

重點是上面。SLA是不斷線、服務提供時間的保證，資安是有沒有通過某些等級資安的要求，這個才是比較難克服的，OS跟硬體是容易的。

SLA跟資安不對齊的話，可能是我們要先講，這是我們可以拿來要求中華電信，具體來問說報稅的等級你們做不做得到。

所以，需要知道哪裡做不到。

不好意思，我補充一下，昨天的會我有參加。

基本上昨天有聽到一個具體HGR合約沒有辦法配合的點是，關貿自己控的機器如果硬碟有壞掉的話，他們這邊的做法是直接拿出來，並且要做銷毀，HGR答應可以做到的是消磁，但是並沒有在現有的合約裡面，而是要另外簽，昨天的說明是這樣，也就是另外簽的話，他們可以做到消磁，但實體銷毀的這一件事，HGR沒有給出保證。

其實昨天HGR派來的人，也非常擔心一些賦稅的資料進到他們那邊，他們的安全等級是否足夠，自己也沒有辦法保證，只能說他們目前有過27001，預計未來要過另外一個，應該是20000，大概是這樣子。

硬體的部分，比如現在是用Oracle的DB，如果這一個部分沒有辦法在OS上整合的話，他們有另外一種虛實整合的方案，但虛實整合的方案，昨天HGR表示要規模夠大，才願意這樣做，至於規模要到多少才算夠大，要開另外的專案去談。

好。先不管HGR版的虛實整合方案，我們沒有要講這個，講這個可以講很久。

HGR的方案裡面，剛剛是說Oracle跑不起來？

這個我不確定，因為Oracle DB也可以灌在Windows的server上，我不知道關貿如何處理這一塊。

而且他們也有Linux，他們不是只有Windows。如果Oracle灌不起來的話，他們就不用談了。

這邊再補充一下，HGR到108年，還不能保證有異地備援，這個也是我們會擔心的一個事情。

還有一個是資料庫的部分，是不是全部的報稅都要過去？因為不是只有綜稅，如果資料庫分在兩邊，後面作業是有問題的，因中華Hicloud建議資料庫跟AP擺在同一個網段，所以架構是很大的事。

一步步來：

第一個，異地備援確實是他們沒有具體承諾的事，如果到最後真的要用HGR的話，我們會有一個風險，也就是單一的資料中心突然天災地變不可抗力掉了。

如果要因應發生那樣的事，我們有更多的事情要準備，也就是並不只放HGR，而是移一部份的服務去放HGR。

這個確實是需要plan的。這個是一個爭點。

第二個是，銷毀的意思是把硬碟砸掉然後丟到果汁機裡面，這個意思嗎？

這個是不是有一個明確的作業規範，有什麼要點或者是要求？

當初在委外的合約裡有明訂的，我們對資安要求非常高。

所以這個部分沒有辦法以消磁替代。除非更改合約或者是作業流程，回去要求HGR把硬碟丟到果汁機裡，是這個意思嗎？

是。

好，這個是第二個爭點。

接下來，資安的部分我沒有聽得很清楚，合約裡面有要求他們過27001之外的其他資安認證嗎？

現在回答不出來，沒有關係，我們只是提出這一個詢問。

可能要回去查證一下。

這個還不確定是否為爭點，我們先不列出來。

另外一個，有關於資料軟體是否能夠運行在虛擬環境裡面，以我的理解，運行一定是沒有問題，只是要多買一些授權而已。

如果具體上有困難，那還是要說，不然我不知道是不是Oracle有客製化一版程式，只能在特定的CPU上面跑之類的（笑）？

如果沒有更多資訊的話，我就推定成其實資料庫是可以跑的，只是需要設定而已。

所以只有兩個爭點，也就是一個是異地備援，一個是銷毀或者是消磁的差異。

如果HGR到明年不提供異地備援，也不配合我們做銷毀，加上我們討論之後也有疑慮，也就是消磁不行。那我們這樣有別的能夠符合這樣的需求，但又調得出六台電腦給我們一個月的地方嗎？好比像財資中心自己裡面的電腦或者是其他的電腦？也就是撥過來用一個月？

沒有。

如果現在給關貿錢，關貿如果可以自己採購的話，你們有任何想法或備案？

我知道的不是很全面，不過我聽到的問題在於不只是機器，可能機房、機櫃現在好像剩下的空間沒有很多，是要再另外租機櫃。

但同一層樓，聽說中華電信的機櫃也都滿了。

你講的是實體的機櫃嗎？

是實體的，即便要增購實體的機櫃，還要再看。因為我昨天提出來之後，中心說機櫃的擴增不是問題。

現在機櫃都是在關貿嗎？DB都是在中心。

我們的機櫃是建置在中華電信的報稅機房。

關貿現在在中華的。

是在哪裡？

是在中華電信的信義機房。因為機櫃是別的公司在租用，我們的機櫃是五櫃，目前是差不多塞滿的狀態，如果要擴充一個機櫃的話，並不會在同一個地點，可能會在別的樓層，大概是這個問題。

不好意思，我回覆一下Oracle database。

我們是用在原來用的Oracle公司的機器上，如果要放在Windows上，因為Oracle不能在Linux，除非是在自己的Linux上，我們也沒有這樣用過，如果是Windows上用Oracle的database，這還需要有一些測試，因為平常有一些作業要做，因為備份、備援還要再作設定的。

所以Oracle是跑在Sun的OS上？

Solaris。

我可以問更細一點嗎？可以知道幾版嗎？

現在應該是Solaris 10。

其實Linux跟Windows都可以，只是我們沒有這樣測過。

我有聽過Oracle支援Windows，但是Oracle自己有出VM，Linux版本，但是Oracle有設定……

你的底層是Linux的話，上面可以模擬成任何東西。

Oracle以我的理解，至少在Linux作為主機的情況，至少可以作為這個主機被模擬的部分在上面運行（Oracle VM Templates），以我的理解是沒有問題。

至於Solaris能不能被模擬，這個也要稍微看一下，但理論上這不應該是一個問題才對。

即使你們只能在Solaris 10上運行Oracle，也可以要Linux去模擬你們的Solaris。

這個是技術上要測，還有你們布署是否習慣而已，這是習慣的問題。

我們也不能一直被Solaris綁住，最後還是要習慣跨平台。但不用在今年就習慣。

所以，那個機櫃一定要在同一個樓層嗎？也就是你們對於硬體、實體網段是有規範或者是限制？

如果不在同一個樓層，甚至不是在同一個機房裡面的話，就必須要想辦法拉網路線，就會有額外的網路設備等等的管理出現。

對，可是這個不是最基本的嗎（笑）？只要還在中華電信底下，還要讓你連得上，不會讓你連不上？

對，按照這種理論，沒有伺服器是做不到的。

理解，只是要多少時間而已。我的意思是，以同個機房在別的機櫃，請中華電信把網路線牽起來，這會需要時間嗎？

我沒有辦法回答這一個問題，因為資源不是我在管的，我必須要申請。

我們現在會需要知道的是時間。這會比同一個機櫃自己的機器調度來得長，長多少不是今天的會議可以知道的，我可以下這樣的結論嗎？

是。

所以主要是時間的問題，並不是SLA或者是資安的問題，只要是在同一個機房，應該就是一樣的。

除了用關貿現有的機櫃及HGR方法之外，還有沒有人討論過或者是想別的解決方案嗎？不管是你們自己的或者是財資中心的機器？

我們現在要解決的問題很簡單，就是兩台機器，如果要再多出四台機器要放哪裡，我不知道有沒有別的想法或者是可能性。

現在只講兩台機器的作業問題，現在的流程若全部都上來，操作行為都不一樣，含所得下載跟申報上傳的DB，應該不是只有這幾台機器的問題，你們是不是要補充那一塊？

這個就是我剛剛所說的量的大小，因為在網路的使用行為，應該這麼說，我們現在要先看量，像剛剛所講的參數，以現在來講，我就是搬到另外那兩台主機版放置，並不是跟現行的離線版共用，原因是使用行為會去不斷access，一萬多、兩萬多的使用戶，暴增到六十萬或者是百萬，跟原本整體國稅版的影響不會有太大的影響，但是爆增到一、兩百萬之後，我們勢必會對那個部分做一些影響評估。

可能必須調整做法，也就是必須把一些參數資料從原本離線搬過來行動版，但到底要如何搬、如何調，我們現在也沒有辦法直接有一個定案，它也會有一個影響效能，等到調整完才做的測試，我們才有辦法知道可能這邊又加重了一些負擔。

簡單來講，他們覺得現在對於本來的IDN.DB的資料庫，他們認為離線版是大宗用戶，線上版是輕微的，如果離線版減少，線上版增加，目前的這一個資料庫還沒有辦法清楚的輪廓。

他們的想法是，把用得到的部分view想辦法快照一份，然後放在實際運行版的機器上，這樣做之後就可以減低負擔，是這樣嗎？

IDN跟DB可能要弄清楚一下，我們比較care的是資料存哪裡的問題，因為剛剛有聽到要另外送一份，但事實上資料庫還有別的業務在用，我們也很擔心一個東西分兩邊，也就是資料的維護，線上隨時統計，跟很多東西要變動……

……沒有，那邊過來的是唯讀的copy，不會放回去，那個是參考用？你們會寫入嗎？這個要搞清楚的，這樣畫的意思是不寫入喔！

在整個申報期間，我們有幾次的資料更正。

沒有問題，那個只是快取清除的問題，當你底下DB有任何更動的時候，之前他們這一些快取必須要更新，這個是非常容易做的，但是問題是，如果他們現在拿過去，不是只是讀取還要寫回的話，那個才會出真正的問題。

但是以我剛剛聽到的，這邊只是參考它的，不管是資料或者是報稅相關資料，並沒有真的寫入的成分，所以當你們在說放一份來這裡的時候，你們應該是不寫回去的吧！你們會寫進當地的資料庫嗎？

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

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

對，就是每一次更新的時候同步更新，但並不是這邊有寫入跟寫回，沒有寫回，就是同步更新而已。

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

寫入是回到master DB，沒有要寫多重主資料庫，這大概一年也不會做得完的事情。

也就是單一的資料庫，有一些唯讀的資料庫以加強效能，這樣是非常單純的操作，應該是還好。

如果這個沒有問題的話，我就不算出後續待解決事項了。

這個部分是不是應該要再回去仔細評估一下？

因為我比較擔心的是，我們在溝通語意上有誤解，因為對一些定義上不熟悉，我覺得還是要仔細回去評估。

好。我們可不可以這樣子，這部分的運作方式，包含剛剛用畫圖也不那麼清楚的部分，我寫成「3」，就把它書面化，然後可能講清楚說預期可能會有這樣的操作，然後先確定我們大家對於這一個理解事項是相同的，但是這個東西就剛剛所講的，不可能馬上變成壓測的一部分，總要規劃完，先知道這邊有幾台機器，才會做模擬的壓測，才有意義，這個目前只是規劃，在「3」的部分。

不好意思，我要提醒關貿，雖然現在剛申報完，我們又要開始準備下一期的申報，所以如果未來方向確定了，甚至等設備都建置完備了，才能做壓測的話，在時間及期程上規劃要非常清楚審慎。

我再問一下，現在這兩台包含處理PDF之類的，現在是放在中華電信信義機房的關貿機櫃？

（點頭）

現在一台都放不進去了？

不是都放不進去，而是要整理一下，因為中華電信的機櫃有電的限制，所以空間上是空的，但實際上是沒有電的。

也就是沒有足夠的電力可以用，也就是要調整一下，看是不是可以挪一些空間出來。

這個什麼時候會具體知道？也就是什麼時候可以放幾顆CPU的事情，這個是比喬別的機櫃來得快。

對，就是要安排去問，預估要二個禮拜左右。

可以啊！就兩星期。

這個算出來的數字，1或2或4的意義是不同的。即使算出來是1，我們也可以想辦法放一台運算能力很強的電腦進去。

如果有空間，我們就可以想辦法生機器放進去，只要它有電，因此兩週之後我們要看這一個數字。

當然如果是0的話，當然另外要找別的案子。

HGR這邊我們要澄清的是，他們那邊的資安，你們這邊有沒有具體資安需求的條文？

我們剛剛請同仁查了，承商必須要有CNS27001或者是ISO27001的認證。

這個有。

其他包括軟硬體設備，必須要達到15408的EAL4的標準。

好啊！

我們提供書面資料給政委辦公室。

書面提供跟HGR對齊，如果都對齊，這個部分就不是問題，就只剩下異地備援跟消磁這兩個，對不對？

就合約的關係來講，我們對口是關貿，等於是關貿要負責，假設這裡面真的要用HGR的話，就是由關貿來負責這一塊。

當然，不是要你們負責，只是要把合約的文字過一遍。不然他們很負責，但違約了，這樣也不好，只是要他們負責時，不要擔心合約。

關貿可能也回去看一下合約。

關貿有沒有額外要加的？

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

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

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

……TSL1.0的意思是HGR在外面幫你做負載平衡，SSL termination是在外面的時候，才有這一個問題。

以我的理解，HGR是直接連你們的port 443，中間不會再放一台F5之類的東西作負載平衡，所以好像沒有這個問題？

其實他講的這一個問題，我之前也問過其他機關，他們也提過HGR。

我們探討他們的經驗，HGR是租一個硬體OS工具的東西，很多維運的東西都要我們辦理。

其實27001只是一個Guideline，但實際執行操作，是在滿足真正維運上SLA的問題。

很多監控執行配套要一起搭配，那個還滿多東西的，我覺得那個評估是要仔細。

我不是說不要評估（笑），不是這一層。

我同意要評估，反正關貿在信義機櫃還有多少，原來是電的問題，也就是要看一下有多少電可以用，有多少電就可以支撐多少CPU，然後就可以來估預計的流量，看如果擴充到三倍的話，到底還能不能承載，如果可以承載的話，至少這一案是可行的。

但是同時因為說不定下次算出來，機櫃是沒有電的，這跟臺灣真像……（笑）那我們就要找到別的方法移到雲端做，就好比像彰濱機房。

可是這樣的方法異地備援不解決、銷毀不解決，是會違約的，這一條路就走不通，除非我們修改過合約，對不對？

政府資料不會離岸，只會在臺灣。

理解，剛是開玩笑的比喻（笑）。

我想說的是，如果異地備援這一個問題，可以透過某些方式解決。HGR一般來講SLA還不支援異地備援，但他們有別的機房，異地備援技術上可以寫出來，只是還沒有賣給其他政府機關。

這是可以去談的，也就是專門為了報稅這案去談異地備援的合約。是否談得出來是另外一回事，但這不是一定不能的。

我們不說離岸，說這是離開固定機櫃的解決方法，也就是離地到雲端的解決方法。到最後如果談不出來的話，我們還是會回去需要知道機櫃的實際狀況。

我想我們兩個一併做。也就是先去盤點那個機櫃的電的狀況。接著是雲端的部分，我們先澄清他們資安目前的狀況，跟寫在合約裡面的狀況是否有對齊？再者是銷毀、瑕疵的部分，你們這邊訂契約時的具體用字，有無可能重新詮釋，或者是HGR有沒有可能承購砸硬碟的服務？

另外，關貿要做的另外一個功課是，他們打算把資料庫的某個唯讀副本放到線上版機器的這個具體程序，到底要放到哪一些部分，以及在有資料匯入更新的時候，要用哪一些程序？

今天用書面、逐字稿的方式呈現出來，兩個禮拜之後，再把這三個東西重新看一次，這樣可以嗎？有沒有具體不可行的部分？要跟我說。

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

資安也不太夠？你覺得對齊會需要超過兩週？

不包括營運的部分。

我之前看到其他機關的評估，雲端機房的想像跟我們平常在操作的想像不太一樣，我覺得那真的要花功夫。

應該這樣講，一個是你做下去會違約，或者是會違法。像剛剛講到的，如果資料真的離岸了，真的放在境外，這個就不行了。所以在違約、違法的部分，我想要盤點的部分是這個。

但是假設評估出來是不違約，那這個是否最佳解？是否是可行的技術解決方案？這個當然要細細下去評估，這當然不是兩個禮拜評估得完。

我想確定的是，過兩個禮拜回來，如果發現這個實際上一定違約或者是違法，那我們就省去後續技術評估的工作，我們就乾脆不考慮，對不對？

對。

這個程度還好嗎？

好。

（點頭）

今天就還是朝著報表保留本來的PDF格式的方向先去做規劃。

如果到最後把所有可行方案都窮盡了，發現真的沒有運算資源可以用、HGR也不可行的話，我們再回來看是不是犧牲一些功能來換取一些效能，如果沒有這一個問題的話，我想我們就暫時以這個功能來看。

如果以目前現行尖峰一小時兩萬六（所有人），目前測試出來只用一台，可以還算合理負載的每小時一萬來看，真的只差三倍。

這是在沒有做任何效能調校的情況下用尖峰值去比，我真的不覺得差很多，應該可以做得到。

在最差的狀況下，計算資源真的發現不夠用了，那Windows用戶不好意思，就請用離線版，可以這樣講？

（點頭）

Java Applet就確定下架了，那就說帖在修改之後，應該就可以對外了，下次就不列管了。

直接將說帖完成，看一下就可以對外了。

我們會後再作一點修正。

對。

說帖的上架還是透過PDIS？

這個就要問PO了，怎麼樣讓大家可以接受？

不是只有新聞稿的說帖，而是整個後續的規劃，說帖一定要再澄清說明。

有關於後續種種的進度、作業，我想基本上是中心的網站上要呈現後續的進度跟步驟，所以我想是多方面（進行），說帖在原來討論版還是會放上去，我覺得中心應該要設立類似專區，來呈現出完整的資料。

至少要有一個專有的網址，名稱不一定，也許叫做「Mac跨平台報稅軟體規劃」或者是「明年精進方案」之類的，但至少要有一個放在財政部網域的網址。

本來國發會的連署案只討論「難用到爆炸」，那個是易用性的問題，現在已經討論到精進的各種措施，嚴格來講是溢出國發會的討論範圍了。

所以有一個部會的專屬網址，之後PO不限制任何channel，就可以把討論的網址分享給大家知道，但還是導流回原本的網址。

我們回去研究看看哪裡適合放。

我要說明，其實一般民眾造訪機關網站頻率或人數不多，發布新聞稿的效用也類同，尤其現在報稅期已經過了，不知道能否引起一般民眾關注……

我想網址最好有一個很漂亮的標題，在社交網站上貼一下，可以試著看縮圖跟標題。

這裡的概念是把自己當媒體，也就是當成媒體供稿發出去，不見得大家來看，畢竟訂閱的人沒有很多。

後續導流，這個是PO的工作了，想辦法以這一頁為主，只要主要網址的網域是你們架的，這個是政府標準的宣示，這個跟好比像在中央社發一篇新聞稿是一樣的。

中央社先登，別的媒體會加值去做各種各樣的東西，但是大家都會回來查證說「中央社的版本是這樣子」，比較像這樣的想法。

每個機關的網頁都有最新消息，我們再來安排看看。

就請金亨繼續協助。

我們議程用完了，有沒有動議想要討論的？

如果沒有的話，我們很有效率，一小時結束這一場會議，謝謝。