準行政院長林全公布新一波內閣名單，宣布由中山大學教授楊弘敦出任科技部長， 楊弘敦現任國立中山大學校長、中研院物理所合聘研究員，曾任國科會副主委。

楊弘敦出生高雄美濃，取得美國愛荷華州立大學取得物理博士後，回台至中山大學任教，擔任中山大學理學院院長期間，到Wayne State University物理系擔任一年訪問教授。之後擔任國科會處長，接管自然處，後升任副主委，自2008年起為中山大學校長。

楊弘敦專長是超導物理、磁物理、材料科學與奈米材料，林全表示，將借用楊弘敦經歷，更緊密結合產業界與學術界，並攜手經濟部，讓研究成果發揮更大的商業化價值。

Google在推出低功耗藍牙Beacon開放格式Eddystone的同時，為了確保裝置和Beacon間通訊的隱私和安全性，也發展了短暫識別碼（Ephemeral Identifiers，EID）技術，且在4月14日公開EID的技術規格，並於GitHub上開放開發者使用。

Google在2015年7月時，推出Eddystone開放格式，可以同時執行在Android、iOS、Chrome等支援低功耗藍牙Beacon的平臺上，而Beacon會廣播公開的單向訊號，如Eddystone的唯一識別碼（UID）或URL，讓附近支援Bluetooth Smart規格的裝置可以辨識Beacon的位置。而EID則是Eddystone開放格式中的Beacon加密框架，提供開發者可以控制使用Beacon訊號的人，也就是只有授權的用戶端可以解讀Beacon訊號。

另外，EID的8位元AES金鑰識別碼也會週期性變換，且開發者可以透過Beacon的軟體中的計時器，來設定AES金鑰識別碼的變換週期，設定範圍在1秒到9小時之間。當開發者完成Beacon設定後，解析服務如Proximity Beacon API則會產生密鑰，同時，計時器也會與服務同步，只有授權的用戶可以存取這把密鑰。

而為了避免Beacon遭受攻擊，如位置欺騙、追蹤等，EID也有防護措施，例如，單一Beacon識別碼間的循環週期變化略有不同，也就是攻擊者無法使用一致的週期來辨識特定的Beacon。另外，EID還具備其他的安全性功能，如接近察覺（Proximity Awareness）、裝置認證，以及傳輸封包的資料加密等。

除此之外，Google也更新了The Eddystone-TLM加密架構，支援Beacon的電池電量也能共享金鑰，讓攻擊者無法使用電池電量作為Beacon的辨識特徵。還有，Google也新增了Eddystone的通用配置協定GATT服務，允許支援GATT服務的工具來提供Eddystone Beacon服務。Google表示，這消除了Beacon開發者的限制，並激勵Beacon產品軟硬體的開放生態系統發展。

Xeon E5 v4來了！擔當2路伺服器運算中樞的英特爾Xeon E5-2600處理器平臺，推出全新v4系列，單顆CPU最高可提供22核心，效能比前代產品增長44％，同時也強化儲存、安全與虛擬化應用效率，更特別的是引進全新的資源監控機制，於資源的調度指揮效率可望因此大增。

針對資料中心的2路伺服器應用，英特爾今天（3月31日）正式推出v4系列的新一代Xeon E5-2600處理器（代號為Broadwell-EP），距離先前的v3系列（代號為Haswell-EP）首度發布，v4系列花了超過1年半的，比起前幾個系列之間的間隔，都要來得長久。

這次Xeon E5-2600 v4的推出，各種應用層面的效能提升，自然是重頭戲。跟v3相比，運算速度超越的幅度最高可達44％；在虛擬化應用環境當中，因為支援直接送入中斷請求（Posted Interrupts）的機制，延遲可降低到8倍之多；在網路互連的環境下，v4處理器搭配英特爾Omni-Path Architecture的網路Fabric架構，能夠比v3處理器平臺傳輸的訊息量高出24％。

對於儲存應用上，Xeon E5-2600 v4繼續強化了ISA-L程式庫（Intelligent Storage Acceleration Library）的性能。跟開始支援ISA-L的Xeon E5-2600 v3相比，效能提升了一些，但相較於不支援ISA-L的Xeon E5-2600 v2或是停用ISA-L的v4環境下，增長幅度更為明顯。例如針對密碼雜湊運算處理工作，像是SHA-256、SHA-512、MD5，啟用ISA-L的v4最高可提供8.2倍效能；對於資料保護的作業，像是RAID-5、RAID-6、Erasure Code，啟用ISA-L的v4效能是3.3倍。

擁有88個執行緒的2路伺服器

在英特爾最新發表的Xeon處理器當中，E5-2699 v4這款產品最高可提供22顆實體核心、44個執行緒，因此，若在2路伺服器搭配兩顆E5-2699 v4，理論上可獲得44顆核心、88個執行緒。而我們在英特爾舉辦的新品發表工作坊活動期間，看到他們在現場特別設置了一臺測試設備，裡面安裝Windows Server 2012 R2作業系統，我們不只親眼目睹搭配這顆處理器的2路伺服器，並且從工作管理員看到系統的確能支援88個執行緒。

採用14奈米製程，內建運算核心衝破20大關

這批處理器都導入Broadwell微架構，並使用了更為先進的14奈米製程（v3系列是22奈米），現有Xeon E5-2600 v3處理器所搭配的LGA 2011-v3插槽（或稱為Socket R3），新的v4系列處理器一樣相容，因此現有針對Xeon E5-2600 v3系列處理器所設計的伺服器，均能搭配。

除了設計製程，v4系列處理器在硬體規格與過去產品最為顯著的差異是，頂級的Xeon E5-2699 v4內含的實體核心，最大可達22顆，L3記憶體容量高達55 MB，若啟用超執行緒（Hyper-Threading）技術之後，可提供44個執行緒；若以搭配2顆2699 v4的伺服器組態而言，單臺設備就擁有44核88緒。

而在前代Xeon E5-2600 v3系列處理器當中，頂級的2699 v3最大可提供18顆實體核心、36個執行緒，L3記憶體容量為45 MB。新舊款Xeon E5-2699處理器的基礎頻率分別為2.2 GHz與2.3 GHz，有些出入，但熱設計功耗都是145瓦。

2路伺服器配1.5 TB記憶體不是夢！英特爾鬆手，Xeon E5正式支援更大量的記憶體

就搭配的系統記憶體規格而言，Xeon E5- 2600 v3和v4都是DDR4，但在支援的最高存取速度規格又更上一層樓，到達2400 MT/s（v3支援到2133 MT/s）。而對於DDR4記憶體規格的支援，Xeon E5- 2600 v3已經開始支援4通道的存取方式，而對於每條通道，可支援3支RDIMM或LRDIMM規格記憶體的配置，到了v4，又額外支援了3DS（three-dimensional stacking）LRDIMM規格的記憶體──它是近年來相當受到矚目的記憶體，相較於傳統的封裝堆疊方式，3DS LRDIMM不只提供更大的容量，能源使用效率與執行效能也較佳。

在記憶體的穩定度與可靠度確保機制上，Xeon E5- 2600 v3支援錯誤修正檢查（ECC）、巡查抹除（Patrol Scrubbing）、需求抹除（Demand Scrubbing），以及冗餘（Sparing）、鏡射（Mirroring）、連續同步模式（Lockstep Mode）、針對x4/x8記憶體的單一裝置資料修正（SDDC）。到了v4，英特爾增加針對DDR4記憶體寫入的循環冗餘校驗（CRC）容錯支援。

此外，對於新推出的v4系列處理器，英特爾終於正式放寬了2路伺服器搭配的記憶體容量，最大可達1.5TB。因為，若你使用的伺服器是v3以前的Xeon E5-2600系列處理器平臺，最大記憶體僅支援到768 GB。

有趣的是，許多廠商在先前推出的Xeon E5伺服器當中，有不少機型的記憶體規格上，已經標示最大容量可達到1TB或1.5TB，但是，相對地，在英特爾官方公布的規格裡面，始終沒有正式認可這件事。

不論過去如何，2路伺服器能搭配超過1TB的記憶體容量，終究成為定局。在更早之前，用戶必須購買支援Xeon E7系列處理器的伺服器，才能獲得如此巨大的記憶體延展性，而這類設備通常搭配的是4路或8路的處理器組態。

但現在居然在Xeon E5-2600系列處理器平臺上，利用較為平價的2路伺服器，就能支援TB等級的記憶體，對於想要大規模導入記憶體內運算（In-Memory Computing）應用的企業來說，將是一大福音，因為當企業能以價格相對低廉的2路伺服器，來支配超大量的記憶體資源使用，將可省下相當多費用。

針對虛擬化，新增直接置入中斷請求與記憶體分頁修改記錄

在Xeon處理器架構與功能推陳出新的過程中，強化伺服器虛擬化應用效能，一直是歷代伺服器平臺發展的重頭戲，最知名的研發成果，就是VT（Virtualization Technology）系列指令集。

到了Haswell微架構之後，該公司又加入了VMCS（Virtual Machine Control Shadowing），因此採用該架構的Xeon E5-2600 v3處理器平臺，對於巢狀虛擬化應用（nested virtualization，也就是在虛擬化環境當中，再建立一層虛擬化環境）更加得心應手。

因為，這麼一來，能將最外層／最底層（根）Hypervisor的權限控管，延伸到所模擬的裡層（Guest）Hypervisor上──在這裡所執行的應用程式，將會耗用最少的效能，不會嚴重影響到整體伺服器與其他虛擬機器的運作。該功能有助於雲端服務業者使用，因為IaaS租戶將因此能對本身所用的Hypervisor環境，獲得更大的主控權，而不需要業者介入協助。

而在下一代的Broadwell微架構當中，英特爾又加入新的虛擬化應用特色，例如：直接置入中斷請求（Posted Interrupts）、記憶體分頁修改記錄（Page Modification Logging，PML），以及虛擬機器進出延遲減緩（VM Enter/Exit latency Reduction）。這些新的加速機制，都在採用該架構的Xeon E5-2600 v4系列處理器開始提供。

直接置入中斷請求

