我們一向準時開始，所以就準時開始。我們等投影機開機的時候，我們跟大家說一下今天紀錄的原則，投影機調好之後我只會拍這邊（指投影螢幕），不會拍到大家的臉，所以請第一次發言的時候，大概講一下說是哪一個單位、怎麼稱呼，開完會之後，我們會把這個給我們的速錄師做成逐字紀錄，做成逐字紀錄之後會寄給所有人，大家有十天內的時間修改它，任何覺得不適合被媒體知道都可以拿掉——包含這一句話——我們會在十天之後公布在網站上，也會把大家初步編輯之後的逐字稿在公布之前先給另外兩位政委，因為理論上這並不是我的領域，是吳政忠老師希望在上次協商會之後我來做這一件事，所以我整個處理的過程會紀錄給他知道，所以先請大家知道這一個狀況。

接下來，在報告之前大家有沒有想提的？或者是直接進入報告？好，那就直接進入報告。

防救災雲的辦理情形及後續的規劃，因為在2月9日及去年12月底都已經報告兩次了，我想今天的機會讓給各個承商來作報告，所以我是不是就跳過？

好啊！沒問題，下一位是NEC。

我們等一下報告的程序就從入口開始，由CHT報告安控案，接下來是EMIC，最底層是基礎案，就是分成這三個來報告。

好，沒問題。

政委好，首先是（簡報第2頁）Agenda，我這邊主要會有三個範圍：第一個，先說明承攬範圍；第二個，承攬狀況之後狀況說明；第三個，未來建議及做法。

（簡報第3頁）首先先看到承攬範圍的說明，我們會說明到專案範疇及系統的現行畫面，讓大家瞭解一下，接著是對於現行的系統架構，我們也有畫架構圖，以便讓大家瞭解。

（簡報第4頁）範疇：主要是在維護安控系統的穩定性，並且在災害應變開設期間，我們人員會進駐，以確保不會中斷，使系統都能使用。並且，在專案期間會進行系統優化調整，讓我們的效能能夠儘量達到最好。時程：其實是從去年9月16日至去年12月31日，所以將近有四個月的時間。

（簡報第5頁）因為時間只有四個月，當時做的方式主要是偏向於對於做系統的調校，程式的部分我們沒有特別動它。這個（投影畫面）是系統畫面，這裡所說的「系統」是消防署防救災入口網站，Url是「Portal.emic.gov.tw」，只要一打這個網址之後，就會跳到下面的首頁，這個是應變中心登入的。

登入有兩種方式，第一種是左邊的，用「我的E政府」帳號登入，登入就會連結到E政府；另外一邊是右邊的「機關帳號登入」，正常來講我們都是比較負責「機關帳號登入」，因為帳號來源是我們自己的OID LDAP，使用者在輸入帳號密碼之後就會到後端的LDAP認證，確認可以登入之後就跳到下一頁。

（簡報第7頁）這是應變中心的主畫面，各使用者應其需求而點到不同的項目。（上述）是整個負責登入的流程。

（簡報第8頁）這個是現行的系統架構，可以看到右上角的部分，會有OHS、WG，這個是說明這一張圖裡面縮寫代表什麼意思，像「OHS」指的是Oracle HTTP Server，主要是Web Server，是以Apache當作底層的架構。接著「WG」是「WebGate」，作為single sign on攔截session的軟體，作為一個plugin安裝在OHS上去。接著是「Weblogic」是AP Server，就是各應用系統運作的平台。接著是「OAM（Oracle Access Manager）」，Oracle推出套裝軟體，作登入的認證跟授權。接著是「OID」是一個LDAP的Server。接著是「Oracle DB」。

使用者在登入的時候，輸入網址之後，其實會打到四台，會經由load balancer去sharing loading，打到四台Web Server，並且Web Server裡面都會各自有一個OHS Server，以及Weblogic Server。

實際上登入的流程之中是OAM在做，所以OAM這邊規劃兩台，並且有做Cluster。因為帳號的來源是OID，所以也有做兩台，只是獨立的兩台去做LDAP，並且有DB。這邊主要系統的DB是Oracle DB。

（簡報第9頁）接著說明這個是這四個月來營運狀況的說明。

（簡報第10頁）我們接手之後，我們評估後提出以下幾點，就我們來看是比較不建議的地方：

第一，所有主機皆在同一網段，有安全疑慮；

第二，兩台OID各自獨立安裝，並在本機安裝單獨DB；

第三，四個AP Domain各自獨立，因無Cluster，所以之後的管理可能要四次，如果有做Cluster的話，我們可以由統一的單位去管理；

第四，OS使用的帳號不統一；

第五，主機OS均為Windows。就我們的經驗來講，還是建議以Linux為base的OS。

（簡報第11頁）接著是維護期間的時間整理，主要有三點：

第一，OID原本有預設密碼到期時間，但是當初可能交接的時候沒有很清楚交代，所以有遇到一個密碼到期時的問題，忽然很多人遇到密碼到期，所以我們後來調了，讓它的到期時間修改；

第二，消防署跟我們反映使用者在使用上不定時出現Bad Request的問題，我們也是找了一些資料，然後去做OHS的參數修改，從去年的11月修改之後，目前沒有這一個問題；

第三，系統效能的參數，之前都是預設值，後來做了很多次的壓測，去調整了系統參數，也增進了系統效能。

（簡報第12頁）我們說明一下壓測的歷程，我們負責的部分比較單純一點，其實只有使用者看到的首頁、登入，及登入到的系統主頁，我們沒有包含後面應用程式的布署。所以就我壓測的時候，我分為兩個步驟：一個是使用者看到登入畫面，可能什麼事都不用做；接著是使用者真的輸入帳號密碼之後，最原始六快磚的畫面。主要的壓測就是這兩個大項目，因為這兩塊基本上就可以包含到所有的項目。

我們說明一下我們使用的壓測軟體，使用的壓測軟體是OATS（Oracle Application Testing Suite），並且我們的壓測時間是從10月12日開始，因為10月12日之前，大大小小有很多颱風，所以剛好沒有辦法在那邊測，所以幾乎是從颱風季過了之後再開始測，並且一直測到11月29日，差不多這個時間。

（簡報第13頁）我等一下會首先說明使用者流程，也就是使用者看到的登入畫面，因為這邊只包含到使用者連到網路，因此包含的項目只有網路、OHS及安控的程式，第一個步驟不會包含OAM，所以我分為兩個步驟來測。

首先，我們測試的系統是OHS，並且我那時模擬的是，每秒三百人開啟的登入畫面，我不做登入，只是一直打，然後持續五分鐘。在測試初期，因為我們的經驗比較多是在Linux上，所以我們一開始初期設定的參數調整，其實是屬於MPM_worker的參數設定，但後來我們測了之後，一直覺得為什麼沒有用，所以我們後來又找了相關的資料，才發現到其實在……

……Windows上根本不是用MPM_worker。

是。

（笑）

對，他要用MPM_winnt，所以我們後來也調整了。下表可以看到，假設我們設woker，即便調到8,000，測試期間也不會改變，是1至60秒（參照簡報是記載67秒），但是我們一調了winnt之後，我們調到350，當然可以再往上調，但是測試的結果，基本上以這一個條件下，response就是1、2秒的時間就已經達成。

所以這一個OHS測完之後，目前我設定值就先停到這邊，繼續測下一個步驟，有包含OAM的地方。

（簡報第14頁至第15頁）這兩張表則是我壓測軟體所跑出來的報表，有興趣可以看一下。

（簡報第16頁）OAM才是比較主要的部分，我們的測試腳本主要分為兩個項目，第一個項目是2,000人於5分鐘之內，全部登入一次完畢，所以平均下來可能是7人/秒，只是第一個腳本是2,000人登完就不再做事，然後真的有在做事情的是後面另外一個步驟，也就是在2,000人登完之後，再繼續以500人的30秒登入完畢，並且每人重複30秒，30秒再重複登入一次，主要是這一個作業。

