20.12.31 上午

表象描述

9：26 dataquery 9111 开始报警，错误量逐步高升
9：31 几乎已经全部宕机
9：49 因开发昨晚回去的晚，9点半知道出现问题，把回滚配置确定，给到运维让回滚
10：45 初步情况好转
10：50 左右全部恢复正常

响应现象

开发反应

  • 开发从9点半开始介入，经初步排查
    • 昨天下午4点发布，减少GC最大停顿时间（-XX:MaxGCPauseMillis=400 -> 200）启动参数
    • 昨天商讨今天9111放一批不小的流量

  • 开发9点45左右通知运维切掉流量回滚配置

    运维反映（不准确）

  • 9点半运维通知9111服务不可用

    • 第一时间扩容6台
    • 云平台界面卡顿操作困难
    • 扩容之后发现依然不可用
    • 开始一台一台重启（操作缓慢）
    • 通知结果页切断流量，运维切断IP
    • 更改配置重启（重启慢，配置未生效）
  • 云平台运维介入后台操作（重启发现配置为生效）

  • 云平台运维设置配置重启生效，逐步恢复

    主要问题

  • 开发相关

    • 未能在现象萌芽期到场（昨晚回去的晚）
    • 更改配置未经全方面压测
      • 因为云平台没有灰度发布，只能全发
      • 测试环境与线上有差距，在测试环境这种问题测不出来
    • 不够谨慎
      • 线上配置改动应一点点调动
      • 在改动后长时间观察但未到峰值，未发现问题放松警惕
  • 运维相关（不够全面准确）
    • 没有应急预案（响应时间慢）
      • 出现问题处理流程不清晰
    • 操作不够流畅
      • 运维操作不够准确有效
      • 有些操作不清楚
    • 云平台
      • 首先容器不稳定
      • 云平台运维笨拙
      • 没有灰度发布机制
      • 没有应急操作（批量重启）