以Posted Interrupts來說，是在Hypervisor存取虛擬機器時，若進入VM-exit狀態時，不需要每次都提出中斷處理請求，系統可將中斷處理視為已經寫入到記憶體上，只在必要時，才會對虛擬機器送出中斷處理。

不論是系統要指派裝置，或是在執行遷移虛擬處理器的作業，都可以更有效率地導引中斷請求。這種新的作法，還可以搭配Xeon E5-2600 v2之後，所新增的APIC虛擬化（Advanced Programmable Interrupt Controller Virtualization，APICv），改良虛擬環境下的中斷處理效能。

免除了VM-exit相關的中斷處理之後，成效有多大？根據英特爾本身的測試，對伺服器裡面執行的虛擬機器而言，平均的網路存取延遲可縮短8倍以上，而網路吞吐量最高可提升41％。

記憶體分頁修改記錄

Xeon E5-2600 v4與虛擬化應用相關的新特色當中，PML是針對兩臺虛擬化主機之間的自動容錯切換。在兩臺相互備援的伺服器虛擬環境下，處理器將會針對另一臺提供容錯機制的次要虛擬化主機（secondary host），定期進行快速檢查（Rapid Checkpointing），查核主要的虛擬化主機（primary host）的可靠度（Availability），以及網路連結（Link），確認狀態是否異常。一般而言，檢查點的資料將會傳送到備援的主機上，等到檢查點套用後，來自主站點的I/O作業就會停止，不會持續連線、佔用頻寬；一旦主要虛擬化主機發生故障，備援虛擬化主機就能透過這種方式回復、接手相關的工作。

比起純粹基於VM層級的容錯備援機制，現在能運用這種方式，將可減少許多不必要的負擔。就運作原理而言，Page Modification Logging的功能，主要是建立在Haswell架構新增的EPT A/D（Extended Paged Table Accessed/Dirty bits），透過硬體機制，提供記憶體區塊殘留位元資料（Dirty bits）的分頁記錄表，可加速虛擬化軟體執行切換這些工作負載的效率，甚至還可以提升虛擬機器的線上不停機遷移（Live Migration）效率，連帶受惠。

虛擬機器進出延遲減緩

Xeon E5-2600 v4新增的第三個虛擬化特色，則是VM enter/exit Latency Reduction，主要效果是減少VM存取狀態改變時所引發的額外負擔。

這項機制是從Haswell架構就開始發展，當虛擬機器在切換為VM-enter或VM-exit時，延遲大約需要5百個週期，而到了Broadwell架構，可減少至400個週期，因此採用該架構的Xeon E5-2600 v4的VM存取延遲，也跟著降低。

提升多種運算指令集的執行效能，強化安全性處理能力

針對安全性應用的強化，也是這次Xeon E5-2600 v4發布的重點特色。根據英特爾內部進行的測試結果，相較於v3，這一代的Xeon處理器平臺在進行金鑰加密演算法時，每核心效能的提升幅度可達到70％。

這部分的改進，主要是因為英特爾在Broadwell微架構下，新增了ADCX/ADOX的指令集，並且降低ADC、SBB、PCLMULQDQ等指令集的執行延遲度，進而能夠針對現行基於RSA、ECC、SHA等演算法的各種安全通訊初始協定，提供加速處理的效果。

以ADCX和ADOX指令集為例，主要針對的是大型整數運算，可用於公鑰的加密處理，它們是基於ADC指令集而演變出來的作法，差異在於搭配不同的旗標行為（flag behavior）——ADCX運用Carry旗標，而ADOX是運用Overflow旗標，當中也運用了在Mathmatica 這類應用軟體支援的GNU多重精度程式庫（multiprecision library），以及常見的RSA公鑰加密處理技術。

而對於ADC、SBB、PCLMULQDQ的加速處理，Xeon E5-2600 v4改善的部分是針對演算法的延遲性，而且，執行相關運算的程式碼不需重新編寫。此外，處理器執行ADC/SBB指令集時，將能在單一運算週期內完成工作；至於PCLMULQDQ的運算，也將從7個週期減至5個週期。

除了這些與演算法相關的安全性特色，Xeon E5-2600 v4也針對系統執行的架構增加了保護機制，稱為管理者模式的存取防護（Supervisor Mode Access Protection，SMAP），這是一種透過處理器的機制，來保護使用者模式下的記憶體位址空間存取。

英特爾早在Xeon E5-2600 v2時期，就提供了OS Guard（Supervisor Mode Execution Prevention，SMEP）防護技術，而SMAP也是很相似的技術，但防護面向不同。

兩者的差別在於：SMEP預防的目標，主要是透過使用者記憶體分頁來執行管理者模式的行為；而SMAP所要抵擋的，則是特別針對另一種藉由管理者模式，到使用者記憶體分頁來存取資料的可疑行為。

最後，在伺服器虛擬化應用的安全防護上，Xeon E5-2600 v4也特別新增了一個名為#VE（Processor Virtualization exception）的功能。這項技術可強化伺服器平臺偵測潛藏惡意程式的能力，並且以處理器即時判斷的機制，預防零時差的應用程式漏洞攻擊，透過這種不需完全仰賴作業系統層級以上的記憶體深度檢測機制，英特爾希望能降低相關的防護負擔。

虛擬化效能增強是Xeon E5歷代發展重點

在系統的效能強化上，每一代Xeon E5-2600系列處理器都會增添一些針對伺服器虛擬化應用環境的特色，早期是發展與擴充VT系列指令集，到了最近則是聚焦在更細緻的底層資源管理，像是v2新增的APICv，v3加入的VMCS、EPT A/D，而最新推出的v4系列，則增添了Posted Interrupts、Page Modification Logging，以及VM enter/exit Latency Reduction等特色。

Posted Interrupts演進歷程

關於伺服器虛擬化環境的中斷處理作法，可分為3個時期：最早是基於Hypervisor（VMM）的軟體APICv，來進行所有的外部中斷處理，VM-exit也會經過VMM執行的軟體APICv，對於少量的VM-exit切換還可以應付。

接下來，從Xeon E5-2600 v2開始，是能夠搭配處理器內建的硬體式APICv機制，可因應少量的VM-exit切換，但外部中斷處理仍須經由VMM的軟體APICv來遞送。

在Xeon E5-2600 v4所支援的Posted Interrupts下，可透過軟體傳送或直接進行外部中斷處理，並同時搭配上述的處理器硬體APICv的作法，如此將能支援SR-IOV的網路介面應用，以及直接穿透虛擬層的Direct I/O周邊裝置指定。

專攻虛擬化主機備援容錯的PML架構

Xeon E5-2600 v4加入了Page Modification Logging（PML），可針對工作負載的層級，提供系統容錯能力，如此能為虛擬化的企業關鍵應用系統環境，提供高可靠度的保護機制。PML主要運用了Rapid Checkpointing的作法，對於VM層級容錯機制所產生的額外負擔，可望因此降低。

【相關報導請參考「英特爾新伺服器平臺登場」】

因為伺服器虛擬化應用的普及與興盛，資料中心基礎架構對於運算、儲存、網路等IT資源的調度指揮（orchestrate），以及自動產生系統執行環境（Automated Provisioning）的工作變得非常頻繁，連帶產生資源分配不均的管理難題。在英特爾新推出的Xeon E5-2600 v4所新添加的眾多特色當中，就有一項是專門針對這樣的需求而發展出來，那就是資源督導技術Resource Director Technology（RDT），透過它，可協助IT人員能夠進一步掌握與控管伺服器平臺的資源，促使資源調度變得更為敏捷，協助企業IT環境能加速轉型，邁向更為全面、也更自動化的軟體定義IT基礎架構。

RDT目前包含4大技術：在Xeon E5-2600 v3時期推出的快取監控技術（Cache Monitoring Technology，CMT），以及快取配置技術（Cache Allocation Technology），再加上新的記憶體頻寬監控技術（Memory Bandwidth Monitoring，MBM），以及程式碼與資料優先存取技術（Code and Data Prioritization，CDP）。

有了這些資源管理技術，使得作業系統與Hypervisor藉由處理器平臺的協助，能夠管理與監督在伺服器共用的快取與記憶體資源，而且，RDT能掌控的程度更為進階，可透過特定模型暫存器（Model Specific Register，MSR）的控制，深入系統核心（Ring 0）執行。

此外，RDT可以相容於現有英特爾處理器所普遍內建的超執行緒技術（Hyper-Threading Technology），彼此可共同合作。對於經常改變的作業系統與Hypervisor執行狀態，RDT也適用。

整體而言，RDT的應用範圍，可涵蓋處理器快取與系統記憶體頻寬，針對這兩項競爭最激烈的資源，提供動態觀察與觀察能力，能採取被動監督與主動配置的作法──每一支應用程式、作業系統與虛擬機器的資源用量，對處理器而言，將變得更為透明；此外，資源用量也將基於每一支應用程式、作業系統與虛擬機器的層級，予以不同的區分與配置。不過，可惜的是，Xeon E5-2600 v4目前對於處理器快取的管理較為完善，而對於記憶體頻寬只能進行監督，但尚未支援配置。

有了RDT之後，整體而言，伺服器因為虛擬機器、應用程式執行環境的提供所引發的資料移動，能根據對應的優先順序、服務等級來調度指揮資源，而不是任憑搶奪、佔用，同時，還能減少非必要的資料傳輸作業。

對於資料中心的維運來說，若能運用RDT，在高度導入伺服器虛擬化環境下，可以將這些快取與記憶體資源的利用，提升到新的層次，並且適應因為業務持續變動所提出的各種IT環境要求，還能支援需線上遷移到其他資料中心位置的工作負載。

隨著英特爾在3月31日正式推出Xeon E5-2600 v4，該公司也同步宣布有多家企業採用RDT這項技術，像是全世界最大的證券交易所NASDAQ，該公司架構與效能工程首席技術專家Sandeep Rao表示，資料中心運作效率因此提升到先前環境的4.1倍。此外，還有阿里巴巴、中國移動、Facebook、VMware等公司已經開始運用RDT。

RDT就像機場塔臺能進行複雜的IT資源調配

