在開源RISC-V指令集技術問世以後，儲存廠商Western Digital也是硬體大廠投入RISC-V研究最早的一家，還在展開研究的兩年後誇下豪語，誓言每年將出貨10億個RISC-V處理器核心，用於自家SSD儲存產品。未來目標更要擴大到所有儲存產品都要用，多達20億顆，顯示其對於RISC-V在儲存領域應用的看重。

目標每年出貨10億顆RISC-V核心

2015年時，RISC-V基金會成立，Western Digital也是創始成員之一。之後，花了一年時間評估RISC-V用於儲存的可能性，Western Digital在2017年時就宣布要用RISC-V處理器核心，來取代現有的SSD的控制處理器，還計畫每年要出貨10億顆RISC-V核心，用於儲存產品相關應用。

隔年，Western Digital馬上推出第一個完成實作的RISC-V處理器核心SweRV，可設計成高效能嵌入式CPU，在內部CPU性能測試時，可以針對每核心時脈（MHz）提供多達4.9 CoreMark的性能，也能對比於Arm Cortex-A15系列的性能表現。在設計上，該公司採用了32位元RISC-V的指令集架構來設計這顆CPU，其內含了I、M、C等基本及擴增指令，可提供基本整數、乘／除與壓縮指令的功能，在Pipeline流程則採用9個stages和2個issue設計。

Western Digital更在去年一連展示了2款全新SweRV處理器，前者能提供更強大的處理效能，並增加對於多執行緒的支援，來提高CPU執行效率，後者，則是以高度省電設計為主，可以用於各種SoC晶片的開發。該公司還貢獻了第一代SweRV處理器核心，包含了RTL程式碼，並以Apache 2.0授權開源釋出，目前已放到GitHub程式代管平臺。

Western Digital擁抱開源不遺餘力，未來更大目標，是要讓所有儲存產品都能使用這些RISC-V產品。

更進一步，該公司還貢獻自己開發的一個OmniXtend快取一致性Fabric架構支援RISC-V生態系的發展，並且同樣開源，透過這個新的快取網路架構，除了可提供跨平臺的資料一致存取與共享，OmniXtend也支援了各種硬體，包括乙太網路交換器等。

由於看見RISC-V開源架構對於儲存發展帶來的好處，Western Digital也開始擁抱其他開源或開放硬體，在2017年就加入臉書成立的OCP開放運算聯盟，還公開展示了不少相容OCP標準的儲存硬體和連接設計。直到現在，這家儲存公司每年都會在OCP技術大會上發表最新開放儲存產品及技術，提供做為開放硬體架構及資料中心架構設計的使用。

Western Digital後來還加入Google為首在2019年初成立的CHIPS聯盟，該聯盟旨在推動開源硬體，以及開放RISC-V架構的建立，來協助推動開源CPU及SoC晶片的普及。Western Digital也貢獻相關RISC-V技術。

 相關報導  CPU晶片設計也能DIY

一個大學實驗室的開源硬體專案，竟掀起全球晶片產業的新革命，就連Google、三星、Nvidia都押寶，不同於主流CPU架構的有限設計選擇，現在可以任意組合、自己設計真正想要的客製CPU

武漢肺炎（COVID-19）疫情重創中國，而中國更是全球科技產業的製造重鎮，市場分析機構集邦科技（TrendForce）預測該疫情在今年第一季，將同時衝擊半導體、面板、通訊及消費者電子產業的產能，包括智慧手錶、智慧型手機、筆記型電腦、遊戲機與智慧音箱的產量，都將減少10%以上。

集邦科技指出，晶圓代工的自動化程度較高，因此武漢肺炎對晶圓代工的衝擊比封測來得低，只是中國半導體的人力多來自於外地，在人力與交通的限制下，仍將使晶圓代工的復工率低於預期，可能下修第一季的出貨量，連帶影響下游的封測業者。

而高度自動化的記憶體工廠一來對人力的需求較低，再加上在農曆年前即有備料，因此短期內不致於短缺，但市場可望維持一定的採購力道，而讓記憶體價格上揚。

值得注意的是，武漢擁有全球最大的光纖供應聚落，占全球光纖電纜生產比重的25%，由於5G對光纖的要求是4G的2倍以上，可能影響5G發展時程。

在智慧型手機方面，有鑑於手機供應鏈對人力的需求高度密集，使得它受到疫情的衝擊較為明顯，估計第一季智慧型手機生產量，將比去年同期衰退12%，創下5年來的新低。

而筆電則因延後復工、作業員返工率低，再加上物料短缺等問題，估計產量也會下滑12%。

其它消費性產品因物料或人力的影響，而造成產量下滑兩位數的，還有智慧手錶的16%，遊戲機的10%與智慧音箱的12%。

微軟發布最新防火牆服務Azure Firewall的更新，新增的預覽功能包括強制通道以及IP群組，而自定義SNAT私有IP地址則成為正式功能，高連接埠限制鬆綁也正式施行了，另外，微軟也提到，Azure Firewall是目前第一個獲得ICSA Labs企業防火牆認證的雲端防火牆。

強制通道（Forced Tunneling）功能，可以強制所有Azure Firewall的網際網路繫結流量，傳回到企業內部或是附近網路虛擬設備（NVA），以執行進一步的檢查與稽核。在預設情況下，Azure Firewall是不允許強制通道，以確保所有流出流量都滿足Azure相依性。而要使用強制通道，需要藉由額外的專用子網，將服務管理流量與用戶流量分開，該子網關聯自有的公開IP地址，可以將流量在傳送到網際網路之前，先路由到任何企業防火牆以及NVA進行處理。

Azure Firewall還提供IP群組功能，微軟提到，IP群組是一個新的頂級Azure資源，可用於Azure Firewall規則中，對IP地址進行分組與管理，用戶可以為IP群組命名，輸入IP地址或上傳檔案以創建IP群組，在單個或是跨多個防火牆中使用IP群組，能夠簡化IP地址管理工作。

Azure Firewall為所有公開IP地址的出站流量，提供自動來源網路地址交換（SNAT）功能，當目標IP地址是屬於IANA RFC 1918的私有IP地址範圍時，Azure Firewall防火牆便不會進行SNAT。而現在用戶有更多自定義的選項，當企業將公開IP地址範圍用於私有網路，或者以強制通道功能將流量導回企業內防火牆，則可以將Azure Firewall配置設為，不對其他自定義IP地址範圍進行SNAT。

微軟提到，從Azure Firewall預覽版發布以來，就有一個限制，會阻擋網路和應用程式使用64,000以上來源或是目標連接埠，不過這項預設規則，限制了RPC技術的使用，特別是Active Directory的同步，現在微軟鬆綁此項規定，用戶已經可以使用1到65535間的任一個連接埠。

美國國土安全部網路安全及基礎架構安全署（CISA）本周披露，當地一家天然氣壓縮公司受到勒索軟體攻擊，使得公司業務停擺兩天，呼籲所有重大基礎設施領域的業者，都應記取教訓並確保已導入相對應的緩解措施。

CISA並未公布該受駭業者的名稱，只說駭客透過魚叉式網釣攻擊入侵該組織的資訊科技（IT）網路，再找機會滲透到操作技術（OT）網路，繼之在這兩個網路上部署了勒索軟體，使得OT網路的人機介面、資料與輪詢伺服器完全失能，且受到影響的資料，也無法再讀取或聚集來自IoT裝置的數據。

幸好相關攻擊只針對Windows作業系統，因此可程式控制器（PLCs）並未受到波及，讓受駭組織還能保有操作控制權，在發現異樣之後，該組織立即關閉了營運。

