一年一度的双11活动已经成了一个全民狂欢的节日。
这一天，如何应对运营的各类指标压力，保障业务系统关键时候不挂，又成了研发和运维同学的梦魇。
临时抱佛脚肯定不行了，还是需要系统性的思考和组织相应的人力进行专项保障，本文就来看一下网易是怎么做的。
一、提前资源准备
01. 容量规划
以做“双11”电商活动为例，对SRE团队的容量规划进行方法剖析。
假设产品运营团队规划的量是平时水位的5倍峰值，在传统运维的跟进模式下，开发团队因为有绩效压力，很多时候会多估计服务器需求。因为类似“双11”的电商活动一般会是整个团队绩效考核的核心，每个模块的团队都会被下发容量指标。
以支付模块为例，在8月时单台云主机处理能力是50qps，而在“双11”时其处理能力就是2000qps。
在初期提服务器需求时，开发团队会理直气壮地提40台云主机的需求。传统运维团队只能被动接受扩容需求，而这种扩容需求很容易导致整体的服务器资源消耗失去控制。
怎么办？
SRE团队介入这方面工作时，使用的是另一种思路。
首先，SRE团队会和运营团队、业务团队沟通电商活动当前的推广情况，结合历史数据计算每个模块的性能指标。
一般情况下，只要整个团队有如图1所示的历史数据积累，那么每次电商活动的广告投放成本就是已知的，所以比较容易估计未来广告投放和用户趋势之间的关系。
图1 电商活动广告投放量和实际QPS关系图
通过评估用户增长和电商活动当天用户的激活比例，可以粗略估计全局的业务请求峰值。
其次，收集所有业务团队的服务器使用情况、服务处理性能，然后结合电商活动推广页面进行QPS指标细化。电商活动模块性能水位整理表如表1所示。
表1 电商活动模块性能水位整理表
通过对表1所示的信息梳理，可以看到实际每个模块的性能需求会有不一样的侧重点。
相比传统业务团队按照简单的峰值×5的容量评估方式，新的容量评估方式对容量水位的控制明显更加精细。这种依赖数据做决策的方式，在很大程度上解决了“人肉”评估带来的不确定性。
02. 技术优化
以电商活动为例， 当性能压测遇到一个问题涉及业务团队多个组件时，会发现同一个性能问题有多种解决办法。
这时SRE团队会通过评估多个组件之间的性能表现、暴露问题的多少、修复难易度等多种因素，协调多个团队进行修复。在这个场景下SRE团队扮演了问题协调者的角色。
电商活动的服务调用链路压测如图2所示。
图2 服务调用链路压测
一个服务调用链路在大流量压测时出现了请求错误率过高的问题，开发团队会发现链路上的服务都有改进的策略和空间。
就调用失败这个问题来看，从Service A的角度，可以用限流来解决Service B和Service C之间的错误率；从Service B的角度，可以将调用Service C的结果缓存起来，从而减少Service C的错误率；从Service C的角度，可以通过细化部分锁结构，提升线程性能，从而解决错误率的问题。
解决方案表如表2所示。
表2 解决方案表
三个层次的解决方案都具备一定的可行性，但在具体落地时就需要考虑时间和人力成本。因为有时在全局层面Service B、Service C会有其他需要解决的问题。
如果是项目经理（Project Manager，PM）来牵头负责，可能会直接按照解决速度、每个模块的问题数量开始排期，然后将其整理成类似表2所示的信息。
SRE团队则更多的是考虑具体方案落地时，资源是否够用的问题。
例如，在一个服务重要程度不高、用户重试无感知、网络等处理资源足够的情况下，选择Service A方案会更有利于项目进度。
当这个服务不能接受重试，但可以接受数据降级（如个性化实时推荐）时，显然Service B方案的缓存方案更有利一些。但是假设这个服务链路是一个资金查询链路，考虑到资金数据的高要求，一般情况下会推动Service C方案的落地。
从SRE团队的角度可以选择Service A的限流方案，既达到了整体压测的目标，同时推动Service C线程优化方案。
云平台（AWS、GCP等）的所有资源都有其极限指标，在一些重要业务活动压测时，有很大的概率会触发极限指标。
一旦发生这样的问题，如果是公有云平台，SRE团队会开一个Ticket给云平台的技术支持，要求跟进解决；如果是私有云平台，SRE团队会有更多的技术选项。
很多云平台的技术参数极限从某种意义上讲是一个不会出现问题的保守值。
例如，某些私有云的数据网关的文档标称处理能力是200万PPS（Package Per Second），但实际压测峰值可能达到250万PPS。这样的数据在内部私有云环境中并不少见。
当遇到应用出现这样的限定后，SRE团队也可以选择推动云平台调整极限参数限制来暂时满足需求。
SRE团队在整个重要业务活动准备过程中，在技术优化层面的参与度不比开发团队低，相比开发团队遇到问题喜欢选择使用新架构/新设计来解决问题，SRE团队更多的则是倾向于用成熟的解决方案去推动问题的解决
二、运营活动评估
如果对“双11”电商活动有两次以上的稳定性支持，你就会发现除容量、性能优化等事项外，更重要的就是业务的活动流程。
SRE团队和运营团队合作的评估模式如图3所示。每次这种关键投放都会提前确认投放的URL和投放量级，然后直接确认对应模块的容量设计。
图3 SRE团队和运营团队合作的评估模式
例如，提前投放的秒杀类活动广告，预计会有50万人被吸引，持续时间估计为30秒，按照经验粗略估计50%的用户会在5秒内点击。
可以计算出整个活动的5秒均值峰值是2.5万人，而活动开始第一秒的请求是均值的2倍，这样粗略估计出请求峰值为5万人。
因为大部分的运营团队本身对技术层面是缺乏了解的，所以很可能提出一些超出当前技术架构能力的需求。
例如，运营团队可能想让100万人同时访问一个页面，这个页面要求做到全动态实时数据，而整个团队支持的最大处理能力可能是全站最高70万人并发请求，这就属于明显不切实际的需求，可能有人会直接拒绝这样的需求。
从SRE团队的角度看，运营团队这样的需求是有一定回转余地的，如可以和他们沟通把这个页面分批投放给用户，将时间拉长到一个相对合理的值。
运营团队对这样的需求描述更多的是期望能达成的结果预期，技术团队完全可以通过了解对方的诉求核心，将系统情况反馈给他们。最终一般会通过接受部分活动效果损失等策略执行，确保整个系统的处理能力不超过业务本身的稳定性设计。
三、业务活动稳定性预案
在“双11”电商活动中，系统开始慢慢过载时，相信没有人有勇气可以直接调整某些参数了，即使有，也需要经过层层审批，审批人还需要承受巨大的压力。
基本上所有人都会感觉责任很大, 因此针对活动制定全面的稳定性预案就变得非常关键.
整个活动保障团队可以采用组织多团队交叉评审每个团队预案情况的方法。虽然这样的操作很消耗时间，但在工程实践上是非常必要的
举例：线上调用过载预案如图4所示。
图4 线上调用过载预案
如果以平时的运作模式，每个团队各自编写各自的预案即可，在独立执行时因为遇到的流量不会太大，所以很少有人觉得会出现问题。如果没有交叉评审，每个模块的开发团队都会觉得自己的预案非常完美。
但是当到电商活动时，这样的预案一旦和系统复杂性和联动性关联起来，各种问题就会在多团队交叉评审时被发现。一般情况下，在设计整个调用跨链路的预案时,应该遵循以下两种原则。
（1）限流优先级。
Service A > Service B > Service C
（2）扩容优先级。
Service C > Service B > Service A
从限流优先级来说，如果服务需要被限流，就应该在处理请求的入口模块开始限流，这样做能保护后端。
从扩容优先级来说，如果服务需要扩容，就是最后面的服务器需要扩容，先扩容前端大部分情况下会导致后端被冲垮导致扩容无效。
当然每个模块都有限流和扩容预案，只要协调好扩容或限流的节奏就可以。可以通知上下游团队，降低无效的扩容操作
四、重要业务活动的变更执行要求
对重要业务活动的稳定性来说，除标准的容量、预案外，还对整体的变更执行有严格的要求。
这些要求体现在以下几个方面。
（1）变更执行精度要求。
（2）变更执行顺序要求。
电商活动前执行流程表如表3所示，这是一个虚拟的变更执行计划表（真实场景中的电商活动执行表中的步骤会更加复杂，而且不同的电商活动会有不一样的做法）。
从稳定性管理角度看，电商活动前的变更和平时变更最大的不同是将多个子系统的变更统一协调起来，会做一定的间隔，防止变更之间相互影响。
粗略看上去可能有违“微服务”架构模式下推崇的解耦变更的理念，但背后是有其独特技术背景的。
表3 电商活动前执行流程表
如果在实际执行时能满足上面两个维度的变更操作要求，那么在稳定性上会有额外的收益。
在确定的时间做确定的事情，可以较好地控制执行结果，降低不确定因素。执行顺序确定后，程序化的操作能减少很多随意操作带来的不可控性。
SRE和研发如果能按照上述的方法和思路和做大促保障，会极大提升大促保障的稳定和成功率。
《大型网站运维：从系统管理到SRE》一书进一步详细阐述了如果做好大型电商的活动运营保障，助力你在后面运维和研发中，游刃有余。
*本文节选自《大型网站运维：从系统管理到SRE》一书，想要了解更多相关内容，欢迎阅读此书。
本书主要对传统运维和SRE进行不同对比，让大家了解运维工程师在实践SRE理念时，关注的点和具体的实践经验。本书的前半部分更多地注重SRE在实际工作中对融入开发团队、监控建设、变更管理、容量管理、异常响应、稳定性治理、事故复盘、用户体验管理等方面的实践和落地。
在对SRE的工作有了一定了解后，本书会针对重要业务保障场景进行实战讲解。本书最后部分对SRE工作中涉及的一些技术进行了概述，以便有兴趣的同学了解SRE相关的技术点。