對很多人來說，RDT的角色與作用似乎很抽象，英特爾用機場管制塔臺作為比喻──塔臺（RDT）會結合雷達遙測資料，隨時監督與控管所有飛機（虛擬機器、應用程式、執行緒）起降作業。

 第一步  對於離處理器最近的L3快取，提供監控與配置

首先，是針對處理器L3快取的使用──快取監控技術（CMT），以及快取配置（CAT）技術，它們能協助Xeon E5-2600 v4更聰明地執行相關的工作排程，以及負載平衡的決策。同時，能將伺服器所要提供的服務，透過這種新的分層方式進行管理，可確保高優先執行順序的應用程式，能享有足夠的快取，針對工作負載的執行，促進更靈敏的配置、載平衡、整併作業。

CMT和CAT之所以能運作，主要是系統會先透過資源調度應用軟體（orchestrator），或是根據作業系統、Hypervisor的指派，將伺服器目前所承載的執行緒、程式、虛擬機器，對應為不同的資源監控代號（Resource Monitoring IDs，RMID），以及服務類別（Classes of Service，CLOS）。

在CMT的使用上，Xeon E5-2600 v4處理器平臺可監控的RMID數量，是Xeon E5-2600 v3的2倍──對於每個部分的快取，能監看8個。而對於CAT，Xeon E5-2600 v4目前可支援16個服務類別。

這兩項技術的實際應用效果如何？以CAT為例，在英特爾與雲端分析服務商AppFormix合作下，他們以搭配兩顆Xeon E5-2699 v4處理器的伺服器，來比較CAT使用前後的差異。測試結果顯示：CAT啟用後，網站伺服器在該機制的保護下，效能（吞吐量）可提升27％；若是與其他會搶占資源的工作負載一同執行（每顆處理器執行11支Stream 效能測試程式），在啟用CAT的伺服器下執行的網站伺服器，平均反應速度比起不啟用CAT時，要快上51％，而在惡劣情況下的反應速度，甚至可快到2.22倍，成效相當驚人！

 第二步 監督系統記憶體與L3快取之間的傳輸頻寬

MBM則是針對系統記憶體的存取流量進行管理，同樣基於上述CMT所使用的RMID來進行觀察，系統可藉此發現記憶體頻寬存取的衝突，以及促使執行緒的遷移。

首度採用MBM的處理器是去年推出的Xeon D-1500系列，所針對的伺服器類型主要是單路架構的應用設備，現在則輪到Xeon E5-2600 v4系列開始支援，也表示對應的主流二路伺服器平臺，從此也將受益於這項技術。

MBM的導入，有助於揭露記憶體頻寬的細部用量，面對橫跨不同處理器插槽、核心之間執行的工作負載，例如英特爾的DPDK（Data Plane Development Kit），伺服器能以此方式做到有效平衡，避免這些處理程序爭奪記憶體資源，可增進記憶體資源利用率，進而提高服務等級，達到存取效能最佳化。

英特爾之所以發展這樣的技術，源自於多核心處理器架構雖然擁有階層式快取，能以大規模的資料吞吐能力與延展性，提升應用程式的執行效能，但許多使用者層級的處理程序同時執行的關係，它們經常彼此爭奪快取與記憶體頻寬的資源。此外，處理器快取區分為越來越多階層，也是記憶體存取效率不彰的理由之一，因為L3快取與系統記憶體對於處理器存取而言，都是橫跨所有核心一同共享的資源。

而記憶體存取效率好壞將會衝擊系統整體效能，因此若要達到最佳記憶體存取效能，必須透過持續監控與提高使用效率等方式。

面對上述這些應用需求，英特爾近期所發展出來的MBM技術，已經能夠從快取的不同階層當中，逐一監控頻寬，特別是L3快取。而MBM的基本架構是延伸自英特爾現有的CMT技術，增添了基於CPUID的計數功能（enumeration），以及新的事件代碼，以便從近端與遠端記憶體的控制器擷取記憶體頻寬資訊。

由於CMT能對每個執行緒加上標記，這意味著在執行應用程式、虛擬機器或容器（Container）時，每個執行緒的頻寬能夠被測量到；同時，本身所在與遠端的記憶體控制器頻寬用量，也都能藉由當中所對應的事件代碼觀察到，因此使得具有頻寬感知能力的排程執行，以及針對非一致式記憶體存取（Non-uniform Memory Access，NUMA）的最佳化，都將能夠實現。

RDT以處理器快取QoS為主要號召

Xeon E5-2600 v4處理器平臺新增的功能當中，以RDT（Resource Director Technology）最為獨特，因為有了這項技術，可確保高優先順序的虛擬機器、應用程式或執行緒，都能獲得相對更多的處理器L3快取與系統記憶體，有助於資料中心環境進一步提升伺服器本身的資源利用效率。

 第三步 透過處理器快取配置，控管應用程式與資料存取優先順序

從英特爾發展上述三種技術的歷程，其實可以看到，對於承載越來越多型態應用的伺服器，他們的目標已經越來越很明確，就是針對共用平臺資源的使用，提供更多有效管理機制。

這項大工程的進行，最早應該回溯到處理器的即時排程執行，以及後來陸續新增與擴展的VT系列指令集，面對執行高優先順序的虛擬機器時，實體處理器必須能夠固定與隔離這些工作負載；接著是記憶體的配置，須具有快取的感知能力，並且能夠為高優先順序的虛擬機器，給予專屬的記憶體區域；然後，才是針對硬體周邊裝置資源的專屬配置，例如網路介面、繪圖處理器。

但對於伺服器平臺上所共用的其他資源，像是處理器內建的L3快取與記憶體頻寬，一直並未著墨，而這部分的功能支援，無法透過應用軟體來幫忙，非得由處理器廠商親自操刀才行。

而這些就是英特爾發展平臺共用資源監控技術的主要理由。因此他們先發展CMT、CAT，聚焦在處理器快取資源的管理，並且在Xeon E5-2600 v3開始提供；從Xeon D-1500起，延伸到系統記憶體頻寬的監督，而推出了MBM；在最新推出的Xeon E5-2600 v4，相關技術又更上一層樓──英特爾正式推出了程式碼與資料優先存取技術（CDP）。

這項技術是基於英特爾CAT的延伸，執行緒能夠針對程式碼執行與資料存取，配置個別專屬的L3快取區塊，因此，程式碼與資料在L3快取置放的區域，能透過軟體設定的方式來隔離彼此，並依照不同優先順序加以區分，進而能夠根據工作負載的特性，來調校快取容量的調配

實際上，處理器是透過程式碼，或資料快取的容量位元遮罩（Capacity Bit Mask，CBM）來分配。這些遮罩都是特定模型暫存器（MSR），皆以IA32_L3_QOS_MASK_n的格式來命名，而由於每一個服務類型（CLOS）都會配合1個dcache_cbm快取位元遮罩，以及1個icache_cbm的MSR，所以每個CLOSid代號都會搭配CDP。

CDP在哪些應用場景可以有效發揮？主要是具有大量程式碼執行痕跡的應用程式，或者是針對一些程式碼較敏感、需在快取當中妥善保護的應用程式。

CMT的運作架構

CMT（Cache Monitoring Technology）是英特爾最先推出的伺服器平臺QoS管理機制，能辨識過度使用資源的應用程式，並根據優先順序重新排程執行。若發現佔用快取資源的應用程式，會以每個資源監控代號（RMIDs）的形式來回報。

CAT的運作架構

CAT（Cache Allocation Technology）和CMT同在Xeon E5-2600 v3處理器推出，但並非全系列提供，當中運用切割L3快取的方法，促使應用程式執行時得以分隔，過度使用L3快取的執行緒將受到隔離，以免影響其他程式。

MBM的運作架構

隨著Xeon E5-2600 v4處理器推出的MBM（Memory Bandwidth Monitoring），也利用RMIDs架構來實現記憶體頻寬監控，能基於執行緒、核心或應用程式的角度觀察，對於爭奪共用資源的情況，能提出較佳的解決方法。

可結合英特爾先前發展的資料中心管理機制

除了跟著Xeon E5-2600 v4系列處理器一起推出的RDT資源督導技術，先前英特爾所提出的多種資料中心管理技術，也還是繼續在新款Xeon當中支援，例如Node Manager（NM）、Data Center Manager（DCM），它們也是管理IT基礎架構資源時，所不可或缺的層面。

以NM為例，在Xeon E5-2600 v3時，功能已提升到3.0版，可監控資料中心基礎架構環境日常運作時的多種特性，包括伺服器平臺的耗電、效能、安全性、散熱（進氣口與排氣口的氣流溫度）、資源使用率（處理器、記憶體、I/O、每秒運算資源利用率）、所在位置。若是針對伺服器的管理而言，NM可做到動態監控設備的耗電情況，並且能橫跨多個節點、機櫃與資料中心，掌握這些不同規模設備的發熱組態。

在NM 3.0當中，新增的特色大多是針對用電的管理，像是：能及早預測電力不足，當系統所需電力瀕臨到資料中心供電的上限時，NM能自動推行減量用電的措施；對於系統開機期間會出現尖峰用電的情況，NM可以設定此時的耗電量上限來控管，而不需要複雜的程序或透過先行關閉部分處理器核心來達成目的。

RDT的兩大應用面向與發展順序

基於快取與記憶體這兩個走向，英特爾發展了多種針對伺服器執行環境的QoS資源管理技術，可橫跨整個共用平臺，實施監控的機制，並延伸到強制套用容量分配政策。

RDT技術發展三部曲

歷經3個時期的發展，英特爾終於將資料中心管理技術，從硬體層次的伺服器省電，逐漸提升到更高階的快取與記憶體資源管理，做到全面的IT資源調度指揮，增進資源使用率，對於軟體定義IT基礎架構下頻繁進行的自動環境產生（Automated Provisioning）工作，也相當有幫助。

【相關報導請參考「英特爾新伺服器平臺登場」】

在很多英雄電影當中，常會提到「能力越大，責任就越大」這句話，同樣地，擁有的資源如果越多，通常大家也會期望，必須能夠提供更好的效率。但實際上，要達到這樣的理想目標，往往相當困難。

以資料中心的管理而言，雖然伺服器虛擬化的應用在企業環境當中，已經相當普及，然而是否能發揮這類型環境的應有功能，仍有許多內外在的條件需要配合。就技術的角度來說，隨著接下來企業IT勢必要走向軟體定義式環境的潮流，如何提升效率仍是重要議題。

