17 | 故障处理最佳实践:应对故障
陈皓
该思维导图由 AI 生成,仅供参考
你好,我是陈皓,网名左耳朵耗子。
或多或少我们都会经历线上的故障。在我的职业生涯中,就经历过很多的线上故障。老实说,线上故障是我们技术人员成长中必须要经历的事。从故障中我们可以吸取到很多教训,也能让我们学到很多书本上学不到的知识。坑踩多了,我们会变得越来越有经验,也就成为老司机了。
不过,我看到很多公司处理线上故障的方式并不科学,而且存在很多问题,所以,今天这节课就来分享一些我的经验。这些经验主要来自亚马逊和阿里这两家互联网公司,以及我个人的经验总结。希望这套方法能够对你有帮助。
故障发生时
在故障发生时,最重要的是快速恢复故障。而快速恢复故障的前提是快速定位故障源。因为在很多分布式系统中,一旦发生故障就会出现“多米诺骨牌效应”。也就是说,系统会随着一个故障开始一点一点地波及到其它系统,而且这个过程可能会很快。一旦很多系统都在报警,要想快速定位到故障源就不是一件简单的事了。
在亚马逊内部,每个开发团队至少都会有一位 oncall 的工程师。在 oncall 的时候,工程师要专心处理线上故障,轮换周期为每人一周。一旦发生比较大的故障,比如,S1 全部不可用,或 S2 某功能不可用,而且找不到替代方案,那么这个故障就会被提交到一个工单系统里。几乎所有相关团队 oncall 的工程师都会被叫到线上处理问题。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
故障处理最佳实践:快速定位与恢复 本文分享了作者在亚马逊和阿里等互联网公司的故障处理经验,强调了快速定位故障源和快速恢复故障的重要性。作者提到了亚马逊内部的故障处理流程,包括oncall工程师制度和跨团队协作。针对故障源,团队可以采取重启和限流、回滚操作、降级操作以及紧急更新等手段来恢复系统。此外,文章还提出了故障前的准备工作,包括以用户功能为索引的服务和资源的全视图、设定故障的等级、故障演练以及灰度发布系统等。这些经验对于技术人员在面对线上故障时具有很强的指导意义,强调了减少故障影响范围和尽快修复问题的重要性。总的来说,本文强调了快速定位故障源和快速恢复故障的重要性,以及跨团队协作在故障处理中的必要性,为读者提供了实用的故障处理最佳实践。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《左耳听风》,新⼈⾸单¥98
《左耳听风》,新⼈⾸单¥98
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(53)
- 最新
- 精选
- 左耳朵置顶自动地图生成一般用APM式的系统。开源的可以看看zipkin2017-12-053120
- paul.yang耗子叔,我是个自学转行做后端的程序员。最近在日活快接近2亿的一个后端团队里面犯了个错误导致某一个功能20分钟不可用,受到了打击,我微博给你留了言,希望能跟你交流下,寻求指导帮助。希望你能看到我的微博留言,呵呵的卫国杨
作者回复: 微博回了
2018-07-2122 - kimi2013 年,应该是 8 月吧,和耗子哥一起处理巨石塔上千台服务器宕机的故障,搞到凌晨三四点2017-12-021162
- ibrothergang“请你来聊聊,你所经历过的线上故障,以及有哪些比较好的故障处理方法。” 我是一名移动端开发的工程师。移动端的开发工作和前端(线上环境)开发还是有一点区别的。移动端的开发一般在上线前会做测试,严重的问题一般在测试过程就解决了,很少情况发版后出现大面积的奔溃情况。但是线上环境不一样,线上环境发版的周期会大大短于客户端,很多的活动都会频繁的上线和下线。影响的范围也大于移动端。 遇到过最严重的一次事故是由于服务端的修改引起了移动端的奔溃。而且这个奔溃发生在 app 启动的时候。也就是说用户点了应用图标,起来马上就又闪退了。当时的 app 设计是起来后会去请求服务端的相关配置信息,相信很多的 app 也是这么做的。造成这个故障的原因是由于 app 对异常的处理不够完备,服务器端又恰巧修改了配置数据,导致 app 端拿到了一个引起奔溃的数据结果。后来因为是上班时间,发现问题后大家都在,及时恢复了服务端数据,遏制了事态的进一步发展,但是已经出现奔溃的用户由于在重新请求服务端数据前就奔溃了,只能通过发布新版本解决这个问题。 一旦服务端和移动端相互影响(往往是服务端影响移动端)引起的奔溃,往往是比较严重的,很多时候不得不通过发布新版本才能解决问题。所以移动端一定要做好服务端的异常处理。2017-11-28458
- 金胖子最典型的一次,项目组成员在测试版本中加了sleep来debug,结果上线的时候就把版本发布到生产,直接影响我第二天下午没能去看变形金刚2018-02-02154
- 艺漫漫每次线上故障处理都是知识体系验证和应用的战场。 2020-03-20/21这两天处理了2个p1级别的问题,一个问题导致几乎所有竞价服务宕机了,这个问题是因为redis内存使用达到机器的限制上限被杀了,导致使用该redis的server重启异常,立即处理操作是rm rdb后重启redis,后续预防措施是增加redis内存和cpu使用监控。另一个问题是所有订单竞价异常,查了很久,定位到直接原因是预算同步机制变慢导致订单因为预算问题不竞价,根本原因是大数据包导致网络延时,进而导致预算同步变慢。查找2问题的过程很值得记录:根据其他服务处理时间监控,发现其他非竞价模块处理时间也严重变慢,进而使用iftop观察网络吞吐,发现有一个server1的入口带宽异常,而server1上的服务处理时间正常,最后根据这台server1上redis的cpu使用率和slowlog找到一条高达13M的异常数据。2020-03-2226
- 晏出现故障时,最重要的不是 debug 故障,而是尽可能地减少故障的影响范围,并尽可能快地修复问题。2018-07-08211
- 郭新鹏代码逻辑错误,导致查看分享的人能看到分享者所有信息,记录的上一个人的cookie. Session存储在redis, flush db。所有用户重新登陆2018-06-25111
- 印哥爱学习楼上的,类似工具:鹰眼,watchMan,京东的CallGraph2018-05-10211
- 凉人。在bd实习的时候,有个很小的独立项目 项目中使用到容器和分布式文件系统,有种情况,当容器心跳检测时,如果检测失败,容器实例将产生漂移,漂移的过程会删除原容器的数据,所以产生一个情况,就是分布式文件系统里的数据都被删除。 导师和leader们快速定位了问题,数据也在是采用move的方式删除,很庆幸数据恢复了。也知道了一个项目的伟大是由一群有预见性的大佬们,和一堆可靠的同事们一起完成的。2021-04-018
收起评论