下表主要會分為兩個大章節，可以看到秒跟人數會有落差，我在測試初期可能不會以那麼大量的人數來打，所以我一開始在測的時候，是5秒鐘20個人，我們先看1至3這邊，比如第一個項目是5秒鐘的20個人時，我們打到1,200人次，等於我壓測幾次，那個時間是1秒鐘到70秒，變成沒有錯誤，後來在相同的條件下是5秒20人，但是我的人次打到2,000的時候，其實就會有一些錯誤產生。

所以那時候就懷疑OAM這一套系統在當初的狀況來講會有兩個瓶頸，一個是每秒多少人登入是一個瓶頸，一個是總登入人次也會是問題產生的可能點。

所以第三次我們調整之後，相同的條件是「20人/5秒」，然後接著總人次是2,000人，這次我們在測的時候，時間已經大幅縮短，登入時間變成1至3秒，並且無誤。

接著是我們又進行了「編號4」、「編號5」另外的一些步驟調整，然後我們再測，「編號4」、「編號5」的話會比較偏向於真的有按照這一個測試腳本來測，「編號1」、「編號2」、「編號3」主要是以壓測人次來打，「編號4」、「編號5」之後才會按照上面的壓測腳本來做，而且是「17人/秒」，那時測的最大值是「17人/秒」，調整前「17人/秒」的登入動作可能從1秒鐘至2分鐘都有可能，並且錯誤的次數很多，可以看到總人次因為有錯誤，而且回覆的時間也慢，所以總人次只有7,000多，但是調整之後的相同條件下，response就回覆到1秒，並且總人次變成1萬6,000人。

（簡報第17頁第21頁）這幾頁是壓測軟體所產生出來的報表，我們不特別說明。

（簡報第22頁）這裡有列出一些參數的調整列表，第一個Bad Request，當初使用者有反應使用者用一段時間之後會有Bad Request出現，這個時候我們調整OHS，讓HTTP Header能夠變得更強，預設是2048及4096，我們多加一個「0」，讓它多了10倍。

（簡報第23頁至第24頁）接著是OHS及OAM，我們有去調整CPU、Weblogic的參數及OAM一些軟體裡面的設定值。我們也有去調整LDAP使用多少的CPU。

（簡報第26頁）我們會建議我們的做法，以系統架構來講，改為三層架構，能夠提升安全性。OID設為Cluster，並且與OAM使用相同的RAC DB就可以了。接著是安控系統布署的AP Domain都設為Cluster，然後能夠統一管理。OS改為Linux，並且統一安裝帳號，以及建立異地備援的機制。

（簡報第27頁）接著是我們建議的架構，基本上不會差太多，只是說我們會切三層式的架構，每一個階層間都有firewall，OID會變為Cluster，並且使用相同的DB，以及我們的安控程式會讓管理者有單一的管理界面，報告完畢。

不知道雲辦或其他朋友，有沒有問題？

如果沒有問題的話，我大概有三個問題：

第一，先回到「建議系統架構」這張投影片，其實這就是那張圖，除了異地備援沒有畫上去之外，所以是異地備援這一整套在另外一個機房弄一次？

對，就是會建造一個能夠（被打斷）……

……其實應該說異地備援可以考量AA或AS的架構，一個是在台中完整起來，但是相對會貴一點，如果採用租用雲端的架構，平常是小的，特別的時候是放大，但是考量異地不一定有這樣環境的時候，可以用AS的架構，就是台北一份，出事的時候可以在異地端起得來，但是要考量是在OS層整備或者是DB層做，何時作sync，其實AS反而相對要考量的比AA更多，但是也是牽涉到未來資源從地層規劃到上層AP層。

你們這樣做完之後，理論上就是我本來的第二個問題，就是AP層或者Web層理論上都是elastic才對，就是你不用的時候，你三台都當機也不會怎麼樣？

是。

理論上是這樣。

是，實際上也是這樣。

所以你們打算用什麼？

只要有一台起來就好了，平常的時候。

應該說這張圖比如以台北的整個環境。

是啊！我的意思好比Web2、3、4都爛掉了，理論上如果你在上面那一層會dispatch，所以什麼事也不會發生？

對，假設真的是2、3、4都掛，因為1還有承受量，如果少量的話，就……

……那當然，因為平常沒有發生災害。

是。

意思是如果我們改成按時租用的話，平常2、3、4都是關的，對不對？

是可以排……

是elastic的意思？

是。

就是平常不開，或者甚至你provision的時間如果很短，甚至那時候再來provision都不會發生什麼事。

是。

理論上是這樣子？

對。

OK。（簡報第27頁）所以這邊的1、2、3、4只是你希望機器數量跟目前一樣，這個是邏輯上重新排列的概念，並不是一開就要開4台的意思？

對。

就是說台中是一台、一台，你也可以做到AA？

對，可以。

總比完全爛掉好（笑）。

（笑）對，因為AA是最完美的。

好，那有沒有（問題）？

台北、台中目前是failover。

跨網段。

沒有，沒有，我們不是以cluster來做……應該是說我們AA不是做兩邊綁cluster，對，是這樣，我們是用別的方式來做。

不是啦！我的意思是說，通常本地備援的時候，你有辦法設cluster，但是如果是異地的話，一般來講，你沒有這樣設cluster？

對啊！對啊！

異地AA應該是在DNS層解決它，就是離台中近，DNS就解到台中去。是嗎？

是的。

所以我的意思是說，這個架構看起來離AA比較近，離AS比較遠，離AS還要再弄一套，就像你剛剛說的。

對，AS還要再弄一套，而且在DB層怎麼樣把資料sync一致，也是一個issue。

如果是AA，你做streaming replication就好了？

對，但是要考量到DB的，台北跟台中的資料是否要一致，即使一致還是什麼時候一致，這個需要考量的。

你們通常的建議做法是什麼？因為台北、台中沒有什麼latency可言，你們可以只有一個寫入端，就是寫入到同一個，另外一個是read only這個是一個辦法，另外一個就是multi master，Cluster應該也不難，所以你們應該都處理過？我可以假設你們都處理過，還是其實沒有？

還是要看條件啦！畢竟還有硬體、軟體那一些。

那當然，我的意思是即使現在台中Web、AP、OID都只有一台，那也不阻擋我們測AA？

對。

不是我們兩邊馬上size一樣大才能測AA，這樣ok嗎？

嗯。

第三個，這個架構你們剛剛講沒有改到程式碼，像我之前看了EMIC程式碼，有建議細修一些LDAP pooling的設定，事實上你們評估完之後，看起來沒有什麼需要，4台機器本來就可以撐本來那個腳本的容量，所以就不太需要再改code，這個是目前的初步結論？

其實應該說這一個案子我們接了4個月，之前有處理過，現在還屬於一個未招標的公告階段，未來如果我們能進去的話，其實那一層的程式碼是有準備說如果需要的話……因為OEM也要升版，我們相信程式碼可能也要有一些要修改，所以是要翻掉的，但是目前4個月確實是有做一些參數的調整。

因為你們還不在一個可以改code的位置上（笑）。

那4個月改，我們也會滿擔心的。

對，理解。

所以它沒有測試環境這個概念？就好比AA我們可以說台中停止replication，我們拿台中來測之類的，但是目前沒有任何類似這樣的架構？沒有？不存在？

所以即使專門為了staging或測試機，我們也應該做AA，對不對？從某個角度來講（笑），或至少AS。

我問問啦！沒有問題，這樣看起來很正確、很完整，謝謝。請繼續。

主席、各位長官大家好，我是NEC，我今天針對應變暨資料服務平台部分作說明。

大綱的部分分成三塊，第一個部分是承攬開發範圍說明，第二個是維運狀況說明，第三個是改善做法與建議。

（簡報第3頁）這是整個雲端計畫裡面不同的區塊，我們今天所要承攬的部分即「應變服務平台」，裡面有整個資源應變中心所有需要的部分，等一下會有一些說明。

（簡報第4頁）整個案子分成三個階段來建置，在101年9月份決標，全案的經費是8,500萬元，由台灣恩益禧得標。

