周日的拼多多事件经过一个周日和一个周一的发酵，想必大部分人都已经知道了，有些人在感慨为什么自己每次都是在别人薅羊毛结束才知道没能参与，有些人在趁机推自家广告，有些人在做事件复盘总结...当然，我也难免落入俗套，也做个技术方面的总结，别人做过的总结我尽量避免重复，重点从开发人员角度说一下类似于拼多多这种量级的系统日常开发和运维要注意的一些问题。
一、监控
个人认为监控是这次事件里最值得关注的地方。一个成熟的系统，除了功能完善之外，监控是必不可少的。这里说的监控主要包括两方面，一是业务方面，一是接口级别。
1）业务方面的监控。当一个系统流量大到一定程度时，就可以额外出现很多数据，一定时间（一分钟或几分钟）内单量总量、一定时间内支付总额、一定时间内支付次数、相比上一小时的涨跌幅、相比昨日相同时间段的涨跌幅、相比一周前相同时间段的涨跌幅等等，明显的涨跌都可能有问题的。我们系统目前每天千万单，高峰期每分钟几万单，刚才介绍的这类监控都有了，任何涨跌幅超出预期都会报警
2）接口级别的监控。接口级别主要包含请求QPS、响应时间（tp99、tp90等）、异常等的监控。
这次事件，明显的接口请求量上涨以及业务指标上涨，正常都应该会触发报警。半夜遇到这种问题，如果有担心半夜报警看不到，可以考虑电话报警通知，自己之前接入过阿里大于和twillio等语音报警api，都是很容易的。
二、降级
翻看相关文章可以发现，本次薅羊毛事件里，开发人员中途处理过一次，然而并没有实际完成，导致没能及时止损。过程中，我相信处理人员已经认为自己的第一次操作已经解决问题了，但为什么自动上线却没有去确认，而问题就出现在会自动上线一次就可能自动上线第二次。
这类问题如何避免呢？我们最喜欢的处理就是降级，对这个券完全降级，或者对券相关的功能进行临时降级（当然，需要代码里提前留好降级开关及预案，且经过验证），出问题后不能直接确认影响或根本原因时，先降级保证不会再出现，再跟进细查。我们平时会要求任何可降级的操作都必须支持降级，相当于在开发时考虑好异常的情况，并在qa时验证降级的处理。
三、线上运维
很多人都说互联网公司工作累，要求24小时谁叫谁"到"（我经历的公司基本都是这个要求的），只要线上有问题，不管当前是什么时间，都要第一时间处理，自己不方便处理也要确认找到其他人处理，直至线上问题原因确认并得到解决。一个合格的开发人员一定要对负责的系统有主人翁意识。
印象深刻的是一次要赶早班飞机，凌晨5点半出发，走到半路领导发现第三方数据出问题了，就打开电脑开始解决，然后在登机之前参与了1个小时的处理，后来同事们挨个上线开始处理，等飞机降落时打开手机，发现同事们已经都处理好了。
四、敬畏心
线上任何操作（发布、调整配置、查问题等）都要保持一颗敬畏之心，不要有任何侥幸心理，阴沟里翻船是常有的事情，常在河边走没有不湿鞋的。如果是代码有问题带来线上问题，如何才能快速有效的解决问题是一件值得认真思考的事情。操作不慎或者有疏漏，很有可能扩大问题影响，或者引发其他问题。既然已经出问题了，那么沟通确认最佳的处理方式是非常关键的。
五、开发
接下来说下非常关键的，开发环节。流量越大的系统越需要注意细节，许多人总是感觉高并发系统特别神秘，其实高并发系统相比非高并发系统最大的差别，就是开发时对细节的注意。
举个最简单的例子，比如要做db更新操作，说白点就是执行一个update操作，该考虑哪些内容呢？普通的系统直接通过 XXXDao.updatexxx可能就ok了，高并发系统就不一样了，如果是我自己开发，我会考虑以下内容：
1）更新时一定要有返回值，并处理返回值
2）更新时要加乐观锁更新，这代表可能会乐观锁检查失败导致没有更新
3）更新时是否抛异常
为什么需要考虑这些内容呢？高并发系统由于流量大，网络随便出点问题影响都会被放大，服务器可能会宕机，db操作很容易出现短时间一堆超时（超时的异常可能成功也可能没成功），并发高时很容易出现更新的操作中间出现其他的更新操作，导致更新后不再符合业务正常逻辑...基于多种考虑，一个普通的update操作也需要考虑的很复杂。这也是高并发系统开发经验的宝贵之处，会培养你对每一行代码都要全面考虑的思维和习惯。
除此之外，开发过程中，还要额外考虑修改/新增的操作对系统及组件的影响（qps变化对服务器的影响、对db压力的大致影响、对涉及组件的大致影响、对其他业务的影响、出错后的降级处理...），养成习惯后，这些考虑点就是你开发任何一个需求任何一个接口都习惯性的考虑的点了。考虑的多了，出问题的概率就会小了。事前做的充分，总比事中慌乱、事后总结好的多。
关于开发，最后一点，是一定要认真review需求的细节及合理性，
六、事后总结
或许这个称作故障review更符合互联网公司的风格。既然线上出问题了，肯定是哪里做的不对，那么就需要相关人等坐在一起review一下根本原因，线上的问题基本上都是一连串各个环节有问题导致的。发现不足，提出改进建议，之后大家都去遵守避免出现故障的流程规范，那么以后线上才可能少出问题。总之，流程的规范非常重要。
其实，大公司线上出现故障非常常见，互相之间谁也没必要笑话谁，但是出现故障后如何快速有效的恢复正常却很能看出一个公司的水平，每个公司也都是在故障中逐渐成长，尽可能的避免掉一些没必要的故障。没有谁喜欢故障，没有谁希望自己是惹出故障的责任人，但是要尽可能的减少故障，必须不断的规范流程、强化开发能力及意识、多总结多改进。当前没问题不代表没有问题，也不要等到问题出现时才开始想着去改进。
最后，分享一个我们组最近的一个线上故障。一个核心业务的主库雪崩并持续1分钟，1分钟内该db几乎所有操作全部"异常"（后来确认部分是成功的，但是返回的是超时异常），带来了不小的数据一致性问题。这件事情给我们震撼很大，之前我们知道某些场景会带来数据一致性，一直认为问题不大，就没高优先级处理。事实证明，我们根本承受不起这种问题严重化的代价，系统该改进的点绝不能拖延！目前整个系统的事务一致性、数据一致性已变成组内优先级最高的事情，必须尽早消除隐患~
···········
欢迎大家关注课程：
共同学习，写下你的评论
评论加载中...
作者其他优质文章
