迁移到云？ 当您转移到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