SRE关于大促保障的经验沉淀和思考

对于SRE来说，大促、尤其是双十一，是一年一度的沉淀系统、防止腐烂、摸清水位、剔除风险的最佳时机，所以一定要加以利用。对于团队的其他开发，大促是一次活动而已，对于SRE来说，大促是系统稳定性提升的过程，与其说是保障大促稳定，不如说是“借大促，修系统”。

所以，一定要转变思想，我们做大促保障，不仅是要“保持系统稳定性”的，更是要“提升系统稳定性”的。保持重在压测、摸排水位、限流、预案，而提升重在链路排查、风险治理、流量提升、兜底容灾。

1. 一般流程

一个完善的大促保障包括如下步骤：

1. 明确本次大促的作战地图，明确时间节点和步骤；

2. 输入活动玩法和节点，明确关键时间点和GMV目标、单量峰值；

3. SRE产出备战报告，其中包括保障目标，大促保障时间节奏，作战地图，流量地图（如果已经绘制出来的话），资源规划地图，业务新的变化和技术的挑战，上下游链路依赖图，核心风险和专项分工（精确到人和完成时间），同时SRE要指定监控、压测、演练、预案专项负责人（leader要为SRE放权和背书）。

4. SRE绘制流量地图，明确接口流量，模块链路，关键风险。

5. SRE和开发同学共同梳理上下游接口依赖流量和峰值，给出限流阈值并沟通上下游；

6. 开始链路梳理，一般由熟悉业务和系统的开发同学梳理，然后拉上上下游、梳理同学、测试同学、SRE、leader一起review，review时，SRE要产出5个点：强弱依赖、风险点、限流、降级预案、新业务特征；

7. 根据梳理出来的风险点展开集中治理，大的风险点要开专项治理，这一阶段要全员听调，风险点要各自去做，SRE只负责把控全局、跟踪进度、验收结果。

8. 治理完成后，开展监控走查，更新监控大盘，建议由SRE指定监控专人负责；

9. 压测开始前配置限流，压测过程中还要不断根据情况调节限流值；

10. 开始压测，分为专项重点压测（一般单接口、单机），上下游压测，全链路压测，建议由SRE指定压测责任人；

11. 录入预案，并对预案进行测试和验证，拉上业务、产品、测试一起，组织预案演练，验证预案可行性，要求业务方知晓预案执行后的影响。建议由SRE指定预案和演练责任人。

12. 上述过程中都要记录未完成点和check点，在大促前，要对checklist 逐项check；

13. 产出作战手册，包括值班表，工具清单，大促期间作战流程（精确到分钟级的操作时间点和人员），再次通知业务侧相关预案的影响。

14. 大促开始前一天，SRE要进行战前宣讲，一般包括大促期间发布流程、审批流程、白名单人员名单，工单汇报方法，大促交流群，大促期间的红线和注意事项。

15. 大促结束后，要进行复盘，复盘内容包括：目标是否达到，大促期间达到系统指标、单量，系统、业务的能力亮点，大促保障期间大家做的工作汇总，保障期间的产出亮点，后续action项，未来保障的思考和计划。

2. 作战地图

一次大促保障，大致分为前期的容量评估和准备阶段，中间的系统健壮性提升阶段，后面的压测摸底、预案演练阶段，最后的战前check和值班阶段。其中前2个阶段才是核心。

容量评估和系统性提升阶段

1. 容量准备阶段，重在根据业务活动节点，输入流量和单量，梳理上下游流量压力，绘制流量地图，统计上下游接口压力，评估限流阈值和资源缺口，同时准备资源。这个阶段是关键阶段

2. 系统健壮性提升阶段，重在链路梳理和风险发现，对发现的风险进行专项治理。这个阶段是最核心阶段

压测摸底、预案演练阶段

1. 在压测阶段，不能只被动参加全链路压测，还要优先在自己域内进行单点压测和上下游链路压测，这样在全链路压测的时候才不会掉链子。同时，压测要关注几个事情：

   1. 有没有达到流量预期；

   2. 有哪些点是瓶颈点；

   3. 对瓶颈点如何解决，如何降级或限流？

   4. 上下游在压测过程中有没有可能与自己域相互影响的地方；

2. 在预案&演练阶段，要注重实效，不要走形式化，演练的目的是验证预案的可行性和可操作性，不是为了证明“我演练过了”，如果预案不进行演练，在大促时就有可能出现：

   1. 不敢执行预案，因为不知道会发生什么；

   2. 执行了预案之后发现有坑；

   3. 执行了预案之后发现无效；