雖然駭客的攻擊行動，只影響了受害組織的一處設施，但因管線傳輸的相依性，其它設施也不得不停止運作，總計停工了兩天。

CISA表示，此一受害組織未能明確隔離IT與OT網路，才讓駭客得以同時危害兩個網路中的資產，隨後受害組織取得了全新配置的替代設備，才得以順利回復。

值得注意的是，受害組織既有的緊急回應方案中，主要是鎖定實體安全上的威脅，並未納入來自網路攻擊的威脅，也未訓練員工如何處理網路攻擊意外。

CISA建議各基礎設施營運商應該明確隔離IT與OT網路；在不同的區域間部署安全控制；從遠端自外部登入，應要求多因素身分認證；嚴格實施用戶權限準則；使用強大的垃圾訊息過濾機制，並過濾網路流量；採用最新軟體與韌體；部署防毒軟體；關閉Office程式中的巨集功能；限制遠端桌面協定的使用。

NuGet.org將會在2020年4月永久移除對TLS 1.0/1.1的支援，微軟現在公開更多棄用施行細節，以幫助用戶將系統轉換到TLS 1.2上。微軟提到，他們暫時停止支援TLS 1.0/1.1的目標，是要幫助開發者辨識出可能受到影響的系統，以順利在期限前過渡。

微軟會在2020年2月26日暫時性地移除對TLS 1.0/1.1的支援，在24小時中，分3個時間段每段4小時，暫時停止支援TLS 1.0/1.1，而這樣的時間分配，為的是要確保暫停支援的時間，涵蓋全球的工作時間。微軟公布了各時區的測試時間，並舉例像是澳洲中部標準時間為UTC+9.5，則根據以下表格為藍色測試區間，暫停支援TLS 1.0/1.1的時間，則為早上9點半到下午1點半。

不過需要注意的是，在非針對用戶時區的測試時間，也可能會被其他測試時間覆蓋，同樣以澳洲中部標準時間UTC+9.5為例，2月26日的下午五點半到晚上9點半，還有2月27日的早上1點半到5點半，同樣也會遇到暫停支援的狀況。

微軟在去年的時候，宣布了兩階段棄用TLS 1.0/1.1的規畫，而2月26日暫停支援TLS 1.0/1.1則為第一階段，第二階段則是在4月全面棄用TLS 1.0/1.1。微軟提到，TLS 1.0和TLS 1.1容易受到POODLE和BEAST等多種攻擊，因此他們才著手移除對這些技術的支援，而這代表用戶將不能使用這些過時的協定，還原或是上傳套件，也不能用來瀏覽NuGet.org。

Compute Engine用戶現在有新選擇，Google推出新的N2D系列，該系列使用第二代AMD EPYC處理器，提供了128與224個vCPU的高階機器類型。N2D虛擬機器現在為測試版本，目前僅在us-central1、Asia-southeast1和Europe-west4地區提供。

Google提到，N2D虛擬機器可用於一般的工作負載，以及需要高記憶體頻寬的工作負載。一般用途是像網頁應用程式與資料庫等，需要在效能、價格和功能上取得平衡的工作，N2D將會是適合的選擇。N2D與相同等級N1執行個體相比，N2D執行個體的花費可節省13%，在Coremark基準測試中，N2D效能比N1執行個體還要高出39％。

由於N2D提供128個和224個vCPU機器類型，因此也可用於HPC工作負載，處理諸如崩潰分析、財務建模、渲染和儲集層分析（Reservoir Analysis）等工作。與相同等級的N1系列相比，N2D多提供70％的平臺記憶體頻寬，加上N2D最高等級可配置更多的核心數，因此於Gromacs和NAMD基準測試中，N2D的效能可以是n1-standard-96執行個體的兩倍。

N2D與N2虛擬機器系列提供相同的功能，包括本地端SSD、自定義機器類型，和具即時搬遷的透明維護等，用戶可以將N2D虛擬機器配置為預定義的機器類型，選用vCPU和記憶體（GB）比例為1:1、1:4和1:8的機器類型，大型機器類型最多可擴增使用224個vCPU，而用戶也可以創建N2D自定義機器類型，以滿足不同工作負載的需要。

N2D系列提供按需模式與先占模式，也有承諾使用優惠，3年承諾使用的價格，比按需定價最多便宜55％，長期使用N2D虛擬機器也能利用持續性使用折扣，減少20％的費用。

著眼於企業韌體安全的Eclypsium在本周警告，危險的周邊裝置韌體已成為Windows與Linux電腦上的安全風險，不管是聯想筆電的觸控板或小紅點（TrackPoint）、HP筆電的視訊攝影機，或者是Dell筆電的Wi-Fi網卡，這些周邊的韌體更新機制，都缺乏適當的程式碼簽章，而讓駭客有機可趁。而且不只上述裝置，這是一個普遍的問題，主要影響Windows及Linux平台，從筆電到伺服器不等。

研究人員指出，除了蘋果的macOS會在每次載入韌體時，針對韌體套件的所有檔案進行簽章驗證之外，Windows與Linux都只會在韌體初次載入時，進行簽章驗證。這意味著駭客可透過不安全的韌體更新機制，把惡意程式注入韌體中。

藉由不同韌體進駐的惡意程式也會有不同的功能，例如惡意的網路卡韌體可能讓駭客可偷窺、複製或變更流量；惡意的PCI裝置韌體可能帶來直接記憶體存取攻擊，允許駭客竊取機密資訊或控制整個系統；惡意的視訊攝影機韌體，則能捕獲使用者環境中的資料。

儘管Eclypsium只驗證了聯想、HP及Dell特定型號筆電的周邊韌體更新漏洞，但該公司相信這是一個廣泛存在的問題，其它的型號或是其它的品牌，可能藏匿著類似的漏洞。

有趣的是，當Eclypsium發現了Dell XPS 15 9560筆電（採用Windows 10平台），使用的Wi-Fi網卡（高通）含有韌體更新漏洞時，該公司同時通知了微軟與高通。高通表示，此一晶片組是由處理器管轄，理應由處理器軟體負責韌體的驗證，而微軟則說，應該由網卡製造商負責驗證載入該裝置的韌體。

不過，Eclypsium認為，最終還是應該要由周邊製造商在韌體更新前，行簽章驗證，而非仰賴作業系統來執行此一功能。

值得注意的是，相關漏洞並不容易修補，因為這些元件一開始就未執行韌體更新時的簽章檢查，因此幾乎無法藉由韌體更新來解決，代表這些安全漏洞，能會一直伴隨著這些元件，直至元件的生命周期結束。

對許多企業來說，全球武漢肺炎（COVID-19）不只是突發事故，更是持續營運能力的考驗。但對老字號的彰化銀行而言，這樣的考驗，不是第一次。

早在2003年，臺灣SARS發生時，許多銀行都是第一次面臨如此大規模的疫情衝擊，彰銀也不例外。原本就有一套持續營運作法的彰銀，在當年疫情過後，更將傳染病納入資訊作業災害復原計畫（DRP），訂定了相關的措施。

到了2019上半年，突如其來的一次事件，疾管署通知彰銀，曾有麻疹群聚個案的高風險接觸者，造訪過分行辦理業務，當時彰銀緊急啟動了對應計畫，也更加重視傳染病的應變措施，再次強化了資訊作業災害復原計畫。去年的實戰考驗，讓彰銀在此次武漢肺炎疫情逐漸升溫之際，也能快速應變。