（簡報第5頁）這個是我們在應用系統使用到的一些基礎環境架構部分，我們每一個AP大概都使用到2台或4台的主機，圖片上或許小一點。

（簡報第6頁）這個是使用到的資源清單，左邊大概是應用系統的名稱，所有的都是在Windows的作業系統，裡面使用到的機器數量，包含CPU數、Memory、Disk都記載在這裡，這個是總計的數字，所以總共適用到49個主機、214G的CPU、396G的Memory及9,800的Disk空間。

（簡報第7頁）剛剛有提到我們分成三個階段來完成應變暨資料服務平台，第一階段有三個系統，第二個階段有八個系統，第三個階段是五個系統，分別在102年至104年三個階段完成整個系統的建置。

（簡報第8頁）剛剛有講到我們的應用系統是資源應變中心，等於是生命週期裡面的作業，所以我們不同的階段都有不同的AP，包括一開始災害發生的時候，我們要作應變中心開設的動作，開設完畢之後，一開始可能會有長官蒞臨工作會報的作業。接下來可能開始陸續有災情進來了，所以我們會有災情查報、災情管制的AP作業。當然在災情裡面，除了防災人員作災情通報之外，我們也跟119做一些災情的介接，包含了有民眾網路通報的部分，災情也會進來；我們也有跟企業來作一些災情的介接，他們會將災情適時提供進來。當然有一些從新聞上看到的，也會從這裡納入。

在這個階段之後，接下來有一些災情的搶救跟現場狀況的回報，這個部分我們大概會有一些任務指派，請相關單位來處置，這一些相關單位處理完畢之後，這一些相關單位處理完畢之後，會透過這樣的系統回覆。

監看的部分我們會收透過不同的管道，包含環保署的平台，把相關的監測資訊、警戒資訊收納進來，讓應變中心的同仁可以參考。

後續的人命搜救、維生搶修的作業，告一個階段進行之後，有一些統計數字的回報，因此在通報表的單位當中，各單位不同的主管機關會把相關的數字，每三個小時彙整到通報表裡面，再陳報到災害應變中心，我們也比對系統來support這樣的作業。

後續可能有一些現場疏散撤離、收容安置的動作，我們也有相關的系統去support現場，像警察人員去做現場撤離的動作，或者是應變中心收容處所的開設，去把這一些災民收容進來，我們有這樣的系統來處理。

到最後整個損失統計、訊息發布，也是透過相關的統計資料提供給後台，後面有一個災害情報站，民眾給災害情報站情報，然後會來作通報。到最後整個專案結束之後，我們系統裡面有一些相對應的應用系統來運作。

我們也support三層級不同的操作，包含從三百六十八個鄉鎮市區到二十二個縣市政府，最後到中央政府。

（簡報第9頁）目前在整個EMIC裡面，有跟不同的系統跟單位來介接，第一個是自建的部分，因為有幾個縣市是自己去建所謂的應變系統，沒有使用中央的這一套，我們還是有跟他做一些資料上的介接，包含台北市、新北市，沒有做一些專案開設撤除資料的介接，一些災情資訊，也會通過這一些管道進來，還有剛剛提到的災害發生通報表，通過這一個管道送進來。

119是另外一個消防的體系，在災害期間也會接到大量報案的電話，這個部分的災情也會透過介接的管道納入到EMIC。

在企業當中是有統一速達、中興保全、究心公益科技有共同介接，會把應變期間將災情送給我們。

通報表剛剛有提到不同的主管機關負責不同的業務，每三個小時的時間點裡面，通報表要也報進來。

另外，在環保署的資源交換平台，裡面有一些監測跟警戒資訊，我們也會再跟他做即時的介接，在這個系統裡面呈現，這個是在EMIC收納別人資料的部分。

在EMIC同時在這個地方會產生三種資料，會把它放到兩個Open Data平台，一個是政府資料開放平台、另外一個是內政資料開放平台，目前產生的三種資料，包含了災情、避難收容處所開設情形、災害應變中心開設情形，我們剛剛講到收了這麼一堆的資料，把它歸納彙總之後，每二十分鐘之後會有一個CSV的檔案定時產生出來，放在這一個平台上，供需要使用來作接取。

而避難收容處所開設情形是，我們系統裡面有跟衛福部作避難收容處所資料的介接，例如端是目前六千六百多個避難收容處所，我們應該每天會有一個時間去把異動的資料收納到我們系統裡面來，這個部分來的資料是所有避難收容處所的一些基礎資料，像位置、收納人數、適用哪一些災害類別等等，收進來之後我們會作加值，就是目前是不是屬於開設的狀態，因為災害來的時候，有一些避難收容處所會開設收容災民，我們會把開設狀態加值到避難收容處所的屬性裡面，再把資料公開到政府資料開放平台，讓有需要的人可以下載下來，（讓民眾）是目前全國大概會有哪一些避難收容處所正在開設或者已經撤除等等。

最後一個是，包含中央、縣市、鄉鎮，如果有開設應變中心的話，要把開設情形開出來。

（簡報第10頁）這個是災情的部分，剛剛有提到不同的管道，包含119、防災人員、企業、民眾通報災情，等收了進來之後會有一個排程機制，20分鐘就產生一個CSV格式。因為這個是CSV檔案的sample。

（簡報第11頁）應用的部分目前有NCDR跟運研所，就我們所知，這兩個單位確實有這一些資料在系統當中做一些加值的運用。

我可不可以就這一張先問幾個問題？

是。

不好意思，因為這個是這次會討論這個案子最主要的原因，就是包含台水、台電的介接，及這個資料如何做更友善的呈現，而不只是列出純文字，所以一樣有三個問題：

第一，我實際看了一下目前的資料，不太能說是CSV，anyway，是用空白分隔的，他的資料可用性有一點奇怪，所以我問一些很細的問題，不好意思。

好比第一列叫做「0213路上交通事故」，那個是固定的title嗎？

不是，那個是目前中央災害應變中心如果有開設專案的話，它的專案名稱。

喔！那如果你有兩個以上的專案？

目前我們的系統架構同時間只能一個。

喔！你們一次只能一個災害？

只能有一個專案開設。如果要開設的話，要陸續先把這個撤掉之後，再開另外一個。

好，瞭解，謝謝（笑）。所以它有一點像title的感覺？

是。

但是這一個「0213路上交通事故」，事實上我們當然知道很嚴重，可是它不可能包含2016年的資料，它資料集裡面還是有2016的資料？

應該這樣講，「0213路上交通事故」是昨天晚上十點鐘的專案。

我知道，滿嚴重的。

因為我們系統裡面，三層級都可以開設專案，鄉鎮可以開、縣市可以開、中央可以開，可是因為有一些層級開設專案之後，通常有一些不會做關的動作，就長時間擺在這裡，所以去年最後一個颱風是艾利，他們就擺著都不關了。

我們再往下抓開設期間的時候，我們就從中央往下看，中央看縣市再看鄉鎮，我們是抓目前所有開設中最早的……

……我有聽懂了，我們剛剛在看的時候，就覺得非常詭異，怎麼會有2016年的資料。

對，因為有某些專案沒有關，所以可能是在去年的9月、10月，或者是更早，所以你會發現為什麼會拉到這麼久以前的災情。

所以我也沒有「0213路上交通事故」title開的時間點，如果有的話，我就可以從那邊抓就好了。

那個應該是在應變中心開設情形……

……瞭解，瞭解，但是就是要自己用大腦去join它（笑）。

是。主要是因為某些層級開了之後，就不去關它。

理解，理解，這個是使用習慣的問題。

是。

經緯度即使是只有點的部分，也有一些自建系統是「0,0」，這個就表示自建系統裡沒有geotag的能力，是這樣嗎？

對，通常看到那一些比較怪異的座標，大概都是介接進來的，我們看到「0,0」，這個座標顯然是沒有。

或者是在臺灣以外的，為什麼會跑來這裡。

有時我們在地圖上看，有些點怎麼會跑到海中間或者是非洲……

