About neohope

一直在努力,还没想过要放弃...

秒杀及大促系统关键点

一、电商秒杀场景
0、尽早做好各相关团队的沟通,做好活动动员工作
1、搭建单独的秒杀系统,与核心交易系统隔离
2、做好静态资源缓存:浏览器、CDN、服务器缓存
3、通过JS,动态下发大促页面,大促抢单URL到秒杀时刻后才能下发
4、网关随机刷掉大部分用户,小部分进入到服务器,每台服务器只处理前N条数据,后续用户秒杀失败
5、redis分布式锁确保不会超卖
6、秒杀成功后,请求发送至核心交易系统
7、做URL验证,防止刷单
8、网关控制同IP流量,屏蔽部分云服务器IP段,防止部分刷单行为
9、提前做好性能测试及压力测试

二、电商大促场景:
0、尽早做好各相关团队的沟通,做好活动动员工作
1、业务上分时段大促,不同商品分流,缓解服务器甚至快递小哥压力
2、做好静态资源缓存:浏览器、CDN、服务器缓存
3、根据过往流量、商品浏览量、购物车商品数量,估算大促流量
4、做好扩容和运维保障工作:服务器、带宽、数据库根据预测流量,进行弹性扩容,而且要有一定比例的富余量
5、大促商品信息提前加载redis缓存
6、引入MQ,异步处理订单,消除业务峰值
7、做好PlanB,限流、降级、熔断,保证核心业务稳定
8、网关控制同IP流量,屏蔽部分云服务器IP段,防止部分刷单行为
9、提前做好性能测试及压力测试

打车软件功能拆解

一个打车软件,基本需要以下功能:

一、乘客:
1、行程管理:乘客叫车、行程取消、历史行程查看
2、乘客上车引导
3、乘客与驾驶员聊天功能
4、乘客与驾驶员虚拟电话沟通功能
5、行驶轨迹展示、规划行驶路线展示
6、目的地修改
7、乘客支付
8、打赏功能
9、驾驶员评价功能
10、投诉功能
11、消息通知
12、紧急联系人,一键报警,行程分享

二、驾驶员:
1、车辆开始接单,车辆停止接单
2、车辆实时位置信息推送
3、抢单、订单查看、订单取消
4、车辆到达确认
5、驾驶员与乘客聊天功能
6、驾驶员与乘客虚拟电话沟通功能
7、乘客上车确认,开始计费
8、结束计费
9、乘客评价功能
10、收入查看、提现
11、申诉
12、消息通知

三、平台:
1、地理信息系统与车辆网格划分
按GeoHash将城市划分为多个网格,收到车辆位置后,将车辆更新到各个网格;
2、平台派单
根据乘客起始地点,在乘客所属网格,就近派单;
考虑用户习惯,价格、车况等;
不能让乘客长久等待,适时给驾驶员奖励;
给同一驾驶员单子要有好有坏;
不同驾驶员要雨露均沾,不能造成饥饿状态;
不同业务要用派单或抢单模式;
3、行驶路线规划
4、等待时长预估
5、计费规则设置、计费功能
6、车辆位置采集,车辆轨迹记录
7、车辆在线时长统计,车辆收入及行程数统计
8、发票管理、行程单管理
9、客服系统,客诉处理,工单系统对接
10、消息通知:
短信、微信、APP
11、信用系统:
乘客信用
驾驶员信用
黑名单
车辆信息审核
驾驶员信息审核
12、标签系统:
乘客标签及画像,个人乘车偏好
车辆标签及画像
驾驶员标签及画像
13、行驶安全:
驾驶员疲劳管理;
防疫信息管理;
行程录音取证分析;
AI自动分析异常情况,识别争吵、车辆路径偏离,车辆长期不移动等情况;
紧急情况处理,安全人员及警方及时介入,通知乘客安全联络人;
14、基础数据管理
用户、权限、角色、组织、城市、车辆管理、驾驶员管理
15、外部对接API
订单接收,订单确认或取消,行程推送,行程状态同步,计费推送,费用结算

