电工培训,电工培训班,电工学校-湖南长沙阳光电工培训学校移动版

这篇整理主要记录几个点

1. 当出现一个线上问题的时候,如何快速定位?

2. 有什么理论来实现快速定位?

3. 事件树、故障树、决策树与贝叶斯网络
   

今天在和同事讨论一个问题:如果一个企业的交易订单量在异常下跌,如何快速的定位到底是什么原因引起的.比如是应用磁盘满了,还是其他monkey事件导致的?

同时晚上又遇到一个数据库的性能问题,一个线上应用要临时做一批任务,对数据库的调用量会上涨,我看了应用接口调用DB的响应时间,看起来是5ms左右就完成了任务,但DB的IOPS已经是到达最上限了.

最后依据个人的经验,把MySQL的binlog从半同步改成了异步临时解决了问题,IOPS降低了将近40%,但以后怎么更加快速的定位这个问题?

前几天还遇到一个问题,我对一台Buffer Pool 350G的 MySQL5.7.19进行truncate 空表测试,触发了InnoDB 脏页和redo 刷盘,堵塞了正常的insert,update,delete的线程,进而连Select也被堵塞了.看到印风也曾经遇到过这个问题,https://yq.aliyun.com/articles/41134 印风是直接pt-pmp打印MySQL的堆栈信息来定位问题,这算是一种暴力的方式,但可复用的成本的比较高.有什么办法可以让人一眼就知道是什么原因引起的?

以上的问题,可以归结为这么一个问题:当一个系统出异常,当一个DB出现性能异常,如何快速的定位到原因并进行解决.

又比如:如果一个电商网站的GMV在下跌?那到底是什么原因?是流量下跌了,还是用户转化率不高,亦或是用户去了别的网站?

如何评价一个数据库,只看数据库响应时间是否足够? 还需要看mutex.但还有些情况是mutex看不出来的,比如上面的猛刷脏页.还有曾经遇到过MySQL5.5在没有线程池的情况下,数前个并发连接操作就把DB卡死了(线程池可以解决这个问题).

上面的问题的解决方式,可以归结为按照经验来排查问题.经验是什么?口口相传的东西叫经验,复用的成本太高了,而且也能看出其实效率不是很高.

我曾经尝试过用时间和事件关联的方式来解决,逻辑是这样的"一旦出现问题,通过产生的时间来关联前后事件,并自动识别可能会导致该问题的操作信息".

这个方式最后也落地了,但效果不是很好.当时候的方式是一旦系统发生报错或者有什么异常信息,就自动去计算这个系统相关的事件和时间,但很多时候是系统本身就会报错,比如写入数据库,触发唯一键的报错.效果不是非常好.

系统报错的时候,反而是因为报错的信息很多,有同学把错误信息做了聚类,大家比较喜欢这个功能.

我目前能想到的一个更好的方式是: 尽可能得收集更多的数据,通过后台异步实时计算各个数据项的变化波动程度来进行分析.数据和指标实在太多,人肉看已经看不过来了.

比如一个外卖网站的流量突然上涨,很多人订餐,可以联合天气温度数据的变化(从18度上升到33度).

以上的问题,一直以来比较困扰我,写着写着,找到了一篇<<事件树、故障树、决策树与贝叶斯网络>> 的论文,发现能让我的部分困惑得到解答,整理上面的问题算是有所收获了.

最后,问一下大家,在这方面有否好的建议?

参考资料:

Netflix Chaos Monkey理论

<<事件树、故障树、决策树与贝叶斯网络>> https://wenku.baidu.com/view/7f70c946763231126fdb1109.html