阿姆斯特丹自由大學（Vrije Universiteit Amsterdam）的漏洞安全實驗室VUSec Lab在本周指出，記憶體製造商為了解決Rowhammer攻擊而部署的緩解措施並不充份，他們發現了編號為CVE2020-10255的新一批漏洞，就算是在最新的DDR4記憶體上仍能發動Rowhammer攻擊，而且這是整個記憶體產業的問題，也波及Google Pixel 3、OnePlus 7及Samsung G970F/DS等手機。

研究人員先是在2012年發現了針對動態隨機存取記憶體（DRAM）展開的Rowhammer攻擊。記憶體是由數列的記憶元（Cell）所組成，當駭客鎖定所要攻擊的記憶體列時，只要重複造訪隔壁列的記憶元，就會造成記憶體控制電路的電壓波動，影響目標記憶體列，造成位元翻轉現象，例如1變成0或0變成1，駭客只要依照需求持續變更記憶體內的位元，最終將能造成權限擴張。

原本研究人員認為Rowhammer攻擊，只存在於PC及伺服器等效能較高的運算裝置上，但隨著手機運算效能的提升，阿姆斯特丹自由大學（Vrije Universiteit Amsterdam）的漏洞安全實驗室VUSec Lab在2016年，證實了該攻擊同樣適用於手機，在所測試的13款、27支Android手機中，成功開採了當中的18支手機，且即使是同樣型號的Android手機，也可能因記憶體品牌的不同，而有不同的結果。

為了防範Rowhammer攻擊，記憶體產業部署了統稱為「目標列刷新」（ Target Row Refresh，TRR）的各式解決方案，其基本概念是設定記憶體列的閥值，並在存取頻率超過該閥值時刷新所偵測到的目標列，也一致於新一代的DDR4上部署TRR。

然而，VUSec Lab指出，已知的各種Rowhammer攻擊手法，的確無法對部署TRR的DDR4造成影響，但他們發展了一個新的TRRespass工具，可以繞過業者的TTR修補，並成功攻陷了DDR4。

這是因為現有的Rowhammer手法最多利用兩列進行攻擊，而TRRespass的作法，則是不斷地在DRAM上的各個區域隨機存取不同列，出現太多的攻擊列令TTR不知所措，而再度成功造成了目標記憶體列的位元翻轉現象。換句話說，只要增加攻擊列的數量，TTR就可能會失效。

VUSec Lab檢驗了42款DRAM模組，以TRRespass成功攻陷了當中的13個。VUSec Lab並未公布這些DRAM模組的品牌，因為該實驗室認為這是整個記憶體產業的問題，相信前三大DRAM廠商也無法倖免於難。

此外，VUSec Lab也以TRRespass測試了13款手機，成功開採了其中的5款，包括第一代的Google Pixel 、Google Pixel  3、LG G7 ThinQ、OnePlus 7與Samsung G970F/DS。

VUSec Lab團隊已透過GitHub公布了TRRsspass的程式碼，並打算釋出相關的Android程式，以讓使用者測試自己的手機是否也面臨Rowhammer攻擊的風險。

當企業在選擇貿易夥伴、供應鏈上下游廠商，又或是銀行在授信借貸時，如何判斷合作對象的信用好壞？任何商業往來，都建立於雙方互信的基礎上，但要了解一家公司的真實情況，光是搜尋其公開的財務報表、營運資料、或爬梳網路評論，就要花費許多時間，而且，若不具調查與分析的專業，也無法做出精準的信評判斷。因此，更多企業選擇將這項任務，委託給工商徵信服務業者。

而CRIF中華徵信所（以下簡稱中華徵信所），就是臺灣歷史悠久的工商徵信業者之一，成立近一甲子的時光裡，累積了大量臺灣企業資訊，平均每年可生成來自於兩萬多家企業、共十多萬份的調查結果。近年來，中華徵信所也積極轉型為金融科技公司，尤其在2016年被併購，成了名列金融軟體全球百強的義大利CRIF集團的子公司後，更要逐步升級內部IT架構與協作文化，來加速發展徵信科技。

CRIF亞太區策略：用雲端架構維持各國IT一致姓

為了支撐徵信業務發展，中華徵信所在2004年，就開發了一套自動化徵信報告作業系統，並沿用至今。在未有系統之前，要製作一份徵信報告，需要靠作業員從無到有的打字、編排，全手動的產出調查結果，直到開發自動化系統後，才開始有了固定的欄位，讓人得以依照欄位來錄入受調查企業的基本資料、財務資料、負面訊息、訴訟記錄等，再由系統按照設定好的格式，自動匯出一份約20到30頁的徵信報告。

接著，中華徵信所也在2006年，將這套自動化系統帶進北京分公司，並根據北京在地的需求調整欄位與功能，而當年主導分公司徵信系統的建置者沈聖書，就是現在CRIF亞太區資深技術經理、同時也是亞太區IT部門最高負責人。他回憶：「當年將系統移植到中國時，仍有水土不服的問題。」比如臺灣地址欄位的縣市、鄉鎮、路段切割詳細，但中國不然，這類資料形式的差異，就需要重新調整輸入欄位來克服。

不過，這套已在臺灣使用超過15年的徵信報告作業系統，最快可能在明年走入歷史。沈聖書說明，因為CRIF從2011年起，就開始佈局亞太區市場，除了陸續在各國成立分公司，自2016年起，也先後併購了包括臺灣、印尼、越南、菲律賓等地的徵信企業，在被併購企業IT架構各自獨立的情況下，「CRIF想要把各國的徵信報告作業系統，轉換為單一的新架構。」

為了維持各國IT架構的一致性，CRIF的全球技術部門（Global Technologies）在2017年著手設計雲端徵信報告作業系統的框架（以下簡稱雲端BI平臺），並在2018年部署到新加坡的AWS資料中心、在2019年部署到阿里雲，兵分兩路進軍亞洲、中國市場。

沈聖書表示，CRIF採取雲端策略的考量，其一，是能運用同一套部署在AWS或阿里雲的雲端BI平臺，跨境服務多個國家或地區，儘管仍有國家礙於法規限制而無法上雲（如臺灣），但長期來說，將比分散各地的IT架構更容易管理；其二，則是CRIF認為，主流雲端大廠提供的雲服務，其IT架構可被信賴，具備健全性、安全性與穩定性等特質，「雖然雲端支出可能增加IT維運成本，但這是必須要走的方向。」

雲端BI架構優點多，但落地臺灣為一大挑戰

CRIF亞太區資深技術經理沈聖書表示，不只是IT需要適應開發協作，對業務部門來說，進一步參與軟體開發也將成一大挑戰。攝影／洪政偉

談到雲端BI平臺與中華徵信所舊有徵信報告作業系統的差異，沈聖書說明，最明顯分別，在於舊系統開發時間早，使用的程式語言、版本都較舊，反觀雲端BI平臺，版本仍在不斷更新，比如部署在AWS的雲端BI架構，先採用了.Net框架、微軟的關聯式資料庫，而後也在去年的新版本中，加入了搜尋引擎Elasticsearch，能針對非結構化數據進行有效率的模糊查詢，強化了雲端BI平臺的搜尋能力。

而且，舊有的徵信報告作業系統，主要提供中華徵信所內部使用，在系統生成報告後，還是需要客服人員負責將徵信報告寄給客戶。但這套雲端BI平臺，現在正在開發提供客戶端使用的功能，未來完成後，預計可以讓客戶透過對外服務的介面來登入，直接進行委託、下載報告或是查詢歷史紀錄，也能查詢是否有受調查客戶的現成報告，並以較低價直接購買。

沈聖書表示，CRIF近年來除了擁抱雲端，在產品開發上，也採取最精簡可用產品（Minimum Viable Product，MVP）的概念，要用相對低的成本開發產品，快速投放到市場上進行檢驗。同時，CRIF也開始嘗試將單一功能模組化並打包成微服務，使其成為不同解決方案都能採用的通用模組，不僅未來整合解決方案時更加容易，版本更新或升級的過程，也會變得更有效率。

不過，要真正將這套雲端BI平臺導入臺灣，「還有很多挑戰。」沈聖書說明，由於菲律賓、印尼、越南等地無法規限制，所以能順利將資料境外儲存到新加坡AWS機房；但在臺灣，若金融機構要將機敏性資料上雲，現行法令就明文規定，委外處理的客戶資料以及資料儲存地，要以我國境內為原則，若需要境外儲存，還需遵守三項配套規範，這也使得中華徵信所要轉換成雲端IT架構，格外困難。

沈聖書指出，資料搬遷計畫將在明年展開，屆時會先評估部分資料境外儲存的可行性，若仍有法規疑慮，會進一步考慮將雲端BI平臺部署到臺灣境內的Google資料中心，採用GCP作為雲端BI平臺的基礎建設，「但這又是另一個挑戰，因為GCP的框架跟AWS不太一樣，整套BI平臺需要重新搬遷部署。」

以它國經驗為參考，為明年資料搬遷工程做準備

不只臺灣子公司明年要上雲，CRIF從去年開始，已經在菲律賓據點啟動資料搬遷上雲的作業，今年上半年則輪到印尼據點、下半年預計是越南據點，這些各國據點都要改用雲端BI平臺來取代當地舊有的徵信報告作業系統。沈聖書表示，這些資料搬遷的經驗，也能作為中華徵信所未來上雲工程的參考。

「在取代舊系統的過程裡，資料的轉換是關鍵。」沈聖書說明，在資料搬遷之前，CRIF會有一組專精資料分析的人員，來分析現有資料庫與雲端資料庫結構的差異，來找出正確的對接方式，並擬定轉換計畫。而且，也因資料轉換的過程是以舊有的資料庫結構為基礎，所以資料搬遷期間內，也不能變更資料庫的架構，比如調整輸入欄位等。

沈聖書表示，資料搬遷過程中，同時也會進行資料清洗，將龐大資料庫中重複的資料刪除，比如被調查的企業中同時出現了「中華徵信所」以及「中華徵信所股份有限公司」，這兩者明顯是同一家企業，就需要比對並刪除重複資訊，而且，分散在本地端資料庫的資料，上傳到雲端後也需要合併或重新分類，「這其實非常花時間，比如印尼的資料搬遷作業，就預計要花半年。」

