Sportradar 是如何实现可恢复性的

  • Manuel Pais
  • 盖磊

2018 年 4 月 12 日

话题:DevOps

看新闻很累?看技术新闻更累?试试下载 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

DevOps