系统稳定性保障工作梳理

稳定性意识

日常值班机制

报警响应机制

复盘机制

故障演练机制

故障奖惩机制

节假日保障机制

稳定性机制体系

梳理。主动梳理团队的业务时序、核心链路流程、流量地图、依赖风险，通过这个过程明确链路风险，流量水位，时序冗余；

治理。主动组织风险治理，将梳理出来的风险，以专项的形式治理掉，防患于未然。

演练。把风险化成攻击，在没有故障时制造一些可控的故障点，通过演练来提高大家响应的能力和对风险点的认知。这一点将在后面详述。

值班。不能仅仅为了值班而值班，值班不只是解决问题，还要能够发现风险，发现问题之后，推动上下游解决，减少值班中的重复问题，才是目标。

报警。除了前面说过的主动响应之外，还要经常做报警保险和机制调整，保证报警的准确度和大家对报警的敏感度。同时也要做到不疏忽任何一个点，因为疏忽的点，就可能导致问题。

SRE主动做的事情

做扁鹊大哥：在系统健康时发现问题

做扁鹊二哥：在系统有隐患时发现问题

做扁鹊：在系统发生问题时快速解决问题

走在系统前面

常常思考产品和系统哪里有问题，如何优化，如何体系化？

常常思考有没有更好的办法，有没有提高效率的办法？

常常思考如何让稳定性本身更加有价值，有意义？

需要思考的问题

MTTF（不出故障的时间）

1）Mean Time To Identify (MTTI): 从故障开始到应急响应介入的时间，一般是考察监控告警、人员值班 oncall 的合理性。

2）Mean Time To Know (MTTK):从应急响应介入到故障定位的时间，主要考察根因分析、可观测性等工具的能力。

3）Mean Time To Fix (MTTF): 从故障定位到故障恢复的时间，主要考察应急预案、快恢体系的能力。

4）Mean Time To Verify (MTTV):从故障恢复之后到确认故障已经解决的时间，一般通过用户反馈、自动化测试等确认恢复。

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

概念

相关域，要分别梳理上游和下游

业务域

服务场景，每行列出一个场景，要列出所有可能的场景

关键场景

逐条列出当前场景的所有可能表现

问题表现

对应前面的问题表现，列出每一个表现的定位方法和指标

问题定位

对每个定位的原因，给出快速止血的措施

止血措施

逐条列出可以执行的预案

预案执行

逐条列出可能导致的业务影响和严重程度、范围

业务影响

逐条列出在上游的影响

上游影响

逐条列出对下游的影响

下游影响

逐条列出数据的影响（qps、rt、单量），以及捞取数据的方法、订正数据的方法

数据影响（操作人）

列出服务端、业务侧的应对话术和退款、赔付、补偿方案；

服务侧、业务侧应对策略

列出产品侧对业务侧的沟通方案、客服话术、产品降级方案；

产品端应对策略

场景梳理

不要进行无场景演练

故障演练

冷静

电话会议

尽快告知当前告警已经有人接手，是谁接手的，表明问题有人在处理了。（这一步叫“响应”）

组织人员，快速定位问题，告知问题初步定位原因（这一步叫“定位”）

初步影响范围是什么？给出大致数据（这一步方便后面做决策）

有哪些需要老板、产品、业务方决策的？你的建议是什么？（这一步很关键，很多时候是：两权相害取其轻，你的评估和建议，直接影响老板的决策）

当前进展如何，是否已经止血？（这一步是“恢复”，要给出“进展”，让决策者和业务方了解情况）

快速响应流程

故障应急过程

三、故障应急

借节日，修系统

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

保障机制

2  作战地图

3  流量地图 & 流量评估

• 强弱依赖

• 风险点

• 限流

• 降级预案

• 新业务特征

将场景细粒度细分，列表化

梳理

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

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

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

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

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

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

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

对大促期间可能随时调整的业务参数，要留出口子，方便调整，做好审批流程报备流程、check流程；在链路治理时，建议可以建立一个aone项目空间或者lark表格，将所有要做的事情，列成工作项，每完成一项勾掉一项，当所有工作项都完成时，项目就结束了，治理也达到了一个水平。