彰化銀行資訊處處長陳顯龍表示，彰化銀行早有業務永續運作計畫（Business Continuity Planning，BCP），IT團隊就是以此訂定了一套資訊作業災害復原計畫（Disaster Recovery Planning，DRP）。他進一步揭露了彰銀在IT面的因應重點。

一般來說，傳染病應變措施，著重於人員備援機制的部分。在IT人員部分，陳顯龍表示，目前已規畫將資訊處人員依照主要經辦人與代理人，分為兩分名單，一半人員移往另一棟大樓作業，另一半人員則留在資訊處作業，確保服務不致於中斷。另一方案則是部分人員可移到彰銀的臺中異地備援中心進行作業。若部分人員因疫情感染無法上班時，則可採取輪班機制彈性調派人力。

此外，包括彰銀的總行單位、185家國內分行、海外分行、南京子行等也規畫了相對應的IT應變措施。比如，當總行大樓無法上班時，總行單位的作業若涉及正式交易，就會移到彰銀資訊處作業，以確保安全。甚至，連彰銀海外分行也有辦公地點備援計畫，一旦海外分行的辦公場所無法進駐，則可租用當地其他辦公場所，讓行員進駐後，透過網路連回臺北資訊處，進行核心業務交易登打。或者是，在當地主管機關的同意下，可由總行相關人員代替海外入該分行核心主機，進行核心交易登打作業。

導入ISO 22301，完善營運持續管理並強化資訊服務運作

彰銀在2018年導入且通過英國標準協會（BSI）ISO 22301：2012營運持續管理系統（BCMS）國際標準驗證，是臺灣少數獲得這個驗證的金融機構。彰銀希望利用這個制度化規範，來提升營運持續管理能力，並且強化資訊服務運作。

而為了完成營運持續管理制度的建置，彰銀先盤點了相關系統資源，包含主機、伺服器、系統軟體、應用系統、資料庫、網路、通訊設備、資料文件、媒體、個人電腦、環境、人員以及備援相關資源。

盤點完成後，再依據ISO 22301營運持續管理制度的內容，建立營運持續管理組織，進行營運衝擊分析，辦理營運持續管理風險評鑑，擬定了營運持續管理策略，並建立相關制度與設計計畫。依循著制度與計畫，規畫及辦理系統演練作業，以及進行內部稽核與召開管理審查會議。

比如，彰銀既有的資訊作業災害復原計畫（DRP），在導入這個管理制度後，就需做營運衝擊分析，評定最小服務水準等，甚至，要比過往更確實地執行演練，並且將系統切換到臺中異地備援的正式環境。

在DRP計畫中，陳顯龍指出，要先定義災難等級。彰銀是以系統重要性，分為核心帳務系統、開放系統，並依照系統停頓時間造成分行營運的衝擊，依照自家BCP標準，再細分3個等級來考量。

而各級的災害處理原則，依照BCP標準辦理，若遇到異常事故發生，則會立即召開會議研判原因並決定解決方案，如果原主機無法恢復營運時，以切換同地備援為優先，連這個作法也不足以支持營運需求時，才會考慮啟用異地備援。

為此，彰銀甚至還盤點了異地的資源，發現不足後，便開始租線路、採購電腦，進行當地環境的設定等，讓異地備援中心的資源較為充足。

當正式演練時，從長官決定切換異地備援，到人員移至臺中的路程，還有後續的演練到恢復，都須符合營運衝擊分析中的最小服務水準。彰銀等於是透過這個營運持續管理制度，把以前較為粗淺的地方，整個完善起來。

而為了真正落實營運持續管理，陳顯龍表示，在系統備援演練部分，彰銀訂有BCP、DRP等應變復原準則，各個重要系統都有備援演練標準作業程序，平時各系統均會定期進行同地備援或異地備援演練，過程中，會模擬系統異常無法即時恢復時的備援系統切換，讓員工熟悉相關應變及復原程序，以利發生緊急狀況時能即時反應及處理。比如彰銀核心帳務系統，一年則會做兩次演練：一次是同地備援演練，另一次是異地備援演練。

這樣每年兩次的異地備援演練，每次的演練約莫2小時，雖說是模擬，對彰銀來說彷彿打了一場仗。陳顯龍指出，因為，打從演練當天，凌晨天剛亮，資訊處人員就要先展開前置準備作業，派人先把相關環境建置好，再把線路從臺北切到臺中，開啟異地備援中心，並把資料庫倒回前一天早上9點。

此時，各家分行要陸續把本地機器開啟，才可連接異地備援中心主機，並讓全部分行的人員把前一天的傳票拿出來，進行30分鐘的資料模擬登打，同時，僅開放某家分行的自動提款機（ATM），來驗證ATM是否能正常運作。確認完成以上驗證後，就表示異地備援系統可運作，即可關掉異地備援的主機，後續再做回復，並切換回原主機繼續正常營運，並能在銀行營業時間開始之際，準時對外提供服務。

不過，陳顯龍提到，因為核心系統太重要，所以彰銀的資料會同步到同地與異地的主機，共三套資料庫瞬間同步。他也坦言，彰銀比較常切換的是同地備援，萬不得已，不會正式切換到異地備援。

而除了資訊系統演練，人員安全也是ISO 22301的重點。彰銀表示，從導入制度到現在，有別於以往的書面宣導，他們已進行超過20幾場的教育訓練課程與情境實際演練，包含火災疏散演練、人員疏散與清點演練、風災與水災演練、核子事故演練、損害評估及事件後續處理演練、地震疏散演練、系統容量／效能不足演練及重大傳染病演練等，藉此訓練員工面臨災害的反應。

不只網路銀行，彰銀是臺灣唯一一家連手機App都納入ISO 22301認證範圍的銀行，今年，彰銀還要做到更全面的BCP，他們透露，希望同樣作法擴大適用到所有資訊處的系統，即便沒有認證，也要讓所有系統都能有一定的標準，甚至連海外分行的系統也要納入。

系統環境盤點須兼顧新系統與現行系統，避免發生單點故障問題

徹底落實營運持續管理更重要的一個基礎是，「IT系統建置之初，就應該要從頭植入持續營運的DNA與精神。」陳顯龍強調。

以彰銀資訊處的作法來說，在公司的營運持續管理制度建置過程中，最初是內部系統環境盤點作業，他們除了在新系統建置期間確認備援機制之外，也會盤點現行系統備援機制是否完備。陳顯龍提到，彰銀的新系統不管是自行開發，還是委外廠商開發，在規畫建置的階段，都要考量系統耐用年限內資源使用不虞匱乏，同時，必須建置此系統的備援系統，而這又分成同地備援與異地備援，並在驗收前實際演練切換，確認備援機制能正常運作，避免發生單點故障問題。

在現有系統部分，彰銀系統人員則會依照整體作業流程，逐一盤點確認各系統的備援機制是否完備，並擬定備援演練計畫，定期進行演練作業，確保各系統的備援機制皆能正常運作。

不只如此，彰銀的內部稽核單位，以及外部的專業機構，也會定期盤點與查核彰銀相關系統備援機制是否符合規定。在內部稽核單位，彰銀現有資訊安全中心與稽核處每年定期對資訊處各項系統及相關作業進行盤點查核，確認各系統的備援機制均正常運作及符合規定。

在外部專業機構的部分，比如英國標準協會（BSI）每年會定期進行系統盤點與備援機制檢視，確認系統均符合認證資格並逐步納入其他系統。陳顯龍提到，彰銀通過ISO 22301的認證後，BSI每年還會複審一次，確保真正落實營運持續管理。

