避免 CMS 災難：如何防止網站停機

一個網站被認為是關閉實際上意味著什麼？

這通常取決於你問誰。

對於一個網站被認為是關閉的，它可能意味著許多不同的事情：

• 該網站完全不可用。
• 該網站在線，但速度慢得無法使用。
• 該網站正在為某些用戶或位置提供錯誤消息。
• 該網站適用於大多數訪問者，但有些訪問者根本無法登錄到他們的 CMS，例如創建、編輯或發佈內容。

無論原因或程度如何，網站停機的影響都可能很嚴重，從電子商務訂單丟失和用戶沮喪到客戶信任度下降。

在我們避免 CMS 災難系列的第三部分中，我們探討了網站停機的經典根本原因以及持續監控和其他因素在避免這種情況中所起的作用。

一、持續監控的作用

我們監控網站的不同方面，因此我們可以判斷構成我們完全託管的 WordPress VIP 平台的任何不同層何時出現問題。 這些層包括：

• 網絡連接
• 負載均衡器
• 網絡服務器
• 對象緩存 (Memcached)
• 數據庫
• 彈性搜索
• 文件服務 (CDN)

我們嘗試及早發現問題，以便我們可以預測可能影響網站穩定性的未來問題。 來自不同系統組件的交叉引用日誌允許我們查看報告網站不穩定的時期。 因為可能是多種因素而不是單個問題導致停機，所以我們使用了許多工具來比較系統和應用程序之間的數據。

在大多數情況下，網站不穩定是由於應用程序代碼，即自定義或第三方 WordPress 主題和插件代碼造成的。 以下是我們在調查不穩定站點時需要注意的一些事項，以及如何緩解這些事項。

緩存不夠

確保網站高性能和穩定的最重要的事情是確保任何可以緩存的完整頁面都被緩存。 每次請求時都需要在服務器上構建未緩存的頁面，這是一個較慢的過程，更容易出錯。

WordPress VIP 答案：

WordPress VIP 平台通過邊緣緩存服務器的全球網絡提供強大的頁面緩存，每個邊緣緩存服務器都用於存儲和提供最接近最終用戶的內容。 邊緣緩存服務器的響應時間幾乎總是比繞過頁面緩存並命中源服務器的任何東西快一個數量級。

緩存挑戰

因為他們需要個性化、完全交互的體驗，一些網站，尤其是電子商務網站，根本無法在頁面緩存級別進行緩存。

通常可以找到一種折衷方案，即靜態頁面由邊緣緩存提供服務，並通過 JavaScript 添加動態特徵（例如，登錄狀態、購物車）。 然後可以使用來自 JavaScript 的異步請求與 WordPress REST API 端點進行通信，該端點的設計開銷比整個頁面加載低得多。

或者，這就是對象緩存發揮作用的地方。 頁面可以保持動態，但頁面的一部分和其中使用的任何數據都可以在對象緩存中存儲和檢索，以避免需要查詢數據庫。

WordPress VIP 答案：

每個 WordPress VIP 應用程序環境都有自己專用的 Memcached 集群，它將對象緩存數據存儲在內存中，以便快速高效地檢索。

未經測試的代碼部署

這是網站停機的另一個常見罪魁禍首，而且很容易根據純粹的因果關係進行診斷。

如果您的網站剛剛部署了未經測試的代碼，從而導致了直接的網站問題，則可能是您的原因。 如果可以的話，盡快將可疑代碼恢復到以前的版本。

避免這種情況的最好辦法是什麼？ 在發佈到生產環境之前，在單獨的開發或暫存環境中徹底測試每一段代碼。

WordPress VIP 答案：

因為我們所有的站點部署都是通過 GitHub 進行的，所以 WordPress VIP 客戶可以輕鬆地自行還原代碼，而不會丟失任何新的代碼更改，這些更改仍安全地存儲在 GitHub 修訂歷史記錄中。 或者，在緊急情況下，我們可以獨立於 GitHub 代表客戶將網站回滾到之前的部署。

關於環境，託管在我們完全託管的服務上的所有應用程序都可以具有單獨的開發或登台環境。 從生產中同步數據很容易，讓您可以針對與生產網站上相同數量和相同類型的數據測試代碼。

PHP 錯誤

WordPress 在服務器上使用 PHP 代碼。 PHP 錯誤可能是“致命的”，這意味著一旦發生錯誤，網頁、腳本或命令將停止運行。 這些幾乎總是以可見錯誤的形式出現在某個地方，並將記錄在 PHP 日誌中。

注意：PHP 7 中的一些 PHP 警告在 PHP 8 中會變成致命錯誤，因此認真對待這些錯誤很重要。

WordPress VIP 答案（加上有用的建議）：

我們的平台會自動記錄所有 PHP 錯誤，讓 WordPress VIP 客戶在他們的儀表板中和我們的工程師都可以使用它們。

專業提示：解決並修復所有 PHP 錯誤——即使網站看起來運行良好。 通常，我們會在看起來穩定的站點上看到充滿 PHP 錯誤的日誌，甚至是致命錯誤。 但是，這並不一定意味著該站點運行正常。 通過解決小錯誤和警告來保持 PHP 日誌清晰，可以在調試過程中更容易地發現更嚴重的錯誤。

