《阿里云:2022 云上大型赛事保障白皮书.pdf》由会员分享,可在线阅读,更多相关《阿里云:2022 云上大型赛事保障白皮书.pdf(147页珍藏版)》请在三个皮匠报告上搜索。
1、目录CATALOG成书背景 创作团队名单0105引言 2.1 云上大型赛事业务架构2.2 云上大型赛事保障目标2.3 云上大型赛事保障挑战2.4 云上大型赛事保障方法论15171921第二章 云上大型赛事保障体系1.1 历史背景 1.2 上云优势1.3 上云之路070910第一章 大型赛事云上数字化转型5959624.1 云上大型赛事监控告警4.1.1 监控告警基本概念 4.1.2 北京冬奥监控告警体系介绍第四章 监控告警与应急预案3.1 云上大型赛事压测调优3.1.1 压力测试基本概念 3.1.2 云上大型赛事压力测试方法论3.1.3 云上大型赛事系统调优3.1.4 北京冬奥压测调优总结3.
2、2 云上大型赛事技术演练3.2.1 技术演练基本概念 3.2.2 容灾演练及冬奥实践3.2.3 安全攻防演练及冬奥实践3.2.4 故障演练及冬奥实践27272933405050505456第三章 压测调优与技术演练2.4.1 赛前全局梳理 2.4.2 保障目标体系构建 2.4.3 赛时技术风险处置2124264.2 云上大型赛事应急预案4.2.1 应急预案原则4.2.2 北京冬奥告警预案4.2.3 北京冬奥技术场景预案70707075858586909292981031031031055.1 云上大型赛事安全设计5.1.1 安全建设 5.1.2 阿里云安全产品5.1.3 阿里云安全服务5.2
3、云上大型赛事安全防护5.2.1 安全攻防演练5.2.2 安全防护体系第五章 安全设计与安全防护6.1 云产品稳定性治理6.1.1 什么是稳定性治理6.1.2 稳定性治理的思想6.1.3 稳定性治理的思考与拓展第六章 云产品稳定性治理与风险管控1071071081101231251271281291291311351351386.2 北京冬奥稳定性治理实践6.2.1 核心系统上云架构-稳定性治理实践6.2.2 智能风险管控工具-Aspara ServiceStack-CloudDoc6.2.3 冬奥重保-风险巡检6.2.4 冬奥重保-稳定性专项6.2.5 冬奥重保-赛时每日巡检6.2.6 冬奥重
4、保变更管控6.3 稳定性巡检总结7.1 云上大型赛事保障阵型7.1.1 基于前中后台的服务分层7.1.2 北京冬奥保障阵型7.2 云上大型赛事流程管理7.2.1 基于业务影响的流程分级7.2.2 北京冬奥应急流转流程第七章 保障阵型与流程管理第八章 未来展望引言成书背景大型赛事作为表征文明发展程度的重要标志,其与人类社会的的政治、经济、文化、人文、科技等都有着密切关联,一并构成当今世界的丰富多样性。其中,每四年举办一次的奥林匹克运动会,其历史最为悠久、参与人数最多、比赛规模最大、涉及项目最广、竞技水平最高、影响范围最广、关注程度最高、科技含量最强,是当之无愧的世界最高等级的国际综合体育赛事,其
5、内涵也已经远远超出体育竞技的范畴,从而形成了独一无二的奥运文化现象,成为了全人类的文化盛会和文明遗产。2022年2月4日,随着耀眼的烟花闪烁在北京国家体育场鸟巢的上空,已筹备和等待了7年的北京冬奥会正式开始了,此时,距2015年北京成功申办本届冬奥会,已过去了2380天,在这漫长的日子里,包括阿里云在内的各条战线的参与者,包括阿里人在内的各行各业的中国人民,通过在各自领域的真诚奉献、默默耕耘、辛勤付出和智慧汗水,保证了这场精彩刺激精彩纷呈的奥运盛会的完整圆满召开,为世界奉献了一场奥林匹克盛宴。正如习总书记在表彰大会上所述:“广大冬奥会、冬残奥会的参与者们,用辛勤付出、坚强毅力、巨大勇气,以强烈
6、的责任感、使命感、荣誉感,出色完成了各项工作任务,创造了无愧于祖国、无愧于人民、无愧于时代的光辉业绩!”01 云上大型赛事保障白皮书云上大型赛事保障白皮书科技的进步,促进着奥运的发展。本届冬奥会在数字基础设施层面实现了两个首次:通过云计算技术向全球转播,实现了奥运史上首次8K视频技术直播开幕式和重大赛事转播1;赛事成绩、组织管理、比赛转播等核心系统100%运行在云上,成为了百年奥运史上第一届全面“上云”的奥运会2。奥运全面上云的成功实践,让我们不禁思考:未来的大型赛事,应当是什么样子?阿里云作为奥林匹克全球合作伙伴和云服务供应商,有幸参与了三届奥运盛事,更是在2022年的北京冬奥会成为核心系统
7、全量数字基础设施提供商,帮助完成了奥运历史上首次全面彻底的云上数字化转型。这也让我们意识到,大型赛事系统上云已然成为发展趋势,技术的发展和创新之路在不断向前,而作为这条路上披荆斩棘的我们,有必要也有意义将这些宝贵的实践经验整理成册,和众多的技术人一起,交流学习,共促提升。图:北京冬奥会升旗仪式时中台作战室全体同学激动鼓掌云上大型赛事保障白皮书 02大型赛事系统迁移上云之后,需要实时感知运转情况、发现潜在风险、有效应对突发状况、保证整体业务7*24平稳运转。因此,如何构建一套完整的云上保障体系,就成为了技术保障工作的重中之重。本书基于阿里云双奥重保经验,以北京冬奥会为例,归纳总结云上大型赛事整体
8、保障体系的业务架构,并逐一解构各工作项内容,为后续的云上大型赛事的技术保障提供参考和借鉴作用。具体来讲,本书分为八个章节。过去,为满足复杂的业务和技术要求,大型赛事业务系统的基础设施都要部署在成本高昂的专有环境下,如同运动场馆一样,这些专有环境在赛事结束之后即面临着闲置风险。随着云计算技术的发展,云厂商能够提供低成本、高稳定性、高弹性的解决方案,业务设施上云成为了业务系统设计时不可或缺的考虑因素。第一章节主要讨论大型赛事的历史背景、上云好处,以及上云之路,作为大型赛事数字化转型之路的综述。诸如奥运会这样的云上大型赛事,其内部业务系统非常复杂,赛事管理、综合管理、办公系统等各个子系统彼此之间互相
9、关联,以高稳定性、高安全性运转的同时,还需要在低时延情况下处理高并发压力,从而在赛时做到底层零故障、业务零中断。第二章节以北京冬奥为例,讲述云上大型赛事的业务架构、保障目标及面临的挑战,从而构建一套完善的保障方法论。第三至第七章则分别从压测调优与技术演练、监控告警与应急预案、安全设计与安全攻防、云产品稳定性治理与风险管控、保障阵型与流程管理等子工作项分别阐述 图:北京冬奥组委给阿里云发来的感谢信!03 云上大型赛事保障白皮书云上大型赛事保障白皮书保障体系的具体内容。非云原生的系统迁移上云之后,首先需要评估系统整体的性能以及业务稳定性。第三章节主要阐述如何用压测调优和技术演练的方式评估系统性能,
10、及两种方法在北京冬奥保障上的应用。尽管压测调优和技术演练已经可以帮助我们提升系统性能、排查故障隐患。但是在实际应用中,风险仍然不可避免。第四章节主要讨论如何通过监控告警体系来实现对各系统实时运转情况的感知,以及对风险的及时应对。不同于常规系统,大型赛事由于其自身的影响力和复杂性极大,故而对系统安全性的要求极高,如何设计全面完善的安全防护能力成为大型赛事系统上云的难点之一。因此,第五章节主要讨论安全设计与安全防护。由于云上大型赛事使用的系统资源相当丰富、空间跨度非常大,云产品的稳定运转对保障业务稳定性起着至关重要的作用。第六章节会详细阐述云产品的稳定性治理,以及在风险管控方面的实践经验。面对云上
11、大型赛事盘根错节的业务体系、规模庞大的客户群体,如何构建合理的保障阵型、设计完善的保障流程,对保障团队的专业度和经验值是一个极大的考验。在第七章节,我们将总结数次保障经验,分享基于前中后台的服务保障阵型,以及基于业务影响的风险保障流程。大型赛事上云,作为一种新兴发展领域,顺应了时代发展,也见证了时代进步。在第八章节,我们展望未来丰富多彩的云上世界,脚踏实地走好技术的发展创新之路。1 OBS Media Guide OLYMPIC WINTER GAMES BEIJING 2022https:/www.obs.tv/prx/asset.php?tgt=OBSBeijing2022MediaGui
12、de-February2022v5-38e55096dd38.pdf&gen=12 Alibaba Cloud,First Olympic Winter Games to Host its Core Systems on Alibaba Cloud,February 22,2022https:/ 04撰写期间,非常感谢北京冬奥组委技术部给我们提供的帮助,从外部视角提出了十分有效的建议和意见。创作团队名单顾问组成员万谊平 潘峥 李晓明 胡甜 张大志 曹林 主编团队王钊 赵哲 胡海峰 陈海清 李盈 韩冰 05 云上大型赛事保障白皮书云上大型赛事保障白皮书第一章 大型赛事云上数字化转型大型赛事,一方
13、面是指体育赛事的规模巨大,另外一方面是指体育赛事对后来的影响具有持续作用3。具体而言,指具有洲际、世界性的各类综合性体育竞技赛事,如奥林匹克运动会、亚洲运动会等,或由世界单项体育组织举办的具有较大影响的单项运动会,如国际足联世界杯、世界篮球锦标赛、世界游泳锦标赛等。本书所讲述的大型赛事,以奥运会为例。让我们从历史背景开始,介绍奥运会数字基础设施的上云之路。1.1 历史背景百年奥运基础设施发展史,也是一部人类科技发展史,人类的最新科技,总会第一时间应用在奥运会上。1964年东京奥运会,卫星转播技术的应用使全世界第一次在电视上实时观看奥运赛事。1976年蒙特利尔奥运会,首次引入大型机进行比赛结果处
14、理与分发,奥运会也由此进入电脑时代,并在之后的数届中逐渐完成了基于现代电脑和现代软件的核心系统基础设施数字化。1996年亚特兰大奥运会,则出现了第一个运行在万维网上的官方奥林匹克网站4。进入新千年,奥运会的业务系统逐渐完成了从分散部署到基于数据中心的数字化整合过程,并且伴随着整体算力的飞速扩展,呈现出数字时代的鲜明特征。2012年伦敦奥运会,仅奥运会核心供应商源讯(Atos)所管理的业务系统规模就达到了900台服务器、1000台网络和安全设备以及9500台计算机。2016年里约奥运会,其IT数据中心占地多达1272平方米,现场工作人员多达500名5。过去二十年,这种基于数据中心的模式支撑了所有
15、的奥运业务系统,我们称之为传统的数字基础设施。随着时间的发展,传统的数字基础设施开始面临转型需求,并且由于奥运庞大的规模使然,这种需求要比其他赛事更为迫切。06 云上大型赛事保障白皮书云上大型赛事保障白皮书为什么会出现这种转型需求呢?首先,是冗余建设和资源浪费问题。过去为了满足复杂而苛刻的业务和技术要求,不仅使用的资源要富足,并且还需要额外备份整个系统建设。然而这些固定投入在赛时短暂使用之后又要被闲置和拆除。这种数字基础设施的冗余建设,给主办方带来成本负荷之外,也造成资源的极大浪费。其次,是业务灵活性问题。传统机房的数字基础设施,在规划初始即已设定系统承载能力,这就导致当遇到突发算力需求或流量
16、洪峰时,系统没有能力灵活应对,从而造成服务降级。此外,安全问题、绿色环保、资产轻量化等因素,也都促使了奥运这类大型赛事对数字基础设施的转型需求。因此,作为奥运会的主办方和承办方,国际奥委会IOC(International1Olympic Committee)和主办城市奥组委一直以来有着强烈的数字化转型意愿。随着云计算技术的逐渐成熟,云厂商能够提供低成本、高稳定性、高弹性的解决方案,“上云”成为了国际奥委会和主办城市奥组委设计数字基础设施时的一个可选项。3 Getz D.Event:Event Management;Event MarketingC.IN:Jafari J.Encycloped
17、ia of Tourism.New York:Routleledge,2000:209212.4 Boris Sakac,Information technology at the Olympic Gameshttps:/ Rio de Janeiro,Atos opens IT Integration Testing Lab for the Rio 2016 Olympic and Paralympic Games,April 9,2015https:/ 071.2 上云优势通过对奥运赛事云上转型需求的分析,本节从降本增效、绿色低碳、灵活弹性和资产轻量化四个方面详细了解大型赛事数字基础设施上
18、云之后的优势。降本增效“此前每一届奥运会举办前的一两年,主办方都要把直播转播相关服务器或IT设备用集装箱跨海跨国地运到举办地,在集装箱里漂洋过海,再重新搭建、测试、使用,结束后又全部拆除。”北京冬奥组委技术部部长喻红回忆到,2008年北京奥运会的环境和设备良好的300平方米的主数据中心在短暂使用半年后被拆除的场景,让她至今都觉得心中有隐隐的痛。喻红坦言,当2009年第一次听到云服务时,“我看见了光。”云技术在奥运会的广泛应用,使得IT基础设施的成本大幅下降。按需收费的模式,为奥组委和各个合作伙伴大大降低了技术人员、硬件设施、运营维护的成本,简化了奥运业务系统的开发集成和部署流程,既缩短了建设时
19、间,也丰富了用户体验。绿色低碳近年来,云厂商的机房建设在降低能耗、绿色低碳方面取得了长足的技术进步。以北京冬奥为例,位于张北的冬奥云数据中心通过自然风冷、浸没式液冷、智能调温等技术,实现100%无机械制冷,相比传统机房,将热能耗降低至70%以上。北京冬奥云数据中心机房里,一排排服务器被浸泡在绝缘冷却液里,它们产生的热量可以直接被冷却液吸收进入外循环冷却,全程用于散热的能耗几乎为零。这种形式的热传导效率比传统的风冷高出百倍,实现了数据中心100%无机械制冷。通过使用云数据中心,北京冬奥会在赛前不用搭建大量IT设施,赛后也无需拆除,将能耗降低了70%,相当于多种400万棵树。全面上云,使北京冬奥会
20、变得更为绿色、低碳、环保。灵活弹性08 云上大型赛事保障白皮书云上大型赛事保障白皮书传统机房一直以来都面临着资源部署不灵活的问题,当发生突发大流量时无法快速扩容。而上云之后则可以利用云厂商的弹性资源部署能力,实现业务系统的快速部署、自由扩展。仍以北京冬奥为例,冬奥组委技术部信息处处长谷岩表示,北京冬奥会最大的挑战是在防疫需求下,各环节和系统都需要根据防疫手册及时变动。2021年12月13日,距离冬奥开幕只剩下一个多月的时间,技术人员正在争分夺秒进行测试赛、常规压力测试等任务,此时最新版本防疫手册出台。“因为有云计算,我们可以弹性扩张计算资源,非常快速地对修改指令做出响应,满足最新防疫手册的信息
21、技术需求。”谷岩表示。云计算让大规模的动员和操作行动有了更多的可能性。资产轻量化另外一个非常具有奥运特色的优势是上云实现了资产的轻量化。传统转播以现场制作为主,需要庞大的制作团队、价格高昂的转播设备。而上云之后的云转播则将重资产、高门槛的传统转播“轻量云化”,实现了转播设备云端化和人员服务远程化。云转播把转播车的功能搬到云端,现场信号可以通过网络传输到云转播平台,只需要笔记本电脑等轻量级设备,就可以实现多路信号的云上导播切换。云转播还可以实现随处播功能,比如转播车难以行驶的高山大川等不再成为播出壁垒,只要有网络就可以进行直播。因此,在赛事现场看不到转播车,只需很少的制作人员就能在各大媒体平台进
22、行实时直播。1.3 上云之路如前所述,随着奥运基础设施数字化转型的需求,以及云计算领域的快速发展,自2016年里约奥运会结束后,国际奥委会就开始将“奥运技术架构向云上迁移”视为了重点发展方向。2017年阿里云成为了国际奥委会在云计算和电商领域首个顶级合作伙伴,从而拉开了百年奥运与新兴的云计算时代相结合的序幕。!云上大型赛事保障白皮书 92018年,在平昌冬奥会,奥运会核心供应商源讯(Atos)首次尝试使用其私用云Canopy交付奥运会的核心系统。同年,阿里云宣布和国际奥委会奥林匹克广播服务公司OBS(Olympic1Broadcasting1Services)联手打造奥林匹克转播云OBS1Cl
23、oud。OBS Cloud以云为基础设施,针对高要求数据流,提供高性能连接、处理、存储等技术能力,并且允许远程工作。也是在同年,阿里云与北京冬奥组委BOCOG(Beijing Organising Committee for the 2022 Olympic and Paralympic Winter Games)在张北联合揭牌了北京冬奥云数据中心,主打大规模清洁能源和风冷液冷服务器技术,目标是打造“云上奥运”和“绿色奥运”。2021年,在东京奥运会,Atos继续通过其私用云Canopy交付奥运会核心系统,同时国际奥委会奥林匹克频道服务公司OCS(Olympic Channel Service
24、s)开始将其部分核心系统,如奥林匹克官网O迁移到阿里云上,并且通过阿里云首次为全球注册媒体提供了云上发布会服务。而OBS则首次通过基于阿里云技术的图:时任阿里巴巴董事局主席马云与国际奥委会主席托马斯巴赫6 10 云上大型赛事保障白皮书云上大型赛事保障白皮书!OBS1Cloud,开启了云转播时代。与2016年里约奥运会相比,东京的国际广播中心减少了25%空间,现场工作人员减少了27%,而体育赛事转播时长增加了30%,达到9500小时以上,极大地提升了转播效率7。同年底,北京冬奥的奥运信息管理和分发、运动会管理、组织协同等核心系统开始了上云部署,实现了云端线上运行。图:OBS云转播中心6 IOC
25、welcomes Alibaba Executive Chairman Jack Ma to Lausanne,Jan 22,2019https:/ OBS Media Guide OLYMPIC GAMES TOKYO 2020https:/www.obs.tv/prx/asset.php?tgt=OBSMediaGuide-Tokyo2020-July2021-7e12cb46507f.pdf&gen=1云上大型赛事保障白皮书 11国际奥委会主席托马斯巴赫表示,北京冬奥会以前所未有的数字化水平,让更多人感受奥运文化与精彩,为奥运留下了全新的技术标准。在接受央视采访的时候,巴赫也提到:“云上
26、奥运,为奥运打开了一扇新的大门,为奥运书写新的历史。”图:阿里云总裁张建峰访问北京冬奥技术运行中心现场如果说平昌和东京是百年奥运与云计算的初遇初识和牛刀小试,那么2022年的北京冬奥,则可称之为双方的全面结合。北京冬奥组委顺应奥林匹克数字化变革趋势,将应用系统的“云化”作为一项重要任务,在国际奥委会技术部的指导下,在阿里云的强大技术支持下,开展了迄今为止最大规模的奥林匹克“上云迁云”运动,在百年奥运历史上首次将核心信息系统成功实现了“全面上云”。这是奥运科技创新的一个里程碑事件,我们称之为“奥林匹克核心系统全面上云”。12 云上大型赛事保障白皮书云上大型赛事保障白皮书回顾自2017年以来这一路
27、的上云之路,历经平昌冬奥、东京夏奥、北京冬奥,我们相信,云计算技术将会持续在未来的奥运赛事中散发光彩,为奥运的科技发展历程添加上浓墨重彩的一笔。图:国际奥委会主席巴赫接受采访评价云计算技术云上大型赛事保障白皮书 13第二章 云上大型赛事保障体系上一章,我们介绍了云上大型赛事的数字化转型,包括对奥运会数字基础设施历史背景的简单回顾、对上云优势的分析,描述了从2017年开始奥运会数字基础设施循序渐进的上云之路。本章将以理论概括为主,对云上大型赛事的业务和组织架构归纳总结,对技术保障体系进行整体介绍。2.1 云上大型赛事业务架构要做好云上大型赛事的技术保障,首先需要了解我们要保障的客户是谁,他们的角
28、色是什么,可以用下面的一张图来概括。图:大型赛事各参与方业务架构14 云上大型赛事保障白皮书云上大型赛事保障白皮书在奥会赛事上云项目中,云服务商所服务的实体主要有以下几个。国际奥林匹克委员会技术部:国际奥林匹克委员会(International1Olympic Committee)简称IOC。IOC技术部负责对奥运长期的合作伙伴和技术方案进行选择和决策,促进奥运知识和遗产在不同的OCOGs之间的传递和转移,促进主办方和合作伙伴的问题解决,协助和监控OCOGs技术应用演进和如期落地。国家奥林匹克委员会:国家奥林匹克委员会(National Olympic Committee)简称NOC,是按照奥
29、林匹克宪章的规定建立、并得到IOC承认负责在一个国家或地区开展奥林匹克运动的组织。是申办奥运时的政治实体,在申办成功后,成立主办城市奥林匹克组织委员会。主办城市奥林匹克组织委员会技术部:举办城市奥林匹克组织委员会(Organis-ing1Committees1for1the1Olympic1Games)简称OCOG,如北京BOCOG、东京TOCOG等。OCOG由IOC委托主办城市所在国的NOC成立,是每届奥运会实施组织、运营、管理的官方实体,并接受IOC、NOC指示。OCOG技术部是在技术层面对接技术合作伙伴、技术提供方、IOC功能机构(主要是OBS和OCS)、场馆方、政府部门的主要接口,是整
30、体技术项目的负责人,确保交付赛事技术方案的时效性,对赛事技术场馆的规划,实施和运行负管理责任。两个主要的IOC功能机构,或者叫IOC子公司(IOC Subsidiaries)如下:奥林匹克广播服务:奥林匹克广播服务(Olympic1Broadcasting1Services)简称OBS,是国际奥委会设立的附属功能机构,是奥运会的主转播商。OBS制作和传播无偏见的电视直播、广播和数字报道,作为一项服务分发给所有购买了奥运会电视和广播权的广播组织(称为权利持有广播公司,RHB,Rights Holding Broadcasters),以此将来自奥运会和残奥会的直播通过RHB传递给全球数十亿观众。O
31、BS负责奥运会期间的广播和电视运行中心国际广播中心(IBC,International1Broadcast Centre),在场馆和IBC为RHB协调和提供转播设施和服务,包括转播设备和通讯服务,在组委会内代表RHB提出服务需求,以及如果需要,担当专题片制作人和向RHB提供奥运档案资料等服务。云上大型赛事保障白皮书 15奥林匹克频道服务:奥林匹克频道服务(Olympic1Channel1Services)简称OCS,是国际奥委会设立的附属功能机构,运营着国际奥委会开设的互联网电视频道,及奥运会官方网站。OCS的目的是在奥运会期外,持续保持奥林匹克项目和运动员的曝光度,为奥运会创造更多价值和内容
32、,以支持国际奥委会在奥林匹克议程2020中提出的用奥林匹克运动以全新方式聚集起年轻世代、体育关注者和新观众的目标。以上每个实体,都运营着大量持续运转的项目系统,通过数字化运行、数字化竞技、数字化媒体、数字化体验等数字化创新的能力为其各自的核心参与者提供服务,这些核心参与者包括运动员、媒体、志愿者、工作人员、转播商、粉丝、数以亿计的观众等等,从而构成了连接全世界、连接全人类的奥运世界。2.2 云上大型赛事保障目标本节以北京冬奥为案例,阐述细化的业务架构,以及业务保障目标。项目按照业务维度将客户分为六大客户群实体:北京冬奥组委:全称为北京2022年冬奥会和冬残奥会组织委员会,英文简写BOCOG。在
33、北京冬奥,共有超过30个奥运核心系统全部迁移运转在云上,即核心系统全面上云,为2897名运动员和8000+注册媒体人、2万名志愿者以及工作人员提供不间断的服务。具体来讲,主要有三部分构成:一是源讯(Atos)所管理的庞大复杂的核心业务系统,可分解为奥运会管理系统Olympic1Management1System(OMS)和奥运会发布系统Olympic1Diffusion System(ODS),OMS的业务包括运动员的报名、注册和赛程制定等,ODS的业务包括奖牌、排名、赛会的记录等。二是BOCOG用来进行组织、运营、管理整个赛事的全部核心系统,包括赛事管理服务Game1Management1S
34、ervice(GMS)和综合办公(Corporate1IT),这里又涵盖了30多个子系统。GMS包括了运动员和志愿者、工作人员的衣食住行系统、16 云上大型赛事保障白皮书云上大型赛事保障白皮书HMS健康监测系统、MED医疗系统、FBS餐饮系统、AMS住宿系统、RHP约车系统、ADS抵离系统等等;CorpIT综合办公包括了IAM统一认证、DES数据交换、HMS人力资源等等。所有这些子系统构成了BOCOG用来行使日常管理权、进行日常工作的方方面面。除此之外还有移动管理终端冬奥通APP,在该APP中,不同账号可根据自己的角色访问不同的核心子系统。三是IOC和BOCOG合作的创新项目,即新闻发布会视频
35、服务系统(Info1AV,Info Audio Video)项目,或叫LSV(LiveStreaming Video)项目。这是IOC的创新项目,由北京冬奥组委具体实施,由第三方转播公司使用阿里云的IaaS资源完成。在北京冬奥期间,一共支撑了249场发布会,总时长160小时,整体流量11T+,4倍于东京奥运的流量。奥林匹克广播服务:即上文所提到的OBS Cloud。在北京冬奥期间,向全球转播了超过6000小时精彩内容,提供子弹时间素材2100+,累计运行超过400+小时,大量精彩内容被各大RHB选用播放。我们在电视上看到的实时直播、实时特效画面,都是由OBS Cloud提供给全球的RHB再触达
36、给全球观众的。奥林匹克频道服务:与东京奥运一样,OCS继续在阿里云上运转包括奥林匹克官网在内的几个核心系统。官网系统稍微特殊一些,有一个应用层的供应商在维护,阿里云为其提供了IaaS资源。国际奥委会:IOC虽然主要是管理机构,但也有一些技术项目存在,并托管在阿里云上。以上是北京冬奥案例的直接客户,除此之外,还有冬奥相关的非直接奥运客户。云展厅:这是北京冬奥组委为了推广“3亿人上冰雪”的愿景而面向大众推出的宣传项目,目的是让更多的人喜欢上冰雪运动,参与到奥会盛事,该项目在冬奥期间的访问流量非常高。云服务商的传媒行业客户:除了向赛事组织方提供业务保障,云服务商同样也要保障自身客户业务需求,保障他们
37、在赛事期间的活动计划顺利进行。此次冬奥,中央电视台(CCTV)的直播活动、抖音快手等短视频社交平台中的冬奥相关应援及直播活云上大型赛事保障白皮书 17也都受到阿里云的全面保障护航。在一场大型赛事活动中,云上保障的最终目的是完成所有直接客户及非直接客户的业务系统在整个赛事期间的技术保障。具体则可以将保障目标和核心指标拆分为以下两点:一是业务稳定性,即通过基础设施的风险巡检与治理、赛前的压测调优、技术演练、云产品稳定性治理等手段,实现赛时0故障,业务0中断的稳定性;二是服务即时性,即通过7*24的专家值守、监控与告警体系建设、应急预案设计等手段,实现基于业务影响程度的服务分级保障策略。2.3 云上
38、大型赛事保障挑战基于前文所总结的保障目标,结合云上大型赛事的特点,云上大型赛事保障的挑战有以下几点:安全要求最高级公开报道显示,从2000年悉尼奥运会开始,网络黑客就开始真正威胁到奥运会图:北京冬奥业务架构及保障目标18 云上大型赛事保障白皮书云上大型赛事保障白皮书的安全举办。随着数字化技术的普及,举世瞩目的奥运会成为网络攻击的重要目标,近十年来几乎每一届奥运会所面临的网络安全威胁都是上一届的N倍。也因此,北京冬奥项目组的安全运维人员从2018年起就进驻奥组委,和其他服务商一起为冬奥设计云安全架构方案,确保奥运期间的万无一失。业务目标多样性客户的角色分工和业务侧重点的不同,带来每个模块的不同业
39、务目标。例如,北京冬奥组委的核心系统涵盖30多个子信息系统,每个系统的运转都不可中断,其目标在于极强的高可用能力。源讯(Atos)的诉求则在于安全性和云服务可集成性。OBS Cloud因为其主要业务是实时的直播转播,因此对低时延非常看重。而像类似于云展厅这样的toC项目,则非常关心云服务所能提供的高并发能力。如何通过合理的架构设计和性能选择,满足复杂多样的客户目标也是云上大型赛事保障的挑战之一。重保过程超长期由于奥运会项目的重要性、复杂性,以及赛事的延续性,重保团队的组织能力和持续能力将受到一次全面的考验和升级。从保障体系和流程设计、资源调动和整合,到各团队之间协同配合、封网和必要业务的平衡等
40、等,均需要全面细致的考虑,确保保障过程万无一失。SLA高标准严要求保证业务连续性是北京冬奥对所有技术人员的最基本要求,赛时的SLA也会写入各个技术提供商的合同中,并对超出SLA情况有详细的罚则,IOC和冬奥组委要求技术人员要像膝跳反射一样在问题发生后做出最本能的恢复业务的反应,特别是对于最高优先级的P1问题,要做到5分钟响应、1小时解决的整体SLA,这基本是业界能力天花板,对云服务商的挑战不言而喻。超高可用性和超高性能为了保证业务系统达到7*24的质量服务登记且不能降级,所有云架构都要经过反复的功能测试、安全测试、性能测试,通过容灾演练、技术演练的验证。并且云资源要确保有足够的弹性以应对赛时突
41、发流量洪峰。因此,云架构方案必须重点考虑系云上大型赛事保障白皮书 19统冗余、备份和故障恢复,保证云产品的超高可用性和超高性能。2.4 云上大型赛事保障方法论总结往年云上大型赛事保障经验并结合此次北京冬奥会的实际情况,可以从赛前和赛时两方面来阐述云上大型赛事技术保障的方法论。2.4.1 赛前全局梳理赛前的全局梳理主要从重保需求、业务目标、架构梳理、风险评估四个维度开始,了解保障范围、沟通业务诉求、构建客户画像,从而明确云服务商在整个项目中的角色分工。图:北京冬奥保障体系能力体系目标业务稳定性赛时0故障、0业务中断技术演练根据业务目标进行容灾演练、技术演练、突袭演练,确保业务连续性压测调优针对各
42、子系统子模块进行模拟真实业务场景压测,对出现的问题解决并调优赛时巡检每日用户侧资源巡检和产品稳定性巡检,保证业务和产品的稳定稳定性治理产研合作稳定专项治理:包括库存水位/高可用风险/产品侧应急预案等专项全局梳理完成项目保障需求、业务目标、架构梳理等前置内容,确保有的放矢风险巡检基于Apsara Service Stack进行风险巡检与治理(用户实例及用云实践)服务即时性以冬奥为例:P1问题5分钟响应,1小时止血变更管控奥运封网期重大变更服务场景评估、客户通知、方案制定与落地应急预案针对告警主动应急预案处理以及垂直线技术场景预案梳理作战纪律业务恢复优先,保持对业务影响的敏感度,保证服务时效性,遵
43、循SOP多点协同区分前中后台形成多层阵型,精确排班保证服务连续性监控告警全垂直线基础产品监控告警AIOPS智能诊断,安全产品主动监控服务流程明确各角色职责分工和问题流转流程,标准化工具及流程,及时复盘20 云上大型赛事保障白皮书云上大型赛事保障白皮书重保需求和业务目标:以北京冬奥为例,首先了解其主要业务诉求:Info1AV项目要求高可用低时延;云展厅项目对峰值流量要求极高;而OBS Cloud关注点则在于时延性能上等等。明确了业务目标,在后续的保障方案制定时才能有的放矢,做到适配。架构梳理:通过三张大图“整体业务架构图、云资源产品覆盖图、系统架构图”,云服务商可以从大到小、从整体到局部地对客户
44、业务系统进行深入了解和细节把控。整体业务架构图:整体模块的业务架构图,体现整体业务逻辑和规模。图:赛前全局梳理风险评估架构风险容量风险变更风险架构梳理整体业务架构图云资源产品覆盖图系统架构图业务目标业务峰值指标业务高峰时间RT要求并发要求成功率要求容量要求重保需求SLA要求可用性要求梳理维度具体事项云上大型赛事保障白皮书 21云资源产品覆盖图:云产品的部署架构图,用于说明各云产品之间的链路关系系统架构图:各子系统链路组件及技术栈。图:整体业务架构图图:产品覆盖图22 云上大型赛事保障白皮书云上大型赛事保障白皮书风险评估:架构梳理完成后,即可针对当前已有信息进行首轮风险评估。包括架构风险,例如单
45、点架构风险、共享实例风险等。和容量风险,例如云产品水位风险、资源争抢风险、流控风险等。当然还有云服务的变更风险等。2.4.2 保障目标体系构建图:子系统架构图云上大型赛事保障白皮书 23在赛前全局梳理完成之后,还需要针对保障目标构建完整的保障体系,拆分为业务稳定性和服务即时性两方面。实现业务稳定性:为了实现赛时0故障、业务0中断的最终目标,技术方案可以归纳为:风险巡检、容量管控、压测调优、稳定性治理、技术演练等关键项,这也是整个保障体系中最重要的一部分。实现服务即时性:为了实现业务连续性、风险损失最低的整体目标,技术协同可以整理归纳为:监控告警、应急预案、职责分工、流转流程、作战纪律等关键项。
46、这部分内容的重点在于工具化、规范化、标准化和流程化。后文将全面阐述这套保障体系的内容。图:赛前要完成保障目标(业务稳定性和服务即时性)的体系构建24 云上大型赛事保障白皮书云上大型赛事保障白皮书2.4.3 赛时技术风险处置在赛时,技术保障团队需要确保赛前设计的整个保障体系可以全面运转,包括应急问题处置、重大问题复盘,技术定时巡检、服务连续性和业务协同性等等。在大型赛事保障体系中,为了实现整体业务稳定性和服务即时性,关键工作项的设计和处理非常重要,在第3-7章节将进行详细阐述。图:赛时要完成技术风险处置云上大型赛事保障白皮书 25第三章 压测调优与技术演练系统迁移上云之后,如何评估系统稳定性是我
47、们要面临的第一个问题。本章主要讨论如何使用压力测试的方法,通过测量量化的指标来评估系统整体性能,并在压测过程中进行系统调优,以及如何使用技术演练的方法,通过具体实践的形式评估系统整体稳定性,以及这两种方法在北京冬奥保障上的应用。3.1 云上大型赛事压测调优3.1.1 压力测试基本概念传统的业务系统并非生来在云上设计、云上搭建,也许我们非常了解系统的架构,清楚每个模块的规格和指标,但是系统整体在云上所能承受的性能量化级别是模糊的。此时就需要一种方法去评估系统整体性能及稳定性,这就是压力测试。压力测试可以帮助我们量化理解该系统架构是否可承载当前至未来一段时间的业务量,也可以帮助我们发现系统瓶颈、系
48、统可能存在的缺陷。压力测试是任何一个高可用高并发系统在上线之前必须经历的过程。以下量化指标常被用来评估压力测试效果:并发数:在同一时刻,同时操作同一个功能点的客户或客户端的数量。也可以理解为同时在线的用户数。QPS(Query Per Second):或者叫RPS(Request Per Second),是最重要的通用指标,指系统每秒能处理的请求个数,或指客户端所发起的每秒请求量。TPS(Transaction Per Second):指系统每秒能处理的事务个数。在单一功能模块场景下,QPS=TPS*每个事务所包含的请求数。假设一个事务只26 云上大型赛事保障白皮书云上大型赛事保障白皮书包含一
49、个请求,那么 TPS=QPS。成功率:在一定量级的QPS或TPS下,系统能成功处理的比例。在达到系统瓶颈时,成功率会极速恶化。RT(Response1Time):响应时间,是指用户在请求某个操作之后到获得结果之前需要等待的时间量。一般情况下这是客户端侧的参数,因此包括网络请求以及网络响应返回时间。吞吐量:反映处理能力总量的指标,在给定的时间内处理的事务量或请求量。CPU资源利用率、内存利用率、I/O、内核参数(信号量、打开文件数)等:一些通用资源指标,不再赘述。通常来说,一个优质的系统可以用较短的响应时间,以较高成功率处理高并发数的QPS请求,同时不会触发资源指标的性能瓶颈。而压测指标的侧重点
50、选取则需要业务方基于业务层面的考量提供明确的压测目标。例如,在北京冬奥通APP压测过程中,确定了压测目标就是系统需要满足xW日活(DAU,Daily Active User,日活跃用户数量),单接口成功率在99.99%以上,单接口RT在3s以内。作为云服务商,我们就可以根据此目标进一步拆解指标,完成压测。与这些指标相伴的是有关压力测试的一些术语,总结如下:事务:是作为单个逻辑工作单元执行的一系列任务,如完成一项查询,完成一次数据传输等。一个事务可能包含多次请求。在一个事务只有一次请求的情况下,TPS=QPS。压测机:也叫施压机,即模拟用户发起请求的机器。单接口压测:针对具体的某个接口实施的压力
51、测试。全链路压测:以全链路业务模型为基础,多个接口串行实施的压力测试。数据清理:压测过程中如果有存储操作,则可能会伴随脏数据,压测结束时要对脏数据清理掉。功能回归:如果系统有针对压测场景进行特定的调整或更改,压测及数据清理完成后,需要进行功能回归。云上大型赛事保障白皮书 273.1.2 云上大型赛事压力测试方法论压力测试的六大核心要点:明确压测目标、梳理压测链路、设计压测方案、配置压测环境、实施压测计划、解决压测问题。3.1.2.1 明确压测目标明确压力测试最终需要达到的目标,是设计与实施整个压测方案的先决条件。目前常见的压测目标可分为两类:一类是基于系统监控找水位,即在系统资源濒临阈值时检查
52、QPS以及对应RT,即为该系统的水位。一般用于评估业务系统可承受的QPS,从而判断当前系统架构是否可满足业务需求。一类是基于预估压力判断业务是否可正常运行,即在稳定的QPS下判断系统是否存在性能瓶颈,业务链路是否可正常运行。一般是用于在大型运营活动前,基于预估QPS对系统进行压测,提前找出性能瓶颈,保证运营活动正常运行。对于大型赛事活动的压测一般是第二类,即首先由业务方预估赛时的压力情况,再通过压测系统模拟该压力找到系统瓶颈。这里需要注意的是,业务方需要给定一个明确的预估压力值,例如1000并发用户数、8万QPS等,如果没有最终目标,压测就会进入不知道压到什么程度才算完成的尴尬局面。并且,这个
53、压力值是基于业务层模拟推导计算出来的,例如,冬奥通APP业务峰值是x万日活用户,对某个页面,根据业务观察,每个用户平均每天会打开10次,打开一次该页面的请求数为5个,那么我们考虑比较极端情况,假设所有用户的这10次请求都集中在某1个小时内,那么该页面的QPS要求即为:xk*10*5/3600=x QPS。再例如,云展厅项目有一个高并发的秒杀业务,预估用户数为8k,假设用户的一次点击产生一次请求,那么这个业务的QPS要求即为8k QPS。28 云上大型赛事保障白皮书云上大型赛事保障白皮书3.1.2.2 梳理压测链路梳理目标系统整体的架构及业务链路,可以体系化的帮助理解当前系统的业务链、业务链之间
54、的依赖关系、功能点所在的业务位置等等,是后续抽象压测模型、划分压测场景、设计压测方案、解决压测问题的关键依据。通常来讲,链路梳理的越细致,后续的工作就会越流畅。对于大型赛事而言,子系统繁多,链路间调用关系复杂,梳理起来对应的工作内容会比较多。一个比较好的最佳实践是根据系统架构图来理解每条接口链路情况,在下文冬奥通APP压测总结中我们将会看到,一个完整详细的系统架构图对链路梳理起了非常大的帮助。在梳理过程中也可以同时分析潜在的瓶颈点,并针对性的增加监控指标、制定应急预案等。例如,负载均衡产品潜在高频问题为容量不足、建连失败等,针对容量不足风险,可通过观察超限丢包指标来进行判断。数据库产品常见问题
55、为连接池耗尽、慢查询等,可通过连接池监控、SQL语句执行时间监控等来进行判断。不同风险的判断指标需要落在压测方案中。3.1.2.3 设计压测方案阿里云PTS产品团队总结的压测方案设计原则,要做到五个一样:一样的线上环境,一样的用户规模,一样的业务场景,一样的业务量级,一样的流量来源。对于大型赛事而言,由于赛程是固定的,所以环境准备这部分其实比较容易解决,因为一定是要在生产环境上线之前进行压测,这时还没有真实用户,但环境已经搭建完毕,此时即为压测的最佳时段。但如果是已经线上运转的生产环境,那么设计压测方案时要做一个取舍,生产环境和测试环境的压测方案各有其优缺点:针对生产环境压测,其衡量的精准度较
56、高,参考效果更好,但是会有一些额外的成本,首先需要对相关的测试数据进行处理,包括压测时如云上大型赛事保障白皮书 29何插入测试数据不会影响生产,以及压测结束后脏数据的清理,同时,也要谨慎考虑压测流量对生产环境造成的影响,要尽量挑选在低峰期进行。针对单独的测试环境压测,其难点在环境的构建上,规模和生产一致的成本也是最高的,所以一般而言为等比构建(生产环境的1/2,1/4,1/8等),甚至是生产环境中部分应用独立部署测试集群,数据库共用的方式,此外测试环境需要从生产环境中导入脱敏的基础数据,例如至少是最近半年或者1年的,保持其整体的数据关联性,这个对于压测的准确度和参考性也很重要。如何准确模拟用户
57、规模、业务场景、业务量级、流量来源是一个比较大的课题。从工具层面来讲,一般是通过专用压测工具如jmeter或直接购买压测服务来进行模拟。使用jmeter等压测工具,需要针对业务场景有针对性的进行分布式部署,可部署在三方的专用压测机云环境,但需要自行编写压测机压测脚本,对技术水平的要求比较高,因为压测准确性很大程度上取决于脚本是否能完美模拟用户请求场景。当然也可以使用专有的云上压测服务,阿里云有一个SaaS化的性能测试分布式云化压测服务PTS(Performance Test Service),其压力发起来源是遍布全国上百个城市和各运营商的CDN节点,可分布式的模拟海量用户的真实业务场景,可以作
58、为压测方案一个轻量快速的选项。要写出能准确模拟真实场景的压测脚本,需要深刻的了解系统的业务模型,系统有很多业务,每种业务逻辑和业务量是不一样的,系统的基础数据、系统预热情况等代表系统的状态。链路范围、链路的访问量级、链路的参数集合、基础数据、预热情况一起构成了压测的业务模型。需要编写者非常了解在真实场景下,各个业务种类的请求模型,及对应的业务占比,以进行不同的容量整体配比,精准地将流量落地。保证压测结果可靠性的几个关键点在:业务逻辑改动要仿真业务场景,QPS配比要仿真业务场景,入参满足业务仿真的需求,影子数据满足业务仿真的需求。同时,压测方案中要包括需要监控的指标,包括压测机资源指标、业务指标
59、、服务端资源指标等。如果是对生产环境压测,也要设计对应的紧急问题的应急预案,如数据回滚、数据清理等。30 云上大型赛事保障白皮书云上大型赛事保障白皮书监控指标应包含以下内容:客户端和服务端操作系统:CPU利用率、内存利用率、磁盘I/O、网络I/O、内核参数等。中间件:nginx返回码、JDBC连接池、SLB超限指标等。数据库:慢SQL、锁、缓存、会话、进程数等。应用侧:请求响应时间、请求超时率、请求成功率、QPS等。3.1.2.4 配置压测环境在预上线环境进行压测,需要注意的是测试数据的准备要和真实用户场景数据一致,可使用生产数据例如人员ID、生产账号账密、生产日期、生产位置等真实数据进行压测
60、,但要注意数据清理和功能回归。在生产环境进行压测,最核心的是线上写操作不能污染正常的业务数据。因此,需要针对存储做影子库表,即正常业务库表的镜像,让压测流量的数据流转到影子库表,正常业务流量流转到正常业务库表,在逻辑上隔离两种流量,使之互不影响。另外一个关键点是配置完善的监控,没有完善的系统监控,将会导致性能分析无从下手。3.1.2.5 实施压测计划在真正实施压测时,要按照阶梯加压的原则进行,首先从小流量压力开始,按照合理阈值逐段增压,同时关注各监控指标数据,在开始性能恶化时即为系统原始性能基线数据与容量,以此为优化初值。观察监控指标除了留意异常告警外,还应留意:应用侧指标是否正常,业务成功率
61、是否满足预期,请求响应时间是否有恶化。中间件流量是否有毛刺和异常下跌情况,是否有超限丢包、连接池打满、返回云上大型赛事保障白皮书 31码大量报错等现象,上下游流量是否对齐,即在相同的时间段到达流量峰值。客户端和服务端是否有性能超限情况,例如CPU打高、IO打满等。数据库是否有大量慢SQL产生,RT偏高、连接池满等现象。也要留意压测场景目标是否都达到,是否需要再补充压测场景。3.1.2.6 解决压测问题压测时一定会遇到具体的问题,这部分属于如何进行系统调优,将在下一小节讨论。以上即为压测通用方法论,无论压测的形式如何更改,其本质皆为这六大核心要点,流程图如下。3.1.3 云上大型赛事系统调优本节
62、讨论针对压测时遇到的具体问题如何进行系统调优。3.1.3.1 常见问题及应对3.1.3.1.1 压测机和服务端问题压测机和服务端上产生的问题通常是系统瓶颈问题,例如压测机发包速率上不图:压测流程图32 云上大型赛事保障白皮书云上大型赛事保障白皮书去、服务端队列溢出、服务端Conntrack表项打满等等,这些系统内问题一般都会有相应的性能指标指示,我们可以通过通用的系统性能问题排查方法找到瓶颈点,并做对应的调整。Linux系统下常见的排查手段命令如下:top命令可以动态查看当前系统的资源情况,以及占用资源的命令列表。dmesg=/var/log/dmesg命令可以快速查看系统启动过程中的内核日志
63、信息,包括:系统设备信息、启动和操作过程中系统记录的任何错误和问题。vmstat 1 5命令输出系统核心指标信息,1 5 表示1秒输出5次信息。mpstat-P ALL 1命令可显示CPU的个数,以及每一个CPU被占用的状况,如果有一个CPU占用率特别高,那么有可能是一个单线程应用程序引起的。pidstat 1输出进程的CPU占用率会持续输出,并不会覆盖之前的数据。iostat-zx 1查看机器磁盘IO情况。sar-n DEV 1 查看网络设备的吞吐率。sar-n TCP,ETCP 1 查看TCP连接状态。systcl-a|grep ipv4 查看Linux系统网络相关内核参数。netstat
64、-tan|grep tcp|awk+a$6 ENDfor(i in a)print i,ai 统计Linux系统不同状态的tcp连接数。netstat-st|egrep-i drop|reject|overflowed|listen|filter 显示系统队列溢出、丢包计数。Windows系统常见的排查工具如下:Task1Manager提供一些排查通用信息,包括系统整体资源利用率、各进程资源占用率、注册服务信息等。Resource1Monitor可实时监控系统详细性能,包括CPU、内存、磁盘IO和网络。Event1Log检查操作系统各组件日志,包括系统日志、应用程序日志和服务日志。云上大型赛事
65、保障白皮书 33Regedit检查系统注册表。注册表实质上是一个庞大的数据库,它存储和管理关于系统的一切信息。Process Explorer为Microsoft提供的Sysinternals工具,可以检查各进程详细信息和hook信息、句柄信息。Process Monitor为Microsoft提供的Sysinternals工具,可以捕获进程的大多数操作数据。WinDbg为Mircosoft提供的GUI调试器,可以调试应用程序,或者提供Windows操作系统的Kernel Debug。CPU瓶颈常见考量点:CPU资源利用率很高的话,需要看CPU消耗User、Sys、Wait哪种状态。如果CPU
66、1User非常高,需要查看消耗在哪个进程,可以用top(Linux)命令看出,接着用topHp看哪个线程消耗资源高。如果是Java应用,就可以用jstack看出此线程正在执行的堆栈,看资源消耗在哪个方法上,查看源代码就知道问题所在;如果是c+应用,可以用gprof性能工具进行分析。如果CPU Sys非常高,可以用strace(Linux)看系统调用的资源消耗及时间。如果CPU1Wait非常高,考虑磁盘读写了,可以通过减少日志输出、异步或换速度快的硬盘。内存瓶颈常见考量点:操作系统为了最大化利用内存,一般都设置大量的cache,因此,内存利用率高达99%并不是问题,内存的问题主要看某个进程占用的
67、内存是否非常大以及是否有大量的swap(虚拟内存交换)。磁盘I/O常见考量点:磁盘I/O一个最显著的指标是繁忙率,可以通过减少日志输出、异步或换速度快的硬盘来降低繁忙率。网络I/O常见考量点:网络I/O主要考虑传输内容大小,不能超过硬件网络传输的最大值70%,可以通34 云上大型赛事保障白皮书云上大型赛事保障白皮书过压缩减少内容大小、在本地设置缓存以及分多次传输等操作提高网络I/O性能。内核参数:内核参数一般都有默认值,这些内核参数默认值对于一般系统没问题,但是对于压力测试来说,可能运行的参数将会超过内核参数,导致系统出现问题,可以用sysctl来查看及修改。3.1.3.1.2 中间件问题中间
68、件问题通常是超限问题,例如SLB1QPS超限、nginx节点不足、EIP流量超限、JDBC连接池不足等等,可以通过组件监控指标查看到,一般是通过升配(Scale up)或者扩容(Scale out)解决。3.1.3.1.3 数据库问题数据库层面需要关注慢SQL、死锁等等。最常见发生的就是慢SQL问题。索引最常见的情况是在数据量比较大的情况下,应用程序的SQL语句未建立索引,或者未能利用索引,产生了全表扫描。带有NULL会导致索引性能低。例如表中有空NULL值或者语句中有IS NULL或IS NOT NULL。锁如SQL语句产生表级锁,将会锁住整个表,导致性能恶化。创建临时表会产生大量日志也可能
69、会导致性能恶化。以上问题可以通过具体的SQL语句调整解决。3.1.3.1.4 应用侧问题应用侧本身问题包括GC/FULL1GC频率过大、应用线程池不足等问题,需要检查应用端代码解决。云上大型赛事保障白皮书 353.1.3.2 通用调优方法根据我们的经验,下面是一些通用参数调优,当然,并非放之四海而皆准,但可以应用到大部分环境。3.1.3.2.1 Linux内核参数添加如下参数至/etc/sysctl.conf并执行sysctl-p生效。net.ipv4.tcp_syncookies=1net.core.somaxconn=4096net.ipv4.tcp_max_syn_backlog=819
70、2net.ipv4.tcp_max_tw_buckets=filter.nf_conntrack_max=filter.nf_conntrack_tcp_timeout_established=1200net.ipv4.ip_local_port_range=1024 60999tcp_timestamps=1tcp_tw_recycle=0net.ipv4.tcp_tw_reuse=1net.ipv4.tcp_fin_timeout=30net.ipv4.tcp_max_tw_buckets=5000执行 ulimit-SHn 655350 后,修改如下参数至/etc/security/li
71、mits.conf#/etc/security/limits.confroot soft nofile 655350root hard nofile 655350root soft nproc 655350root hard nproc 655350*soft nofile 65535036 云上大型赛事保障白皮书云上大型赛事保障白皮书*hard nofile 655350*soft nproc 655350*hard nproc 6553503.1.3.2.2 Tomcat配置调整使用Tomcat做为Web服务器时的通用调整。配置文件:server.xml 中 acceptCount=409
72、6,重启tomcat生效。验证backlog设置是否生效的方法:执行ss-tanl,找到业务进程监听的端口行,Send-Q列为当前生效的backlog值调整完之后应为4096,具体tomcat应用可以从下图的监听端口判断:3.1.3.2.3 Nginx配置调整如果用NGINX做反向代理,到upstream需要调整为长连接,(短连接在大并发时会引起各种问题),nginx.conf配置文件如下。http upstream my_upstream keepalive 1024;/保持的长连接数量,按需调整server XXX;图:Tomcat配置之backlog 检查云上大型赛事保障白皮书 37se
73、rver .#upstream使用长连接location/keepalive proxy_pass http:/my_upstream;proxy_http_version 1.1;/proxy_pass模块默认使用HTTP/1.0,要显示指定1.1proxy_set_header Connection;.其他nginx.conf配置worker_connections 调整为 10240worker_processes 调整为 autoworker_rlimit_nofile 调整为 102400重启nginx:systemctl restart nginx生效3.1.3.2.4 操作系统参
74、数开启网卡多队列。单个vCPU处理网络中断存在性能瓶颈时,可以将系统中的网络中断分散给不同的vCPU处理,从而提升性能。网卡多队列是一种技术手段,可以解决网络I/O带宽QoS(Qualityfof Service)问题。网卡多队列驱动将各个队列通过中断绑定到不同的核上,从而解决网络I/O带宽升高时单核CPU的处理瓶颈,提升网络PPS和带宽性能。经测试,在相同的网络PPS和网络带宽的条件下,与1个队列相比,2个队列最多可提升性能达50%到100%,4个队列的性能提升更大。38 云上大型赛事保障白皮书云上大型赛事保障白皮书3.1.3.2.5 信息收集方法内核参数列表:sysctl-a sysctl
75、_conf.lognginx配置文件默认为/etc/nginx.conf以及/etc/nginx/conf.d/下所有配置文件,如非标准安装应可在具体安装目录下寻找。Tomcat配置文件默认为server.xml web.xml context.xml log4j.properties tom-cat.conf,如非标准安装应可在具体安装目录下寻找。3.1.4 北京冬奥压测调优总结北京冬奥一共有30多个子系统在云上,我们针对部分核心子系统进行了全面的全链路压测,以确保赛时不会出现系统瓶颈,下面具体介绍其中两个系统的压测过程,即冬奥通APP系统和冬奥云展厅系统。3.1.2.1 冬奥通APP压测总
76、结冬奥通APP是北京冬奥组委为包括运动员、志愿者、媒体人员、赛会工作人员及普通观众等所有赛事参与者推出的移动端APP,集成了各种角色在本次赛会期间会使用到的功能模块。从业务上,可以分为16个模块,包括高频的首页、路由、配置中心、奖牌榜、组织、组织应用授权、打卡、餐饮、IM等模块,以及低频核的统一身份认证、个人授权、赛事赛程等模块。冬奥通APP系统全面运行在阿里云上,主要使用的产品是阿里云DCDN、SLB、ACK、ECS、RDS等,为保证安全性,整体划分为DMZ和Trusted区,用户请求流量经DCDN接入,过WAF后通过EIP+SLB(前端SLB)上到云内,先到DMZ区的前端代理服务进行初步处
77、理,再转发至Trust区的后端服务上。在DMZ区和Trust区各部署一个大型ACK集群,分别运行各功能模块的前端代理服务和后端功能服务,各功能模块以K8S1pod的形式存在,共享ACK集群节点,由ACK进行调度,DMZ区和Trust区之间用一批SLB做中间层转发(后端SLB),部分后云上大型赛事保障白皮书 39端服务需要再VPC内访问数据库进行读写操作。整体来讲,冬奥通APP是一个比较标准的云上系统。如前所述,在制定压测方案前,我们基于业务目标明确了本次压测需要取得的最终目标,即为高频模块达到x并发和低频模块达到x并发,并保证错误率小于0.01%,RT小于3s。链路梳理方面,在压测前,我们先梳
78、理了全部16个模块详细的网络链路,以路由模块为例:用户-冬奥通APP-SLB3(lb-xxx,七层,443端口)-DMZ1ECS上的node-port:xxx(xxx端口)-SLB7(lb-xxx,七层,xxx端口)-Trusted区ingress1pod:xxx(七层)-Trusted区pod:xxx(路由服务)其余几个模块简化版链路如下,不再一一赘述:奖牌榜模块:用户-冬奥通APP-SLB1-DMZ区ECS1-1系列前端pod-SLB5-Trusted区ECS2-1系列服务pod 打卡模块:用户-冬奥通APP-SLB1-H5前端pod-SLB5-打卡服务(和RDS实时交互)-组织开放平台服
79、务餐饮模块:用户-冬奥通APP-SLB1-H5前端服pod-SLB5-餐饮服务IM登录模块:用户-冬奥通APP-SLB2端口xxxDMZ区ECS1-2上node-port:xxx-ipvs-SLB6-Trusted区ECS2-2系列xxx-xxx-RDS MySQL服务赛事赛程模块:用户-冬奥通APP-SLB1-DMZ区ECS1-1系列pod-SLB5-Trusted区ECS 2-1系列服务pod埋点模块:用户-冬奥通APP-SLB3-SA(nginx ECS)事实证明,事前的详细链路梳理,对于排查压测问题非常有帮助,在压测到性能瓶颈时,我们根据梳理好的链路,迅速切入排查找到了瓶颈点,即便是比
80、较疑难的问题,最终也没有过夜。压测方案和环境部署方面,本次我们采用了自建jmeter工具进行压测,压测机部署在第三方云平台,调用各模块公网接口模拟用户请求,压测脚本、各模块测试账号40 云上大型赛事保障白皮书云上大型赛事保障白皮书由业务方提供。我们一共规划了5轮压测,每轮压测约5-8个模块不等,在每轮结束后,收集相关数据及问题现场,对出现的系统瓶颈进行分析和调整,并制定下一轮压测计划,观察优化后的性能效果。根据各模块接口的业务占比、日活跃用户数、用户行为,我们计算出每个模块接口所需要达到的并发用户数,及对应的QPS。各模块初始并发及加压策略如下,以其中一个模块为例。系统调优方面,最终我们一共完
81、成全部16个模块x个接口的单接口压测及一次混合场景的全链路压测,整个过程一共发现问题18个,包括应用侧自身问题3个和系统架构调优问题15个,除此之外,我们也发现并执行了一共35条针对RDS的优化动作。最终效果冬奥通APP各模块的并发量提升了2倍-5倍,有力的保证了赛时该系统的稳定性。以下是一些具有明显改善效果的问题记录:第一轮压测开始时,大部分模块在加压到x并发时即发生了成功率恶化,提示系统瓶颈的存在。我们通过全链路资源监控指标的梳理,发现了三处瓶颈:一处为多个模块的前端SLB的EIP公网入口流量超限丢包,该问题通过使用大带宽的共享带宽替换各个SLB的单EIP解决。一处为路由模块压测x并发时,
82、因为该模块业务模型的原因QPS比较高,导致了前端SLB发生QPS超限返回了大量503异常码,该问题通过SLB升配方式解决。一处为多个模块ACK集群服务中承载SLB流量的ingress1pod资源使用率过高,造成多个模块偶发发生请求timeout,为此扩容了DMZ区和Trust区承载SLB流量的ingress1pod数量,该问题得到解决。在这些比较明显的瓶颈点解决之序号备注加压策略运行时间初始并发数场景描述首页3分钟并发数按照x基数增长结合性能结果中响应时间,错误率,服务器资源数情况,灵活调整并发数x1云上大型赛事保障白皮书 41后,结合RDS层面的SQL优化建议,我们在随后的压测可以看到大部分
83、模块已经可以达到压测目标。之后我们解决了一个非常具有参考意义的疑难问题:在调优和SLB升配之后,此时已不再存在简单的超限或超时问题,但路由模块和配置中心模块在x并发时仍可以观察到大量的5021Bad1Gateway报错,但节点监控没有明显异常。考虑到这两个模块的业务模型,同并发场景下比其他模块的QPS都要高,我们怀疑在ACK集群节点转发组件上产生了瓶颈。我们在复现问题时在节点上进行了抓包,通过抓包可以看到由SLB发来的TCP1SYN建连报文有一定概率被延迟转发或者丢包,同时conntrack-s检查conntrack状态表显示大量 insert_failed和drop计数。图:ACK集群节点抓
84、包显示IPVS延迟转发图:ACK集群节点抓包显示IPVS丢包42 云上大型赛事保障白皮书云上大型赛事保障白皮书考虑到ACK集群nodeport的用法实质上起的是一个NAT的功能,节点在处理每一个TCP流的NAT转换时都需要插入conntrack表项。根据压测高峰期时的QPS计算,按TCP连接TIME_WAIT状态默认120秒的回收速度,节点上的conntrack表项会不够空间插入。因此我们缩小了节点上IPVS1Conntrack表内核参数中针对TIME_WAIT状态的保留时间,由默认120秒改为了15秒,以快速回收,具体命令如下:a.操作sysctl-filter.nf_conntrack_t
85、cp_timeout_time_wait=15b.回滚sysctl-filter.nf_conntrack_tcp_timeout_time_wait=120在做了这一调整之后,再次压测路由模块和配置中心模块时,果然502问题不再发生。之后,这个内核参数优化动作,我们也应用到了DMZ和Trust集群的所有节点上。另外一个问题是在压测埋点模块时,初始并发就达到了1.54%的503超限错误码。埋点模块的链路比较简单,前端SLB直接挂了一个运行nginx的ECS。我们通过检查SLB日志可以看到是由nginx返回的503,检查nginx上的参数配置可以看到并发连接数的配置较小,调整之后即得到解决。全部
86、的问题列表及解决方案如下:问题描述序号1234问题现象问题原因解决方案压测多个模块时发现SLB的公网入口流量超限丢包SLB 流量超限SLB QPS超限利用大带宽共享带宽替换各SLB的单EIPSLB规格升配RDS慢SQL资源利用率过高针对具体的SQL添加索引优化某模块ingress pod扩容压测某模块SLB返回大量503异常码某模块SLB性能瓶颈在RDS性能日志中观察到多个模块有慢SQL某模块ingress pod资源利用率过高带宽资源受限多模块慢SQL问题某模块偶发报错timeout超时云上大型赛事保障白皮书 43问题描述序号10111213151456789问题现象问题原因解决方案QPS超
87、限经评估不再升配某模块x并发时能看到0.54%的偶发503报错某模块503超限问题QPS超限经评估不再升配调整nginx并发限制后仍有部分503报错某模块503超限问题应用侧问题应用侧调整应用侧报错某模块应用侧报错nginx并发连接数限制导致调整nginx并发连接数参数初始压测SLB返回1.54%的503错误码某模块503超限问题应用侧SQL语句高并发支持性问题修改应用侧SQL语句逻辑高并发场景下应用侧大量返回504错误码某模块大量504问题应用侧SQL语句逻辑问题 修改应用侧SQL语句逻辑初始压测时应用侧返回高达12.54%报错消息某应用授权模块应用侧报错共享带宽包流量超限扩容共享带宽包某模
88、块x并发时共享带宽包流量出现丢包某模块高并发流量超限某模块x并发时大量502 Bad Gateway报错ACK容器集群节点IPVS参数netfilter.nf_conntrack_tcp_timeout_-time_wait调优某模块x并发时大量502 Bad Gateway报错某模块高并发502问题资源利用率过高某模块ingress pod扩容某模块ingress pod资源利用率过高某模块偶发报错timeout超时资源利用率过高某模块ingress pod扩容某模块ingress pod资源利用率过高某模块偶发报错timeout超时资源利用率过高某模块ingress pod扩容某模块ing
89、ress pod资源利用率过高某模块偶发报错timeout超时44 云上大型赛事保障白皮书云上大型赛事保障白皮书最终,经过全面的压测和调优,我们得以保证冬奥通APP在赛时稳定运转,为2897名运动员和8000+注册媒体人,2万名志愿者、工作人员提供了不间断的服务8 3.1.2.2 云展厅项目压测总结云展厅项目是北京2022年冬奥会及冬残奥会的官方线上展厅,打造3亿用户在线上与冬奥沟通和互动的乐园,实现奥运的全民参与。“北京2022云展厅”是北京冬奥组委与阿里巴巴携手用科技力量消减疫情影响、实现合作伙伴展示权益的一项创举。按照惯例规则,国际奥委会应为各级别赞助商提供线下品牌宣传等权益。但因疫情影
90、响,此权益的兑现受到严重影响。云展厅则通过数字能力为22个奥赞伙伴提供线上展示,此项创举有望成为后续奥运赞助商权益关系中的有机组成部分。云展厅打造集奥运展示与互动体验为一体的冰雪狂欢互动城,为参与观众提供线上更丰富多元的沉浸式体验。观众可以通过展示中心一键了解本届奥运的理念,各类奥运知识以及所有奥运品牌的相关历史。除此之外,观众还可通过冰雪狂欢互动城中的系列趣味性、沉浸式互动,感受冬奥氛围,加强与奥运的连接。“北京2022云展厅”是奥运历史上的首个线上展示平台,也是参与合作伙伴最多的一次(共22家合作伙伴参与),国际奥委会和北京奥组委高度重视本次项目,并拟将项目列入阿里巴巴集团VIK资源,以期
91、实现与IOC的长期合作。问题描述序号161718问题现象问题原因解决方案应用侧报错应用侧问题应用侧问题应用侧调整应用侧调整应用侧报错某模块应用侧报错针对某模块502问题调查出来的内核参数优化建议,应用到了DMZ和Trust集群的所有节点上某模块应用侧报错内核参数调优云上大型赛事保障白皮书 45如上图,冬奥云展厅主要分为4大模块,分别为云展主应用,阿里巴巴展馆,松下展馆,冰雪互动城。云展主应用包含了云展账号、注册、展会信息、咨询、会议、抽奖、数据看板等信息。阿里巴巴展馆和松下展馆是两个主题展馆。冰雪互动城可以让用户进行游戏体验、收集徽章并抽奖。云资源架构:客户访问云展域名,域名会解析到DDoS,
92、DDoS回源到WAF,WAF在回源到公网SLB,公网SLB后端是部署在EDAS上的Nginx集群,Nginx会对流量进行分流,不同域名或者URL的请求转发到不同的内网SLB,内网SLB后端是真实的业务服务器,主应用使用的是java程序,冰雪&松下是PHP程序。对应的应用会调用Redis,RDS等读取数据库和缓存信息。图:云展厅项目业务架构46 云上大型赛事保障白皮书云上大型赛事保障白皮书常规调用链路:client-DDOS-WAF-公网SLB-Nginx-内网SLB-应用ECS-Redis/Mysql如果是图片访问会直接请求OSS:Client-D-CDN-OSS压测目标:主要功能界面能够达到
93、xQPS。在第一轮压测的时候大多数接口和页面只能承载xQPS,通过压测发现14个云平台和系统参数相关问题,最后根据业务架构和需求提供优化解决方案,包含资源规格优化、架构优化、数据库请求优化、应用参数优化等,最终实现xQPS的目标。其中一个比较典型的问题如下:客户端在调用初始化接口的时候,应用又会去调用用户接口判断用户是否是登录状态,但是应用二次调用用户接口的时候访问的是公网域名,这就导致二次调用的请求会通过自身的公网网关到公网,客户是使用NAT网关提供公网访问的,这时候就会占用NAT网关连接,当请求量增大的时候,占用的NAT的连接数也会成倍增加。而且域名是解析到DDOS上的,所以所有流量又会经
94、过DDOS,WAF,公网SLB等云产品,最终才会到达后端服务器处理,这样不仅仅占用了云产品的带宽,连接数等资源,又由于经过的多个网络组件,导致网络延迟也有一定的增加。这种场景下可以使用云解析privatezone优化,在业务VPC内配置业务域名,解析到内网的SLB上,这样可以避免二次请求的时候流量从公网绕行,优化网路链路减少云产品资源无效消耗。调优前网络链路:客户端发起初始化请求-DDOS-WAF-公网SLB-Nginx-内网SLB-应用ECS发起用户登录验证请求-NAT-D-DOS-WAF-公网SLB-Nginx-内网SLB-应用ECS调优后网络链路:客户端发起初始化请求-DDOS-WAF-
95、公网SLB-Nginx-内网SLB-应用ECS发起用户登录验证请求-内网SLB-应用ECS全部的问题列表及解决方案如下:云上大型赛事保障白皮书 47问题描述某接口SLB后端只有1台服务器CDN突发带宽超过限流规则CDN带宽预警达到NAT规格上限升级NAT规格,调整架构添加CDN白名单SLB后端单可用区风险应用问题优化应用建议双可用区,每个可用区两台某接口压测x QPS后出现503达到SLB规格上限SLB规格升配某接口压测x RPS后出现请求超时Redis缓存问题添加Redis缓存某接口RT抖动,怀疑与缓存过期有关Redis缓存时间调整Redis缓存配置某接口压测x RPS后EIP达到流量峰值E
96、IP带宽峰值预警扩容EIP带宽或者接口使用CDN某接口压测x RPS后出现502 13456789101112132Nginx压力过大扩容Nginx pod规格和数量序号问题原因优化方案某接口压力大的情况下后端应用pod会重启,检查发现是liveness/readiness健康检查失败导致pod重启某接口压测至x QPS后平均RT为800ms,后端应用响应时间较长某接口压测至x QPS,平均RT会有波动,最大RT偶发大于1S,后端应用连接时间超过1秒系统参数net.core.somaxconn配置过小调整应用监听队列和内核参数某接口压测x1QPS崩溃,出现fullgc某接口压测x QPS崩溃,
97、出现fullgc某接口压测x QPS出现502应用问题应用问题应用问题优化应用扩容Pod扩容Pod48 云上大型赛事保障白皮书云上大型赛事保障白皮书最终,通过压测和调优,我们保证了主要接口和界面可以顺利支持xQPS访问请求。在整个奥运赛事期间,云展厅项目一共实现了608万访客人次和7600万线上总访问量,圆满完成了任务。3.2 云上大型赛事技术演练3.2.1 技术演练基本概念压力测试是量化的通过模拟真实环境压力的方式找出系统瓶颈、暴露系统缺陷,从而评估系统整体性能。而技术演练则是以具体实践的形式评估系统整体稳定性。技术演练包含容灾演练、安全攻防演练、故障演练等。容灾演练:从容灾的角度对整体系统
98、进行实践性演练。只有成功的容灾演练才能最好地证明了容灾系统的设计及交付的正确性和可靠性。但同时,演练也是具有较大风险的过程,稍有失误可能导致业务或数据的损失。安全攻防演练:从安全的角度对系统进行攻防模拟演练。从而找出安全薄弱点,做对应的调整。故障演练:模拟真实线上故障,检测系统快恢能力,对保障流程做演练。3.2.2 容灾演练及冬奥实践容灾是一个系统化、体系化工程,通常会覆盖分析、规划、设计、实施及管理5大部分。这里只讨论实施阶段中的容灾演练部分。容灾建设是否成功、是否达到设计目标,需要多种手段进行衡量,而通过演练来验证容灾建设方案是最直接最有效的手段。全面、有序、高效的容灾演练可以提升信息系统
99、服务在突发中断后应急响应和灾难恢复的效率,以最大限度减少业务中断时间并降低风险,对提升赛时信息系统整体可用性非常重要。在容灾领域,有两个最重要的概念,即所谓RTP和RPO。云上大型赛事保障白皮书 49所谓 RTO,Recovery Time Objective,它是指灾难发生后,从 系统宕机导致业务停顿之时开始,到IT系统恢复至可以支持各部门运作、恢复运营之时,此两点之间的时间段称为 RTO。所谓 RPO,Recovery Point Objective,是指从系统和应用数据而言,要实现能够恢复至可以支持各部门业务运作,系统及生产数据应恢复到怎样的更新程度。这种更新程度可以是上一周的备份数据,
100、也可以是上一次交易的实时数据。在系统设计时就需要明确RTO和RPO,通常来讲,我们的目标是追求更短的RTO和RPO。当然,这和成本有关:设计两地三中心类型的容灾系统,可以保证RTO为0,但成本要double或者trible;设计极高的数据备份频率,可以保证RPO非常小,但成本也会比较高。成本、RTO、RPO总是一个不可能三角的模型。容灾演练规划大体可分成三个环节:规划演练方案:规划好要验证系统的哪些功能、设计演练的具体场景、落实操作具体流程为演练脚本。实施演练过程:按照顺序逐步实施演练脚本,并观察业务运转是否符合预期,观察系统稳定性指标。解决演练问题:针对演练过程中出现的问题进行定位并逐一解决
101、。缩写解释RTORPORecovery Time ObjectiveRecovery Point Objective恢复时间目标。故障发生后,期望从启动容灾恢复操作到应用恢复上线所需要的时间,RTO是衡量服务中断的时间长度。故障单位时间内对业务造成的损失越大,RTO 就要求越短数据恢复点目标。指应用发生故障时可以容忍的数据丢失量。指当服务恢复后,恢复到的数据所对应时的间点,主要取决于数据同步的延迟。数据越重要,RPO 就要求越小。RPO 越高,往往要求数据备份、复制频率更高,对生产环境、网络的压力也会越大,成本通常也越高全称50 云上大型赛事保障白皮书云上大型赛事保障白皮书在北京冬奥,我们一共
102、做了两次系统容灾演练(DDR,Discovery Disaster Re-hearsal)。考虑到云数据中心承载着公共服务,无法模拟真实的灾难场景,且与赛时保障密切相关的信息系统均采用了双活架构,因而演练主要从云产品实例层面进行触发,通过手工切换的方式,来考察上层应用的容灾能力,识别潜在风险。整个容灾演练涉及SLB、ECS、RDS、Redis和OSS的灾难切换和恢复操作,涵盖了应用、存储和数据层面的灾难模拟和恢复。两次容灾演练共计15个关键信息系统参与。项目团队针对各产品的特性,制定了详细的演练计划和执行脚本,在云基础设施和应用层面均识别出了不同类型的问题和风险,为赛时重保打下了坚实的基础。下
103、面介绍下第二次容灾演练DDR2,在DDR2,我们针对8个核心信息系统(交通、火炬手、餐饮、数据、抵离、Info1AV,健康监测,收费卡)进行演练,涉及SLB/ECS/RDS/Redis/OSS等核心云资源在政务云AC可用区之间切换,覆盖资源数量占整体资源的15%以上。在此期间,我们和各系统的开发商密切配合,按照演练脚本逐一测试了核心功能。规划演练方案:为保证本次演练顺利进行,我们从多个维度进行充分准备工作。组织维度:我们确定了阿里云支持侧/产研侧核心人员名单,演练期间全程会议。业务维度:明确参与演练的核心信息系统架构,向相关开发商作演练说明,向开发商提前准备好临时权限,避免因无权限发生的演练延
104、误。演练方案流程如下表所述。云上大型赛事保障白皮书 511516141312111098演练结束容灾恢复启动故障调查TOCTOCTOCPDC已经过小流量验证测试。窗口期执行正式回切。各信息系统值班经理调整PDC的SLB权重为1,SDC的SLB权重为99,进行小规模恢复测试。PDC上SLB、OSS、RDS和RedisS进行恢复。信息系统值班经理调整SDC上SLB权重为100,然后恢复PDC上ECS。TOC值班主任宣布启动容灾恢复。阿里云向IT值班经理报告故障原因(为PDC断电引发),并表明目前供电已恢复,PDC可以启用。报告容灾切换情况TOC向TOC值班主任报告整体容灾切换情况。应用验证5TOC
105、测试SDC应用、流量状况,并向IT值班经理汇报相关情况。故障模拟5TOC切换PDC上的OSS到SDC。应用验证4TOC测试SDC应用、流量状况,并向IT值班经理汇报相关情况。故障模拟4TOC关停PDC上的Redis。应用验证3TOC测试SDC应用、流量状况,并向IT值班经理汇报相关情况。7故障模拟3TOC关停PDC上的RDS。6应用验证2TOC测试SDC应用、流量状况,并向IT值班经理汇报相关情况。5故障模拟2TOC应用系统将PDC上的ECS关停。4应用验证1TOC测试SDC应用、流量状况,并向IT值班经理汇报相关情况。3故障模拟1TOC将PDC上的SLB切换到SDC。2宣布灾难TOCTOC主
106、任宣布启动容灾切换。1故障报警TOC报告PDC发生故障,需要启用SDC,并开具2级故障工单。步骤演练场景地点操作描述52 云上大型赛事保障白皮书云上大型赛事保障白皮书实施演练过程:演练从19:00开始,至21:50结束,得益于前期的充分准备和演练过程中各位同学的及时支持,各产品切换和回切均比较顺利,各系统切换和验证工作基本符合预期。整体演练比原定演练计划提前3小时结束。解决演练问题:演练过程中发现政务云上有部分产品管控异常(不影响演练本身),均已明确原因并排期修复。针对客户侧问题也总结整理并提供建议,请客户侧做了优化。客户侧问题如下:HMS SLB只挂载了单个PDC区域的ECS,没有挂在SDC
107、的ECS。HMS,FBS,TMS,Info1AV没有设置开机服务自启动,导致服务无法自动启动。FBS系统没有设置自动mount/dev/vdb1/Data,导致服务无法自动启动。发现HMS的三个SLB的健康检查状态异常,原因是由于异常的ECS内部还没有部署业务的服务。阿里侧问题如下:RDS的备份Button不可用,后联系RDS产研修复。部分ECS的可用区的控制台显示异常,不能区分具体可用区,后联系ECS产研修复。最终,通过两次的容灾演练,我们验证了阿里云组件切换功能正常,保证了系统的整体稳定性。3.2.3 安全攻防演练及冬奥实践安全攻防演练即为从组织内部,从安全建设的角度对信息系统进行模拟攻击
108、的行为,从而发现组织内安全薄弱点,并做出对应安全策略的调整,攻防演练是可以发现更深层次的安全隐患,因此对安全技术的能力相对较高。在一次完整的攻防演练项目实践中,主要有攻击方(蓝军)也叫做蓝队、防守方云上大型赛事保障白皮书 53(红军)也叫做红队等攻防人员构造,需要注意的是国内外红队蓝队的叫法相反。在攻防演练中防守方人员会有如下的划分:在一些大型的攻防演练或赛事中对于防守方人员还会有更细的划分:负责组织内部的网络设备、安全设备和各个专业信息系统的安全值守;包括日志分析、攻击行为、安全事件发现并记录现有问题,初步评估后向其它工作小组汇报所发现的安全事件,协助其它小组完成所汇报安全事件的闭环。对攻击
109、行为、安全事件进行判断,甄别攻击事件,为监测分析组的工作指明方向和工作重点。针对攻击行为、网络安全攻击事件的影响进行评估,并组织人员、制定方案,针对安全事件执行应急处置与根除操作(包括封禁攻击链路);检查与确认安全事件的处置效果,事后提交封禁IP列表或网络安全攻击事件应急响应处置报告。应急处置组攻击研判组监测分析组321序号工作组职责321序号工作组职责收集和分析与活动或组织内部相关的安全情报,分析最新的安全漏洞和威胁信息,为攻击方提供技战术,为防守方制定应对建议。针对攻击行为、安全事件进行溯源,回溯攻击路径、追踪攻击者的身份信息,并进行信息固化;在条件允许的情况下对攻击行为进行反制,分析攻击
110、者技战术、攻击思路,限制攻击者攻击行为或捕获攻击者攻击成果,提交攻击溯源反制成果报告。攻击溯源反制组威胁情报分析组21序号工作组职责54 云上大型赛事保障白皮书云上大型赛事保障白皮书在北京冬奥赛前,开展了多次针对信息系统的渗透测试工作,为了发现更深次安全问题,也进行了大量拟真的攻防对抗。攻击方和防守方均由国内顶级的安全团队组成,其中将防守方细分为如上组别。攻击方和防守方各司其职开展攻防对抗演练工作。在攻击侧,攻击方人员主要使用信息收集,收集防守侧的暴露面开展漏洞挖掘并尝试使用已知组件的安全漏洞发起攻击。例如尝试使用FastJson、SQL注入漏洞等;其中钓鱼邮件也是攻击队使用的主要攻击方式之一
111、。权限维持阶段,攻击者在内网持续钓鱼、水抗攻击扩散受害者,使用内存马等方法规避查杀与对抗溯源分析工作,企图通过此方式获取更长久且稳定的控制权限。内网横向移动阶段,攻击者也使用扫描工具队内网发起大量的扫描探测、密码爆破、Web漏洞(主要为Java反序列化类)漏洞企图寻找更多受害者,捕获更多受害机器以跨出当前VPC网络环境发起针对权重更高信息系统的攻击行为。在防守侧主要通过安全设备结合人工监测、通过不同组别的协调工作,对安全事件进行安全响应,包括监测、溯源分析、风险修复等工作,让每个安全事件在防守侧进行闭环。通过开展渗透测试、攻防演练在北京冬奥赛前发现了多处安全风险,在将这些安全风险收敛后,使北京
112、冬奥相关系统安全水位更上一层楼。同时通过攻防演练锻炼了各防守侧人员的协调能力,使防守侧人员在处理安全事件时操作更规范更细致,同时也使得应急响应的效率提升,为赛时的快速处理安全事件打下了良好的基础。3.2.4 故障演练及冬奥实践线上问题发生的概率很小,但我们不能等真实问题发生后来验证监控和应急能力,日常就应该完成验证。在故障演练中,我们模拟线上真实发生问题的场景,以检测我们的系统快恢能力和故障应急流程。对于任何一个大型赛事活动,故障演练都是必要的。云上大型赛事保障白皮书 55故障演练一般可以分为如下三个部分:设计故障:这是最重要的部分,设计的故障要能贴合真实的场景,才能产生演练价值。通常情况下可
113、以从实际发生过的历史故障库出发去设计。故障可以根据严重性划分为轻型、中型、重大等级别。典型的轻型故障举例:高可用SLB单可用区服务宕机、单台ECS宕机、CDN单节点异常等;典型的中型故障举例:单宿主机上批量ECS宕机、IDC机房单路掉电、特定产品控制台不可用、物理专线设备宕机等;典型的重大故障举例:IDC机房多路掉电机器全宕、可用区核心网络设备主备光缆全断、大规模DDoS攻击导致可用区级出口带宽打挂等。那么在设计故障时,也应区分不同的级别等级,以检查系统在不同级别下的恢复能力。故障注入:我们不可能在生产环境下实际触发故障,那么就需要对应的手段真实模拟线上故障。为此可以有两种方法,其一是在安全生
114、产环境直接触发故障,安全生产环境可以是99%的模拟流量和1%的线上流量,这样影响范围可控,而且可以根据需要调整线上流量比例,比如模拟重大故障时把线上流量关闭;其二是故障模拟系统,一般是和产品监控告警系统一同开发,可以注入并不存在的故障触发产品侧监控告警,以模拟真实场景。故障处理与复盘:在注入故障后需要观察系统快恢自愈能力,以及演练故障处理流程,针对产品或者流程暴露的问题做针对性的复盘。产品问题一般性为不触发流量切换、流量切换延迟、主备切换不合预期、宕机未自动迁移拉起等。故障处理流程我们将在保障阵型与流程管理这个章节详细描述。在北京冬奥,我们一共做了若干次故障演练,得益于阿里云完善的故障管理体系
115、,我们有可以直接注入模拟故障的故障模拟系统,和一整套故障处理流程规范。其中典型的几次如下:56 云上大型赛事保障白皮书云上大型赛事保障白皮书通过故障演练,我们检查了系统快恢能力,及整套故障处理流程规范的应急动作熟练度,为赛时的快速故障处理打下了良好的基础。突袭演练2突袭演练1故障注入唤起,机房升温异常,ECS/存储/网络/安全/数据库等多线联动自检机器健康状态,降温预案15分钟内恢复,未有产品存在宕机情况。2022/01/25故障注入唤起,网络相关的联合快恢、DCDN+GA相关的联合快恢、安全产品稳定性的快恢。2022/01/21故障演练22021/12/11主备AC可用区双宕推演,纯电话会议
116、推演流程,未做故障注入唤起。故障演练12021/10/26单可用区机房整体宕机推演(可用区级切换),纯桌面推演。序号时间说明云上大型赛事保障白皮书 57第四章 监控告警与应急预案上一章,我们全面介绍了压测调优和技术演练。但是,任何的压测调优、技术演练等风险治理手段都不能完全消除风险,那么我们就需要有对应的手段来感知风险、提示风险,并作出对应的风险处理。本章,我们将讨论如何通过监控告警体系来实现对各系统实时的运转情况和风险的感知与处理,以及对应的应急预案。4.1 云上大型赛事监控告警4.1.1 监控告警基本概念4.1.1.1 监控告警系统CTPS模型原则对于云上大型赛事活动来说,建设一个相对优秀
117、的监控告警系统是有章法可依的,下面是整理抽象的适用于建设一般监控告警系统的CTPS模型。全面(Comprehensive),监控覆盖要全面,从系统监控、应用监控、云平台监控、云产品监控到业务监控缺一不可。对于云上系统来讲,因为有物理网和云网络、IaaS和PaaS的区分,因此天然是有分层的概念的,底层为云平台,中层为云产品,上层为业务应用,一个全面的监控告警系统,应至少包含这三层。实时(Timely),告警实时性要高,一般来说从监控触发告警到工程师接收告警,整个流程时间消耗是秒级的。得益于阿里云成熟的云平台故障管理体系,及标准化商业化的监控产品云监控,我们总是可以在云平台层和云产品层面,做到实时
118、的告警,即时发现即时告警。而在应用层的监控则见仁见智,其告警的实时性则取决于监控系统的设计。准确(Precise),告警信息要准确,要有足够高的信噪比。58 云上大型赛事保障白皮书云上大型赛事保障白皮书智能(Smart),告警信息要智能,告警可以给到工程师更多的有效信息,可以自动化完成一些根因分析甚至运维操作。4.1.1.2 云上大型赛事监控告警系统设计4.1.1.2.1 分层监控云上大型赛事虽然东西向的结构比较复杂,但是其纵向的层次结构是比较清晰的。最底层为云平台物理层,这里是云产品的底座,包括IDC机房、机房中的计算和存储集群、物理网络网络设备(传统的接入、汇聚、核心三层)、云产品底层物理
119、设备(如XGW、CGW等)、及其他平台层设备等。云产品则是运行在云平台物理层之上的标准化IaaSPaaSSaaS产品,是我们售卖的商品,也是我们给客户提供的资源。再往上则是客户的应用层,基于我们的标准化云产品构建具体的业务。因此,云上大型赛事的监控告警系统天然就适配分层的设计理念,对整个系统每一层分别进行监控和告警,相互之间不必有强关联,可以解耦式设计各层的监控告警体系,再最终有机的整合到一起。对于云平台物理层的监控,我们关注的是物理设备的运转情况,例如机房电压、网络设备资源利用率、底层设备故障情况等等,这个层面是很难感知到应用业务层的运转情况的,比如计算集群中某一台宿主机宕机,其实一般情况下
120、我们并不清楚这个问题会造成最上层应用受到什么影响,这就需要通过云产品层和详细系统架构图做一个连接,以在告警出来时我们能第一时间掌握业务受损情况。对于云产品层的监控,通常是采用各厂商的商业化云监控产品对各标准云产品进行监控和告警。阿里云云监控(CloudMonitor)是一项针对阿里云资源和互联网应用进行监控的服务,已经是我们非常成熟的产品,也积累了丰富详细的监控方案,并仍然在不停迭代发展中。阿里云所有的标准化云产品的底层监控数据都已经接入云监控,底层全部打通,并且云监控开放了大量的监控告警能力给客户,可以说,任何一个部署在阿里云上的大型系统,其云产品层的监控基本肯定是需要由云监控(CloudM
121、oni-tor)来做主导。云上大型赛事保障白皮书 59对于应用业务层的监控,大部分情况下需要云厂商和赛事方共建,这有时候取决于客户侧的IT技术水平,或者阿里云的TAMSRE团队多大程度上介入到客户的业务中。常见的监控指标有应用层的接口可用率、接口时延、流量等,这些指标是最直观反应应用运转情况的指标。阿里云有一些商业化产品具有应用层监控的能力,例如云监控的站点监控,或者ARMS业务监控,通过应用探针集成到客户具体业务功能中收集数据,可以提供业务层的洞察。4.1.1.2.2 监控数据生命周期管理监控数据的全生命周期包括数据生产、数据采集与存储、数据消费三部分,下面分别简单介绍在大型赛事场景下针对监
122、控数据的管理。大型赛事场景下,由于系统架构天然分层的存在,监控数据会产生在不同的数据源,这些数据源多种多样,可能来自于物理层的设备日志,也可能来自于产品运行时埋点日志,也可能来自于应用探针探测,这些都是监控数据的原始metadata。这些原始数据是层系统运转时产生的生产实时运转情况,但通常是无业务含义的数据流。不同数据源的原始数据有不同的采集与存储方式,注意数据采集这里有一个不可能三角,即:采集速率、准确性、成本无法同时达到最优,如果所有的原始数据都采集存储,那么准确性能达到最高,但成本会比较高,如果要降成本,可以根据情况增大采样间隔,但这势必会影响到数据的准确性,所以数据采集这里总是会有一个
123、平衡与取舍。数据存储方面,对于阿里云云平台物理层或者云产品层来讲,常见的监控数据存储方式是由产品侧数据源通过接口调用把采集到的数据投递到云产品内部账号的日志服务(SLS)的一个logstore中,阿里云日志服务是我们的一款标准化商业化产品,一站式提供数据采集、加工、查询与分析、可视化、告警、消费与投递等功能,已成为阿里云各层云产品存储生产日志的缺省值。对于应用业务监控,可以使用标准的日志服务,也可以自建日志存储库。监控数据的数据消费,其实就是告警与处理。阿里云云监控提供了完善的告警功能,可以自定义阈值告警规则和事件告警规则,并实时推送至邮件、短信、电话、Webhook等多种渠道,云上的日志服务
124、+云监控告警功能,已成为大型赛事监控告警60 云上大型赛事保障白皮书云上大型赛事保障白皮书4.1.2.1.2 云平台层监控主要是各产品自己维护的底层监控,客户是不可见的。例如XGW流量监控、CDN节点监控等。这是阿里云各产品方自己稳定性建设的一部分。在本次冬奥保障过程中,很多产品方专门为冬奥相关资源定制开发了相关的监控。系统的事实标准。4.1.2 北京冬奥监控告警体系介绍4.1.2.1 四层监控在冬奥保障项目中,我们把监控系统自上到下分为四个层次,分别为:IDC监控、云平台层监控、云产品层监控、业务层监控,并且为每层定义了核心的监控项。4.1.2.1.1 IDC层监控主要是各针对客户资源所在的
125、IDC层面的监控告警,包含电力、温度、功耗、硬件故障等方面进行监控告警。这是最底层的监控,由阿里云IDC部门(基础设施事业部)负责。图:北京冬奥会IDC数字大盘云上大型赛事保障白皮书 614.1.2.1.3 云产品层监控利用产品云监控,Prometheus,DataV等产品能力,我们针对不同的业务系统涉及到的云资源进行细化和拆分。在云产品层,我们使用的最多的是阿里云云监控这个产品,因为所有其他云产品的底层数据源都会上报至云监控LogStore,这样底层的无缝衔接赋予了云监控强大的产品监控能力,可以方便的在云监控上设置监控阈值告警和事件告警,设置自定义事件等进行消费。基础资源监控:ECS1CPU
126、利用率、内存利用率、磁盘空间;POD1CPU利用率、内存利用率、磁盘空间;RDS1CPU使用率、内存使用率、IOPS使用率、磁盘空间;Redis CPU使用率、内存使用率;CSG前端读写速率、共享缓存使用率、用户态空间使用率、Trottling状态等。网络层监控,主要是各网络组件参数:带宽情况、活跃连接数、限速丢包率、专线健康检查丢包率等。图:北京冬奥主账号下的监控告警规则62 云上大型赛事保障白皮书云上大型赛事保障白皮书我们还通过云原生的ARMS对冬奥容器集群进行一体化监控,根据不同的命名空间可以基于NS、Pod维度详细查看CPU、内存使用率以及网络带宽等情况。图:针对北京冬奥核心系统ACK
127、集群的Prometheus监控云上大型赛事保障白皮书 634.1.2.1.4 业务层监控应用核心指标的监控,参考谷歌提出的四个黄金监控指标,一般可以分为四大类可用率,服务的请求成功率。时延,请求的耗时。错误数,主要包括管控侧以及资源侧。错误数,主要包括管控侧以及资源侧。流量,主要包括流量指标、流量移动、流量跌零监控。除了通过现有的的工具比如ARMS、Zabbix、Open-Falcon等等客户可以使用的公有云工具,针对这次重保我们也开发了一些与业务对应的一些业务异常监控,直接推送到我们的告警群。4.1.2.2 监控大屏在北京冬奥保障过程中,基于分层,我们开发了非常多的监控大屏,每一层都有非常详
128、细的系统监控指标可查。这里介绍其中两个比较重要的监控大屏:直接对客户展示的前场Grafana监控大屏,和在阿里云后场的重保作战室现场大屏幕上播放的后场作战室监控大屏。4.1.2.2.1 前场Grafana监控大屏在北京冬奥技术运行中心(TOC)现场,包括阿里云在内的多家冬奥供应商、北京冬奥组委技术部等现场联合办公。我们利用云监控集成Grafana能力展示信息系统的云产品实时使用情况。一共配置了40个Grafana大盘,显示在TOC的大屏幕及我们在TOC现场办公的工程师电脑上。现场盯屏的工程师主要监控这些Grafana大盘,以了解全部系统的实时运转情况。64 云上大型赛事保障白皮书云上大型赛事保
129、障白皮书4.1.2.2.2 后场作战室监控大屏利用阿里云飞天技术服务平台Apsara ServiceStack-CloudDoc大屏能力,按项目群和应用汇总资源及水位监控情况,多场点人员排班情况,及整体服务水平情况。作战室监控大屏显示在阿里云作战室内。Apsara ServiceStack-CloudDoc拥有强大采集系统,可实现阿里云、政务云、私有云等多云API配置化采集能力,实时采集数据服务奥运作战室大屏,对关键指标做实时监控和分析,实时掌握奥运云上系统的整体运行趋势,包括系统负载、流量趋势和安全风险等。同时,我们也一并把排班管理和多场点管理也集成到了Apsara1Ser-viceStac
130、k-CloudDoc中,定制化开发上下班打卡功能,并合理限定打卡地点实现冬奥重保护航值班管控,通过服务大屏做到对整体服务情况一目了然。具体的护航排班及流程可以参考章节保障阵型与流程管理。图:北京冬奥阿里云后场作战室监控大屏云上大型赛事保障白皮书 654.1.2.3 告警系统在冬奥保障项目中,我们针对云平台和云产品的告警系统主要是基于云监控的Web推动能力,把实时告警推送到专门的钉钉群(北京冬奥核心告警群)中。告警覆盖基础云产品,如ECS/RDS/SLB/OSS等,告警样例参见下图,并针对每项告警做了对应的告警预案。图:北京冬奥阿里云后场作战室服务大屏图:北京冬奥核心告警群告警示例66 云上大型
131、赛事保障白皮书云上大型赛事保障白皮书具体告警规则参见下表,一共32项。SLB_后端非健康ECS实例_5分钟Warning健康检查后端健康ECS实例个数=1Count Warn 连续5次就报警ECS_硬盘利用率_5分钟WarningECS_内存利用率_15分钟WarningECS_CPU利用率_15分钟WarningRedis_平均响应时间_1分钟Redis_带宽使用率_1分钟WarningRedis_带宽使用率_1分钟WarningRedis_QPS使用率_1分钟WarningRedis_内存使用率_1分钟WarningRedis_CPU使用率_1分钟Warning(Agent)disk.us
132、age.utilization_device=95%Warn 连续15次就报警(Agent)memory.used.utilization=90%Warn 连续15次就报警(Agent)cpu.total=90%Warn 连续15次就报警平均响应时间=1000000us Warn 连续3次就报警流出带宽使用率=90%Warn 连续3次就报警流入带宽使用率=90%Warn 连续3次就报警QPS使用率=90%Warn 连续3次就报警内存使用率=90%Warn 连续3次就报警CPU使用率=90%Warn 连续3次就报警NAS_读延迟读延迟=500ms Warn 连续5次就报警RDS_只读实例延迟只读
133、实例延迟=60秒 Warn 连续3次就报警RDS_连接使用率_15分钟Warning连接数使用率=90%Warn 连续3次就报警RDS_IOPS使用率_15分钟WarningIOPS使用率=90%Warn 连续3次就报警RDS_内存使用率内存使用率=95%Warn 连续3次就报警RDS_CPU使用率CPU使用率=90%Warn 连续3次就报警RDS_磁盘使用率磁盘使用率=90%Warn 连续1次就报警告警项告警规则(一次=1min)云上大型赛事保障白皮书 67每分钟产生死信消息的数量(GroupId)MQ_消息堆积_5分钟WarningVPC_IDC丢弃流出数据包数VPC到IDC方向丢弃流入数
134、据包数=5pps Warn 连续5次就报警IDC_VPC丢弃流入数据包数VBR健康检查丢包率_20分钟VBR健康检查丢包率_5分钟EIP 网络流出带宽利用率 80%15minEIP 网络流入带宽利用率 80%15min死信消息数量=1count 连续1次就告警消息堆积=100count Warn 连续5次就报警IDC到VPC方向丢弃流入数据包数=5pps Warn 连续5次就报警VBR健康检查丢包率=20ratio Warn 连续5次就报警VBR健康检查丢包率=5ratio Warn 连续5次就报警网络流出带宽利用率=80%Warn 连续15次就报警网络流入带宽利用率=80%Warn 连续15
135、次就报警OSS_请求错误_5分钟Warning成功请求占比=80%Warn 连续3次就报警MongoDB_IOPS使用率_1分钟Warning(副本集)IOPS使用率=80%Warn 连续3次就报警MongoDB_硬盘使用率_5分钟Warning(副本集)磁盘使用率=80%Warn 连续3次就报警MongoDB_内存使用率_5分钟Warning(副本集)内存使用百分比=80%Warn 连续3次就报警MongoDB_CPU使用率_1分钟Warning(副本集)CPU使用率=80%Warn 连续3次就报警SLB_后端服务中断_5分钟Warning健康检查后端健康ECS实例个数=0Count War
136、n 连续5次就报警告警项告警规则(一次=1min)68 云上大型赛事保障白皮书云上大型赛事保障白皮书4.2 云上大型赛事应急预案4.2.1 应急预案原则当监控异常或者收到告警后,需要有充足的预案进行处理及快速恢复。详细的应急预案是保证服务SLA的重要手段,也是大型赛事活动的必备。与分层监控对应的就是分层预案,注意虽然在不同的层级我们的应急手段、应急指标不同,但核心的原则不变,即应急预案应集中在如何快速止血恢复业务。对于IDC层,对应的应急预案有机房升温时应如何迅速降温、市电供电中断时如何快速上电、运营商BGP出口故障时如何做流量容灾、突发拥塞如何做绕行等等;对于云平台层,对应的应急预案主要由各
137、产品团队设计实施,例如XGW流量打满如何限流、NC批量宕机如何快速拉起或者迁移、CDN节点流量超限如何处置等等;对于云产品层和应用业务层,则主要由保障团队和客户自身做相应的考量设计。下面详细介绍北京冬奥保障项目中关于产品层和业务层的应急预案,我们针对不同的业务场景,梳理了预警等级、快恢方案、优化建议等等32项告警预案以及73项各类产品技术场景的预案。4.2.2 北京冬奥告警预案针对告警系统中配置的32项告警,我们一一制定了对应的应急预案,当告警发生时,可以做到手中有粮心中不慌。最终我们在冬奥期间完成了若干次告警的处置,有力的保证了赛事的顺利进行。以下是针对32项告警的详细应急预案云上大型赛事保
138、障白皮书 691.保障团队检查只读实例延迟情况。2.如果延迟持续上升,确认下备用只读是否无延迟,无延迟后和客户确认是否需要切换到备用只读,切换时注意有连接闪断;对于大事务产生的延迟,建议客户对大事务放到业务低峰期,或者对可以拆分的大事务做下拆分。1.保障团队检查NAS读延迟情况。2.如果读延迟持续升高,检查NAS后台服务运行状态。NAS_读延迟24h中读延迟=500ms Warn 连续5次就报警RDS_只读实例延迟24h中只读实例延迟=60秒 Warn 连续3次就报警1.保障团队检查连接数使用情况。2.连接数使用率如果持续上涨,可以后台临时放大连接数限制,然后反馈客户确认是否有必要保持大量连接
139、,建议合理设置连接池参数回收空闲连接。RDS_连接使用率_15分钟Warning24h中连接数使用率=90%Warn 连续3次就报警1.保障团队检查IOPS使用量情况,确认什么行为导致IOPS打高。2.如果IOPS持续打高,先后台临时调大IOPS限制。3.如果慢SQL导致的,反馈相应慢SQL给客户引导尽快优化相关慢SQL;如果并发高导致的,引导客户升级配置。RDS_IOPS使用率_15分钟Warning24h中IOPS使用率=90%Warn 连续3次就报警1.保障团队检查内存使用情况。2.内存使用高随时有可能导致OOM,引导客户尽快升级。3.如果有大量慢SQL扫描大量数据,反馈对应慢SQL给客
140、户。RDS_内存使用率24h中内存使用率=95%Warn 连续3次就报警1.保障团队检查CPU使用量情况,确认什么行为导致CPU打高。2.如果CPU持续打高,先后台临时调大CPU核心数。3.如果慢SQL导致的,反馈相应慢SQL给客户引导尽快优化相关慢SQL;如果并发高导致的,引导客户升级配置。1.保障团队检查磁盘使用量情况。2.如果磁盘空间占用高一直持续,可以后台临时调大实例的存储空间,避免实例锁定;然后通知客户尽快升级配置。RDS_CPU使用率24h中CPU使用率=90%Warn 连续3次就报警RDS_磁盘使用率24h中磁盘使用率=90%Warn 连续1次就报警应急预案告警项沉默时间严重程度
141、告警规则(一次=1min)70 云上大型赛事保障白皮书云上大型赛事保障白皮书1.保障团队检查平均响应时间为什么高。2.如果规格原因导致的,建议客户升级配置,如果大key导致的,建议客户对大key做好拆分。1.保障团队在嫦娥平台检查ECS是否有异常。2.云监控查看是否有应用进程占用内存高。3.如果应用进程占用内存高,联系开发商处理。4.如果系统进程高,进行热冷迁移看是否能够止血。5.如果不能止血让客户查看top命令以及/proc/meminfo,让客户提供对应的日志以及/var/log/message日志,Windows系统查看任务管理器以及evetvwr中的系统日志和应用程序日志。ECS_内存
142、利用率_15分钟Warning24h中(Agent)memory.used.utilization=90%Warn 连续15次就报警1.保障团队在嫦娥平台检查ECS是否有异常。2.云监控查看是否有应用进程占用CPU高。3.如果应用进程占用CPU高,联系开发商处理。4.如果系统进程高,进行热冷迁移看是否能够止血。5.如果不能止血让客户查看top命令和提供对应的日志以及/var/log/message日志,Windows系统查看任务管理器以及evetvwr中的系统日志和应用程序日志。ECS_CPU利用率_15分钟Warning24h中(Agent)cpu.total=90%Warn 连续15次就报
143、警Redis_平均响应时间_1分钟24h中平均响应时间=1000000usWarn 连续3次就报警1.保障团队检查流出带宽使用情况。2.流出带宽打满会导致程序读写超时,可以引导客户临时放大带宽应对业务高峰。Redis_带宽使用率_1分钟Warning24h中流出带宽使用率=90%Warn 连续3次就报警1.保障团队检查流入带宽使用情况。2.流入带宽打满会导致程序读写超时,可以引导客户临时放大带宽应对业务高峰。Redis_带宽使用率_1分钟Warning24h中流入带宽使用率=90%Warn 连续3次就报警1.保障团队检查QPS使用情况。2.确认QPS当前并发下,CPU负载情况是否较高,持续高位
144、情况下建议客户尽快升级配置。Redis_QPS使用率_1分钟Warning24h中QPS使用率=90%Warn 连续3次就报警1.保障团队检查内存使用情况。2.内存使用打满会引起内存驱逐,可后台临时放大内存,然后引导客户尽快升级。Redis_内存使用率_1分钟Warning24h中内存使用率=90%Warn 连续3次就报警1.保障团队检查CPU使用量情况,确认什么行为导致CPU打高。2.如果慢SQL导致的,反馈相应慢SQL给客户引导尽快优化相关慢SQL;如果并发高导致的,不是热点key行为建议客户采用集群架构,已经集群架构的建议增加节点个数。Redis_CPU使用率_1分钟Warning24h
145、中CPU使用率=90%Warn 连续3次就报警云上大型赛事保障白皮书 711.保障团队检查IOPS使用量情况,确认什么行为导致IOPS打高。2.如果IOPS持续打高,先后台临时调大IOPS限制。3.如果慢SQL导致的,反馈相应慢SQL给客户引导尽快优化相关慢SQL;如果并发高导致的,引导客户升级配置。1.保障团队检查磁盘使用量情况。2.如果磁盘空间占用高一直持续,可后台临时调大实例的存储空间,避免实例锁定;然后通知客户尽快升级配置。MongoDB_IOPS使用率_1分钟Warning24h中(副本集)IOPS使用率=80%Warn 连续3次就报警MongoDB_硬盘使用率_5分钟Warning
146、24h中(副本集)磁盘使用率=80%Warn 连续3次就报警1.保障团队检查内存使用情况。2.内存使用高随时有可能导致OOM,引导客户尽快升级。3.如果有大量慢SQL扫描大量数据,反馈对应慢SQL给客户。MongoDB_内存使用率_5分钟Warning24h中(副本集)内存使用百分比=80%Warn 连续3次就报警1.保障团队检查CPU使用量情况,确认什么行为导致CPU打高。2.如果CPU持续打高,后台先临时调大CPU核心数。3.如果慢SQL导致的,反馈相应慢SQL给客户引导尽快优化相关慢SQL;如果并发高导致的,引导客户升级配置。MongoDB_CPU使用率_1分钟Warning24h中(副
147、本集)CPU使用率=80%Warn 连续3次就报警SLB_后端服务中断_5分钟Warning24h中健康检查后端健康ECS实例个数=0Count Warn 连续5次就报警1.检查后端ECS上系统和应用是否有异常。2.将后端异常ECS 权重配置为0。3.评估扩容后端ECS数量。1.检查后端ECS上系统和应用是否有异常。2.在后端ECS上抓包确认是否为系统问题。3.扩容后端新ECS承载业务,或者切换SLB到备用集群。SLB_后端非健康ECS实例_5分钟Warning24h中健康检查后端健康ECS实例个数=1Count Warn 连续5次就报警1.保障团队检查连接数使用情况。2.连接数使用率如果持续
148、上涨,可以先在后台临时放大连接线限制,然后反馈客户确认是否有必要保持大量连接,建议合理设置连接池参数回收空闲连接。MongoDB_连接数使用率_1分钟Warning24h中(副本集)连接数使用率=80%Warn 连续3次就报警1.查看最新修改日志的文件和文件夹,看是什么文件占用磁盘空间大。2.查看对应磁盘是否有大的日志文件,如果有和客户确认是否可以删除。3.如果无法快速定位问题建议直接扩容后再查问题。ECS_硬盘利用率_5分钟Warning24h中(Agent)disk.usage.utilization_device=95%Warn 连续15次就报警72 云上大型赛事保障白皮书云上大型赛事保
149、障白皮书每分钟产生死信消息的数量(GroupId)12h中死信消息数量=1count 连续1次就告警1.保障团队检查MQ服务侧是否有服务侧问题。2.如果客户使用TCP接入点,客户提供ons.log,报障团队查看是否下游链路有阻塞影响消息消费进度。MQ_消息堆积_5分钟Warning24h中消息堆积=100count Warn 连续5次就报警1.保障团队检查MQ服务侧是否有服务侧问题。2.如果客户使用TCP接入点,客户提供ons.log,保障团队查看是否下游链路有阻塞影响消息消费进度。VPC_IDC丢弃流出数据包数24h中VPC到IDC方向丢弃流入数据包数=5pps Warn 连续5次就报警1.
150、扩容高速通道带宽IDC_VPC丢弃流入数据包数24h中IDC到VPC方向丢弃流入数据包数=5pps Warn 连续5次就报警1.扩容高速通道带宽VBR健康检查丢包率_20分钟24h中VBR健康检查丢包率=20ratio Warn 连续5次就报警1.检查CSW是否有异常。2.如果CSW无异常需要客户反馈运营商排查专线线路。VBR健康检查丢包_5分钟24h中VBR健康检查丢包率=5ratio Warn 连续5次就报警1.检查CSW是否有异常。2.如果CSW无异常需要客户反馈运营商排查专线线路。EIP 网络流出带宽利用率 80%15min24h中网络流出带宽利用率=80%Warn 连续15次就报警1
151、.控制台扩容EIP带宽规格。2.如果EIP带宽达到规格上限,EIP绑定共享带宽包。EIP 网络流入带宽利用率 80%15min24h中网络流入带宽利用率=80%Warn 连续15次就报警OSS_请求错误_5分钟Warning24h中成功请求占比=20%Warn 连续5次就报警1.检查OSS 状态码监控是否存在很多非200响应。2.根据OSS离线SLS查看非200状态码对应的错误描述,如果是文件不存在错误,引导客户自查访问的URI;如果是权限报错,引导客户检查访问的AK或者bucket权限,如果是5xx报错,联系OSS产研值班检查服务端状态。1.控制台扩容EIP带宽规格。2.如果EIP带宽达到规
152、格上限,EIP绑定共享带宽包。云上大型赛事保障白皮书 734.2.3 北京冬奥技术场景预案一些常见的问题场景,例如丢包、流量跌零、黑洞等场景,这些场景可能会有告警出来,也可能不会有。我们对这些常见的问题场景也设计了对应的应急预案,即技术场景预案。技术方向问题场景处理方案弹性计算大规模ECS出现CPU负载异常-提前预案1.根据阿里云提供全链路评估报告梳理ECS安全组规则,收敛存在安全风险的策略,如收敛0.0.0.0/0规则2.核心业务服务器请安装安骑士,及时修补服务器安全风险及漏洞。-恢复预案1.登陆异常ECS通过TOP命令查看是否存在陌生进程占用大量CPU,判断有可能被暴力破解并部署挖矿程序,
153、需要及时切彻底删除木马程序。2.如业务进程占用CPU最高,可尝试重启应用优先恢复业务。3.通过快照进行恢复到之前的状态弹性计算单ECS出现CPU/网络/IO负载异常1.可控制台尝试强制重启服务器优先恢复业务。2.如果重启依然存在负载高的问题,可以扩容和升配快速恢复业务。弹性计算 ECS 所在物理机意外宕机1.梳理护航核心业务,去单点架构,确保所有业务都是集群或者分布式部署。2.通过宕机迁移恢复,影响业务时间为服务器重启时间。网络EIP带宽打满1.请优先升级带宽处理,升级时间较快,不影响线上业务。2.如果是按量实例需要升级到200M或者固定带宽500M以上,立即联系产品团队处理。网络VPN网关带
154、宽打满1.请优先升级带宽处理,升级时间较快,不影响线上业务。2.如果升级异常,立即联系产品团队处理。网络NAT网关带宽打满1.请优先升级带宽处理,升级时间较快,不影响线上业务。2.如果升级异常,立即联系产品团队处理。网络NAT网关连接数打满1.请优先升级规格处理,升级时间较快,不影响线上业务。2.如果升级异常,立即联系产品团队处理。74 云上大型赛事保障白皮书云上大型赛事保障白皮书安全安全DCDN服务或相关安全服务故障安全WAF服务故障1.通知组委技术部信息处/安全处、系统开发商,解析域名至回源IP(SLB、EIP),如直接的绑定WAF IP需重新绑定至回源IP。1.通知组委技术部信息处/安全
155、处、系统开发商,解析域名至回源IP(DDOS高防、WAF CANME、SLB IP)。安全DDoS高防故障1.通知组委技术部信息处/安全处、系统开发商,解析域名至回源(WAF CNAME、SLB IP),如直接的绑定高防IP需重新绑定至回源IP。安全加密服务连接数达上限堡垒机连接数达上限1.查询当前应用系统连接的HSM的总连接数是否超过阀值(256),若没有超过,阿里提供系统开发或运维人员将服务器配置的连接数值设大,直到解决问题。若超过阀值,需要临时购买新HSM实例,让系统开发或运维人员将服务器新增新实例的配置并设置连接数直到解决问题。1.扩容新堡垒机实例规格。安全云安全中心客户端离线1.立即
156、重启/重装客户端软件。2.排查下线原因,排除入侵或人为操作失误。安全WAF监控流量、QPS达上限1.将观察到的峰值流量作为参考,并要求技术部扩容。安全DDoS高防带宽、QPS、连接数达上限1.将观察到的峰值流量作为参考,并要求技术部扩容。网络专线流量跌01.检查专线物理设备状态2.检查对端设备状态网络专线丢包1.检查专线物理设备状态2.检查对端设备状态网络SLB后端健康检查实例异常1.检查SLB健康检查配置2.根据健康检查配置检查后端服务器业务运行状态网络SLB带宽打满1.请优先升级带宽,升级时间较快,不影响线上业务。2.如果升级异常,立即联系产品团队处理。网络SLB实例可用区切换失败1.对S
157、LB进行一键诊断;确认为阿里云问题后联系SLB产品团队。2.登陆SLB后端进行手工切换。云上大型赛事保障白皮书 75安全DCDN 高防漏拦截事件告警及漏拦截1.通知组委技术部信息处/安全处,相关云平台和安全应急人员。对行为进行防护效果分析,确定是否存在漏拦截,判断是否采取进一步严格的防御措施(如:封禁攻击来源IP,启用防御模块等)。安全DDoS高防误拦截事件告警及漏拦截1.如果是单个IP,优先将被拦截IP加白,如大量IP被web规格或CC误拦截可调整或关闭web防护,调整自定义ACL规则或关闭默认CC功能。2.事后分析误拦截原因,并给出根治方案。安全业务IP被DCDN的WAF防护功能误拦截安全
158、业务IP被WAF误拦截1.如果是单个IP,优先将被拦截IP加白,如大量IP被web规格或CC误拦截可调整或关闭web防护,调整自定义ACL规则或关闭默认CC功能。2.事后分析误拦截原因,并给出根治方案。1.优先将被拦截IP加白或关闭防护。2.事后分析误拦截原因,并给出根治方案。3.如大量IP被CC误拦截可调整CC模式或关闭默认CC。安全业务IP被DCDN的DDoS防护功能误拦截1.优先将被拦截IP加白或关闭防护。2.事后分析误拦截原因,并给出根治方案。3.改为如大量被误拦截可以关闭AI智能防护。安全业务IP被高防误拦截1.如果是单个IP,优先将被拦截IP加白,如大量IP被CC误拦截可调整AI智
159、能防护CC防护模式、调整自定义ACL规则或关闭默认CC功能。2.事后分析误拦截原因,并给出根治方案。DCDN的WAF拦截事件告警及漏拦截1.通知组委技术部信息处/安全处,相关云平台和安全应急人员。对行为进行防护效果分析,确定是否存在漏拦截,判断是否采取进一步严格防御措施(如:封禁攻击来源IP,启用防御模块等)。安全安全安全1.通知组委技术部信息处/安全处,相关云平台和安全应急人员。对行为进行防护效果分析,确定是否存在漏拦截,判断是否采取进一步严格防御措施(如:封禁攻击来源IP,启用防御模块等)。WAF拦截事件告警及漏拦截76 云上大型赛事保障白皮书云上大型赛事保障白皮书安全主机文件系统被加密勒
160、索1.提前快照。2.断网下线,使用快照恢复。3.已经开通了防勒索功能,使用该功能恢复文件。安全主机被获取所有权限1.断网下线。2.修改所有账号密码或删除异常账号。安全云安全中心(网站后门连接防御、防病毒功能)主机文件误删除1.提前快照。2.使用快照恢复。安全安全安全CTAS,云安全中心(主动防御-防病毒、防勒索、网站后门连接防御、恶意网络行为防御功能),内网蜜罐触发告警拦截主机账号口令存在泄露风险或已经泄露1.通知组委技术部信息处/安全处,相关云平台和安全应急人员。对告警信息进行分析,判断是否存在误拦截,若确定误报,通知,启用针对入侵行为的应急响应预案。1.断网下线。2.修改所有账号密码或删除
161、异常账号。安全外网蜜罐触发告警安全1.通知组委技术部信息处/安全处工程师清洗是否对业务造成影响,如果无影响,继续观察清洗效果。2.如果有影响,阿里云工程师立即启动解除清洗流程,帮助客户恢复业务。3.阿里云工程师协助客户分析判断是否存在误清洗,如确认是误清洗原因,调整清洗策略。1.通知组委技术部信息处/安全处,相关云平台和安全应急人员。2.阿里云侧收到告警信息后,立即启动解除黑洞流程,帮助客户恢复业务。3.时候阿里云工程师协助客户分析判断是否DDoS攻击,确定是否需要增大EIP防护黑洞阈值或接入高防,调整弹性防护阈值。4.攻击持续无缓解的情况下可以更换暴露的EIP。1.通知组委技术部信息处/安全
162、处,相关云平台和安全应急人员。对攻击进行分析。IP(EIPAnti DDoSWAF IP)进入清洗状态IP(EIPAnti DDoSWAF IP)进入清洗状态云上大型赛事保障白皮书 77数据库磁盘空间满(只读不可写)1.通知阿里云产品同学,关闭实例磁盘空间检查,立即恢复业务。2.清理RDS日志文件或扩容RDS磁盘空间或者升级磁盘空间。数据库IOPS打满1.立即通知产品同学,临时提高RDS IOPS规格。2.升级RDS实例规格。3.优化RDS慢查询。数据库连接数打满安全数据泄漏1.通知组委技术部信息处/安全处,相关云平台和安全应急人员。查找泄漏原因,封堵泄漏出口。1.登录DMS控制台KILL长时
163、间处于Sleep状态的数据库连接。2.立即通知产品同学,临时提高RDS连接数。3.升级RDS实例规格。4.恢复后,需恢复RDS实例的连接数设置。安全RAM/AK泄漏1.通知RAM/AK所有者。对于RAM,立即封禁并要求所有者修改密码,对于AK,实施凭据更换AK。通知组委技术部信息处/安全处,相关云平台和安全应急人员。查找泄漏原因,封堵泄漏出口。安全网页页面被篡改1.通知应用系统开发商,立即删除被篡改的页面。2.断网下线,立即启动应急响应预案,对攻击手法溯源,修补入侵或篡改页面漏洞。DNS解析异常1.临时将RDS连接地址从DNS切换为VIP。2.阿里云确认故障恢复后,客户需将应用程序立即切换为D
164、NS访问方式。安全数据库数据库-提前预案1.需要应用端具备自动重连机制。-恢复预案2.正常不用人为干预,RDS切换后会有30s内的闪断,应用自动重连即可。3.如切换后业务出现大量异常日志告警,大概率是应用重连机制不够友好,需要滚动重启应用优先恢复业务。RDS实例出现HA切换78 云上大型赛事保障白皮书云上大型赛事保障白皮书数据库只读实例性能瓶颈(CPU|IO压力过大)1.立即通知阿里云产品同学评估临时调整资源。2.升级只读实例规格。3.优化只读实例上对性能消耗严重的SQL语句。4.立即扩展只读实例节点数,最多可将只读实例数量扩展至10个。5.调整性能问题严重的RDS只读实例的访问权重。数据库读
165、写实例性能瓶颈(CPU|IO压力过大)1.立即通知产品同学评估临时调整资源。2.升级实例规格。3.优化性能消耗严重的SQL语句。4.未开通读写分离功能的RDS,购买只读实例,申请RDS读写分离连接地址,应用程序配置读写分离。5.已开通读写分离功能的RDS,增加只读实例节点数,进行扩展,通过权重将流量引导到只读实例。数据库数据库数据库可用区故障Region级故障1.建议使用跨可用区容灾实例。2.建议不同可用区分别申请一个RDS读写实例,使用DTS进行实时数据同步,故障后应用切换连接地址到备用可用区RDS实例。1.建议不同region分别申请一个RDS读写实例,使用DTS进行实时数据同步,故障后应
166、用切换连接地址到备用可用区RDS实例。安全内网网络故障数据库数据库1.依赖于RDS产品的快速恢复,立即通知阿里云产品同学,进行手工切换。1.立即检查宕机的只读实例读权重是否设置为0。2.程序如果长连接方式访问只读实例,建议重启应用,重新建立连接。1.检查备库是否开启并行复制功能(库级、表级、事务级)。2.立即检查并将延时过大只读实例读权重设置为0。3.升级只读实例规格。1.申请RDS外网地址和ECS外网出口,临时使用外网方式访问RDS数据库。DBnode故障,HA切换失败只读实例DBnode宕机只读实例延时过大云上大型赛事保障白皮书 79数据库Redis带宽被打满-提前预案1.前期需要对Red
167、is大key进行清理,优化内存架构。-恢复预案1.登陆redis控制台临时调整带宽。https:/ 热点key问题1.使用阿里云自研的imonitor命令监控Redis集群中某一节点的请求状态,并利用请求解析工具redis-faina快速地从监控数据中分析出热点Key和命令。https:/ _cluster/settingstransient:cluster.routing.allocation.exclude._ip:node_ip。ElasticSearch当集群状态值是2.00时ElasticSearch磁盘使用率超过85%ElasticSearch某节点cpu和load 1m均远高于其
168、他所有节点80 云上大型赛事保障白皮书云上大型赛事保障白皮书容器NTP service is not running1.使用命令systemctl start chronyd尝试重新启动。并通过命令 journalctl-u chronyd 查看服务的日志。数据库1.发送模拟真实用户访问的探测请求,监控大屏的访问情况,当页面不可访问时触发电话、短信告警。在 DataV 应急响应群中上报问题,由重保人员及时处理。DataV大屏可用性检测异常容器1.在容器服务节点维护控制台选择排空节点(同时设置为不可调度),节点状态变为不可调度,同时会将节点上已经存在的Pod进行(排空)驱逐,Pod会被调度到其他
169、节点进行重建。注意:节点上由守护进程集DaemonSet控制的Pod不会被排空。2.尝试重启节点kubelet;再尝试重启Docker进程恢复节点状态。3.如果步骤2中重启kubelet没有效果,节点依然不可用,那么需要强制重启ECS节点。通常该操作后可以恢复。不可用的原因包括负载过高等因素。4.节点状态恢复后不可调度的节点重新上线,您可以单击节点上线,在弹出的对话框中,单击确定,此时该节点状态又变成可调度。节点不可用,集群认为节点not ready。容器CCM异常1.重拉相关集群的ccm pod。容器节点磁盘资源不足检查节点的磁盘分配情况,通常有一下一些常见情况导致磁盘占用率过高。1.有大量
170、日志在磁盘上没有清理;请清理日志。2.有进程在宿主机不停的写文件;请控制文件大小,将文件存储至OSS或者NAS。3.下载的或者是其他的静态资源文件占用空间过大;静态资源请存储至OSS或CDN。注:为了避免影响本节点上已经部署的容器,节点升级维护前一定要对ECS进行排空操作,排空的话,需要保证其他ECS节点上有富余资源,否则排空后容器也无法调度到其他机器。容器节点PLEG异常1.可以尝试重启kubelet;再尝试重启Docker进程。重启这两个进程过程中,不会对已运行容器造成影响。2.如果1无法解决,很有可能是systemd版本问题导致,重启节点可短暂修复,彻底解决的话需要升级节点的system
171、d。注:为了避免影响本节点上已经部署的容器,重启前一定对ECS进行排空操作,排空的话,需要保证其他ECS节点上有富余资源,否则排空后容器也无法调度到其他机器。云上大型赛事保障白皮书 81中间件消息队列 RocketMQ消息积压告警1.登录消息队列 RocketMQ 版控制台,导航栏中选择资源报表,选择消息消费,输入对应信息,查询历史消费记录。如果消息写入速度大于消息消费速度,则调整业务代码或者对消费者进行扩容。2.登录代码所在服务器,如果存在消息阻塞现象,则多次执行下列命令,连续打印Jstack信息,确认消费线程位置,解决后可尝试重启代码应用,观察消息消费是否恢复正常。jstack-l$PID
172、|grepConsumeMessageThread说明:$PID为运行代码产生的进程ID。3.如果消息堆积量较小,检查阈值是否设置过小导致消息堆积。单击监控报警,单击目标监控项右侧编辑,增加消息堆积的报警阈值。请按照下列步骤确认问题得到解决:登录代码所在服务器,执行下列命令,确认无消费线程阻塞现象。jstack-l$PID|grep ConsumeMessageThread登录消息队列 RocketMQ 版控制台,导航栏中选择Group 管理,单击目标Group右侧的消费者状态。在连接信息下方发现堆积量栏的值下降到正常值。存储OSS成功率低于80%1.检查OSS 状态码监控是否存在很多非200
173、响应。2.根据OSS离线SLS查看非200状态码对应的错误描述:如果是文件不存在错误,引导客户自查访问的URI;如果是权限报错,引导客户检查访问的AK或者bucket权限;如果是5xx报错,联系OSS产研值检查服务端状态。容器APIServer异常1.重拉相关集群的apiserver pod。消息队列 RocketMQ消息轨迹功能降级消息轨迹用于记录消息生命周期信息,辅助排查问题,根据大流量情况下可能会对消息轨迹进行降级。1.如果采取了此预案,共享集群的实例消息轨迹可能会受影响,消息轨迹可能查询不到。2.铂金版集群不受影响,除非事先已和客户沟通会采取降级预案。中间件财税法/备案财税法/备案1.
174、到风控中心确认处罚情况,待用户整改后联系处罚接口人审核通过解除阻断。1.引导用户在线充值(若对公汇款到账周期比较长,建议临时在线充值优先保证第一时间款项到账)。联系阿里云财务开通信控:商务提交申请,财务审批。商务侧提升信控额度。违法处罚欠费82 云上大型赛事保障白皮书云上大型赛事保障白皮书财税法/备案1.备案阻断:联系备案服务产研,提供临时解决方案(备案白名单,风险核查白名单流程)。备案异常最终,在整个冬奥期间,保障团队一共进行了若干次次应急处置,包括若干次应急告警的处置和若干次次无告警的技术场景应急处置,保证了冬奥各系统的流畅运转。云上大型赛事保障白皮书 83第五章 安全设计与安全防护对于大
175、型赛事而言,如何保证整个系统的安全性,一直是系统保障中的重中之重本章,我们将专门讨论这个问题。这包括两个大的方面,安全设计与安全防护。5.1 云上大型赛事安全设计5.1.1 安全建设随着计算机技术的飞速发展,数字化资产也呈指数性增长,攻击面在不断扩大。面对层出不穷的安全漏洞,如何保障企业内部的网络安全,成为安全建设中需要考虑的重点问题。本文不再赘述如何开展安全建设,而是罗列安全建设原则在安全设计之初存在的一些共性。通俗易懂序号描述安全原则最小权限隔离越复杂的设计,就越容易在安全审查/测试阶段出问题。可追溯4321根据角色、任务和期限仅分配使用范围内的必要权限。一切操作和访问行为均应有所记录,当
176、出现安全事件或故障时可以快速定位问题事件源,如日志记录能力。将网络整体、系统平台尽可能的拆分成多个网络域或独立单元,当系统面对安全威胁时将损害量降到最低。其中网络隔离原则也是纵深防御体系的基础。84 云上大型赛事保障白皮书云上大型赛事保障白皮书5.1.2 阿里云安全产品安全架构的设计和可持续性安全保障,离不开安全产品的合理使用与安全技术的常态化服务。安全产品可以为用户提供基础安全、数据安全、应用安全、业务安全、账户安全、安全监控以及安全运营等功能。本章覆盖较典型的安全产品,如需了解更多安全产品和服务请参照阿里云官网。5.1.2.1 云上基础安全5.1.2.1.1 DDoS 防护DDoS防护(A
177、nti-DDoS1Service)是针对在互联网上提供服务的企业在遭受DDoS攻击后导致服务不可用的情况下,使用阿里云全球DDoS清洗网络,秒级检测系统,AI大数据引擎,高效地缓解DDoS攻击,保障业务持续稳定运行。DDoS基础防护:阿里云免费为用户提供最高5G的默认DDoS防护能力。在此基础上,阿里云推出了安全信誉防护联盟计划,将基于安全信誉分进一步提升有限时间的DDoS免费防护能力。阿里云为所有用户提供一定量免费的DDoS防护,免费防护阈值(即黑洞阈值)见官网上的产品规格,不同地域的黑洞阈值不同。对于不常受到攻击的初创/小体量用户来说,加入安全信誉防护联盟计划并根据联盟建议,维护平台安全,
178、提升安全信誉分,从而获得更高的有限时间免费DDoS防护能力,用于抵御偶然突发的DDoS攻击。DDoS防护包:DDoS防护包是针对阿里云上大型企业客户,通过阿里云原生网络和透明防护引擎缓解DDoS攻击,支持ECS、SLB、Web应用防火墙、EIP等云产品。默认提供免费DDoS基础防护能力,付费升级后可直接提升云产品防护能力,无需更换IP,无四层端口、七层域名数等接入规格限制,部署简单,只需要绑定需要防云上大型赛事保障白皮书 85护的云产品的公网IP地址即可使用。DDoS高防:DDoS高防(Anti-DDoS1Pro/Premium)是针对阿里云上以及云下企业客户,使用阿里云在全球部署的大流量清洗
179、中心资源,结合AI智能防护引擎,通过全流量代理的方式实现大流量攻击防护和精细化Web应用层资源耗尽型攻击防护。游戏盾:游戏盾(GameShield)是阿里云针对游戏行业面对的DDoS攻击推出的针对性的网络安全解决方案,相比DDoS高防,除了能针对大流量DDoS攻击(T级别)进行有效防御外,还具备彻底解决游戏行业特有的TCP协议资源耗尽型攻击(L4-CC攻击)问题能力,防护成本更低、效果更好。5.1.2.1.2 云安全中心云安全中心是一个实时识别、分析、预警安全威胁的统一安全管理系统,通过防勒索、防病毒、防篡改、合规检查等安全能力,帮助用户实现威胁检测、响应、溯源的自动化安全运营闭环,保护云上资
180、产和本地主机并满足监管合规要求。5.1.2.1.3 云防火墙云防火墙是业界首款公共云环境下的SaaS化防火墙,可以统一管理互联网到业务的南北向访问策略和业务与业务之间的东西向微隔离策略,针对云环境对互联网的资产暴露情况,进行全面梳理并集中管理公网IP的访问策略,并且一键接入,是业务上云的网络安全基础设施。该产品集成了入侵检测(IPS)功能,具有智能防御,同时支持失陷主机检测、主动外联行为的阻断、支持全网流量可视、业务间访问关系可视。该产品满足等保2.0中对虚拟边界、内到外管控、IPS入侵检测、6个月网络日志的相关要求,是等保2.0合规必选产品。5.1.2.2 云上数据安全5.1.2.2.1 敏
181、感数据保护敏感数据保护(Sensitive Data Detection and Protection,简称SDDP)是一86 云上大型赛事保障白皮书云上大型赛事保障白皮书款基于业务需求实现数据分类分级,并在精准识别基础上实现数据权限监控、数据脱敏、全域流转监控与异常检测的阿里云安全服务。该服务从海量数据中发现、检测并分析敏感数据的使用情况,及时发现是否存在数据泄露的异常事件并对其进行风险预警,帮助用户防止数据泄露并满足个人信息保护、等保2.0以及GDPR等合规要求。5.1.2.2.2 密钥管理服务密钥管理服务(Key Management Service,简称KMS)是一款安全易用的密码类服
182、务(cryptographic1service),提供密钥(cryptographic1key)的安全托管、密码运算(cryptographic operation)等基本功能,内置密钥轮转等安全实践,同时支持其他云产品通过一方集成的方式对云产品管理的用户数据进行加密保护。通过密钥管理服务,用户无需花费大量成本来建设专用的密码硬件基础设施以及设施之上的管理系统,而且还能获得云服务的高可用性和高可靠性,从而可以专注于开发用户真正需要关心的数据加解密、电子签名验签等业务功能场景。5.1.2.2.3 加密服务加密服务(Alibaba Cloud Data Encryption Service)通过在
183、阿里云上使用经国家密码管理局检测认证的硬件密码机,帮助客户满足数据安全方面的监管合规要求,保护云上业务数据的机密性。借助加密服务,用户可以进行安全的密钥管理,并使用多种加密算法来进行加密运算。5.1.2.2.4 数据库审计云数据库审计服务是一款专业、主动、实时监控数据库安全的审计产品。针对数据库SQL注入、风险操作等数据库风险操作行为进行记录与告警。云数据库审计支持RDS云数据库、ECS自建数据库,将数据库监控、审计技术与公有云环境相结合,为云端数据库提供安全诊断、维 护、管理能力。云数据库审计服务符合等级保护三级标准,帮助用户满足合规性要求。云上大型赛事保障白皮书 875.1.2.3 云上应
184、用安全5.1.2.3.1 Web应用防火墙Web应用防火墙(Web Application Firewall,简称 WAF),基于云安全大数据和智能计算能力,通过防御SQL注入、XSS跨站脚本、常见Web服务器插件漏洞、木马上传、非授权核心资源访问等OWASP常见Web攻击,过滤海量恶意访问,避免网站资产数据泄露,保障网站应用的安全性与可用性。5.1.2.4 云上业务安全5.1.2.4.1 爬虫风险管理爬虫风险管理(Anti-Bot1Service)专业检测高级爬虫,降低爬虫及自动化工具对网站的业务影响,提供对Web网页端、H5页面、APP、API全方位防护。主要防护场景包括航空占座、电商黄牛
185、、恶意撞库、核心接口被刷、刷票刷积分等。5.1.2.4.2 风险识别风险识别(Anti-Fraud1Detection)基于大数据、机器学习算法、流式计算等阿里巴巴的业务风控最佳实践,为客户提供从API服务、到决策引擎平台的一站式智能风控解决方案。解决企业客户在用户注册、运营活动、交易、信贷审核等关键业务中面临的欺诈问题。5.1.2.4.3 内容安全内容安全是一款多媒体内容智能识别服务,支持对图片、视频、文本、语音等对象进行多样化场景检测,有效帮助用户降低内容违规风险。常用的检测场景包括:智能鉴黄、暴恐涉政识别、图文广告识别、logo识别、敏感人脸识别、二维码识别、OCR图文识别、文本反垃圾、
186、语音反垃圾、文件内容反垃圾等。内容安全提供站点检测功能,可以定期自动检测您的网站上的风险和违规内容;OSS违规检测功能,对用户指定的OSS空间中的图片和视频进行涉黄、涉政检测;用户也可以直接调用内容88 云上大型赛事保障白皮书云上大型赛事保障白皮书检测API,提交指定场景的机器识别任务。5.1.2.4.4 实人认证实人认证服务是指依托活体检测、人脸比对等生物识别技术、证件OCR识别技术等进行的自然人真实身份的校验服务。目前实人认证服务只对企业用户开发,并只支持对拥有中华人民共和国第二代居民身份证的居民进行认证。5.1.3 阿里云安全服务在安全建设中除了完善安全产品的安全措施之外,构建专业化的安
187、全团队也是保障企业网络安全的措施之一。通常企业也会为了节省人力成本,采购专业化的安全服务用于内部网络安全能力的建设。传统的安全服务,例如渗透测试、代码审计、红蓝对抗、重保护航等都是保障企业网络安全的重要措施。本章罗列较典型的安全服务,如需了解更多安全服务和产品请参照阿里云官网。5.1.3.1 渗透测试渗透测试是一种黑盒安全测试方法,安全专家通过模拟真实黑客的技术手段对目标进行漏洞检测,突破系统的安全防护手段,深入评估漏洞可能造成的实际影响。以攻击者思维,模拟黑客对业务系统进行全面深入的安全测试,帮助企业挖掘出正常业务流程中的隐藏的安全缺陷和漏洞,并提出修复建议。5.1.3.2 代码审计通过人工
188、观察、模拟执行或半自动化工具扫描的方式,全面深入挖掘代码中的通用Web漏洞、业务逻辑漏洞、应用程序漏洞以及应用程序配置文件中的不安全因素云上大型赛事保障白皮书 895.1.3.3 红蓝对抗在确保业务稳定正常运行的前提下,以企业真实网络环境开展红蓝对抗演练。通常由蓝队服务(攻击方)扮演攻击者角色,以获取企业资产权限、业务数据、业务控制权限为目的展开攻击行为。通过攻击成果报告展现当前企业所面临的安全威胁并提出可落地的改进建议。红队服务扮演防守方(安全管家护航保障服务),包括演练前的风险梳理、风险加固及安全策略优化以及针对安全事件的应急响应处置,最大程度保障企业在重要时期或攻防演练阶段的零安全事件。
189、5.1.3.4 安全管家服务阿里云安全管家服务(以下简称:安全管家)是阿里云云盾安全专家团队经过多年的技术实战和经验沉淀,根据客户的业务需求,以云盾安全产品为防护基础,面向云上租户提供全面的、专业的、客户化的安全服务及安全咨询服务,从而保障用户安全体系能正常运行和持续优化,提供强有力的技术能力支撑,保障客户业务稳定、安全运行。5.1.3.5 云安全产品托管服务云安全产品托管服务提供日常的安全巡检以便及时发现漏洞风险,并通过漏洞修复、策略配置、补丁升级等安全加固方式,消除潜在风险,同时在出现安全事件时快速启动应急响应。托管服务提供针对云安全中心产品的5*8的在线安全咨询服务,及时解决用户在使用过
190、程中遇到的各类问题,协助客户完成产品的接入及策略的配置,根据业务情况制定产品防护策略,保障云安全产品的最大防护效果。90 云上大型赛事保障白皮书云上大型赛事保障白皮书5.2 云上大型赛事安全防护5.2.1 安全攻防演练5.2.1.1 重保护航的必要性随着计算机技术的飞速发展,大量数据信息保存在信息网络中。数据信息中包含着身份证信息、银行卡信息、家庭地址、网购记录信息等个人敏感信息,甚至还包括国家机密信息,难免会引来世界各地的人为攻击(例如拒绝服务、信息窃取、数据篡改/删除、计算机病毒等)。重大活动(重要会议、重大节日)期间,人为的网络攻击活动更为频繁,且更具针对性,导致安全压力剧增。一旦发生安
191、全事件,活动开展受到影响,甚至会带来不可估量的经济和名誉损失。由此可见大型赛事期间开展网络安全保障工作已经成为整个活动不可或缺的重要一环。5.2.1.2 重保护航分类在安全服务中,重保护航通常被分为两类,一是业务可持续性访问安全保障类,二是攻防演练对抗性安全保障类。前者在保障安全访问的同时仍需考虑如何对抗大流量攻击行为,避免在关键时刻出现不能访问或访问异常等情况。后者更多是组织内部从安全建设的角度,对信息系统进行模拟攻击行为,从而发现系统安全薄弱点,进而调整安全策略。攻防演练有助于发现更深层次的安全隐患,所以对安全技术的能力要求更高。另外,在保障业务可持续性访问的同时时,往往也会开展渗透测试、
192、红蓝对抗等具攻防演练性质的安全活动,以便为重保护航活动多上一份安全保险。云上大型赛事保障白皮书 915.2.1.3 攻防演练基本概论在一次完整的攻防演练项目实践中,主要有攻击方和防守方等攻防人员构造,其中防守方人员会有如下的划分:在一些大型的攻防演练或赛事中,防守方人员还有更细的划分:监测分析组序号职责工作组监测分析组应急处置组3攻击研判组21威胁情报分析组攻击溯源反制组21负责组织内部的网络设备、安全设备和各个专业信息系统的安全值守;包括日志分析、攻击行为、安全事件发现并记录现有问题,初步评估后向其它工作小组汇报所发现的安全事件,协助其它小组完成所汇报安全事件的闭环。对攻击行为、安全事件进行
193、判断,甄别攻击事件,为监测分析组的工作指明方向和工作重点。针对攻击行为、网络安全攻击事件的影响进行评估,并组织人员、制定方案,针对安全事件执行应急处置与根除操作(包括封禁攻击链路);检查与确认安全事件的处置效果,事后提交封禁IP列表或网络安全攻击事件应急响应处置报告收集和分析与活动或组织内部相关的安全情报,分析最新的安全漏洞和威胁信息,为攻击方提供技战术,为防守方制定应对建议。针对攻击行为、安全事件进行溯源,回溯攻击路径、追踪攻击者的身份信息,并进行信息固化;在条件允许的情况下对攻击行为进行反制,分析攻击者技战术、攻击思路,限制攻击者攻击行为或捕获攻击者攻击成果,提交攻击溯源反制成果报告。92
194、 云上大型赛事保障白皮书云上大型赛事保障白皮书序号职责工作组5.2.1.3.1 未知攻 焉知防(上)攻防对抗中,攻击方通常掌握着攻击的主动性,防御体系的建立也必然需要了解攻击者可能使用的攻击技术。作为攻击者,需要了解的安全相关概念如下:安全漏洞:指在硬件、软件、协议或流程的具体实现上存在缺陷,从而可以使攻击者在未经授权的情况下利用或绕过预先设定的安全流程,访问、修改或破坏安全流程校验之后的数据或信息,其中关注度较高的通常为RCE、SQL注入、任意文件上传/写入、未授权、弱凭证等。RCE漏洞:也叫远程命令执行/远程代码执行(remote1command/code1exe-cute),可让攻击者直
195、接向后端服务器注入操作系统命令或者代码,并达到控制后端服务器目的。SQL注入漏洞:服务端对客户端的请求未做特殊处理便交给数据库进行查询。客户端传入的参数内容可控,攻击者可构造恶意的SQL语句,恶意的SQL语句被带入数据库执行,可让攻击者获取到数据库中的敏感数据。网络边界:逻辑上不同网络安全域之间建立链接的枢纽,通常指DMZ区域(互联网与业务内网隔离的缓冲带)。APT攻击:高级持续性威胁,通常为某个团队利用当下先进的攻击手法对特定目标进行长期且持续性的网络攻击,常见的攻击方式为(使用0day攻击、鱼叉攻击、水坑攻击)。作为防守方,需要了解安全产品相关的基本概念:DDoS高防:用于防护大流量DDo
196、S攻击(例如SYN1Flood、UDP1Flood、DNS Flood)的技术或产品,避免业务系统在遭受到大流量攻击时,业务系统不会出现服务不可用,系统无法访问或其它拒绝服务现象。Web应用防火墙:简称WAF,主要为网站或App业务提供一站式安全防护,通过识别Web业务流量的恶意特征,对流量进行清洗和过滤后,将正常、安全的流量返回给服务端,避免业务系统被恶意入侵引发安全事件,保障系统业务安全和数据安全。防火墙:由计算机硬件和软件组成,部署于网络边界,对进出网络边界的流量进云上大型赛事保障白皮书 93行安全检查,可拒绝不受安全信任的访问流量,保障内部网络数据的安全。蜜罐:由计算机硬件和软件组成,
197、部署于不同的网络域环境,通过诱饵主机或诱饵服务,诱使攻击者对它们进行攻击,从而捕获攻击行为,通过分析捕获到的攻击行为,可推测出攻击者攻击意图或动机,使防守方更清晰的了解目前所面对的安全威胁,在一定程度上也给攻击者增加攻击成本。HIDS:基于主机的入侵检测系统,用于监测系统的安全状态或拦截恶意的动态行为,同时可以对攻击者在主机层执行的所有操作进行回溯。威胁情报:通过技术手段或安全产品(例如舆情分析、态势感知)等方式采集数据,并通过特定规则对采集的数据进行分析整理,最终为面临威胁的资产主体提供全面、准确或有参考意义的情报信息,有价值的威胁情报可以为高层人员提供后续工作决策方向的重要依据。5.2.1
198、.3.2 未知攻 焉知防(中)在一场攻防演练中,攻击者可能并不知道内部网络的区域边界、所使用的信息系统,甚至不知道组织内部的人员构成,他们知道的可能仅是防守方的组织名称。因此,攻击阶段的第一步则是信息收集,信息收集的广度与深度对演练最终结果起到举足轻重的作用。收集内容主要为防守侧的人员信息、组织架构、网络资产、技术框架及安全措施等。收集渠道以互联网端为主,例如合理使用各类搜索引擎、利用企业注册信息、企业备案信息等公开的信息查询平台,或者是使用社交网络开展信息收集。除此之外,攻击者还会发起主动的信息收集探测行为,例如使用一些安全相关的工具类(子域名枚举工具、端口扫描工具、web指纹/目录扫描等安
199、全工具)。这里使用某公开的搜索引擎为例,输入企业名称,可以从搜索引擎中检索到相关企业在互联网上披露的资产信息,如图。94 云上大型赛事保障白皮书云上大型赛事保障白皮书在对收集到的基础信息进行分析,提取出关键人物、关键系统、边缘系统、第三方系统、供应链等信息。此时进入打点阶段,意为从互联网突破进入到防守方相关的网络中或拿到与防守方有关系统的管理权限。该阶段技巧很多,也因供给侧人员的能力和经验而有所不同。常用的有边缘渗透,即基于已知信息生成攻击组合策略、已知高危漏洞自动化编排攻击、批量爆破互联网服务弱口令;社会工程学手段,即采用钓鱼邮件、从属关系、供应链等维度展开攻击行为。此外,近源渗透也是近年来
200、攻击者惯用伎俩,例如硬件植入、通信接入或伪装成维护人员,进入企业内部获取敏感数据。在当下网络安全背景下,参与攻防演练的双方都具备一定的安全技能,不同安全团队也都有安全知识储备,这些安全团队作为攻击方时也会使用一些未知的高危漏洞或攻击技术作为攻击方案。值得一提的是,打点作为高对抗阶段,需要与IPS、WAF、EDR等安全产品对抗,也需要与防守侧的人员做对抗。当攻击者寻找到突破口,就会采取稳固自身据点图:搜索引擎检索企业信息云上大型赛事保障白皮书 95的攻击行为,例如上传后门文件、创建通信隧道等便于后续横向渗透的操作。攻击者利用自身知识储备分析组织内部数据,在攻防过程中持续信息收集和分析,走完关键系
201、统、关键网络、管控平台等攻击路径。最终控制目标、清理痕迹、证明成果、提交攻击成果报告。5.2.1.3.3 未知攻 焉知防(下)攻防演练可分为三个重要阶段,阶段一是攻防演练准备阶段;阶段二是攻防演练保障阶段;阶段三是攻防演练结束阶段。作为防守方,一般在安全设施或业务系统趋于完善之时介入,开启专职的防守工作。图:攻防演练技战术的关键步骤图:防御构建准备工作的大致方向96 云上大型赛事保障白皮书云上大型赛事保障白皮书控制目标遍历攻击路径定位目标寻找突破口信息收集获取通行证横向渗透稳固据点确认攻击方案攻防演练的准备阶段,主要为梳理业务资产、识别安全风险、收敛安全风险。如有需要,可关停部分非核心业务系统
202、,来减少攻击暴露面。此外,还会审查安全基线、安全策略配置等是否满足安全要求。态势感知、蜜罐、IDS/IPS等安全设备的部署往往也在此阶段完成。在攻防演练保障阶段,攻击者会采用适宜的方式展开攻击行为,防守人员则需要从不同检测维度来识别这些攻击行为和攻击流量,将捕捉到的攻击事件上报并及时展开应急响应。值得注意的是,防守人员必须结合自身业务和关键痕迹进行联动分析。例如,当攻击路径中出现大规模的扫描与漏洞利用、OA系统/邮件系统/VPN等人工尝试登陆的行为以及人工注册业务系统账号挖掘漏洞等,便会产生与之对应的关键痕迹,如安全设备大量漏洞利用告警、办公系统/软件组织架构被批量浏览、关键业务系统出现大量错
203、误登陆日志以及业务系统出现如test关键词的新用户注册等,甚至某些业务系统还会出现主动防御退出告警、安全软件配置变动、来源未知的新增文件以及对外的DNS解析和ICMP行为。如果过于依赖安全设备,就有可能忽略掉这些细微异常而最终导致安全事件发生。攻防演练结束阶段,防守方可以拿到攻击方的攻击成果报告,从报告中可以了解组织内部的真实风险,对攻击过程进行复盘可以使防守方深入了解攻击者的攻击思路和攻击方案,以便在后续的安全建设中采取更优质更全面的安全防护措施,而不再是专注于修复某个安全漏洞,对防守侧工作的总结复盘也可以了解到内部安全建设的短板,为后续的安全建设指明方向。5.2.2 安全防护体系本届冬奥相
204、关信息系统部署在阿里云上,阿里云安全也全程参与了系统安全建设。本节即以阿里云安全的视角,对大型赛事的安全建设与安全防护展开论述。5.2.2.1 安全原则云上大型赛事保障白皮书 97在冬奥信息系统安全建设中,云上资产访问和管理遵从以下安全原则:网络隔离(纵深防御):通过云产品的安全隔离和访问控制功能,实现网络、系统、应用和数据不同维度的隔离以实现纵深防御。认证授权(最小权限):仅授权使用者必须的云账户和子账户权限,并开启双因素认证措施和关键操作二次认证能力。安全加密(开启加密措施):通过传输加密和存储加密措施实现数据在云上全程加密。监控告警:通过日志和监控措施及时发现配置变动、异常登录和操作、数
205、据泄露以及异常攻击等。5.2.2.2 云上安全防护框架5.2.2.2.1 身份认证体系云上身份认证体系包括面向云资源管理的RAM体系和面向客户自身的IDaaS身份认证体系,当企业存在多用户协同操作资源时,按需为用户分配最小权限,实行三权分立策略,管理更加方便,权限更加明确,信息更加安全。在冬奥实践中,对用户分配不同的子账号权限,并创建不同的用户组进行分组管理。其中AK和RAM采用单独权限划分,同一个用户单独的AK或RAM子账号,具备不同的调用权限,这里就使用了最小权限分配原则。5.2.2.2.1 云上安全防护体系云上安全防护体系框架分为以下四部分:淡蓝色:安全产品为用户提供的安全防护能力。例如
206、,DDOS/DCDN、WAF、云安全中心、RAM等。绿色:云产品为用户提供的安全防护能力(含红色的数据安全)。例如,VPC隔离、传输和存储加密等。蓝色:用户利用云产品能力进行的安全管理和安全监控活动。例如,日志透明98 云上大型赛事保障白皮书云上大型赛事保障白皮书5.2.3.2.3 安全监控体系安全监控体系是云计算基础架构最重要的组成部分之一。面向租户的阿里云安全监控体系主要由阿里云监控产品提供,如进行安全监控的云安全中心,进行资源监控的Cloud1Monitor,进行日志审计的SLS,进行云上运维风控的PAM(特权账户管理系统)以及进行操作和配置审计监控的Action1Trail等。有效的安
207、全监控能及时发现安全隐患和攻击行为,及早降低损失。安全监测体系主要由云安全中心(态势感知)、日志服务、操作和配置审计、云监控以及SQL洞察组成。其中云安全中心主要关注安全攻击和漏洞相关信息,日志服务汇聚所有云上日志审计信息,可以作为合规和审计使用,操作和配置审计是日志服务主要日志来源,云监控主要关注云资源的使用、释放等,SQL洞察主要是数据库相关的增删改查审计。化、云主机安全管理等。橘色:作为用户云上安全防护体系的主要体现。图:云上安全防护体系云上大型赛事保障白皮书 995.2.3.2.4 应急响应恢复体系通过高防、WAF和云安全中心能自动响应、告警并阻断攻击行为。云基础设施提供快照、备份和容
208、灾技术,当出现误操作或攻击异常时,安全工程师及时进行安全恢复和应急响应。5.2.3.2.5 安全运营体系基于系统总会被攻破的假设,强保护、强监控、强运营是云上安全之道。根据业务需求,对业务系统以及业务数据进行分类分级,圈定需要重点保障的业务系统,根据分类分级结果执行有区分的安全防护措施。从以下维度思考安全保障体系:PDR模型:保护、监测、响应,三种安全措施分别能覆盖的面和能达到的深度。安全分层模型:ECS、容器、网络、中间件、应用、数据层。等保2.0:云上通信网络、云上区域边界、云上计算环境、云上安全管理中心。业务分层:核心业务、重点业务、边缘业务。身份管理:特权账户和权限、运维账户和权限、关
209、键业务账户和权限。风险和合规:业务风险、合规风险、安全风险。高级风险管理:已知风险和威胁、未知风险和威胁,重点关注未知风险和威胁。风险收益:投入产出比,风险和最终收益,成本、风险和收益是云上风险考虑的重要因素和安全工作的出发点。通过不同矩阵的分析,交汇查找安全体系的弱点。在冬奥安全建设与安全保障实践工作中定期检查账户和特权账户权限、定期变更密码、云安全中心配置变动规则检查、红蓝对抗等方式去发现安全体系具体风险点进行安全加固。通过合规(例如隐私保护、等保)以及行业监管要求为冬奥提供安全保障。100 云上大型赛事保障白皮书云上大型赛事保障白皮书5.2.2.3 常态化安全护航在冬奥安全护航实践中,除
210、了基于本文提到的云上安全原则、云上安全建设防护体系框架的基础之外,在实践中还对整个冬奥赛事进行了常态化的安全护航工作。这些安全护航工作包括多个安全监控系统的部署(例如安全监控CTAS系统)、多次开展渗透测试和红蓝对抗等具攻防性质的安全活动以及多家安全团队(IOC威胁情报、邮件安全、终端安全、云安全等)提供的专业领域类的安全保障工作。其中在冬奥赛事期间,安全保障工作为7x24小时不间断,安全告警事件在实践中得到了分钟级闭环。纵观从安全建设到赛事闭幕的整个过程,云产品自身的可靠性为阿里云用户提供了更多云上安全保障,让用户以更低成本拥有更强的安全能力。但是,用户仍需要对自身云上数据的安全性承担责任,
211、定期执行安全测试、合规检查,以及开展攻防类安全活动等,这样才能更好地提升自身安全能力。云上大型赛事保障白皮书 101第六章 云产品稳定性治理与风险管控系统的稳定性极大程度依赖于云产品的稳定性,在赛前、赛时,我们都需要时刻关注着云产品层是否在稳定运转、是否有潜在风险,这是业务稳定性保障的基石。在本章,我们将详细介绍云产品稳定性治理和风险管控方面的实践经验。6.1 云产品稳定性治理6.1.1 什么是稳定性治理在ISO1IEC125010-20111SQuaRE标准中,稳定性被理解为“应对故障(faults)的能力、对用户而言是可用的,被性能、可用性、可维护性等因素影响”9。系统的“稳定性”是指系统
212、要素在外界影响下表现出的某种稳定状态。但事实上,复杂系统中潜伏着大量可能影响到稳定性状态的因素组合。在各种应用、系统、平台的交叉组合中,稳定性保障难度也呈指数性增长。由于复杂系统的涟漪效应,细微的参数配置(MTU/某个内核参数/环境变量等等)也可能让系统稳定性受到挑战。在大型赛事核心系统上云的背景下,开、闭幕式及重点赛事会遇到流量高峰,最高会有千万级DAU以及十万级的PV的访问量,赛事系统的稳定性、准确性和即时性对于一届大型体育赛事是至关重要的。稳定性的高低依赖两大因素:云平台自身的稳定性能力,以及使用产品组合保障业务的高可用、灾备能力。本章节主要阐述稳定性建设的在大型赛事活动上的实践思考和简
213、要思路。6.1.2 稳定性治理的思想关于稳定性治理的方法,答案和途径都不尽相同。那什么是可遵循的稳定性治理102 云上大型赛事保障白皮书云上大型赛事保障白皮书的思想呢?我们可以从可用性计算公式(Availability Estimate)进行挖掘:AvailabilityEstimate=MTBF/(MTBF+MTTR)其中,MTBF:the1Mean1Time1Between1Failure(平均故障间隔时间),MTTR:the Mean Time To Recover(平均故障修复时间)这里涉及两个变量:故障概率、故障时长。通过增大MTBF、减小MTTR,可以提高系统的高可用性。主要包含减
214、少故障发生概率、减少故障恢复时间、制造故障发生概率(可控的)三个方法。为什么会需要人为制造故障发生概率?因为故障发生相应频次较低,没有办法很好地提前发现故障,所以需要制造故障。减少故障发生概率是通过一些稳定性原则进行系统设计及调优来改善的,制造故障发生概率是通过一系列的容灾演练、全链路压测、混沌工程等检查系统的自愈能力及稳定性,并将发现的潜在风险进行治理。9 ISO/IEC 25010:2011,Systems and software engineering-Systems and software Quality Requirements and Evaluation(SQuaRE)-Sy
215、stem and software quality models,S云上大型赛事保障白皮书 103我们可以推导及设计一些对应的稳定性原则,用于设计客户核心系统架构及优化其稳定性。N+1原则:系统中的每个组件都应做到没有单点故障。依赖识别简化原则:尽可能单元化每个组件,减少各系统的依赖性。回滚原则:确保系统可以向前兼容,在系统升级时应能有办法回滚版本。隔离原则:应该提供控制具体功能是否可用的配置,在系统出现故障时能够快速下线功能。异地多活原则:考虑在多地实施数据中心进行多活,至少在一个机房断电的情况下系统依然可用。自我保护原则:遇到外部恶意输入时,有一定的防错能力,遇到大促时可以考虑少流血,牺牲
216、一部分保护另外一部分。例如:限流,降级等。水平扩展原则:系统架构做到能水平扩展,才能有效避免瓶颈问题。6.1.3 稳定性治理的思考与拓展当经历几次大型赛事的保障活动后,我们对于稳定性治理就有了进一步的思考:一个是“人”,一个是“时间”。图:故障恢复公式104 云上大型赛事保障白皮书云上大型赛事保障白皮书角色转变人:通常来讲,稳定性治理是通过人进行巡检、发现问题并解决问题,这对于人的要求就很高,且可复用性会较差,那么我们是否能将稳定性治理场景化及工具化?时间:大多数场景下,我们是被动的接收问题和处理问题,系统稳定性风险较大,耗费成本也极大。那么我们能否将动作前置,提前介入进行风险巡检,主动规避风
217、险?传统的巡检及诊断工具过度依赖工程师的经验以及事后复盘之后的诊断效率,导致开发迭代成本较高、使用风险较大。阿里云根据多年专家诊断以及重大活动重保经验,开发了Apsara1ServiceStack工具箱,其中包括CloudDoc/Advisor/智能诊断等工具。Apsara ServiceStack-CloudDoC是用于风险管理的工具,有三大亮点:1)前置的资源健康评估,以售后、研发团队多年积累的海量问题特征库为依托。2)对每个客户自动梳理潜在风险并提供解决方案。3)让用户可以有机会在问题实际发生之前采取预发措施进行规避,大大提高诊断效率和降低售后人力成本。针对30类云产品及各种使用特性,A
218、psara ServiceStack-CloudDoc通过巡检账号下资产各产品各专项的风险项,进行诊断并输出巡检报告。客户可以在任何周期进行风险巡检,并不断修复达到理想的健康评分。图:稳定性治理的拓展主动寻找问题发现问题解决问题云上大型赛事保障白皮书 1056.2 北京冬奥稳定性治理实践通过以上稳定性原则及智能巡检工具,北京冬奥核心系统上云的业务场景也成为了我们的思想及工具的锤炼场,将稳定性治理转化为前置主动方。6.2.1 核心系统上云架构-稳定性治理实践在冬奥中,我们根据上述的设计原则对核心系统上云架构进行了设计和评估。根据异地多活原则,制定了核心系统上云的架构设计(同城双可用区三机房异地容
219、灾),欧洲项目群多region多AZ容灾方案。根据N+1原则,针对识别出LiveCloud视频传播项目单点架构风险,并做好充足的预案准备。根据水平扩展原则,在某核心系统容器集群中建议配置水平伸缩HPA组件,避免!图:Apsara ServiceStack-CloudDoc的诊断能力106 云上大型赛事保障白皮书云上大型赛事保障白皮书流量高峰的瓶颈问题。根据自我保护原则,安全层面配置蜜罐捕获,获取攻击行为及情报,以此进行溯源反制。经过上述治理,我们不仅对整体系统的架构进行了调优,同时让大型赛事核心系统在云上的架构加更稳定,为后续赛时0故障奠定了良好的基础。6.2.2 智能风险管控工具-Aspar
220、a ServiceStack-CloudDoc在冬奥重保活动中,我们也通过智能巡检工具进行了一系列的稳定性治理及巡检,保障赛前及赛时核心系统平稳的运行。图:蜜罐访问趋势图!云上大型赛事保障白皮书 107Aspara ServiceStack-CloudDoc是集巡检、诊断、监控和服务管理一体化的公共云运维服务平台。基于云上用户海量问题特征库,通过技术服务经验沉淀、大数据、机器学习等方式,提供场景化根因分析、风险管理、诊断能力编排以及自动处理能力,帮助客户减少业务故障影响时间,提高用户业务稳定性。其不仅仅是技术或产品,更是一种理念和策略。Aspara ServiceStack-CloudDoc的
221、运维服务以数据为基础,场景为导向,算法为支撑,为现有云上业务赋予巡检与诊断服务能力,全方面覆盖云上业务领域场景,解决运维工作闭环问题。Aspara ServiceStack-CloudDoc平台风险管理功能,集成各产品全链路能力,大幅度降低了人肉风险巡检带来的耗时长问题,并提高服务自主化效率。现有风险管理中包含:风险巡检、风险报告、风险治理、风险通知,支持风险场景1009个,覆盖产品30个。在整个冬奥保障过程中,针对冬奥会多个账号共发现x项风险,闭环优化x项。Aspara1ServiceStack-CloudDoc还赋能了公共云产品智能顾问(Intelligent Ad-图:Aspara Se
222、rviceStack-CloudDoc相关架构及能力108 云上大型赛事保障白皮书云上大型赛事保障白皮书Advisor),通过与Advsior进行融合,赋能Advsior平台更多的巡检能力,同步Cloud-Doc独有的风险巡检项,助力了阿里云公共云智能化运维,以资源+应用的视角对云上产品数据进行梳理,使其具备巡检、诊断、监控与服务管理多元化的能力,推动云上运维体系建设及用户生命周期运维管理,实现全面数字化转型。6.2.3 冬奥重保-风险巡检整体的风险巡检的逻辑分为产品和场景两部分。产品方面,当前我们的各产品方已经有了各类巡检平台,针对不同产品特性及潜在风险,我们可以进行巡检项的配置。比如针对E
223、CS产品,我们的可配置项有以下单机容错能力&共享型实例风险。禁止资源腾挪类热迁移。rlock资源预留。实例打散度确认。ECS实例所在宿主机风险巡检。对于数据库产品的巡检,可以参考如下的脑图:图:公共云产品智能顾问调用了Aspara ServiceStack-CloudDoc能力云上大型赛事保障白皮书 109图:数据库监控巡检项110 云上大型赛事保障白皮书云上大型赛事保障白皮书针对不同的业务场景,Aspara ServiceStack-CloudDoc也可以针对对应的场景进行场景化针对性巡检并输出相应报告及修复建议,例如:高可用:负载均衡后端单点风险,CDN单源站风险,多VM聚集在同一底层宿主
224、机风险等等。安全:公网暴露IP地址DDOS风险。数据冗余:ECS快照冗余风险、MySQL数据备份风险。性能:ECS共享实例争抢风险、RDS共享实例争抢风险。同时在这期间定制化输出了开发SLB挂载机器跨可用区检测能力,定制增加异常事件、优化建议、优化SQL等能力,经过冬奥会的实践,我们反向增强了Aspara ServiceStack-CloudDoc巡检工具的能力。图:Aspara ServiceStack-CloudDoc巡检报告封面云上大型赛事保障白皮书 111下面分享我们在某一次巡检中获取的报告,给读者一个直观的印象。针对阿里云账号:北京2022年冬奥会和冬残奥会组织委员会,CloudDo
225、c为您执行风险扫描任务,任务摘要信息如下:容器容器xxxxxxxxx1712022-01-18资源分布实例检测深度风险安全风险稳定性风险成本风险性能风险基础数据总扫描资源数风险扫描场景扫描时间112 云上大型赛事保障白皮书云上大型赛事保障白皮书RDS实例检测实例锁定检测x建议检查实例资源使用情况,联系后端同学解锁RDS实例检测实例运维时间检测x建议调整运维时间为02-06之间RDS实例检测实例状态检测x检查实例状态,看是否有升级等操作RDS实例检测实例规格检测x建议升级为RDS高可用版和三节点企业版RDS实例检测实例可用性检测x查看控制台日志,周期内是否有HA故障、实例宕机等情况RDS实例检测
226、实例读写账户检测x建议只保留一个读写账号,业务账号请使用DML账号RDS实例检测实例账户检测x请给业务创建请求账户RDS安全风险RDS多可用区评估x本评估结果属于参考信息RDS安全风险开启公网访问的RDS实例列表xRDS安全风险白名单检测xRDS性能风险DAS Sql优化数据明细RDS性能风险DAS Sql执行异常统计xxRDS性能风险DAS优化建议xRDS性能风险RDS异常事件xRDS性能风险RDS重写慢SQL建议RDS性能风险RDS升级规格建议xxRDS性能风险RDS索引建议xRDS性能风险RDS内存、IOPS或CPU超限实例列表xRDS性能风险连接数超限的RDS实例列表xRDS基础数据R
227、DS基础信息根据最小权限原则和业务需要,按需配置检查数据库SQL是否需要优化,如无法优化,则需升级实例规格x产品名一级分类评估项建议影响实例云上大型赛事保障白皮书 113SLB基础数据SLB基础信息xRDS深度风险MySQL-TimeSeriesAbnormalx请您登录到DAS控制台查看详情RDS深度风险MySQL-SQLOptimizationx请您登录到DAS控制台查看详情RDS资源分布RDS同时存在经典和VPC地址的实例列表xRDS实例检测实例空间使用率检测x建议升配或清理数据RDS实例检测实例活跃连接数检测x建议排查慢SQL与请求QPS是否异常RDS实例检测实例内存使用率检测x建议联
228、系小二排查内存升高原因RDS实例检测实例CPU使用率检测x建议排查慢查询,优化SQLRDS实例检测实例主备延迟xRDS实例检测实例复制SQL线程检测xRDS实例检测实例复制IO线程检测RDS实例检测实例临时表数量检测xxRDS实例检测实例innodbBuffer命中率检测xRDS实例检测实例故障切换检测xRDS实例检测实例白名单检测RDS实例检测实例同步方式检测xxRDS实例检测实例近期备份检测xRDS实例检测实例备份数量检测xRDS实例检测实例IOPS检测xRDS实例检测实例连接数检测建议联系售后排查延迟根因建议业务降低流量,减少连接池连接数量建议升配或者减少大查询该调整该实例的备份策略请检
229、查该实例的备份策略建议修改为半同步方式建议清理掉0.0.0.0IP段建议关注故障切换记录,排查原因规避风险建议升配扩大buffer建议检查实例慢SQL,重点优化表连接,file sort,insert.select等请联系小二进行修复请联系小二进行修复x产品名一级分类评估项建议影响实例114 云上大型赛事保障白皮书云上大型赛事保障白皮书弹性IP安全风险EIP DDOS攻击统计(仅供参考)x弹性IP成本风险未使用的弹性IP列表x将EIP绑定至目标实例,或退订未使用的EIP实例。CDN安全风险未配置IP黑名单的CDN域名列表x配置IP黑名单CDN安全风险未开启防盗链的CDN域名列表x开启防盗链CD
230、N安全风险未开启鉴权的CDN域名列表x开启鉴权CDN稳定性风险QPS超限的CDN域名列表xCDN性能风险命中率超限的CDN域名列表x检查CDN缓存配置CDN性能风险错误率超限的CDN域名列表x检查CDN上配置的源站是否正确、检查源站是否存在URI路径问题、检查是否存在防盗链配置错误问题SLB深度风险单点风险xSLB安全风险SLB DDOS 攻击统计(仅供参考)xSLB性能风险SLB挂载机器跨可用区检测SLB稳定性风险不是RS跨可用区的SLB实例列表xxSLB稳定性风险未开启健康检查的SLB实例列表xSLB稳定性风险SLB共享实例列表xSLB成本风险资源空闲检测SLB性能风险新建连接数(4层)超
231、限的SLB实例列表xxSLB性能风险带宽出流量(4层)超限的SLB实例列表xSLB性能风险xQPS超限的(7层)SLB实例列表SLB性能风险连接数超限(4层)的SLB实例列表建议您根据实际业务需要加多个实例到对应默认服务器组或虚拟服务器组建议删除未使用的实例可关注共享实例性能,可升级至更高实例规格修改SLB健康检查配置本评估结果属于参考信息x产品名一级分类评估项建议影响实例云上大型赛事保障白皮书 115Redis实例检测db节点请求RT检测xRedis实例检测db节点异常流量检测x请通过控制台监控查看数据节点流量异常情况请通过控制台监控查看数据节点请求RT情况Redis实例检测db节点内存使用
232、量倾斜检测x请通过控制台查看各数据节点内存使用量情况Redis实例检测db节点QPS流量倾斜检测xRedis实例检测db节点内存使用率倾斜检测x请通过控制台查看各数据节点内存使用率情况请通过控制台查看各数据节点QPS流量情况Redis实例检测db节点key数量倾斜检测x请通过控制台查看各数据节点key数量情况Redis实例检测db节点出口流量倾斜检测x请通过控制台查看各数据节点出口流量使用情况Redis实例检测db节点入口流量倾斜检测x请通过控制台查看各数据入口流量情况Redis实例检测db节点磁盘容量倾斜检测xRedis实例检测风险操作检测xRedis实例检测大版本实例检查Redis实例检测
233、实例锁定状态检测xxRedis实例检测实例状态检测xRedis实例检测实例可用性检测xRedis实例检测实例运维时间检测Redis实例检测实例白名单检测xxRedis性能风险Redis多可用区评估xRedis性能风险实例连接数超限的Redis实例列表xRedis性能风险CPU、内存超限的Redis实例列表xRedis基础数据Redis基础信息请通过控制台查看各数据节点磁盘容量情况检查连接数情况,判断是否存在读写不合理的情况,没有则需要升级Redis实例规格本评估结果属于参考信息建议清理掉0.0.0.0IP段建议调整运维时间为02-06之间查看控制台日志,周期内是否有HA故障、实例宕机等情况查看
234、控制台日志,周期内是否有HA故障、实例宕机等情况提交工单申请解锁,解锁后请紧急处理使实例处于正常状态请升级实例引擎版本请检查实例审计日志的风险操作x产品名一级分类评估项建议影响实例116 云上大型赛事保障白皮书云上大型赛事保障白皮书Redis实例检测proxy节点DB后端异常检测xRedis实例检测proxy节点CPU使用率异常检测x请在控制台监控查看相关CPU指标进行排查请联系小二进行排查处理Redis实例检测proxy节点拒绝连接检测x请联系小二进行连接排查Redis实例检测proxy节点buffer缓存容量检测x请在控制台监控查看proxy节点buffer缓存使用情况Redis实例检测p
235、roxy节点出口流量倾斜x请在控制台监控查看proxy节点出口流量倾斜异常情况Redis实例检测proxy节点入口流量倾斜xRedis实例检测proxy节点请求连接倾斜x请在控制台监控查看proxy节点请求连接倾斜异常情况请在控制台监控查看proxy节点入口流量倾斜异常情况Redis实例检测proxy节点慢查询检测x请通过控制台查看proxy节点慢查询,并作出相应优化处理Redis实例检测db慢查询监测xRedis实例检测proxy节点主机检测xRedis实例检测db节点主机健康监测Redis实例检测 db节点内存使用率检测xxRedis实例检测db节点出口流量检测xRedis实例检测db节点
236、入口流量检测xRedis实例检测 db节点请求命中率检测Redis实例检测db节点风险命令检测xxRedis实例检测db节点CPU使用率检测xRedis实例检测xdb节点CPU限制检测Redis实例检测db节点连接数检测请通过控制台查看慢查询日志,并进行相应的优化请通过控制台监控查看节点命中率,做适当的调整请通过控制台检查审计日志中的高风险命令请通过控制台监控查看数据节点CPU使用率情况请通过控制台监控查看数据节点CPU情况请通过控制台监控查看数据节点请求连接数情况请通过控制台监控查看入口流量,并做适当的调整请通过控制台监控查看出口流量,并做适当的调整请通过控制台监控查看内存使用率,并做适当的
237、调整请联系售后做相应的主机排查和处理请联系技术售后排查主机异常x产品名一级分类评估项建议影响实例云上大型赛事保障白皮书 117SSL深度风险SSL证书到期x备案稳定性风险未完成备案接入的域名列表x完成域名备案请及时续费,续费操作参考:https:/ 云上大型赛事保障白皮书云上大型赛事保障白皮书ECS安全风险VPC网络的ECS安全组开启过度授权xECS成本风险经典网络的ECS安全组开启过度授权x过度授权可能导致允许了非预期的访问,引起安全风险,建议调整安全组策略。过度授权可能导致允许了非预期的访问,引起安全风险,建议调整安全组策略。ECS安全风险ECS资源争抢(共享型实例)xECS安全风险ECS
238、资源争抢(独享型实例)xECS安全风险ECS相同NC检查x相同NC存在过多实例需要做打散ECS稳定性风险ECS宕机日志xECS性能风险ECS共享实例列表x对于共享实例可根据业务适当推荐升级为独享实例ECS成本风险ECS CPU使用率低x根据CPU总体运行情况,适当减少实例配置,优化成本ECS成本风险未挂载到ECS实例的磁盘列表xECS成本风险ECS 实例带宽负载过低xECS成本风险ECS IOPS读和写过低ECS成本风险ECS IOPS均值过低xxECS性能风险ECS实例带宽负载过高xECS性能风险 ECS公网出流量TOP50 xECS性能风险ECS IOPS均值过高ECS性能风险ECS IO
239、PS读或者写过高xxECS性能风险xECS CPU利用率高ECS基础数据ECS实例基础信息列表磁盘已购买未使用,造成成本的浪费,建议挂载到ECS实例,如确实未使用,则做退订处理。检查应用层是否需要优化性能,否则建议扩容机器。提示:此CPU使用率的数据来源从物理机层面采集,数据准确性低于云监控Agent从VM内部采集的数据,仅供参考,如果出现CPU 平均使用率、峰值使用率和云监控不一致的情况,则以云监控的为准。如您未安装云监控,则建议安装。系统负载长期处于较低状态,在未有流量突变的前提下,可适当减少实例数x产品名一级分类评估项建议影响实例云上大型赛事保障白皮书 119ECS实例检测检查按量实例是
240、否因为欠费导致停服xECS实例检测检查实例的组件是否已欠费xECS实例检测实例启动异常xECS实例检测实例镜像加载异常xECS实例检测实例性能短暂受损xECS实例检测实例管控系统异常xECS实例检测实例虚拟化异常xECS实例检测实例操作系统异常xECS实例检测实例申请资源异常xECS实例检测突发型实例CPU性能受限xECS实例检测实例所在宿主机告警ECS实例检测CPU资源争抢或绑定失败xxECS实例检测实例磁盘扩缩容异常xECS实例检测实例磁盘IOHangxECS实例检测实例磁盘加载异常ECS实例检测实例云盘读写受限xxECS安全风险ECS DDOS 攻击统计(仅供参考)xECS安全风险超过公
241、网清洗限制的ECS实例列表xECS安全风险ECS安全组策列表xECS安全风险未设置安全组策略的ECS实例列表当前攻击流量已经超过ECS默认防护能力,请使用高防IP产品x产品名一级分类评估项建议影响实例120 云上大型赛事保障白皮书云上大型赛事保障白皮书ECS深度风险实例内网bps/pps超过规格限制x1)建议升配,各实例规格对应网络bps/pps上限可参考https:/ 2)或增加业务集群机器数量。ECS深度风险ECS系统内部夯机xECS深度风险虚拟化网卡队列丢包x1)确认VM内部CPU是否打满,如果是因为业务load高打满建议升级配置。2)确认网卡多队列是否开启,如果未开启,建议参考http
242、s:/ 进行开启。配置kdump等复现或者现场授权抓dump分析ECS资源分布类型分组xECS资源分布地域分组xECS资源分布配置分组xECS实例检测DDos攻击的防护状态异常ECS实例检测安全组入方向常用端口未放开xxECS实例检测网卡丢包xECS实例检测网络会话异常xECS实例检测网卡加载异常ECS实例检测网络流量达到实例网络带宽上限xxECS实例检测网络突发带宽受限xECS实例检测x基础网络配置异常ECS实例检测检查包年包月实例是否已到期x产品名一级分类评估项建议影响实例云上大型赛事保障白皮书 1216.2.4 冬奥重保-稳定性专项在赛前,我们成立了稳定性专项,对阿里云各产品包括库存水位
243、、高可用风险、产品侧应急预案等等都进行了专项梳理。通过系统化的稳定性排查项来规避产品侧的部分风险。以ECS为例,本次冬奥会北京奥组委、奥林匹克国际官网、奥林匹克频道OCS、奥林匹克广播服务公司OBS等奥运核心系统全面上云,神龙ECS是冬奥系统运行的核心底座,其稳定性直接关系着冬奥系统的稳定运行,可以说牵一发动全身。为给北京冬奥提供极致的ECS稳定性体验,ECS数据稳定性团队和技术中台团队紧密合作,共同制定北京冬奥重保方案,包括重保风险识别、风险预防、风险消除、重保告警信息推送、变更风险管控、应急预案验证等。包括以下手段:共享型实例识别并消除性能争抢风险 实例宿主机聚合度较高的情况进行合理热迁移
244、打散 库存进行腾挪及资源预留 变更风险管控 底层宿主机风险巡检并评估规避 禁止资源腾挪热迁移以及告警发送更新 rlock资源评估在评估奥组委ECS库存资源时,我们发现北京政务云部分ECS实例规格存在库存不足情况,可能不足以满足赛事过程中的升配需求。为了更好的保障冬奥会顺利进行,应对非预期的扩容需求,我们决定对北京政务云机房进行腾挪扩容并做资源预留。同时也考虑到SPOT实例售卖可能影响公有云上冬奥客户扩容,对客户所在地域的SPOT水位进行了检查并做合理水位调整,尽力保障客户有扩容空间。云网络方面,我们在稳定性单点风险梳理过程中发现Live Cloud系统存在单专线风险,如发生异常将直接影响赛事转
245、播。若阿里云侧对应CSW设备出现故障,恢复SLA将是12小时。在确认运营商无法提供冗余线路的情况下,云网络与物理网络团队122 云上大型赛事保障白皮书云上大型赛事保障白皮书积极设计阿里云侧的异常处置机制并分别提供了完整方案。基于客户风险考虑,最终选择了物理网络同机架备份CSW设备的方案,虽然成本提高了,但是可把恢复时间控制在一小时以内。数据库方面,针对宿主机、资源维度、实例维度以及管控任务维度进行体系化稳定性检查。主机维度类资源维度类实例维度类管控任务维度类分类检查项主机内存售卖率检测实例打散情况分布实例磁盘高水位列表实例CPU峰值检测Redis实例内存峰值检测实例连接数使用率检测Redis实
246、例带宽峰值检测主机磁盘高水位检测主机CPU峰值检测主机IO util峰值检测主机机型检测主机CPU售卖率主机磁盘售卖率检测实例备份时间检测(避开开幕式/闭幕式等高峰期)实例主动HA检测实例重搭/升级/迁移任务实例处于不可用修复状态实例处于不可用状态RDS-MySQL巡检评分检测实例故障HA检测实例备份失败检测实例单节点部署检测RDS-MySQL实例版本检测实例复制延迟检测云上大型赛事保障白皮书 1236.2.5 冬奥重保-赛时每日巡检在赛时重保关键期,我们针对各类产品对底层宿主机稳定性、管控组件、容量水位、安全告警进行每日巡检,保障赛时期间云产品平稳运行。ECS稳定性:风险每日巡检及规避、聚合
247、度打散等7项措施。ACK稳定性:容器ARMS业务监控及每日巡检。RDS稳定性:NC/实例/管控任务3个维度进行每日巡检。云网络稳定:8类云网络产品监控告警,水位监控/IDC和XGW物理网络水位监控。云安全稳定性:欧洲项目群监控大盘及安全告警。DCDN稳定:DCDN节点水位巡检。图:赛时每日云产品水位巡检结果124 云上大型赛事保障白皮书云上大型赛事保障白皮书对于系统核心业务资源,我们也进行了关键节点的流量峰值巡检,进而与压测结果进行对比,动态调整横向扩容策略。DCDN流量 核心系统DCDN总流量峰值巡检 重点DCDN域名流量峰值巡检 WAF流量 核心系统WAF总请求量巡检 核心系统WAF峰值带
248、宽巡检 公网流量 核心系统与欧洲项目公网总出入流量峰值巡检 Anti-DDoS高防带宽 Anti-DDoS高防整体流量峰值巡检图:赛时每日业务侧流量巡检结果云上大型赛事保障白皮书 1256.2.6 冬奥重保变更管控变更管控工作贯穿在网平基础架构环境各种设备架构的整个生命周期,是ITIL管理中非常重要的一个流程环节,和其他流程关系非常紧密,稍有不慎就容易导致故障。在最古老的变更管控理论中Lewin提到过变更管理的三个基本逻辑,基本定义了变更所需要做的准备,实施变更以及变更达到的效果三个大阶段。Stage 1 entails persuading a group that change is ne
249、cessary.Once they are amenable to the idea of change.Stage 2 executes that change.Finally,when the change is broadly complete,Stage 3 institutionalizes the new patterns of behavior and thought.保证云资源稳定性的最有效方式是封网,这也是历次重大活动保障前的标准操作。但是封网过多则会影响阿里云正常的产品发布和迭代,尤其在冬奥重保周期跨度长达x天的情况下。因此,保障团队在系统和产品能力支持的情况下,尽量把封网
250、精细化到资源颗粒度层面,减少封网对其他用户的影响。由于云的多租户环境特性,在长达x天的封网中,还是存在着多种变更需求。平衡变更对奥运业务的影响以及对其他客户的影响程度成为一件重要的事情。在变更需求的评审中,我们引入了不同维度的评审机制,从变更地域、变更时间、变更产品、潜在影响、回滚方案成熟度等多个维度进行评审,并且和各产品稳定性负责人一起严格把关,最终实现变更期间奥运业务0中断。图:封网公告126 云上大型赛事保障白皮书云上大型赛事保障白皮书6.3 稳定性巡检总结稳定性工作除了赛事保障和日常轮值,更是一份目标清晰、过程可跟进、结果能检验的体系化工作。稳定性治理是稳定性工作中较为复杂的部分,这里
251、面既包含历史包袱,又存在新的问题场景。现有的很多系统均会逐步经历原始阶段、部分具备、基本覆盖、能力完善以及全面提升的阶段,整体稳定性治理的工作就是在不断的迭代循环,在一个“相对混沌”的核心系统打造的有序化,稳定化。图:北京冬奥变更管理云上大型赛事保障白皮书 127图:云上大型赛事东西向服务分层第七章 保障阵型与流程管理前文详细介绍了保障体系的大部分内容,主要集中在技术领域。本章将从阵型与流程的角度入手,阐述如何构建合理的保障阵型,及如何设计合理的保障流程,以此构建大型赛事的服务保障通用方法论。7.1 云上大型赛事保障阵型基于云上大型赛事的规模,为提供更有效的服务,有必要对保障团队进行分层,这里
252、以东西向的概念进行讨论。7.1.1 基于前中后台的服务分层如下图所示,整个服务体系分为前中后台。前台是听得见炮火的一线业务专家,中台是体系化标准化解决问题的技术专家资源池,后台则为代表了细分产品领域最高深度的产品专家。128 云上大型赛事保障白皮书云上大型赛事保障白皮书前台:业务前台的定位是通过前场的快速响应保证客户业务稳定性,提升服务体感。这就要求前台必须要由深入了解客户业务的业务专家担任,对于客户的体系、架构、人员、业务、日常工作都比较熟悉,可以对客户随时的突发业务问题或业务需求进行快速响应对接。前台需要把这些业务问题或者业务需求“翻译”为具体的技术问题,以便中后台从技术角度出发来解决问题
253、。在保障过程中,前台既需要代表客户从业务角度发声,又需要作为中后台的传声筒传达技术理解,因此前台需要有极强的沟通协作能力,对客户心智的把控能力,以及问题主导能力,以结果为导向来思考和动作。中台:技术中台的定位是问题终结者,能够体系化的解决大部分云上的问题。我们为客户提供的保障,其本质也不过是对客户的业务问题或业务需求进行一一解决,中台以合理的支持体系、完善的知识储备、过硬的专家能力完成这些问题的解决,以实现我们技术服务的交付,也就实现了护航保障。中台的立足之本是技术能力,但也需要有一定的商务思维,同时也需要有成体系的服务能力。中台对前直接承接来自于客户或者前台的技术问题或业务需求,并闭环其中大
254、部分;对后则主要是以前线业务视角出发和产研同学沟通解决技术问题或落地需求,解决剩余的问题。后台:产品后台的定位是提供云产品层面的深度保障,以彰显在该产品领域的深厚积淀。后台需要在云产品细分领域有一击必中的技术能力和全面深刻的技术理解,代表着在这个细分领域的最高能力。后台因为距离前线较远,对客户业务、整体架构、系统运转等可能不太熟悉,但必须对自己的细分领域极为擅长。一个合格的后台需要实现:在所有需要该细分领域介入的问题,在这里都可以得到最终的解法。后台和中台一起组成了技术服务T型模式的一横和一竖,后台深钻技术深度,中台则专注于技术广度,两者组合构成了坚固的技术能力。前中后台的协同一起构成了完善的
255、技术服务体系,所有客户的问题由业务前台进行统一收口和快速响应,然后分发到技术中台进行通用处理,技术中台利用其技术广度和技术积累妥善的解决问题,当需要深度细分领域知识时,则调用产品后台进行深度的技术研究。以此模式,为客户提供快速、专业、深度的保障服务。云上大型赛事保障白皮书 1297.1.2 北京冬奥保障阵型在冬奥之前,我们与北京冬奥组委签署保障合同方案,其中规定了详细的保障机制和流程,在具体操作过程中,我们成立了对应的前中后台团队进行东西向服务分层,各团队基于业务影响进行南北向的服务分级,并组建了管理层应急响应小组做为最终的决策层,具体的保障阵型如下图所示。下面从前到后再对不同的团队进行逐一介
256、绍。客户:不同的奥运客户实体,基本都会使用奥组委指定的ITSM工具联系到阿里云的保障团队,但阿里云提供的接口不同,例如:北京冬奥核心系统客户,会反馈至工作在北京冬奥组委技术运行中心(TOC)的阿里云TOC驻场保障团队;国际奥组委项目群(OBSOCS等客户),对于来到北京的OBS,会反馈至工作在闭环主媒体中心(MMC)的阿里云MMC驻场保障团队,其余则通过ITSM工单系统或阿里云国际站工单系统反馈至阿里云技术中台保障团队。图:北京冬奥阿里云保障团队组织架构图130 云上大型赛事保障白皮书云上大型赛事保障白皮书前台团队:工作在北京冬奥组委技术运行中心(TOC)和闭环区主媒体中心(MMC),现场服务
257、在TOC和MMC的奥运客户实体。在TOC的现场保障团队又区分为不同的角色:值班经理(Duty1Manager)负责保障过程的整体把控、监控资源盯屏和云产品变更审批;技术专家(Technical1Specialist)负责承接客户反馈的ITSM工单和紧急配置变更,并针对需进一步处理的问题发起阿里云内部处理流程;运行经理(Operation Manager)负责技术问题的响应升级、对客沟通和后场报障;运行专家(Operation Expert)负责现场的技术问题深入排查、前后场技术串联,是现场保障团队的技术兜底;安全专家(Security Expert)DCDN专家(DCDN Expert)则针对
258、于具体的安全产品和DCDN产品提供产品方保障,这是由于此两个产品为奥运云上架构下最容易产生大规模故障的产品线;Info AV值班经理则是为一个比较特殊的IOC创新项目Info AV系统专门安排的一个现场支持岗位。前台团队的主要职责是为客户提供快速响应和现场服务,提升奥运客户的服务体感,对定位至阿里云侧的问题快速拉通中后台团队介入处理。图:TOC驻场前台团队各角色定义(无Info AV值班经理)1 现场一号位现场负责整体与组委合作伙伴沟通,紧急情况协调内外资源应急2 监控钉盘-主负责钉盘,若发现潜在异常,及时拉通相关资源做排障。3 阿里云平台变更封网情况下紧急变更技术部审批协调1 中台重保接口人
259、中台重保接口人,收敛所有支持请求,紧急场景下进行保障。确保对应问题在SLA内完成解决2 问题解决负责问题分析和推动问题升级。确保支撑体系顺利运转。3 变更服务请求运维变更执行1 问题排错对于现场技术问题的及时排错并联动后台AES专家产研做问题的及时处理和 解决2 钉群告警应急基础产品告警,进行响应和首轮排错,若需要拉动产研团队,自行联系后方排错(赛时借助云鼎)1 工单承接主负责所有阿里云工单在SLA范围内的承接。和上游工单提交者沟通,跟进,知道关单。2 监控钉盘-备作为钉盘的backup,保证异常信息及时触达。3 变更服务请求运维变更执行1 安全告警处置负责安全监控并保证安全告警及时得到处置和
260、解决2 安全应急各种安全突发场景下,执行对应预案保证系统安全运转云上大型赛事保障白皮书 131中台团队:在北京冬奥,阿里云技术中台团队的名字叫做OCOC(Olympic Cloud Operation1Center),OCOC团队定位为整个解决问题环节中的技术中台,处理来自于TOC和MMC现场团队升级的问题,并直接处理无现场服务的奥运客户的问题,工作在阿里云的北京望京园区和杭州飞天园区。OCOC团队是服务阵型中承前启后的一环,来自于前台团队流转的阿里云侧问题绝大部分在OCOC团队闭环,OCOC团队通过内部问题管理系统对问题响应、问题处理、问题排查解决、风险上报、故障应急等进行持续跟踪和闭环处理
261、,确保整体SLA达成。同时,OCOC团队建立了奥运客户所有云产品的告警与监控机制,设计了相应的告警应急预案,当告警发生时,通过标准告警应急预案进行处理,设计了垂直技术应急预案,当发生不同云产品突发情况时,通过标准垂直技术应急预案进行处理,以此确保云上环境运转正常。在特定情况下引入后台团队,即:当紧急情况发生时,引入安全生产团队;当需要产品底层原理排查时,引入产品研发团队。OCOC团队主要由阿里云全球技术服务部专家服务团队(GTS-AES)构成,之前护航过阿里云所有重大活动,例如双十一、双十二、云栖大会等等,经验非常丰富。后台团队:即安全生产团队和产品研发团队。安全生产团队负责处理产品侧的重大故
262、障,及时引入对应的产研团队,在发生故障的情况下主导故障应急;产研团队则是整体服务阵营中人数最多的团队,这是因为客户使用了60+款云产品,而每款云产品都需有对应的冬奥保障团队。具体来讲,从研发侧,一共有基础产品事业部、基础设施事业部、数据库产品事业部、流量产品事业部、计算平台事业部、产品解决方案与大网站事业部等六个部门参与,覆盖北京冬奥全量奥运客户所使用的所有云产品。产研部门除了主导云产品侧的问题处理,还研发了不同的云产品层实时监控,做为整体监控系统的一部分发挥作用。对于TOC现场客户产生的具体问题,其服务流程如下:客户向技术运行中心现场团队提交ITSM工单,或面对面交流提出问题。技术运行中心现
263、场团队依据SLA响应工单,确认事件描述,如果不能解决,就升级给远程OCOC团队。远程OCOC团队会和TOC现场团队通过钉钉密切协作。132 云上大型赛事保障白皮书云上大型赛事保障白皮书如果需要云产品团队介入,OCOC团队会引入产品团队。当紧急情况发生时,则还会引入安全生产团队。任何对业务有重大影响的紧急情况都可能导致SLA违规或引起负面舆论,立即上报给管理应急决策小组。管理层应急响应小组将对紧急情况的处置做出决策,并和北京冬奥组委管理层保持密切沟通,包括技术运行中心主任。对于MMC现场客户产生的具体问题,其服务流程如下:客户向主媒体中心现场团队提交ITSM工单,或面对面交流提出问题。主媒体中心
264、现场团队依据SLA响应工单,确认事件描述,如果不能解决,就升级给远程OCOC团队。远程OCOC团队会和TOC现场团队通过钉钉密切协作。如果需要云产品团队介入,OCOC团队会引入产品团队。当紧急情况发生时,则还会引入安全生产团队。任何对业务有重大影响的紧急情况都可能导致SLA违规或引起负面舆论,立即上报给管理应急决策小组。管理层应急响应小组将对紧急情况的处置作出决策,并和国际奥组委管理层保持密切沟通。对于线上奥运客户产生的具体问题,其服务流程如下:客户通过ITSM系统或者阿里云国际站工单系统向OCOC团队提交工单。如果需要云产品团队介入,OCOC团队会引入产品团队。当紧急情况发生时,则还会引入安
265、全生产团队。任何对业务有重大影响的紧急情况都可能导致SLA违规或引起负面舆论,立即上报给管理应急决策小组。管理层应急响应小组将对紧急情况的处置作出决策,并和客户管理层保持密切沟通。云上大型赛事保障白皮书 1337.2 云上大型赛事流程管理我们为客户提供的保障,其本质就是对客户的业务问题或业务需求进行一一解决。而如何去以标准化的方式处理这些问题,则需要合适的流程管理,本小节讨论云上大型赛事的问题处理流程。7.2.1 基于业务影响的流程分级一个核心的思想就是基于业务影响进行流程分级,根据对客户业务的影响,分为普通问题和故障问题。普通问题包括咨询类、配置类、通用类问题,无业务影响,不会产生客情;故障
266、问题则通常代表客户业务受影响,包括核心业务不可用、核心业务受损、非核心业务不可用、非核心业务受损等场景,故障问题需要用最快的速度止血处理。7.2.1.1 普通问题处理对于普通问题,可按照上一节描述的前中后台服务分层模型进行支持,由前台快速响应,由中台进行通用问题处理,由后台提供细分领域的深度知识。对于较为复杂的普通问题,可以采用下面的一些通用方法论来拆解,以便更好的进行处理。7.2.1.1.1 问题管理之一:4W1H方法定义清楚一个问题能定义清楚一个问题,就指明了通往解决它的路。有时候客户的问题描述或者需求描述比较模糊,就需要我们彻底理解客户的问题,否则在错误的道路上左冲右突,就会事倍功半。如
267、果对客户的问题还不够理解,那么就问他下面几个开放式问题,当这些问题有了答案,一个详细的问题描述就出来了。134 云上大型赛事保障白皮书云上大型赛事保障白皮书Who,谁发生的问题。What,什么发生了问题。When,什么时候发生的问题。Where,在哪里发生的问题。How,如何发生的问题(问题现象)。7.2.1.1.2 问题管理之二:对比法找到复杂问题的切入点对于比较有技术难度的问题,做一做这几个对比,可能就找到了解题的线索WHAT:是什么对象发生的问题,为什么不是其他对象WHEN:是什么时候开始的,为什么之前没有发生/发生概率是必现还是偶发以及为什么WHERE:在哪里发生/什么条件下发生,为什
268、么不在其他地方/其他条件下发生EXTENT:严重程度如何/影响面多大,为什么是这个程度/影响面普通问题,因为没有业务影响,可基于技术驱动,用抽丝剥茧的方式把它做重,每一步力求专业、稳重、有深度、经得起推敲和检验,这样的处理方式可彰显我们的技术优势和能力沉淀,从而影响客户心智。7.2.1.2 故障问题应急云上大型赛事一旦产生故障,其带来的负面影响不可估量,甚至可能会有政治性影响。对于故障问题,必须争分夺秒处理,和时间赛跑,因此基于前中后台的把服务过程做重的普通问题处理思路已不再适用,必须设计专门的短平快的故障应急流程。7.2.1.2.1 故障应急流程之一:故障上报及通报在感知故障的第一时刻,由前
269、线上报故障,并迅速拉齐所有的相关方一起实时讨论,这里的相关方指客户、前线、中台、产品、决策层等。前线需要能及时准确的传!云上大型赛事保障白皮书 135递当前情况,中后台需要能快速的给出技术止血方案及优劣势,供决策层决策。在每一个重大进展节点,例如故障发现、决策止血方案、实施止血方案、故障恢复,需要及时同步到各相关方,做到信息的一致性。得益于阿里云的技术风险建设,我们有专门的故障处理工具云鼎,该工具可以基于故障情况,一键创建故障应急协同群,引入故障应急值守人员及决策者,并把当前进展及时通报给内部所有相关方,做到信息实时同步。7.2.1.2.2 故障应急流程之二:故障应急原则故障应急的第一原则为止
270、血快速,即如何以最快的速度把故障抹平恢复业务,具体的问题根因可留待之后详细排查,应急处置过程中以恢复运转为第一要义。举一个简单的例子,当发生流量突增触发EIP限速引发丢包导致业务受损时,不必详细排查流量突增的原因,第一件事一定是先把EIP的带宽升配。故障应急的第二原则为协同,故障的应急处置可能需要多个产品方参与,在这个过程中,各产品方需要协同合作,不仅仅考虑自己的细分领域是否故障,也需要有整体框架思维,以协同的方式一起参与快恢。阿里云的应急协同工具云鼎,提供了产品化的故障应急协同相关能力,确保故障应急的高效、有序和透明。在一键拉起的故障应急协同群,提供了便于应急的签到响应、应急作战室、电话会议
271、、邀请排查等相关功能,同时还提供了舆情聚类平台、GOC应急工作台、应急基础信息、应急看板作为底层支撑。7.2.1.2.3 故障应急流程之三:故障复盘复盘源于围棋术语。指对局完毕后,复演该盘棋的记录,以检查对局中招法的优劣与得失关键。当故障发生后,如果不及时去对故障的根因和处理过程进行复盘,很难保证下次类似的问题不会出现甚至扩大化,所以故障复盘对于故障应急流程非常重要。复盘过程包括:过程回溯,即抽丝剥茧的检查本次故障发生原因、处置过程中各136 云上大型赛事保障白皮书云上大型赛事保障白皮书!个团队如何处理、处理流程是否可以再优化等;问题剖析,即深层次剖析问题根因,是客户侧问题还是产品侧问题、有没
272、有优化点、如何防范再次发生等;经验总结,即给出可落地的短期治标Action、长期治本Action、以及沉淀经验和教训等。7.2.2 北京冬奥应急流转流程依据北京冬奥组委的整体技术运行计划,此次保障的SLA如下表所示。由于奥运业务的极端重要性,因此本次SLA制定的非常激进和严格。对于最高等级的P1故障,要求在1个小时内解决。因此我们精心设计了前中后台的角色和流程,确保任何级别的问题我们都可以在SLA内处理。针对于服务请求和P4问题,我们定义为普通问题,针对于P4以上问题,我们定义为故障问题,对于故障问题,我们采用了在上一小节所阐述的应急流程,基于协同工具云鼎进行快速的故障应急处置。具体的应急流程
273、如下图所示。具体的应急流程如下图所示。严重等级严重等级1(P1)严重等级4(P4)服务请求严重等级3(P3)严重等级2(P2)响应时间5 分钟1 小时1 小时30分钟5 分钟解决时间1 小时6 小时8 小时4 小时2 小时云上大型赛事保障白皮书 137在实际操作中,会由前线和中台协同进行上报和主导故障排查。因此,对OCOC中台团队,我们制定了详细的普通问题和故障问题的处理流程,如下图所示。我们根据业务影响来决定我们的服务行为,是做重按照抽丝剥茧的方式来体现技术深度,还是做轻按照短平快的方式来体现服务响应能力。图:故障应急流程138 云上大型赛事保障白皮书云上大型赛事保障白皮书在整个北京冬奥保障
274、过程中,我们全部满足了约定的SLA,没有发生服务风险。图:技术中台(OCOC)团队视角问题流转流程云上大型赛事保障白皮书 139第八章 未来展望未来的大型赛事,应当是什么样子?2021年3月13日,国际奥委会一致通过了奥林匹克运动新的改革路线图奥林匹克2020+5议程10。在原有的奥林匹克2020议程基础上,新增的15条改革建议旨在未来五年更好地应对后疫情时代的挑战。巴赫主席在会议中表示:新冠疫情彻底改变了世界,这个世界已不可能再像之前那样。即使我们最终克服了这次健康危机,我们仍将面临深远的社会、金融、经济和政治方面的影响。作为奥林匹克运动的领导者,我们必须为这个新世界做好准备。为了塑造我们的
275、未来,我们需要对这个新世界提出愿景。其中很重要的一个愿景,就是要抓住科技的发展,增强奥运会的独特性和普遍性,促进可持续性的奥运会。“进一步通过创新和新兴技术(如增强现实和虚拟现实、云服务、5G、人工智能和数据分析),执行以运动员为核心的高质量奥运会转播。”随着新兴技术不断发展,奥运会传播方式也在不断演变中。我们可以抓住这一机遇,向世界各地传播奥林匹克价值观,让人们能够以前所未有的方式体验奥运会。我们要抓住演变/变革的机会,让所有人都有机会以不同的方式与运动员近距离接触,感受到他们身上所传递的积极的精神。这一系列的挑战和愿景都可以通过云上的数字化和智能化的方式来解决和实现。在云上,我们提供更多连接、更加高效、更加安全、更多协同的数字化创新能力。这些数字化创新能力,则将为大型赛事、体育行业创造出新的机遇和价值,实现他们的愿景。未来已来,大型赛事系统上云已然成为趋势,技术的发展和创新之路不断向前。任重道远,期待作为技术人的我们可以携手并进,砥砺前行,共赢未来!140 云上大型赛事保障白皮书云上大型赛事保障白皮书10 Olympic Agenda 2020+5https:/