圖片來源: 

國家時間與頻率標準實驗室

在不到24小時之後,全球時間將因閏秒調整而多出1秒,臺灣也將在7月1日上午8時實施閏秒。儘管過去也經歷過多次閏秒調整,但經濟部標準檢驗局近日更提醒,這是從1997年以來,首次在非假日實施閏秒調整,呼籲資訊業、金融業及期貨交易等系統管理人員必須提防閏秒對資訊系統造成的影響。

不少IT軟硬體業者如VMware、甲骨文、思科等,近日也紛紛在官網上警告,閏秒可能導致特定應用系統突然重開機,或導致系統滿載,紛紛建議MIS當天得緊盯系統時間的閏秒調整過程以防萬一。而網路業者如Amazon或Google則是早早就做好因應準備。

如VMware在官方產品說明網頁上表示,配置了NTP用戶端程式的系統會有潛在風險,當天這類系統會收到有閏秒標是的NTP封包,如果企業的系統未針對閏秒進行調整,排程機制可能因為出現相同的時間戳記(Timestamp)而鎖死,導致系統必須重開機。或是Java環境也可能因為無法對閏秒進行例外處理,造成CPU使用率達到100%,進而讓服務中斷。部分產品若沒有啟用slew模式,也可能無法處理60秒的時間戳記。

甲骨文官網上則提醒,雖然Java API已每一秒定義為介於0至61的數字,以防範閏秒的發生,但是有些應用程式僅定義1分鐘為60秒,一旦遇到閏秒調整可能會導致應用系統出錯。因此,甲骨文建議,系統管理者在閏秒發生的時間內更加關注系統的狀況。另外,舊版MySQL (5.1.31以前的版本),也可能因系統回傳了閏秒,而導致呼叫Now()函數時傳回59分61秒的錯誤時間值,程式若未能處理這樣的例外也可能導致出錯。而思科也列出了可能會可能受到閏秒影響的多款產品,如Nexus1000vNexus 5000系列的交換器。

上一次的閏秒出現於2012年,除知名網站如Yelp、FourSquare、LinkedIn受影響外,澳洲航空及澳洲維珍航空的報到系統亦當機,導致數百名旅客班機延誤。為避免閏秒導致服務中斷,Google及AWS也做出準備。如Google的網站可靠度工程師Christopher Pascoe表示,Google在每次更新時,NTP就會多幾毫秒,直至閏秒出現時,NTP就會填補好這一秒。而AWS則把多的1秒平均分攤在閏秒出現前的24小時,讓系統每秒都增加 1/86400 秒,累積24小時之後就會恰好填補完多的1秒。

各國金融交易市場亦採取不同方式因應閏秒,如美國芝加哥商品交易所(CME)與洲際交易所(ICE)預計把6月30日的夜間電子開盤時間延至美東晚間8點後,日本則計畫將閏秒前的秒數延長以稀釋閏秒,澳洲與南韓將稀釋閏秒後的數秒,新加坡將等到閏秒結束後再進行時間校正,而歐股此時大多休市並不受到影響。

根據證交所發布的公文顯示,證交所將並不會變更系統的時間,而是在當日收盤結束並待相關的交易程序都完成後,再進行系統校時作業。此外,證交所表示,由於其交易行為都在國內市場,所以交易並不會受到閏秒的影響。證交所副總經理黃乃寬日前也對媒體解釋,因為證交所與券商在6點就已連線並完成假開盤,如果照原本的時間調整,會出現各家系統時間不同步的狀況,因而選擇在收盤後才調整。而期交所則表示,為讓交易正常進行,也同樣會等到隔天交易前,才會對照中央標準時間來校正系統時間。

 

熱門新聞

Advertisement