若以中華徵信所的系統現況來預估，沈聖書表示，「臺灣花費的時間只會更長、困難度也更高。」除了臺灣本地端的徵信報告資料量龐大，系統長期下來也串連了多種服務與資料平臺，已經不是一個獨立的系統，「所以資料移轉的時候，還要同時考慮到新的平臺能否提供相同服務。」這些都是未來進行資料搬遷的挑戰。

CRIF的敏捷協作開發方法也要移植臺灣

除了IT架構要轉換，在IT人員的協作文化上，CRIF也要在臺灣引進敏捷開發、以及兼顧安全性的協作開發流程（DevSecOps）。

沈聖書指出，中華徵信所IT部門一直以來扮演後勤單位的角色，在開發系統時，會先與業務部門確認詳細的規格與需求，接著由IT部門進行系統設計、開發，最後再由業務部門來測試，沒問題即上線，「但這種由需求方提出詳細需求，再一次由IT部門開發完才交付測試的方法，很常在測試的時候，才發現與當初設想的不一樣。」沈聖書表示。

相較之下，CRIF採用JIRA作為內部敏捷開發平臺，更重視需求方與開發方協作的過程。沈聖書表示，敏捷開發要求雙方最少每兩週要開一次會，來定期回報開發進度、確認需求，以及訂定未來兩週的階段性目標，要透過持續互動溝通，來讓最後的開發結果，更接近於實際需求情況。

而在DevSecOps方面，CRIF的標準協作流程，會經過開發、測試與生產三大環境。當IT部門在開發環境完成開發並經簡單測試後，就會進到測試環境，由提出需求的單位進行完整測試，若無問題，才會部署到生產環境正式上線，「而且在每個開發環節裡，都要考慮到安全性，也就是在DevOps中加入Sec的概念。」沈聖書說。

DevSecOps的另一個特點，則是在任何測試環節發現問題時，必須不厭其煩的回到開發環境，重新開發與測試，但隨著要修正或新增的需求增加，軟體版本也需不斷更新，為了加快軟體的部署與測試，CRIF也導入了持續整合工具Jenkins，將作業流程自動化。

沈聖書表示，中華徵信所預計在今年，將CRIF的開發方法移植臺灣，全面升級協作文化，「未來導入新協作方法後，不只是IT部門需要適應，對於業務部門來說，進一步參與軟體開發也將成為一大挑戰。」

看好開放銀行浪潮，更要取得資安認證成為TSP業者

隨著臺灣開放銀行邁入第二階段、法規日漸完善，中華徵信所也想要搭上這一波開放銀浪潮，成為TSP業者來創新徵信服務。就像CRIF歐洲有項服務就是，取得顧客授權後，以API串接顧客在各銀行的帳戶資訊與交易記錄，自動算出信評分數後，再提供給銀行來加速借貸申請的審核。為了將解決方案引進臺灣，中華徵信所的IT部門也計畫盡快取得資安標準的認證，來爭取成為臺灣開放銀行的合作夥伴。

CIO小檔案

沈聖書

CRIF亞太區資深技術經理

學歷：中央大學地球物理所碩士

經歷：2000年開始在喜瑪拉雅研究發展基金會擔任助理研究員，而後任職於非營利組織發展中心。在2006年加入中華徵信所，赴北京擔任技術長一職長達10年，並在2016年CRIF集團收購中華徵信所之後，擔任亞太區資深技術經理至今，同時也是亞太區IT部門最高負責人。

公司檔案

CRIF中華徵信所

● 成立時間：1961年1月18日

● 網址：www.credit.com.tw

● 地址：台北市信義區東興路57號5樓

● 員工人數：90人

● 主要業務：企業商業徵信、企方位企業資料庫、風險管理、金融科技解決方案

● 董事長：Vincenzo Resta 雷斯塔

● 總經理：郭曉薇

● 資本額：3億4千萬元

資訊部門檔案

● CRIF亞太區IT最高負責人：沈聖書

● CRIF中華徵信所資訊部門主管：高文川

● CRIF中華徵信所資訊部門人數：7人

IT大事紀

● 2004年：徵信報告作業系統自動化

● 2006年：開發北京分公司的徵信報告作業系統

● 2012年：開發與上線ERP系統

● 2015年：MMD監控服務平臺上線

● 2016年：為CRIF所併購

● 2017年：CRIF在新加坡建立雲端數據中心，並設計AWS雲端徵信報告作業平臺的框架。（簡稱雲端BI平臺）

● 2018年：成立GT（CRIF Global Technologies）亞太分部。

● 2019年：與中國廣東企業合作，將雲端BI平臺部署到阿里雲服務；將菲律賓本地端的徵信報告作業系統移轉到AWS雲端BI平臺

● 2020年：預計在臺灣導入CRIF的敏捷開發流程、DevSecOps開發流程；將印尼與越南本地端的徵信報告作業系統移轉到AWS雲端BI平臺

現代程式語言大多具備垃圾收集機制，若想確切地知道運作方式，可從實作C++智慧指標（smart pointer）開始著手，這也有助於理解各種垃圾收集演算法的優缺點，以及必要時能夠選擇適當的垃圾收集器。

以堆疊來包裹堆積

想理解程式語言的垃圾收集機制，往往就會涉及堆疊（stack）、堆積（heap）的說明，大部份文件會以資源是否動態配置，來區別這兩個存放位置，但實際的差異是在於資源生命週期的不同。

因為，函式執行結束時，堆疊必須為空，因此存放在堆疊的資源，我們可以理解為，其生命週期局限於函式執行期間，然而，有些資源無法預期其使用的生命週期，這類資源會存放在堆積，正因為位於堆積的資源無法預期生命週期，才必須在不使用的時候自行清除。

問題就在於「無法預期」。因為程式運行後，資源之間的互用關係錯綜複雜，開發者也很難掌握哪些資源還在使用，而哪些是已經沒人要的垃圾，這時，就會希望有個類似生活中資源回收業者之類的程式，可以代為判斷是否為垃圾，並予以清除。

但C++沒有垃圾收集機制，該怎麼辦呢？實際上，有些開發者自以為無法預期生命週期的資源，原因就只是懶得想罷了。

例如，函式中若需要動態配置連續空間來當成陣列使用，在函式結束前，我們就要用delete[]刪除，只是有時會忘了這件事，此時，我們如果可以設計一個會在函式結束前刪除資源的類別，就不會因為忽略而造成資源沒有回收。

什麼樣的資源會自動在函式執行後結束生命週期呢？就是哪些放在堆疊的資源，如果可以用堆疊的資源，也就是函式的區域物件來包裹堆積的資源，一旦堆疊資源結束生命週期時，就去刪除堆積資源，這件事就解決了，而C++可以透過定義包裹器的解構器（destructor）來做這件事。

如果包裹器各自只管理一份資源，就沒有其他問題了，然而在現實程式中是不可能的。因為，一份資源可能被指定給多個物件，這時包裹器該如何共享資源，就決定了包裹器的複製建構式、指定運算子與解構式怎麼寫了。

C++智慧指標

在C++ 98有auto_ptr類別，雖然現在已經廢棄，不過實作上最簡單（可參考〈auto_ptr〉）。

auto_ptr被用來建構另一auto_ptr實例時，來源實例包裹的資源會被接管，將auto_ptr指定給另一auto_ptr時，目標實例包裹的資源會被刪除，並接管來源實例的資源，因此，在解構式中，我們只要檢查資源是不是nullptr，若結果為否，就delete資源。

事實上，auto_ptr被廢棄的原因在於，接管資源的動作是隱含的，開發者容易忽略了資源被接管，而持續使用沒有包裹任何資源的auto_ptr。另一個問題是，它無法管理動態配置的連續空間，因為不會使用delete[]來刪除。

因此解決問題的方式之一就是，不允許複製建構與複製指定，如果真的要轉移資源，必須透過的明確語義的方法來釋放、重置資源。而對於第二個問題的因應，我們可以讓使用者指定刪除器，自行決定怎麼刪除資源，這個概念在C++ 11中的實作品是unique_ptr（想看看實作原理可參考〈unique_ptr〉），因為轉移資源意謂著資源是不能共享的，一旦unique_ptr呼叫了release，在還沒有用reset重置管理的資源前，是不能透過unique_ptr來試圖操作資源。

不過，現實程式中有更多情況會需要共享資源，而一旦資源被共享，情況就會變得複雜許多。因此，最基本的考量就是：還有誰使用著被管理的資源呢？

在C++ 11當中，有shared_ptr使用參考計數，如果資源被複製建構或指定，參考計數增一，若某個auto_ptr解構時，參考計數就減一；如果auto_ptr解構時，發現參考計數為零，就表示沒有其他地方使用這份資源了，此時，可以直接刪除（想看看實作原理可參考〈shared_ptr〉）。

unique_ptr、shared_ptr被稱為智慧指標，然而，從實作上就可以知道，它們並不是指標，而是行為上具有指標行為的指標包裹器。具體而言，它們就是重載了*、->運算子的類別，對於沒有重載對應運算子的指標行為，例如+、++、-、--等，就不會支援，若真要進行這類操作，必須透過get取得管理的指標直接操作。

垃圾收集器

shared_ptr的好處是，資源在不使用的時候就會被刪除。然而，若資源的刪除也有其成本，以及開發者希望資源的刪除不是參考計數為零時，而是在某個時間點，例如，使用者沒在操作應用程式時再來檢查與清除。

那麼，該如何處理這種情況？我們可以設計一個資源清單（list），專門用來記錄資源的參考計數，當資源的包裹器被複製建構或指定，而需要增加參考計數時，我們可透過使用資源的記憶位址來查找資源清單，處理對應的參考計數。

當資源的包裹器解構時，清單中對應的參考計數會減一，若參考計數為零，並不會馬上刪除資源，而是在某個時間點，呼叫collect之類的方法。基於這樣的做法，我們會逐一取得資源清單中的參考計數，若某個資源的參考計數為零，從清單中移除並刪除該資源，這就是垃圾收集的相關文件中，所談到的基本垃圾收集器原理。在《The Art of C++》第二章，有個簡單的垃圾收集器，就是基於參考計數的實作，有興趣可以參考。