此外，彰銀每3年會重審一次證書版本，若版本有更改，則會進行轉版。目前，ISO國際標準組織已於2019年10月30日發布最新版本的營運持續管理系統──國際標準ISO 22301：2019，目的是確保此標準因應現今營運環境。而ISO 22301：2012年版的證書也將在2022年10月30日失效。所以，彰銀預計2021年先進行轉版準備，2022年上半年完成轉版驗證。

除了自家的系統，彰銀甚至要求外部廠商須有營運持續計畫（BCP）的作法，讓外部廠商在面臨重大天災及突發狀況，危害或阻斷資訊系統、公司營運與人員的正常運作時，能提供正常的作業活動，才不至於影響彰銀的業務運作。文⊙李靜宜

進一步向傳統運算客戶招手，Google Cloud周三宣布收購荷蘭大型主機應用搬移軟體商Cornerstone Technology。

隨著雲端運算漸取得商務界的信心，有愈來愈多企業藉由把傳統資料中心的應用及作業搬移到雲端上，以現代化（modernize）其IT 環境。在產業開始將應用打造成一個一個「服務」的潮流中，有許多企業想將大型主機上的大型程式，切分成Java應用或Java微服務，這就是Cornerstone工具的核心功能。

Cornerstone的工具透過自動化流程，可以把企業Cobol、PL/1或Assembler程式切分成一個個服務，且能原生執行於雲端，像是代管容器環境上。Google Cloud 並未公布交易細節。

Google Cloud轉型業務總監Howard Weale指出，Cornerstone整合到Google Cloud上，將可在客戶現代化其基礎架構和應用過程中，提供大型主機搬移的規劃，像是整體評估、尋找巨服務及微服務、建立服務架構的開發藍圖。不論客戶用的是何種語言或資料庫，Cornerstone都能協助轉換，並將資料搬上雲端建立資料分析及資料倉儲。

Google並分享已有巴西一家金融機構Boa Vista，將其AS/400 和z/OS系統搬上Google Cloud上，並轉為Java服務及SQL資料庫。

這是Google雲端服務擴大向企業客戶招手的最新一例，因為在講求穩定的商用運算產業如金融業，仍有很大比例使用大型主機。上個月Google Cloud才宣布開始提供IBM Power Systems方案，讓習於大型主機的企業，不論是AIX IBMi或Linux on IBM Power版本，都能在Google Cloud平台上，使用IBM Power Systems 即服務（IBM Power Systems as a Service）。

另一方面，IBM也企圖為大型主機加入新技術，以因應客戶採用雲端運算的需求。去年IBM宣布最新一代大型主機系統z15，除了強調支援大量資料運算外，也因應混合、多雲環境部署需求，增加可端對端加密的TDO資料安全技術，並加入RedHat的OpenShift雲端服務，來支援原生雲應用開發。

因應全球氣候變遷，英國政府本周宣布將投入12億英鎊（約470億台幣），以打造全球最快的氣象超級電腦。

這座超級電腦由英國商務、能源暨產業策略部出資打造，英國氣象局負責管理，可望成為全球用於氣象及氣候運算最先進的系統，其資料將用於預測風暴、降雨及預測全球氣候變化。此外，也可協助英國環境署提供精準降雨預測，以選擇最適防洪地點，協助各地機場、電力公司提早準備及應變。

這項開發計畫預計從2022年開始為期10年，12億中的8.6億英鎊用於開發硬體，其餘用於行政及人力。不過英國政府並未說明系統細節，僅表示，前5年將可讓氣象局現有運算能力增加6倍。6到10年則再擴增3倍。

此外，英國政府也宣布投入3千萬英鎊，資助貝爾法斯特、愛丁堡及杜倫大學執行的高效能運算服務，以協助其他研究人員取得超級電腦的開發技術及軟體工程，投入人工智慧、能源儲存技術及藥物研究。

2019年公布的最新超級電腦排行榜中，第一、二名為美國能源部旗下的橡樹嶺國家實驗室（Oak Ridge National Laboratory）的Summit，及同屬能源部的勞倫斯利佛摩國家實驗室（Lawrence Livermore National Laboratory）的Sierra。英國最頂尖的超級電腦為英國氣象局的Cray XC40，浮點運算峰值為8128.5 TFlop/s，排名全球27。

歐盟在本周揭露了當地的人工智慧（AI）與資料政策，釋出了AI白皮書，並計畫打造一個歐洲資料空間，前者希望能在民眾的信賴下打造各種AI應用，後者則將督促各大科技業者與彼此及歐盟政府分享不涉及民眾隱私的資料。

其中，AI白皮書描繪了一個基於卓越與信賴的AI框架，準備動員整個價值鏈上的產官界，以建立可加速AI部署的適當措施，同時強調將以信賴作為該框架的基礎，透過訂定清楚的規範，來解決高風險AI系統可能帶來的危機，而低風險的AI系統則將採用相對寬鬆的標準。

歐盟把健康、治安與交通等類別，視為重要且高風險的領域，規定相關的AI系統必須是透明、可追蹤，且可由人類監督的。監管機構在檢查化妝品、汽車或玩具時，應該能測試及驗證它們所使用的演算法。必須以無偏見的數據來訓練高風險AI系統，確保這些系統尊重各種基本權利，特別是不歧視。

其實現在歐盟大致上禁止透過人臉辨識，作為遠端身分認證途徑，只允許在特殊、正當及適合的狀況下使用，至於是哪些狀況，則需要藉由公開辯論來決定。對於低風險的AI應用，歐盟也鼓勵業者可自願採行更高的標準。

此一白皮書是用來闡述歐盟對於規範AI的立場與方向，以供大眾、歐洲議會及歐盟理事會進行討論，在相關議題上取得共識後才進入立法階段。

而歐盟的資料政策則被外界視為，是對大型科技業者的挑戰。歐盟計畫打造「歐盟資料空間」（European data space），把歐盟視為一個單一的資料市場，讓所有資料都可在該市場內自由流動，釋放未曾使用的資料，以供當地的企業、研究人員或政府機關使用，讓民眾、企業及各組織都能因為大數據而受益。

因此，歐盟打算建立一個資料監管框架，鼓勵資料分享，並規範在企業之間、在企業與政府之間，或是在政府內部的資料管理、存取及重新使用，它同時也代表各國政府將釋出公領域的資料集以供重新使用及創新。未來的資料空間還將分門別類，像是製造、行動或健康等。

金融時報分析，歐盟有可能強行規定科技業者必須對外分享自己的資料，如此一來，即有機會打破Amazon或Google在歐洲的壟斷地位。紐約時報與華爾街日報的看法相似，認為全球頂尖的AI或科技技術，多由歐盟以外的業者把持，在數位經濟時代處於弱勢的歐盟，期望藉由新政策與規範來取回控制權。

不管是AI白皮書或資料政策，都將受到歐盟隱私法GDPR的規範，以不危及個人隱私為前提。

Red Hat本周宣布將在2020年5月26日，終止對CoreOS Container Linux的支援，呼籲用戶儘速轉換到其他作業系統，像是Fedora CoreOS。

5月底CoreOS Container Linux來到生命周期終點（EOL）後，用戶將無法獲得安全及功能更新。

CoreOS Container Linux是很適合跑容器的輕量級作業系統，支援多種叢集架構，並具備自動更新功能，容器runtime可以選擇Docker或CoreOS自有的Rocket（rkt）。Red Hat2018年初買下CoreOS公司，但之後宣布以Red Hat CoreOS及Fedora CoreOS取代CoreOS Container Linux。Red Hat稱Fedora CoreOS為CoreOS Container Linux的「正式繼承人」。