緩慢的 MySQL 數據庫查詢

每個 WordPress 網站都使用數據庫來存儲網站內容和配置數據。 數據庫查詢獲取網頁的內容數據，但有時這些查詢的編寫效率很低。 它們可能適用於只有幾百頁的網站，但在處理大量數據時會停止（我們平台上的一些網站存儲了數百萬條記錄）。

緩慢的查詢會佔用數據庫資源，可能會影響站點的穩定性——不僅僅是頁面、腳本或運行 SQL 的命令，而是整個應用程序。 站點經常遇到困難，因為單個或多個數據庫查詢速度很慢，例如，任何執行時間超過 0.75 秒的查詢。

WordPress VIP 答案：

WordPress VIP 通過為每個應用程序提供一個專用的數據庫集群來幫助緩解數據庫瓶頸，該集群具有一個主數據庫，所有數據庫寫入查詢都在其中發生，以及一個或多個只讀副本數據庫。 這增加了可以同時進行的數據庫查詢的數量，從而在站點處於壓力之下時分散了資源負載。 也就是說，緩慢的數據庫查詢並不總是通過添加額外的數據庫資源來解決。 這就是為什麼我們建議客戶使用 Query Monitor 和 New Relic（由我們的平台提供）來監控慢速數據庫查詢。 這些突出顯示查詢源自數據庫的位置，因此您的開發團隊可以重構它們以優化性能。

最後，我們的應用支持和高級工程師還可以幫助您的團隊查找和分析這些查詢，並提出改進它們以提高速度和效率的方法。

數據庫寫入過多

有時，諸如自定義日誌記錄或跟踪代碼之類的功能會在每次請求時更新數據庫。 這可能導致不穩定，原因有兩個：

• Foregoing database replicas ：所有寫查詢都指向主庫； 在同一頁面請求中對同一表（或多個表）的後續數據庫查詢也將被定向到那裡。 由於不利用數據庫副本，這限制了站點的可擴展性。
• 繞過頁面緩存：為了在每個頁面請求上發生數據庫寫入，必須繞過頁面緩存。 但這樣做意味著第一道（也是最好的）防線已被攻破。

WordPress VIP 答案：

在這些情況下，我們建議重構該功能。 例如，內容分析通常最好委託給在頁面中使用 JavaScript 片段的外部服務，而不是服務器端代碼，後者不能很好地用於緩存，並可能導致過多的數據庫寫入。

其他已知的停機原因以及如何避免它們

插件

WordPress 生態系統中有數千個流行的、有用的第三方插件，它們提供了出色的特性和功能。 但是，有些人在擴展方面面臨挑戰，當添加到具有大量內容和流量的網站時，可能會導致停機問題。

WordPress VIP 答案：

作為優秀的生態系統管家，我們會定期向供應商提供建議，以使他們的插件在高流量環境中表現更好。 我們還可以建議已在我們的平台上大規模嘗試和測試的替代插件。

自定義日誌記錄

自定義日誌記錄是一種強大的調試工具，通常是追踪似乎僅在生產站點上發生的錯誤或問題的唯一可行方法。 然而，在許多情況下，我們已經看到在高流量站點上用 PHP 構建的自定義日誌記錄會減慢速度，或者由於過多的數據庫寫入而使站點處於停機危險之中。

WordPress VIP 答案：

對於客戶，我們在 WordPress VIP 應用程序儀表板的運行狀況面板中提供對標準 PHP 日誌的訪問。 他們可以在那裡記錄自定義錯誤（也可以記錄到 New Relic），這不會對數據庫產生負面影響。

遠程 API 調用

一些網站利用對其他應用程序或服務的服務器端 REST API 調用。 這些在正常情況下非常快，但有時底層應用程序代碼會導致響應緩慢、超時或拋出錯誤。

WordPress VIP 答案：

為了盡量減少這些問題，我們建議“防禦性編碼”。 這取決於遠程調用的目的，但通常當遠程請求失敗時，可能會退回到先前請求的緩存響應——或者至少“優雅地處理錯誤”，以便頁面的其餘部分可以仍然加載。 我們提供了許多幫助函數來處理這些場景。 保持低超時還意味著如果遠程 API 沒有響應，PHP 資源可以更快地釋放。

在我們的避免 CMS 災難系列中了解更多信息

當您的業務上線時，您無法負擔將新業務發送到其他地方並通過讓您的內容管理系統 (CMS) 提供糟糕的數字體驗來玷污您的品牌。 在如何提高網站性能中，我們診斷出五個常見的減速罪魁禍首，以及如何使用敏捷的 CMS 加速事情。

高流量的日子應該值得慶祝，而不是讓工程師們集體退後一步，努力保持網站和應用程序正常運行並嗡嗡作響以處理負載——以及你的聲譽完好無損。 在為高流量擴展 WordPress 中，我們探討了四種使 WordPress 網站能夠處理這些流量潮汐的方法。