……對，是。

那個可能因為接進來的時候，他給出這樣的座標。

所以你們不會主動去通知你們給的座標格式有誤，或者是日期有誤？

介接的部分大概是進來是什麼，我們就呈現什麼。因為我們當初其實在介接的規範有特別說明這個部分希望能夠給正確的，因為我們基本上接進來……

……對，因為我有看程式碼，就是完全沒有檢查（笑）。

因為當初在介接的規範裡面……

……沒有寫這個。

有希望他們提供給我們，所以我們認為應該會提供正確的。

對不起，一直問很細的問題。所以同樣的就是說，如果他的發生時間，我看到一些來源，其實有經緯度，好比像桃園市龜山區的停電，很奇怪都發生在整點的時候，9點發生或10點發生，或者至少在整分的時候，可是理論上發生的時候，登入就這一個解析度嗎？或者是用介接時間來算？

我們那個畫面，就是新增的畫面，點開的時候其實是系統時間，但是使用者可以自己去調整它，有時災情發生可能是十分鐘之前發生的事，他可能現在才做登入，可是他要……

……那就不可能精確到秒嘛！

對。

甚至也不可能精確到分鐘？

那個其實是使用者可以自己改。

我理解。

所以這樣的意思就是說，你們系統對系統的介接，剛剛不是有好幾個嗎？

是。

理論上那應該是用他們的登錄界面才對？

對，對，如果是接進來的話，就是他給我的時間。

所以我看到這一種很奇怪的，或者都是在整點的，就是之前來用你們的系統，或者是在他的登入系統裡面只有十分鐘的解析度，那這一件事也不會特別去盯就是了？

是。

因為我後來看到有些有更多資訊是在純文字的部分，就是會在純文字的部分會說幾路、幾號，或者是路段什麼時候到什麼地方，但是geometry是一個點，所以這就表示資訊流失，對不對？就是它本來是有路段的，甚至一段到二段，但是在你們這邊是點跟經緯度。

應該這樣講，我們提供的定位方式其實有點……

……點、線、面三種，可是面幾乎沒有人在用。

不用說面，線都很少人用。

對嘛！謝謝。

因為大家點一個點就過去了，大概地圖上有一個位置就行了。

OK。

然後在描述裡面再用文字描述……

對啊！

這個其實就是使用者，因為我們沒有強制做這樣的介入，我沒有辦法說從文字解析因為這個是面，所以強制你一定要做成面的標示，這個辦法沒有辦法從文字描述。

是，因為如果只是像路樹倒塌，我覺得無所謂，可是如果好比從一段到三段，這個應該要是線段才對。

這個就取決於使用者要如何去做輸入。

理解。所以以目前台水的部分來講，停水已經接進來了？

停水部分，我們之前有跟台水開過會，他們有給我們一個sample，我們有試過，但是後續目前還沒有……

沒有機器對機器過來？

對，沒有進一步新的東西出來。

好啊！我想會後sample再看一下好了，我自己來問台水。

好，到這邊可以了，請繼續。

（簡報第12頁）因為我們的系統大概在104年下半年開始繼續陸續上線使用，也經歷了幾個颱風，到了104年最後一個颱風，我不記得哪一個，反正10月份有一個颱風結束了，我們有跟署裡面討論，系統歷經了幾個颱風以後有做一些調整，包含了「待辦事項提示調整」，我們在主畫面右上角有一個所謂「待辦事項提示調整」，也就是是不是要填書報表、是不是有災情案件指派給你要作回覆，大概有六項。這個部分本來在文字後面有一個括弧的數字，也就是通報表填報，後面有一個「3」，表示有三個表還沒有回覆；災情指派後面有一個「5」，表示有五件還沒有回覆。

本來是有上述的統計功能，這個部分對系統的效能還滿吃資源的，要很即時計算這一些。

有聽懂。

而且是依照登入的人是哪一個單位，並不是每一個人看到的數字一樣，因為有的人要辦理的事項要計算，所以滿吃資源的，所以我們就有跟署裡面討論，因為使用者說看到3、5、8，其實對他來講沒什麼意義，只要有或者是沒有就好了，所以我們後來就改成紅綠燈，紅色就是有、綠色就是沒有，如果是有、沒有，這個判斷就比較容易，比較不吃資源。

用EXISTS subquery就好了，比較不吃計算資源。

另外我們也在這邊可以開關，也許有時認為提示的這一列不需要顯示，就可以把它關掉，關掉之後就不用做統計的計算，系統效能上就ok，這個是第一個調整的部分。

第二個部分，我們針對SQL的部分檢視，把有問題或者當初下的不是那麼好的語法挑出來優化，當然是透過一些工具，去看我們調整完的指令是不是比之前有效，如果有的話，再把它換上去。

另外，像剛剛提到Open Data第一個欄位有一個很長的一串數字，那個是所謂災情的案號，那個是透過Stored Procedure去決定怎麼樣產生案號。這一個案號在取得的時候是做table lock的動作，後來我們認為這樣子會常常造成lock的現象，也就是改成row lock，發現改完這樣之後，確實有比較好，這個是有做一些調整。

接著是資料庫存取的部分，Isolation Level的設定，我們把它改成read uncommitted，也做了一些調整。

接著在通報表的部分，我們有提供給外部一些介接，取通報表的統計數字，這部分我們也有做Cache機制，如果是在短時間內重複取同樣資料的時候，就可以從Cache抓給他，就不用再去資料庫重新撈了，我們有做這一些調校的部分，這個是在104年10月至12月。

（簡報第13頁）在壓力測試的部分，我們有針對系統裡面幾個作業有分別不同的情境下去做的，可以看到有七個系統，依照整個義務面的作業流程，去設計操作模型，每一個系統我們大概看到右邊是模擬了兩千四百個使用者，單一系統是兩千四百個使用者同時下去進行操作，然後持續的時間是三十分鐘做壓力測試，每一個操作時間是以六十秒來作區隔。

（簡報第14頁）以這樣操作的情境所做的壓力測試，你看到下面這一頁，左邊是主機端出來的數字，主要是看Fail Hits、Total Hits，右邊是我們做的Jmeter的壓測工具，壓出來的結果大家可以看到右邊，登入的部分我們可以看前一個topic講過的，主要是看kp的部分，平均維持滿快的，大概是三秒以內就有平均回應。

（簡報第15頁）這個是個別不同的系統，用兩千四百個下去壓每一個系統，我們整個再全部壓測，那整個壓測就會有多少人、每個系統分配多少人數的議題，當初在署裡面有根據整個實際發生災害時，全國會使用的防災人員統計數字給我們，就是八千一百一十六人左右，這個數字署裡面統計給我們的。

我們就把這八千一百一十六個人依照去年梅姬颱風，我們大概算了一下每一個系統使用的次數，把這個比例算出來。

這個次數是人次嗎？

是操作的次數，是人操作的次數，就是點擊。

就是假設每一個人點的每個系統差不多的分配？

是。我們就依照這個比例，把這八千一百一十六人分配到這一些系統裡面去，就是最右邊這個欄位，加起來就是八千一百一十六人，分配到不同系統有兩千多、一千多，也有幾百個。

（簡報第16頁）我們依照這樣的結果，把這所有的系統同時間依照這一些人次去做壓測，持續的時間也是三十分鐘，我們看到上半段是主機端的，看到Fail Hits是不高，大概是零點五幾，有些都是零。下半段我們CLIENT的Jmeter，整個AP……因為資料太多了，total的平均數字算出來，大概是二點五秒，是小於三。

等一下，為什麼這一頁可以這樣看？災情管理的那四台，應該是一樣的設定，對不對？

是。

這四台應該是當作identical environment來看待？

是。

所以這樣的意思就表示它有一個ceiling，差不多到九千個Hit。

一旦over那個ceiling的時候，看起來系統會開始爆炸，如果他的軟體完全一樣的話，應該是這樣看。

