@Rays
2018-04-07T17:18:05.000000Z
字数 1869
阅读 1739
架构&设计
摘要: Pablo Jensen是体育数据服务提供商Sportradar的CTO。在今年的QCon伦敦大会上,他做演讲介绍了Sportradar在确保自身系统满足所期望的可恢复等级中所采取的实践和操作。Jenson在演讲中提及,影响可靠性的因素不仅包括技术方面,而且包括企业结构与管治、对客户的支持,并需要不断进行努力以实现持续改进。
作者: Manuel Pais
正文:
Pablo Jensen是体育数据服务提供商Sportradar的CTO。在今年的QCon伦敦大会上,他做演讲(幻灯片PDF文件)介绍了Sportradar在确保自身系统满足所期望的可恢复等级中所采取的实践和操作。Jenson在演讲中提及,影响可靠性的因素不仅包括技术方面,而且包括企业结构与管治、对客户的支持,并需要不断进行努力以实现持续改进。
Sportradar所采用的技术实践之一,就是在生产环境中定期做故障转移测试(可以看成是一种混沌工程)。他们的快速故障策略是在单一服务层面、集群层面乃至整个数据中心层面得到测试的。Jensen强调指出,之所以可以进行数据中心层面的测试,原因在于所有数据中心生产环境的创建和运行是完全一致的。从客户的角度看,他们只需要访问单一的联系点,而内部工作负载可以分配(或移动)到任何实时数据中心。应用尽可能与所运行的架构无关,并可采用同一方式部署在本地和云(AWS)上。尽管出于代价考虑,大部分工作是运行在Sprtradar自身的数据中心中。在 Sportradar部署的其它常用可恢复策略还包括断路器(circuit breaker)和请求限制(request throttling)等,并由Netflix的Hystrix工具处理。Jensen还提及,他们将实时数据库从数据仓库解耦,以避免报告和数据分析对实时客户产生潜在的影响。
在管治方面,Sportradar非常注重对依赖关系的管理(以及依赖关系的影响,因为第三方提供商的问题依然在导致企业故障因素中位居首位)。例如,企业将外部服务提供商划分为三类可接受的风险:
据Jensen介绍,为进一步降低风险,企业已将扩展架构到Google Cloud提上日程(这也使云架构服务从“多区域”转变为“多供应商”)。继而,考虑到单个供应商的服务可能会出现故障,这意味着为应对这些故障,必须设计并测试具有依赖的内部服务。由于每个业务区域是通过托管在冗余服务上的技术栈独立提供的,因此问题聚焦于风险管理证明也应是内部的。
鉴于Sportradar对特定业务区域分配了超过40个IT团队,企业还面对为软件架构和生命周期设立管治的需求。一个新的开发在启动之前,必须达到“适合开发”的状态,即具有经认可的架构,并且安全和托管指南部署到位。更重要的是,为确保市场和客户支持团队知悉更改并做好准备,部署到生产必须达到“适合发布”的状态。服务在加载后,依然可以做改进。这时IT团队必须遵循“30%规则”,即团队时间的30%要分配给对当前服务稳定性和可操作性的改进,以及对现有过程(例如随叫随到或故障处理程序)的改进。Jensen强调了对已建立过程迭代、改进、定期沟通并澄清的重要性(不正确遵循规程依然位居导致企业故障因素的第四位)。
在企业结构方面,与业务领域保持一致的IT(产品)团队运行良好。在团队中,集中式的IT和安全团队提供指导和监督,而非亲历亲为。例如,团队群策群力定义安全开发指南,然后首个产品团队遵循该指南,并反馈其中的有用和无用之处,如此利用三个月的时间做迭代改进。只有这样,指南才能推广到所有的团队。
最后一点,每个服务在发布前,企业必定会指定一个值班团队。值班团队为服务的整个生命期提供第二层的技术支持。在每年合计超过11万客户请求中,大约0.5%的请求会升级到这个层级。正如Jensen所强调的,企业中最好的(并且薪酬最高的)工程师才能工作在这些团队中,从而提升了关注客户和服务属主的文化。任何风吹草动的异常都可公开告知客户,进而会在故障后会做出事后查验。Jensen补充说,客户对这样层级的透明非常认可。
更多的演讲信息提供在QCon伦敦大会的官方网站上。InfoQ将于下周发布演讲的视频。