今年的2019双十一高峰基本上落下帷幕了，一般情况下是为期一周，到今天17号，我们做到了2019年双十一高峰期间核心业务0故障，稳如山，从双十一前一个礼拜到今天，半个月的时间，相比去年，今年感觉特别的漫长，可能是自己的心中的责任更大了些，在一线站久了好像也麻木不了，反而会更紧张。。。
2018年的双十一高峰我也做过总结，原文地址： https://my.oschina.net/110NotFound/blog/2885795
去掉敏感的业务数据，下面就说下今年双十一的大致技术上的过程。
2019年双十一技术类过程回放：
11.10号之前我们做了很多优化，还因为优化领了一个严重生产事故（ 记一次字符类型转换发生的生产事故 ），迁移了几个kafka集群和扩了es集群.（ 大型kafka集群平滑迁移 ）
11.10号下午小会议总结下今年双十一高峰期的各种问题预案。
11.11号迎来了双十一，因为是物流业务，所以这一天的量和平时差不多，高峰期在后头。
11.12号，量开始显著上升，已经高于去年双十一的最高峰，这天我们出现了es某些节点写入瓶颈，读取瓶颈，当天晚上紧急进行某些es节点替换到ssd机器。
11.13号凌晨2点多es节点迁移替换完成，又发现了一个查询服务节点宕机的问题（ 双十一期间查询服务某节点OOM原因分析 ）。
11.13号所有数据量相比平时都有了翻倍，白天就开始突破昨天的最高峰，到了下午，各类接口的qps达到历史最高值，我们最核心的那套redis集群的qpm已经超过百万，这只是其中一套集群的qpm。
11.13号下午，下午16点20分左右，流量的猛增，某网卡可能因为老化等硬件因素出现抖动，备用网卡自动切换上去，应用受到短暂影响，某kafka集群因为网络因素出现消息提交失败，但是马上自动恢复。下午5点，核心应用的cpu告警都开始爆发，但是对应用是没有影响的，因为我们预留了的机器的CPU配置是告警阈值的两倍，当天晚上为了安全起见，向上级领导请示凌晨开始对告警的应用的机器进行扩容CPU，迎接14号的更高峰。
11.14号早上高峰到来，因为很多机器扩了CPU，稳了很多，这一天流量达到最高峰，数据量也是最高，派件核心的数据库平均的qps过了1W，把监控拉细了看，3W的qps也是超过了的。
15号很稳，基本上就平稳了，若干个小问题的出现，和之前一样，别的应用出现波动，但是我们的接口调用的时候做了熔断，所以不会影响主流程。 比如有一些老的代码有导数据的功能，这个特殊时期的数据量是很大的，应用本身负载也很高，就导致了出现导数据的逻辑被执行后，内存暴增发生GC，导致其他线程处理变慢，紧接着就是超时。 还有的应用因为突然的业务量增加，线程池不够用，导致RPC调用过去的时候发现线程池满了等待超时报错。
16号周六虽然量还是很大，但是基本上平稳了。
17号，稳。
总结：
这次的双十一基本全组的同学精神都是崩的紧紧的，这个礼拜真的是漫长又漫长。这次双十一的高峰总体来说还是很顺利的，相比较以往，这次是核心服务0故障，稳如山，即使是出现了一些边角的小问题，对用户也是无感知的，这个有一部分原因要感谢之前做的sentinel限流降级熔断机制。
通过这次的双十一考验，发现监控真的一定要做好，最基本的CPU内存网络磁盘，这四个基本的监控一定要有，其次就是接口层的监控，响应时间，执行时间等。各类中间件的监控也是需要好的支持。更重要的是告警，现在的告警其实有点乱，有的告警很严重的研发并不知情，因为这个是历史遗留问题，所以在双十一之前我准备了一个小工具应对，写了个告警机器人对接企业聊天工具，实时监听爬取公司总的告警系统，在发现有告警，直接通知到研发群，为什么要这么做？因为核心业务的下游有很多的别组的应用，当别组的应用出现问题，会间接的影响到核心业务（这个不管在理论上还是实际上都已经证实，即使是做了熔断）。
告警的响应，这个需要考验团队合作能力，因为运维首先收到告警，必须能在第一时间知道这个问题大致是哪个业务线，跟踪到具体的研发团队去处理这个问题。（目前还存在未知的情况，这个问题值得思考）
研发团队的紧急预案，这个其实很重要，如果一旦发生问题，需要研发人员马上介入进行处理，最后一道防火墙。
业务划分，在双十一之前，就需要把熟悉相应系统的人员安排到相应的应用，出问题的时候可以第一时间找到问题所在，进行技术支持。
团队合作，不是嘴上说的团队合作（表面兄弟），这一点我感觉我们团队做的非常棒，在特殊时期需要所有人的心拧成一根绳，遇到问题的时候不管是不是自己的问题，都要了解关注一下，因为业务链路长，指不定走到哪里了就和自己的业务线交接上了。巴西丛林的蝴蝶煽动一下翅膀,就可以引起美国德克萨斯州的飓风。
技术优化和性能评估，这种东西是创造不了直接收益的（毕竟公司的目的是赚钱），甚至会打击你的自信心（技术优化把BUG优化出来了），但是有追求的研发人员还依然会去做，虽千万人吾往矣。不过话说回来，在双十一之前一定要做技术优化和系统性能评估，而且一定要在高峰期之前的至少半个月前完成，如果发生了问题才有机会补救。（技术优化有的时候是存在风险的，解决了一个BUG，又引入了两个新的BUG。。。） 今年我们的性能评估没有估算准确，因为还是出现了高峰期间晚上加机器抗第二天的高峰，对于技术类的问题，研发人员应该站在一个中立的角度来思考问题（我必须承认我当时考虑了成本问题，当然很大一部分原因还是估算不准，没有过这种经历，高峰期一年比一年高，还是翻番的）。
