• 我們準時開始。

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

  • 原則上如技術面沒有問題,我們就按照說帖來做。但依據關貿公司提供的壓測報告,我們發現並不是像上次開會討論時預期的,上次會議政委提出是壓兩百萬的量,但關貿目前壓測的情境是六百加六百(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 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的工作了,想辦法以這一頁為主,只要主要網址的網域是你們架的,這個是政府標準的宣示,這個跟好比像在中央社發一篇新聞稿是一樣的。

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

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

  • 就請金亨繼續協助。

  • 我們議程用完了,有沒有動議想要討論的?

  • (沒有動議)

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