1。背景B站每年都会举办很多大型活动，比如拜年、最美夜、LOL全球总决赛、电商626、919秒杀等活动。其中，最美丽的夜晚和LOL全球总决赛是在线流量最高的赛事。S11总决赛期间，整个站点运行平稳，没有发生基础设施故障、组件故障、服务核心链稳定性故障。它承受了远超预期的在线用户数和流量。一场成功的赛事离不开多个团队的共同努力和付出。SRE如何支持和保障这些活动，并不断完善我们的活动保障体系？接下来就为大家揭晓。二、活动场景案例1SRE某活动保障期间，突然听运营同学说，微信、今日头条等APP会在某个时刻推出该活动的推广链接。考虑到微信和今日头条APP的用户规模，SRE担心新用户的到来会对基础资源和业务服务造成影响。不过由于事发突然，短时间内大家不可能预测到下一级用户。好在最终推广带来的用户增长有限，并未影响活跃度。案例2在一次活动的前期沟通中，SRE从研发方获悉，运营会在活动期间对站点所有在线用户进行站内推送：在app内向所有用户推送一个弹窗谁打开应用程序。这种方式将很快被推送给数千万在线用户。如果用户点击活动链接，瞬间带来的流量会压垮活动业务，甚至给我们的基础设施带来压力。在与运营方和研发方确认后，SRE认为这个方案风险太大，最终取消了。案例三：SRE某事件保障期间，流量高峰顺利通过，事件保障进入收官阶段，大家准备收拾下班。突然多个服务告警，服务不可用。SRE紧急介入调查，发现运营在事后进行推送，导致用户在一个不活跃的环节集中访问服务。该服务未纳入赛事保障范围，导致容量过载，服务不可用。类似的案例还有很多。因此，对于SRE来说，要保证赛事的成功举办，除了技术支持和与研发的沟通外，还需要主动与运营和产品确认赛事形式、玩法、对外宣传方式等。SRE必须更贴近业务。.SRE目前收集有关该事件的以下信息：1。事件的形式。活动的具体玩法是什么：无论是直播间，闪购，还是互动等等，不同的玩法需要保障的业务场景是完全不同的。2.重点场景是同一个活动，但重点场景可能不同。比如某场直播的重要场景是在线人数和弹幕，而另一场直播的核心可能是用户礼物和抽奖。了解关键场景，可以指导SRE跟进研发，共同构建服务端保障的关键预估在线数。3.预估在线人数本次预估在线人数是多少，如何预估。在线号码转换的路径有哪些。4.活动外链WEB和APP中的活动入口是什么？车站外有哪些排水口？只有了解用户访问路径，SRE才能保证整个链路的可用性。5、事件推送有多少个推送？交货形式是什么？什么是用户转化率？6、活动结束后的活动场景有没有特殊行为，比如直播间自动跳转到点播页面？活动结束后会有哪些运营事件和次要热点？这些事件对应的用户访问路径和服务都需要SRE来保证，否则就无始无终，不管结局如何（这是血泪的教训）。7.时间线活动前期上线、对外宣传、预热的时间线。活动开始、推送、抽奖、口头直播、结束的时间线。3.资源准备根据上一步运营和研发了解到的活动内容，我们已经知道本次活动的预估在线人数。根据在线人数和历史活动的容量数据，我们可以初步预测本次活动所需的资源。SRE将资源分为两类：基础资源和业务资源。1.基础资源主要是基础设施对应的资源，如下。一般需要确认CPU资源和带宽资源：DNSDCDN（动态CDN）静态CDN带宽直播弹幕带宽高防源站四层LB源站七层SLBWAFIDC-云专线带宽IDC间专线带宽NATbandwidth网络硬件带宽log/monitoring这里解释一下最后两项：1）在log/monitoring活动中，大家特别关注监控数据，需要根据监控数据来执行方案，所以监控的保障是非常重要，需要纳入SRE的管理；与日志类似，在活动过程中，各种数据查询、用户行为、业务异常等也需要稳定在日志系统中。2）网络硬件带宽由于活动期间业务流量的爆发，在历史活动中曾出现过网络硬件设备带宽突然爆满的情况。所以对于业务的核心环节（机房入口—>业务APIGW—>存储服务—>基础设施）也需要确认这一步。基于以上资源，将按以下格式确认信息：对应时间点的已用容量和当前已用水位，弹性扩容计划的原因，预定扩容后的水位.在梳理了以上信息后，SRE和基础设施团队确定了后续的扩容方案，SRE对基础设施资源有了一个整体的把握。接下来SRE会和业务团队确认业务资源情况。2.业务直接使用的业务资源PAAS、IAAS、缓存、DB资源等。一般需要确认的资源有：PaaS（容器资源）IAAS（裸运行物理机资源）CACHE中间件MQ中间件KV存储DB存储SRE搭建了容量管理系统，可以快速获取整体容量和业务部门资源的使用水平，可用的剩余Buffer等数据，用于确认活动所需的资源缺口。业务资源通过购买机器或混合云得到满足。资源准备好后，交付业务或交付给平台进行扩展。业务在使用时，可以动态扩展或提前扩展。之后通过性能压测来验证预估是否达到预期。四、压测&演练1、性能压测每个活动开始前都会对业务进行多次压测，一般分为三轮。第一轮：根据现有系统资源压力，发现系统瓶颈和需要优化的项目（部分活动可能没有本轮）第二轮：根据活动目标进行资源投放、业务拓展、服务优化和压力测试（每个活动都会有本轮）第三轮：优化方案和保障方案全部上线后，再次进行压力测试，验证方案的有效性和最终的服务能力。过了这个时间，非必要的需求将不再推出。在每一轮压力测试中，SRE的关注点是不一样的。1）第一轮重点关注压测工具和压测链路是否稳定，是否满足事件压测要求；比如扩大压力测试肉鸡的产能；调整电流限制以避免拦截压力测试流量。发现存在性能瓶颈的服务和接口，与研发一起分析瓶颈。确认中间件是否存在性能瓶颈，如Redis热KEY、DB热SQL。跨部门发现上下游服务环节瓶颈。本轮压测的重点是针对压测工具本身和业务服务的性能瓶颈，与研发一起确定后续的改进方案。2）第二轮主要看活动目标能否达成。关注基础设施资源容量水位，确保安全。关注商业资源，确保安全。关注整个链路的上下游服务瓶颈和中间件瓶颈。会进行多轮压测，中间多次优化，直到达到活动目标，容量水位安全，依赖服务不再成为瓶颈。2）经过二轮压测，活跃业务系统基本满足要求。SRE会和R&D确认各个业务模块和接口的限流配置，讨论限流执行的层级：七层SLB，业务APIGW，服务框架层和服务框架层都可以支持限流配置。我们的最佳实践是：服务框架为活动的预期流量配置一个限流阈值，然后根据活动的实际峰值压力动态调整。APIGW配置了一个比服务框架宽松但保证服务不会过载的限流阈值。SLB配置了用于保护APIGW的限流阈值，一般为APIGW限流阈值的两倍以上。第二轮压测时，活动部一般会针对自身业务场景进行压测。但活动也会给其他基础系统带来压力，比如搜索、账户、支付等，此时SRE会跨部门协调这些业务团队也进行压力测试，确保各个系统的容量是安全的并且万无一失。第二轮压测结束后，各项保障计划也将确定配置上线时间。3）第三轮第三轮压力测试不是必须的。对于第三轮压测的业务，常见的场景有以下三种：比如S11，1/8决赛和1/4决赛。对系统进行压力审核，同时验证总决赛前业务上线的需求表现。各种上线保障方案上线后，再次进行压测，确保系统运行符合预期，如：HPA可自动扩容、各种限流生效、多房分流符合预期等。对业务进行限压测试，观察业务的限流瓶颈，评估业务系统期望支持的在线用户数上限。如果业务支持的在线用户数上限较高，则会为业务设置超过预期在线用户数的限流配置。本轮压测中，SRE重点关注上线保障方案是否有效，方案是否符合预期，第二轮业务压测结果能否在本轮延续，各项方案是否需要进行调整。2.演练这里的演练是指计划演练和故障演练。这里我们重点介绍故障演练。B站的故障演练，即ChaosEngineering，2019年在SRE开始建设，基于阿里开源的chaosblade工具构建，与内部平台集成。目前支持：节点级故障：既有PaaS环境下的K8S节点，也有裸机运行业务的物理机IaaS环境。硬件资源竞争：节点CPU负载、内存占用、磁盘满满、网络异常上下游故障：服务间调用延迟、丢包、故障中间件故障：服务调用中间件，如CACHE、KV存储、DB、MQ等延迟、丢包、故障目前的混沌工程平台不仅提供了面向研发和QA的控制面故障注入能力，还提供了集成到自动化故障测试中的API能力。基于搭建的混沌工程平台，SRE与多个业务部门进行了多阶段故障演练和自动化测试，例如：直播业务S11核心场景故障演练UGC业务场景中间件依赖故障演练OGV业务场景上下游应用依赖故障演练MessagingTeamSpecialFaultDrill针对电商业务场景的自动化故障测试...共进行了3000+次故障演练，发现了200+个服务隐患，对提高服务可用性有非常显着的效果.发现的典型问题如下：服务本应弱依赖下游服务，却被编码成强依赖。服务调用下游服务失败后，熔断或降级方案未按预期生效。当服务调用缓存超时或异常时，接口失效，导致用户请求。服务调用消息队列失败，导致用户写操作失败。。。对于大型事件场景，我们演练过的失败场景也是类似的，如下：是强弱之间调用上下游服务失败的服务合理吗？,熔断机制是否有效。服务调用中间件失败是否有中间件降级方案，降级方案是否生效。服务所在主机节点的故障验证了服务是否有状态，是否可以接受单点故障。ServicePODfailure，POD中的sidecarfailure，验证平台的failover能力是否达到预期，主容器对sidecar的依赖是否合理。服务POD的CPU负载注入验证服务的HPA策略是否生效，HPA策略是否合理。通过故障演练，SRE不仅保证了服务的容量和性能，还进一步提升了服务的可用性，提前发现了服务架构中的薄弱环节，验证了方案的有效性以及监控和监控的准确性。令人震惊。5.以史为鉴在梳理我们的支持能力之前，SRE会先查看《以史为鉴》链接的内容。SRE会将之前事件保证中所做的不好的事情总结为历史教训，形成检查表，确保本次事件中同样的问题不再发生。我以后不会再这样做了。活动期间，线下混音并未关闭，对突然爆发的线上服务有一定的压力。为了以后的活动，线上核心业务场景下机器的离线混音任务要关闭。活动期间关闭K8S的VPA策略，避免活动期间服务压力增加，导致第二天服务请求增加，资源池无资源可调度。Activity的核心链路上有服务没有开启HPA，需要在Activity中手动扩容，效率低下。.....通过checklist模式的确认，SRE可以保证不会再出现同样的问题。这种模式类似于谷歌SRE中提到的《发布检查列表》。6、技术支持我们常说业务高可用，也常说服务可用性得到提升。是业务幸运没有出现问题，还是我们的技术支持能力避免了业务问题？SRE有哪些方法、能力和方案来保证服务的高可用？下面是我们一些核心组件的业务支撑能力盘点。1.DCDN1）CDN缓存如果业务可以接受一定的数据延迟，可以在DCDN上增加一个接口缓存来降低源站的服务压力和带宽，比如视频弹幕列表、直播礼物道具等。2）多活业务的多机房通信B站在DCDN层面实现同城双活业务调度。对于支持同城双活的业务，DCDN可以动态调度多个机房的流量配比。如果某个机房的服务出现问题，用户流量可以快速切换到其他机房。2.七层SLB1）全球限流B站的七层SLB是基于OpenResty和部分自研功能实现的。前面提到，SLB的限流能力主要是为了保护服务APIGW不会过载。对于没有APIGW的服务，SLB限流直接保护服务不被过载。2）多机房或服务故障自动降级如果单机房多机房出现问题，为了快速止损业务，切换到其他机房是最快的方案。如果在DCDN层面进行切片，需要手动进行切片操作。目前，执行时间约为5分钟。为了实时止损，SLB会寻找服务于所有机房的节点。如果某个机房的某个节点无法处理请求，SLB会自动将请求降级到其他多活机房/可用区。该降级能力目前需要手动开启，适用于已全面实现同城双活的业务。对于活跃场景的核心请求，SRE会提前和R&D沟通，在SLB上配置这个降级能力。这个自动降级的功能也是后来在APIGW的功能中实现的。实现原理比较简单，如下：3、WAF1）可以配置单个IP限频，在一定时间内访问量超过限制后，对单个IP屏蔽某个URL或域名。时间，一般用于接口防刷，用于保护服务器，提前拦截无用的请求。2）恶意IP封禁可以根据请求的某个特征，比如UA或者Referer，来封杀活动中的刷机用户。4.PaaS1）HPA横向扩展：Horizo??ntalPodAutoscalerPaaS平台构建于K8S基础之上，支持基于CPU、Memory、GPU等服务化指标的弹性伸缩。有些活动时间会比较长，流量增长会比较平缓，比如LOL游戏直播，很适合加入HPA策略，这样可以根据压力动态扩展服务容量。在一些事件场景中，比如电商手把手销售，事件时长是秒级的，可能事件已经结束，但是HPA还没有展开生效。这种场景不适用于HPA。而是提前扩容，配置限流阈值，做好容量保护。2）VPA纵向扩展：VerticalPodAutoscaler资源池的可调度资源总量有限。如果活动期间有临时业务扩容或触发HPA扩容，则资源池没有资源可调度。这个时候需要出个bug，不然不就无法处理业务扩展了吗？这里强调一下VPA的重要性（VPA的概念可以参考K8S文档，这里不再赘述）。一般情况下，线上业务资源利用率较低，CPU使用率峰值不会超过40%。只要资源池的整体CPU使用率是安全的，我们就可以动态调整服务请求，释放资源用于其他服务调度。这就是超额认购/超卖的逻辑。上面提到了SRE的容量管理系统。该系统还支持VPA管理和PaaS服务的动态执行。一个VPA策略的核心配置例如是：选择一批服务，根据该服务在过去一天的cpu使用率的99点位值，设置cpu_used/cpurequest*100%=50%；该政策可以立即发布。只要资源池的整体CPU使用水平是安全的，SRE可以在服务没有可调度资源的情况下，通过VPA能力快速释放可调度资源，大大提高了SRE容量管理的灵活性和可控性。3）如果混合云的资源池整体CPU使用率已经达到50%，此时不宜使用VPA能力继续超分。SRE会预留一个基于云的K8S资源池，供业务扩展使用。如果IDC资源池容量不足，可在10分钟内完成云K8S节点初始化，加入云资源池进行调度。5.Cache1)CapacityGuarantee数据层扩容一般需要很长时间。建议业务在之前压测的基础上，提前扩充足够的容量。如果需要紧急扩容，SRE建议临时增加单个节点的内存大小，尽量避免扩容节点。redis扩容节点时，槽的迁移对业务影响不大。2）HotKEY和bigKEY监控如果服务使用了Cache代理，在代理端可以通过埋点数据发现hotKEY和bigKEY。如果服务直连Redis，可以使用Redis平台临时采样抓取一段时间的请求，分析热点KEY和大KEY。6.DB1)服务降级在主从延迟比较大（大于120秒）时触发DBA的自动降级保护逻辑，牺牲部分宕机场景（最大1s）的数据一致性，提升从库性能。2）异常拦截服务接入DBproxy后，支持异常SQL黑名单拦截。通过该能力，慢SQL多次被在线快速拦截，快速止损业务。3）负载均衡将其他机房的从库加入读负载，暂时提高读请求的吞吐量。7.监控大市场SRE联合监控和业务研发，做了一个全链路的活动监控Dashboard，一般包括业务大数据、基础资源容量、业务监控、中间件监控等数据，内容会是根据具体活动进行微调。这块大板将用于赛事现场保障期间的现场投影，大家随时关注监控大板中的异常情况。上述支撑能力是我们支撑体系核心能力的一部分，完整的能力在此不再赘述。SRE也会和业务研发团队一起对业务架构的技术支撑能力进行盘点，这里不再赘述。通过以上技术支撑能力的梳理，SRE可以清楚的知道我们目前有哪些能力来保证活动的稳定性。SRE在盘点这些技术支撑方案后，也会全面提升SRE自身的能力。7.预案能力如果活动中出现异常或故障，SRE或业务研发团队应该如何选择相应的技术支持能力，或者在紧急情况下如何处理？提前盘点规划能力也很重要。该计划是着重于出现问题时快速止损的能力。技术支持能力与事前策划能力的区别在于：前者关注问题发生前，后者关注问题发生后。下面列出了SRE在主动保证中关注的一些重要故障场景。以上计划只是SRE侧计划的一部分。除了基础架构和组件方案，SRE还会和业务研发团队一起梳理业务端的方案。业务端计划分为两种：业务熔断、降级、限流等高可用计划活动。产品体验方案和技术方案，这里多说说。常见的预案包括：减量、降级、限流、回滚、重启、扩容等。在确定应急预案的优先级时，应考虑以下几个方面：概率：优先考虑TOP3故障场景的应急预案。有效时间：有效时间越快，止损效果越好。是否有害：方案是否对业务有害，优先考虑损失较小的方案。复杂性：计划执行的复杂性。幂等性：计划多次执行的结果是否相同，优先选择不确定性较小的计划。8.回顾与改进大型赛事结束后，SRE将组织各战队对赛事进行回顾与总结，如S11总决赛。SRE会提供一个活动回顾模板，大致如下：1.项目目标对于这次xx活动，SRE团队的目标是：第一，xx活动不应该出现主流程事故。其次，相关业务不得存在主工序事故。此外，不会发生基本的技术事故。2.流程回顾在这个阶段，我们的核心目标是对活动开始前的筹备阶段进行回顾和总结。不要只在活动期间和活动结束后进行回顾。活动筹备阶段也有很多有价值的优化改进项目。3.数据汇总该阶段汇总了活动中的一些核心数据，如最终在线用户数、基础资源使用能力水平、业务资源使用能力水平等。数据有两个重要用途：用于SRE容量预估后续活动。基于数据曲线的挖矿活动中的一些意外行为，例如带宽峰值、流量峰值等。4.问题回顾在这个阶段，SRE会记录活动过程中出现的问题，做出回顾总结，并确定后续的改进方案。SRE会跟进事件保障中产生的Todos，定期确认进度，确保优化方案落地。5、反思与总结在这个阶段，SRE会对整个活动保障项目的优缺点进行思考，进行整体反思。比如事件发生后的资源回收，目前还没有做好，以后需要加入到事件保障流程中。同时，我们将重点更新事件模板中基于历史记录的清单和其他内容。9.总结与展望对于SRE来说，参与一次活动支持可以快速了解整个系统的基础设施、组件能力、技术支持、应急预案、应急响应等，个人技术和综合能力将得到极大的提升。大型活动也是对基础设施和技术支持的大锻炼。通过上述赛事保障体系，SRE成功保障了B站近几年的所有大型赛事，其中包括上线的千万级用户S11总结赛，流量远超预期。在目前的保障中，一些保障措施还没有自动化，人力消耗大，比如基础资源的梳理。未来，保障体系中的人工工作应该沉淀到赛事保障平台中，让SRE更高效地保障大型赛事。
