一次生产环境P0级事故分析( 三 ) _P0级事故

整体负载均衡方案也有问题，只做了服务器负载，系统整体架构是A-->B-->C这种形式的，如上图，策略只针对两台服务器的服务1所在端口做了负载，就是如果服务1端口没有问题，服务都会一直过来。如上图链路上服务2，服务3不管出现什么问题，请求还是照样会过来的。

厂商其实是个小代理商，设备也比较low，前期的时候也比较拽，上面的几个问题据说前期都是沟通过的，但是人不配合。做过政府信息化软件的都清楚，内部会涉及多方博弈，有时候很多问题不是技术能解决的。

这次事故也算是一件好事，至少让甲方意识到设备是有问题的，叫上了设备供应商对负载均衡各项内容进行了调整；对我们来说，甲方的炮火也适当转移了一部分，我们的压力也减轻了。

解决措施

增加了服务监测(原来的端口监测保留，也增加其他服务的端口监测)，为了不影响系统运行，我们针对每个服务额外编写了一个监测服务接口，专门用于设备配置服务监测。(因为老系统是基于jsp运行的，所以不能是html页面，需要jsp页面，返回200表示正常，其他就是异常
访问策略修改成轮询策略，平衡分布请求流量
调整程序配置，支持服务之间负载(类似分布式架构)

服务和端口监测场景

文章插图

服务访问场景

文章插图

所有内部服务访问都通过负载去转发，做到每个服务都高可用。
需要承担的风险：
1、高度依赖负载均衡设备的稳定性，以前请求较少，现在请求都会经过。(后面出现过一次负载扛不住压力，系统全面崩盘的情况) 。
2、会话保持需要依赖于软件架构的设计，如果会话保持无法做到，此套架构无法使用

当时负载均衡策略根据上述的方式做了调整，效现场果还是不行。

当时设置完成以后，厂商才告诉我们，老的设备监测有问题了，要10分钟才会切换(好像是老设备的问题)，需要更换新的设备才行。10分钟对业务来说太长了，这种效果根本没用。

回到当时内部的多方博弈，业务部门要求换，信息部门要求我们软件供应商写一个保证，更换设备以后，系统100%不出问题。这种说法就是耍流氓了，我敢说没有一家软件公司敢说自己产品100%没有Bug，再说硬件负载切换更换，为什么要软件公司来保障。后来这个事情就不了了之了。

网上经常说的那句话，“往往最朴素的方法就是最有效的方法”，甲方后来也知道他们硬件设备不行，采用了重启大法，他们会定期(差不多一个月)的样子，重启下所有设备，后面确实没发生什么大问题了。

后来我们在公司内部完全模拟了现场的情况，采用了国内知名硬件厂商的负载均衡设备(不打品牌了，有打广告的嫌疑)，发现效果非常理想，可以达到预期的切换的效果。说明说做的策略没有任何问题。

系统宕机，无法恢复
9.25下午开始，那就是灾难性的了，也是那天，所有领导齐聚现场，安抚客户。这天出现了将近三个小时无法恢复系统，业务直接停摆。

黑色的一个星期五，我也是在这天到现场的，前面都是远程指挥的(开发负责人在现场)

文章插图

整个事件莫名其妙来，莫名其妙走，从星期五晚上开始(通宵了两晚)，一直到星期六半夜里吧，经过多人的头脑风暴以后，才基本确定了问题的所在。

真的找到问题以后发现过程很可笑，但是代价太惨痛

前面我们是一直在怀疑是中午12:00左右更新的代码引起的问题，因为从各种现象来说，就是更新了以后出现的问题，但是经过一个多小时的反复验证和讨论，直接排除这方面的原因，那时候就直接开玩笑说了，敢用脑袋担保新加的代码是没问题的。
后面开始翻看各种本地日志，那时候日志文件很大，好几百兆(其实这个文件大小就是有问题了，只是所有人都没意识到，为了排查方便，是每天备份清理日志的，正常业务不应该产生这么大的日志，况且这天下午基本没有业务办理，只是那时候我刚到，不了解情况，也没多想)，日志非常大，加载又慢，看了一大堆无用的运行日志，没发现任何有价值的信息