你們還有沒有再往上測？就是你看八萬一跟八萬四的時候，它沒事，九萬二的時候，Fail 三十八筆，這樣就不linear，除非是那一台的configuration跟別台不一樣，不然就表示這一個系統有一個閾值。

還是我理解錯，這是不同的電腦？那一台CPU比較少，所以這個是應該的？（笑）

硬體支援是一樣的，軟體也是一樣的，設定也是相同的。

所以你還有再加，好比像多壓一點到災情管理去測它的閾值嗎？

目前就是用兩千六百五十六個下去做。

所以等於四台都吃掉兩千六百五十六？還是不是？是兩千六百五十六分到四台？所以每一台分個六百多這樣子？

因為前面有一個VIP，所以有F5自動配。

F5自己配，所以有人運氣不好，骰運不好就會多分幾個？

是，是，主要是看怎麼配。

那這樣的話，我會覺得說，就是你不多拿個，好比像兩、三倍去測，你就不知道那個九萬是運氣不好，還是真的就是九萬會開始爛掉。

對，這個可能就是再去測。

好，沒關係，請繼續，不好意思打斷你。

這個大概是這個部分。（簡報第16頁）這個是在1月份做的，剛剛前面這邊忘了（說），這個大概是11月份做的，最左邊可以看到日期。

（簡報第17頁）105年中央災變總共開了六次，第一次是0206震災，再來後面是尼伯特，再來是莫蘭蒂、馬勒卡連著那一個禮拜，就是中秋節的時候，大概有六個。最右邊有看到這六個開設的機會裡面，有看到災情筆數，「0206震災」是一千兩百多個，「尼伯特」是三千兩百個，「莫蘭蒂」八千七百個，「馬勒卡」是四百六十，最多就是「梅姬」，有兩萬五千多筆，「艾利」因為擦邊過，在我們的系統裡面沒有……

……沒有開設。

沒有人登打災情。

有開設，沒有登打。

大概是這樣子，給大家參考。「0206震災」、「艾利」的使用者沒有反應什麼問題，這四個中間有反應一些問題。我們簡單來講，大部分看來是資料面的調整，也有一些是系統的問題，我們當下做即時的處理，這一些問題都處理完。

（簡報第19頁）我們看到「ZK升級測試」的部分，因為署裡面未來有一個計畫，希望能夠做成手機……

……手機登打。

對。署裡面有請我們做ZK的設計，因為ZK自己有說在8.0開始……

……開始做RWD。

有support。

你們有跟ZK簽約嗎？還是只是用ZK OSS而已？

我們有跟他簽。

好。

我們在這邊有實際上升級到8.0.4，這個是原本，我們就拿同一個作業來看，這個是工作會報的作業……

……然後就會破版。

它的界面是原本長這樣，我們升級到8.0.4之後就會變成這樣（簡報第20頁），版面上有一些很奇怪的東西跑出來，這個是在桌機上看到的，就是跟前面那一頁的解析度完全一樣。

沒有啊！這只是CSS的input option的display attribute，改一行就好了。

瞭解。

然後我們再把這個瀏覽器去設置。

對。

我們設成iPad。

對啊！

主要是下拉式選單的部分。

對啊！跟左邊編號下拉式選單沒改到。

再跑到iPhone就會像這樣（簡報第22頁），我們的建議是這樣，雖然很低，但是還是需要橫的。

是，因為它的字就這麼多。

沒有縮小。

對。

字還是這麼小。

是啊！

所以對user的操作是滿方便的，（簡報第23頁）我們有提幾個建議：第一，8.0.4有一些樣式會亂掉。

這個就改一行。

對。如果真的要做RWD，因為RWD主要是支持行動裝置，是不是長的畫面要跟桌機上使用一樣，可能會跟使用者操作行動不是那麼適合、貼近，所以也許在畫面上要做一些調整，要比較小尺寸的螢幕上，比較容易查到要的東西跟操作，這個是我們的建議。

（簡報第24頁）最後改善的部分，我們還要持續配合專案開設、署裡面的定期演練，持續做一些系統的優化，消防署在未來有計畫做一些盤點系統的升級，我們當然也要配合後面這些的應用程式，應該有機會去作調整，也許有一些要測試或修正，我們會全力來配合。這個是今天的說明。

謝謝，那我就繼續問了。

第一，往外的頁面，www.emic.gov.tw，也就是不用登入就可以看到的外網，這個東西也是同一套嗎？

這個部分不是我負責的。

所以這個是災害情報？

是。

可是我這邊看到的資料都是EMIC系統的那一些資料。

這個部分我來說明一下，因為當初有跟情報站有談，資料來源是我們這邊，所以我們有寫了web service。

喔！所以是……

那一塊塊需要的就是copy我們……我們吐資料給他，他show在畫面上。

所以這一個東西並不是經過Open Data？

對。

是專門開了一個類似專門給他們用的東西，是這樣子？

是。

好比我這邊按交通狀況，我就會看到更多交通狀況，這個更多交通狀況其實在後台是有copy你們的API嘛。

是。

就是這幾個區塊的內容。

是。

可是因為我這邊看到，HTTP request只有到gateway的dataservice.aspx，帶的參數是你們的interfacing getpicture.aspx，意思就是說你們為他們可能接的都單獨寫了aspx？

不是，我們都是JAVA程式。

也就是說，我現在看到的還是他們的service proxy？

對，他們應該是包了一層。

那你們JAVA給他的是什麼？JSON或XML或CSV？

大部分都是XML，少數一些是JSON。

OK。這個中間除了我看程式碼之外，沒有別的文件嗎？

我們當初跟情報站有一些spec。

只是沒有放在說明文件裡……因為我沒有收到（笑）。

是，會後會再提供。

瞭解，所以說是存在一個Web Service的，只是目前只有一個consumer。

每個服務可能都有一個。

對，我理解，你們各有一套Service？

是。

但目前只有emic.gov.tw這邊在call你們的？

對。

沒有別人call？

沒有別人。

好比他們多要一個，你們就開一個view給他？

對。

然後這中間的spec是他開給你們，或者是你們開給他？

我們會先討論，他大概希望取得什麼樣的資料，我們這邊是每一個他要的都有，如果都有，我們就重複，可能有一些我們沒有的話，好比就會從那邊取得，如果需要我們提供的話，我們就會討論好從哪一些資料。

就專門寫給他？

對。他要丟什麼參數進來，我們要吐什麼資料，大概都會討論。

瞭解，你剛剛目前提到spec，這個spec是用什麼語言寫的？中文嗎？（笑）

當然。

（笑）因為我說是只有中文，它是一個word檔，或者是機器可讀的API spec？

沒有，就是類似word。

所以他們那邊改了系統都要跟你們開會，就是說不可能bypass掉你們自己去抓raw data，你們跟他唯一的端口就是這一些Web Service？

是。

所以反過來講，如果現在是別人，NCDR之類，要拿這一些Web Service，他們需要做什麼？

因為我們有一個資料服務平台，這個Service丟到這個服務平台就可以丟了，只是因為現在這一些Service是我們跟他們在用，不需要外部使用，所以沒有掛到資料平台上。

這裡指的是包了第二層的API proxy嗎？一般網路上的人也可以呼叫的的API？

Web service是內部的，所以前面URL的前段可能是外面URL的……

……是內網？

對，對。

因為這個東西我看是GET only，它沒有寫資料回去，對不對？還是它也有POST/PUT？

它沒有。

所以這個是民眾看的，等於所有的request都是GET，理論上你們約好了，好比這邊一分鐘才會更新一次的，應該就可以cache一分鐘之類的，運氣好的話。

我們是希望它能cache，可是因為當初在討論的時候，他們這邊不想存資料，所以變成只要user有一個Hit，它就叫一次後端。

對，因為我這邊看Cache-control: private，意思是我每一次載入，後端就會query。

對。

這樣何苦呢？

因為我們有建議希望它存，如果它發現短時間取相同的資料就不要再來問。

對啊！

其實我loading會很重，可是他們有一些考量，可能每一次Hit就來問我。

我可以問是什麼考量嗎？

這個我們不知道為什麼。