Red Hat指出，Fedora CoreOS是專為大規模而安全執行容器化作業而設計的Fedora版，結合了ContainerOS的調撥（provisioning）及自動更新工具，以及封裝技術、OCI映像檔格式支援及SELinux安全存取技術。

RedHat去年年中釋出Fedora CoreOS預覽版，上個月釋出正式版。

今天起，AWS Marketplace上的CoreOS Container Linux將不再接受新訂閱戶。原有訂閱戶仍可使用，也不影響透過CoreOS官網以AIM ID啟用的Container Linux。最後一版CoreOS Container Linux將自5月26日釋出。但之後任何臭蟲及安全漏洞，都不會有修補程式。

而從9月1日起，CoreOS Container Linux的所有相關公開資源，都會刪除或僅提供唯讀服務。用戶將無法下載OS、CoreUpdate伺服器也會關閉，AWS、Azure、Google Compute Engine上的OS映像檔也會移除。GitHub上的issue tracker和文件將只提供純讀取。現有CoreOS Container Linux機器還是可以跑，只是不會有更新。未來在公有雲上，也將無法啟用新的CoreOS Container Linux機器，除非有事先準備。

此外，9月1日後，Red Hat也會加強力道來移除CoreOS Container Linux物件和映像檔，以防止這些OS在沒有安全更新下繼續使用。

Red Hat也提供從CoreOS Container Linux搬移到Fedora CoreOS的指示。但也提醒Fedora CoreOS目前還無法取代CoreOS Container Linux所有應用情境，包括不支援Azure、DigitalOcean、Google Cloud Engine、Vagrant，不包含rkt container runtime。此外，Red Hat 警告，Fedora CoreOS雖具備相當穩定性，但可能在某些情況中還是會出錯。

如果用戶不想用Fedora CoreOS，Red Hat建議用戶也可改用由CoreOS Container Linux分叉出來的Flatcar Container Linux。此外Red Hat Openshift也內建RHEL CoreOS。

武漢肺炎（COVID-19）疫情持續延燒，製造業也遭受衝擊。面對突發狀況時，企業平時是否落實持續營運計畫的規畫工作，顯得更為重要，身為2千大製造業的雙鴻科技，回顧自身建立企業持續營運計畫（BCP）的機緣，揭開了製造業IT應變作法的神秘面紗。

「若大型主機壞掉，資訊團隊需多少時間才能還原設備和系統？」雙鴻科技資訊室協理林伯勳回想2015年一次簡報會議上，董事長向IT團隊提出了這個問題。經資訊團隊評估後發現，還原硬體設備和系統約需半個月時間。

雙鴻從2007年開始落實備援機制，但只限在地的單機備分與備援，沒有建立異地備援機制。林柏勳表示，不像PC設備可直接購得來復原，大型主機若是壞掉，需先向廠商訂購設備、等廠商將機器送到位，並待機器架設完成，才可進行系統還原的工作。

以散熱模組起家的雙鴻，每年全球出貨量都名列前茅，並無法容忍系統中斷半個月。一旦關鍵系統像是ERP中斷，就會全面影響營運，造成嚴重的損失，且雙鴻舊有備援機制的系統還原演練，只限各套系統自身的備份還原動作，未將企業整體的業務架構納入考量。林柏勳指出，若有災難發生，雙鴻並無法掌握會受波及的業務範圍，以及業務將受影響的程度及時間。

全面盤點業務架構和IT系統，以訂定BCP預備災難對策

經過該次模擬評估，雙鴻認為系統中斷造成的災難，不可忽視，於是，全面盤點了業務架構和資訊系統，花了約4個月的時間，以滿足客戶的交付需求為目標進行規畫，於2016年訂定BCP，涵蓋了各特別事件包含地震、颱風等天災，還有公用事業供應中斷、勞力短缺、關鍵設備故障，以及與資訊部最切身相關的IT系統損壞等情況。

在這份規範中，雙鴻詳列了各部門面對各種可能的突發性事件，需肩負的職責和握有的許可權，並針對各類特別事件明列運作準則，以及因應對策，其中包含IT系統發生損壞時，像是：內外網路斷線、應用軟體損壞等，各部門負責人須立即提報問題，由IT工程師確認處理，而若修復時間較長，各部門負責人需通知銷售服務中心，以通知客戶並協商對應方法。

林柏勳也提及如何從資訊角度看BCP，他認為，聚焦的部分應是IT如何支援企業持續營運。首先，以企業整體營運為基礎，評估哪些攸關企業持續營運的項目與IT有關；接著，評估這些項目會影響的層面，規畫並訂定對策和規範；下一步，才進而針對突發事件對資訊系統造成的衝擊，訂定災難復原計畫（DRP）。

DRP可視為BCP的關鍵環節，為訂定DRP，雙鴻從4大面向分析業務架構，剖析BCP，包含了風險因素、業務關鍵性分析、IT現況分析和技術恢復分析，從而可獲得3項分析結果，分別是：災難恢復時間目標（RTO），也就是雙鴻可容許服務中斷的時間；以及災難復原點目標（RPO），指當雙鴻服務復原後，取得的恢復資料對應的時間點；還有IT可行性分析。

雙鴻再以這3項結果為基礎，訂定DRP，以規範復原動作如何推展，內容包含了資料備份與還原應遵循的步驟，還有業務持續性的步驟，以及資訊災難等級說明、資訊系統回復等級等。

以業務持續性步驟為例，首先，他們從評估受災等級和狀況開始，標準包括災難破壞情況、業務影響程度、機房重建選址，以及挽救的設備清單和測試情況；下一步，公司會對外發布受災聲明，說明業務影響及IT損壞情況；而後，他們將制訂復原實施方案，一步一步重建資訊環境和系統，從重建資料中心、網路系統，到重建生產系統，再經過系統全面測試，最後，系統才可全面復原執行。

另外，雙鴻依災難對資訊系統的影響程度，將災難分為下列四大等級，而各層級有不同的行動準則。第一級，也是對系統影響最大的情況，當重大災難導致系統全面無法執行，同時，資訊系統場域毀損，導致人員無法進駐，像是斷電、地震等。這時，雙鴻會切換備援系統，並於IDC機房設立臨時處理中心，讓IT人員轉移，此外，通知協力廠商進行復原。

第二級則是當災難造成部分系統無法使用，而人員仍可進入資訊場域辦公，像是ERP中斷，但人員電腦可上網。對此，雙鴻會切換備援系統因應，並通知廠商復原。

第三級為人員電腦大規模無法使用，像是個人電腦遭遇病毒感染，影響電腦自身、系統等運作，嚴重甚至可能危及整個公司的營運。因應此情況，雙鴻IT人員會協助復原，隔離受影響的資訊範圍，阻絕災害擴大。最後，第四級為人員硬體設備發生問題，像是程式異常，造成人員無法操作業務，雙鴻IT團隊則會協助修復。

除了災難分級對策外，雙鴻在DRP中，也依系統對公司營運的影響程度，系統是否有可替方案，以及回復速度將衍生的成本等因素，以4大等級訂定系統的回復時效。

第一等級為會造成企業的業務嚴重損失的系統，包含ERP、郵件系統、網路等，系統回復時效為4小時；第二級為會影響企業長期營運，並影響人員作業效率的系統，包含PLM、BPM等，最遲要在3天內回復。林柏勳指出，BPM若中斷，電子簽核流程可使用紙本代替，再透過郵件系統傳遞。

