在过去的几年中，我一直在构建和运营大型分布式系统：Uber 的支付系统。在这段时间里，我学到了许多分布式架构的概念，也亲眼看到了高负荷高可用系统的构建和运营是多么富有挑战性。就构建系统这件事来说，它本身是非常有趣的。要规划好当流量增加 10 倍 /100 倍时系统该如何处理，即使硬件出故障数据也要能持久化保存等等，解决这些问题都可以让人有极大的收获。不过对于我个人来说，运营一套大型分布式系统却更是令人大开眼界的经历。

系统越大，墨菲定律“可能出错的事终将出错”就越适用。对于频繁进行系统部署、许多开发者协同提交代码、数据分散在多个数据中心、系统由全球海量用户共同使用这样的场景来说，就更明显。在过去的几年中，我经历过许多次不同的系统故障，很多都大大出乎我意料之外。从可预见的问题——如硬件故障或不小心把有缺陷的代码发布到生产系统，到连接数据中心的网络光纤被铲断或多个级联故障同时发生，许多次故障都让部分系统无法正常工作，因而导致了停服，最终造成了极大的业务影响。

这篇文章是我在 Uber 工作期间，关于如何可靠地运营一套大型分布式系统的经验总结。我的经验会很具有普遍性，运营类似规模系统的人也会有类似的经验。我曾经与谷歌、Facebook、Netflix 等公司的工程师们谈过，他们的经验和解决方案都很相似。不管系统是运行在自建数据中心（Uber 大多数情况下是这样的），还是运行在云端（Uber 的系统有时候会扩展到云端），只要系统规模相似，文章中的想法和流程就会适用。不过如果要把经验照搬到小型系统或非核心系统时就请三思而后行，因为很可能会过犹不及。

具体来说，我会谈到以下话题：

• 监控
  
  

• 值班、异常检测与告警
  
  

• 停服与事件管理流程
  
  

• 事后总结、事件回顾与持续改进的文化
  
  
  

• 故障切换演习、有计划的停机、容量规划与黑盒测试
  
  
• SLO、SLA 及相应的报告
  
  

• 独立的 SRE 团队
  
  

• 对可靠性做持续投入
  
  

• 深入阅读建议
  
  

1.监控

要知道系统是否健康，我们就要回答问题：“我的系统在正常工作吗？”要给出答案，首先就要收集关于系统关键部分的数据。对于运行在不同数据中心多台服务器上，由多个不同服务组成的分布式系统来说，决定哪些关键指标需要被监控，这事本来就不容易。

基础设施健康监控：如果一或多台服务器、虚拟机负载过高，那分布式系统就会发生部分降级。服务要运行在服务器上，所以像 CPU 使用率、内存使用率之类的服务器基本健康信息就很值得监控。有些平台就是专门做这样的监控的，而且支持自动扩展。Uber 有个很大的核心基础设施团队，专门为大家提供底层的监控和告警。不管具体的实现方案如何，当服务的某些实例或基础设施有问题时你都要被通知到，这些信息必须掌握。

服务健康监控：流量、错误、延迟。“后端服务健康吗”？这个问题实在太泛了。观察终端在处理的流量、错误率、终端延迟等，这些都对服务健康提供着有价值的信息。我喜欢为它们各自设置专门的仪表盘。构建新服务时，使用合适的 HTTP 响应映射，并监控相应的编码，这些都会提供很多关于系统状态的信息。比如在客户端出错时返回 4XX 编码，在服务端出错时返回 5XX 编码，这类监控很容易构建，也很容易解读。

对系统延迟的监控值得多考虑一下。对于产品来说，目标就是让大多数的终端用户都有良好的体验。但只监测平均延迟这项指标远远不够，因为平均延迟会掩盖一小部分高延迟的请求。因此就经验来说，监测 P95、P99 或 P999（即 95%、99% 或 99.9% 的请求）的延迟指标会更好。监测这些指标得到的数字可以回答这样的问题：99% 的人发出的请求会有多快得到响应（P99）？1000 个人发出请求，最慢能怎样（P999）？如果有读者对这个话题感兴趣，可以进一步阅读文章《 latencies primer 》。

服务健康监控：流量、错误、延迟。“后端服务健康吗”？

对系统延迟的监控值得多考虑一下。对于产品来说，目标就是让大多数的终端用户都有良好的体验。

要知道系统是否健康，我们就要回答问题：“我的系统在正常工作吗？”

要知道系统是否健康，我们就要回答问题：“我的系统在正常工作吗？”

基础设施健康监控：如果一或多台服务器、虚拟机负载过高，那分布式系统就会发生部分降级。