Servers 服務器

TL;DR 之前唸書時微軟送的 Windows Server 2012 己經不支援 Plex 和 Docker 這類新的應用。但又不想花錢買新的版本在一台主要是下載和家用影音的伺服器上。所以把作業系統全面改成 Linux 來取代相關的功能。

在打合約或工作聲明中。對於伺服器或雲端服務的反應時間 (response time) 和延遲 (latency)，以前都會用平均值 (average) 或中間數 (median) 來評量。但是只用平均值或中間數來看，會無法完整的看出整理的延遲反應。 就拿以下的圖表為例，當一個專業的網管，單純的看延遲反應，在下午一點五十一分左右，系統出現了不穩定。延遲衝到了800毫秒。一連持續到約二點零七分左右。直覺可能是其中一個服務器掛掉了。但又自我修復好了。　所幸暴衝不是一直持續，所以可能不以為意。 毫秒 圖一：系統３小時的反應時間 如果是早期的服務水平，這時候會調出平均服務圖表來確認整體的服務是不是有被影響到。一般的服務水平都會訂在 99% 的情況下，服務水平會在 200 或 250 毫秒以下。以平均表來看，在反應最慢的時候也都還在 160 毫秒內。所以看起來也是沒什麼異狀。　 圖二：系統３小時的平均反應時間 但是如果是使用 90 百分位數的圖表來看，那可就不同了。90 百分等級是一種描述統計指標。意思是指，在百分之九十位數 (90th percentile) 的正常狀況之下，服務狀況還是可以持續在 200 毫秒內嗎？　 圖三：系統３小時的90百分等級時間 圖三指出在十二點三十三分時，百分之九十的正常服務就己經飇高了。一直攀昇到一點五十一分到最高峯約 500 毫秒，之後才開始穩定下來直到約二點零三才恢復過來。那其實不穩定的時間比相象中更久，快要 90 分鐘系統的穩定性一直都是在服務平均水平之外的。 所以結論就是在管理系統時，不能只單看平均服務的數據來確定服務水平是否有達標。利用百分位數的圖表可以更了解系統淺在表現狀況。主統雲端服務都有提供百分位數的監控（如 AWS)，請大家多加利用。 參考文獻： 1. https://www.elastic.co/blog/averages-can-dangerous-use-percentile 2. https://azure.microsoft.com/zh-tw/support/legal/sla/cloud-services/v1_5/ 3. https://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Percentiles

有鑑於現在主流的瀏覽器會把一般的 HTTP 劃分成不安全未加密的網站，炒麵決定購入 HTTPS 認證讓本站也加入綠色認證的行列。雖然本站無廣告，無個資的疑慮，但就為在技術上不能落後，現在一 都連線都會通過 HTTPS 加密。還有，網站全面改版。新的板模是用Gantry5 的架構，更彈性更流暢。2019 一開始就來個新氣象。 開心啦！