减少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 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