我们有个博客服务,用WordPress做的,最初的目的就是给内部使用,所以当时设计的时候支持的qps很低,而且线上只用了一台机器部署。
虽然服务被压垮是个悲伤的事情,但是整个过程却是十分有趣。在此需要深深的感谢一下我们的运维团队。
1.运维团队发现博客服务压力过大,导致机器CPU到达100%。迅速通知到我们团队
2.运维团队迅速将机器扩容,从一台变为五台,但是五台机器的CPU迅速达到100%
3.运维团队对请求进行限流,服务和机器稳定下来
我们开始查看高流量的来源
1.查看日志,找到了最高请求的URL
2.查看日志,从15:30开始访问量急剧增加。怀疑该URL被发送了APP PUSH或者放在了高流量入口位置。
3.查看日志,确认都是手机访问的,但是没有refer,通过检查客户端IP,大多来源于印度,日志无法提供更多信息
4.找产品、策划、运营团队负责人,都表示没有做过相关操作
5.通过查看这个URL的内容,怀疑可能是浏览器团队做了什么事情。四处发动关系,找到浏览器团队负责人,因为负责人在开会,一直没有回应
6.找到一个安装海外MIUI的手机,打开浏览器,启动页为博客的URL。至此确定了来源。
告知运维后,运维决定将流量导到商城首页 - 凡是打开浏览器的用户,最先看到的是商城首页。服务得以正常运行,我们也收割了一些流量。
后来浏览器负责人看到了我们联系的内容,表达了歉意,并把启动页移除。
这次查找问题的历程还是蛮有意思的,从服务被压垮到收割流量,很大的一个反转。但是也暴露了很多问题:
1.使用其他组的服务,仅仅和业务方确认不够,一定要和服务所有人进行确认。因为业务方可能缺乏技术方面的一些思考,而且容易产生这种流量被收割,给他人做嫁衣的情况
2.机器资源有限。虽然扩容了4台机器,仍然满足不了需求,而当时只有4台适合扩容。机器资源问题在迁移NEO后会被解决。
3.机器扩容并非首选。以当时的流量来看,机器扩容后也撑不住,最好的做法是限流,同时知道URL后做nginx层缓存。因为扩容后,这些库容的机器CPU也到100%,影响了这些机器上面的服务。
4.突发情况没有应急预案。对于所有服务,高并发情况下,都应该有一套应急预案,按照预案走,可以处理的更加有章法一些。
最终在大家的努力下问题终于解决了,我们也在运维团队发现了销售鬼才,哈哈哈