小心AP突然重開機！明早多一閏秒，VMware、甲骨文、思科皆呼籲MIS要盯緊

在不到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秒的錯誤時間值，程式若未能處理這樣的例外也可能導致出錯。而思科也列出了可能會可能受到閏秒影響的多款產品，如Nexus1000v及Nexus 5000系列的交換器。

阿光我不是什麼「MIS」人員，當然是看不懂「有閏秒標是的NTP封包」是啥東東？只不過「出現相同的時間戳記（Timestamp）」就會「鎖死，導致系統必須重開機」這也太爛了！