減少Amazon EC2上託管的WordPress網站的停機時間

使用SIOS AppKeeper從無知變成幸福

WordPress是一個開放源代碼的內容管理系統（CMS），數百萬公司使用它來創建網站，博客或應用程序。據估計，如今有超過7500萬個使用WordPress的網站，許多公司開始在WordPress實例上託管Amazon EC2。 用戶喜歡WordPress的靈活性和創建和修改佈局的便捷性。如果您在網站上使用WordPress，那麼您的公司就很好。

如此眾多的用戶依靠WordPress來驅動其網站，您可以想像有一套旨在滿足這些用戶需求的豐富的第三方工具（插件和服務）。其中一些插件用於添加安全功能，例如用於探測漏洞的掃描儀。因為更多的插件可能導致更多的漏洞。

信任但要驗證。為什麼監視WordPress正常運行時間很重要。

部署未在WordPress上運行的網站或應用程序而沒有對其進行正確監控，就像讓您的車在外面運行並帶有鍵。您需要保護自己的投資。對於管理WordPress網站（或其他任何應用程序）的公司，有三個主要的監視原因：

1. 了解訪客並優化他們的體驗；
2. 監視站點的速度並確保其符合預期的服務水平協議（SLA）；和
3. 為確保您最大限度地延長正常運行時間。停機可能意味著（嚴重）失去了在WordPress上運行的任何電子商務網站的收入。

您相信自己的WordPress網站可以正常運行，但是您確實想知道發生了什麼。監視的目標應該是快速了解發生的情況和原因，以便您快速響應任何問題。

有各種各樣的工具可以幫助WordPress用戶監視其網站。其中一些非常專注於WordPress，例如ManageWP和JetPack，而另一些則是適用於許多不同CMS和應用程序的行業標準解決方案。有些“深入”並專注於監視的一個要素，例如Google Analytics（分析）及其對訪問者分析的關注，而其他一些則試圖“廣泛”並解決監視的所有三個關鍵方面。您決定使用什麼取決於您的預算，需求和技術能力。

在SIOS，我們相信最好的育種方法是有道理的。我們專注於監視應用程序，並確保我們的客戶在使用這些應用程序時所經歷的停機時間盡可能短。今天，我們的許多客戶正在使用SIOS AppKeeper來監視和保護其在Amazon EC2上運行的WordPress網站。

SIOS AppKeeper –簡單但功能強大的WordPress網站監控和自動修復

許多WordPress監控解決方案（從免費插件到低成本的免費增值服務）都會告訴您WordPress網站何時關閉。並且取決於監視解決方案的複雜程度（和成本），它可能會告訴您為什麼您的WordPress網站已關閉。但是，它會幫助您減少停機時間並在遇到停機時間時自動重新啟動服務或重新啟動實例嗎？

許多公司使用Apache或NGINX Web服務器將其WordPress網站託管在Amazon EC2上。SIOS AppKeeper是一項SaaS服務，可以將其配置為自動發現Amazon EC2實例及其服務上運行的WordPress網站或應用程序，然後在遇到停機時自動採取任何行動。因此，您不僅會收到發生某事的通知，而且會自動得到解決，而不僅會收到發生問題的警報。

停機時間很重要。如果您正在使用WordPress運行電子商務網站，則停機將導致收入損失。多少收入？只需將您的年收入除以365天和24小時（年收入/ 365/24），即可了解您的每小時收入。2013年，Google經歷了5分鐘的停運，這使他們損失了545,000美元的收入。 現在，您可能不是Google，但您確實希望盡可能地減少停機時間。

現在，想像一下當您收到WordPress網站已關閉的警報時會發生什麼。您準備好立即回應了嗎？您知道如何解決並恢復WordPress網站正常運行嗎？根據我們的客戶研究，僅使用三個Amazon EC2實例的普通客戶每月至少會經歷一次停機。

SIOS AppKeeper會監控Amazon EC2並提醒您任何停機時間，並通過重新啟動Amazon EC2服務或重新啟動實例來採取措施糾正這種情況。

AppKeeper會自動解決超過85％的客戶的Amazon EC2停機問題。這意味著您可以通知您已識別並解決了故障，而不必丟掉所有東西或損失任何可觀的收入。

如今，數百家公司依靠AppKeeper來保持其云環境正常運行。 我們邀請您觀看下面的視頻，了解安裝和使用AppKeeper多麼容易。

視頻：安裝AppKeeper並從AWS EC2故障演示中恢復

