引言

随着企业和其他组织越来越依赖于基于互联网的服务,开发人员和系统管理员正将注意力集中在创建可靠的基础设施上,以最小化昂贵的停机时间。

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

  • 不满意的客户和用户: 用户期望稳定的服务。 中断可能导致支持请求增加,以及对你的品牌普遍丧失信心。
  • 失去的生产力: 如果你的员工依靠服务来完成他们的工作,停机意味着你的组织失去了生产力。 此外,如果你的员工花费时间重启服务器和争取停机时间,他们没有开发新的功能和产品。
  • 不快乐的员工: 频繁的停工警报会导致警觉疲劳,不断地争先恐后地解决问题会损害你的团队和他们的士气。

解决这些问题的现代领域被称为网站可靠度或 SRE。 从2003年开始,SRE 在谷歌创建,他们开发的策略被收集到一本名为《可靠度。 阅读这个领域的文章是探索最小化停机时间的技术和最佳实践的好方法。

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

这并不是一个详尽的策略列表,而是为了向您指出一些常见的解决方案,这些解决方案是您在提高服务的生产准备状态时应该考虑的。

1. 监测和警报

正确地监视您的基础结构将使您能够主动地监视即将发生的问题,向您的团队发出问题警报,并且更容易地调查以前停机时间的原因。 监视涉及聚合和记录统计信息,例如系统资源利用率和应用程序性能指标。 警报是在这个度量集合的基础上构建的,它不断地根据当前度量评估警报规则,以确定何时需要采取行动。

监视通常由每台主机上的客户机实现,客户机收集指标并向中央服务器报告。 然后这些指标被存储在一个时间序列数据库(一个专门存储和搜索有时间戳的数字数据的数据库)中,并可用于绘图、搜索和警报。 监控软件的一些例子如下:

  • 普罗米修斯实验室可以从各种官方和社区支持的客户(称为出口商)那里获取数据。 它具有高度可伸缩性,具有内置的警报,并且对于大多数编程语言都具有可用的客户机库。
  • Graphite 提供了一个现在无处不在的 API,它被许多编程语言和应用程序所支持。 度量数据从节点推送到中央 Graphite 安装,在那里存储并绘制图表。

将日志文件推送到中心服务并解析它们以获得相关指标(如异常和错误率)也很常见。 Elastic stack (Elasticsearch,Logstash,Kibana)和 Graylog 是可以方便日志文件解析和分析的软件堆栈示例。

在尝试提高可靠性和减少停机时间时,应该收集哪些最有用的指标? 大多数监控客户端和出口商都有一套默认的度量标准,这是一个很好的起点,但是你的应用程序或服务将有独特的需求,这是你在决定导出哪些度量标准时需要考虑的。 值得庆幸的是,SRE 文献提供了一些通用的指导方针,用于监视哪些是最有用的度量标准。 这些度量被分组为四个黄金信号,摘自 SRE 的书: 延迟: 响应请求所需的时间。 例如,服务器对 HTTP 请求的响应时间。 流量: 你的系统正在经历的需求量。 这可能是 web 服务器的请求速率、网络 i / o、每秒登录数或数据库的每秒事务数。 错误: 事务或请求的失败率。 请记住,并不是所有的错误都像 HTTP 500错误一样清楚。 例如,客户应该在500毫秒或更短的时间内收到回复,这可能是您的策略。 在这种情况下,任何延迟较长的响应都应该显示为错误。 饱和度: 一项服务有多“全面”。 这可以度量硬盘驱动器上的可用空间、网络吞吐量,甚至是 CPU 绑定服务上的可用 CPU 数量。

可视化度量

一旦您建立了监控系统,您将希望探索您正在收集的数据。 Grafana 是一个软件包,它通过图形和仪表板提供非常灵活的度量探索。 可视化可以从多个后端数据源聚合,包括 Graphite、 Prometheus 和 Elasticsearch。

设置警报

除了可视化您的指标,您还需要设置一些方法,以便在出现问题时自动提醒您的团队。 Grafana 拥有警报能力,Prometheus 通过 Alertmanager 组件也具有这种能力。 其他软件包包括 Nagios 和 Sensu,它们允许您定义用于度量的警报规则。

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

要记住的主要事情是,目标应该是尽可能少的警告,并且只针对那些你的团队可以立即采取行动来解决问题的事件。 过多的警报,或者对于实际上无法解决的情况的警报,会导致警报疲劳。 这种疲劳会导致不快乐的员工,他们可能会错过或忽视那些重要的、可以采取行动的警报。

在设置警报时,SRE 书总结了一些需要牢记的原则:

每当传呼机响起,我应该能够以一种紧迫感作出反应。 我一天只能有几次带着紧迫感做出反应,然后就会感到疲惫。 每一页都应该是可操作的。 每个页面响应都需要智能。 如果一个页面仅仅是一个机器人式的回复,那么它就不应该是一个页面。 页面应该是关于一个新的问题或者一个以前从未见过的事件。

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

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