四、业务扩展:
1、市场营销:卡券管理、优惠活动
2、增值业务:保险售卖、加油卡售卖
3、在专车之外,可以开展出租车、顺风车、拼车、预约用车、代驾、企业用户等业务
4、入口从APP扩展到公众号、小程序、其他打车平台、电话

记一次分布式锁引发的生产问题

近期发版,要修复一个并发引起的主键冲突报警。

运维要求没有此类报警,组里同事顺手就改了。

结果第二天一早服务高峰期,服务直接卡死没有反应了。

快速定位到是这段代码的问题,回滚,解决问题。

然后分析了一下,开发、测试、架构都有问题:

原始逻辑:
1、服务A加了分布式锁L1
2、服务A调用服务B
3、服务B加了分布式锁L2
4、服务B调用数据库服务入库
由于加锁逻辑比较特殊,并发时,会造成主键冲突。

问题逻辑:
1、服务A加了分布式锁L1
2、服务A调用服务B
3、服务B加了分布式锁L1
4、服务B调用数据库服务入库
服务直接卡死,要么服务超时,要么锁超时,服务能不卡死吗

解决问题并不复杂,在这里就不罗嗦了。

问题是很简单,但暴漏的问题十分多:
1、开发对程序逻辑、分布式锁理解明显不够
2、在开发、测试、UAT环境下,开发和测试其实都发现了性能下降的问题,但都没有重视
3、架构和资深开发,代码审核工作问题也很大
其实很多时候,工具是一回事,但人员的专业性思维,其实更重要。

记一次HTTPS授权失败

我们伟大的云提供商告诉我们,他们廊坊机房要关停了,要求我们迁移到其他机房,春节前一定要迁移完毕。

和运维、架构沟通后,做了迁移计划,做了演练,虽然时间仓促,问题特别多,但还是扛过去了。

迁移后,不少用户受到了影响,比如有一个省由于网络供应商问题,整个省的用户无法解析DNS。

这其中,印象最深的是,我们一个用户,服务、配置、权限各种都是正确的。但就是无法登录。

分析了几个小时,最后发现,原来是用户机器时间不对,时差有几个小时,在HTTPS请求到达防火墙时,就被干掉了。

设好时间,一切正常。

其实,之前也遇到过两三次类似问题,频率太低了,一开始根本就没考虑这种可能。

重大黑客攻击事件2021

2021年黑客攻击事件核心趋势
1、史诗级漏洞震动全网:Log4j、PrintNightmare等“史诗级”漏洞爆发,利用难度低、影响范围广,从IT系统蔓延至工业控制,修复难度极大。
2、0day漏洞“军备竞赛”:微软Exchange漏洞被国家级APT组织(如Hafnium)大规模利用,数百万人数据遭窃,显示0day漏洞已成为攻击者手中的常规武器。
3、勒索攻击“物理断供”:勒索软件不再局限于加密数据求财,而是直接攻击能源(Colonial Pipeline)、食品(JBS Foods)、水务等关键基础设施,导致现实世界断油、断水、断粮。
4、供应链“单点爆破”:黑客通过攻陷Kaseya、Accellion、SITA等核心供应商,实现对下游数千家企业(如瑞典超市、航空客户)的“一键式”连锁打击。
5、数据泄露“全民裸奔”:T-Mobile、Facebook等巨头相继泄露数亿用户敏感数据(身份证、人脸、电话),个人隐私在黑产面前彻底透明。

2021年12月:Log4j漏洞爆发
事件经过:Apache Log4J库中的Log4Shell漏洞被公开披露,该漏洞允许远程代码执行,影响全球数百万系统。
攻击方式:漏洞利用(远程代码执行)
造成损失:成为史上最严重的软件供应链漏洞之一,全球各行业系统面临被入侵风险,修复漏洞投入大量人力物力。

2021年10月:Facebook(Meta)数据泄露
事件经过:由于API中的一个漏洞被利用,黑客在暗网论坛上出售超过5亿Facebook用户的个人数据,涉及用户包括姓名、电话号码、电子邮件地址和出生日期。虽然数据多为旧数据,但泄露规模巨大。
攻击方式:API接口漏洞利用、数据聚合
造成损失:Facebook再次陷入隐私丑闻,加剧了公众对社交媒体数据安全的不信任,为后来公司更名Meta后的品牌形象蒙上阴影。