如果您喜歡自己所看到的內容，請隨時註冊AppKeeper的14天免費試用版。 AppKeeper的起價為每個實例每月40美元。

遷移到雲？ 當您轉移到Amazon EC2時，這是應該如何更改DevOps優先級的

大多數遷移到雲或創建“雲原生”應用程序的公司都使用Amazon Web Services（AWS）進行了遷移。AWS提供了許多成本和功能優勢。那些採用行業標準的開發人員運營（“ DevOps”）最佳實踐來監視和管理內部部署環境的公司通常會問自己如何適應新的雲環境和應用程序。

從本地應用程序遷移到Amazon EC2時，DevOps優先級將如何變化？這是兩者之間的區別以及您應注意的事項的解釋。

雲中的DevOps優先級？相同。 但是不一樣。

我們經常聽到客戶說，當他們遷移到AWS時，操作會更容易。 我們告誡他們，遷移到雲（甚至是AWS）並不意味著他們不再需要監視和管理其應用程序。

遷移到Amazon AWS的公司可以在硬件採購，供應和維護方面利用較低的成本和人力資源。但是您需要考慮到，當您決定在Amazon EC2上託管應用程序時，操作系統層以上的任何事情都是您的責任。

當涉及到Amazon EC2環境的備份/可用性保證/安全措施等時，優先級與本地應用程序相同。 亞馬遜提供了一些本地工具和功能。但是您需要確定它們是否適合需求。

安全，備份… 管理Amazon AWS環境時需要了解什麼？

那麼，在遷移到Amazon EC2時需要牢記哪些特定於AWS的注意事項？而什麼是最適合您的工具？您在設計應用程序上投入的時間以及如何部署和管理應用程序將為您帶來回報。

首先要考慮的是如何保護Amazon EC2應用程序。必須以與本地應用程序相同的方式來考慮網絡設計，例如“打開哪些端口”和“從何處允許訪問”。可以在AWS中使用安全組和網絡ACL（訪問控制列表）進行配置。

您可以使用AWS Trusted Advisor功能*，該功能會自動檢查您的AWS環境並指出是否將其設置為建議的設置，從而可以檢查公司的AWS環境中的安全性問題。我們建議在實施時並定期與AWS Trusted Advisor進行檢查。

安全性的另一個基本方面是身份驗證和訪問權限的管理。AWS將所有這些整合到AWS Identity and Access Management（AWS IAM）中。除了控制哪些人可以訪問哪些EC2實例之外，您還可以使用AWS IAM設置從EC2實例到其他資源（例如DB）等的訪問權限。一旦遷移到AWS，您需要做的第一件事是為了在AWS IAM中正確設置帳戶和訪問限制。

下一個考慮因素是“如何在Amazon EC2上備份我的應用程序？” Amazon EC2提供了拍攝快照的功能，您可以執行此操作。此外，使用“ Amazon Data Lifecycle Manager”可以輕鬆設置定期快照以及增量備份。快照文件存儲在Amazon S3存儲服務上。您需要根據其容量收費，因此您需要了解所擁有的數據量，並設置諸如“通過增量備份減少容量”和“從舊數據刪除”這樣的設置。

需要事先考慮“可用性”。 關鍵是根據系統的優先級來操作系統。

最後考慮的是可用性。對於Amazon EC2應用程序以及本地應用程序，您應該根據成本和系統重要性來考慮所需的可用性級別。 但是，如果您使用Amazon的Multi-AZ部署功能，則可以在不同數據中心之間指定冗餘配置。但是，使用多可用區比使用單可用區配置要花費更多（儘管不如使用冗餘本地系統那樣多）。在設計應用程序時，您需要考慮是否需要多可用區以及應該在可用性上投入多少。

如果您不投資於故障轉移，那麼您至少應該監視您的應用程序併計劃在遇到宕機時如何恢復它們。 您可以使用Amazon CloudWatch輕鬆監視CPU，內存和磁盤等常規項目，還可以對Amazon EC2自動恢復功能進行編程，以在EC2中發生錯誤時自動恢復實例。

如果您的應用程序是關鍵任務，那麼您將需要對其可用性進行更多投資。您應該考慮許多出色的第三方解決方案，它們為AWS社區提供了寶貴的功能。一種選擇是SIOS AppKeeper，這是一種易於配置和使用的解決方案，可監控您的Amazon EC2實例並自動重啟服務或在遇到系統故障時重啟實例。這是有關AppKeeper工作原理的快速視頻