然而，shared_ptr有個問題，在shared_ptr實例間不小心形成環狀下，會因為參考計數計算錯誤，而令資源明明不再使用，參考計數卻不為零而未被刪除。想解決這個問題的方式之一，是透過C++ 11提供的weak_ptr──當shared_ptr實例用來建構weak_ptr實例，或指定給weak_ptr時，動態配置資源的參考計數並不會增加，因此，形成環狀也就不會造成參考計數的錯誤（可參考〈weak_ptr〉。

至於垃圾收集器這邊，就有其他的方案了，像是標記／清除、節點複製、分代收集等，現代程式語言可能結合了多個方案，例如，Python使用了參考計數，並輔以標記／清除、分代搜尋等，如果確定資源不會形成環狀，還可以透過gc模組的disable停用垃圾收集器。

思考資源的使用方式

若開發者使用C++，有興趣的話，可以自行實作shared_ptr等智慧指標，對於資源如何釋放這件事，就會有更多的認識，在運用到動態配置資源時，也就會有多個機會思考，設想這些資源的生命週期與使用情境，從而決定該選用哪個智慧指標。而這就像在生活當中，將一切棄置用品訴諸資源回收業者前，消費者自身還是要作好基本的分類。

試著自行實作個簡單的垃圾收集器，也是個有趣的挑戰，這有助於我們理解標記／清除、節點複製、分代收集等方案的優缺點。有些語言允許開發者操作或選擇垃圾收集器，這時，對於相關演算的認識就很重要了，重要的是回頭思考資源的使用方式，而不是將一切都交給垃圾收集器就沒事了。

位於京都的新創公司DataGrid，持續研發將創意人的工作交給人工智慧的「創意人工智慧」。該公司提出未來全新的人工智慧運用方式，研發出能「生成」偶像臉孔的人工智慧，作為一項「創意人工智慧」。

DataGrid社長岡田侑貴說明，「講到以往的人工智慧，幾乎都用來辨識、預測，很少看到創作的人工智慧。DataGrid希望藉由讓人工智慧做創意人的工作，刺激創意人的想像力，打造一個人類與人工智慧共同創作的社會。公司裡的十一名員工全都具備機器學習的專業背景，在學術上也與大學展開共同研究。另外，商業面上用創意人工智慧的成果，建立起能夠授權企業的商業模式。」

以深度學習來辨識偶像的特徵

DataGrid打造能自動生成偶像臉孔的創意型人工智慧應用。

二○一八年六月，該公司宣布研發創意人工智慧的應用軟體「偶像自動生成AI」。這項作業的概要，是讓運用深度學習的人工智慧以幾萬張偶像大頭照來學習，使人工智慧辨識出偶像的特徵。藉由學習了偶像臉孔特徵的人工智慧，來生成虛擬的偶像臉孔。因為有無限多變化，可以創造出擁有「偶像臉孔特徵」的人臉。

在具體的手法上，使用的是「生成對抗網路」（Generative Adversarial Network，GAN）。生成對抗網路是一種非監督式學習模型，從不給予正確答案的學習資料中，推導出結構和規則，並「生成」影像等成果。其中一個網路是試圖接近從給予的學習資料所獲得的資訊，另一個是判別真偽的網路，藉由兩者在互相對抗之下各自提高準確率，提高要求的影像等生成物的品質，因此以「對抗」為名。

岡田建立使用生成對抗網路的人工智慧模型，成功將偶像臉孔特徵做出頸部以上的高解析度（1024×1024）影像，但研發過程中面臨意想不到的狀況。「一開始使用偶像臉孔的影像來學習時，雖說看得出是臉部，但生成的大多是輪廓不完整的怪臉孔。其中一個原因是起初的資料量比較少，大概只有五千筆。另一方面，偶像的大頭照形形色色，有些影像中配戴了髮飾，或者比出勝利手勢，還有臉轉向側面的，因此有時頭髮上出現莫名其妙的圖案。最後增加了幾萬筆學習資料，在資料上有絕對的優勢，不過我深深體會到針對資料進行預處理，修正為適合學習的型態，這一點非常重要。」（岡田）

有了資料的預處理，加上自由度高的學習模型最佳化，並且有後處理（posttreatment）的機制，評估生成的影像，只留下好的顯示為成果。費盡心思，終於完成了偶像自動生成AI。

經過一番努力研發出的偶像自動生成AI，現階段還沒有明確的用途。岡田說明，不只是目前的「臉孔」，希望能用人工智慧來生成動態的虛擬偶像「全身」。這麼一來，在很多情境下都能以虛擬偶像來替代真人上場。「出現在電視廣告中的人物或電商服飾模特兒，未必一定得是真人。如果能用人工智慧模特兒來替代真人藝人，想降低成本的廣告或電商網站就能使用虛擬人物。」（岡田）即使因為成本而無法採用真人，生成高解析度且幾近真實的人物影像，同樣帶來新的創意。

生成「擬真影像」的技術有什麼用處？

使用生成對抗網路生成新資料的人工智慧，可說是DataGrid的核心技術。換言之，DataGrid的業務不只是偶像自動生成。

另一個接近偶像自動生成的領域是「內容（contents）自動生成」。運用生成對抗網路，以動畫人物或電玩遊戲中使用的地下迷宮（dungeon）作為學習資料建立模型，生成前所未有的「具備動畫人物特徵的影像」或「具備電玩遊戲地下迷宮特徵的圖形」。如果有效運用這類人工智慧，就不必像現在人工作業繪製一個個動畫人物，只要用生成對抗網路一次生成多個人物，然後「挑選」出來。

比方說，使用能生成無數個人物的特徵，在電玩遊戲中針對每個玩家有不同的客製化人物。事實上，經營線上電玩遊戲的Aeria便投資了DataGrid，共同推動以人工智慧生成人物影像的專案。目前除了規畫提供利用這項技術的電玩遊戲，未來還預計發展出讓人工智慧辨識玩家喜好並配合生成遊戲人物。

不只生成影像，還能應用於加工。「把照片變成梵谷名畫」之類廣受歡迎的手機應用程式，很容易建立影像濾鏡功能，根據某些特徵來改變圖像。除此之外，要提高畫質粗劣的影像的解析度，「超解析」（super-resolution）、「降噪」之類影像處理也能有效使用生成對抗網路，目前仍持續研究開發。超解析必須生成原本非以數據存在的畫素資訊，但這種「擬真創作補足」正是生成對抗網路最擅長的領域，「成功實現了比以往超解析更漂亮的超解析影像。」（岡田）降噪方面的成果同樣效果顯著，未來可望應用在影像和照片的數位修復作業或博物館。

第三個解決方案是「學習用資料的自動生成」。想在業務上運用人工智慧，想用深度學習打造模型，雖然有這樣的期望，卻礙於收集不到學習用的資料或數量太少，這些情況尋常可見。例如偵測異常的人工智慧，即使有大量正常的影像，通常顯示異常的影像很少。這時可以運用生成對抗網路，生成各種「具備異常特徵的影像」，以這種方式來增加學習用的資料。

「如果能把一百筆資料增加到一萬筆的各種變化，深度學習的準確率大幅提高。工廠內的異常影像、產品品管檢查時發現缺失的影像、行車紀錄器拍到汽車前方有人或動物衝出來的影像等，這些希望借助運用人工智慧的異常影像數量都很少。若以生成對抗網路生成的資料來補充，將有助於建立準確率高的人工智慧模型。」（岡田）

藉由DataGrid研發的人工智慧，能夠以各種形式「無中生有」。DataGrid和面對課題的夥伴企業共同運用這些功能。岡田表示，「到頭來，人工智慧單打獨鬥什麼事都做不了，重要的是『人工智慧×未知的X』。然而，要靠自己來打造X，工程太浩大。因此，我們希望與已經擁有X的其他公司合作，繼續推動創意人工智慧的實用化。」他非常看好創意人工智慧的未來。（摘錄整理自本書case 31）

 書名 深度學習的商戰必修課：走在時代尖端的日本企業如何活用AI

日經xTREND／著；日本深度學習協會／監修；葉韋利／譯

臉譜出版

售價：420元

 作者簡介 

日經xTREND

新興市場創業人的數位策略媒體。針對正在開發企業新業務、致力行銷相關業務者，提供行銷、消費、技術、資料、創新等領域的最新相關實務資訊。

等待了近1年時間後，Pure Storage的雲端區塊儲存服務——Cloud Block Store（CBS），終於在去年底（2019）正式上線。

過去一年多以來，Pure Storage在整合公有雲平臺方面動作連連，於2018年底宣布了稱作「Pure Storage Cloud Data Services」的一系列雲端儲存服務，而CBS便是其中之一。

CBS是當前興起中的新類型儲存產品——「雲端儲存陣列」的一員。這種產品的本質，其實就是傳統儲存陣列廠商將其儲存陣列系統移植到公有雲上，成為「雲端化」儲存陣列而成，透過公有雲平臺來提供儲存空間服務。

而CBS便是Pure Storage將旗下的FlashArray全快閃儲存陣列，移植到AWS公有雲平臺上的產品，可在AWS上提供基於iSCSI的區塊儲存空間服務，目前有10TB、20TB與50TB等3種容量授權可選，並憑藉著與FlashArray儲存陣列相同的Purity//FA儲存作業系統，具備了Thin Provisioning、壓縮與重複資料刪除等進階功能。

目前CBS雖然只支援AWS平臺，但依照Pure Storage的規畫，日後也將在Azure與Google Cloud上推出相同的服務。

CBS是Pure Storage FlashArray全快閃儲存陣列，移植到AWS而成的雲端化儲存陣列，可在AWS上提供基於Pure Storage儲存系統的區塊儲存服務，並含有完整的資料服務功能。

雲端化的儲存陣列

公有雲服務的盛行已是大勢所趨，傳統儲存陣列廠商面對這個新興威脅，一個出路便是「打不過他，就加入他」，把自身的儲存陣列平臺移植到公有雲平臺上。

公有雲服務商雖然自身提供了原生的儲存服務，但老牌的儲存陣列平臺，有著用戶熟悉、系統成熟、資料服務功能豐富完整的優點，而移植到公有雲以後，不僅保有儲存陣列原本的優點，還能兼有雲端服務的維運負擔輕、按需訂購彈性等優點。

以CBS來說，相較於AWS自身原生的兩種區塊儲存服務——執行個體儲存空間（Instance Stores），以及EBS（Elastic Block Store），目的同樣都是提供區塊儲存服務，但能提供後兩者沒有的豐富資料服務功能。

