减少停机时间的3种策略

介绍

随着企业和其他组织越来越依赖基于 Internet 的服务，开发人员和系统管理员将注意力集中在创建可靠的基础架构上，以最大限度地减少代价高昂的停机时间。

网站、API 或其他服务不可用可能会因销售损失而产生巨大的金钱成本。此外，停机时间可能会导致：

不满意的客户和用户： 用户期望稳定的服务。中断可能会导致更多的支持请求和对您的品牌的信心普遍丧失。
生产力损失： 如果您的员工依赖服务来完成工作，那么停机时间意味着您的组织失去了生产力。此外，如果您的员工花时间重新启动服务器并与停机时间作斗争，那么他们并不是在开发新功能和产品。
不开心的员工： 频繁的停机警报会导致警报疲劳，并且不断争先恐后地解决问题可能会损害您的团队和他们的士气。

为解决这些问题而联合起来的现代领域称为 站点可靠性工程 或 SRE。 SRE 于 2003 年在 Google 创建，他们开发的策略被收集到一本名为 Site Reliability Engineering 的书中。阅读该领域是探索减少停机时间的技术和最佳实践的好方法。

在本文中，我们将讨论三个方面的改进可以为您的组织减少停机时间。这些领域是 监控和警报 、 软件部署 和 高可用性 。

这不是一个详尽的策略列表，而是旨在为您指出一些在提高服务的生产准备情况时应该考虑的常见解决方案。

1. 监控和警报

正确监控您的基础架构将使您能够主动观察即将发生的问题，提醒您的团队注意问题，并更轻松地调查以前停机的原因。监控涉及聚合和记录统计信息，例如系统资源利用率和应用程序性能指标。通过根据当前指标不断评估警报规则以确定何时需要采取行动，警报建立在此指标集合之上。

监控通常由每个主机上的客户端实现，该客户端收集指标并向中央服务器报告。然后将这些指标存储在时间序列数据库（专门存储和搜索带时间戳的数字数据的数据库）中，并可用于图形、搜索和警报。监控软件的一些示例是：

Prometheus 可以从各种官方和社区支持的客户端（称为 exporters）中提取数据。它具有高度可扩展性，具有内置警报，并且具有可用于大多数编程语言的客户端库。
Graphite 提供了一个现在无处不在的 API，被数十种编程语言和应用程序支持。指标从节点推送到中央 Graphite 安装，在那里它们被存储和绘制。

将日志文件推送到中央服务并解析它们以获取相关指标（例如异常和错误率）也很常见。 Elastic stack（Elasticsearch、Logstash、Kibana）和 Graylog 是有助于日志文件解析和分析的软件堆栈示例。

监控哪些指标

在尝试提高可靠性和减少停机时间时，收集哪些最有用的指标？

大多数监控客户端和导出器都有一组默认指标，这是一个很好的起点，但您的应用程序或服务将有独特的需求，您在决定导出哪些度量时需要考虑这些需求。值得庆幸的是，SRE 文献有一些关于什么是最有用的监控指标的一般指南。这些指标被分组为 四个黄金信号 ，从 SRE 书籍中总结如下：

延迟：响应请求需要多长时间。例如，服务器对 HTTP 请求的响应时间。
Traffic： 您的系统正在经历多少需求。这可能是 Web 服务器的请求率、网络 I/O、每秒登录数或数据库每秒事务数。
Errors：事务或请求的失败率。请记住，并非每个错误都像 HTTP 500 错误一样明确。例如，您的策略可能是客户端应在 500 毫秒或更短的时间内收到响应。在这种情况下，任何具有较高延迟的响应都应显示为错误。
饱和度： 服务有多“满”。这可能是测量硬盘驱动器上的可用空间、网络吞吐量，甚至是 CPU 绑定服务上有多少可用 CPU。

可视化指标