治理

4  链路梳理 & 治理

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

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

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

5  压测

五、节假日保障机制

手工处理不能超过50%

自动化

通过监控体系、链路风险、演练体系发现问题

监控、链路治理、演练

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

体系化

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

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

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

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

数据化

三化

系统间依赖图（也包括业务时序，熟悉业务流程）

流量地图（知道上下游系统，团队内系统的流量关系和流量水位，也同时把控系统架构）

系统保障图（知道稳定性保障的步骤和打法）

三张图

机器资源表（做到占用多少资源，了然于胸，团队需要时能拿得出来）

异常场景应急表（出现问题时知道怎么应对，演练知道哪里容易出问题）

业务近30日单量表（知道哪些业务影响大，哪些业务是重点）

三张表

监控的核心目标，是快速发现“异常”

内存、CPU、磁盘、load、rt

1、系统监控

显著上涨

显著下降

同比或环比下跌/上涨

qps

偶尔抖动，一般不处理

长时间增加，或突然增加，或同比增加，需要关注

rt

流量小的时候，这个不准

流量大的时候，主要要看成功率

成功率

流量小的时候，主要看异常数

异常数

四大指标

对外服务的4大指标

下游依赖服务的4大指标

中间件、缓存的4大指标

服务

不应是异常，但是很可能除了数据上的错误需要特殊关注

错误码

对于服务系统、只要服务4大指标没问题、都不是大问题

2、服务监控

1、基于日志

1、按业务划分的流量监控或异常流量监控

按业务身份、门店、仓、行业等进行分类统计

一般都要同时有总计报警

2、业务的异常归类统计

2、分类

3、特殊业务可以特殊定制，灵活性高

4、尤其重视错误码的top统计和报警

3、业务监控

1、基于sql查询

创单晚

接单晚

下载晚

超时监控

下发积压

合批积压

积压监控

2、在业务系统体现

订单系统中，只要数据不错，都不是大问题

3、主要目的在于，不管系统怎么样，要保障数据的最终稳定性

4、数据监控

1、资损场景梳理

2、资损对账

1、平时队长，防治资损风险

2、遇到资损，最快速资损

3、在服务降级和资损之间，具体权衡，取伤害轻的

3、资损关键点

5、资损监控

监控的组成(五个维度)

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

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

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

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

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

监控大盘

谨慎使用电话报警

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

报警留底

24小时内，报警群内的报警总数，在不出故障/风险的情况下小于100条

日常报警数量限制

对于系统监控报警，采用范围报警，比如load，设置集群内超过N %且机器数大于M的机器load都升高了才报警。毕竟对于一个集群而言，偶尔一台机器的load抖动，是不需要响应的。

对于业务报警，一定要做好同比，不但要同比昨天，还要同比上周，通过对比确认，对于一些流量不是很大的业务来说，这一点尤其重要，有些时候错误高，纯粹是ERROR级别日志过度打印，所以只要相对于昨天和上周没有明显增加，就不用报警。

对于qps、rt等服务报警，要注意持续性，一般来说，要考虑持续N分钟，才需要报警，偶尔的抖动，是不用报警的。当然，对于成功率下跌，异常数增加，一般要立即报出来。

复合报警，比如一方面要持续N分钟，一方面要同比昨天和上周，这样来减少一些无需报警的情况。

根据需要设置报警的阈值，避免设置>0就报警这种，这种报警没有意义，一般来说，如果一个报警，连续重复报10条以上，都没有处理，一般是这个报警的通知级别不够，但是如果一个报警，重复10条以上，经过处理人判断，不需要处理，那就肯定是这个报警的阈值有问题。

合理报警

首先当然是要监控治理，做到监控准确，全面，然后按照前面说的，控制报警数量，集中报警群，做到可控、合理。

监控治理

避免监控信息爆炸

二、监控

机器服务资源

数据库资源

四、资源管控

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

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

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

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

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

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

黄金链路治理

黄金链路识别治理机制

值班机制

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

日常风险和问题报备机制

团队权限管控机制

日常演练机制

六、故障日常稳定性机制

稳定性梳理