AWS執行個體儲存空間，是一種執行個體直連的本地端儲存空間，有硬碟、SAS SSD與NVMe SSD等型式，具備低延遲的特點，但組態固定，缺乏彈性，也沒有因應磁碟裝置故障的冗餘能力。

至於EBS儲存區，則有著類型選擇豐富（有io1、gp2、st1與sc1等4種）、組態彈性（500GB～16TB），以及透過分散複制機制所提供的高可用性，還具備基本的資料服務功能（快照與加密）。

而CBS實際上是建立在前兩者的基礎上——以EBS的io1儲存區作為NVRAM寫入緩衝角色，以執行個體本機的NVMe SSD作為讀取快取與寫入儲存區，再結合S3物件儲存作為備援的持久儲存區，並能透過Pure Storage的ActiveCluster複製功能，跨不同AWS可用區域（AZ）建立異地的高可用性CBS群組，兼具了效能與可靠性。

更重要的是，CBS還能憑藉Pure Storage自身專屬的Purity//FA儲存平臺，提供目前AWS原生儲存服務還沒有的即時壓縮、重複資料刪除等資料縮減功能，藉此改善儲存空間耗用經濟性。

因此CBS這類雲端儲存陣列產品的問世，也讓用戶在公有雲上的應用，除了使用各公有雲自身原生的儲存服務外，也多了Pure Storage這些第三方廠商的解決方案，各自基於專屬儲存平臺，提供了公有雲儲存服務新選擇。

獨具一格的雲端部署架構

如前所述，CBS這類雲端儲存陣列產品，是將傳統儲存陣列平臺移植到公有雲環境而成，從而為公有雲上的運算單元，提供基於傳統儲存陣列平臺的儲存空間服務。而要實現這樣的目的，關鍵便在於如何讓傳統儲存陣列平臺「移植」部署到雲端環境，從而化身為公有雲上的儲存服務。

將儲存陣列移植到公有雲上的方式，主要分為兩種。一種方式為實體部署，也就是在公有雲服務商資料中心部署實體儲存設備。例如NetApp的Cloud Volumes Service（CVS）、HPE的Cloud Volumes，都屬於這種類型。

另一種方式為軟體定義部署，也就是利用公有雲的執行個體與儲存空間，來運行儲存陣列系統軟體。如NetApp的Cloud Volumes ONTAP（CVO）、Dell EMC的UnityVSA Cloud Edition，以及我們這裡介紹的Pure Storage CBS，都屬於這種類型。

不過，即使同樣屬於軟體定義部署，但個別產品的實作方式也大相逕庭，而CBS可說是最特別的一種。

NetApp CVO算是軟體定義部署式雲端儲存陣列的標準範本，使用1臺雲端運算單元來運行NetApp的ONTAP系統，擔任儲存控制器角色，並掛載公有雲的區塊儲存區來作為儲存空間。為了提高可用性，還可將2臺CVO組成高可用性群組。

而CBS則動用了AWS的EC2執行個體、執行個體本機儲存區、EBS區塊儲存區，以及S3物件儲存區，來扮演儲存控制器、寫入緩衝、讀取快取等角色，每套CBS單元至少需耗用9臺或16臺執行個體（2臺用於控制器，7或14臺用於虛擬磁碟）、7個EBS服務的區塊磁碟區，與一定容量的S3儲存區。

雖然CBS耗用的資源相對較大，成本相對也較高，但藉此在AWS上再現了FlashArray全快閃儲存陣列的架構，理應更能保證效能與可用性，以因應Tier1的關鍵應用儲存需求。

靈活的混合雲應用方式

CBS這類雲端儲存陣列，除了能為公有雲的儲存服務，提供基於第3方儲存廠商平臺的新選擇外，另一個重點是能結合用戶的本地端儲存設備，構成高度整合的混合雲架構。

以CBS來說，便能與用戶本地端的FlashArray儲存陣列，構成緊密的混合雲應用架構。CBS與FlashArray的核心，同樣都是基於Purity//FA作業系統，因此可以相互連結，構成異地備援，在儲存服務這一層級，直接透過磁碟區的遠端複製，在本地端FlashArray與雲端的CBS之間，交換或遷移資料。

另外，CBS也能結合Pure Storage的CloudSnap雲端快照儲存服務，提供經濟的混合雲應用。用戶平時可將本地端FlashArray的資料。透過CloudSnap上傳到S3儲存空間保存，待需要異地備援時，再訂購與啟用CBS，然後於CBS上掛載CloudSnap在S3保存的本地端FlashArray快照，便能迅速完成CBS與本地端間的站點資料同步。

 Cloud Block Store的版本與規格 

在AWS環境中運行的CBS雲端儲存陣列，是以AWS的資源架構而成，分別使用EC2的c5n與i3執行個體，以及EBS的io1區塊儲存區，來分別扮演儲存控制器、Flash儲存模組、讀取快取，以及NVRAM模組等角色。

Pure Storage提出了兩種CBS組成規格——CBS //V10A-R1與CBS //V20A-R1，分別採用不同等級的EC2執行個體與EBS io1儲存區。

其中較低階的CBS //V10A-R1，Pure Storage建議使用2臺c5n.9xlarge執行個體來作為儲存控制器，搭配作為虛擬磁碟機的7或14臺i3.2xlarge執行個體，再加上作為NVRAM的7個60GB EBS io1磁碟區。其中，作為控制器的c5n.9xlarge執行個體，可提供50Gbps的總網路頻寬，每個連接埠的頻寬為5Gbps，整個系統則可提供13.8TB～15.2TB的可用容量。

至於較高階的CBS //V20A-R1，控制器是使用2臺規格更高的c5n.18xlarge執行個體來擔任，搭配作為虛擬磁碟機的7或14臺i3.4xlarge執行個體，或是7臺i3.8xlarge執行個體，加上作為NVRAM的7個120GB EBS io1磁碟區。其中，作為控制器的c5n.18xlarge執行個體，可提供100Gbps的總網路頻寬，每個連接埠的頻寬為5Gbps，整個系統能提供55.2TB～60.8TB的可用容量。

CBS使用的執行個體規格

Pure Storage建議用於扮演CBS儲存控制器角色的兩種執行個體——c5n.9xlarge與c5n.18xlarge，都屬於c5n系列運算優化型執行個體，是EC2服務中針對HPC、資料湖等應用，特別強調運算能力與網路傳輸頻寬的執行個體，基於3 GHz的Intel Xeon Platinum 處理器，分別可提供36個與72個vCPU、96GB與192GB記憶體，以及50Gbps與100Gbps傳輸頻寬，可保證CBS的I/O效能，並因應資料刪減相關功能帶來的運算負荷。

而CBS用於擔任虛擬磁碟機角色的3種執行個體——i3.2xlarge、i3.4xlarge與i3.8xlarge，則屬於i3系列儲存優化執行個體，特別強調本機儲存能力，均配置了直連的NVMe SSD，但處理器規格與網路頻寬相對較低（10Gbps以下） 。

另外Pure Storage還建議，用戶在訂購供CBS使用的執行個體時（包含控制器與虛擬磁碟），選用可轉換型式的預留執行個體（Convertible Reserve Instance），而非標準預留執行個體（Standard Reserve Instance），以便運用可轉換預留執行個體便於變更屬性的特性，在日後升級為更高階的執行個體。

 Cloud Block Store的訂閱形式 

如同多數的公有雲服務產品，CBS的訂購方式，也分為公有雲服務商與儲存廠商等兩個來源。

「Pure as-a-Service」服務是一種混合雲的授權，在「Pure Storage ES2」採購項目下，提供了在1年（以上）合約期限內，100TB容量起跳的混合雲使用空間授權（雲端CBS＋本地端FlashArray），用戶從這裡取得CBS的授權後，再到AWS市集中的「Cloud Block Store - Product Deployment」訂閱項目下完成部署。

更單純的方式，是直接從AWS的市集訂閱CBS服務，先在「Cloud Block Store」訂閱項目下，購買使用空間授權，然後再到「Cloud Block Store - Product Deployment」項目下完成部署。

AWS提供了4種等級的CBS授權——Small、Medium、Large與按使用量計價的Pay-as-you-go。其中Small等級授權的預留容量上限是10TB，Medium等級是20TB，Large等級為50TB，訂閱期限有1個月或12個月兩種可選。

比較特別的是Pay-as-you-go授權，適合想要體驗CBS的用戶，這種模式不需要一次購買定量的空間，頭1個月10TB內不收取費用，從第2個月起，再按每單位每GB來計價，訂閱期限以1個月為基準。

除了前述4種等級的容量授權費用外，CBS還有基本設定費（Basic Setup）、超過預留容量上限的超量（Overage） 使用費，以及加值服務費（Professional services）等額外費用。

其中，加值服務是一系列幫助用戶部署CBS的諮詢與協助服務，包含初期的需求評估、部署前準備、部署作業執行、部署後作業等服務，同時，又分為基本加值服務（Basic Professional services），以及進階加值服務（Advanced Professional services），而前述的基本設定（Basic Setup）費用所對應的部份，就等於這裡所提及的基本加值服務。

Cloud Block Store 的採購模式

用戶可透過Pure Storage的「Pure as-a-Service」服務，或直接從AWS市集訂閱CBS的授權，前者可提供較長的訂閱期限（1～3年），後者則提供較靈活的按月訂閱與1年期訂閱。圖片來源／Pure Storage

Cloud Block Store 的採購層級

CBS的授權以容量作為層級區分基準，分為Small（10TB）、Medium（20TB）與Large（50TB），再加上按使用量計價的Pay-as-you-go等4種層級。圖片來源／AWS

 Cloud Block Store系統管理與軟體功能 

由於CBS是FlashArray儲存陣列移植AWS的「雲端化」版本，核心相同，所以，系統管理方式與軟體功能，基本上，也是與Pure Storage自家的FlashArray儲存陣列相同。

在系統管理方面，如同本地端的FlashArray儲存陣列，CBS也是透過自身內含的網頁控制臺，來進行基本的監控與設定作業，管理介面與FlashArray完全一致。除此之外，用戶還能利用Pure Storage的Pure 1雲端AI管理平臺來管理CBS，包括從雲端集中監控CBS的運行，以及使用Pure 1的效能分析、資源耗用預測等功能，來檢核與預估CBS系統的使用情況。