第三級則為影響單一廠區人員作業的系統或設備，像是MES、印表機等，回復時效加長為3至7天。林柏勳表示，MES系統分散於各地工廠內，且若中斷可改採手動報工，不影響產線的生產作業。第四等級是會影響個別人員作業的設備或系統，例如，個人電腦、筆電等，回復時效可大於7天。

因應DRP中訂定的資料災難備分與復原準則，雙鴻於2016年也著手建立異地備援機制，將屬於第一級復原時效的系統，列為異地備援對象，並選擇了IDC機房作為備援場所。林柏勳提到，當時曾考慮租用海外機房，後來他們考量管理便利性，像是進行還原演練需至機房做設定，而選擇了在臺的機房，不過他提到，考量災害威脅，該機房與自有機房位處不同區域。

DRP隨業務影響分析結果調整，以符合企業持續營運的需求

林柏勳強調，DRP非固定不變的辦法，而是隨著RTO、RPO和IT可行性分析結果的變動，而進行調整，再依新復原點的定義，重新進行系統測試及演練，最後，再進行系統維運。

然而，百密總有一疏，就在BCP訂定完成後的同年9月，中度颱風梅姬侵襲臺灣，造成全臺破百萬戶停電。位於新北市的雙鴻也是受災戶之一，停電約半天，導致其系統全面中斷，全球業務都受波及而停擺。林柏勳表示，以郵件系統造成的影響最劇，少了該系統，人員無法聯繫各地客戶，且當時該系統非異地備援的對象。

大停電讓雙鴻發現郵件系統的重要性，事後重新進行業務影響分析，而該系統的RTO和RPO皆提升，雙鴻進而調整DRP，來提升該系統的回復等級。郵件系統因而從原先需8小時復原，屬第二等級，縮短為現今4小時內復原，屬第一等級，並成為異地備援的對象。

除此之外，雙鴻在2017年翻新ERP時，也重新檢討了既有的備援計畫，進而調整還原演練的流程，訂定了新的DRP。面對當前的武漢肺炎（COVID-19）疫情，雙鴻甚至重新檢討了BCP，納入遠距工作機制使用VPN的抗疫對策。文⊙黃郁芸

過去Google通常是在3月的第二周，釋出新一代的Android預覽版，但此次Google提前於本周發表了Android 11的第一個開發者預覽版，該版將只適用於Pixel手機，而Google同時也公布了Android 11的開發時程表。

第一個開發者預覽版代表它是個早期建置，具備許多新功能、API及行為上的改變，但它的功能或API並不完善，主要著重於程式開發人員的意見回饋。

Android 11 Developer Preview 1改善了對摺疊螢幕手機、5G及來電過濾APIs的支援，有新的媒體及照相能力，也強化了機器學習能力。該版本更新了既有的連結APIs，讓開發人員更能利用5G的連線速度，例如Dynamic meteredness API可偵測到不限流量的網速，那麼就能提供更高解析度或品質的內容，而支援5G的Bandwidth estimator API，則可直接檢查上傳及下載頻寬。

為了因應新的手機螢幕設計，Android 11改善並新增APIs，以支援嵌入相機鏡頭（Pinhole）或是有弧度的曲面（Waterfall）螢幕。另有一個專替傳訊程式設計的Bubbles API，將可在多工的環境下，仍可檢視及存取對話。

在保護用戶的隱私上，Android 11 提供了一次許可（One-time permission）能力，讓使用者在必要的時候釋出位置、麥克風或相機存取權限予應用程式，但只限當次。

Android 11 Developer Preview 1目前只支援Pixel手機，包括Pixel 2、3、3a及4，而且只能手動安裝與更新。

根據Google的規畫，Android 11將有3個預覽版（Preview），分別在2月、3月及4月釋出，5月則會發表Android 11的首個測試（Beta）版，6月的Beta 2又被稱為Platform Stability，並在第三季釋出Beta及正式版。

Platform Stability將是定型的Android版本，有最終的內部與外部API、確定的行為與確定的非SDK灰名單，代表開發人員已可用它，來作為正式版程式的依據，不再有任何會影響程式運作的改變。

加密貨幣交易平台Coinbase本周對外宣布，該公司已取得國際發卡組織Visa的主要會員（Principal）授權，是Visa組織第一個純粹經營加密貨幣業務的主要會員，未來將提供更多的服務與功能予旗下的Coinbase Card客戶。

Coinbase去年4月就與Visa合作，在英國發行了全球第一張加密貨幣簽帳卡Coinbase Card，才9個月的時間，Coinbase Card已在全球29個國家發行，支援10種加密貨幣，且已有數百萬個商家接受Coinbase Card。合作當時Coinbase的身分，還只是Visa的準會員（Associate）。

主要會員與準會員是Visa最常見的兩種授權類型，準會員必須要依附主要會員，由主要會員為其擔保，至於主要會員則必須直接與Visa結算，但在服務上則有更多的彈性，理論上主要會員不只能發行金融卡，還能替其它業者提供金融卡的發行業務。而Coinbase的角色則由最初的準會員，升級到主要會員。

Forbes分析，直接成為主要會員替Coinbase省去了昂貴的中間成本，還讓Coinbase可替其它業者或平台發行簽帳卡。

不過，目前看來Coinbase尚無替其它業者發行簽帳卡的計畫，僅說此一身分將讓該平台提供更多的Coinbase Card功能，包括新增其它的服務或支援更多的市場，以改善用戶的加密貨幣支付體驗。

Coinbase的共同創辦人Brian Armstrong曾在今年初，提出未來10年的區塊鏈大預測，認為加密貨幣的用途將從2010年代的投機、投資、交易，轉變至實用階段，未來將應用在獎勵（staking）、借貸、簽帳卡、收入或商業上等。

Google發布自然語言理解平臺Dialogflow更新，改善其客服中心AI（Contact Center AI）服務，提供10倍意圖數量的Mega Agent，且新增代理驗證功能，自動檢查代理設計錯誤，而使用者也能夠簡單地創建多版本的代理，並將他們部署到不同環境。

Dialogflow是可用於創建虛擬代理的對話式人工智慧引擎，能以語音和文字作為媒介，回應使用者的查詢，而客服中心AI則能用來簡化傳統客服中心AI技術的應用複雜性，更簡單地建置自動語音應答、互動語音應答（IVR）以及電話聯繫網（Phone Tree）等功能，利用對話AI技術和客戶進行寒暄，並自然地引導客戶描述來電需求，甚至能回應像是帳單金額或是交通方式等簡單查詢。

Dialogflow現在提供稱為Mega Agent的代理人，可以回答客戶問題的數量，是一般代理人的10倍。當客戶說或是寫出一些內容時，Dialogflow會擷取客戶的請求，並將這些請求與代理最相近的意圖配對，因此更多的意圖數量，表示代理能夠更好地回應客戶。

一般的Dialogflow代理最多只能有2千個意圖，但是現在Beta測試版的Dialogflow Mega Agent，可以將多個Dialogflow代理組合成一個代理，並且擴充意圖數量10倍，達到2萬個意圖，Google提到，隨著意圖增加，客服中心AI可以更自然地與客戶對話，獲得更多處理使用者情境的能力，以滿足客戶需求並解決他們的問題。Dialogflow Mega Agent也讓開發人員可以簡單地管理Dialogflow代理，當企業中有多個團隊一起建構一個代理，則現在可以由每個團隊負責一個子代理，以更好的治理方式減少變更衝突。