设置好监控系统后，您将想要探索正在收集的数据。 Grafana 是一个软件包，它通过图表和仪表板提供非常灵活的指标探索。可视化可以从多个后端数据源聚合，包括 Graphite、Prometheus 和 Elasticsearch。

设置警报

除了可视化您的指标之外，您还需要设置一些方法来在出现问题时自动提醒您的团队。 Grafana 具有警报功能，Prometheus 通过其 Alertmanager 组件具有警报功能。其他允许您为指标定义警报规则的软件包包括 Nagios 和 Sensu。

如何构建警报系统将在很大程度上取决于您的组织。如果您有多个团队，警报可能会直接发送给负责行为不端服务的团队。或者，您可能有一个计划的待命轮换来处理特定时间段内的所有警报。警报可以通过电子邮件、推送通知或第三方寻呼服务发送。

要记住的主要事情是，目标应该是尽可能少地发出警报，并且只针对您的团队可以立即采取行动解决问题的事件。过多的警报，或针对实际上无法修复的情况的警报会导致 警报疲劳 。这种疲劳会导致员工不开心，他们可能会错过或忽略是关键且可操作的警报。

SRE 书中总结了一些设置警报时要牢记的原则：

* 每次寻呼机响起，我都应该能够以一种紧迫感做出反应。在我变得疲倦之前，我每天只能以紧迫感做出几次反应。

每个页面都应该是可操作的。
每个页面响应都应该需要智能。如果一个页面仅仅值得机器人响应，那么它不应该是一个页面。
页面应该是关于一个新问题或以前从未见过的事件。

如果您的警报不符合这些标准，最好将其发送到优先级较低的票务系统或日志文件，或者完全删除警报。

有关设置一些开源监控和警报系统的更多信息，请参阅下面的相关教程。

相关教程：

2. 改进软件部署

另一个可能影响停机时间的领域是您的软件部署策略。如果您的部署过程需要多个手动步骤才能完成，或者过于复杂，那么您的生产环境可能会大大落后于您的开发环境。这可能会导致风险更大的软件发布，因为每次部署都会变成一组更大的更改，并具有更多潜在的复杂性。这反过来会导致错误，减慢开发速度，并可能导致无意中部署降级或不可用的服务。

这将需要一些前期时间和计划来平滑您的部署，但最终，提出一个允许您自动化代码集成、测试和部署工作流程的策略将导致生产环境更加紧密匹配开发——更频繁的部署和更少的发布之间的复杂性。

CI/CD 最佳实践

随着当今可用的容器技术、配置管理软件、编程语言和操作系统的多样性，有关如何自动化部署的具体细节超出了任何一篇文章的范围。一般来说，一个好的起点是确保您遵循有关持续集成 (CI) 交付 (CD) 和软件测试的最佳实践。其中一些最佳实践包括：

维护单一存储库： 每个人都应该定期将代码集成到同一个存储库中，其中应该包含在相对裸机或 CI 环境中构建项目所需的一切（包括测试和配置文件）。这确保了每个人都在使用类似的代码库，集成相对轻松，每个人都可以轻松地测试和构建他们的更改。
自动化测试和构建： 你的 CI 软件或服务应该能够自动运行测试和构建你的项目。
自动部署： 您的 CI 软件应该能够在与最终生产环境紧密模拟的测试环境中部署和测试构建。

这些实践描述了一个持续集成和交付环境，但它们并没有让我们一直到生产部署。有可能——如果你对自动化测试有足够的信心——你可能会对自动化部署到生产环境感到满意。或者您可以选择将其设为手动任务（或者更确切地说，是需要人工判断才能启动的自动化任务）。

无论哪种方式，您都需要一种方法将新版本推送到生产环境，而不会导致用户停机。如果频繁部署涉及在基础设施更新时服务中断，则将带来很大的不便。

蓝绿部署

实现安全最终推向生产的一种特定方法——版本之间的无缝切换——称为 蓝绿部署 。