2021年9月:T-Mobile数据泄露事件
事件经过:美国电信巨头T-Mobile遭遇大规模数据泄露,约5000万用户的敏感信息被窃取并在黑客论坛上出售。泄露的数据包括社会安全号码(SSN)、驾照信息、姓名和地址等。
攻击方式:未经授权访问、数据窃取。
造成损失:这是美国电信行业历史上最严重的数据泄露事件之一,导致用户面临极高的身份盗窃和金融诈骗风险,T-Mobile随后面临了巨额的集体诉讼和监管调查。

2021年9月:Twitch数据泄露
事件经过:全球知名游戏直播平台Twitch遭到黑客攻击,约125GB的数据被泄露,包括源代码、未发布的项目细节以及大量主播的收入信息。黑客将数据发布在4chan论坛上。
攻击方式:系统漏洞利用、数据窃取
造成损失:公司核心商业机密外泄,主播收入隐私曝光引发社区巨大争议,平台面临法律诉讼风险,暴露了互联网巨头在代码安全和访问控制上的疏漏。

2021年7月:Windows PrintNightmare漏洞危机
事件经过:微软Windows Print Spooler服务中被曝出严重的远程代码执行漏洞(CVE-2021-34527),该漏洞影响几乎所有主流Windows版本。由于该服务在域控环境中默认开启,一旦被利用,攻击者可完全控制服务器。
攻击方式:漏洞利用(远程代码执行)
造成损失:企业内网防御体系面临崩塌风险,安全团队被迫紧急禁用打印服务或进行高风险的补丁测试,全球IT运维人员陷入紧急“排雷”状态。

2021年7月:佛罗里达州水务系统攻击
事件经过:一名黑客入侵了佛罗里达州奥尔兹马尔市的水务处理系统。攻击者短暂获得了系统控制权,并试图将水中氢氧化钠(碱液)的含量提高到危险水平(从100ppm提高到11,100ppm),幸被操作员及时发现并阻止。
攻击方式:远程桌面软件入侵(使用被盗凭证)
造成损失:直接威胁城市公共饮水安全,暴露了工业控制系统(OT)与IT网络连接后的巨大风险,引发公众对关键基础设施安全的极度担忧。

2021年6月:Kaseya供应链攻击
事件经过:REvil团伙通过Kaseya的MSP平台漏洞,影响约60家Kaseya客户和1500家企业,勒索金额高达7000万美元;瑞典最大连锁超市Coop被迫关闭800家门店。
攻击方式:供应链攻击、勒索软件攻击
造成损失:全球大量企业运营中断,零售、服务等多个行业受影响,行业供应链安全风险引发广泛关注。

2021年5月:JBS Foods勒索软件攻击
事件经过:全球最大牛肉加工商JBS Foods遭受网络攻击,被迫关闭全球多个生产基地;公司向REvil勒索软件团伙支付1100万美元赎金。
攻击方式:勒索软件攻击
造成损失:全球食品供应链受冲击,相关地区肉类供应短暂紧张,企业经济损失惨重。

2021年5月:Colonial Pipeline勒索软件攻击
事件经过:黑客组织DarkSide对美国最大成品油管道运营商Colonial Pipeline发起攻击,加密其核心运营系统,迫使公司关闭系统5天;美国最大燃油管道运输公司因攻击被迫关闭管道,导致东海岸45%的燃料供应中断,美国宣布进入紧急状态;公司最终支付近500万美元赎金。
攻击方式:勒索软件攻击(通过钓鱼邮件植入恶意程序)
造成损失:美国东海岸燃料供应中断,汽油价格飙涨4%,美国总统宣布国家紧急状态,企业经济损失与行业动荡并存。

2021年3月:微软Exchange Server漏洞攻击
事件经过:黑客利用微软Exchange Server漏洞,在全球超30万台服务器上植入webshell,多个国家政府部门受影响。
攻击方式:漏洞利用、webshell植入
造成损失:大量机构数据泄露,政府部门信息安全受严重威胁,相关单位需投入大量资源进行漏洞修复与系统清理。

