自动地图生成一般用APM式的系统。开源的可以看看zipkin

耗子叔，我是个自学转行做后端的程序员。最近在日活快接近2亿的一个后端团队里面犯了个错误导致某一个功能20分钟不可用，受到了打击，我微博给你留了言，希望能跟你交流下，寻求指导帮助。希望你能看到我的微博留言，呵呵的卫国杨

2013 年，应该是 8 月吧，和耗子哥一起处理巨石塔上千台服务器宕机的故障，搞到凌晨三四点

“请你来聊聊，你所经历过的线上故障，以及有哪些比较好的故障处理方法。” 我是一名移动端开发的工程师。移动端的开发工作和前端(线上环境)开发还是有一点区别的。移动端的开发一般在上线前会做测试，严重的问题一般在测试过程就解决了，很少情况发版后出现大面积的奔溃情况。但是线上环境不一样，线上环境发版的周期会大大短于客户端，很多的活动都会频繁的上线和下线。影响的范围也大于移动端。 遇到过最严重的一次事故是由于服务端的修改引起了移动端的奔溃。而且这个奔溃发生在 app 启动的时候。也就是说用户点了应用图标，起来马上就又闪退了。当时的 app 设计是起来后会去请求服务端的相关配置信息，相信很多的 app 也是这么做的。造成这个故障的原因是由于 app 对异常的处理不够完备，服务器端又恰巧修改了配置数据，导致 app 端拿到了一个引起奔溃的数据结果。后来因为是上班时间，发现问题后大家都在，及时恢复了服务端数据，遏制了事态的进一步发展，但是已经出现奔溃的用户由于在重新请求服务端数据前就奔溃了，只能通过发布新版本解决这个问题。 一旦服务端和移动端相互影响(往往是服务端影响移动端)引起的奔溃，往往是比较严重的，很多时候不得不通过发布新版本才能解决问题。所以移动端一定要做好服务端的异常处理。

最典型的一次，项目组成员在测试版本中加了sleep来debug，结果上线的时候就把版本发布到生产，直接影响我第二天下午没能去看变形金刚

每次线上故障处理都是知识体系验证和应用的战场。 2020-03-20/21这两天处理了2个p1级别的问题，一个问题导致几乎所有竞价服务宕机了，这个问题是因为redis内存使用达到机器的限制上限被杀了，导致使用该redis的server重启异常，立即处理操作是rm rdb后重启redis，后续预防措施是增加redis内存和cpu使用监控。另一个问题是所有订单竞价异常，查了很久，定位到直接原因是预算同步机制变慢导致订单因为预算问题不竞价，根本原因是大数据包导致网络延时，进而导致预算同步变慢。查找2问题的过程很值得记录：根据其他服务处理时间监控，发现其他非竞价模块处理时间也严重变慢，进而使用iftop观察网络吞吐，发现有一个server1的入口带宽异常，而server1上的服务处理时间正常，最后根据这台server1上redis的cpu使用率和slowlog找到一条高达13M的异常数据。

出现故障时，最重要的不是 debug 故障，而是尽可能地减少故障的影响范围，并尽可能快地修复问题。

代码逻辑错误，导致查看分享的人能看到分享者所有信息，记录的上一个人的cookie. Session存储在redis, flush db。所有用户重新登陆

楼上的，类似工具:鹰眼，watchMan,京东的CallGraph

在bd实习的时候，有个很小的独立项目 项目中使用到容器和分布式文件系统，有种情况，当容器心跳检测时，如果检测失败，容器实例将产生漂移，漂移的过程会删除原容器的数据，所以产生一个情况，就是分布式文件系统里的数据都被删除。 导师和leader们快速定位了问题，数据也在是采用move的方式删除，很庆幸数据恢复了。也知道了一个项目的伟大是由一群有预见性的大佬们，和一堆可靠的同事们一起完成的。