站前准备阶段

1. 在战前准备阶段，重在检查和宣讲，检查要查缺补漏，要有checklist，一项项check；

2. 宣讲要有作战手册和红线，作战手册要精确到时间点和人，每个时间点由谁做什么要明确；红线一定要宣讲清楚，大促是一场战役，如何报备，如何响应工单，各自分工是什么，哪些红线不能踩，要明确到位，避免低级骚操作带来的风险。

下面重点介绍容量评估阶段（流量地图和评估）和系统健壮性提升阶段（梳理和治理）；

3. 容量评估

绘制流量地图的目的，是让SRE人员对于域内和上下游流量有明确的了解，在心中有一张全局流量的“图”。流量地图应该包括几个要素：

1. 系统核心模块和模块间的依赖关系；

2. 核心功能流量流向；

3. 核心接口/功能的单量或qps；

4. 链路上的主要风险点；

在进行流量评估时，关键在于要明白上下游依赖、是否有缓存、平时单量和大促单量:

1. 本域应用名

2. 对方域

3. 对方应用host

4. 业务场景

5. 服务接口

6. 对方owner

7. 依赖方式、强弱

8. 日常峰值

9. 大促预估峰值

10. 缓存击穿情况下的悲观峰值

流量评估除了要跟域内对齐外，更加重要的是上下游的沟通，这一点非常重要，要相互明确各自域的瓶颈、限流、承诺；在对上做出流量承诺的时候，一定要优先考虑保护自己域；在对下提出流量要求的时候，要同时提出有保护措施（如缓存）情况下的正常流量和无保护措施下最糟糕流量。

4. 链路梳理和治理

这个是SRE能够借双十一提升系统性能的重中之重，大促保障准备时间有限，所以不能等全都梳理完了之后才开始治理。一般，我建议遵循下面的方法

1. 一般来说是先根据经验和日常的发现，治理一波，

2. 同时进行梳理，然后对梳理进行review时，发现新的风险点，并进行治理。

一般由熟悉业务和系统的开发同学梳理，然后拉上上下游、梳理同学、测试同学、SRE、团队leader一起review，review时，SRE要重点关注5个点：

1. 强弱依赖

2. 风险点

3. 限流

4. 降级预案

5. 新业务特征

梳理的目的不是仅仅评估风险，更重要的是治理，治理不一定是代码层面的升级，可能有如下方式：

1. 对可能有流量尖峰、造成系统冲击的接口，加特殊限流，如全局限流、线程数限流；

2. 对流量尖峰，加dts等异步任务，进行削峰填谷；

3. 对需要做降级的地方加降级预案；

4. 对需要兜底容灾的地方加自动兜底；

5. 对强依赖的下游接口，加本地缓存或tair缓存（慎之又慎，同时下游绝对不能期待上游加缓存来降低访问量）；

6. 治理的时候，要注意几个最容易出问题的地方：缓存、异步消息、异步任务、数据库量级、数据库关联查询量或批量更新量（比如1主单关联N子单的情况）、接口超时时间、重试次数、幂等、sql limit和查询上限；

7. 需要提前禁写的，要产出禁写预案

8. 对大促期间可能随时调整的业务参数，要留出口子，方便调整，做好审批流程报备流程、check流程；

在链路治理时，建议可以建立一个aone项目空间或者lark表格，将所有要做的事情，列成工作项，每完成一项勾掉一项，当所有工作项都完成时，项目就结束了，治理也达到了一个水平。

5. 压测

在大促保障过程中，提到压测，有同学可能习惯性的将其归结到“全链路压测”中，这个是不全面的，压测应该贯穿整个大促保障的过程。

压测分为3种，分别是单点压测（如：单机压测和单接口压测），单链路压测，全链路压测。

1. 单点压测的目标就是考察单点性能，主要用于发现单机或者单接口的性能水位和性能热点，为了后面计算限流阈值，评估集群规模做准备；应该在大促前就开始，随时可以进行，不一定要在正式环境。如果只是发现性能热点，可以使用火焰图分析；如果是评估性能水位，就要进行摸高，一般对于4核8g的机器，至少要摸到load 到5，cpu利用率到75%，内存到70%，线程数超过800个，这4个指标至少要达到1个才能算。