不論是在何時，IT要做到資源的高度融合，以及快速提供應用系統所需要的環境，一向不太容易，然而，現在因為虛擬化技術大為流行的關係，也促使許多廠商提出了好幾種新的IT基礎架構建置方式，例如，融合式基礎架構（Converged Infrastructure）、超融合式基礎架構（Hyper-Converged Infrastructure），最近又有廠商想要主推組合式基礎架構（Composable Infrastructure）。整體而言，它們都可算是軟體定義基礎架構（Software Defined Infrastructure，SDI），最大的差別在於整合度與搭配彈性。

在這樣的發展下，仍有個共通點，那就是資料中心對於伺服器的依賴度將會越來越高。因為每臺伺服器或一群伺服器叢集就是共用平臺，而且，IT基礎架構所需的各種資源，現在幾乎能夠完全由伺服器搭配虛擬化平臺軟體來提供——不只是運算（虛擬處理器與記憶體），現在當紅的軟體定義儲存，也是能夠架構在裸機伺服器（bare metal），或是整合在伺服器虛擬化平臺的環境、以超融合架構之姿提供，而SDI繼續演進的下一步目標，則是寄望網路虛擬化應用的普及，像是網路功能虛擬化（NFV）、軟體定義式網路（SDN）等相關的各式技術。

既然有越來越多IT基礎架構的資源，都逐漸改由伺服器搭配各種虛擬化軟體來提供與承擔，對於伺服器所要提供的效能與功能，要求也越來越多。這些當然可以透過軟體做到最佳化與提供對應的機制，不過若能從底層共通硬體平臺的角度來著手支援和改良，將可以節省許多額外的處理負擔，更能達到一勞永逸的理想效果。

關於這樣的想法，其實在我這次在製作封面故事的過程，才逐漸意識到。對於每次處理器平臺的推陳出新，不論是個人電腦或伺服器，我跟大多數人一樣，總覺得不外乎效能的提升、功能的增加，即便3月初我已經先參加過處理器廠商所舉辦的新品發表工作坊，直到月底產品正式推出，對於有哪些令人驚艷的亮點，我還沒有很明確的答案。

然而，經過仔細研究一些新功能的運作原理後，我才赫然發現為何英特爾一直強調資源督導技術（Resource Director Technology，RDT），因為它的確是切中當前伺服器應用上的要害——IT資源調配（Orchestrator）和自動化環境提供（Automated Provisioning）。

在伺服器虛擬化還未流行的年代，許多系統大廠所提倡的IT服務管理當中，已提到上述這兩種應用，但是當時只有大型企業環境比較有相關的需求，去實踐這樣的功能，而現在隨著VMware vSphere、微軟Hyper-V的競爭，接續而來的OpenStack降低了建置IaaS環境的門檻，後續又有Container引發的DevOps浪潮，Orchestrator和Provisioning成為IT人員所熟悉的字眼，因為平常可能就必須透過這些方式來快速部署應用系統環境。但誰想得到，如今這些資源監督與服務品質控管（QoS）的工作負載，如今也可卸載一部分給處理器平臺來幫忙分攤呢？

因此，我認為RDT的確是相當關鍵的技術突破，此外，最近許多軟體定義架構的相關產品也陸續增添了這類功能，剛好能與此相呼應。例如，VMware在Virtual SAN年初發布的6.2版當中，也強調能對所管轄的軟體化虛擬儲存資源，提供QoS控管機制。

由此可見，相關的資源管理機制有其必要，因為如果坐視不管，各種應用程式將會相互搶奪IT基礎架構的資源，這樣可能會導致一種怪現象：明明資源充沛，但重要業務應用系統反而得不到足夠資源的情況。

因此，如何妥善地分而治之，勢在必行，QoS不該只是針對網路、運算、儲存等層面來逐一進行，對於身繫SDI關鍵的伺服器平臺來說，若能從底層開始提供輔助機制，對於相關的控管要求，可以落實到更徹底的程度。

想要認識一門語言，不單只是就語法部份，認識的設計與風格，也是極為重要的一部份。

在標準程式庫為數眾多的API中，從群集API的資料結構分類與階層作為開始，是個不錯的方式，對於Python這類將常用資料結構作為內建型態的語言，更是如此。

從Python內建型態談起

就語言來說，常用的資料結構，都會有一套標準實作。

有些語言將常用資料結構內建為語法的一部份，像是Python的list、set、tuple、dict等，都可使用實字方式撰寫，這讓程式變得簡潔，也能應付大多數處理資料的需求；有些語言將這些實作以獨立的API實作，像是Java的Collection、Map API等，讓這類資料結構用來與程式語法涇渭分明，雖然語法囉嗦，然而，開發者較易（或說是強制要）掌握型態與實作品的特性。

對於熟悉Java的我而言，在使用Python語言，享用過這類資料結構作為直譯器內建型態的好處之後，不免開始有了一些矇朧的疑問，這些內建型態的實作特性呢？我很熟悉Java中Collection、Map API的設計架構，那麼Python中list、set、tuple、dict的分類與階層呢？

若不能掌握API設計架構，不但難以掌握各資料結構實作品的特性，也容易淪為死記API的窘境，更容易撰寫出沒有彈性的程式。

由於熟悉Java，一開始不免想要將Java中的介面與實作品，逐一在Python中找出對照物，不過，不久就發現方向似乎有點錯誤，畢竟兩門語言的設計哲學不同，更何況是API的設計了，最大的差別之一是，Python是動態定型，而Java是靜態定型語言，因此Python沒有Java中Collection、Map那樣的介面階層，而是直接思考行為，將相關資料結構分為了Sequences、Set與Mapping三種型態。

對於Sequence，它們都具有索引取值、切片等一些共同的行為，Python接著將Sequence進一步地區分了Immutable與Mutable兩種，str、tuple、bytes屬於Immutable，而list、bytearray屬於Mutable，並具有Immutable幾乎全部的行為，以及切片操作指定、append、remove等操作，然而，Immutable具備、但Mutable不一定會實作的行為是hash操作，因此Immutable的型態就可以作為dict的鍵，或者是set、frozenset的元素。

collections模組

所謂Sequence型態，並不是指它們真的有繼承一個Sequence類別，而是指具備Sequence的行為，具體而言，就是像實作了len、index這類的操作罷了，這讓設計函式時更有彈性；進一步地，我開始想到‥set、dict的行為，分別看來就像是Java中的HashSet、HashMap，都是無序的，那麼有沒有TreeSet、TreeMap呢？對於這類需求，Python提供了collections模組來滿足。

在collections模組中，可基於dict建立一個OrderedDict，它看來像是Java中的TreeMap，不過是以元素插入順序來定序，這表示，若想在取得鍵值對時，能依自訂順序來取出，就必須先在一個Sequence中自行對鍵值排序，再用排序後的結果建立OrderedDict。

在Java的Collection架構中，有個Queue介面與子介面Deque，而在Python中，list本身可實現Queue甚至是Deque，不過要注意到效能問題——當從list前端取出或新增元素時，時間複雜度會是O(n)，如果元素數量多的話，最好是改用collections模組中的deque，它的popleft、appendleft時間複雜度會是O(1)，當然，作為雙向佇列的實現，deque也提供了rotate之類的方法。

在Python中，tuple的地位總是比較尷尬，很多層面它跟list類似，只不過它是Immutable，佔用比較少的資源；然而，如果看過Haskell的Tuple，就會知道Tuple的元素型態，相當於臨時組成了未命名的新型態，其實在Python的collections模組中，也有個類似的namedtuple函式，可讓既有的tuple跟Haskell中的Tuple類似，充當臨時的資料結構。例如：

Point = namedtuple('Point', ['x', 'y'])
p = Point(11, 22)
print(p.x + p.y)  # 顯示 33

namedtuple是個工廠函式，傳回的實際上是動態建立的tuple子類別，因此具有tuple的行為，然而具有指定的型態名稱與欄位名稱，也可以使用dot來存取欄位，這讓它的實例就像是個Immutable物件，比一般物件節省資源，也可以充當dict來使用。

collections.abc模組

當然，collections中，還有像是Counter類別、defaultdict函式等可以使用，不過，終究還是沒有發現像是Java中LinkedList、TreeSet這類的東西。如果需要這類東西，必須要自行實作。例如，若需要list的全部功能，而且，在某些場合必須被判斷為list實例（像是使用isinstance()判斷，例如OrderedDict就是dict的子類別），那麼可以繼承list；如果只是要包裹一個list，並讓包裹器行為上像個list，可以繼承UserList。

然而，如果只是要實作群集的行為，但不需要是群集中某個類別的子類別時，可以繼承collections.abc模組中的相關類別——abc代表著abstract base classes，也就是這些類別是作為抽象基礎類別，它們本身已經實作了一些行為。不過，還有些必要的抽象方法，必須開發者在繼承之後自行定義，如果開發者忘了定義，建立實例時會引發TypeError，並告知忘了實作哪些抽象方法，這開發者免於記憶或查詢有哪些方法必須實作。

而且，一旦開發者定義了必要的抽象方法，基於這些抽象方法的其他方法實作（Mixin Methods），就能夠運作了，這會比完全自定義一個群集類別來得方便許多且不容易出錯，比方說，在Python的collections.abc官方說明文件中，就有個〈OrderedSet recipe〉的文件鏈結，其中的OrderedSet，就是基於collections.MutableSet而實作。

collections.abc模組中，還有Iterable、Iterator、Hashable等抽象基礎類別，想要清楚地認識Python中的群集特性與行為，認識collections.abc模組是個相當好的管道，規範抽象基礎類別的PEP 3119規格書，也非常值得參考。

若想再更進一步，我們可以針對collections、collections.abc中，研究相關函式或類別的程式碼實現，這樣將更能夠掌握相關特性的實現細節。

清楚而自信地使用資料結構

Pascal之父Niklaus E. Writh曾經說過：「演算法加資料結構就等於程式」，因此是否瞭解常用的、特性與相關的效用函式，對程式的設計影響鉅大。這在我先前專欄〈開發者應認識的資料型態及效用函式〉、以及〈善用程式庫中的資料結構特性〉，也曾經探討過。