在軟體方面，CBS運行的是FlashArray的作業系統Purity//FA的修改版本，僅有核心的部份稍微不同，同時，也擁有FlashArray幾乎全部的軟體功能，只有下列2項不提供——Purity//RUN與Windows File Services（WFS）。

其中的Purity//RUN是一項輕量的虛擬化功能，可以透過Container或VM的形式，使用部份控制器處理器與記憶體資源來執行用戶需要的應用功能。而WFS則是架構在Purity//RUN上的服務，可以運行CIFS/SMB與NFS等檔案服務，讓FlashArray扮演NAS的角色。

由於目前Pure Storage將CBS定位於專門提供區塊儲存服務（從產品名稱即清楚表明），因而不提供前述兩項附加功能。

CBS的網頁控制臺

如同本地端的FlashArray儲存陣列，雲端上的CBS也提供了相同的網頁式控制臺，管理者可藉此執行基本的系統管理與設定工作，包括磁碟區設定、磁碟區掛載、系統運行監控等基本管理功能，以及快照、遠端複製等進階資料服務功能，無論操作介面還是操作方式，都與FlashArray儲存陣列的網頁控制臺一致。

透過Pure 1雲端平臺管理CBS

用戶也能透過Pure Storage的Pure 1雲端AI管理平臺，從遠端監控CBS的運行，並使用效能分析、資源耗用預測等功能。圖片來源／Pure Storage

 Cloud Block Store的運作架構 

我們可將CBS這款產品，視為Pure Storage將FlashArray快閃儲存陣列，移植到AWS平臺的「雲端化」版本。

FlashArray儲存陣列的軟體，是以Pure Storage專屬的Purity//FA儲存作業系統為核心；硬體部份，則由內含控制器、NVRAM與Flash儲存模組的Base機箱，加上外接的擴充儲存櫃組成。每臺FlashArray儲存陣列，含有這4種主要元件：

● 控制器：負責運行Purity//FA儲存作業系統，以及提供前、後端I/O介面，每臺Base機箱含有2組控制器，構成Active—Standby的高可用性架構。

● NVRAM模組：NVRAM模組由DRAM、備份用Flash模組與供電用的超級電容組成，目的是為寫入I/O提供一個高效能、且能預防斷電的緩衝儲存區。每臺Base機箱最多可以安裝4組NVRAM模組，並且以互為備援的方式，透過NVMe介面兩兩配置給2組控制器使用。

● 讀取快取記憶體：FlashArray陣列的讀取快取記憶體可分為兩種——控制器內含的DRAM，以及控制器外的DMM模組。受限於容量與成本，控制器內含的DRAM，主要用於metadata的讀取快取，至於一般資料的讀取I/O，則主要是直接從底層的Flash儲存模組來讀取，因此也導致較大的延遲。

不過，Pure Storage在2019年9月，推出基於Intel Optane儲存級記憶體的DMM模組（DirectMemory Modules），專用於讀取I/O的快取，安裝在Flash模組磁碟槽中，配置給控制器使用，藉此可讓讀取延遲獲得5倍的改善，但目前只有少數FlashArray//X系列支援DMM模組。

● Flash儲存模組：包括SAS介面的SSD，或NVMe介面的DFM模組（DirectFlash Modules）兩種，以10個模組的10 module pack為基本單位。

而到了CBS，Pure Storage為了在AWS環境，「重現」FlashArray儲存陣列的架構及系統功能，使用AWS EC2、EBS與S3的資源，組成CBS的「控制器」與「虛擬磁碟機」等2種元件，進而扮演儲存控制器、NVRAM、讀取快取與Flash儲存模組等角色。

CBS的控制器

CBS使用2臺AWS EC2 c5n執行個體，來擔任FlashArray儲存陣列的兩組控制器角色。每臺c5n擁有總頻寬50Gbps或100Gbps的網路介面，可兼用於系統管理或iSCSI傳輸連接。

CBS的虛擬磁碟

CBS使用獨立的AWS EC2的i3執行個體，以此構成了稱作「虛擬磁碟機（Virtual Drive）」的儲存單元，並同時扮演了Flash儲存模組、NVRAM模組與讀取快取記憶體等3個角色，這種充當虛擬磁碟機的i3執行個體，後端都掛載了3種儲存裝置：

（1）i3執行個體內含直連的1～3臺NVMe SSD本機磁碟。

（2）EBS區塊儲存服務掛載的io1磁碟區。

（3）S3物件儲存區（標準型）。

i3執行個體直連的NVMe SSD，擁有低延遲與高頻寬，被CBS用於讀取快取記憶體，以及寫入資料的儲存區等兩種角色。不過，這屬於沒有冗餘能力的Instance Store空間，可靠性不足，對於讀取快取角色來說，即使失效，也只會損及讀取效能而已，但若做為資料寫入儲存區，一旦失效，便會影響資料的完整性。因此，CBS為虛擬磁碟提供多重冗餘的保護。

至於用於承接寫入I/O的NVRAM角色，CBS使用EBS區塊儲存服務的io1儲存區來承擔。io1是EBS的高效能型SSD儲存服務，擁有EBS的高可用性架構，足以扛起NVRAM的重責大任。

而S3物件儲存空間，則被CBS用作資料寫入資料的備援用保存區。當虛擬磁碟正常運作時，所有讀寫I/O都是在虛擬磁碟這一層級完成，但若虛擬磁碟完全失效，用戶可從S3儲存區取回資料。S3的低成本與極高耐久性，十分適合作為持久儲存區使用。而且S3是獨立的空間，即使CBS控制器與虛擬磁碟完全失效，也不會影響S3儲存區資料，提供了最後一層的保障。

CBS的運作與保護機制

運作時，作為虛擬磁碟機的i3執行個體，分別透過EBS io1儲存區與本機NVMe SSD，扮演寫入緩衝與讀取快取角色，寫入資料則由NVMe SSD保存，同時虛擬磁碟還會將寫入資料複製一份，送到最後端的S3物件儲存區，作為備援保存之用。

為了提高整個架構的可用性，CBS各個環節都採用了多重配置。在儲存控制器層級，採用雙控制器組態，單一控制器失效不會影響CBS服務；在虛擬磁碟機層級，CBS基本組態使用7臺i3執行個體，也就是7臺虛擬磁碟機，構成具備失效冗餘能力的虛擬儲存櫃（Virtual Shelf），在作為控制器的c5n執行個體管理下，任何擔任虛擬磁碟機的i3執行個體失效，可由群組中其他i3執行個體備援，而整個群組的冗餘能力，可容許2臺虛擬磁碟機（i3執行個體）失效。CBS最大能組成含有14臺虛擬磁碟機的儲存群組，但其中只有前7臺虛擬磁碟機，會掛載作為NVRAM的io1儲存區。

更進一步，即使有3臺以上的虛擬磁碟失效，導致CBS服務終止，用戶也還能從後端的S3儲存區取回資料。

如果用戶需要更高的可用性，還可在兩個以上AZ服務區建立CBS，再利用ActiveCluster功能同步資料，達到兩地雙中心的高可用性架構。同時，他們也可透過非同步複製，將第二地AZ作為異地備援中心。

Cloud Block Store vs. FlashArray儲存陣列架構對照

CBS使用了AWS的EC2、EBS與S3等雲端服務資源，於AWS環境「重構」出FlashArray全快閃儲存陣列的架構與功能。首先，由2臺EC2的c5n執行個體，扮演FlashArray陣列的雙控制器角色；接著，以EC2 i3執行個體構成虛擬磁碟機（Virtual Drive），由7臺虛擬磁碟機組成具備冗餘能力的虛擬儲存櫃（Virtual Shelf），可容許2臺虛擬磁碟失效。而這些虛擬磁碟機單元還連接了EBS io1儲存區與本機NVMe SSD，分別用於NVRAM寫入緩衝區、讀取快取記憶體與資料寫入儲存區。

產品資訊［規格與售價時有異動，正確資訊請洽廠商］

Pure Storage CBS

●原廠：Pure Storage

●建議售價：Small級（10TB，每月1800美元，每年18000美元），Medium級（20TB，每月3000美元，每年30000美元），Large級（50TB，每月6000美元，每年60000美元），Pay-as-you-go（首月10TB內免費，自第2個月起，每單元、每月、每GB 0.2美元）

●適用平臺：AWS

●支援傳輸協定：iSCSI

根據Business Insider的報導，Google繼於日前發出郵件，建議所有北美地區的員工儘可能地在家上班之後，再度指示英國、歐洲、中東與非洲地區的Google員工，從本周四（3/12）起在家工作。

Google對武漢肺炎疫情採取非常謹慎的態度，先前愛爾蘭一名員工才出現類似武漢肺炎的流感症狀，Google就要求當地的8千名員工測試在家上班的可能性。這可能是因為更早之前，Google瑞士辦公室的一名員工，已被確診罹患武漢肺炎。

本周CNBC則報導，另一名位於印度的Google員工也已確診並正被隔離中。

Google執行長Sundar Pichai日前即曾透過Twitter呼籲，如果可以的話應該要與群眾保持距離，以避免群聚散布，此舉將有助於減輕醫療照護系統的負擔，讓他們服務其他有需要的人。

有報導指出，Google利用和智慧電視廠商的Android授權條款，限制使用分支版Android，企圖封鎖Amazon FireOS進入這塊市場。

科技部落格Protocol周四引述不願具名的廠商報導，智慧電視廠商找Google尋求Android授權時，Google的授權合約中包含「Android相容性」（Android Compatibility Commitment）章節，要求廠商不得在智慧電視產品內使用分支（fork）版本Android。一旦廠商違反這項條款，廠商所有產品就喪失存取Play Store及Google服務，像是Google Maps、Gmail等等。

Amazon暢銷的電視機上盒Fire TV，就是使用由Android分支出來的作業系統FireOS。根據市調業者Statista的統計，2019年全美出貨的機上盒中，出貨最多為Roku，Amazon Fire TV佔12%居次，Google Android TV和Chromecast合計佔比為9%，排名第四位。

報導引述消息人士指出，去年Google宣佈的智慧電視合作夥伴，包含10家主要業者中的6家，以及全球160家有線電視業者，基本上已排擠掉Amazon的位置。

