一个服务端故障应急响应处理案例|演绎

Chapter 1 发现告警

2023年3月11日，上午11点，这是一个周末，大壮正在刷七猫免费小说，一条告警赫然出现在飞书监控告警群里。大壮点开看一下，虽然平常也会有一些 5xx 出现，但是10%这么高占比的有点离谱。大壮顺手就在飞书群@了值班人员阿新。但是阿新一直未读，过了一分钟，新的告警又来了，5xx占比来到了15%。

Chapter 2 接警启动

大壮意识到问题比较严重，立即将最新的告警消息创建了话题，@了Teamleader 阿茂。同时根据《业务线负责人和值班文档》多维表格文档，确定了业务线 owner 小美为【快恢负责人】，在话题中@了他。值班人员阿新同时也是项目的专职【通讯员】之一，也在话题群里@了阿新。接着发起了和小美、阿茂、阿新4人的视频会议。

视频会议：

小美、阿茂上线，阿新依然不在线。大壮反馈了问题；Teamleader 阿茂说：阿新不在线，大壮这次你来做通讯员，阿新上线了让他和你一起跟进。小美，你先跟进一下预案，看预案是否符合。我把运维阿义也拉进来，有哪些需要的信息，你们等会儿 @他。阿茂继续说：大家可以把麦克风 Mute 掉，有问题直接开麦说就行，有消息进展直接发到群里。 

Chapter 3 前期

大壮根据《应急响应处理模板》创建了飞书文档，命名 《IR-20230311-配置中心500》，并且在群内置顶。小美表示，当前的告警暂时没有对应的预案。该项目最近一次上线时间是3天前。然后打开《排查指南》快速打开了 LTS 日志平台，并直接定位到了配置中心项目，开始搜索最近1小时的 cce 错误日志。发现了有很多 “redis: connection pool timeout”错误日志，并截图发群里。因为不能依赖预案直接恢复，阿茂将上级 Teamleader 拉近了群里，同步了相关信息与此同时运维阿义 将 redis 的慢日志记录发了出来，分析并验证得出是存在 热key；小美把麦克风打开：“大家能听到吗，我快速说下方案：这块逻辑本身是读写分离，我可以快速加上 Go 缓存解决热key问题，也不影响缓存的生效时间。”阿茂将测试小帅拉进会议：“小美，起一个 hotfix 修改，用单测快速验证一下，上线预发布验证。小帅到时候测试一下。”大壮将信息同步至文档，并@了小帅。小帅随后入会，大壮跟小帅顺着在线文档同步了一下信息。

Chapter 4 执行修复

小美快速完成了编码并完成单元测试，提交了合并请求，阿茂看了没问题，并发布到了预发布环境。小帅在预发布环境完成了测试，再经过灰度和全量上线和验证。

Chapter 5 恢复

网关 5xx 降为0，业务恢复正常。Redis 并发操作数降低。大壮将结果同步至文档。会议上阿茂说：“故障目前恢复，大家可以先休息，我再观察10分钟。我创建了一个任务，排查热key的根因，小美周一跟进一下。”阿茂向上级Teamleader同步了最新结果。阿茂一边观察，一边创建了另一个任务：预案更新。

Chapter 6 结尾

阿新终于上线，收到消息，它点赞了话题消息，并点赞了文档。留言：“人在xx，手机被抢，刚回到酒店打开电脑”。