因此，面對像Python這類將資料結構內建為語法一部份的語言，雖然一開始用起來順手且具有高產能，然而，最好還是循著對資料結構特性的基本認識，逐一探討這些便捷語法背後的設計與實現，甚至必要時，可基於標準程式庫提供的基礎，試著自行實現相關資料結構。

這麼一來，不但能對相關語法或程式庫能有更深入的瞭解，且進一步地認識語言及API的相關設計哲學，在需要這些資料結構時，也才能清楚而有自信地加以運用。

畢業多年的學生準備要出國留學，來找我聊天兼拿他的推薦信。學生問我，我常鼓勵學生多看看世界，有機會要到世界不同角落闖一闖，為何又曾為文反對臺灣人到澳洲度假打工？

在我看來，這一點也不矛盾。我們每做一件事，不妨都先自問，做這件事的初衷是什麼，這件事的本質又是什麼。勇闖天涯的目的，原本不就是為了脫離自己熟悉的舒適圈，讓自己的視野與能力得到在家鄉無以實現的提升？

那麼多人去度假打工，臺灣留學歐美的人數卻緩步下滑，到全世界其他兩百多個國家工作的人數也是不成比例的低，難道不是因為度假打工簽證門檻低，先去過的朋友或是學長姊人數眾多，可能有人照顧或是有安心感，而且不用花那麼大的力氣準備留學所需的種種考試？

想看看世界有多大，卻又不想花太大的力氣準備與研究，是臺灣人度假打工集中在少數兩三個國家的主要原因。但輕飄飄的選擇，只能換來輕飄飄的結果。你若花了大把的時間在農場低頭採蕃茄，又有多少時間能抬頭看看這個世界有多大？這樣的勞力工作經驗，又能對未來人生的視野開拓與能力提升有多大的助益？

只選輕鬆的路走，是臺灣陷入當前困局很關鍵的因素。

臺灣現在那麼多人瘋韓劇、迷韓團，臺灣自製的電視節目卻凋零得令人欷噓不已，何以致之？最簡單而具有安慰劑效果的標準答案通常是：臺灣市場太小。但這種答案根本忽略了，韓國也不過是個五千萬人口的國家，像〈太陽的後裔〉這樣製作經費近4億臺幣的電視劇（一集的製作經費為兩千五百萬臺幣），同樣也不可能靠韓國的國內市場回收成本，而是在節目企畫的同時，就已將海外市場的收入納入考量。

臺灣的電視人的選擇則是，宣稱電視頻道的平均收視率越來越低，節目製作經費只能等比例的越來越少。而這越來越少的經費製作出來的節目，對觀眾來說自然也是越來越沒有吸引力，往下沈淪的惡性循環就此開展。

電視平均收視率往下滑全世界都一樣，不同的是，不同國家的人，回應的策略不一樣。韓國人用企圖心與冒險來挑戰一個更大的市場（也沒人能保證韓國人一定能成功），我們臺灣人呢，選擇了一條比較輕鬆的路來走──有多少錢，做多少事，聽起來言之成理，但其產出，不會是現今的全球市場有競爭力的產品。

電視業在臺灣並非特例，我們過去的專長叫彈性快速，向來的習慣是短期回收，不做太冒險的投資。過去這套還算靈光，但這樣的思維若還可行，臺灣的經濟現況也就不致坐困愁城。

最近鴻海董事長郭台銘經過四年的努力，終於成功入主日本夏普。有點產業常識的人應該都不難理解，要成功扭轉夏普的頹勢，絕對不是簡單的事情，但這事堪稱令人振奮也正在於：年逾六旬的千億富豪都在挑戰困難之事了，年輕人還要選一條輕鬆的路走嗎？

中了加密勒贖軟體Petya別緊張，專家釋出破解方法

名為Petya的硬碟加密勒贖軟體在肆虐兩周後，有高手製作出解密工具並在網路上公開釋出。

這隻勒贖軟體三月底開始流傳而聲名大噪。受害者接到冒充面試者寄來的履歷，在不疑有他情況下下載並開啟後數秒即出現Windows藍色死亡螢幕而當機。等電腦重新開機後，電腦開始貌似Windows磁碟檢查的過程，實際上是Petya正在加密主開機檔（master boot file），導致硬碟無法使用。（詳全文）

IBM伺服器處理器，在Google資料中心找到新春天

（圖片來源／Google）

日前，在IBM OpenPower大會上，Google宣布與美國雲端服務業者Rackspace合作，共同開發以IBM Power9 CPU為基礎的開放式伺服器架構，且此開放式伺服器的規格將符合Google與臉書共同設計的48V開放式機架電源分配設計。另外，Power9開放式伺服器的設計也將提交給由臉書主導的OCP社群。（詳全文）

臺灣IoT聯盟又多一家，將結盟工業IoT加快產業實作

臺灣IoT廠商又多一家IoT聯盟的新選擇。由民間共同籌組成立的亞洲物聯網聯盟（AIoTA）今日在臺成軍，未來將以打造一個跨產業合作的IoT夥伴平臺為目標，更將攜手國際工業物聯網聯盟（IIC），透過雙方緊密合作，以加速建立產業IoT生態系。該聯盟初期成員將有20多家，涵蓋了IT廠、企業、法人和新創公司等。（詳全文）

找駭客當打手代價知多少？DDoS攻擊每小時5美元起跳

（圖片來源／Dell SecureWorks）

Dell旗下資安部門SecureWorks發佈了地下駭客市場報告，顯示駭客黑市的發展愈來愈專業化，不僅拉長駭客工時，為確保客戶滿意度還提供擔保人製度。另外，該報告也揭露雇用駭客服務如DDoS攻擊收費，網路銀行帳戶登入資料、航空公司哩程等資料買賣價格，以及破解Wi-Fi教學、側錄ATM等線上教學課程收費。（詳全文）

Rackspace推OpenStack代管服務

（圖片來源／Rackspace）

美國雲端服務業者Rackspace推出OpenStack私有雲代管服務，協助企業用戶建置OpenStack私有雲環境，以及管理端到端的部 署、監控和營運，用戶可以選擇部署在自己的資料中心、Rackspace資料中心，或是Rackspace支援的第三方託管設備。（詳全文）

SQL Server 2005已終止延伸支援

（圖片來源／微軟）

微軟SQL Server 2005自4月12日起終止延伸支援，微軟將不再發布SQL Server 2005的安全性更新或修補程式，建議用戶盡快更新至較新版本的SQL Server或Azure SQL資料庫，另外，SQL Server 2008在2019年7月9日也將終止延伸支援。（詳全文）

WordPress實施代管網域免費HTTPS加密

（圖片來源／WordPress）

WordPress.com代管網域下的所有新網站幾分鐘內即可自動完成加密部署。未來會逐次推向代管於WordPress.com的網站，已啟用HTTPS加密的網站及部落格會在瀏覽器網址列上顯示綠色鎖頭標誌，以明碼HTTP呼叫者也都會自動導向加密網站，即從HTTP://導向HTTPS://。（詳全文）

福斯捨VMware用OpenStack架私雲

OpenStack業者Mirantis上周宣布已奪下福斯汽車集團（Volkswagen Group，VW）的私有雲建置案，這是OpenStack開放源碼在雲端應用中的一次大勝利，但開放源碼大佬紅帽（RedHat）卻在此次的競爭中落敗。

根據外電報導，VW並不會馬上結束與諸如VMware等既有合作夥伴的合約，但打算循序漸進讓OpenStack成為旗下12款汽車品牌的標準化平台，涵蓋Audi、VW、Porsche等。（詳全文）

北韓發動GPS蓋臺，南韓導航系統失效，恐導致武器無法定位

根據韓國最大新聞通訊社韓聯社報導，北韓在3月31日發射無線電波，干擾北緯38度停戰線以南的韓國地區的GPS衛星導航定位系統，韓國統一部發言人Jeong Joon-Hee譴責，北韓發動GPS蓋臺（GPS Jamming）是一種挑釁行為，應該即刻停止這樣的攻擊手法。

雖然韓國在這次的攻擊中，沒有發生立即的危險事件，但綜合各家媒體報導，有70多艘韓國漁船因為無法定位返航，也有110架飛機受到影響，其他包括部分智慧型手機的功能失效，都在此次無線電波攻擊受影響範圍中。不過韓國軍方設備有反GPS干擾系統，尚無實際的軍事衝突爆發，也沒有造成實際的損害。（詳全文）

臉書整合Dropbox，聊天同時分享檔案

（圖片來源／Dropbox）

Facebook Messenger用戶必需在手機中同時安裝Dropbox App，如此便能在Messenger中透過「更多」（More）選單，使用Dropbox的檔案分享功能，直接在Messenger中分享照片、影片及動畫檔，其他形式檔案則需開啟Dropbox App。（詳全文）

Android Studio 2.0穩定版釋出

（圖片來源／Google）

新的Instant Run能讓開發者立刻檢視程式碼改變後的執行狀況，不需要重新編譯並安裝APK檔，將能大幅提高開發速度。此外，Android裝置模擬器能夠支援多核心CPU，大幅加速模擬器的運作，提昇開發效率。（詳全文）

ESET與執法單位聯手關閉垃圾郵件殭屍網路Mumblehard

資安業者ESET宣佈經過近一年多的追蹤後，在與執法單位合作下，感染約4000台Linux伺服器的垃圾郵件僵屍網路Mumblehard終於遭到成功關閉。

ESET在2014年底發現，並於2015年4月首度公佈Mumblehard的研究結果。Mumblehard由外部C&C伺服器控制執行命令，另有負責發送大量垃圾郵件mail daemon，以及隱藏其執行的Perl程式碼的packer。C&C伺服器具有script會隨時監控IP位址封鎖名單Spamhaus CBL（ Composite Blocking List），一旦發現它感染的伺服器IP位址在黑名單上，該script就會要求Spamhaus刪除該IP位址，成功躲過封鎖。（詳全文）

臉書釋出眾多開發者工具，臉書Account Kit、儲存按鍵受矚目

（圖片來源／Facebook）