你不知道為什麼？

不好意思，我說明一下，因為這個問題我們在署裡面有討論很多次，基本上我們怕每一個Hit都來跟我們要……

對啊！是啊！

我們也希望署能夠響應要求，但是對方廠商覺得他們用這個方式，對他們來講……我們也不知道他們的原因，對他們來講程式已經寫好、不願意變動，類似這樣的問題。

所以這個不是政治問題嘛，對不對？

因為理論上你們domain name都是emic.gov.tw結尾，所以他們並沒有任何依法不能存資料的這種狀況。

這還是要cache，不然的話，你們的loading是只會多，不會少的。

我們報告的地方，後端我們有些自己做了cache，因為怕我們的系統給他們拖累了，所以部分的東西有些cache……

……對，因為你剛剛測的這個是寫入端的八千人或者多少人。

但是隨著臺灣上網人口增加，讀取端只會多、不會少，那個不是你們可以做的事情，所以你們也同意說，理論上不應該是你們來cache，應該是讀取的那一端要來cache才對。

我們有這樣建議過。

第二個問題：你們被讀取的這一些資料，既然我網頁上都看得到，其實並沒有任何道理不能是開放資料，對不對？當然不會有個資、營業秘密及隱私的問題。

所以有一個可能性是，你們針對你們所提供的每一個資料，在你們建議cache的頻段，好比像每分鐘或者是每二十分鐘，你們產生出一筆Open Data，就像剛剛災情通報的Open Data一樣，放到災情平台，請EOC去跟開放資料平台抓，就會自動cache住，你知道我的意思嗎？

瞭解。

那這樣的架構有人提出來過嗎？

跟主席報告一下，像有些路徑，其實我們也是從氣象局那裡來的，其實理論上再去要就好了。

所以你們完全沒有加任何東西？

因為氣象局先提供的那個環保署CDX，我們再從CDX，其實是第二手、第三手，其實源頭一定是……

所以縣市政府你剛剛講的那一些登報系統，CDX也會有嗎？還是那個就不會了。

那個就不會了。

對，所以你們也有第一手的災情資料。

裡面EMIC系統，產生的大概是災情的部分，也就是通報表裡面的一些相關數字，那個是來源端。

其他看到像發布的警報資訊或者是淹水，那個源頭都是給機關負責的。

總之，後者沒有必要從你們這邊拿。

也不是沒有必要，因為我們不是第一手，我們也不是主管這個資料，如果資料有問題的時候，來找我們，我們也很困擾，因為我們不是……

同意啊！同意啊！可是你這邊是第一手的，產生開放資料，應該不成問題嘛？

是，是。

所以我覺得需要盤點的是，有哪一些是EOC有跟你們拿，而你們目前在內部開放資料集裡面還沒有放的資料，那一些資料都轉成開放資料的話，理論上你們可以0 Hit，就根本不會動到你們的後端。

是。

理論上成立嗎？

對。

OK，好，這個是第一個問題，這個是讀取端。

寫入端有另外一個 NDA.emic.gov.tw/dim，它是使用者可以自己登打，所以它只有三個，就是苗栗、嘉義及桃園？

剛剛看到的是民眾參與NDA的網站，那個是提供給民眾來作災情通報的，這個是由縣市決定要不要開，目前是只有剩三個縣市開，他也可以決定關掉，所以可能下一年就發現有一個縣市不見，它關掉了，服務要不要開是縣市決定的。

對，我理解，所以意思是這三個縣市目前……

……有開。現在你看到的三個，就是三個縣市。

但是這個是寫入端，就是它會寫進你們的DB？

對。

所以我們還是有一個Web寫入，它只是不在剛剛的那一個網頁上，在另外一個？

對。

這一個寫入的Web Service有spec嗎？也是一個word檔？

因為這個是我們自己做的，我們其中一個子系統。

所以這個東西就是你們的子系統自己畫出來的？

是，是。

可是它不是ZK啊！

對，它不是ZK。

所以就是專門為了民眾寫的。

對，為了民眾。

做了一個非ZK形式的。

對。

總之你們做了基本的登打系統，這個登打系統因為是系統的一部分，所以我們如果要改成，好比像一個API寫入，它是完全在你們控制裡的？

對。

就是我們完全要把HTML網頁寫成API Form，那種最樸素機器寫入用的，理論上你們不用問任何人？

對。

OK，好，那這是第二個問題，所以寫入分別是這樣。

最後一個是整筆匯出入，目前你們自己在這邊登入剛剛那些災害，它有點像整筆匯出，從上次關掉到這一次還沒關掉的區間，就是剛剛Open Data的那個部分。

目前是從事件開設最早的那一個到現在。

OK。所以其實這一個東西平常會造成你們的資料壓力嗎？還是還好，你提到舊的這一些人跟你接？

目前是還好。

因為用的人沒有那麼多。

對，他們傳的頻率也沒那麼高。

OK。所以就是說，整筆匯出的這一個部分，目前不造成你們的壓力？

對。

整筆匯入的部分呢？也就是機器對機器的部分？

機器對機器，那個是不定時的，他們有觸發這個……

……多的時候很多。

對，當然颱風期間就很多，像最近這一段一定是沒什麼。

對，但是我意思是說在寫入滿載的時候，你剛剛測的時候是人進去登打的，那機器呢？

機器部分沒有針對這個部分注意。

OK，因為以前壓力沒有大到這個地步？

是。因為量也沒有大到……剛剛兩萬多筆裡面，也許不到十分之一……

……喔！所以只有不到兩千筆是機器對機器？

對，大部分還是從……

大部分都是人的登打？

是。

然後裡面相當少部分是剛剛網友自己登打，這個也是有嘛？

那個幾乎沒有。

幾乎沒有人在用這個界面？

幾乎沒有。

我剛看起來，它還可以上傳MP4（笑）。

去年幾個颱風，透過這一個NDA進來的，我的印象中幾乎沒有。

OK，所以不太有人真的用手機拍了一部電影然後上傳？

因為它有限制檔案大小，所以也沒辦法拍一部電影。

30Mb，如果壓縮率高也可以傳微電影了（笑）。

不過我要講的是說，在批次寫入你們系統跟匯出你們系統，兩個你們都不覺得是壓力的來源，就是以目前的用量看起來都還好，然後這兩個東西如果要做成更結構化的方式，都是你們自己開發就可以了？

對，如果是我們的。

瞭解，謝謝，我問完了，不曉得有沒有別人想要討論什麼？我們還有一個簡報對不對？我們先進入下一個簡報。

主席、各位長官大家好，接下來就是由中華電信來報告一下我們基礎服務平台，也是整個雲端基礎建設的一些建置部分及架構。

（簡報第2頁）我們大概分成四個部分：第一個是跟雲端相關的整體服務規劃及建置；第二個是針對Cloud BOSS自動擴展，所謂的「自動擴展」是有需要的時候，可以依照需求直接產生更多的VM來作一些流量分流，我們有針對這個部分來介紹；第三個部分是HGR服務介紹，介紹一下未來可能租用雲端的服務方式，所謂的「HGR」是「HiCloud Government Region」，HiCloud的部分有牽一區特別專屬專用為政府而建置的；第四個是對自建或者用租用的雲端方式來做一些比較表，請各位長官提供一些意見。

（簡報第4頁）整體服務規劃的部分，第一個是我們當初建置這一朵雲的目標是易用、高品質、彈性擴充，因此我們建置的地層是以HiCloud為一個模範的範本來進行經驗的複製，所以不管是在軟體的容易使用上，或者是在硬體的採購上，都是用一些比較大廠知名品牌，有一些雲端經驗方式來建置，為消防署建立一些底層的服務，讓支撐的系統能夠順利運行。

（簡報第5頁）我們建置的地方是在「東七機房」，也就是在松德路，這一個機房是經過ISO 27001、ISO 20000-1及其他環境認證部分。建置在安全的機房之後，消防署的人員就可以遠端使用雲端服務連進來，其他一些人員也可以藉由網路的方式連進來。

