新浪、百度、淘宝以及其他的一些大型互联网系统,在出现故障之后,一般的处理思路、流程和方法是怎么样的( 五 )




上图是一个简化过的两地三中心的架构,这不是单机Web,只是一个Web集群。MySQL依然是最开始业务所支持的中间件MySQL集群,基于链路架构图画出来,包括应用跟踪可以实现到的错误故障或耗时,可以实际的展示到图表上,这种应用拓扑其实是真实的反映了现有业务运维架构。
新浪、百度、淘宝以及其他的一些大型互联网系统,在出现故障之后,一般的处理思路、流程和方法是怎么样的


第三块是链路回放,上图是Login页面,一个用户登录需要完成什么?所有的程序调用会像链路一样展现出来,例如,调用第三方API、传入、传出、消耗时间、连接中间件、插入的数据、反馈的数据等。主要核心是做故障定位,例如,基于应用层面,某一个业务登录发生非常严重的下降,我们在链路跟踪中打开登录页面,就能详细的知道,API无法提供服务,导致业务故障。整体上关于链路,整个质量保证处于中间那一块,核心是从上到下访问链路,来解决质量的相关问题。
以上内容来自童传江老师的分享。
文末福利
看了童传江老师的精彩演讲,你是否有了新的启示?将此文转到朋友圈并截图给我们,即可获得本文完整演讲PPT哦!


新浪、百度、淘宝以及其他的一些大型互联网系统,在出现故障之后,一般的处理思路、流程和方法是怎么样的



■网友
我这边的业务可能复杂些,不会轻易做回滚操作,除非100%确定是代码变更引起的。代码变更我们是通过environment来尽可能避免生产环境影响。故障后期处理主是要:1. 查找原因2. 影响面,时长与范围3. 改进建议大伙的做法应该是差不多的。99%的故障都来源于变更,处理好变更也就可以说运维成功了一半。


推荐阅读