蓝绿部署涉及在可以轻松在两者之间切换流量的机制背后设置两个相同的生产环境。这种机制可以是一个浮动 IP 地址，可以在蓝色或绿色服务器之间快速切换，或者是一个负载均衡器，用于在多个服务器的整个集群之间切换。

在任何时间点，只有一个环境（在本例中为蓝色）处于活动状态并接收生产流量。发布新版本的过程是：

将构建推送到非活动环境（此示例为绿色）。
在此生产环境中测试构建。
如果所有测试都通过，则通过更新负载均衡器配置或将浮动 IP 分配给绿色服务器来切断到绿色环境的流量。

这种技术的另一个好处是提供了一个简单的机制，可以在出现任何问题时回滚到以前的版本。在您对新版本感到满意之前，让之前的部署保持启动并处于待机状态。如果需要回滚，请再次更新负载均衡器或浮动 IP 以恢复到之前的状态。

同样，有很多方法可以以安全和容错的方式实现部署过程自动化的目标。我们在这里只强调了一种可能性。下面的相关教程有更多关于开源 CI/CD 软件和蓝绿部署的信息。

相关教程：

3. 实施高可用性

减少停机时间的最后一种策略是将 高可用性 的概念应用于您的基础架构。术语 高可用性 概括了设计冗余和弹性系统的一些原则。这些系统通常必须：

消除单点故障： 这通常意味着多个冗余服务器，或冗余容器化服务。还在考虑在多个地区的多个数据中心之间传播基础设施的可能性。您消除这些瓶颈的深度取决于您对成本和复杂性的容忍度，以及您的组织和用户的需求。例如，并非所有服务都需要冗余负载平衡器和区域之间的自动故障转移。
无缝重定向流量：为了最大限度地减少停机时间，切断服务器之间的流量必须快速，服务中断最小。
检测冗余系统的健康状况： 通知决定何时重新路由流量，系统必须能够确定服务何时失败。

使用负载均衡器升级 Web 服务器

升级到更高可用性基础架构的一个示例是从单个 Web 服务器迁移到多个 Web 服务器和负载平衡器。负载均衡器将在 Web 服务器上执行定期健康检查，并将流量从那些失败的服务器中路由出去。如上一节所述，此基础架构还可以实现更无缝的代码部署。

提高数据库弹性

另一个增加弹性和冗余的例子是数据库复制。例如，MySQL 数据库服务器具有许多不同的复制配置。 Group replication 的有趣之处在于它可以在冗余服务器集群上同时启用 read 和 write 操作。您可以在多台服务器之间进行复制，而不是将所有数据都放在一个容易停机的服务器上。 MySQL 将自动检测故障服务器并绕过问题。

新的数据库，例如 CockroachDB 正在从头开始构建，并考虑到这些冗余复制功能，从而可以在多个数据中心中的多台机器上实现高可用性数据库访问，开箱即用。

使用浮动 IP 和热备用服务器

高可用性架构的最后一个示例是使用浮动 IP 将流量故障转移到 热备用 服务器。许多云提供商都有特殊的 IP 地址，可以使用 API 快速重新分配给不同的服务器或负载均衡器。热备件是随时准备就绪的冗余服务器，但在主服务器未通过健康检查之前不会接收流量。此时，浮动 IP 被重新分配给热备件，流量随之而来。要实现这些健康检查和浮动 IP API 调用，您需要安装和配置一些额外的软件，例如 keepalived 或 heartbeat。

下面的相关教程重点介绍了更多可用于提高基础架构弹性的软件和工具。

相关教程：

结论

在本文中，我们回顾了流程或基础架构的改进可以减少停机时间、增加销售额和让用户更满意的三个领域。监控指标、改进部署和提高基础设施可用性是开始调查您可以实施的更改以使您的应用程序或服务更具生产就绪性和弹性的好地方。

当然，除了这三点之外，还有更多的可靠性。有关更多信息，您可以深入了解每个部分末尾的建议教程，并查看 站点可靠性工程 书，该书可在线免费获得。