（簡報第6頁）這張是我們整體網路規劃的架構，規劃方面第一個是高可用度、安全，所以我們可以看到幾乎是兩兩備援的方式來建置一套系統，頻寬是大頻寬，遠端有一個異地文心，走的是縱深防禦的架構，我們等一下也會對資安有些介紹。

（簡報第7頁）這個是我們的SLA，所以可以看到在服務可用度的部分幾乎都是1＋1，不管是在OS層、在底層或者是應用層都是做一些高可用度的規劃架構，讓不會因為單點失效而產生系統的困擾，還有一些RTO、RPO的規範。資訊安全的部分有做一個COC的監控管理，一旦有一些緊急事件，會做一些email或者是簡訊的告警。我們還有做一些門禁管制、人員管理及專案管理，這邊提供給各位長官參考。

（簡報第8頁）服務水準協議，我們都是採用高可用度的網路設計架構，網路的部分是採用1＋1，在Virtual Port的部分也做一些網路的串接，所採用的Router或Switch都是國際知名大廠。

第二層是虛擬機（VM）的部分，VM為了保護有高可用度跟SRM，所以不管是在單一虛擬機器的故障或者是卡板上的故障，又或者是遠端發生一些問題的時候，要移植到遠端做立即啟用的時候，在虛擬層的部分也有做一些保護。

第三層是SLB，在單台或者是單點故障的時候，可以利用這樣的特性來偵測是不是發生故障，而把流量導到另外備援的點或面去。

第四個是有做異地的備援跟設計。

（簡報第9頁）在整體資訊安全的部分，我們以ISO 27001及20000管理的架構，會成立一個SOC的中心去做蒐集，所以可以蒐集各項設備的log，會做整個的判斷，如果有需要的時候，可以發布訊息，然後告警使用的機器。

（簡報第10頁）建置的部分我們是用所謂的縱深防禦架構，也就是多層次式的，第一層建立一個IPS，然後有一些基礎的D6S功能，所以可以阻擋一些IP等惡意部分，我們可以在第一層的部分先阻擋掉。

第二層是在Firewall跟SLB的部分，所以這層也可以是不友善的IP來源或者是特定的區域，我們可以用IP層的方式來對他們管理。

最後的部分是我們把這一些資料收到SOC中心，然後做整體的整合判斷，看看是不是有一些攻擊的趨勢，或者是白人有一些特定的方向，所以可以根據這邊來做一些判斷。

（簡報第11頁）我們有建主機房跟異地備援機房，所以是兩座儲存設備，可以作為發生災難時確保業務還是能持續運作。我們中間會做差異的資料備份，每日會去除重複的快照備份，以節省儲存空間。

對不起，打斷一下。「主機房」的這兩個意思是類似AA的狀態嗎？

其實主機房應該是一整座大的，然後他作RAID，應該說這應該只是示意圖。

他們的意思是在做RAID？

對。

那這樣的話有測過異地嗎？

有，每一年都會做一個異地備援的演練。

就是如果主機房被炸掉了會發生什麼事？

我們是沒有模擬被炸掉（笑），就重大災害啦！然後會在特定的時間搬到異地機房去。

是人工改類似DNS的做法嗎？

對，有些部分還是要手動，DNS應該是手動的一部分。

所以一次從這邊知道被……我們不要說炸掉，被斷電（笑），到這邊recover大概要多久？

三十分鐘。

滿長的，裡面有多少時間是手動的？

其實SI按下一個按鈕之後就自動開始切換，手動的部分就是要去修改負載平衡的部分，他也知道，可能是有疑慮，所以我們現在是用純手工切換，就是外部的DNS這樣。

所以意思是手動的部分可能一分鐘不到？

對，剩下來的就是……因為那邊的VM是在關閉的狀態，要把它叫起來。

就要二十五分鐘？

對，因為是有分階段性，本來要先開第一批再開第二批……

開機就要二十分鐘？等於整套系統？

對，有分階層式的開機，可能要等這個階段開完之後再開下一個階段，大部分花在開機的時間比較久，沒有錯。

我是不知道災害後三十分鐘會怎麼樣，但是當時的spec是說這樣可以接受？

對。

當時RTO是訂在三十分鐘。

然後開機就要開二十幾分鐘？

開機會考量到ABCD應用系統寫了某一個順序，某一些人起來之後……

……可是這是全自動的，不是嗎？就是說你會起來知道它active……

對，它會去偵測，然後再開。

然後你們沒有所謂sleep to disk或這一類的東西？就是snapshot是一個running state，而不是一個cold boot，你知道我的意思？

對，不是。

通常我們的做法是資料備份之後，把它開起來，然後snapshot包含memory的狀態，然後把它freeze起來，就跟我們電腦沒電的時候一樣，然後醒來的時候你等於是memory多少就讀多少，然後就開機了，這樣不應該超過一分鐘才對。

就是在SI另外一端是屬於完全關機的狀態。

對，可是當時這樣設計有特殊原因，還是就是因為三十分鐘可以交卷就這樣子？

SI這個系統在這一個狀態copy去另外邊，另外一邊就是屬於沒有在開VM，設計就是這樣子。

瞭解，謝謝。請繼續。

（簡報第12頁）那資料中心就是我們東七機房，東七機房是一個綠能中心的規劃，所以有建置在高密度的一些機房跟冷熱的通道分離。

（簡報第13頁）第二個部分是介紹Cloud BOSS。

（簡報第14頁至第15頁）在自動擴展的部分，主要是要分好幾項，有一些要注意的事項是虛擬主機是關機的狀態，我們同仁有做一些實際上的演練跟操演來完成這樣的簡報，所以在布署測試這邊有一個非上線的服務主機，我們要製作一個Template，然後申請Auto Scaling，然後最後會跟SLB產生一個串聯。

（簡報第16頁）這一次最小虛擬主機是一台，我們最大可以擴充到五台，所以在最不忙的時候是一台，在最忙的上線是五台。CPU如果低於百分之三十，就會自動VM縮掉，如果高於百分之七十就持續架起來。偵測的gap是五分鐘。

（簡報第17頁）這個是這五台機器。

（簡報第18頁）最小設定是一台，所以目前可以看到的是一台的狀況。

（簡報第19頁）如果CPU達到一百的時候，我們可以看到會自動開機。

（簡報第20頁）因為前三台CPU的壓測軟體，即第四台還沒有開的狀況下，除起來是百分之七十五，還是高於百分之七十的，所以還會再開一台，此時開了五台虛擬機，但只有三台虛擬機使用率百分之百，它算一個CPU的平均值來判斷要不要再開。

可是你不是說我們這幾層裡面也許開機就要超過五分鐘？還是事實上是沒有？

政委的意思是實際的狀況沒有？

我們現在是在說AP層CPU高，你說AP層就要多開，是不是？是每一層分別Cluster？

對，沒錯，分布圖來看。

但是當它一開就會先算CPU使用量，好比AP還沒有開起來，因為我程式還在跑，但是我的電腦已經開起來了，所以這個時候會有一陣子CPU會……

喔！它有一個持續期間。

瞭解，如果它正在開AP，那幾分鐘不會算？

對，比如說五分鐘持續到一百的時候，我們就會開到一百。

瞭解，瞭解。所以它只要開這整個service的這整個過程，不要一直CPU 100%，就不會有錯誤判斷的情況。

是。

請繼續。

（簡報第21頁）這次是以CPU當作一個判斷的基準，所以計算的方式是CPU使用率的加總，我們可以來判斷未來是不是要做Auto Scaling，其實不管在高或低，都是類似這樣的算法，要建議的是，像剛剛講的是，在AP層或者是DB層可能要確認一下，為了的劇本是不是能夠適用，其實是我們更需要考量的。

（簡報第23頁）這個我們就不多作贅述。

（簡報第24頁）這個是可以自助申裝的功能，主要開發CloudBoss的系統有這樣的功能可以幫你做整合的判斷，然後做一些開機的動作。

（簡報第25頁）第三個大項是我們介紹HGR的服務，就是未來租用一些雲端服務的介紹。