2. 单链路压测的目标是考虑单链路多个应用间多级调用的性能，用于评估某个功能点的水位，为的是应对活动过程中某个业务的量级，评估的目标是整个链路中至少一个节点达到性能瓶颈为止。整个链路的性能水位，是由最低的那个节点接口/应用 决定的。在压测过程中，建议摸高，一直摸到其中一个节点达到瓶颈。单链路压测建议在业务给出活动目标后，就要梳理出核心链路有那几条，这几条核心链路是一定要压测的。需要注意的是，如果有非核心链路影响了核心链路，那么大促时这个非核心链路要么做降级预案，要么改为核心链路死保。

3. 全链路压测的目标是预演，而不是压测，这一点跟前面的压测是完全不同的，需要特别注意，虽然全链路压测本身也会摸高，但是它摸高是预设目标的，比如本次大促50wqps创建，预计摸高也就是120%，不会一直摸高。全链路压测其实是在将各个团队压测的结果进行汇总并验证，所以现在全链路压测一般要去一次通过。这就要求各个团队要提前调通内部各条单链路。

另外，如果链路有涉及外部partner，建议一定要在压测中走通，不要轻易相信外部partner自己的压测结果，也不能认为“他们承诺了，他们要做到”，这种想法，在大促的时候，partner的承诺无法做到的比比皆是，不要最后坑了自己的业务，导致业务单子积压。

7. 日常稳定性机制

对于SRE来说，在日常稳定性保障过程中，建立一个行之有效的机制体系，比事必躬亲更加重要。一般来说，SRE在日常稳定性保障过程中，要建立的机制如下：

1. 黄金链路识别治理机制

2. 值班机制

3. 复盘机制

4. 日常资源（机器、中间件）管控和记账机制

5. 日常风险和问题报备机制

6. 团队权限管控机制

7. 日常演练机制

下面重点说一下黄金链路和值班。

7.1 黄金链路治理

黄金链路，就是核心链路，或者说，是团队的生命线链路，由最核心的应用，最关键的DB，最需要死保的接口，支撑的最核心业务。所以黄金链路的治理就一个目标：不要让非核心的东西，影响了核心的；这里的“东西”，包括业务、系统、db；
黄金链路治理机制，是要在日常工作中，做如下工作：

1. 每隔一段时间（半个月左右），要统计一次线上订单各业务单量，有条件的团队，建议分配专门负责数据驱动的人员，建立fbi报表，或者建立数据分析系统。这些数据产出的目标，是统计业务的量级和趋势，报告最核心单量最大的业务、最容易出问题的业务、和发展最快的业务；

2. 对业务和应用链路，按重要性进行划分。把重要的挑出来，把不重要的，不死人的，可以降级的摘出去；

3. 开始治理，要求核心链路上的系统，不能依赖非核心的接口，不能依赖非核心的db。非核心链路上的任何降级措施，不能影响核心链路的功能；

4. 核心链路和非核心链路，也不能依赖共同的基础组件，注意，核心链路不等同于核心应用，现在很多核心应用里的非核心功能太多了。导致每次改非核心功能，要发布核心应用，甚至两者共用底层组件，导致底层发布影响上层。比如，非核心功能要改一个消息发送接口，正好核心功能也依赖了这个接口，非核心功能改动里的bug，可能导致核心功能挂掉；

5. 核心链路和非核心链路，要有2套发布等级，2种监控等级。防止相互影响。

黄金链路治理做好了，团队出现高等级（P1/P2）故障的可能性会大大降低。

7.2 值班机制建设

值班，既能让大家熟悉业务，又能让SRE不那么劳累，因此，值班人员一方面要响应报警，另一方面要响应工单。SRE要做的事情，是安排好值班表和值班机制，明确值班人员的职责。一般来说，可以如下建设：

1. 事前：

   1. 值班人员必须参与故障演练（包括故障止血方法）以及熟练使用各种故障排查工具。

   2. 值班人员需要明确值班的范围，包括预警群、工单群、线上问题反馈群、答疑群等；

   3. 值班人员在值班周期内，应该减少业务工作安排；

   4. 值班人员的值班周期不宜过长或者过短，以一周为宜；

   5. SRE应该尽可能的多值班，只有对业务熟悉的人，才能更加敏锐的发现系统的问题；

   6. 新进入团队的同学，应该先值几个月的轮班，通过值班熟悉业务，是最快的方式；

1. 事中：不管是工单问题还是报警，如果短时间无法定位原因的情况，立即把相关人员拉入电话会议，如果遇到卡点，需要把接力棒明确交接给下一位，事后再回顾卡点的原因。对于会影响上下游的问题（事故），需要立刻通知上下游，可能引起故障的，需要GOC报备。

   1. 值班人员自己发现问题后，应该第一时间在群里反馈说处理中，签到通知其他人已经在处理

   2. 关闭当前报警的通知（关闭方法集中沉淀到常见问题处理手册），防止电话打爆掩盖其他更重要的报警，事后再重开报警（由当前值班人员保证）

1. 事后：值班人员和SRE一起组织问题Review，并把涉及到稳定性的操作内容记录在稳定性流程中。对于常见问题的排查沉淀到一处，后续工具化和演练。

值得注意的是，值班不应该是简单的人力消耗，应该花费时间开发工具平台，包括问题智能排查、订单详情查询，业务日志轨迹、数据变更轨迹查询，并且开发问题自动排查、问题解决方案自动推荐机器人，做到自动答疑、自助答疑，减少工单数量，提高问题排查效率。

8. 弹性建设

系统的健壮不是没有报警，也不是不出故障，服务、数据、体验都不受影响，我们才认为系统是健壮的。一个系统想要健壮，应该具有一定的弹性，系统的弹性体现在系统是：容灾的、可自愈的、一定程度上容错的、可运营的。
这里，有ufried 在2017年的弹性设计PPT：《Resilient software design in a nutshell》，这个PPT非常清晰准确的阐述了“弹性软件设计”的概念，下图取自该PPT：

对于我个人的实践而言，我自己倾向于重点做好其中的发现、恢复、预防、缓解4个部分。

9. 价值建设

我想把“价值建设”这个事情，放到本文的最后，作为对SRE人员提升工作信心的鼓励。

开发人员容易趋向于实现什么，如何做到，Dev工作的目标，是电脑屏幕和系统功能；而SRE，很多都是电脑外的工作：上下游沟通，流量评估，演练组织，资源调度，故障应急，系统治理。工作内容既有代码里的ifelse，也有Excel上的各种统计，还有PPT上的各种曲线。很多人觉得这样的事情很boring，倾向于做一个专心写代码的美男子，但是一个开发人员，偶尔抬起头看着窗外，心里对那些横跨多域，调度多个资源，影响力辐射多个团队甚至BU的人，也有一丝羡慕和无力感。

SRE恰恰给了这样一个机会，它能让一个级别不怎么高的开发人员，调度域内尽可能多的资源，从事多种能够辐射影响力的机会。SRE最容易拿到数据，就要去考虑一个问题：价值导向，当前做的事情，有多少数据量，有哪些是无用的长尾的，有哪些可以下线掉。哪些是造成资损的，哪些是需要推动解决的异常订单，哪些是有巨大价值的。哪些是客户抱怨最多的，耗时耗人力最大的。

开发人员容易正向思维，而SRE人员，一定要去做反向思维，通过价值来考量，通过价值反推意义，提效降本。

绝大多数情况下，一个好的SRE，和一个差的SRE，差距就体现在3个方面：好的SRE会随时发现和响应问题，会建立体系化，会极其细致的落地解决方案。 这其中，随时发现和响应，是第一态度，是要持之以恒的心态，而不是一个作秀和表现；落地是基础，是保障稳定的生命线，细致的落地，是决定你是走走过场，还是真的做深的根本；体系化是框架，是决定机制能否持久以及你自己累不累的原因。

另外，一个团队（尤其是业务团队）的SRE是极度需要老板的鼎力支持和权力背书的，SRE往往没有组织架构上的权力，这个时候，老板真正意义上的支持就很重要，如果一个SRE，你的老板总是口头上跟你说稳定性不能松懈，但是几乎从来不愿意在稳定性上给你支持，一心只想做业务，你就要考虑2个方面：

1. 是不是你做的不落地，没有得到老板信任；

2. 换个老板。

如果老板愿意给你时间和空间，也愿意投入资源，给你权力，那你就要认真做好SRE这份工作，做出价值。

• 一般来说，老板愿意给你权力的时候，就意味着老板愿意帮你背责任，所以不要怕出错，要先把态度做出来，老板会支持你的。

• 但是注意：老板给你的权力用好了，老板才会给你背责任，用不好，责任就是你自己的。这一点无论在哪个团队，无论在哪个层级，都是一样。

写在最后，加油吧，少年！！！