我們回去會評估一下,至少給我們一週的時間到底要怎麼做,以及需要多少時間去做這一件事,因為可能要溝通的單位還滿多的。
順帶一提,這個需求畢竟今天剛聽到,我們帶回去評估,因為可能不僅是設備機房這一些問題,包含現有的人力跟時程都是問題,畢竟現在並不是沒有其他的稅目在營運,我們還是要做一些協調,才知道有沒有辦法做到。
是 。
但三個點是base在不同的規格下。
可能在這樣的場合裡面,我沒有辦法直接告訴中心說這一件事有沒有辦法做到。原因是,我現在不知道規格,再來是規格有幾個機櫃、空間,說不定擺不進去。我接下來做問那一份壓測之後,我很難分析那個結果,因為是兩份不同規格的東西,我是沒有辦法推估的,就算去推估,也是用很簡單的數學方法,也就是加減乘除而已。
如果現有增加兩台——還是還不確定規格的機器——壓出來的數據跟到時上線的是一部樣。
以壓測來講,我們每一年3月的壓測會訂在那一個時間點,我們會就即將要上線的環境去壓,那個才會核准。
首先壓測一定是跟他同規格的主機去壓,才有意義。
從第13頁這邊主要先前財資中心有邀請我們到中心這邊去就現有評估出來的現況去作討論,所以三個解決方案,其實是從財資這邊的業務考量,可能是希望維持現狀或者是部分擴大提供服務,或者是可能要提供一百二十萬用戶分別可能需要的設備清單,我們就幫他在第13頁開始做彙整的列出,然後提供給財資中心作決策的參考。
當時擴充是從盤點機櫃需求的來源是,因為我們上次從壓測去推估到如果擴充為六台營運主機,才會有後面所謂的擴充方案所須的設備清單。
從其他的層面如果真的要客製化,當下也無法回答成本跟時程,所以我們才會沒有去表明提出來的時程是什麼時候。
應該有一些東西不只是IPv6的這一件事,只是剛好講到IPv6,我們講到這一個東西是口頭上覺得其實不是不能建置,好像技術上可行的,建的話要多久。
第三個是HGR,如果要就現有的合約條件要符合的話,其實在於現有的平台,即便要因應擴充,在時程跟成本上可能都是來不及明年申報,我們評估簡要的概述大概是這樣子。
如果AP調整建議,我想這個是比較miner的,等到大家採行的決策確認之後,再來仔細檢視就可以。
這一份報告裡面很明確我們可以看到的是,我們的機房機櫃如果要擴充六台AP的話,其實空間已經不足了,所以我們後面也有做了所謂的擴充建議,也就是相關的設備清單。
最後是就現有合約範圍跟條件去做HGR可行性的評估。
第二個作業是,我們自己有主動提出建議,考量未來的效能問題,也就是有做AP調整的建議。
我相信大家看看過這一份報告,應該看過不只一次,上次會議當中交付給我們做的功課有三項,我們先盤點現有的機房、機櫃及電壓的狀況,然後瞭解是否充足以及是否要擴充。
(點頭)
不包括營運的部分。
在機房的盤點上,我想兩週是足夠的,HGR的評估,因為它的東西滿細的,所以兩週不夠。
這一些細微的東西可能都要逐一跟HGR確認他能夠配合,我們才有辦法……
我舉例好了,我想這一個例子回去再想一下是不是會影響,有一些資安要修補或者是什麼的,在國稅的考量上會覺得影響用戶,所以暫時承受這一個風險,而不要修復,但HGR因為資安的狀況,像TLS1.0要關閉,但有一些業務上的考量,國稅局會希望不要關閉,因為會不會跟機器有一些衝突。
HGR只是很簡略做介紹,是不是真的適用,我們真的要花一點時間回頭去看,包括中心要求我們有一些監控服務。
如果是正式的申報資料寫回,一定是寫回原來的Oracle DB,但是暫存資料就是在線上版的DB。
我們的做法就會比較建議類似像現在的所得,在離線那一邊的DB,在匯入的時候,離線的DB就會匯一份,然後在線上版的DB再匯一份。
我們所謂放一份過來通常是比較靜態的,中心也會考量說有一些靜態的東西有時也會異動,我知道,在5月份的時候。
可能必須調整做法,也就是必須把一些參數資料從原本離線搬過來行動版,但到底要如何搬、如何調,我們現在也沒有辦法直接有一個定案,它也會有一個影響效能,等到調整完才做的測試,我們才有辦法知道可能這邊又加重了一些負擔。
這個就是我剛剛所說的量的大小,因為在網路的使用行為,應該這麼說,我們現在要先看量,像剛剛所講的參數,以現在來講,我就是搬到另外那兩台主機版放置,並不是跟現行的離線版共用,原因是使用行為會去不斷access,一萬多、兩萬多的使用戶,暴增到六十萬或者是百萬,跟原本整體國稅版的影響不會有太大的影響,但是爆增到一、兩百萬之後,我們勢必會對那個部分做一些影響評估。
我們的機櫃是建置在中華電信的報稅機房。
是實體的,即便要增購實體的機櫃,還要再看。因為我昨天提出來之後,中心說機櫃的擴增不是問題。
但同一層樓,聽說中華電信的機櫃也都滿了。
我知道的不是很全面,不過我聽到的問題在於不只是機器,可能機房、機櫃現在好像剩下的空間沒有很多,是要再另外租機櫃。
其實昨天中華電信有提供所謂的租賃方案,在昨天的討論跟評估當中,看起來提供的是比較一般標準的環境,是不是能夠符合中心所要的SLA跟資安的policy,我們討論出來,好像還沒有辦法完全貼近。
理論上報表主機充足的話,不見得要改回去,如果開放量越大,其實耗損的資源會越大,幾百萬跟六十萬戶還是有差別。
(搖頭)
一旦是要大量開放的時候,我們就要再檢視是不是有一些參數,必須兩邊做維護,以避免要不斷回到另外一邊而產生的效能問題,我覺得這個是要看到底需求上想要開放到什麼程度。
對。但是還有一個前提是要開放所有申報用戶量,有一些程式必須會後檢視跟調整,原因是並不是只有用到這兩台主機,像暫存,像還有一些基本的資料戶號、IDN跟參數檔,以現行的系統來講,我們是會回頭查詢原來離線版DB裡面的參數資料。
如果以現行功能的話,要保留PDF報表的話,要增加報表伺服器,其實程式是多增加布版的調整。
產出PDF報表這一段,其實也是藉由兩台機器做成的報表伺服器產出的。
所以當然我們也會比較建議的是,這樣一個新的服務,如果假設不影響整體國稅申報為前提的話,我們會比較建議是一個獨立的機器來做這樣比較新的服務。
未來真的要開放的話,我們壓測出來的數據,是以這一台主機完全是for線上版去使用所壓測出來的數據,可是這個數據不等於你日後再加上兩個服務的數據。
可是在那個當下,其實營所稅的附件上傳還在進行,所以無法終止服務,我們必須保留一台對外仍然提供服務,所以我們才會只做了一台壓測。
試算PDF下載,在我們的壓測期間其實已經下稅,所以沒有影響。
其實行動版原來建構的這兩台主機上,其實總共有三個服務,一個包括PDF下載,另外還有包括附件上傳,還有剛剛所講的稅額試算的下載。
對。
至於要容納更高或者是全部的申報戶,以現在手頭上的設備是沒有辦法進行這樣的壓測。
如果可以解決報表問題的話,當然還是要再去測,我們預期CPU使用率是會下降的,如果是這樣的話,我們以現在壓測的機容規格來看,我們會覺得這樣子是比較能夠容納60萬戶。
對,但一般正常營運不會讓它滿載,以現行手頭上可以測試的資源,我們發現六十萬戶就遇到瓶頸了,所以在昨天跟中心的討論也有說,原本希望報表的設計其實是利用html網頁呈現給他而已,這個是要再請國稅局或者是賦稅署考量這樣收執的留存,是不是可以被認定跟認可。