系统保障

系统稳定性

影响稳定性有哪些因素：

人为操作:

• 比如不合理的系统变更，外部的攻击，访问流量突增

自然灾害：

• 比如网线光纤被挖

硬件故障：

• 比如自然硬盘损坏，内存网络

从以往经验来看，影响系统稳定性最多的原因是人为因素

稳定性方法:

注重代码健壮性，注重CodeReview：

• 代码开发需要考虑可观测，可降级，考虑异常容错性
• 合理使用缓存，线程池等，对于外部依赖需要超时机制

安全变更，遵守SOP：

• 任何生产环境的变更都要按公司规范操作，做到可灰度,可监控,可回滚

系统链路梳理，强弱依赖梳理：

• 把系统核心链路流程梳理，分析系统的出强弱依赖，分析是否有损降级

接口降级，限流，熔断，超时设置：

• 需要对下游依赖设置可降级，可熔断，超时，避免外部系统性能或者故障拖垮服务
• 对本服务接口设置必要的限流，一般有网关层总限流和单机限流，防止突发流程冲击系统

定期业务系统降级演练：

• 需要定期对系统的业务功能进行降级演练，只有真实演练过了，线上有问题的时候才可以临危不乱

系统预案准备充分：

• 业务功能上线前都需要做好降级预案，包括技术和业务层面的准备，这样出现问题可以快速恢复，止血

系统或全链路压测：

• 新功能上线需要做压测摸高，日常也需要常态化压测
• 通过压测用于合理评估系统资源是否合理，可以及时消除容量和性能瓶颈隐患

业务系统日常巡检：

• 需要观察业务指标趋势，业务指标一般有一定的规律，如果变化比较大可能业务有调整，可以评估是否正常的业务

业务流量QPS巡检:

• 巡检QPS的环比变化，发现异常的流量，防止业务或者流量突增对系统冲击

接口响应时间RT巡检:

• 发现系统响应时间的变化，主动发现问题

系统异常巡检：

• 自动发现系统的错误，提早评估业务影响

中间件巡检

MySQL巡检：

• MySQL慢查询
• MySQL的CPU繁忙度
• MySQL磁盘空间大小与增长情况
• MySQL的主键或者分布式id是否将达到阈值

Redis巡检:

• Redis的CPU繁忙度
• Redis热点Key的变化
• Redis大key的变化
• Redis的数据分布均衡情况

系统值班：

• 针对重要节假日，预估会有流量高峰的时间，安排相关人员值守
• 重点关注系统水位，比如流量QPS,CPU，有无异常等，还关注客服响应群，保障有问题时可以及时响应

告警：

• 配置核心告警群，把系统核心告警统一到群里，系统相关人需要在群里
• 需要将重要的业务情况同步播报在群里，系统异常情况告警出来，方便快速发现问题

常态化压测

什么是常态化压测：

让压测趋于正常的状态，趋于合理。

常态化压测是指在某个产品或系统上进行自定义周期（常态化）的、系统自动执行的、可验证结果的压测过程。

• 目的是检测产品或系统的稳定性、可靠性和性能，确保它们能够在不同的场景下正常运行。

大促中如何去做技术保障

KO会议(Kick Off Meeting，项目启动会)：

介绍大促的背景与意义。

明确大促的目的与目标。

介绍大促的内容以及具体时间。

介绍大促的相关人员。

沟通：

KO大会是一个全局整体的介绍。

对于一些细节，需要与业务进行沟通。

• 目的是确认你的信息是无误，以及了解一些细节。

流量评估：

需要清晰的知道当前阶段每天的流量。

• 当前阶段的性能是否能支撑即将来临的大促，如果不能，需要做出什么调整。

业务梳理：

需要梳理出哪些业务是核心业务，哪些业务是非核心业务，哪些业务是可降级业务。

压测:

有了业务梳理和业务指标，在技术上要能够支撑到这个业务级别，就需要压测。

限流：

压测完了后，需要输出一份压测报告，比如不同接口支持多少QPS等。

• 这些数据说明了系统有多少实例，哪个接口能承受的最大峰值是多少。

需要对这个接口或这些接口做限流。

降级：

要降级一些比较耗性能的业务降级，一些边缘业务降级，给核心业务让路。

应急预案与演练:

当保证了核心链路的正常后，还需要考虑异常的情况。

对于电商系统来说，要考虑到整个生命周期异常的可能性。

• 比如：打开商详页失败、打开订单页失败、下单失败、履约失败等。

做完预案后，要通过预案平台进行演练，或者人工演练，这样大促出问题后才会临危不乱。

监控：

大促大盘监控、全链路监控、核心链路监控、限流监控、资源监控、网关监控…

规范:

大促期间需要制定规矩:

• 比如发布红线、红线问责、预案执行规范、紧急扩容规范、紧急发布规范…

制定规范的目的是能明确问题发生后应该按照什么流程去应急。