2021年2月:印度航空数据泄露
事件经过:黑客攻击航空数据巨头SITA系统,导致印度航空约450万名客户的个人及财务数据被窃取,泄露数据包含护照信息、信用卡号、出生日期及联系方式等敏感内容。
攻击方式:供应链攻击(通过第三方服务商渗透)、数据窃取
造成损失:大量乘客面临身份盗用与金融诈骗风险,航空公司声誉严重受损,并面临潜在的监管调查与罚款。

2021年2月:Accellion文件传输系统供应链攻击
事件经过:黑客利用Accellion旧版文件传输设备(FTA)中的零日漏洞,入侵了包括新加坡电信、新西兰储备银行、加拿大税务局在内的全球数十家机构。攻击者利用该漏洞窃取了大量敏感数据。
攻击方式:供应链攻击、零日漏洞利用
造成损失:大量金融机构、政府部门数据泄露,多家跨国企业被迫公开数据泄露事件,Accellion作为老牌文件传输服务商的信誉受到重创。

导致惨重代价的运维事故2021

2021年12月:微软Azure日本东部地区故障
事件经过:因电力设备故障,导致Azure日本东部地区服务中断超5小时,影响大量企业客户业务。
事故原因:基础设施运维事故,电力设备故障。
造成损失:客户业务中断,微软按SLA赔付,声誉受损。

2021年12月:西安“一码通” 短短半月崩溃两次
事件经过:12月20日及次年1月4日,西安“一码通”系统在半个月内连续两次崩溃。特别是在全员核酸检测期间,系统无法显示健康码,导致检测点排起长龙。
事故原因:系统架构无法承载峰值流量。虽然有疫情压力,但从运维角度看,是缺乏有效的弹性扩容机制和流量削峰设计,系统在面对突增的并发访问时直接“熔断”。
造成损失:疫情防控关键环节“掉链子”,严重影响了城市的防疫效率和秩序。
相关事故:
2022年1月10日,广州“粤康码”崩溃。
2022年3月11日,上海“随申码”崩溃。

2021年11月:网易游戏机房过热宕机
事件经过:网易游戏机房温度过高触发报警,部分服务器过热宕机,空调重启后仍无法解决,多款游戏无法登录、断连,3小时后服务器恢复正常。
事故原因:机房制冷系统故障,温度失控。
造成损失:干扰玩家游戏体验,影响游戏运营口碑。

2021年10月:Facebook史上最严重宕机
事件经过:10月4日,Meta旗下Facebook、Instagram、WhatsApp等服务全球中断近7小时,创2008年以来最长纪录,员工门禁卡、邮箱也无法使用。
事故原因:内部运维操作失误,修改BGP路由规则时误删域名服务器IP地址块路由配置。
造成损失:影响全球数十亿用户,Facebook市值蒸发约600亿美元,险些引发第三方服务连锁崩溃。
小插曲:宕机期间,大量用户涌向了Twitter、Telegram等其他应用,又进一步导致这些应用程序的服务器崩溃。

2021年10月:微软Azure 虚拟机全球故障
事件经过:10月13日,微软Azure云服务发生长达6小时的严重中断。全球范围内的用户无法启动、创建或更新Windows虚拟机,甚至连管理界面都打不开。
事故原因:服务管理操作期间的调用故障。在进行后台维护操作时,系统内部的调用机制失效,导致控制平面(Control Plane)失灵,用户失去了对服务器的“控制权”。
造成损失:企业无法管理核心云资产,业务扩展和维护受阻,再次打击了企业对公有云稳定性的信心。

2021年10月:Roblox 历史最长宕机
事件经过:10月28日,全球热门游戏平台Roblox发生了一次长达73小时的严重宕机。作为“元宇宙”概念的代表,这次长时间的停服让数千万玩家无法登录。
事故原因:负载均衡器过载与架构瓶颈。由于平台流量激增,负责分配流量的负载均衡器不堪重负,引发了内部网络的拥塞。Roblox坚持自建数据中心而非完全上云的策略,在应对突发流量洪峰时暴露了弹性不足的问题。
造成损失:平台信誉受损,玩家流失,且引发了关于“关键业务是否该上公有云”的行业大讨论。

