在过去的几年里，我一直在构建和运营一个大型分布式系统：优步的支付系统。在此期间，我学到了很多关于分布式架构概念的知识，并亲眼目睹了高负载和高可用性系统运行的挑战（一个系统远远不是开发完了就完了，线上运行的挑战实际更大）。构建系统本身是一项有趣的工作。规划系统如何处理10x / 100x流量的增加，确保数据持久，面对硬件故障处理等等，这些都需要智慧。不管怎样，运维大型分布式系统对我来说是一次令人大开眼界的体验。
这篇文章是我在Uber工作时总结的，可以有效运维大型系统的实践的集合。我的经验并不是独一无二的 - 在类似规模的系统上工作的人也经历了类似的旅程。我与Google，Facebook和Netflix的工程师进行了交谈，他们分享了类似的经验和解决方案。这里列出的许多想法和流程应该适用于类似规模的系统，无论是在自己的数据中心（如Uber大多数情况下）上运行，还是在云上运行（Uber 有时会把部分服务弹性部署到云上）。但是，对于规模较小或较少关键任务的系统而言，这些做法可能过于苛刻。
- 监控
- 值班，异常检测和警报
- 故障和事件管理流程
- 事后分析，事件回顾和持续改进文化
- 故障演习，容量规划和黑盒测试
- SLOs、SLAs 及其报告
- SRE 作为独立团队
- 可靠性作为持续投资
- 更多推荐阅读
监控
要知道系统是否健康，我们需要回答“我的系统是否正常工作”的问题？为此，收集系统关键部分的数据至关重要。对于在多台计算机和数据中心上运行多个服务的分布式系统，可能很难确定要监控的关键内容是什么。
服务运行状况监控：流量，错误，延迟。我们经常需要回答“这个后端服务是否健康？”这样的问题。观察访问端点的请求流量、错误率和端点延迟等事项都可以提供有关服务健康状况的有价值信息。我更喜欢将这些都显示在仪表板上。在构建新服务时，通过使用正确的HTTP响应映射并监视相关代码可以对系统有很多了解。因此，确保客户端错误能返回4XX，以及如果服务器错误则返回5xx，这种监控易于构建且易于解释。
围绕监控和可观察性有很多更有深度的内容。值得一读的两个资源是Google的SRE书和关于分布式系统监控的四个黄金指标的部分。他们建议，如果您只能测量面向用户的系统的四个指标，请关注流量，错误，延迟和饱和度。比较简短的材料的话，推荐来自Cindy Sridharan的分布式系统可观察性电子书，它涉及其他有用的工具，如事件日志，指标和跟踪最佳实践。
虽然我们建立了各种监控，有些业务问题仍然无法探测到，这让我们遭受了巨大的痛苦，最终建立了业务指标的监控。有时我们所有的服务看起来都在正常运行，但关键产品功能不可用！这种监控对我们的组织和领域来说非常有用。因此，我们必须在Uber的可观察性技术堆栈的基础上，为自己定制这种类型的监控做了大量的思考和努力。
Oncall，异常检测和警报
监控对于洞察系统的当前状态而言，是一个很棒的工具。但这只是自动检测问题并发出警报以供人们采取行动的一个垫脚石。
从监控数据中检测异常是一个艰巨的挑战，也是机器学习可以发光的领域。有很多第三方服务提供异常检测。再次幸运的是，我们团队有一个内部机器学习团队与之合作，他们根据Uber的使用情况量身定制了解决方案。位于纽约的 Observability 团队撰写了一篇有用的文章，介绍 Uber 的异常检测工作原理。从我的团队的角度来看，我们将监控数据推送到该团队的管道，并获得具有各自置信度的警报。然后我们决定是否应该呼叫工程师。
位于 Vilnius 的Uber开发工具团队构建了整洁的呼叫工具，我们用它来注释警报并可视化呼叫班次。我们的团队每周对上一次值班班次进行回顾，分析痛点并花时间改善值班体验，一周又一周。
故障和事件管理流程
想象一下：你是本周的值班工程师。半夜，一个警报把你吵醒了。你调查是否有生产中断发生。糟糕，似乎系统的某个部分出现了故障。现在怎么办？监控和警报真实发生了。
附加到警报的Runbook手册，描述简单的缓解步骤是第一道防线。对于拥有良好Runbook手册的团队，即使值班工程师不深入了解系统，也很少会成为问题。Runbook 需要保持最新、更新，并在故障出现时使用新型缓解措施进行处理。
一旦有超过几个部署服务的团队，跨组织进行故障交流就变得至关重要。在我工作的环境中，成千上万的工程师会根据自己的判断将他们所开发的服务部署到生产环境中，每小时可能会有数百次部署。一个看似不相关的服务部署可能会影响另一个服务。在这种情况下，标准化的故障广播和通信渠道可以起到很大作用。我曾经遇到过多种罕见的警报信息 - 意识到其他团队中的人也看到了类似奇怪现象。通过加入一个集中式聊天群组来处理故障，我们迅速确定了导致故障的服务并解决了问题。我们做得比任何单独一人更快地完成了任务。
事后分析，事件回顾和持续改进文化
这是在说一个团队如何处理故障的后续。他们会继续工作吗？他们会做小规模的调查吗？他们是否会在后续工作中花费惊人的精力，停止产品工作以进行系统级修复？
良好的事后分析深入挖掘根本原因并提出改进措施，以更快地预防、检测或缓解所有类似的故障。当我说深入挖掘时，我的意思是他们不会停留在根本原因上，即错误的代码更改和代码审查者没有发现错误。
- 为什么会出现这个问题？–> 因为代码里引入了bug。
- 为什么其他人没有发现这个错误？–> 代码审查员没有注意到代码更改可能会导致此类问题。
- 我们为什么只依赖于代码审查员捕获此错误？–> 因为我们没有针对此用例的自动化测试。
- “为什么我们没有针对此用例的自动化测试？” –> 因为在没有测试帐户的情况下很难进行测试。
- 我们为什么没有测试帐户？ –> 因为该系统尚不支持它们
- 结论：这个问题指向了缺乏测试账户的系统性问题。建议将测试账户支持添加到系统中。接下来，编写所有未来类似代码更改的自动化测试。
事件回顾是事后分析的重要配套工具。虽然许多团队在事后分析方面做得很彻底，但其他团队可以从额外的输入和对预防性改进的挑战中受益。同样重要的是，团队要有责任感并有权执行他们提出的系统级改进。
故障演习，容量规划和黑盒测试
有一些常规活动需要大量投资，但对于保持大型分布式系统的正常运行至关重要。这些是我在优步第一次接触到的概念——在以前的公司，我们不需要使用这些，因为我们的规模和基础设施没有促使我们这样做。
我观察到的最常见的故障场景是在发生故障转移时，新数据中心的服务没有足够的资源来处理全球流量。假设ServiceA和ServiceB分别从两个数据中心运行。假设资源利用率为60％，每个数据中心都有数十或数百台虚拟机在运行，并设置警报以在70％时触发。现在让我们进行故障转移，将所有流量从DataCenterA重定向到DataCenterB。 在没有提供新机器的情况下，DataCenterB突然无法承受负载。提供新机器可能需要足够长的时间，以至于请求会堆积并开始丢弃。这种阻塞可能会开始影响其他服务，导致其他系统的级联故障，这些系统甚至不是此故障转移的一部分。
译者注：切流量，本就是预案“三板斧”之一。出故障的时候，要保证预案是可用的，那平时就少不了演练。重视起来吧，老铁们。
黑盒测试是一种测量系统正确性的方法，尽可能接近最终用户所看到的条件。这种类型的测试类似于端到端测试，但对于大多数产品来说，拥有适当的黑盒测试需要单独投入。关键用户流程和最常见的面向用户的测试场景是好的黑盒可测性示例：以这种方式进行设置可以随时触发它们，以检查系统是否正常工作。
容量规划对于大型分布式系统同样重要。所谓大型，是指计算和存储成本每月达到数万或数十万美元。在这个规模下，使用固定数量的部署可能比使用自动扩展的云解决方案更便宜。至少，固定部署应该处理“业务常态”流量，并在高峰负载时进行自动扩展。但是，在接下来的一个月内、未来三个月内以及明年需要运行多少最小实例呢？
SLOs, SLAs 以及相关报告
SLO 代表服务级别目标 - 系统可用性的数字目标。对于每个独立的服务，定义服务级别 SLO（例如容量、延迟、准确性和可用性的目标）是一种很好的做法。然后，这些 SLO 可以作为警报的触发器。服务级别 SLO 示例可能如下所示：
| SLO Metric | Subcategory | Value for Service |
|---|---|---|
| Capacity | Minumum throughput | 500 req/sec |
| Maximum expected throughput | 2,500 req/sec | |
| Latency | Expected median response time | 50-90ms |
| Expected p99 response time | 500-800ms | |
| Accuracy | Maximum error rate | 0.5% |
| Availability | Guaranteed uptime | 99.9% |
SLA - 服务水平协议 - 是服务提供者和服务消费者之间更广泛的协议。通常，多个 SLO 组成一个 SLA。例如，99.99% 可用的支付系统可以是 SLA，它分解为每个支持系统的特定 SLO。
这就引出了下一个话题：运营大型分布式系统的组织迟早需要为这些系统的可靠性投入专门的人员。让我们来谈谈网站可靠性工程团队。
SRE 作为独立团队
快速发展的科技公司通常会在早期组建 SRE 团队，由他们制定自己的路线图。在优步，SRE 团队成立于 2015 年，其使命是随着时间的推移管理系统复杂性。其他公司可能会在创建专门的基础架构团队时同时启动这样的团队。当一家公司发展到跨团队的可靠性工作占用了很多工程师的时间时，是时候为此设立一个专门的团队了。
鉴于公司有不同的痛点，他们寻求 SRE 来解决，因此 SRE 组织在公司之间是不同的。这个团队的名称通常也会不同：可能被称为运维、平台工程或基础设施。Google 出版了两本关于站点可靠性的必读书籍，这些书籍可免费获取，是深入了解 SRE 的绝佳读物。
可靠性作为持续投资
分布式系统具有相似的生命周期，只是它们需要更多投资，不仅仅是为了新功能，还要跟上扩展的步伐。随着系统开始承受更多负载、存储更多数据、更多工程师对其进行处理，它需要持续关注以保持平稳运行。很多人第一次构建分布式系统时会认为这个系统就像一辆汽车：一旦建好，只需要每几个月进行必要的维护。但是这种比较与实际情况相去甚远。
为了让团队运行可靠的分布式系统，组织需要持续投资于这些系统的操作以及它们所构建的平台。
更多推荐阅读
图书
Google SRE Book - 一本来自 Google 的优秀免费书籍。《监控分布式系统》章节对本文尤为相关。
Martin Kleppmann 博士的《数据密集型应用系统设计》是我迄今为止发现的关于分布式系统概念最实用的书籍。然而，这本书并没有涉及到文章中讨论的操作方面。
在线资源
学习构建分布式系统 - AWS工程师Marc Brooker发表的一篇文章，回答了“我如何学习构建大型分布式系统”的问题。
One more thing
Uber 这位仁兄写的内容挺丰富了，感觉非常有共鸣，前段时间我也写了一个《稳定性体系建设白皮书》，很多思路是相通的，各位看官可以一起查阅，查漏补缺，希望对你有些帮助: