系统稳定性保障工作梳理

MTTF（不出故障的时间）

MTTR（出故障后的恢复时间）

业务域

关键场景

问题表现

问题定位

止血措施

预案执行

业务影响

上游影响

下游影响

数据影响（操作人）

服务侧、业务侧应对策略

产品端应对策略

不要进行无场景演练

冷静

电话会议

快速响应流程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

梳理

治理

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

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

全链路压测的目标是预演，而不是压测，这一点跟前面的压测是完全不同的，需要特别注意，虽然全链路压测本身也会摸高，但是它摸高是预设目标的，比如本次大促50wqps创建，预计摸高也就是120%，不会一直摸高。全链路压测其实是在将各个团队压测的结果进行汇总并验证，所以现在全链路压测一般要去一次通过。这就要求各个团队要提前调通内部各条单链路。 另外，如果链路有涉及外部partner，建议一定要在压测中走通，不要轻易相信外部partner自己的压测结果，也不能认为“他们承诺了，他们要做到”，这种想法，在大促的时候，partner的承诺无法做到的比比皆是，不要最后坑了自己的业务，导致业务单子积压。

手工处理不能超过50%

监控、链路治理、演练

发现问题、解决风险、因事修人

数据驱动：包括日志标准化和错误码标准化，能够对日志和错误码反馈的情况进行量化。

数据对账：包括上下游对账、业务对账，能够通过对账，保障域内数据校准。

轨迹跟踪：包括变更轨迹和数据轨迹，目标是实现数据的可跟踪，和变更的可回溯、可回滚。

数据化运营：主要是将稳定性的指标量化，比如工单解决时间、工单数、报警数、报警响应时间、故障风险数、代码CR量，变更灰度时长等，通过量化指标，驱动团队同学建立量化意识，并且能给老板一份量化数据。

1、系统监控

2、服务监控

3、业务监控

4、数据监控

5、资损监控

最核心业务入口的qps、rt、错误数、成功率，从这个维度可以看到入口流量的大小和相应时间，成功率。这一点，是在知道入口的健康情况。

错误码top N，这个维度可以看到系统运行过程中最核心的错误，快速直观定位问题原因（这个需要打通上下游错误码透传）。这一点，是在快速知晓问题出在哪里。

按业务维度（业务身份、行业、仓储、地区等，根据实际需要决定）分类统计计算的单量、或分钟级下单数量，用于确定核心业务的单量趋势。这一点，只在知道自身业务的健康情况。

核心下游依赖接口、tair、db的qps、rt、错误数、成功率，需要注意的是，这个一般比较多，建议只放最核心、量最大的几个。这一点，是在知道下游依赖的健康情况。

其他影响系统稳定性的核心指标，如限单量，核心计数器等，根据各个团队的核心来决定。这一点，是在个性化定义关键影响点的监控情况。

谨慎使用电话报警

设置专门的唯一的钉钉报警群

报警留底

日常报警数量限制

合理报警

监控治理

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

黄金链路治理