2021年8月:英国Telstra数据中心火灾
事件经过:澳大利亚电信巨头Telstra伦敦数据中心因UPS故障发生火灾,导致一半大楼断电,部分区域受损。
事故原因:UPS故障引发火灾,烧毁供电组件。
造成损失:严重影响依赖该数据中心的金融及企业客户业务运转。

2021年6月:Fastly 内容分发网络崩溃
事件经过:6月8日,CDN服务商Fastly出现严重故障,导致全球大量依赖其加速的网站(包括Amazon、Reddit、CNN、PayPal等)在近1小时内无法访问。
事故原因:服务配置修改触发系统漏洞。Fastly工程师在进行一项常规的“服务配置”修改时,意外触发了系统底层的一个未被发现的软件漏洞,导致其全球节点瞬间瘫痪。
造成损失:互联网“基础设施”级故障,大量主流网站同时“消失”,凸显了互联网供应链的脆弱性。

2021年5月:Salesforce 全球大规模宕机
事件经过:5月11日,全球最大的CRM服务商Salesforce遭遇长达5小时的服务中断。这次故障波及全球,导致大量销售和客服人员无法访问客户数据。
事故原因:运维人员“走捷径”引发连锁故障。一名工程师在进行配置变更时,使用了有缺陷的脚本去绕过标准流程。该脚本在重启服务器时发生超时失败,但由于自动化部署机制未停止后续操作,导致故障在各个数据中心不断扩散,最终压垮了系统。
造成损失:全球数百万依赖Salesforce的企业用户业务停摆,作为“云服务标杆”的可靠性形象受损。

2021年4月:美国WebNX犹他州数据中心火灾
事件经过:美国WebNX犹他州数据中心发生火灾,导致超360万个网站故障,约1.5万名客户资料受影响。
事故原因:UPS故障引发火灾,缺乏物理隔离导致火势蔓延。
造成损失:部分数据永久丢失,客户权益受损,企业声誉受创。

2021年3月:法国OVH斯特拉斯堡数据中心火灾
事件经过:3月10日,欧洲云计算巨头OVH位于法国斯特拉斯堡的数据中心发生火灾,燃烧6小时后被扑灭,4个数据中心中1座完全烧毁。
事故原因:疑似UPS故障或电力室逆变器周围湿气引发短路。
造成损失:发生起火的SBG2数据中心被完全烧毁,360万个法国政府及企业网站瘫痪,OVH面临巨额赔偿和客户流失。

为何医院数字化转型项目难以成功

数字化转型,只能是一把手项目,除此之外注定失败。
国内多数的医院数字化转型项目,都是要求信息科来推进,医院领导和业务部门实际介入很少。
开局就十分不利。

产生这样局面的底层问题,在于两个:
1、组织架构老化
与欧美通常会有专业的CIO或CTO,中国多数医院的信息部门,受到的重视程度不够。
医院的信息科,其实主要就是一个运维部门,在医院组织架构中处于后勤部门一类。
这个组织架构已经几十年没变了,很难适应现代化的运营管理方法。
2、医院缺乏懂信息化的人才
国内多数的医院,十分缺乏懂业务、懂管理、懂IT技术的综合性管理人才。
直接导致了医院管理部门,与实际执行部门之间的脱节。
这样的人才不是没有,而是很稀少,且集中在顶级的那几家。
如果医院有这样的人,医院那真是捡到宝了。

再看看,中国多数医院信息科的现状(非顶级医院):
1、相对业务科室是很弱势的
对于大科室、大专家和大主任,沟通的时候处于绝对的劣势地位,几乎没有任何话语权
2、人员数量和质量不匹配
信息科的人员,主要是桌面和运维人员,一般数量很少。
多数人员,对现代化的技术缺少理解和一手落地经验,难以挑起技术变革的大梁。
3、资源投入严重不足
效益好的医院:对比软件和安全的投入,多数医院仍倾向于基建和采购设备,因为会带来新的收入。
效益差的医院:绩效发放已经很困难,就更不愿意在这方面投入更多的资源。
加之多数医院都是风险厌恶型号机构,就更难有人愿意去做这种变革了。

