稳定性建设的方法论 架构师应该做什么?

故障原因印象流.

1. 代码改动的发布 bug 

2. 下游依赖 bug .(软件,硬件)

3. 稳定性雪崩

      3.1下游慢等性能问题导致的雪崩

      3.2 mysql 慢查等索引性能问题导致的雪崩.

4. 本业务机器故障.

5. 大促等流量激增导致的雪崩

6. 机房迁移.

 

如何避免上述问题? 体感报警,体感监控体系
问题定位2/5/15 稳定性 问题定位[基于此监控系统] 系统优化[内部调用异常数据流量,基于此系统上的压测瓶颈发现]

补充照片上没有的两点.

拆分: 水平拆分,垂直拆分,基础(中台)拆分. 读放大.

 

各个内部中间件系统最好也改造接上各核心节点监控. 分成各区间段.

数据驱动的稳定性建设基础: 1.入口监控 (dubbo,mq,定时任务 dubbo,内部定时任务) 2.出口监控(mq,dubbo,http,thrift,mysql,redis)

 

流量大的接口要隔离.

 

埋点树: 要有ui 自动下一批子节点找出来. 用来确认埋点是否ok.

 

发布监控:

      看错误Exception,错误量. 不要看成功率,成功量. 

          监控:  1.量够看成功率,上周同比,上上周同比.. 将绝对值转换为率来判断,比如 大于多少算不正常,不正常的比例. 这样就自动化,不用担心.  2. 量不够看连续绝对值. 确定一个阈值,平台最好可配置时间段阈值  

           耗时这个指标绝对值有异常就要报警,比较重要. 体感角度监控. 从线程池角度监控: 乘积要监控.

           梳理: 看绝对值. 成功率低的,耗时高的.

           看耗时,一般上线都是低峰期. 耗时要特别关注.

           看耗时提高(早高峰崩溃),相比6周同期,相比上周同期      

  1. 监控. 总量,率,失败数,耗时,总量*耗时, size,错误类型, exception. error日志. 

      低流量报警: 关注失败率和code率. 如果有些接口失败但用户体感无影响. 要进行改造.先暂时过滤. 

   流量: 需要一个系统,

       整理出: 1. 离线稳定性分析大盘,架构师专注查看. 这样架构师不需手动执行n各sql,然后整理到webExcel中

      2. 分配给各同学, web excel

      3. 各个同学整理答复, 更新进度.

  1.  检查是否全面覆盖.
    1. 入口: lwp,http,hsf,mq,定时任务
    2. 出口:http,hsf,mq,mysql,tair,redis,hbase,异步发送到队列返回的时间. tair要区分keyType.
  2.  按入口各指标top5列出,指定同学分析定位.
    1. 依赖链路分析. 总时间 是否 =总下游依赖调用时间
  3. 按入口/出口(直接,异步间接)数量比top5分析
  4. 按入口-出口(直接,异步间接)总耗时top5分析
    1. 异步怎么办? 
  5. 按出口各指标top5分析.
  6. 绝对值耗时分析: 按区间分析.

存储:

    1. 持久化存储
    2. 内存

      自动化大盘,监控. 

      灰度监控,比较人肉,淹没在全量监控中.  

      [创新] 可视化web中台.  趋势图, 圆饼图, 漏斗图. 分组(kv),指标.  多key(无key)

      [创新] 指标api后端中台. 服务端通过数据采集, 然后通过接口传递给可视化平台. 同比,环比,报表可点击.[ 阿里xflush + 业务自动化]

       

      指标+ 指标上的指标. 

      链路: 入口到db的读放大

  在线      

  2. 演练

       

  3. 降级

  4, 雪崩下问题定位

  5. 指标平台. 按维度报警.

秘钥覆盖率, 大组织的,一部分人发了加密消息, 另外50w不能解密,向第三方取秘钥. 挂掉.

针对业务数据我们可以利用历史数据使用Holt-Winters等模型进行业务数据预测. 

你可能感兴趣的:(分布式)