主席、各位長官大家好，接下來就是由中華電信來報告一下我們基礎服務平台，也是整個雲端基礎建設的一些建置部分及架構。
（簡報第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頁）我們有建主機房跟異地備援機房，所以是兩座儲存設備，可以作為發生災難時確保業務還是能持續運作。我們中間會做差異的資料備份，每日會去除重複的快照備份，以節省儲存空間。
其實主機房應該是一整座大的，然後他作RAID，應該說這應該只是示意圖。
對。
有，每一年都會做一個異地備援的演練。
我們是沒有模擬被炸掉（笑），就重大災害啦！然後會在特定的時間搬到異地機房去。
對，有些部分還是要手動，DNS應該是手動的一部分。
三十分鐘。
當時RTO是訂在三十分鐘。
開機會考量到ABCD應用系統寫了某一個順序，某一些人起來之後……
（簡報第12頁）那資料中心就是我們東七機房，東七機房是一個綠能中心的規劃，所以有建置在高密度的一些機房跟冷熱的通道分離。
（簡報第13頁）第二個部分是介紹Cloud BOSS。
（簡報第14頁至第15頁）在自動擴展的部分，主要是要分好幾項，有一些要注意的事項是虛擬主機是關機的狀態，我們同仁有做一些實際上的演練跟操演來完成這樣的簡報，所以在布署測試這邊有一個非上線的服務主機，我們要製作一個Template，然後申請Auto Scaling，然後最後會跟SLB產生一個串聯。
（簡報第16頁）這一次最小虛擬主機是一台，我們最大可以擴充到五台，所以在最不忙的時候是一台，在最忙的上線是五台。CPU如果低於百分之三十，就會自動VM縮掉，如果高於百分之七十就持續架起來。偵測的gap是五分鐘。
（簡報第17頁）這個是這五台機器。
（簡報第18頁）最小設定是一台，所以目前可以看到的是一台的狀況。
（簡報第19頁）如果CPU達到一百的時候，我們可以看到會自動開機。
（簡報第20頁）因為前三台CPU的壓測軟體，即第四台還沒有開的狀況下，除起來是百分之七十五，還是高於百分之七十的，所以還會再開一台，此時開了五台虛擬機，但只有三台虛擬機使用率百分之百，它算一個CPU的平均值來判斷要不要再開。
政委的意思是實際的狀況沒有？
（簡報第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頁）這個是簡單的計價提供給各位參考。
是。國發會那一朵是屬於自建雲，這邊比較屬於租用的部分，是by 小時來計費。其實目前已經可以提供適用了，所以如果政委有興趣的話……
可以試用了，我們還沒有提供正式租用上線的服務，因為它畢竟跟HiCloud是同一個系統，只是給政府機關使用。
是。
理論上。
應該說還是有整個的開機時間，所以五十台這麼大量的開機數在這麼同一瞬間開……
但是如果政委願意，我們是願意一起合作，因為我們沒有做過這麼大量的壓力測試。
其實這一個是為了政府機關，它切一塊出來。