那一般项目是如何落地的呢?
信息科协调不到院内资源,根本无法推动大刀阔斧的改革,没法动里子。
就只能借助院外资源,也就是厂商,做做面子。
但厂商和医院是很难平衡利益关系的:厂商利润很低,急着上线验收,医院如果再缺乏正确引导,很难有好的结果。
最后结果,同一口径,骂厂商无能。

一次MacOS升级引发的灾难

一、上周帮老婆大人把MacOS从Mojave升级到了Catalina,然后悲剧发生了。
任何需要截屏、屏幕共享或屏幕录制的应用都不能使用了,具体表现为:
1、配置-》安全与隐私里,多了一个选项”屏幕录制/Screen Recording”,里面列表是空的。
2、快捷键录屏是可以的
3、打开QuickPlayer,录制屏幕,提示之前禁用过屏幕录制,要求去修改权限;但由于列表是空的,根本无法做任何操作
4、其他APP,如微信、腾讯会议什么的,提示要增加权限,但“屏幕录制”里还是空的。

二、网上找了一下,无论国内国外,都有一些用户遇到了这个问题。尝试了一些建议的方法,搞不定。

#正常模式下,显示失败
sudo tccutil reset ScreenCapture

#恢复模式下,显示成功,重启后无效
tccutil reset ScreenCapture

三、于是打电话给Apple,一位妹子远程视频帮忙处理了很久,把能重置配置的方式都用了,还是不行。最后建议我重装系统。

四、重装,没任何变化。

五、把系统升级到了Big Sur,好歹有了一点儿进展:
1、配置-》安全与隐私里,”屏幕录制/Screen Recording”,里面列表是空的,但是新增任何APP都无效
2、快捷键录屏是可以的
3、QuickPlayer录制屏幕是可以的
4、其他APP,如微信、腾讯会议什么的,提示要增加权限,但“屏幕录制”里还是空的。

六、找了好长时间,最后终于解决了,步骤如下:
1、重启系统,听到提示音时,按下Command+R,进入恢复模式
2、恢复模式下,开启Terminal,禁用SIP服务 (system integrity protection)

csrutil disable

3、重启系统,进入正常模式,重命名tcc.db文件

sudo mv /Library/Application\ Support/com.apple.TCC/TCC.db /Library/Application\ Support/com.apple.TCC/TCC.db.bak

4、重启系统,进入恢复模式
5、恢复模式下,开启Terminal,启用SIP服务 (system integrity protection)

csrutil enable

6、重启系统,进入正常模式
7、你会发现问题解决了

整体来说,这应该是MacOS升级的一个Bug,出现频率并不高,而且横跨两个大版本至今没有解决。
(也可以这么说,Big Sur解决问题的方式只是把QuickTime加白名单了,根本没有解决根本问题;或者说解决问题的Apple程序员可能根本没有定位到问题产生的原因)

我自己解决这个问题花费了4个小时以上,如果没有编程经验的普通用户遇到,估计只能格式化重装了,希望Apple可以出个工具,解决此类问题,节约大家的时间。

记一次Excutor引发的生产故障

当时看到《阿里巴巴Java编码规范》时,我感觉这里面说的不是大家都该知道的事情吗?真有必要汇总个规范出来?

出来混,总要还的,最近在老项目上就遇到了。

我们有两个服务,遗留项目,代码写的实在是不敢恭维。
用量其实不大,或者说偏小,但很默契的每两周挂一次,到今天是第三次了。

第一次OOM(没定位到根本问题):
K8S网络组件异常,DNS解析失败,和架构一起排查后,发现问题如下:
1、系统原来使用过RabbitMQ,后来代码注释了
2、但POM中,还是有MQ的引用,别的不会做,但会启动MQ的监听
3、结果有一天K8S网络组件异常,DNS解析失败
4、MQ的心跳包瞬间起了几千个线程,连接找不到的MQ Server
5、服务挂了

