软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6699 人已学习
课程目录
已完结 54 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 你为什么应该学好软件工程?
免费
特别放送 | 从软件工程的角度解读任正非的新年公开信
学习攻略 | 怎样学好软件工程?
基础理论 (9讲)
01 | 到底应该怎样理解软件工程?
02 | 工程思维:把每件事都当作一个项目来推进
03 | 瀑布模型:像工厂流水线一样把软件开发分层化
04 | 瀑布模型之外,还有哪些开发模型?
05 | 敏捷开发到底是想解决什么问题?
06 | 大厂都在用哪些敏捷方法?(上)
07 | 大厂都在用哪些敏捷方法?(下)
08 | 怎样平衡软件质量与时间成本范围的关系?
“一问一答”第1期 | 30个软件开发常见问题解决策略
项目规划篇 (8讲)
09 | 为什么软件工程项目普遍不重视可行性分析?
10 | 如果你想技术转管理,先来试试管好一个项目
11 | 项目计划:代码未动,计划先行
12 | 流程和规范:红绿灯不是约束,而是用来提高效率
13 | 白天开会,加班写代码的节奏怎么破?
14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决
15 | 风险管理:不能盲目乐观,凡事都应该有B计划
16 | 怎样才能写好项目文档?
需求分析篇 (5讲)
17 | 需求分析到底要分析什么?怎么分析?
18 | 原型设计:如何用最小的代价完成产品特性?
19 | 作为程序员,你应该有产品意识
20 | 如何应对让人头疼的需求变更问题?
“一问一答”第2期 | 30个软件开发常见问题解决策略
系统设计篇 (4讲)
21 | 架构设计:普通程序员也能实现复杂系统?
22 | 如何为项目做好技术选型?
23 | 架构师:不想当架构师的程序员不是好程序员
24 | 技术债务:是继续修修补补凑合着用,还是推翻重来?
开发编码篇 (7讲)
25 | 有哪些方法可以提高开发效率?
26 | 持续交付:如何做到随时发布新版本到生产环境?
27 | 软件工程师的核心竞争力是什么?(上)
28 | 软件工程师的核心竞争力是什么?(下)
29 | 自动化测试:如何把Bug杀死在摇篮里?
30 | 用好源代码管理工具,让你的协作更高效
“一问一答”第3期 | 18个软件开发常见问题解决策略
软件测试篇 (4讲)
31 | 软件测试要为产品质量负责吗?
32 | 软件测试:什么样的公司需要专职测试?
33 | 测试工具:为什么不应该通过QQ/微信/邮件报Bug?
34 | 账号密码泄漏成灾,应该怎样预防?
运行维护篇 (6讲)
35 | 版本发布:软件上线只是新的开始
36 | DevOps工程师到底要做什么事情?
37 | 遇到线上故障,你和高手的差距在哪里?
38 | 日志管理:如何借助工具快速发现和定位产品问题 ?
39 | 项目总结:做好项目复盘,把经验变成能力
“一问一答”第4期 | 14个软件开发常见问题解决策略
经典案例解析篇 (7讲)
40 | 最佳实践:小团队如何应用软件工程?
41 | 为什么程序员的业余项目大多都死了?
42 | 反面案例:盘点那些失败的软件项目
43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?
44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?
45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术
“一问一答”第5期(内含彩蛋) | 22个软件开发常见问题解决策略
结束语 (1讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

37 | 遇到线上故障,你和高手的差距在哪里?

宝玉 2019-05-25
你好,我是宝玉。在软件上线后,发生线上故障是一个常见的问题,但怎样对线上的故障进行处理,却很能反映出新手和高手程序员的差距。对于团队来说,如何应对线上故障,也同样能反映出线上运维水平的高低。
今天,我将带你一起分析一下,新手和高手在应对故障时有什么不同?大厂在处理线上故障时,有哪些可以学习借鉴的地方。

遇到线上故障,新手和高手的差距在哪里?

在这里,我把新手在处理线上故障遇到的一些常见问题列一下,同时,我们也一起分析下,高手是怎么处理这些问题的。

新手遇到复杂的线上故障,不知道该怎么下手

对于线上故障,有的很简单,从界面或者错误日志上可以直观地看到问题在哪,从而也好找到方法去解决。但有的故障,却没办法直观地看出原因,比如说内存一直在涨,CPU 居高不下,遇到这种复杂的故障,通常新手就不知道该怎么下手了。
而对高手来说,会在实践中总结一套自己解决问题的步骤,遇到问题,会按照解决问题的步骤有条不紊地去分析和解决。(比如说 caoz 的这篇《出了 bug 怎么办》,就充分体现了一个高手的水平。)通常通过下面这样的步骤:
第一步,评估影响范围;
第二步,试图重现问题;
第三步,临时方案和终极方案;
第四步,风险评估及持续优化。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(8)

  • hua168
    老师,像大点的公司一般都会有业务监控系统吧,直接用业务监控会不会有帮助?
    比如比较著名的CAT(地址:https://github.com/dianping/cat)
    像日志监控系统也运维写的吧,是不是开发给一个监控的API就行了?

    作者回复: 有关这部分内容,可以参考下一篇的内容,会有更详细的介绍。

    CAT是很好的业务监控系统,用好了一样可以很有帮助。

    日志监控系统不需要自己从头写,开发或者运维搭都可以,搭建好了做一些配置或者二次工作就好了。

    2019-05-27
    3
  • alva_xu
    这是ITIL要解决的问题。我觉得最主要还是从三个方面来看。一是从流程上,对于事件管理、问题管理、变更管理、服务等级管理等,要有明确的流程。二是要有合适的工具,比如ticket系统,CMDB,监控工具、日志平台等。三是从人员组织来看,要有一线、二线和三线团队的支持,根据所创建的ticket的严重性和紧急性,给予不同level的支持。当然这也是目前流行的devops要解决的问题。

    作者回复: 🙏谢谢补充:在对故障评级后,还应该要提交ticket用来跟踪整个故障解决的过程。

    2019-05-27
    3
  • 纯洁的憎恶
    新手用野路子解决问题,高手用模型解决问题:
    1.给问题评级。紧迫的调动优势资源先解决,一般的往后放放。
    2.尽快恢复生产。生产是企业的首要职责,遇到问题优先恢复生产,减少直接损失,然后再正式的解决问题。
    3.找到问题出现的位置。“搜集证据”,通过“粗调”在时空上缩小包围圈,再用“精调”明确问题点,运用排除法最终锁定问题。
    4.分析原因,修复问题。
    5.提出解决方案。钥匙不一定插在锁眼里,要沿着问题的线索不停“倒带”找到根源。再针对根源,站在系统和流程的高度制定解决方案,避免问题复现。

    重点:
    1.通过故障报警+业务骨干轮值机制,让正确的人第一时间响应问题。
    2.通过实战演习,确保应急预案稳定可行。
    3.通过使用日志记录和分析工具,积累、整理日常生产信息,出现问题才有得分析,否则重现问题也无济于事。

    作者回复: 👍感谢分享补充!

    2019-05-25
    3
  • 鲍勃
    我是做物联网(嵌入式)Linux相关的开发的,感觉有一点就是:解决问题后,总结做的不够。需要不断学习和实践

    作者回复: 总结还是蛮重要的。因为出了故障,多少反映出整个开发流程可能是存在问题的,比如开发时没有写自动化测试和代码审查,测试时没有充分测试各种路径。总结后,就可能会找出来这些潜在问题,比如说增加针对这类Bug的自动化测试代码,增加代码审查,测试时增加对这类Bug的测试用例,从根源上改进这些问题,从而做的更好。

    2019-05-25
    3
  • 邢爱明
    我在传统的制造业甲方公司,系统大部分是内部管理系统,对于线上故障处理,个人一直有几个疑问,希望老师能给一些指导意见:
    1. 谁来主导线上故障处理的过程?我们现在定的是产品经理,这个岗位用户安抚、信息同步方面做的比较好,但由于完全不懂技术,对排查原因、制定解决方案基本帮不上忙。
    2. 故障排查是不是应该有一个标准的分析过程,让运维、开发、安全各方能更好的协作?如判断影响范围、分析系统资源是否有瓶颈、查看系统日志报错信息、分析最近发布等等。目前一旦有线上事故,由于分工不同,大家在排查的时候容易出现扯皮的现象,运维说系统资源没问题,开发做最近没做发布,很影响故障的恢复进度。
    3. 便利性和安全如何平衡?目前处于安全考虑,开发人员不能登录生产的应用服务器,一些核心系统生产数据库也不能查询数据,只能查看tomcat日志;而运维人员完全不懂系统的功能,tomcat的日志也不看。这样的安全限制在故障排查的时候造成了信息的割裂,难以快速对故障进行定位。

    作者回复: 1. 谁主导线上故障,我觉得有两个指标要考虑:

    一个是这个人或者角色要懂技术懂业务,这样出现故障,能对故障进行评级;
    另一个是要能调动开发和运维去协调处理,这样出现故障能找到合适的人去处理,不然也只能干着急。

    2. 故障排查上:

    如果是操作系统、数据库、网络等非应用程序故障,应该是运维负责;

    如果是应用服务故障,应该是开发去负责,即使开发最近没有去做发布也应该是开发去查。因为只有开发对于应用程序的结构才清楚,才能找出来问题。排查过程中,运维要给予配合。

    3. 应该搭建起来像ELK这样的日志管理系统(可参考《38 | 日志管理:如何借助工具快速发现和定位产品问题 ?》),将应用程序日志也放上去,这样正常情况下就不需要去登录服务器了,直接就可以通过日志工具查看到异常信息。另外,一些特殊情况应该允许开发人员登录服务器排查定位。

    2019-05-30
    2
  • 梁中华
    最好的方式是不出现问题,事情做在前面,多做设计评审和测试用例评审,大点的项目要做上线方案评审和应急回滚方案,当然灰度发布几乎是必须,staging环境验证也是必须的。

    作者回复: 👍对,预防是最好的!只是再怎么预防还是有发生故障的可能,所以各方面准备措施都需要准备齐全。

    2019-05-26
    2
  • 风翱
    目前线上故障,是直接通过工作群反馈的。 目前大小问题都要立即(包括春节期间)响应处理。一看到有消息,所有人员都绷紧了一条线。 故障评级和对应的处理策略是可以借鉴引入的,轮班制度也需要建立,不至于出现联系不到人的情况(要让所有的研发人员7*24小时待命是不现实的)。

    作者回复: PagerDuty这个产品可以了解下看看,很适合用来做故障报警工具,不知道国内是否有同类产品。

    2019-06-27
    1
  • 小老鼠
    可以用精准测试工具
    2019-11-25
收起评论
8
返回
顶部