Account Kit採用臉書的架構，允許使用者以手機號碼或電子郵件登入，不需輸入使用者名稱或密碼，能降低使用者登入門檻；而儲存按鍵（Save Button）允許外部網站嵌入臉書的儲存按鍵，讓臉書用戶瀏覽外部網站時按下儲存鍵，將外站的內容存放在臉書的私有列表（private list）中。（詳全文）

臉書發表Messenger聊天機器人API

一如多天的傳言，臉書(Facebook)在開發者大會F8正式發表包括自有聊天機器人及傳訊API的Messenger Platform計畫預覽版，讓開發人員及企業得以Messenger為平台，開發人工智慧的客戶互動應用，包括聊天機器人。

自去年起Facebook已發表Messenger Platform，將Messenger從單純的傳訊應用推展為平台，以鼓勵開發人員及企業打造整合Messenger的多樣化服務，當時已提供包含影音編輯、動畫等40多款程式。最新一項嘗試則是Messenger機器人程式。（詳全文）

臉書開放Live API，可整合無人機、Livestream與手機

Live API能讓無人機、相機或智慧型手機等製造商能將Live整合到其影音播放產品中。首批整合Live API的業者包括美食電視網Tastemade、直播業者Livestream、串流影像編輯軟體Videpresso、線上新聞媒體BuzzFeed及無人機廠商DJI等。（詳全文）

監測四億多用戶中的洗錢行為 螞蟻金服如何用大資料偵測金融犯罪

（圖片來源／勤業眾信）

數位金融時代最大的特色在於，反洗錢人員透過取得大量的用戶資料，包括網路搜尋、影音觀看紀錄與物流資料等，來分析交易是否存在異常，而傳統銀行多是使用靜態資料，如用戶的性別、年齡、地區與職業等為客戶進行風險評級，螞蟻金服法務及合規部高級經理黃元駿表示，「對於數位金融反洗錢來說，最關鍵的就是掌握資料。」（詳全文）

IBM X-Force研究團隊上周揭露了一隻結合Nymaim及Gozi ISFB的木馬程式GozNym，該木馬程式已攻擊24家位於美國及加拿大的銀行，只花了短短的幾天便盜走數百萬美元。

Nymaim與Gozi ISFB皆為木馬程式，其中，Nymaim最主要的功能為勒索，同時也是一隻下載木馬，可下載諸如Ursnif金融木馬等其他惡意程式；Gozi ISFB則是一隻金融木馬程式，當被注入瀏覽器時，駭客即可監控使用者的瀏覽行為。

X-Force表示，經營Nymaim的集團融合了Nymaim與Gozi ISFB的程式碼，建立了新的GozNym木馬程式，它擷取Nymaim的隱形與持久優點，同時利用Gozi ISFB竊取金融資訊的能力，成就了一款強大的木馬程式，並針對北美的銀行展開攻擊。

調查顯示，GozNym鎖定22家的美國銀行、信用合作社與電子商務平台，以及2家的加拿大金融機構，它能夠操縱網頁程序，進行網路銀行詐騙攻擊。

根據富比士（Forbes）的報導，操縱GozNym的駭客集團來自東歐，今年4月初在短短的3天內便盜走了400萬美元。

The Information近日報導，Alphabet旗下專注於研究智慧城市技術的子公司Sidewalk Labs即將展開Sidewalk專案，準備建立一個充滿各種未來高科技服務的智慧城市，這個未來城市路上跑的是自動駕駛車，會有創新的無線網路解決方案，有新型態的大眾運輸，還有新的管理模式。

根據報導，Sidewalk Labs執行長Dan Doctoroff正準備與Alphabet執行長Larry Page討論Sidewalk專案的可行性，倘若獲得Page首肯，那麼今年就會向全球徵求打造此一未來城市的地點。

Sidewalk Labs已與上百名都市計畫專家或技術專家討論過Sidewalk專案，探討各種智慧城市模型，最主要的目標則是在建立一個可用來測試各種創新技術的區域，以利未來將相關技術導入至各大城市，此一實驗區域至少應可容納數十萬人口。

從育成專案到去年搖身一變成為Alphabet子公司的Sidewalk Labs宗旨在於改進城市的居住品質，以智慧技術為基礎來改善生活成本、交通效率、能源使用率與政府營運效率，該公司執行長Doctoroff曾經擔任紐約市副市長，擁有經濟開發與都市更新的完善經驗。

Sidewalk Labs去年因投資Intersection而參與了紐約市的LinkNYC公共電話亭免費無線熱點計畫，將紐約市的電話亭改造成Wi-Fi服務站（Wi-Fi Kiosk），提供免費的Wi-Fi網路服務、國內電話與USB充電，營收則全仰賴其55吋螢幕上所播放的廣告，估計今年7月底可達到500座Wi-Fi服務站，最終將達到7000至1萬座的Wi-Fi服務站。

Google於上周五（4/15）更新了Chrome線上應用程式商店（Chrome Web Store）的使用者資料政策，祭出更嚴格的隱私與透明度要求，舉凡不合規定的擴充功能與應用程式都會在今年的7月15日之後被移除。

Chrome Web Store是Google替Chrome瀏覽器所建置的應用程式商店，供應各種應用程式、瀏覽器主題與擴充功能，原本就設有使用者隱私保障功能，提供無痕模式與精細隱私偏好設定，現在則進一步擴大使用者資料政策（User Data Policy），以確保開發人員對使用者資料的處置方式符合使用者預期。

新的條款包括要公開對使用者資料的處置方式並揭露隱私作法、得公布隱私政策且加密使用者的個人資訊，以及在蒐集與功能無關的使用者資料之前，必須透過明顯的提示取得使用者的同意。此外，Google也將禁止開發人員蒐集與程式主要功能無關的網路瀏覽行為。

Google會先行通知那些違反新政策的程式開發人員，要求他們在7月14日之前進行必要的修改，7月15日便會開始將不合格的程式自Chrome Web Store中移除。

市佔率僅次於IE的Chrome瀏覽器日益成為駭客染指的對象，打造惡意程式來詐騙使用者，或是鬼祟蒐集使用者資料以出售求利的事件層出不窮，這使得Google持續整頓Chrome的生態體系，於2014年封鎖了官方網站以外的Chrome擴充程式，2015年大舉移除亂插廣告的不當程式。

根據市場調查機構Net Applications的數據，今年3月Chrome在桌面瀏覽器市場的佔有率已達到39.09%，緊追微軟IE的43.4%，而Firefox的市佔率也受到Chrome影響，從2009年的25%高峰跌至10.54%。

在被微軟收購兩個月後，Xamarin宣佈旗下Java行動應用開發工具RoboVM將自2017年4月終止提供服務。

和Xamarin的工具一樣，RoboVM的工具也是讓開發人員以單一程式語言開發iOS或Android等平台的App，差別在於Xamarin使用C#，RoboVM則使用Java。

Xamarin於去年10月收購RoboVM後，原本開源的RoboVM也開始收費。Xamarin本身則在今年二月被微軟買下，使得RoboVM的Java開發工具面臨去留問題。

上周RoboVM創辦人Henric Müller 上周指出，過去幾周RoboVM、Xamarin及微軟團隊一直針對RoboVM的產品未來進行技術與業務的評估，而根據現有Java開發App的整體狀況，決定將逐步關閉RoboVM。RoboVM的現有付費授權或相關訂閱服務將到明年4月30日起終止，以便開發人員有時間移轉到其他技術。

RoboVM表示，已開發好的App將不會有任何影響。以iOS app而言，除非蘋果有什麼重大改變，否則應該還能持續運作。而Android app則可以Android Studio及IntellliJ IDEA開啟及組譯，而任何在Android和iOS上使用的跨平台RoboPods，在沒有重大變動情況下也可繼續使用。

還在開發中的App可選擇以Xamarin工具轉移到C#，或使用其他支援iOS的Java SDK，像是libGDX。不想再用的客戶也可以尋求全額退費。

微軟買下Xamarin決心大力支持，不但於本月初宣佈整合到Visual Studio所有版本，包括免費的社群版（Community Edition）、專業版及企業版、開源Xamarin SDK，而且還停止Android到Windows的 App橋接計畫Astoria，呼籲開發人員轉向Xamarin。

蘋果一月起終止Windows版QuickTime的安全更新後，出現2個安全漏洞，安全公司呼籲唯有移除才能免於攻擊。

安全業者TippingPoint旗下的零時攻擊研究計畫（Zero Day Initiative）於上周針對 ZDI-16-241以及 ZDI-16-242兩項漏洞發佈安全公告，揭露Windows版QuickTime中兩個新發現的重大漏洞。

其中ZDI-16-241為moov Atom堆積損毁（heap corruption）遠端程式碼執行漏洞，攻擊者對moov atom欄位中發出錯誤值，進而在分配的堆積緩衝區之外寫入資料，藉機在QuickTime播放器環境下執行任意程式碼。ZDI-16-242也是堆積損毁遠端程式碼執行漏洞，只是位於QuickTime Atom處理過程中。兩項漏洞可能導致機密資料被竊或系統資源與公司資產受損。

值得注意的是，安全廠商在去年11月即已通知，然蘋果遲遲未修補這兩項漏洞，零時計畫乃依據該部門針對此類情況的政策，逕行發佈漏洞公告。

蘋果最近一次是在一月發佈Windows 版QuickTime 7.7.8。趨勢科技指出，由於蘋果已不再發佈Windows 版QuickTime 安全更新，因此這兩個漏洞也將不會獲得修補。

年初的更新已移除QuickTime瀏覽器外掛，使得惡意程式無法透過網頁掛馬攻擊入侵，需要使用者點入惡意網站或開啟惡意檔案程式才能駭入QuickTime。

趨勢科技表示，雖然目前沒有發現相關的攻擊，但由於永遠喪失了蘋果的支援，因此Windows用戶自保之道是將之移除。美國電腦緊急應變小組（US-CERT）也對此發佈安全警告。蘋果也公佈QuickTime 7 for Windows的移除指示。

蘋果並未正式公佈QuickTime停止支援Windows的消息，但Ars Technica表示這項計畫已醞釀至少數個月之久。 QuickTime則從未支援過Windows 8 及10。