（簡報第27頁）「HGR」是「HiCloud Government Region」 ，提供一個私有虛擬的VPC及上網服務，所以是一個CPPC的架構，並不是我們一般看到功能上的架構。

（簡報第28頁）提供這一些功能，包含一些基礎功能，像也有防火牆的服務，CPPC提供每一個用戶的專屬虛擬防火牆，所以可以自成一個虛擬的私有網路，也提供一個負載平衡及自動擴展，當然這一些是軟體式的。

（簡報第29頁至第30頁）當然申請情境其實可以用自助的服務管理來申裝，所以機關人員如果有申請帳號的話，就可以自己上來告訴系統說要申請哪一些需求。申請完之後，幫他申裝一個VM之後，就可以透過一些比較private的方式來作一些所謂的建置，不管是AP或者DB。

（簡報第31頁）如果建立好之後，使用者就可以透過這個上網，這個是簡單的情境。

（簡報第32頁）架構是各個政府單位的管理者，其實都可以租用這樣的服務，透過我們的自助服務管理系統。我們不管提供了虛擬的防火牆、虛擬負載平衡、虛擬主機，都可以透過一個自助的申請，申請到他所需要的，大部分都是以by小時來計費。

底層的部分就是我們所用整個大資源，但是就個別用戶來說，是一個虛擬的小私雲。

（簡報第33頁）這個是簡單的計價提供給各位參考。

這個部分是什麼時候開始？因為我們目前是在用國發會框的那個，那個是他們自己的，等於是用你們的IDC，但是是一塊固定的。因為我想要開一個Cluster，他說CPU快要用光，所以只能用2CPU，不能用4CPU比較好，所以事實上快用光的？

是。國發會那一朵是屬於自建雲，這邊比較屬於租用的部分，是by 小時來計費。其實目前已經可以提供適用了，所以如果政委有興趣的話……

……已經可以用了？

可以試用了，我們還沒有提供正式租用上線的服務，因為它畢竟跟HiCloud是同一個系統，只是給政府機關使用。

瞭解，因為我們自己在架好比像Sandstorm Cluster或者是未來的Kubernetes Cluster，如果目前用國發會iaas的話，它目前已經快沒有了，不能給我們測了，我們很多劇本沒有辦法測。

所以如果可以的話，我們先在這上面測測看，我們比較知道你們那一些parameter比起GCE或者是AWS大概長什麼樣子。

是。

我想我們會後就馬上來聯絡，主要在做這個的，反正都來了，就PDIS三樓的朋友們。

所以如果未來要測這種比較一下子起十台或者是五十台的劇本，目前這個已經都可以做了？

理論上。

當然是在測爛掉不會怪你們的情況下（笑）。

應該說還是有整個的開機時間，所以五十台這麼大量的開機數在這麼同一瞬間開……

……就很難講。

但是如果政委願意，我們是願意一起合作，因為我們沒有做過這麼大量的壓力測試。

那這樣很好啊！因為在這樣的前提裡面，就變成是等於HiCloud是你們已經有了，只是這一個Virtual network是新的。

其實這一個是為了政府機關，它切一塊出來。

那像切出來的，有異地備援嗎？

為什麼還沒有開始對外正式上線，其實我們異地備援大概年中之後才會建置完成，所以這一塊希望等那一塊有了之後再正式發。

喔！不然我看你其他功能都有了。

是。

OK，好啊！所以那到年中就封測一下。

如果最近要測可以先測，因為elastic這些功能是政委要的，隨時可以測。

然後費用是比照雲端的共同採構，這邊的算法跟工業局的算法，不只是現在一樣，未來也都一樣，是掛鉤的。

好啊！那我們就來測它，請繼續。

（簡報第35頁）最後講到雲端方案比較，剛剛講到像署方或者NDC屬於代維代建，也就是中華幫機關建一朵獨立的私雲。第二個是我們有一些出租的服務，像HGR跟HiCloud，其實這兩個看起來都會是一致的。

其實在提供的服務深，兩個是沒有差別的，但是在一些客製化的服務上，好比我們要做更充分的使用，或者是我們有一些獨特的需求，是有一些客製化的，像快照服務及備份服務，在備援的部分，這邊是文心機房，（HGR）我剛剛提到目前還在計畫中。

（簡報第36頁）在經費的部分，代建代維是一次的支出，HGR是用租用的方式。其實如果硬體撐得夠久，比如十年才換一次，相對反而會便宜的，但是用HGR的好處是，租房子可以一直住在一個新的，也就是資源足夠的使用VM上，所以這邊是每一年需要編一些經費，但是確保使用支援上是完整獨立且符合需求的。

不會撞天花板，這個很重要（笑）。

沒錯，是沒有天花板的。

客製化的部分，有一些私雲是我們可以配合它的政策來作所有的管理，不管是27000或者是其他的政策，其他的就要按照HGR跟HiCloud的方式往下走。

我們就拿消防雲來講好了，這個經費本來已經花下去了？

是。

所以意思就是說，即使我們現在到這裡，也不能折舊賣回（笑）？

（笑）應該是，要問那一邊的，應該是不行。

但是因為折舊年限在今年也差不多是第五年了，所以可以考量未來是不是採用租用的方式。

現在大概用一半了？

百分之七十、八十。

喔！真的？

對，因為是以五年為評估基準的話，已經快要用到了，只是通常過了五年之後還可以再付一些保固費用，可以繼續使用，相對便宜會是在這一段，就是過保固期。

但是當我們已知，又要擴充它的量，又撞到天花板的時候，我們不妨把一些elastic的部分往這邊建置，那這樣這兩個中間等於是只能透過公共的網路？

網路或者是VPN。

也可以VPN？

可以走GSN VPN。

都是還在GSN VPN裡面？

其實兩邊各串一條GSN VPN，到中間那一個大網路下就通了，因為我們會給你一個特別的網路編號。

這個跟網段規劃是沒有關聯的，就是說事實上我這邊出來，我等於Join這邊的VPN。

從這一台機器的角度來看，這邊有很多台機器，這邊有動態的一至三台都無所謂？

相對還是要考量，應該是說兩邊串起來之後，兩邊的網段不能重複，因為網段是自己的，所以IPv4幾乎是不會撞到的。

幾乎是不可能撞到的？

對，幾乎啦！但是還是兩邊測一下。

當然要測一下。然後latency應該也都還好，因為infrastructure都你們？

對，其實應該真的……

……等於intranet。

而且就台北、台中，甚至高雄也就這麼大。

他的route也不可能經過任何你們不認識的人。

是，而且propagation delay也不會太大。

對啊！臺灣就這麼大、光速就這麼快（笑）。

請繼續。

像剛講到負載平衡設備，像署這邊是實體的設備，不可否認實體的這個還是效能上好的，這建議在中小型的一些分配上，虛擬化是可以做到的，雖然是一個設備，未來當然HGR如果對大客戶，比如租用了幾百台，要做虛實整合也是有機會的，但並不是現在說要建一個什麼就建什麼。

知道。

防火牆也是一樣，虛擬化跟實體設備。因為現在有ASIC晶片來講，這個虛擬化用CPU還是較弱的。

那當然。

是的。

資源擴充性，也就是剛剛講天花板的部分，就是要符合ISO 20000的精神，每一年都做一個資源容量的評估，來評估明年、後年的用量，HGR就是有需要的時候來做，技術門檻是需要一組人來維護，相對這成本是高的，這就是一組團隊，反正就是維護同一個，所以相對付的租金是低廉的。

所以等於是年中做完，然後明年開始賣？

其實單台已經可以賣，但是我們不敢大聲張揚，是因為異地備援還沒有，所以我們還是想要做一個完整的。

我們測的時候沒有SLA的，這個我理解（笑）。

費用應該可以抵免……我們再談好了。

沒有SLA的話，可以打折嗎（笑）？

其實CPU費用都是on demand，但是軟體的license會有困難。

我們就是用Oracle，還有用什麼？

這個部分就會有問題。