Google對此拒絕評論。Amazon Fire TV部門主管Marc Whitten也未正面評論Google政策。報導引述Whitten指出，該公司並不期待裝置廠商只使用Amazon的解決方案或軟體，但Amazon認為廠商應該要有權選擇適合他們的解決方案，依據不同電視產品線或不同裝置類型與地區。

消息一旦屬實，可能會引發主管機關介入調查。過去Google藉Android合約在行動裝置中強搭自家服務，經歐盟調查後，於2018年開罰44億美金。

蘋果在今年1月底因應中國武漢肺炎大爆發，而暫時關閉了當地的辦公室與42家蘋果直營門市，不過它們已全數在今天（3/13）恢復正常營業，但提前2小時打烊。

蘋果是在今年1月底開始，關閉中國境內特定城市的蘋果商店，並在2月全面關閉門市，之後再陸續重啟門市，而本周五（3/13）則宣布，中國所有門市恢復正常營業。

就在武漢肺炎疫情爆發後，蘋果在今年2月中旬，調降了該公司2020財年第二季（截至今年3月底）的財報預測，其一是因全球的iPhone供應鏈受到疫情影響而受限，其次則是中國市場的需求，也因門市的關閉而受到波及。

不過，雖然蘋果重啟了中國門市，但隨著義大利成為武漢肺炎的重災區，已在本周關閉了位於當地的17家蘋果門市。

武漢肺炎（COVID-19）進入全球大流行狀態，各地都有企業員工自願、或被迫利用遠端協同工具在家上班，造成本周各個協同作業平臺包括Slack、Zoom及Google、微軟，紛紛傳出因流量過大，而出現暫時斷線或視訊、訊息傳輸不穩的問題。

因應疫情爆發，企業員工在家上班或居家隔離者數量激增，微軟、Google、Zoom上周分別放寬視訊及遠端協同免費版服務的容量及使用限制。最早宣布優惠服務的Zoom，周四發生數小時斷線。根據Downdector的紀錄，Zoom於臺灣時間周四（3/12）晚上10點起直到周五早上11點，陸續有用戶回報登入或視訊會議系統出現問題，用戶集中於美東、加州、華盛頓州、北義大利、英國、西歐及北歐。

另一遠距協同平臺Slack，約在周四晚間9點到周五早上8點，有西歐、中國、日本、美東、加州和華盛頓州的用戶反映連線異常、無法上網及傳送訊息等問題。這個時間主要是歐美地區的工作時間。

除小型業者外，微軟、Google等大廠也沒能倖免於難。Google Hangouts於周五凌晨數小時內，在日本、義大利、英國及西班牙地區，傳出服務登入及影音通話問題。微軟Microsoft 365企業副總裁Jared Spataro指出，該公司自從在家工作的第一天起，Microsoft Teams上的通訊流量成長了50%，會議流量增加37%，而企業客戶以Teams進行的會議、通話及協同流量也都激增。Microsoft Teams及Office 365從周四晚上9點開始，也出現用戶抱怨，Skype for Business也有部份用戶反映服務問題，地點分布也是以美東及西歐為主。事實上思科的WebEx也有類似情形，不過反映人數較少。

隨著疫情在歐美蔓延開來，全球已有超過12萬人確診。微軟上周要求西雅圖及舊金山地區的員工，改在家上班直到3月25日。Google也建議北美、歐洲、非洲及中東據點的員工，近日最好在家上班。世界衛生組織昨（12）日終於宣布，武漢肺炎進入全球大流行狀態。

微軟在周四（3/12），完成了無法在3月Patch Tuesday準時提供的CVE-2020-0796漏洞修補，該漏洞存在於Microsoft Server Message Block 3.1.1（SMBv3）協定中，允許駭客自遠端執行任意程式，且被英國資安業者Sophos視為本月微軟最重要的安全漏洞。

微軟原本計畫要在Patch Tuesday同步修補CVE-2020-0796，只是當天卻未見CVE-2020-0796，但事前收到微軟通知的資安業者不小心外洩了CVE-2020-0796的資訊，且微軟也公布了與該漏洞有關的安全通報。

不過，微軟在兩天後緊急修補了CVE-2020-0796。此一存在於SMBv3協定的漏洞，可同時用來開採SMB伺服器端與SMB客戶端程式，波及Windows 10 1903/1909，以及Windows Server 1903/1909等平台。

根據Sophos的說明，該漏洞涉及其中一個核心驅動程式的整數上溢與下溢，駭客可藉由惡意封包來觸發下溢，以自由讀取核心，或是觸發上溢來覆蓋核心中的寫入指標。

Sophos指出，駭客可能透過網路，來危害任何啟用檔案分享功能的Windows電腦，不管是個人電腦或是檔案伺服器；或是利用社交工程或中間人攻擊以將Windows用戶引導至惡意的SMB伺服器；也可藉此展開權限擴張攻擊，取得系統的更高權限。

一般而言，Windows防火牆會封鎖從SMB埠進入的公共網路流量，但如果防火牆被關閉了，SMB埠被開啟了，或是該電腦位於Windows Domain中，那麼可能就會曝露在安全風險中，因此，任何未修補且開放SMB埠的電腦，都有可能受到攻擊，而且是類似WannaCry般的蠕蟲式攻擊。

這類的攻擊通常鎖定開啟的445/tcp連接埠，但使用者不能只透過關閉445/tcp來因應，因為不只是SMB，其它Windows Domain的重要元件，也需要使用445/tcp。

總之，Sophos呼籲Windows用戶應該要立即修補CVE-2020-0796。

武漢肺炎（COVID-19）疫情令全球人心惶惶，駭客也利用以相關時事為誘餌發動惡意攻擊，近日又有假冒約翰霍普金斯大學製作的疫情地圖，利用民眾關注全球疫情散布狀況的心理，藉機散布AZORult惡意程式。

先前就有多家資安業者在2月初指出，網路上有偽裝防疫衛教資訊網釣郵件開始流竄，後續還包括世界衛生組織（WHO），他們也呼籲使用者小心假冒為WHO的郵件，而美國國土安全部前幾日也提醒，當心假藉社福團體名義的醫療捐款釣魚信，最近，還有駭客則是將假冒焦點放到武漢疫情儀表板上。

根據安全公司Reason Cybersecurity研究中心指出，有駭客仿照了約翰霍普金斯大學所製作的儀表板，並植入惡意程式，目的是要要竊取使用者電腦中的敏感資訊，包括線上服務的帳密與信用卡號碼等。

由於約翰霍普金斯大學製作的疫情地圖，是使用Esri公司的ArcGIS Online產品，加上這起事件網路上有許多誤導性的報導，因此引起該公司的關注。

Esri的軟體安全暨隱私小組在12日在官方部落格上發出公告，澄清約翰·霍普金斯大學發布的疫情地圖，並沒有包含任何惡意軟體。會造成混淆的原因，是因為駭客打造的武漢肺炎儀表板，是一個可下載並安裝在Windows的應用程式，具瞭解，開啟後會看到以Web為基礎的儀表板，但會欺騙使用者使用者下載其他的程式。

對此，Esri的臺灣區總代理商互動國際數位也提醒，如果網站要求用戶下載安裝才能看到儀表板，那它就是假的，真正的疫情儀表板可以直接透過瀏覽器線上瀏覽。關於該惡意網站要求下載的部分，他們也透過虛擬機器測試，防毒功能可以擋下，但也表示難保會透過郵件邀請下載。

Windows 內建遠端桌面連線工具（Remote Desktop Connection Manager，RDCMan）傳出有漏洞，微軟直接宣布將之除役，呼籲用戶改用新的MSTSC或Remote Desktop App。

RDCMan的漏洞編號CVE-2020-0765是由中國平安科技安全研究人員Ethan Sterling發現，出在解析包含外部參照的XML內容過程發生錯誤，成功開採本漏洞的攻擊者，可以透過注入XML外部實體（XXE）宣告來讀取任意檔案，造成資訊外洩。

RDCMan原是微軟Live Experience部門內部使用的工具，大約2009年前後開放下載。在還沒有其他類似工具前，RDCMan很受歡迎，但它作為遠端管理其實功能並不齊全。微軟後來在Windows內建了遠端管理工具MSTSC（Microsoft terminal services client），還釋出可單獨下載的遠端桌面（Remote Desktop）App。RDCMan自2014年11月釋出2.7後即未再更新。微軟去年即呼籲用戶轉到MSTSC或Remote Desktop App。

CVE-2020-0765影響的即是RDCMan 2.7。攻擊者可以新增包含改造過的XML內容的RDCMan組態（RDG）檔，以郵件或其他方式傳給用戶，誘使具有授權的用戶開啟檔案即可開採本漏洞。

雖然目前RDCMan還是擁有不少愛用者，但藉由這次漏洞，微軟畢其功於一役，宣佈終止RDCMan。微軟表示已讓該App除役，因此不會修補RDCMan漏洞。微軟再次呼籲客戶改用MSTSC或Remote Desktop App，開啟RDCMan組態檔（.rdg）時也要特別留意。

Google自家的智慧型手機Pixel系列，其最新的Pixel 4和Pixel 4 XL使用了Motion Sense技術，讓用戶不需要觸碰裝置，就能透過手勢，控制音樂播放軟體或是靜音來電，而Motion Sense背後使用一種稱為Soli的短程雷達感測器，Google還設計特別的機器學習演算法，以解讀Soli雷達資料中的訊號，了解用戶的動作意義。Google提到，Pixel 4為目前消費型手機中，第一個整合短程雷達的裝置。

雷達的基本功能，便是使用無線電波偵測和量測遠程物體的屬性。傳統的雷達系統包含了發射器和接收器兩部分，由發射器發射無線電波，無線電波碰到路徑上的物體便會散射，部分反彈的無線電波會被接收器攔截，根據收到的波型，雷達系統便能偵測到物體的存在，並且估計物體的大小與距離等屬性。

不過這種傳統雷達並不能用在行動裝置上，因為傳統雷達的設計，僅可用於檢測大型、剛性且遠距的物體，消費型裝置需要更高的靈敏度和解析度來感測複雜的動作，因此Google團隊重新打造了新型的雷達系統，以符合人機互動需要的精準度。

與傳統雷達區分空間結構的想法不同，Soli主要的目的是要感測動作，Soli的天線可封裝進5 mm x 6.5 mm x 0.873 mm無線射頻整合電路（RFIC）中，並且被整合安裝在手機頂部。Google提到，相對於以光學影像為基礎的偵測器，他們開發出不需要對目標空間產生清晰影像的演算法，不會有可辨識的身體或是臉部的圖像。