隨著大廠的產品支援到期，許多軟體成為孤兒而令用戶身陷資安風險。除了Windows版QuickTime外，知名擁有廣大用戶但無法獲得更新的軟體還包括Windows XP及Oracle Java 6。

為了迎接4月22日的世界地球日（Earth Day），蘋果於上周更新了生態環境（Environment）的網頁內容，並被眼尖的媒體發現蘋果將OS X的名稱寫成MacOS了，猜測蘋果將替Mac作業系統更名，然而，蘋果很快就更正了，把MacOS再換回OS X。

Mac OS一辭現身於生態環境網頁的FAQ中，其中一個問題涉及蘋果如何評估產品的溫室氣體生命周期，蘋果提到：「在客戶使用上，評估的是產品於模擬場景運作時的電力損耗....每年的使用模式資料來自於前四年的『MacOS』及tvOS裝置用戶，以及前三年的iOS與watchOS裝置用戶。」

文中所指的MacOS顯然就是蘋果Mac電腦的作業系統OS X，其實，蘋果在今年3月釋出的OS X 10.11.4框架中，也有一份文件的名稱以MacOS取代了OS X。

美國媒體分析，蘋果近來習於將作業系統名稱冠上產品類別，例如Apple TV所使用的tvOS或Apple Watch所使用的watchOS，因此把Mac電腦使用的作業系統從OS X改為MacOS也是理所當然的。

總之，也許是注意到媒體的報導，蘋果很快就把網頁上的MacOS換回OS X，外界則揣測若蘋果真要變更OS X名稱，最快應會在6月舉行的WWDC開發者大會上宣布。

由Google、微軟、IBM及VMware等廠商組成的OCI聯盟，致力於統一各家Container技術標準。OCI除推出OCI runtime標準，讓開發者打包、簽署應用程式，並且可以自由選用不同的Container runtime環境外，在近日則更一步延伸，推出開放容器OCI映像檔標準，由Container技術社群訂定規範，確立容器映像檔建立、認證、簽署以及命名的方式。

CoreOS研發團隊總監Jonathan Boulle表示，未來數個月中，開發者可期待透過共享標準，建立、發布軟體Container。因此，無論開發者是使用appc或是Docker映像檔，也不會受到任何影響，「對於業界承諾『打包一次，各處運行』（package once，run anywhere），也是前進了一大步。」他說。

OCI在去年6月成立時，起初的目標主要瞄準於建立Container執行環境。然而，此次映像檔標準的推出，Jonathan Boulle認為，訂定了Cotnainer標準的最重要基礎元件，「建立起了分散式（distributable）的容器映像檔」，為容器可攜性的目標奠定了基礎。他表示，開發者也只須一次性地建立、打包容器，便可以在不同的雲端業者平臺或是企業就地部署。

OCI映像檔標準目標是避免Container遭廠商或引擎所綁定

訂定OCI映像檔標準的目的在於，讓開發者自由打包應用程式Container，並使用不同的Container引擎運作。因此，Jonathan Boulle表示，使用者也不會被特定廠商的Container技術所綁定。同時，也可以在rkt、Docker、Kubernetes及Amazon ECS等異質runtime中運作，「Container本身也不需要進行修改。」

Jonathan Boulle也透露，在未來數個月中，如Amazon Container Registry、Google Container Registry、Docker Hub及Quay等Container儲存庫，也都將支援OCI映像檔標準。

許多開源容器廠商對於OCI映像檔標準，也紛紛表示看好。如CoreOS技術長Brandon Philips表示，推出OCI映像檔標準，讓使用者逐步在採用現代化基礎架構中導入Container技術。Rancher首席架構施Darren Shepherd則認為，此標準的釋出，不僅讓工作可以在異質雲環境中進行，也可以跨Container runtime環境執行。

大廠相繼搶攻360度環景影片市場，Alphabet旗下Google的Youtube開始支援全景影片即時串流及空間音效，以展現沈浸式的影音體驗。

這項宣佈是Youtube去年三月首度支援360環景影片播放後更進一步的行動。Youtube首席產品經理Neal Mohan同時也指出，本周的Coachella 音樂節也將在Youtube合作下，首度以360度環景形式在Youtube即時轉播。

另外，該公司也宣佈支援隨選Youtube影片的空間音效。Mohan指出，一如360度沈浸式影片，透過展現聲音的深度、距離及強度，可帶給聽眾身歷其境的感受。Youtube也提供了目前可支援Android裝置播放空間音效的歌單。

同時，Youtube也正和第三方軟體商合作，以使這些產品製作的影音內容相容播放於Youtube上，包括VideoStitch、Two Big Ear，以及pux ALLie、Vahana VR 、 Orah 4i等。

今年初Google 即已發佈新版Cardboard SDK支援空間音效的播放。透過Youtube及VR裝置Cardboard支援環景影片及音效，Alphabet積極建構內容播放平台，以搶攻虛擬實境市場。

臉書（Facebook）也積極佈署VR及直播影片的應用。除了網站新聞動態支援360度影片及Oculus VR頭戴裝置外，在上周的F8大會上， Facebook也宣佈了環景相機Surround 360的參考規格，同時開放串流影像Live的API，以爭取第三方軟、硬體業者未來採用其平台播放。

蘋果於本周一（4/18）公布今年全球開發者大會（Worldwide Developers Conference，WWDC）將於6月13日至17日間於舊金山舉行，即日起開放登記，並將抽籤決定門票得主。

欲參加WWDC必須得是蘋果開發者專案（Apple Developer Program）或蘋果開發者企業專案（Apple Developer Enterprise Program）的會員，符合資格者可於4月18日至4月22日之間進行登記，之後蘋果將會隨機抽出入場門票，票價為1599美元（台幣近5.2萬元）。

蘋果全球行銷副總裁Philip Schiller表示，今年的WWDC對於採用Swift語言，以及打造基於iOS、OS X、watchOS 與tvOS等平台應用程式及產品的開發人員而言是場標誌性的活動。

蘋果也列出了今年WWDC的活動內容，包括將有超過1000名蘋果工程師支援逾150場的手動實驗室與活動，以協助及指導開發人員使用蘋果技術與平台；可存取最新的平台與技術資訊，取得強化程式效能及設計的最佳實作準則；還能與來自全球的蘋果開發人員交流，去年參與WWDC的開發人員來自全球逾70個國家，並有8成是首度參加。

另有一系列不同主題的講座，餐會時也能與來自科技、科學或娛樂領域的大佬們一起交流，並發布蘋果針對各平台應用程式所設立的「Apple Design Awards 」設計獎得主。

即使無緣親臨現場，屆時全球開發人員仍可透過WWDC網站或WWDC程式觀賞直播內容。

麻省理工學院（MIT）電腦科學暨人工智慧實驗室（CSAIL）及專精於機器學習的新創公司PatternEx近日共同發表一份研究報告，展示了一個新的人工智慧系統AI2（原意為AI的平方，下面均以AI2表示），其預測網路攻擊行動的準確度高達85%，為先前系統的3倍。

AI2使用非監督式機器學習（unsupervised machine-learning）將資料轉化成有意義的模式，以用來檢查可疑的事件，之後將這些事件交由人類分析師來判斷哪些事件屬於真正的攻擊，再將成果回饋到系統上。

CSAIL科學家Kalyan Veeramachaneni表示，大家可將AI2視作一個虛擬分析師，它可以持續地產生新的模式，而且能在數小時內進行調整，代表它能夠快速且明顯地改善偵測率。

要建立一個結合人腦與電腦的網路安全系統並不容易，部份原因來自於必須手動標註網路安全資料的演算法。舉例來說，要發展可高度辨識物件的電腦視覺演算法時，只需幾個尋常志工來標註物件或非物件照片，然後送進演算法即可，但在一個攸關網路安全的系統上，多數人並不具備可標註諸如DDOS或滲出攻擊（exfiltration attacks）的能力，必須仰賴安全專家的協助。

然而，專家們通常是忙碌的，也不太可能花一整天的時間來辨識這些可疑的事件，因此一個有效率的機器學習系統必須能夠在不耗盡人力的情況下自我改善。

AI2在第一天的訓練中取出了200個可疑事件，交由安全專家進行判斷，隨著安全專家日復一日將成果回饋至演算法中，不多久每天需要安全專家辨識的可疑事件就可下滑至30到40個。在掃描36億行的日誌及經過3個月的訓練之後，AI2系統偵測攻擊行動的準確率便已達到85%。

該團隊指出，AI2每天所掃描的日誌可拓展至數十億行，將眾多的資料轉換成各種不同的行為類別，再藉以判斷是正常或異常。

從2010年開始風行的行動化、API化成為新一代的應用趨勢，也為遊戲產業帶來了不一樣的新挑戰，不僅要分析大量的資料，還要求快速，才能為競爭激烈且瞬息萬變的遊戲產業，精準掌握玩家行為與需求，以開發出吸引人的遊戲。

作為跨國遊戲平臺與遊戲開發商，好玩家跨足日本、香港、澳門、泰國越南與柬埔寨等，擁有近2,600萬會員，擁有大量的資料，但原先的BI系統僅能提供玩家在遊戲中登入時間、人數等平均值，難以挖掘出個別玩家消費行為與過關資訊等。

「BI系統提供的資訊遠遠不足，必須要跨入大資料。」他說。

在未來的遊戲產業中，誰能夠掌握更多的資料且具備更強的資料分析能力，就能夠精準抓住玩家的目光，以獲得更好的發展機會，因此，「大資料是公司轉型的競爭力的基礎。」，更是決定未來產業話語權的核心的所在。

為臺灣遊戲產業建立大資料平臺

一手建立大資料平臺的關鍵人物正是好玩家技術部副總經理古銘遠，為了要清楚掌握公司的營運狀況與玩家資訊，例如，分析出玩家購買寶物的品項、過關時間等，透過精準掌握玩家喜好，開發出更吸引人的遊戲以進軍全世界。

因此，古銘遠不滿足僅利用BI產生的資料，如玩家在遊戲中登入時間、人數等平均值，而難以挖掘出每秒鐘玩家的行為，他更積極地思考如何透過IT系統，對公司營運面產生正面的影響。

