下午正在写代码，突然收到一个小集群的机器高负载告警。运维同学也及时收到了公有云网络检测到的DDoS攻击告警。整体攻击流量不大，不到300m，毕竟咱之前也见过几十g的DDoS攻击了，并没有很紧张，况且是一个小集群，业务也没那么重要，影响不大。所以，当时想的是这人要干啥，这点攻击流量没啥意思，这一波会不会是试探，后面会有针对其他站点的大规模攻击，注意警戒，有问题及时反馈，协调各方围堵。
与业务相关的几个群及监控相关的群里也相继有人反馈问题，并被告之有DDOS攻击，大家注意观察，云上已经开启了清洗，一副战争已经打响，各部门严阵以待的样子~就这这时，突然某个群里，有个客户端大佬说，对应时间点下发了配置，导致客户端会多发一些请求。。。赶紧执行回滚，后面才慢慢恢复。一场自导自演的伪DDOS攻击进入尾声
事后回顾总结一下
- 运维大佬在公有云控制台看攻击ip很分散（当然，真实大规模DDOS，攻击方也是控制了很多肉鸡，IP基本不聚集），无法排除是真实攻击还是业务自身问题
- 客户端同学要有前端保护后端的意识：具体体现在每一个发起的请求都应该慎重，包括失败重试，循环请求，尤其是对APP的核心主路径。因为对客户端而言是一个请求，但是对于后端而言，是需要乘上实时的用户基数。
- 服务端同学要有不信任前端的意识：熔断、限流基本的能力要具备，日常容量buffer保持在合理水平，毕竟这里还涉及成本问题，后端可以支持海量，但不是随时随地无限容量。
- 此次事件本来影响的是A业务，但是有另外一个不相干的B业务反馈，他们的请求也变少了，B业务找我帮忙定位，看时间点和此次事件时间点完全对的上，经过对链路排查，两个业务从公网入口，到后端集群，到后端具体业务都是完全独立的，后端没有理由相互影响，大胆猜测还是客户端的问题，后来我提出会不会是客户端这里，两个业务请求走的是一个网络通道，A业务因为被认为DDOS，公有云做了清洗拦截，后端过载也有异常错误返回，必然导致客户端出现超时、失败情况。倘若客户端使用了一个网络通道，利用队列保持请求正确发出，A业务的失败可能引起后面请求的拥堵。经客户端几位同学的排查得以证实。
以上。
2021年04月02日
