網站效能異常問題的案例回顧

最近讀到 Ars Technica 網站的一篇文章《I abandoned OpenLiteSpeed and went back to good ol’ Nginx》，其內容勾起了 DR 幾年前在虛擬主機商做工程師的一些回憶。呃，所以本文並不是要對該文章所涉及的技術議題做出回應；而是想借題發揮，在分享該文章的同時，順便陳述自己當年曾經遇到的一個網站效能異常問題。

雖然當時勢必有在工單系統裡保存較為詳細的案件資料及備註，不過已事隔多年，如今 DR 自己也已經不太記得細節了，所以只能憑大略的印象來描述。話說有一位客戶反映他們放在主機上的網站不知何故，以往都是正常的，卻開始會卡住無回應。於是 DR 翻查了一輪，包含網站的程式碼在內，最後發現問題是發生在 PHP 裡與 iconv 有關的函式上，例如 iconv_mime_encode()。某些理應要能夠正常處理的輸入值，執行時會異常地產生相當高的負載，而且最後也不會有正確的執行結果，以致網站失常。倘若進一步測試，則會發現異常僅存在於特定的 PHP 版本，若切換至其它版本則不會再有異常情形。

回頭查詢 PHP 套件供應商的更新記錄，發現近期確實是有與問題點相吻合的更新項目，估計是更新內容反過來引致新的問題（regression）。於是便將問題回報給供應商，並附上測試案例。後經供應商確認並釋出更新的套件後，如此便徹底修正了此問題。

這種軟體更新後出現問題的案例，一旦發生後，同事間很容易都會再次勾起一個話題，那就是放任主機系統自動更新的風險。是的沒錯，在 DR 當時的工作經歷裡，令人訝異的其中一件事，就是每部 Linux 主機的 yum 套件更新都是完全依賴自動排程，而沒有任何人為監督涉入其中──這完全打破了 DR 對於如何妥善地維護伺服器系統的認知。軟體保持更新固然重要，但倘若放任更新自動地進行，並且對更新內容一無所知，則恐怕會產生新的風險。

幾乎很容易就可以直接想到的一種修正方案，是建立一個驗證環境，將所有的更新先實施在這個環境中。並且根據過往的案例、或者是對狀況的預估，來建立多個測試項目。然後在驗證環境通過測試後，再將更新進一步套用到生產環境中。而套用更新的主機數目也可能是漸次地，而非一次性對所有主機實施。雖然並不是說這樣就一定可以防堵到，例如前文所描述的 PHP 異常問題。但起碼是在工程方法上有加入一道可按需求補強的事前檢測階段。而非好像只是雙手一攤，一且都等到事後有狀況了再來處理。

至於為什麼這樣的方案，好像是僅存在於口頭上的閒談，而沒有實際成為公司的新政策。其實 DR 也必須承認，自己並沒有很積極地提出這項改變。或許部份因素，是公司平日運作事情的氛圍，讓人不太有意願想從下而上做出提案，通常 DR 更寧可做一些只需要自己一個人就可以默默地實現的事情。以及另一方面，平日的工作內容，光是處理客戶問題大概就飽了，讓人也不是很想要多花心力在一些更加政治性的層面上。

在這個工作經歷裡，除了前面所提到的案例外，還有處理過許多各形各色的網站或系統失常問題，且各自都有不同的令人詫異之處。不過若是通通都寫在同一篇文章裡，則恐怕會顯得太過凌亂。所以可能還是得留待之後若有其它可借題發揮的時刻，就再憑印象交代一下了。