《云上大型赛事保障白皮书》——第七章 保障阵型与流程管理——7.1 云上大型赛事保障阵型——7.1.2 北京冬奥保障阵型

简介: 《云上大型赛事保障白皮书》——第七章 保障阵型与流程管理——7.1 云上大型赛事保障阵型——7.1.2 北京冬奥保障阵型

7.1.2 北京冬奥保障阵型


在冬奥之前,我们与北京冬奥组委签署保障合同方案,其中规定了详细的保障机制和流程,在具体操作过程中,我们成立了对应的前中后台团队进行东西向服务分层,各团队基于业务影响进行南北向的服务分级,并组建了管理层应急响应小组做为最终的决策层,具体的保障阵型如下图所示。

image.png

图:北京冬奥阿里云保障团队组织架构图


下面从前到后再对不同的团队进行逐一介绍。

客户:不同的奥运客户实体,基本都会使用奥组委指定的ITSM工具联系到阿里云的保障团队,但阿里云提供的接口不同,例如:北京冬奥核心系统客户,会反馈至工作在北京冬奥组委技术运行中心(TOC)的阿里云TOC驻场保障团队;国际奥组委项目群(OBS\OCS等客户),对于来到北京的OBS,会反馈至工作在"闭环"主媒体中心(MMC)的阿里云MMC驻场保障团队,其余则通过ITSM工单系统或阿里云国际站工单系统反馈至阿里云技术中台保障团队。

前台团队:工作在北京冬奥组委技术运行中心(TOC)和闭环区主媒体中心(MMC),现场服务在TOC和MMC的奥运客户实体。在TOC的现场保障团队又区分为不同的角色:值班经理(Duty1Manager)负责保障过程的整体把控、监控资源盯屏和云产品变更审批;技术专家(Technical1Specialist)负责承接客户反馈的ITSM工单和紧急配置变更,并针对需进一步处理的问题发起阿里云内部处理流程;运行经理(Operation Manager)负责技术问题的响应升级、对客沟通和后场报障;运行专家(Operation Expert)负责现场的技术问题深入排查、前后场技术串联,是现场保障团队的技术兜底;安全专家(Security Expert)\DCDN专家(DCDN Expert)则针对于具体的安全产品和DCDN产品提供产品方保障,这是由于此两个产品为奥运云上架构下最容易产生大规模故障的产品线;Info AV值班经理则是为一个比较特殊的IOC创新项目Info AV系统专门安排的一个现场支持岗位。前台团队的主要职责是为客户提供快速响应和现场服务,提升奥运客户的服务体感,对定位至阿里云侧的问题快速拉通中后台团队介入处理。

1684907317131.png


中台团队:在北京冬奥,阿里云技术中台团队的名字叫做OCOC(Olympic Cloud

Operation1Center),OCOC团队定位为整个解决问题环节中的技术中台,处理来自于TOC和MMC现场团队升级的问题,并直接处理无现场服务的奥运客户的问题,工作在阿里云的北京望京园区和杭州飞天园区。OCOC团队是服务阵型中承前启后的一环,来自于前台团队流转的阿里云侧问题绝大部分在OCOC团队闭环,OCOC团队通过内部问题管理系统对问题响应、问题处理、问题排查解决、风险上报、故障应急等进行持续跟踪和闭环处理,确保整体SLA达成。同时,OCOC团队建立了奥运客户所有云产品的告警与监控机制,设计了相应的告警应急预案,当告警发生时,通过标准告警应急预案进行处理,设计了垂直技术应急预案,当发生不同云产品突发情况时,通过标准垂直技术应急预案进行处理,以此确保云上环境运转正常。在特定情况下引入后台团队,即:当紧急情况发生时,引入安全生产团队;当需要产品底层原理排查时,引入产品研发团队。OCOC团队主要由阿里云全球技术服务部专家服务团队(GTS-AES)构成,之前护航过阿里云所有重大活动,例如双十一、双十二、云栖大会等等,经验非常丰富。

后台团队:即安全生产团队和产品研发团队。安全生产团队负责处理产品侧的重大故障,及时引入对应的产研团队,在发生故障的情况下主导故障应急;产研团队则是整体服务阵营中人数最多的团队,这是因为客户使用了60+款云产品,而每款云产品都需有对应的冬奥保障团队。具体来讲,从研发侧,一共有基础产品事业部、基础设施事业部、数据库产品事业部、流量产品事业部、计算平台事业部、产品解决方案与大网站事业部等六个部门参与,覆盖北京冬奥全量奥运客户所使用的所有云产品。产研部门除了主导云产品侧的问题处理,还研发了不同的云产品层实时监控,做为整体监控系统的一部分发挥作用。

对于TOC现场客户产生的具体问题,其服务流程如下:

客户向技术运行中心现场团队提交ITSM工单,或面对面交流提出问题。技术运行中心现场团队依据SLA响应工单,确认事件描述,如果不能解决,就升级给远程OCOC团队。远程OCOC团队会和TOC现场团队通过钉钉密切协作。