Dialogflow也能幫使用者驗證代理設計，向客戶提供更好地對話體驗。Google提到，令人不滿意的客服體驗會讓企業失去客戶，且經過他們內部的研究，發現80％的品質問題都很容易解決。Dialogflow提供的代理驗證功能，可以幫使用者辨識錯誤，以創建品質更好的代理，盡可能消除與客戶的負面互動。

Google也在Dialogflow新增了一站式創建、測試和部署代理功能，使用者可以創建多個版本的代理，並將其發布到各種自定義環境中，像是開發、測試或是生產等，Google提到，這項功能讓用戶可以在Dialogflow代理中，測試不同版本、追蹤變更和管理整個部署過程。

Webhook管理API在這次更新達到正式版，使用者可以利用該API創建和管理Webhook，使企業能夠以更簡單的程式開發方式完成查詢，這個API本來只有Dialogflow控制臺可用，滿足日常數百萬筆的查詢，現在開放出來，將能加速企業設計代理的過程。

Google本周宣布，即將在Google Docs正式提供智慧撰寫與自動校正功能，不過，這兩項功能將只支援G Suite Basic、G Suite Business與G Suite Enterprise用戶，並不適用於教育版或一般用戶。

其中的智慧撰寫功能，可協助使用者寫出正確又優雅的文字，減少拼錯字或文法上的錯誤，也能提供文句撰寫建議。

至於自動校正功能，則會在使用者輸入文字的當下，即時幫使用者校正，校正過的文字底下會出現虛線，繼續寫不理它虛線就會不見，若不想被變更，只要將滑鼠移至被修改的單字，就能選擇將它復原。

這兩項功能都已從2月18日起，陸續部署至全球的G Suite用戶，預計15天內部署完畢，它們的預設值是開啟的，使用者也能選擇自行關閉。

不管是智慧撰寫或自動校正，都只支援G Suite Basic、G Suite Business與G Suite Enterprise用戶，並不適用於教育版、非營利組織版或一般用戶。

隨著國內武漢肺炎疫情出現了社區感染案例，在員工被感染的風險下，企業能否營運持續將成一大挑戰。對此，金管會近日對銀行祭出五大營運不中斷要求，金管會主委顧立雄今天也在記者會上表示，銀行局目前密切關注分行、子行在中國的營運概況，除了武漢的銀行未開業，其餘開業者均須採取必要防疫措施，比如輪班的人力調度機制，來分散感染風險；而疫情方面，目前未有臺籍的幹部確診，「不過一旦有人感染，我們要求銀行一定要通報！」

金管會日前發布五大營運不中斷要求，要求銀行遵守。首先，在國外應變措施方面，從1月底疫情開始時，就要求國內銀行於中港澳地區的分支機構，回報因應疫情採取的作法，包括員工健康情形、開始營業日期、上班方式等。第二，則是要求國內銀行研擬防疫應變措施，且需保持疫情訊息即時傳遞，若國內外從業人員有確診情形，使得該機構的辦公方式改變，就必須立即電話通報金管會。

第三，則是在環境方面，要求各銀行、總行、各分支機構，應經常實施辦公環境及營業場所的消毒工作，以消除感染源，確保人員安全。第四，在人力調度方面，應在尊重員工意願的原則下，研擬人力調度機制，來分散員工感染風險，總行也應提供各營業單位充足的防疫物資。最後，各銀行也應依照疫情等級，確實依據「金融事業機構災害防救作業要點」，來訂定災害緊急應變措施，且應由總經理擔任召集人，建立指揮中心，來監測各種可能情況、即時作出應變。

銀行局副局長黃光熙也對此說明，銀行面對緊急事件時，本來就有制定災難應變計畫，力求在法規允許範圍內維持營運持續，比如平時就設置異地備援機制，來確保核心系統不中斷等，「且因台灣疫情仍是有效控制，所以當前還是配合中央流行疫情指揮中心，來進行防疫即可。」

由於臺灣在庚子年春節起，都一直在武漢肺炎疫情籠罩下，尤其，中央流行疫情指揮中心在2月16日傍晚，公布臺灣第一起因為武漢肺炎死亡的第十九例確診病例，隨即引發社會大眾對於是否會爆發社區感染的恐慌。畢竟，武漢肺炎若爆發社區感染進一步擴展到社區傳播時，就會演變成「只要出門就是人人自危的時刻」。

對於企業而言，當然營運上會受到很大的影響。在中央流行疫情指揮中心陸續公布第20到23例武漢肺炎確診病例，以及相關的疫調內容時，隨之出現的這則公告，證實臺中潭子地區有一家木業公司，就是因為公司員工家屬確診為武漢肺炎，導致全公司20多人都必須自主健康管理14天。也因為員工不能到公司上班，連帶公司的訂單出貨也必須暫時中斷，直到3月1日相關人等解除自主健康管理後，才能恢復正常運作。

另一個例子，則是新加坡最大的星展銀行總部，也出現一名員工確診武漢肺炎，造成同部門300人必須隔離、淨空並消毒辦公司，所有員工則要開始實行遠距上班。

從臺灣到新加坡的案例，其實都是對企業的警訊。我們必須自問：如果公司有一個員工直接或間接受到感染武漢肺炎的影響時，公司還有辦法繼續營運嗎？可繼續提供服務嗎？

如果這個案例就發生在自家公司身上，明天所有員工都因為武漢肺炎而不能到公司上班的話，公司到底有沒有辦法面對這一場突如其來的風暴呢？

「居安思危、有備無患」就是營運持續管理的精髓

《左傳》：「居安思危，思則有備，有備無患。」公司在危急時刻若能持續營運，重點就是，要準備的夠多、想的夠深遠才行，這背後的邏輯，就是營運持續管理（Business Continuity Management，BCM）的概念。

以標準驗證公司臺灣BSI為例，該公司營運長謝君豪表示，為了確保未來有員工直接或間接感染武漢肺炎，或屆時臺灣爆發大規模社區感染，該公司還可以提供最低水準的服務，因此，早在第10例武漢肺炎確診案例公布後，臺灣BSI便決定展開為期約莫兩週的營運持續管理（BCM）正式演練。

他們演練的方式，就是實施分批上班政策，以及在家上班政策。包含全公司各個部門員工及主管在內，其中一半的員工和主管，於週一、三、五上班，另一半則是週二、四上班，當天若是不用到公司上班的員工和主管，則「強制」在家上班。

謝君豪說：「這次分批上班、遠距上班其實就是該公司BCM的正式演練，唯有真正透過一段時間的實際演練，才能發現在日常運作中，有沒有系統連不上、計畫不周全，以及可以進一步修正改進之處。」

爆發第一起武漢肺炎死亡案例後，因為這是社區感染的重大警訊，也促使許多臺灣企業必須儘快執行BCM的演練，他們希望一旦員工必須在家遠距上班時，公司相關系統能夠有周全的配套措施，以防萬一。例如，線上音樂公司KKBox就決定在2月20日，強制全公司同仁必須在家上班一天，實測各種雲端服務和VPN連網能否正常運作，確認包含視訊會議在內的系統都可正常運作。

透過設定誇張高風險情境，決定關鍵優先項目

臺灣勤業眾信風險管理諮詢公司副總經理田嘉雯表示，關於BCM的定義，大致可解釋為：「當公司無預警遇到大型災害事件時，公司是否有能力做災害控管。」然而，這其中也有一個但書，那就是：做了BCM，不表示可以保百年平安，重點在於認清現實、不要「鐵齒」。

