Sportradar 是如何实现可恢复性的

看新闻很累？看技术新闻更累？试试下载 InfoQ 手机客户端，每天上下班路上听新闻，有趣还有料！

Pablo Jensen 是体育数据服务提供商 Sportradar 的 CTO。在今年的 QCon 伦敦大会上，他做演讲（幻灯片PDF 文件）介绍了Sportradar 在确保自身系统满足所期望的可恢复等级中所采取的实践和操作。Jenson 在演讲中提及，影响可靠性的因素不仅包括技术方面，而且包括企业结构与管治、对客户的支持，并需要不断进行努力以实现持续改进。

Sportradar 所采用的技术实践之一，就是在生产环境中定期做故障转移测试（可以看成是一种混沌工程）。他们的快速故障策略是在单一服务层面、集群层面乃至整个数据中心层面得到测试的。Jensen 强调指出，之所以可以进行数据中心层面的测试，原因在于所有数据中心生产环境的创建和运行是完全一致的。从客户的角度看，他们只需要访问单一的联系点，而内部工作负载可以分配（或移动）到任何实时数据中心。应用尽可能与所运行的架构无关，并可采用同一方式部署在本地和云（AWS）上。尽管出于代价考虑，大部分工作是运行在Sprtradar 自身的数据中心中。在 Sportradar 部署的其它常用可恢复策略还包括断路器（circuit breaker）和请求限制（request throttling）等，并由 Netflix 的 Hystrix 工具处理。Jensen 还提及，他们将实时数据库从数据仓库解耦，以避免报告和数据分析对实时客户产生潜在的影响。

在管治方面，Sportradar 非常注重对依赖关系的管理（以及依赖关系的影响，因为第三方提供商的问题依然在导致企业故障因素中位居首位）。例如，企业将外部服务提供商划分为三类可接受的风险：

• “单服务”：针对单个供应商提供的非关键服务 ;
• “多区域”：针对提供某种级别的冗余（例如 AWS 可用区）的单个供应商 ;
• “多供应商”：针对需要强大冗余的关键服务，并且而且依赖于单个供应商是不可接受的。

据 Jensen 介绍，为进一步降低风险，企业已将扩展架构到 Google Cloud 提上日程（这也使云架构服务从“多区域”转变为“多供应商”）。继而，考虑到单个供应商的服务可能会出现故障，这意味着为应对这些故障，必须设计并测试具有依赖的内部服务。由于每个业务区域是通过托管在冗余服务上的技术栈独立提供的，因此问题聚焦于风险管理证明也应是内部的。

鉴于 Sportradar 对特定业务区域分配了超过 40 个 IT 团队，企业还面对为软件架构和生命周期设立管治的需求。一个新的开发在启动之前，必须达到“适合开发”的状态，即具有经认可的架构，并且安全和托管指南部署到位。更重要的是，为确保市场和客户支持团队知悉更改并做好准备，部署到生产必须达到“适合发布”的状态。服务在加载后，依然可以做改进。这时 IT 团队必须遵循“30% 规则”，即团队时间的 30% 要分配给对当前服务稳定性和可操作性的改进，以及对现有过程（例如随叫随到或故障处理程序）的改进。Jensen 强调了对已建立过程迭代、改进、定期沟通并澄清的重要性（不正确遵循规程依然位居导致企业故障因素的第四位）。

在企业结构方面，与业务领域保持一致的 IT（产品）团队运行良好。在团队中，集中式的 IT 和安全团队提供指导和监督，而非亲历亲为。例如，团队群策群力定义安全开发指南，然后首个产品团队遵循该指南，并反馈其中的有用和无用之处，如此利用三个月的时间做迭代改进。只有这样，指南才能推广到所有的团队。

最后一点，每个服务在发布前，企业必定会指定一个值班团队。值班团队为服务的整个生命期提供第二层的技术支持。在每年合计超过 11 万客户请求中，大约 0.5% 的请求会升级到这个层级。正如 Jensen 所强调的，企业中最好的（并且薪酬最高的）工程师才能工作在这些团队中，从而提升了关注客户和服务属主的文化。任何风吹草动的异常都可公开告知客户，进而会在故障后会做出事后查验。Jensen 补充说，客户对这样层级的透明非常认可。

更多的演讲信息提供在 QCon 伦敦大会的官方网站上。InfoQ 将于下周发布演讲的视频。

查看英文原文： What Resiliency Means at Sportradar