收到告警消息后，如何快速定位问题
- 关联版本发布：如果是新版本发布后新产生的告警，就首先考虑告警与发布的内容之间的关系，如果不能快速解决，就需要回滚版本
- 收集多组告警：收集一起出现的所有错误错误消息或错误日志，分析什么原因可能导致一组错误。 比如：
Unable to send PING command over channel: [id: 0xaabc5c3c, L:/9.165.34.233:57438 - R:10.62.15.30/10.62.15.30:6380]
Exception: Command execution timeout for command: (PING), params: [], Redis client: [addr=redis://10.62.15.30:6380]
Redis server response timeout (3000 ms) occured after 3 retry attempts. Increase nettyThreads and/or timeout settings. Try to define pingConnectionInterval setting. Command: (ZRANGEBYSCORE)
上面两个错误是突然出现的，如果只看第一个错误，就可能以为是redisson的bug(https://github.com/redisson/redisson/issues/3273)。实际上是因为命令ZRANGEBYSCORE在大key上执行，耗时太长，引发其他请求也超时
- 尽早定位：收到告警消息，需要尽早定位问题，防止错误扩散
有一次发布后，收到一个"订单不存在"的告警消息，因为看起来问题不大，也没有影响用户下单，就没有第一时间去定位，等第二次出现"结算单不存在"时，才觉得有新的问题，原来是自定义多数据源时，漏了自定义事务管理器，导致数据不一致
- 快速跳转：告警消息中需要携带关键信息，特别是调用链的traceId，并且可以点击跳转
- 减少无用告警：防止错误消息被无效消息淹没