推断的问题链路为:
DNS无法解析-》MQ心跳包不断起线程,而且没有连接池-》线程耗尽内存-》OOM-》服务挂掉

解决方法:
在POM中,干掉了MQ的引用,以为问题被修复了。

第二次OOM(大意了):
1、表现仍是K8S网络组件异常,DNS解析失败
2、架构感觉容器DNS解析不了应该运维去查
3、只好拉上运维查,运维也比较给力,很快把日志给出来了
4、但是系统OOM时,并没有生成镜像,架构建议添加JVM参数,结果和运维排查后发现JVM参数已经加了,OOM应该有Dump啊
5、最后的结论是,非常规问题,等下次发生再解决
6、这个时候,已经感觉怪怪的了,问题根源根本没有找到啊,但大家都忙着机房搬迁,就没能跟下去(我的问题)

推断的问题链路为:
DNS无法解析-》不断起新线程去连接-》线程耗尽内存-》OOM-》但没有Dump文件-》无法定位问题

解决方法:
碰运气,等下一次OOM生成Dump文件?我当时咋想的呢

第三次OOM(真的解决问题了吗?):
1、感觉不对劲啊,为什么总是两周挂,于是拉取了日志
2、日志上没看出什么来
3、仍然没有OOM的Dump
4、jstack一看线程,傻眼了,一堆线程在waiting on condition
5、赶快看相关源码,居然是用了Excutor,然后线程和队列都是默认的
6、你懂的,线程数和队列默认几乎都是无限的,参数设置错误,导致线程池根本不会服用原来的工作线程
7、服务挂掉是早晚的事情

推断的问题链路为:
DNS无法解析-》不断起新线程去连接-》线程耗尽内存-》OOM-》但没有Dump文件-》无法定位问题

解决方法:
修改Executor默认配置

咋说呢,再次认识到规范强制推行也是必要的,全靠人的个人水平,是不行的。他们的规范,恐怕也是各种坑汇总成的结晶吧。

记一次PG引发的生产故障

前几天,突然收到报修,一个文件接收服务突然宕了。
我们运维同事很快就进行了重启,此时怪异的事情发生了:
重启服务后,服务一会儿就没响应了,端口可以通,文件全部上传失败,没有任何异常日志输出。

那就排查吧:
1、PG数据库连接正常,无死锁,表空间正常,数据查询秒回
2、服务配置几个月都没人改过,CPU、内存、存储、IO、网络,全部正常
3、上传客户端日志输出,显示其工作正常
4、只有文件接收服务,没有响应,也没有日志输出
初步判断,文件接收服务出问题了。

于是,新开一个云主机,重新安装服务,仍然无响应。
然后,拷贝了一个正常工作的主机,修改配置后,仍然无响应。
来来回回折腾了几个小时,还是不行。

无奈之余,试了一下向PG数据库插入数据,我去,几十秒都没有响应。
赶快问DBA,原来是做了高可用,主从库数据同步,从库异常了,导致主库可读不可写。
众人皆表示无奈,重启从库,问题解决。

其实,一开始就排查数据库了,但由于是生产库,只试过查询,没有试过写入。
但是,我们都大意了:
1、服务日志,输出不够详细,就算DEBUG打开,也不知道数据进行到哪一步了,这个最坑
2、没有正确的设置超时时间,原因是接收文件后,写入数据库一直在等待,服务日志没有任何数据库异常
3、数据库监视软件,只做了主库监视,根本没做从库监视
4、数据库主从配置,本应该是异步,但现在配置成了同步
5、没有监视主从库同步的情况
6、生产库,不敢轻易进行写操作,只看了查询效率及死锁,没有看慢语句

就这样一个小问题,绕过了层层监控机制,让问题排查十分困难,花费了大量的人力。
反思起来,如果只是为了记录日志而记录日志,但日志不能反应服务状态,那不如不记;如果只是为了监控而监控,但监控不到位,那不如不监控。
我们日常做事情,也是同样的道理,细节是魔鬼,把该把控的把控好了,才能提升效率,得到想要的结果。