唯有透過大資料分析，才能精準掌握玩家道具消耗情況，如購買的道具名稱、購買時間、或是玩家購買道具之後，什麼時候第一次使用，與分析在一個關卡中，玩家購買那些道具，與最喜歡購買的道具為何等，以作為行銷人員與公司高階主管在決策時的重要參考。

身為好玩家技術長的古銘遠認為，建置大資料平臺最困難的不是建構系統，而是挖掘出有用的資料，以精準描繪出每一位玩家的型態與樣貌。

作為建置大資料分析平臺的遊戲公司，很大的挑戰在於，如何針對遊戲產業撰寫資料分析運算方式與邏輯架構，為了能夠精準地分析資料，古銘遠也利用了其他的資料視覺化分析工具，來評斷自家撰寫的分析邏輯或是其他的資料工具哪一套更為精準。

不過，古銘遠說，培養大資料分析相關人才正是準確挖掘出有價值資料的關鍵，目前好玩家內部仍舊缺乏大資料分析相關人員，由於臺灣資料科學相關學系近一兩年間才相繼成立，因此，正積極到業界尋找統計學科、資料採集與生物科技醫療相關領域的人員，借用他們資料分析方面的專才來協助公司建立大資料平臺。

不過，由於這些人員並非遊戲產業出身，古銘遠表示，約需要花一年時間培訓，才能正式上手。

好玩家預計於2017年完成建置大資料平臺，古銘遠說，屆時遊戲開發商只需要透過和好玩家的大資料平臺介接，就可以取得大資料平臺所提供的玩家資訊等，而不需要再自己耗費大量時間建置一套大資料分析平臺，以加速遊戲開發時間，藉以提高臺灣遊戲產業的國際競爭力。

成立初期大力擁抱開源虛擬化

不過，要建立大資料平臺之前，如何強化公司內部的基礎設備，以因應大資料分析應用服務所需，又是古銘遠面對的一大挑戰。

好玩家在公司成立初期就全面導入Citrix Xen虛擬化技術，依照會員人數多寡手動調整遊戲主機的數量，古銘遠解釋，由於遊戲平臺上玩家達千萬人以上，考慮到未來玩家數量會越來越多，透過導入虛擬化技術，可以降低實體機器的採購成本，與符合快速部署服務的需求，因此決定徹底擁抱虛擬化。

不過，導入虛擬化技術的過程中，因租用海外IDC機房的成本相當高，加上隨著遊戲種類和會員人數快速增加，以及遊戲主機中的資料量越來越多與每款遊戲所需的資源皆不同，加上不同的資料中心無法共享資源的情況下，為了要解決跨國支援服務和調度時會遇到的瓶頸，好玩家自2013年著手評估自建雲端平臺。

擁抱開源使用OpenStack

好玩家當初不是決定採用商業套裝軟體如VMware，而是選擇導入開源雲端作業系統OpenStack來打造雲端平臺。

古銘遠表示，導入VMware的授權費用相當昂貴，大大提高建置雲端平臺的成本，對於有意願在好玩家雲端平臺上部署遊戲的遊戲開發商來說，若將遊戲放在好玩家的雲端平臺上必須支付高額費用，倒不如選擇亞馬遜的AWS，藉以控管與降低開發成本。

此外，古銘遠表示，以好玩家內部來說，在導入雲端平臺時，若必須支付高昂的商用虛擬化產品的授權費用，會壓縮到技術部門創新研發的經費。

另一方面，OpenStack具備的未來潛力在於，企業激烈競爭下，IT部門的預算越來越低，而行銷部門的預算則逐年上升，如果公司有一天再也無力支付大筆商業軟體授權費用，公司為了節省IT建置經費，才考慮更換成開源平臺，不但會耗費大量轉移雲端平臺的時間，也浪費有限的人力與經濟資源。

不過，除了考量開發成本之外，為什麼好玩家敢比其他企業更早導入沒有商業技術支援的OpenStack，古銘遠說，擁抱OpenStack是因為此已經得到上百家IT軟體與硬體廠商的支持，且全球開發人數也達到上萬人。

為了要取得OpenStack第一手的訊息，古銘遠去年更赴東京參加OpenStack高峰會，和全世界的軟體開發人員交換最新訊息與討論導入OpenStack所遇到的問題，「很多問題不能只在社群中找答案，必須和技術廠商交流，才有助於解決導入與維運OpenStack。」他說。

而在導入OpenStack的過程中，首先面臨的挑戰就是，由於OpenStack有很多核心服務套件，包括了區塊儲存Cinder、網路Neutron等，建議企業必須先思考導入策略，也就是需要先解決的基礎架構問題為何，再選擇先行導入哪一些服務套件，「而非看到OpenStack好用，就全部拿來用。」。

另外，古銘遠也認為，建置OpenStack所面臨的挑戰還包括要必須先確定內部團隊的雲端技術能力，為了解決此問題，好玩家開始培養雲端技術團隊，包括至學校中招募大三、大四與研究所的學生至公司培養技術能力與學習遊戲產業的關鍵知識等。

不過，古銘遠說，光是建立OpenStack雲端平臺仍遠遠不夠，還需要搭配周遭的硬體設備，才能讓平臺順利運行。

在儲存設備上，隨著手機時代來臨，手機玩家在遊戲中需要與伺服器進行非常頻繁的資料存取，因此也需要使用能夠支援OpenStack的高IOPS讀寫效能的儲存設備，才能夠讓雲端平臺能夠順利運作。

另外，網路設計方面，採用軟體定義網路（SDN）交換器，以和OpenStack結合，未來最終極的目標就是採用軟體定義網路的方向進行雲端部署。

未來遊戲平臺將導入Docker

不過，古銘遠不光著手建置雲端平臺，未來甚至計畫積極擁抱Docker，即透過容器即服務（Container as a Service，CaaS），利用Container技術來建立雲端服務層，相較動輒要數分鐘才能啟動的虛擬機器，Docker建立Container的速度甚至只要數秒鐘。

古銘遠表示，目前將自家產品放在好玩家平臺的遊戲開發商也正在研究Container技術，未來會透過和合作廠商技術交流，在完成建置SNSplus Cloud雲端平臺與大資料平臺之後，就會逐漸將遊戲服務導向Docker應用。

對抗大規模DDoS攻擊

由於線上遊戲平臺匯集了很多玩家資訊，為確保這些資訊安全無虞，目前好玩家傳輸資料加密達256-Bit，且為了防範網路上各種大規模攻擊，也制定了自家的因應策略等。

古銘遠說，在網路攻擊中，泰國的機房也有被駭客DDoS攻擊的經驗，駭客便利用殭屍網路針對機房發動了分散式阻斷服務攻擊（DDoS），期間攻擊量達到每秒數GB以上，過程中，駭客短時間內建立了大量的網路連線，占據了許多網路資源。

古銘遠說，臺灣機房也受到DDoS攻擊，因為當時臺灣機房人員因為沒有按照公司內部DDoS處理標準化作業流程操作，才會被攻擊，也就是他們開啟了不需要對外開放的服務，因此，確保網路安全第一步就是嚴格規定工作人員必須依照操作規則進行。

在管理面向，古銘遠強調，身為公司經理人，在提出關鍵性新技術時，一定要符合公司現階段著重的營運策略與未來發展計畫，才能幫助公司發展，若只是一頭熱導入新技術，卻無法符合公司發展策略，便常常會面臨到被漠視和駁回的情況。

而一旦面臨此情況，一定要回過頭來看看自己有哪些不足的地方，再仔細檢視公司營運方向與策略，舉例來說，公司成立之初使用BI系統來了解公司內部營運狀況，但是卻無法協助遊戲開發商掌握玩家精確的遊戲使用狀態，如每一位玩家購買寶物的時間點與闖關時間等，故先向公司主管提出大資料的概念，而非著重於技術方案。

古銘遠說，由於董事長看好大資料的未來趨勢，使得建立大資料平臺，順利地成為好玩家未來主要資訊系統的建置方向。

IT人需時時重新歸零與重頭學起

因此，古銘遠建議，IT人要做到八面玲瓏，不但必須要說服工作同事接收資訊化帶來的便利性，在和主管報告時，也需要強調在資訊安全、成本投入與使用方便性上達到平衡，才能在處理IT相關事務時，做到四平八穩。「不驕傲自滿，時時重新歸零與重頭學起正是IT人的精神。」古銘遠說。

 CTO小檔案 

好玩家技術部副總經理 古銘遠

●      學歷：雲林科技大學空間設計系

●      經歷：曾進入大陸管理開發團隊，主要開發相關企業即時視訊產品，進入好玩家後，統籌企業平臺、系統、資安、開發與服務等，目前正著手利用OpenStack開發SNSplus Cloud雲端平臺及遊戲大資料平臺等。

 公司檔案 

好玩家

●      成立時間：2010年

●      網址：snsplus.com

●      董事長：何俊輝

●      總經理：伊能輝

●      地址：新北市新店區北新路三段213號6樓

●      員工人數：海內外約110人

●      直屬主管：伊能輝總經理

●      技術部門名稱：技術部

●      技術部門主管職稱：副總經理

●      技術部門人數：26人

●      技術部門分工：系統維運處、系統開發處、資訊技術處、資料分析處及美術設計處

 公司大事紀 

●      100年12月：自有品牌遊戲平臺GAMAGIC 1.0正式上線。

●      101年6月：GAMAGIC 2.0正式上線。

●      104年1月：GAMAGIC 3.0、「遊戲大數據」平臺開始開發，預期目標運行於SNSplus Cloud雲端架構，並與「遊戲大數據」平臺整合。

●      104年04月：通過經濟部工業局標竿新產品之創新應用服務研發計畫「臺灣遊戲產業進軍國際市場領航計畫」，預期將建置遊戲業第一個開放式大數據（BigData）平臺，帶領臺灣遊戲產業進軍東南亞市場。

●      104年7月：全球聯運平臺「Mymaji」正式上線。

●      104年8月：臺灣新金流平臺技術架構升級及服務轉移。

●      104年9月：SNSplus Cloud開始POC。

●      104年11月：SNSplus Cloud完成硬體部署。

●      105年03月：泰國新金流平臺技術架構升級及服務轉移