Soli處理隨時間變化的訊號來偵測和解析細微的動作，Soli雷達發送60 GHz的調頻訊號，並且接收附近物體的反射疊加，由於目標的位置移動，會在訊號產生明顯的定時偏移，透過分析多次的雷達訊號，訊號處理工作管線便能以不同的運動模式區分物體移動。

Google給出了幾張動畫範例，來表示Soli訊號的特徵，圖像垂直軸代表從感測器出發的徑向距（Radial Distance），由上而下數值增加，而水平軸則為朝向或是離開感測器的速度，中心為零，左側是接近目標速度為負，右側反之，另外，雷達所接收到的能量，也會被映射到徑向距與速度維度中，會以每個畫素的強度表示，強反射目標的像素，比弱反射目標的像素更亮。

下圖3張雷達動態圖由左至右分別是人走靠近裝置、人碰觸裝置，最右則是人的手在裝置上滑動。

Soli雷達原始訊號在經過過濾和增強之後，便會輸入Soli機器學習模型進行手勢分類。Google提到，運動感測技術都存在兩個主要的挑戰，首先，每個用戶的動作都是獨特的，即便是簡單的動作都是獨一無二的，另一個挑戰則是，感測器可能會接收到許多看起來跟手勢類似，但實際上是不重要的訊號，特別是當手機在移動時，以Soli雷達的角度來看，整個世界都在移動。

為了解決這些問題，Google並需要特製機器學習演算法，他們找來了數千名志願者，記錄下數百萬個手勢，並且配對側錄的雷達訊號，訓練Soli的神經網路。Soli機器學習模型使用TensorFlow進行訓練，並為Pixel裝置的低功耗數位訊號處理器最佳化，使其在裝置低電量的情況下仍然可以執行。

Google早從2014年就開始研發Soli系統，經過大幅縮小整個雷達系統之後（下圖），才得以放進消費性智慧手機中，除了尺寸縮小之外，Google還必須最佳化Soli的計算周期，才能讓Motion Sense適應智慧手機的功率。Google也發展出特殊的訊號處理技術，解決聲音震動對於Soli系統的影響，使其能與周圍的電話元件共存。

擋不住的武漢肺炎疫情，讓義大利在日前宣布封城政策，也要求學校停課、關閉非必需品及藥房以外的商家，而義大利電信（Telecom Italia）則說，這兩周以來，境內所使用的網路流量比過去增加了70%。而美國電信業者AT&T則表示，為了滿足在家上班或學習的避疫措施，該公司將移除用戶的寬頻使用上限。

根據彭博社的報導，就在義大利相繼關閉學校、商店與餐廳以抑制武漢肺炎疫情的散布時，義大利電信的網路流量竄升了70%，這些流量有的來自遊戲，有的來自在家工作的視訊會議，或是各種串流服務。

不只是義大利，在美國也看到網路使用量的大增，當地的電信業者AT&T已宣布將取消頻寬使用上限。AT&T向Motherboard表示，許多人因為疫情而被迫在家工作或學習，因此該公司決定取消頻寬使用上限，期限則視情況而定。

根據AT&T的說法，該公司有許多用戶原本就訂閱吃到飽的頻寬服務，但現在他們也消除其它用戶的頻寬使用上限。

AT&T的上網方案可能介於每月150GB到1TB之間，若是超過上限就會被收取每50GB約10美元的費用，AT&T的決定等於讓所有寬頻用戶都能享用吃到飽服務。

事實上，有17名美國參議員在本周連署發表了公開信，呼籲當地的電信業者都應在此一緊急時刻同舟共濟，取消上網限制，但目前只有AT&T正面表態。

在民眾被規勸與人群保持距離、不要參加大型活動，以及在家上班等防疫措施之後，各地的網路使用都明顯上升，英國電信業者Vodafone也說他們已擴充網路能力以應付可能突然增加的流量。

負責G Suite的Google副總裁Javier Soltero本周向Axios透露，G Suite在全球的用戶數已超越2億門檻。

Google是在2006年的8月發表G Suite，這是一套工產力工具，內含Gmail、Hangouts、日曆、文件、試算表、簡報、協作及硬碟等服務，主要的競爭對手為微軟的Office 365。

Soltero則曾是行動個人資訊管理程式Acompli的共同創辦人，微軟在2014年以2億美元買下了Acompli，隨後將它更名為Outlook Mobile，當時Soltero也順勢加入了微軟，並在去年跳槽至Google。

Soltero只說G Suite用戶數突破2億門檻，並未公布使用免費及付費服務的比例。

另一方面，微軟在截至去年9月底的2020財年第一季財報中，便宣布其Office 365商用版的每月活躍用戶就已超過2億，而訂閱Office 365的消費者亦超過3,560萬人。

Atlassian在其用來簡化專案進度追蹤的工具Jira，增加了無程式碼工作流程自動化功能，用戶只需要拖放並起組合規則，就可以讓系統自動處理重複性的工作，自動化功能支援的服務，包括了Jira Software、Jira Service Desk和Jira Core。

官方提到，手動分配工作和發送提醒等日常工作，過於單調乏味，也會占用進行真正有產值工作的時間。為此Atlassian在Jira雲端導入了自動化技術，用戶透過直觀的拖拉介面，可以非常快速地建置自動化規則，自動處理無聊且重複性的工作，自動化工作流程不止支援Jira雲端產品，同時也可以與第三方工具整合，並且能夠與DevOps實踐結合使用，使程式碼能夠順利地部署到產品環境，自動化整個發布過程。

Atlassian這個新的自動化功能，讓用戶完全不需撰寫程式碼，只需要拖放if-this-then-that規則，將他們組合在一起，便可以讓工作自動化，並且應用在各種使用案例上。企業除了可以利用自動化功能，解決入職或是授權等工作，管理員還可以設定時間規則，用來關閉過時的支援票券，或是臭蟲報告。

自動化功能內建了數十種觸發規則並且支援JQL，用戶可以擷取多個問題，並在列表上一次設置一系列的自動化操作來解決這些問題，由於自動化功能整合了Slack、Twilio和Microsoft Teams等協作工具，因此團隊成員可以即時地監控這些問題的處理狀況。

現在每個Jira雲端用戶都可以使用新的自動化功能，Atlassian提到，自動化已經是企業不可或缺的工具之一，開發人員可以因為使用Jira，花更多的時間在有價值的工作上。根據Altlassian的說法，他們對Jira用戶進行調查，97％受訪者表示使用自動化功能可節省時間，一半以上的受訪者表示，每個月節省的時間達6個小時以上。

Google現在增加Compute Engine可附加本地端SSD的容量，並且可提升每個虛擬機器的IOPS量，達過去的3.5倍之多，將使得達到特定效能目標的執行個體需求數量降低，進而減少整體成本。

Google提到，部分企業進行運作密集的工作，像是電子商務網站分析、遊戲或是視覺效果渲染，運算效能可能會直接影響專案進度，而要改善運算效能以及降低延遲，首要工作便是改善儲存效能，而本地端SSD便能大幅提升存取效能。

本地端SSD常見的使用案例，是經快閃最佳化的資料庫，這些資料庫在SSD儲存上進行分散與複製，Google表示，像是即時詐欺偵測和廣告交易這類應用程式，必須要使用本地端SSD，才能夠將延遲降低至次毫秒等級，並且每秒提供超高的輸入和輸出操作。

而為了擴增容量提升儲存效能，Google現在提升可附加到Compute Engine虛擬機器的本地端SSD容量，用戶可以為每個虛擬機器附加6 TB或是9 TB的本地端SSD，已經在使用本地端SSD的用戶，可以使用相同的API來存取更大容量的磁碟。更多的SSD容量也為每個虛擬機器帶來更高的吞吐量與IOPS，為現行的3 TB的3.5倍，用戶可以用更少的執行個體，就能達到與過去相同的效能目標。

採用更大和更快的本地端SSD，不只能達到更好的效能，Google提到，他們在新的SSD服務中，透過提升SSD附加的靈活性，進而讓每IOPS的價格比起過去更加的划算。這使得分散式工作負載的整體擁有成本（TCO）得以降低，在經快閃最佳化的資料庫叢集上，進行即時分析的用戶，將獲得更低的TCO與更好的效能。而對於高交易性，以及像多媒體渲染這類效能敏感的工作負載，也可以在各種虛擬機器上，處理超大量IOPS交易。

6 TB和9 TB執行個體的價格，繼續採用現行每GB的價格，6 TB和9 TB的本地端SSD也可以連接到新的N1執行個體，但目前為beta測試階段，另外，也會很快的在N2虛擬機器上提供。

包括Amazon、Google、微軟、蘋果、PayPal及IBM等逾40家企業，在本周連署了一份公開信，宣稱它們擁護多樣性與包容性，鼓勵員工呈現真實的自我，因此反對美國訂定各種歧視同性戀、雙性戀、跨性別或不明性別（LGBTQ）等族群的法令

此一公開信是由Freedom for All Americans（FFAA）所發起的，這是一個專門反對歧視LGBTQ族群的運動，該運動追蹤並公布了美國各州所擬定的、與LGBTQ族群相關的法案，並邀請支持該運動理念的組織或企業參與。

在FFAA所列出的歧視LGBTQ族群的數十個法案中，有的是LGBTQ希望推動的非歧視法案，也有些是針對LGBTQ族群所制定的不平等法案。

此一公開信表達了對LGBTQ族群的支持，指出不管是公平，或是平等的待遇與機會，都是企業最重要的價值觀之一，他們關注那些不平等對待LGBTQ族群的法案，因為相關法案不僅會損害團隊成員及其家人，剝奪他們的機會，也會讓他們在社群中感到不受歡迎，甚至是處於危險當中。

這些企業指出，某些州準備制定的LGBTQ歧視法案可能直接影響公司的業務，呼籲美國政府應該放棄或反對制定歧視性的法規，應該公平對待所有的美國人。

因應武漢肺炎社區傳播2大情境，政府發布企業營運持續計畫指引

圖片來源／中央流行疫情指揮中心

