37 | 遇到线上故障，你和高手的差距在哪里？
该思维导图由 AI 生成，仅供参考
遇到线上故障，新手和高手的差距在哪里？
新手遇到复杂的线上故障，不知道该怎么下手
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
大厂处理线上故障的机制值得借鉴，包括故障报警和轮值机制、实战演习、日志记录和分析工具。故障处理需要快速评级、恢复生产、分析原因并修复，并记录全过程提出改进方案。正确的人应第一时间响应故障，大厂采用轮值机制确保最熟悉服务的人员待命。实战演习可测试备份恢复方案的可行性，如Netflix的混乱猴子军团测试生产环境稳定性。日志记录和分析工具是最有效的定位问题方式，大厂的实践可借鉴到项目中。文章提供了线上故障处理的基本原则和课后思考问题，鼓励读者分享讨论。
《软件工程之美》，新⼈⾸单¥59
全部留言(11)
- 最新
- 精选
邢爱明我在传统的制造业甲方公司，系统大部分是内部管理系统，对于线上故障处理，个人一直有几个疑问，希望老师能给一些指导意见: 1. 谁来主导线上故障处理的过程？我们现在定的是产品经理，这个岗位用户安抚、信息同步方面做的比较好，但由于完全不懂技术，对排查原因、制定解决方案基本帮不上忙。 2. 故障排查是不是应该有一个标准的分析过程，让运维、开发、安全各方能更好的协作？如判断影响范围、分析系统资源是否有瓶颈、查看系统日志报错信息、分析最近发布等等。目前一旦有线上事故，由于分工不同，大家在排查的时候容易出现扯皮的现象，运维说系统资源没问题，开发做最近没做发布，很影响故障的恢复进度。 3. 便利性和安全如何平衡？目前处于安全考虑，开发人员不能登录生产的应用服务器，一些核心系统生产数据库也不能查询数据，只能查看tomcat日志；而运维人员完全不懂系统的功能，tomcat的日志也不看。这样的安全限制在故障排查的时候造成了信息的割裂，难以快速对故障进行定位。作者回复: 1. 谁主导线上故障，我觉得有两个指标要考虑： 一个是这个人或者角色要懂技术懂业务，这样出现故障，能对故障进行评级； 另一个是要能调动开发和运维去协调处理，这样出现故障能找到合适的人去处理，不然也只能干着急。 2. 故障排查上： 如果是操作系统、数据库、网络等非应用程序故障，应该是运维负责； 如果是应用服务故障，应该是开发去负责，即使开发最近没有去做发布也应该是开发去查。因为只有开发对于应用程序的结构才清楚，才能找出来问题。排查过程中，运维要给予配合。 3. 应该搭建起来像ELK这样的日志管理系统（可参考《38 | 日志管理：如何借助工具快速发现和定位产品问题 ？》），将应用程序日志也放上去，这样正常情况下就不需要去登录服务器了，直接就可以通过日志工具查看到异常信息。另外，一些特殊情况应该允许开发人员登录服务器排查定位。
2019-05-3028
纯洁的憎恶新手用野路子解决问题，高手用模型解决问题： 1.给问题评级。紧迫的调动优势资源先解决，一般的往后放放。 2.尽快恢复生产。生产是企业的首要职责，遇到问题优先恢复生产，减少直接损失，然后再正式的解决问题。 3.找到问题出现的位置。“搜集证据”，通过“粗调”在时空上缩小包围圈，再用“精调”明确问题点，运用排除法最终锁定问题。 4.分析原因，修复问题。 5.提出解决方案。钥匙不一定插在锁眼里，要沿着问题的线索不停“倒带”找到根源。再针对根源，站在系统和流程的高度制定解决方案，避免问题复现。 重点： 1.通过故障报警+业务骨干轮值机制，让正确的人第一时间响应问题。 2.通过实战演习，确保应急预案稳定可行。 3.通过使用日志记录和分析工具，积累、整理日常生产信息，出现问题才有得分析，否则重现问题也无济于事。作者回复: 👍感谢分享补充！
2019-05-258
鲍勃我是做物联网(嵌入式)Linux相关的开发的，感觉有一点就是：解决问题后，总结做的不够。需要不断学习和实践作者回复: 总结还是蛮重要的。因为出了故障，多少反映出整个开发流程可能是存在问题的，比如开发时没有写自动化测试和代码审查，测试时没有充分测试各种路径。总结后，就可能会找出来这些潜在问题，比如说增加针对这类Bug的自动化测试代码，增加代码审查，测试时增加对这类Bug的测试用例，从根源上改进这些问题，从而做的更好。
2019-05-254- calvinsBug故障，我觉得从三个方面考虑，第一，预防，包括应急方案，多维度评审，充分测试等，第二，排查，怎么快速定位，分析问题，这块高手和新手最大的差别是经验和知识面，有一套完整分析的流程和工具是非常重要的。第三，处理，怎么形成一套完整的处理流程，常见的是先预警，建立故障问题，itil系统流程跟踪，最终解决问题，后续就是反思总结，经验分享，但是从目前接触得大多系统来看，三个方面都有涉及，过程还不是特别理想，特别涉及多系统接入，扯皮还是不少的。
作者回复: 👍赞总结！ 帮补充一点：遇到线上故障，第一时间恢复生产非常重要！
2020-04-093 
hua168老师，像大点的公司一般都会有业务监控系统吧，直接用业务监控会不会有帮助？ 比如比较著名的CAT（地址：https://github.com/dianping/cat） 像日志监控系统也运维写的吧，是不是开发给一个监控的API就行了？作者回复: 有关这部分内容，可以参考下一篇的内容，会有更详细的介绍。 CAT是很好的业务监控系统，用好了一样可以很有帮助。 日志监控系统不需要自己从头写，开发或者运维搭都可以，搭建好了做一些配置或者二次工作就好了。
2019-05-273- alva_xu这是ITIL要解决的问题。我觉得最主要还是从三个方面来看。一是从流程上，对于事件管理、问题管理、变更管理、服务等级管理等，要有明确的流程。二是要有合适的工具，比如ticket系统，CMDB，监控工具、日志平台等。三是从人员组织来看，要有一线、二线和三线团队的支持，根据所创建的ticket的严重性和紧急性，给予不同level的支持。当然这也是目前流行的devops要解决的问题。
作者回复: 🙏谢谢补充：在对故障评级后，还应该要提交ticket用来跟踪整个故障解决的过程。
2019-05-273 
梁中华最好的方式是不出现问题，事情做在前面，多做设计评审和测试用例评审，大点的项目要做上线方案评审和应急回滚方案，当然灰度发布几乎是必须，staging环境验证也是必须的。作者回复: 👍对，预防是最好的！只是再怎么预防还是有发生故障的可能，所以各方面准备措施都需要准备齐全。
2019-05-262
风翱目前线上故障，是直接通过工作群反馈的。 目前大小问题都要立即（包括春节期间）响应处理。一看到有消息，所有人员都绷紧了一条线。 故障评级和对应的处理策略是可以借鉴引入的，轮班制度也需要建立，不至于出现联系不到人的情况（要让所有的研发人员7*24小时待命是不现实的）。作者回复: PagerDuty这个产品可以了解下看看，很适合用来做故障报警工具，不知道国内是否有同类产品。
2019-06-271
ifelse
今天带你一起学习了线上故障的处理。对于线上故障的处理，基本原则就是要先尽快恢复生产减少损失，然后再去查找原因，最后不要忘记总结复盘。--记下来2022-07-06
巫山老妖
稍微总结了下： **新手处理线上故障** - 遇到复杂的线上故障，不知道怎么下手 - 遇到线上故障，会想着马上修复Bug，匆忙打补丁，可能会引入新的Bug，造成更严重的损失 - 不知道如何快速定位Bug - 解决完线上故障，可能还会重犯 **高手处理线上故障** - 会有一套解决问题的步骤 - 第一步，评估影响范围 - 第二步，试图重现问题 - 第三步，临时方案和终极方案 - 第四步，风险评估及持续优化 - 遇到故障，会先评级、评估影响范围，优先保证业务可用，恢复生产，再考虑修复Bug - 通过有效手段重现Bug，逐步缩小问题范围，定位具体的错误位置 - 会仔细分析Bug产生的原因，从根本上解决，避免类似的故障再次发生 **大厂处理线上故障值得借鉴的地方** > 大厂其实是把高手解决故障的方式，变成故障处理的流程和操作手册，并且通过反复地故障演习。不断练习和强化对故障处理的流程，让系统更健壮，让新手也可以快速上手，做到高效处理线上故障。 - 故障报警和轮值机制 - 找对故障服务最熟悉的人 - 轮值on call，报警响应 - 实战演习（混沌工程） - 日志记录和分析工具（搭建ELK或Splunk这样的日志分析系统） - 其他好的实践 - 灰度发布策略 - 开关控制灰度 这节课让我更深刻的了解处理线上故障的实践，前后端解决具体问题的方法可能会有所不同，但总体解决策略和思路是类似的。关于工程师解决问题的和分析问题的能力其实也是我们的核心竞争力，如何更好的解决问题，提升业务价值，是我们在整个成长过程中需要不停去思考并践行的。2020-02-28