雖然為您的應用程序遷移到云非常有意義，但是您不能放棄DevOps最佳實踐。Amazon AWS為您提供了豐富的功能和工具，但是您仍然需要對應用程序的安全性，備份和可用性承擔主要責任。您如何執行此操作取決於您的技能和應用程序本身的重要性。

我們邀請您加入使用AppKeeper的數百個客戶中，通過註冊服務的14天免費試用來減少其Amazon EC2停機時間。

*注意：要使用AWS Trusted Advisor，需要獲得業務支持或更高級的合同。

經SIOS許可轉載

擴展您的高可用性指標

在技術領域，我們喜歡數據。我們喜歡有關數據的數據以及我們工具可以帶來的所有指標和度量。我們圍繞分析技術創建了行業，這些產品可以捕獲數千個已連接設備的每個細節。我們喜歡指標和措施。在更高可用性空間中的許多情況下，我們喜歡高可用性指標，這些指標告訴我們系統從故障中恢復的速度。我們計算並跟踪檢測和修復之間的時間，我們著迷於了解和衡量在災難，系統故障或磁盤崩潰中會丟失多少事務數據。

具有諷刺意味的是，在高可用性和災難恢復（HA / DR）系統中，有些指標沒有引起足夠的重視。

以下是管理環境時應注意的其他八個高可用性指標：

1。  安全警報

可用性不僅涉及應用程序監視和恢復。  公開可用的系統總是受到攻擊。  如果您不監視安全警報和警告，則您的應用程序可能會完美運行，而您的知識產權卻可以完美無缺地被轉移。

2。空閒連接

空閒的連接聽起來無害，但它們幾乎和南部草坪上的綠葉葛根一樣無害。  空閒連接會佔用資源，並有可能填滿數據庫池，擁塞網絡和窒息性能。  此外，空閒連接可能表明應用程序層或數據庫配置存在問題。

3。長期運行的查詢，命令或作業

這不僅適用於數據庫查詢或作業，還適用於命令和備份。  長時間運行的查詢，命令和作業可能表明系統運行狀況不佳，磁盤速度降低，CPU或其他資源爭用，或者係統，應用程序兼容性或操作系統存在更深層次的問題。

4。磁盤IO

磁盤IO通常是指與磁盤活動有關的系統的輸入/輸出操作。測量磁盤I / O可以幫助確定瓶頸，給定工作負載的硬件配置不正確，磁盤大小不正確或磁盤佈局調整不當。  監視磁盤I / O可以幫助您告訴您長時間運行的查詢是否是由於不良的sql語法，不良的應用程序編碼或延遲和訪問問題引起的。

5，記憶

我們都考慮要使用多少內存，但是內存監視不只是衡量和查看可用內存還是已使用內存。  監視內存可幫助您調查瓶頸，洩漏，識別大小不正確的系統，了解負載，平均負載和峰值。  此外，了解內存密集型模式可以幫助您調整可用性套件，以避免錯誤的故障。

6。磁盤空間

作為客戶體驗副總裁，我曾經有過一次很不幸的經歷，要在清晨醒來緊急呼叫。  停電後，客戶面臨停機生產系統。  當他們嘗試重新啟動系統時，受保護的應用程序無法啟動。  快速檢查錯誤日誌後，很明顯根驅動器已100％充滿。  該應用程序無法寫入任何文件系統。  磁盤空間監視有多種形式和方法，將其作為度量標準可以防止不必要的問題和增加更多成本的最後一刻爭奪。。

7 錯誤和警報

日誌中的錯誤，警報和恢復消息是要考慮的另一個很好的指標。  您的可用性解決方案可能會使您的客戶保持在線狀態並感到滿意，但也可能掩蓋了需要盡快引起您注意的問題。  為FATAL，PANIC和關鍵ERROR消息添加日誌監視可以幫助您確定可用性解決方案經常從中恢復的問題，例如數據庫崩潰，應用程序緊急情況或核心轉儲，或者需要冷重啟的致命錯誤。

8。恢復編號

與監視錯誤和警報類似，恢復編號可以告訴您很多有關係統可用性的信息。  如果您平均每週要進行一次以上的應用程序恢復，則可能會遇到比正常的可用性保護更多的事情。  儘管恢復成功地重啟了您的應用程序或系統，但這些錯誤甚至真實的恢復中有太多是不健康的。

我們可以監控的HA / DR指標列表以及用於監控它們的工具正在飛速發展。  確保您和您的團隊考慮擴展當前的數據捕獲和分析，以包括那些可能構成最佳更高可用性系統的數據。

—客戶體驗副總裁Cassius Rhue