SRE服务端预案,应急处理手册

服务端应急处理流程

问题升级流程

问题升级步骤

SRE人员-各端组长-业务线负责人

现有降级手段

App业务入口降级

降级范围以及作用域

使用App降级策略,App在各个业务入口会直接降级,关闭对应的业务入口

使用场景

  1. 对应业务出现会持续扩大损失并且短期无法修复的报错,比如应用持续出现异常,并且异常会导致越来越多的脏数据影响业务流程
  2. 应用无法正常提供服务,并且确认无法短期内恢复。

AHAS限流降级

降级范围以及作用域

通过AHAS的限流能力,对核心应用接入AHAS,具备对指定接口做限流降级的能力。

使用场景

  1. 特定业务出现过量的访问或请求,在扩容之前,先使用AHAS进行限流保证已有业务不被打挂。
  2. 服务端出现短期内无法恢复的基础设施异常,使用AHAS进行限流降级,保证友好的返回。

应急预案SOP

MySQL

目前C端现有资源

rds_***等

表变更

现象

阿里云DMS审核表变更

动作

通知大数据,同步表待大数据确认变更的内容对他们的影响后,再执行。

长事务慢会话告警

现象

云监控-数据库层群出现C端实例的慢会话或者长事务告警

动作

登录das查看对应数据库实例状况,分析具体原因

  1. 如果实例会话中有异常会话,联系DBA,backup,帮忙杀死异常的会话
  2. 如果请求分析中慢日志某系统出现大量慢sql,视慢sql增长量,对该系统进行扩容处理

MySQL连接获取慢

现象

应用arms出现慢接口告警,并且链路追踪中耗时较长的步骤是druid或者hikari的getConnect等方法

动作

  1. 对应用进行扩容,按依次按顺序找SRE->组长->运维,其中的一个完成
  2. 观察慢接口数量是否下降,告警是否消失
  3. 调整应用数据库连接池配置,重新发布应用

Kafka

目前现有资源

kafka_**

kafka堆积

现象

动作

  1. 登录阿里云kafka监控查看堆积的消费者组的情况

  2. 刷新查看堆积量的增长情况,如果堆积量逐渐减少,那么可能只是突增流量和业务导致的,可以继续观察,如果没有明显减少的情况,则对比分区以及机器数,如果分区>机器数,则扩容机器数到=分区数,如果分区<=机器数,则联系运维组扩分区+应用扩容,扩容后继续观察堆积情况。

## Redis

### 目前现有资源

redis_*

### Redis告警

#### 现象

#### 动作

  1. 登录DAS查看情况,先看实时趋势,辨别一下是短期增长后回落还是还在持续增长。

  2. 主要查看内存和cpu使用率,一般是这两个告警

  3. 依靠实例会话里慢日志和缓存分析,查看导致异常的应用或者会话或者业务,如果对redis整体的影响增加很大,那么需要对对应的业务做降级,如果影响不大,那么则马上安排优化该业务

    ## 服务

    ### 目前C端现有资源

    all

    ### 慢接口告警

    #### 现象

    #### 动作

    1. 登录arms查看情况,对应应用-接口调用-调用链查询-按时间排序。

    2. 点击traceId进入排查接口慢的原因,如果是下游慢,联系下游排查处理,如果是中间件(mysql或者redis)慢,看一下是否某个sql导致的

    3. 观察慢接口出现的频率是否持续上升,如果没有缓解并且短时间内无法解决,马上使用ahas对该接口进行限流降级。

      ### Full gc告警

      #### 现象

      #### 动作

      1. 登录arms查看情况,对应应用-应用详情-JVM监控。
      2. 查看gc情况以及堆内存情况,如果只是单pod的fullgc次数越来越多但堆内的老年代内存没有明显回收释放,那么需要对有问题的pod进行手动重启。
      3. 如果只是比较稳定的进行full gc并且老年代回收较为理想,但应用扔保持触发告警阈值的频率,那么可能只是单纯量上来了,需要对集群进行扩容。

线程池告警

现象

动作

  1. 登录arms查看情况,对应应用-应用详情-JVM监控。

  2. 查看JVM监控中的线程数,是否有明显的尖刺。

  3. 查看是单pod的问题,还是整个集群每个pod都有问题。

  4. 如果单pod的问题,重启该pod。

  5. 如果是整个集群的每个pod都有该情况,扩容集群,观察情况是否有缓解。

### 错误率告警

#### 现象

#### 动作

  1. 点击链接进入sls,查看对应服务的error日志
  2. 具体情况具体分析,如果对系统影响较小,或者可以业务上进行修复恢复,那么就业务修复处理。
  3. 如果对业务影响较大,并且会持续出现脏数据或者报错,那么对业务进行降级
版权声明:除特殊说明,博客文章均为intotw原创,依据CC BY-SA 4.0许可证进行授权,转载请附上出处链接及本声明。
暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