自從臺灣武漢肺炎的本土病例數超過境外移入病例數，也出現零星社區感染案例後，對企業來說，員工因疫情被隔離，使人力資源出現變動的可能性提升。中央流行疫情指揮中心在3月5日發布一份「企業因應嚴重特殊傳染性肺炎（COVID-19）疫情持續營運指引」，依據「現階段（零星社區感染）」及「發生持續性或廣泛性社區傳播」二大情境，建議企業依照當前疫情進行應變。更多內容

VMware全力擁抱K8s，新vSphere將登場

早在去年VMworld全球用戶大會上，VMware就揭露將改用K8s重新打造下一代vSphere的消息。逾半年之後，VMware終於在3月10日透過線上媒體發布會，揭露更多新產品線Tanzu的內容。

幾家基礎架構主要平臺商，如微軟、IBM、紅帽，早在幾年前就全力擁抱容器和K8s，連Google都推出K8s本地端混合雲軟體，終於，VMware也開始加速進軍K8s市場。VMware營運長Sanjay Poonen在記者會上表示，在基於容器技術的微服務世界，「VMware將擁抱K8s，想要成為最佳的企業容器平臺。」這展現了VMware積極追趕對手的企圖。更多內容

口罩實名制2.0開始試營運

圖片翻攝自／www.youtube.com/watch?v=LpExH-vFayQ

中央流行疫情指揮中心宣布口罩實名制2.0政策，以報稅系統為基礎修改而成，開放民眾以健保卡或自然人憑證登記，或是以健保快易通App進行身分認證。目前同樣以7天3片成人口罩為限，需自付運費7元。之後，成功預購的民眾可於3月26日至4月1日，持健保卡或預購憑證領取。更多內容

金管會：36家金融機構已啟動異地辦公

中央流行疫情指揮中心3月5日發布的企業持續營運指引，給了臺灣所有企業一份疫情應變準則。對此，金管會回應，將以先前發布的5大營運不中斷要求為原則，要求銀行繼續進行必要的防疫措施。此外，金管會也會持續依照中央流行疫情指揮中心的發布，來配合辦理。金管會也揭露，目前有多家金融機構已啟動異地辦公。更多內容

臺北榮總推出預約探病App管理訪客

北榮與交大合作開發預約探病APP，讓民眾透過線上預約，減少臨櫃申請、身份查驗時間，整體流程可從5分鐘縮短至10秒。更多內容

Java 14要來了，正式加入新的Switch表示式

依照6個月的發布周期，甲骨文預計在3月17日時釋出Java 14，這個版本有三個主要的更新，第一個便是在Java 12新增的預覽功能Switch表示式，在Java 14中成熟成為正式功能，第二個則是新增的語言功能，為instanceof增加模式配對，第三個則是JVM的功能，提供有用的NullPointerExceptions訊息。更多內容

美國將打造2 Exaflops等級全球最快超級電腦

圖片來源／美國能源部

HPE宣布將打造全球速度最快的Exascale等級超級電腦El Captan，買主是美國能源部國家核子安全局（NNSA），預計2023年初交貨。

El Captan將使用代號Genoa的最新一代AMD EPYC處理器，它採用Zen 4處理器核心、下世代AMD Radeon Instinct GPU，以及第3代AMD Infinity 架構，後者具備高頻寬低延遲性的CPU與GPU通道。Genoa及Radeon Instinct GPU的記憶體及I/O子系統，皆是為人工智慧（AI）、深度學習及高效能運算（HPC）作業而設計。

HPE表示，El Captan的最高浮點運算將達到2 Exaflops（2,000 petaflops），比當今全球200大超級電腦加總更強大。更多內容

研究：AMD處理器存在旁路攻擊漏洞

奧地利格拉茨科技大學研究人員發表的論文指出，AMD為了最佳化CPU的效能和能耗，在L1D快取採用一種預測器，以高效率的方式，預測特定記憶體位址位於哪一個快取路（Way）中，研究人員可以透過操縱L1D快取預測器，來洩漏AMD處理器的機密資料。更多內容

最新PowerShell 7.0釋出，大幅提升模組相容性

微軟釋出最新的PowerShell 7.0正式版，採用的.NET Core從2.x升級到3.1，含有許多.NET Framework API，可大幅提升與現存Windows PowerShell模組的向後相容度。更多內容

Go加入新版協定緩衝區API，但承諾支援舊版本

Go原本的協定緩衝區套件已釋出十年，但是隨著使用者需求的成長，該套件也越來越不敷使用。不少開發者使用Go反射套件，撰寫程式來檢查協定緩衝區的訊息，但因為反射套件只可檢視Go的類型和數值，會忽略來自協定緩衝區類型系統的資訊。由於無法在不改動Message類型現有定義的情況下，維持套件API的相容性，因此Go官方決定釋出全新協定緩衝區模組，且新版本不與舊版本相容。更多內容

Google開源量子機器學習函式庫

圖片來源／Google

Google與多個組織合作釋出量子機器學習模型TFQ。可以將量子運算和機器學習技術結合在一起。TFQ底層整合TensorFlow和雜訊中等規模量子（NISQ）演算法框架Cirq，並且透過現有和TensorFlow API相容的量子運算原語，以及高效能量子電路模擬器，為判別性和生成性量子古典模型的設計和實作，提供高階抽象。更多內容

2月底Win10更新又出狀況，官方證實問題調查中

微軟針對Windows 10桌機及伺服器版1903、1909釋出KB4535996累積更新，主要解決印表機連不上及工作列搜尋功能問題。不少Windows 10 PC用戶安裝後，發生無法開機、重開機超慢、出現安裝失敗訊息等問題。另外還會造成簽署工具（Sign Tools）程式當掉。

微軟近期僅證實已注意到簽署工具的安裝問題，表示正在趕製解決方案。更多內容

卡位臺灣5G市場，三星推Galaxy S20旗艦級5G手機

看準各家電信業者將在下半年開通5G服務，臺灣三星搶先卡位國內5G手機市場，預告3月20日將開始銷售旗艦手機Galaxy S20。

三星Galaxy S20 5G系列共推出三款機型，S20與S20+支援了6400萬畫素相機，最高階的S20 Ultra更支援1億800萬畫素相機，高畫素照相功能，加上支援8K錄影，大容量影像檔案傳輸，未來將能透過5G或是Wi-Fi（上傳/下載速度達1.2Gbps），進行高速傳輸。更多內容

Google Play商店推出點數獎勵計畫

為強化Google Play商店生態發展，Google在臺灣推出Google Play Points獎勵計畫，消費者只要在商店上購買應用程式、書籍、遊戲、電影，都可以獲得點數。更多內容

21年的SETI@Home尋找外星人專案本月結束

以尋找外星智慧為宗旨的運算資源共享專案SETI @ Home，在上線21年後，管理人員基於資料已足夠及管理太麻煩等原因，將在3月31日終止。更多內容

當全世界113個國家地區陷入傳染病危機，個人與組織除了對內設法自保，確保人員健康，維持本身的業務運作，對外的各種聯繫與交流能否如常進行，將會牽涉到許多因素的影響。

以製造業而言，就算本地人員仍能進行生產，然而，原料的取得、成品的出貨，都與各地的產銷、運輸作業能否正常運作有關，而且，並非都有其他替代的來源與管道，因此，許多商業新聞媒體都在持續關注各廠商之間，是否存在著轉單效應及斷鏈危機，若出現這些狀況，將對企業本身的營運產生重大衝擊。

「巧婦難為無米之炊」，若生產端無法獲得足夠的原料，遑論接下來的製造、銷售。另一方面，因為整體經濟局勢嚴峻，需求端可能會趨於保守，再加上各地人員的交通與實體活動的進行，均有可能因為各種疫情管制措施而面臨受阻，也會使得終端消費者不願意花錢購買產品。

在各種服務提供的過程當中，同樣會受到疫情因素的影響，而導致上下游服務體系之間的連結斷裂，因此，企業在積極發展與實施本身的遠距辦公對策之餘，須注意與公司往來的各種產品與服務供應商，以及客戶，確保彼此的供銷關係，仍能繼續維持，若要進行相關的演練，最好也能考慮到這些對象，並與他們進行溝通，找出彼此的業務持續運作方法。

關於武漢肺炎對供應鏈產生的衝擊，已經有不少媒體持續追蹤相關的消息，大部分都是聚焦在製造業的動向，尤其是記憶體、面板等關鍵零組件，但其他產業目前面臨與處理的狀況，似乎較少被揭露。

若想多了解供應鏈因應武漢肺炎衝擊的作法，或許可以參考幾家研究與顧問機構發表相關的文章。像是：Gartner〈Coronavirus: How to Secure Your Supply Chain〉，以及Deloitte〈COVID-19: Managing supply chain risk and disruption〉、KPMG〈Businesses need to respond to COVID-19 supply chain disruption〉、PwC〈COVID-19: Operations and supply chain disruption〉，而在哈佛商業評論上，刊載了〈Coronavirus Is Proving We Need More Resilient Supply Chains〉。

有些顧問機構則是在整體衝擊的分析時，也涵蓋到供應鏈的應對作法，例如，麥肯錫〈COVID-19: Implications for business〉、Deloitte〈COVID-19: Managing cash flow during a period of crisis〉，以及哈佛商業評論〈Lead Your Business Through the Coronavirus Crisis〉，都特別談到供應鏈層面的挑戰與反應方式。

事實上，面對此次全球擴散的疫情，所要考量的層面，除了我們先前提到的工作力（Workforce），以及上述的供應鏈，其實還有其他領域的影響，須提出對策與採取行動。根據PwC的分析，企業還要關注危機管理、財務報告、稅務與貿易等領域。

若純粹從IT產品與服務的層面來看廠商與用戶受到的衝擊，市場調查機構IDC也發布了相關預測。以臺灣資通訊市場來看，他們認為，硬體受到的負面影響較大，個人電腦、顯示器、穿戴裝置、周邊裝置/印表機等產品，在今年第一季會面臨較大的衝擊，其次是手機與平板，再其次是伺服器與儲存設備，網路設備與IoT設備也會受到負面影響。而在個人電腦的部份，IDC認為，桌上型電腦受到影響的程度，高於筆記型電腦。

在軟體層面，因為遠距辦公與教學的需求，企業與學校對於協同合作、客戶關係管理的應用，都可能會升溫，人工智慧的部份也是熱門應用，資安、IT服務、雲端服務則不受影響。