最大限度减少停机时间的 3 种策略

简介

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

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

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

为解决这些问题而联合起来的现代领域称为现场可靠性工程或SRE。从2003年开始，谷歌创建了SRE，他们开发的策略被收集到一本名为Site Reliability Engineering.]的书中阅读这一领域的资料是探索将停机时间降至最低的技术和最佳实践的好方法。

在本文中，我们将讨论三个方面的改进可以减少组织的停机时间。这些区域是**[监控和警报](# 1-监控和警报)** 、** 软件deployments** ，和** [高availability](# 3-implementing-high-availability)** .

这并不是一个详尽的策略列表，但它旨在为您提供一些在改进服务的生产准备情况时应该考虑的常见解决方案。

1.监控与告警

正确监控您的基础架构将使您能够主动监视迫在眉睫的问题，提醒您的团队注意问题，并更轻松地调查以前停机的原因。监控涉及汇总和记录统计数据，如系统资源利用率和应用程序性能指标。警报建立在此指标集合的基础上，方法是根据当前指标不断评估警报规则，以确定何时需要采取操作。

监控通常使用每台主机上的客户端来实施，该客户端收集指标并将报告返回给中央服务器。然后，这些指标被存储在时间序列数据库(专门存储和搜索带有时间戳的数字数据的数据库)中，并可用于绘图、搜索和警报。监控软件的一些示例包括：

  • 普罗米修斯 可以从各种官方和社区支持的客户(称为_导出器_)获取数据。它具有高度可伸缩性，具有内置警报功能，并且具有可用于大多数编程语言的客户端库。
  • Graphite 提供了一个现在无处不在的接口，得到了数十种编程语言和应用程序的支持。指标从节点推送到中央Graphite安装，并在那里存储和绘制图表。

将日志文件推送到中央服务并对其进行解析以获取相关指标(如异常和错误率)也很常见。弹性堆栈(Elasticsearch，Logstash，Kibana)和GrayLog)是可促进日志文件解析和分析的软件堆栈的示例。

<$>[备注] 监控哪些指标

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

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

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

<$>

可视化指标

一旦你建立了监控系统，你就会想要探索你正在收集的数据。Grafana是一个软件包，它通过图形和仪表板提供非常灵活的指标探索。可视化可以从多个后端数据源聚合，包括Graphite、Prometheus和Elasticearch。

设置警报

除了可视化您的指标之外，您还需要设置一些方法，以便在出现问题时自动向您的团队发出警报。Grafana具有警报功能，普罗米修斯通过其Alertmanager组件也具有警报功能。允许您为指标定义警报规则的其他软件包包括Nagios和SENSU.

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

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

这本书总结了设置alerts](https://landing.google.com/sre/book/chapters/monitoring-distributed-systems.html# tying-these-principles-together-nqsJfw)：时需要牢记的一些原则

  • 每次呼机响起，我都应该能有一种紧迫感。在我变得疲惫之前，我一天只能有几次紧迫感。
  • 每一页都应该是可操作的。
  • 每个页面响应都需要智能。如果一个页面仅仅值得机器人的回应，它不应该是一个页面。
  • 页面应该是关于一个新的问题或一个以前没有见过的事件。

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

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

相关教程：

2.完善软件部署

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

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

CI/CD最佳实践

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

  • 维护单一存储库： 每个人都应该定期将代码集成到同一存储库中，该存储库应该包含在相对裸机或CI环境中构建项目所需的所有内容(包括测试和配置文件)。这确保了每个人都在类似的代码库上工作，集成相对轻松，每个人都可以轻松地测试和构建他们的更改。
  • 自动测试和构建： 您的CI软件或服务应该能够自动运行测试并构建您的项目。
  • 自动部署： 您的CI软件应该能够在接近模拟最终生产环境的测试环境中部署和测试构建。

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

无论哪种方式，您都需要一种方法来将新版本推向生产，而不会给您的用户造成停机。如果在更新基础设施时涉及服务中断，频繁部署将是一大不便。

蓝绿部署

实现安全的最终推向生产的一种具体方式--版本之间的无缝切换--称为蓝绿部署 。

蓝绿色部署需要设置两个完全相同的生产环境，其背后的机制可以轻松地在两者之间切换流量。该机制可以是保留的IP地址，可以在蓝色或绿色服务器之间快速切换，也可以是用于在多个服务器的整个集群之间切换的负载均衡器。

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

  • 将构建推送到非活动环境(本例中为绿色)。
  • 在此生产环境中测试构建。
  • 如果所有测试都通过，则通过更新负载均衡器配置或将保留的IP分配给绿色服务器，将流量切换到绿色环境。

这项技术还有一个额外的好处，即提供了一种简单的机制，以便在出现任何错误时回滚到以前的版本。保持以前的部署并处于待机状态，直到您对新版本感到满意。如果需要回档，请再次更新负载均衡器或预留IP，以恢复到之前的状态。

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

相关教程：

3.实现高可用

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

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

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

升级到更高可用性基础设施的一个示例是从单个Web服务器迁移到多个Web服务器和负载均衡器。负载均衡器将在Web服务器上执行定期运行状况检查，并将流量从出现故障的服务器中路由出去。此基础设施还可以实现更无缝的代码部署，如上一节所讨论的。

提高数据库弹性

增加弹性和冗余性的另一个例子是数据库复制。例如，MySQL数据库服务器有许多不同的复制配置。_组复制_很有趣，因为它在冗余的服务器集群上同时启用读 和** 写** 操作。您可以在多台服务器之间进行复制，而不是将所有数据都放在一台服务器上，这样就很容易出现宕机。MySQL将自动检测故障服务器并绕过该问题。

<$>[注] 较新的数据库，如CockroachDB正在从头开始构建，并考虑到这些冗余复制功能，从而实现开箱即用的跨多个数据中心中的多台机器的高可用数据库访问。 <$>

使用预留IP和热备服务器

高可用性体系结构的最后一个示例是使用保留的IPs将流量故障转移到热备盘服务器。许多云提供商都有特殊的IP地址，可以使用API将其快速重新分配给不同的服务器或负载均衡器。热备盘是一种随时可用的冗余服务器，但在主服务器未通过运行状况检查之前不会收到任何流量。在这一点上，保留的IP被重新分配给热备盘，流量随之继续。要实现这些运行状况检查和保留的IPAPI调用，您需要安装和配置一些附加软件，如keepalived或heartbeat.

下面的相关教程重点介绍了更多可用于提高基础设施恢复能力的软件和工具。

相关教程：

结论

在本文中，我们回顾了流程或基础设施的改进可以减少停机时间、增加销售和提高用户满意度的三个方面。监控指标、改进部署和提高基础设施可用性是开始研究可以实施哪些更改以使您的应用程序或服务更好地为生产做好准备和恢复能力的好地方。

当然，除了这三点之外，还有更多的可靠性问题。有关更多信息，您可以深入了解每个部分末尾的建议教程，并查看_SITE可靠性工程_书，这本书可免费获取online.

Published At
Categories with 技术
Tagged with
comments powered by Disqus