「BCM的範圍最重要，」田嘉雯指出，很多公司會直接把BCM的工作丟給IT部門，但真正的BCM還是要跨到業務部門才完整。

臺灣勤業眾信風險管理諮詢公司執行副總經理曾韵表示，要落實BCM，可以分成三個階段來看。首先，從分析階段了解公司面臨的各種情境，進行風險評鑑（RA）和營運衝擊分析（BIA）；再者，透過發展階段，從組織與政策的建立，了解各種可用資源和緊急應變計畫、業務持續計畫、危機管理等階段；最後，透過實作階段，進行相關的教育訓練和演練測試。

田嘉雯進一步解釋，RA會先設定一些相關的高風險情境，這可以參考金融業自評時常見的高風險情境，包括：天然災害的地震、風災和水災等，人為災害的疾病與傳染病、火災與爆炸、網路連線通訊中斷等，或是資訊系統異常的駭客入侵、電腦病毒攻擊或資訊系統程式邏輯錯誤等。

她指出，RA的目的在於辨識高風險機率，決定哪一些是優先或關鍵的業務項目，如果公司過去曾經發生過高風險、導致公司營運或服務中斷的情境，這些都必須要先條列清楚。

但田嘉雯也觀察到，許多企業在進行風險評鑑時，往往情境設定都相對保守、不敢大膽假設，如此一來，反而無法從各種極端案例、同業經驗，或是英國BSI的地平線掃描報導等，去思考相應對方式。

BIA要設定最大可容許中斷時間和最低可接受服務水準

RA是許多國際標準都有的環節，但BIA則是參照ISO 22301才有的項目。而透過設定不同的高風險情境後，田嘉雯說：「接下來要關注的就是，當公司的服務中斷後，會對公司營運帶來多大的衝擊，這就是營運衝擊分析（BIA）。」這是一種自我了解評估的手法。「RA和BIA要一起做，可以利用問卷的方式，也是一種組織自評的過程。」她說。

BIA主要目的有二，首先，要決定「時間」：最大可容許中斷時間（MTPD），目的就是要把重要的業務服務和優先順序列出來；第二，就是確定恢復程度，怎麼樣是最低可接受的服務水準。

若要衡量哪些業務優先順序，就得訂定全公司一致的衡量標準，標準包括：1、影響多少業務量；2、影響多少營收；3、影響多少賠償金額；4、影響多少商譽損失；5、影響多少法遵要求等。至於如何計算MTPD合理的時間，最常見的標準作法就是，將上述衡量業務優先順序5個標準中，列出每一個標準真正無法接受的時間，那就是MTPD。

而MTPD會根據產能和服務來設定，關鍵點在於「有多少成本」和「有多少資源」投入。例如，當實體店面無法營運時，單一店面提供多少服務？牽涉多少客戶？是否有其他線上服務可以取代等？這也涉及究竟需要提供多少辦公室的後勤服務，以及有多少資訊系統作為復原中斷服務的支撐等。

但田嘉雯也說，臺灣很多產業並沒有規定最大可容許中斷時間（MTPD），而MTPD要個別訂定，且是當企業不得已中斷服務後，最核心的業務應該在多久時間內恢復的最短時間。

像是納莉風災引發的水災，當年就對臺北市某些銀行的營運服務造成中斷，而這些銀行要在多久時間內，恢復銀行最低程度的運作（例如找到其他場地、人力、系統等），就是MTPD。

簡而言之，MTPD就是高風險情境中的最大可容許中斷時間，相較於一般金管會要求銀行某些業務中斷，必須要4小時內恢復的概念，MTPD是不同的。

不過，要達到MTPD，曾韵認為，必須要從資源調度的角度來看，如何設定不同的工作項目的復原時間目標（RTO），恢復每個產品和服務的最低服務水準。

舉例而言，金融業必須在4小時內啟用異地辦公室，其MTPD就是4小時，但從接獲通知、移動到異地辦公室、到班人員清點與座位分配、記錄回報作業恢復狀況，直到協助組員申請異地辦公室門禁，每個工作項目都會設定不同的RTO，而且，因為不同工作項目有些時候會平行作業，透過甘特圖看不同作業的RTO之餘，要注意其絕對不能超過MTPD的作業時間規定。

但田嘉雯則提醒，每一個工作項目的RTO，例如，開機下指令的RTO必須在5分鐘內要完成，就必須清楚標註RTO是5分鐘，提醒執行任務的人員注意時間。

BCM不僅要人和資源投入，實際演練更不可少

田嘉雯表示，不管是RA或是BIA的問卷填寫，通常建議由資深同仁填寫，這麼做，可以知道過往發生的歷史事件和業務重點，而代表各部門填寫的人員，也必須了解業務中斷對業務帶來的衝擊；而資源分配與投入上，則包括：業務、場地（行政）、IT系統（AP、Infra、系統相依性等）。

若要成功推動BCM的必備因素，可包括：公司全員參與；高階主管由上而下的支持，加上適當的資源準備才行。

田嘉雯進一步解釋，推動BCM時，公司每個層級和部門都必須有代表參與，包括：業務、IT、人資、財務、行政及採購等，其中，要挑選參與的代表，就要找比較有影響力的人，或者是比較敢跟上級主管報告的人來擔任。例如，有一個酒商BCM的主管就是財務主管，因為包括IT和財務採購等部門，都在該名主管轄下。

另外，企業也可以找曾經推動過其他ISO制度認證的單位來幫忙，都很適合作為推動ISO 22301的單位。做完RA 和BIA後，高階主管必須要針對相關的備援方案制定決策。田嘉雯認為，高階主管的心態很重要，例如：針對各種分析，都不要鐵齒，而當風險發生時要願意承擔風險、敢做敢當。同時，要記住，認賠殺出也是接受風險的一種手段，不可以超過MTPD。

最後，資源準備度不可以太差。因為面對不同風險情境、不同MTPD和最低可接受服務水準，企業要投入的資源和成本是不一樣的，尤其針對高風險，更必須要有額外投入資源的心理準備。她指出，如果沒有資源投入，就要花時間開始準備，不必一口氣到位，但如果沒有開始投入，就永遠無法落實BCM。

完整的BCM包括緊急應變計畫（IMP），目的是希望可以將災害控制住，針對風險情境做RA；業務持續和業務復原計畫，則是透過BIA列優先順序和資源，包含人、地、系統等，再透過業務復原計畫，像是條列式的檢核表、有各種聯絡清單、資源盤點表（座位、筆電、Token等），不論人員是誰，他們皆可按表操課；最後則是危機管理，這裡面包含公關溝通和新聞稿撰寫。

有了計畫，還必須要透過演練，去確認計畫是否可行。田嘉雯表示，演練分成桌面演練和實際演練，以桌面演練而言，目的在於集思廣益，但問題在於真實性太差、可驗證性太低；至於實際演練，可驗證度優於桌面演練，但風險也較高，受影響的客戶可以事先通知，但要考慮的風險，還包括系統切換回來、恢復正常運作的時間。田嘉雯提醒，演練沒成功可以接受，但演練引發的風險則不可接受，例如：影響客戶、業務和服務等。

根據英國營運持續機構（BCI）發表的「2019年地平線掃描報告」，去年對全球帶來最昂貴的營運衝擊是「健康安全衛生事件」（Health and Safety Incidents），造成的損失高達11.86億美元（近新臺幣370億元），要對抗武漢肺炎這樣的傳染病帶來的損失，針對BCM投入的資源，永遠不會太遲。

 相關報導  武漢肺炎長期抗疫怎麼做？