相关教程:

  • 如何使用 Prometheus 来监控你的 Ubuntu 14.04服务器
  • 如何在 Ubuntu 14.04服务器上安装和使用 Graphite
  • 石墨、 StatsD 和 CollectD 跟踪统计简介
  • 如何在 Ubuntu 16.04上安装和配置 Zabbix 来安全地监控远程服务器

2. 改进软件部署

另一个会影响停机时间的领域是软件部署策略。 如果您的部署过程需要多个手动步骤才能完成,或者过于复杂,那么您的生产环境很可能明显滞后于您的开发环境。 这可能会导致更危险的软件发布,因为每个部署都会变成一个更大的更改集,带来更多的潜在复杂性。 这反过来又会导致 bug,降低开发速度,并可能无意中导致部署退化或不可用的服务。

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

Ci / cd 最佳实践

随着当今集装箱技术、组态管理软件、编程语言和操作系统的多样性,关于如何自动化部署的具体细节已经超出了任何一篇文章的范围。 一般来说,一个很好的起点是确保遵循关于持续集成(CI)交付(CD)和软件测试的最佳实践。 其中一些最佳做法包括:

  • 维护单一存储库: 每个人都应该定期将代码集成到同一存储库中,存储库应该包含在相对较少的机器或 CI 环境中构建项目所需的所有内容(包括测试和配置文件)。 这确保了每个人都在相似的代码基础上工作,集成相对来说是轻松的,并且每个人都可以轻松地测试和构建他们的变更。
  • 自动化测试和构建: CI 软件或服务应该能够自动运行测试并构建项目。
  • 自动化部署: 您的 CI 软件应该能够在一个测试环境中部署和测试构建,这个测试环境与最终的生产环境非常相似。

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

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

蓝绿色部署

有一种特殊的方法可以实现安全的生产最后推进,即在不同版本之间进行无缝切换,这种方法被称为“蓝绿部署”。

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

在任何时间点,只有一个环境(在本例中是蓝色的)是活动的并接收生产流量。 发布新版本的过程如下:

  • 将构建推送到非活动的环境(本例中为绿色)。
  • 在这个生产环境中测试构建。
  • 如果所有测试都通过了,那么通过更新负载均衡器配置或者将浮动 IP 分配给绿色服务器来切断通向绿色环境的流量。

这种技术还有一个额外的好处,那就是提供了一种简单的机制,可以在出现任何问题时回滚到前一个版本。 保持以前的部署并处于待命状态,直到您对新版本感到满意为止。 如果需要回滚,则再次更新负载均衡器或浮动 IP 以恢复到先前的状态。

同样,有许多方法可以实现以安全和容错的方式自动化部署流程的目标。 我们只强调了一种可能性。 下面的相关教程有关于开源 ci / cd 软件和蓝绿色部署的更多信息。

相关教程:

  • 如何使用蓝绿部署安全发布软件
  • 持续集成、交付和部署介绍
  • 工具比较: Jenkins,GitLab CI,Buildbot,Drone 和 Concourse

3. 实施高可用性

最小化停机时间的最后一个策略是在基础设施中应用高可用性 / 服务的概念。 这个术语高可用性包含了一些设计冗余和弹性系统的原则。 这些系统通常必须:

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

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

升级到更高可用性基础设施的一个例子是从单个 web 服务器转移到多个 web 服务器和负载均衡器。 负载均衡器将在 web 服务器上执行定期的健康检查,并将流量路由到那些失败的服务器上。 此基础结构还可以支持更无缝的代码部署,如前面部分所讨论的那样。

增强数据库的弹性

增加弹性和冗余的另一个例子是数据库复制。 例如,MySQL 数据库服务器有许多不同的复制配置。 组复制非常有趣,因为它支持在冗余服务器集群上执行读写操作。 您可以在多个服务器之间进行复制,而不必将所有数据放在单个服务器上,因为服务器很容易停机。 Mysql 会自动检测出故障服务器并绕过这个问题。

新的数据库,比如 CockroachDB,正在从头开始构建,同时考虑到这些冗余复制特性,使得多个数据中心的多台机器之间的高可用性数据库访问成为可能。

使用浮动 ip 和热备份服务器

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

下面的相关教程重点介绍了更多可用于增强基础设施弹性的软件和工具。

相关教程:

  • 什么是高可用性?
  • 5 DigitalOcean 负载均衡器用例
  • 如何在 DigitalOcean 上使用浮动 ip
  • Haproxy 和负载平衡概念介绍
  • 如何在 Ubuntu 16.04上配置 MySQL 组复制
  • 如何在 Ubuntu 16.04的三节点集群上部署 CockroachDB

总结

在本文中,我们回顾了流程或基础设施的改进可能导致更少的停机时间、更多的销售和更快乐的用户的三个方面。 监视指标、改进部署和提高基础设施可用性是开始研究您可以实现的更改的好地方,这些更改可以使您的应用程序或服务更具生产准备性和弹性。

当然,除了这三点之外,还有更多的可靠性。 要了解更多信息,你可以在每个部分的最后更深入地了解建议的教程,并且查看网站 / 可靠度的书籍,这是免费的在线。