如果需要云产品团队介入,OCOC团队会引入产品团队。当紧急情况发生时,则还会引入安全生产团队。

任何对业务有重大影响的紧急情况都可能导致SLA违规或引起负面舆论,立即上报给管理应急决策小组。

管理层应急响应小组将对紧急情况的处置做出决策,并和北京冬奥组委管理层保持密切沟通,包括技术运行中心主任。

对于MMC现场客户产生的具体问题,其服务流程如下:

客户向主媒体中心现场团队提交ITSM工单,或面对面交流提出问题。

主媒体中心现场团队依据SLA响应工单,确认事件描述,如果不能解决,就升级给远程OCOC团队。远程OCOC团队会和TOC现场团队通过钉钉密切协作。

如果需要云产品团队介入,OCOC团队会引入产品团队。当紧急情况发生时,则还会引入安全生产团队。

任何对业务有重大影响的紧急情况都可能导致SLA违规或引起负面舆论,立即上报给管理应急决策小组。

管理层应急响应小组将对紧急情况的处置作出决策,并和国际奥组委管理层保持密切沟通。

对于线上奥运客户产生的具体问题,其服务流程如下:

客户通过ITSM系统或者阿里云国际站工单系统向OCOC团队提交工单。

如果需要云产品团队介入,OCOC团队会引入产品团队。当紧急情况发生时,则还会引入安全生产团队。

任何对业务有重大影响的紧急情况都可能导致SLA违规或引起负面舆论,立即上报给管理应急决策小组。

管理层应急响应小组将对紧急情况的处置作出决策,并和客户管理层保持密切沟通。

相关文章
稳定性保障6步走:高可用系统大促作战指南!
年年有大促,大家对于大促稳定性保障这个词都不陌生,业务场景尽管各不相同,“套路”往往殊路同归,全链路压测、容量评估、限流、紧急预案等,来来去去总少不了那么几板斧。跳出这些“套路”,回到问题的本质,我们为什么要按照这些策略来做?除了口口相传的历史经验,我们还能做些什么?又有什么理论依据?
稳定性保障6步走:高可用系统大促作战指南!
IDEA这个功能真强大!一键把整个项目代码绘制成UML类图...
IDEA这个功能真强大!一键把整个项目代码绘制成UML类图...
5000 0
IDEA这个功能真强大!一键把整个项目代码绘制成UML类图...
云栖实录 | 智能运维年度重磅发布及大模型实践解读
阿里云大数据运维团队重磅发布云原生大规模集群场景的 GitOps 方案,该方案基于 OAM 云原生模型,促进研发与运维人员协作,同时兼顾变更的过程管理和终态管理,可实现变更的自动化、代码化、透明化。此外,阿里云大数据运维团队分享了大模型在大数据智能运维场景的应用实践,通过引入检索增强生成(RAG)方法和其他优化策略,大幅提高了在智能问答和智能诊断方面知识的关联性和检索精度,并基于多智能体框架建立高效的数据分析和决策支持系统。
【Azure 环境】Azure 虚拟机上部署 DeepSeek R1 模型教程(1.5B参数)【失败】
遇见错误一:operator torchvision::nms does not exist 遇见错误二:RuntimeError: Failed to infer device type
401 22
构建智能化编程助手:AI 在软件开发中的新角色
随着AI技术的发展,智能化编程助手正逐渐改变软件开发方式。本文介绍其核心功能,如代码自动补全、智能错误检测等,并探讨如何利用机器学习、自然语言处理及知识图谱等技术构建高效、易用的编程助手,提升开发效率与代码质量,同时讨论面临的技术挑战与未来前景。
Kafka ISR机制详解!
本文详细解析了Kafka的ISR(In-Sync Replicas)机制,阐述其工作原理及如何确保消息的高可靠性和高可用性。ISR动态维护与Leader同步的副本集,通过不同ACK确认机制(如acks=0、acks=1、acks=all),平衡可靠性和性能。此外,ISR机制支持故障转移,当Leader失效时,可从ISR中选取新的Leader。文章还包括实例分析,展示了ISR在不同场景下的变化,并讨论了其优缺点,帮助读者更好地理解和应用ISR机制。
481 0
Kafka ISR机制详解!
MySQL服务的状态如何查看?
【5月更文挑战第23天】MySQL服务的状态如何查看?
3765 1
k8s面试题大全
本篇模拟面试官提问的各种docker,k8s问题,意在提高面试通过率,欢迎在评论区探讨,同步进步。
376 2
100套HTML静态网页模板免费分享
100套HTML静态网页模板,设计的十分有特色,由于Github服务器原因可能下载速度较慢,已全部打包整理。
1429 0
100套HTML静态网页模板免费分享
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等

登录插画

登录以查看您的控制台资源

管理云资源
状态一览
快捷访问