2019-05-30我在传统的制造业甲方公司，系统大部分是内部管理系统，对于线上故障处理，个人一直有几个疑问，希望老师能给一些指导意见:
1. 谁来主导线上故障处理的过程？我们现在定的是产品经理，这个岗位用户安抚、信息同步方面做的比较好，但由于完全不懂技术，对排查原因、制定解决方案基本帮不上忙。
2. 故障排查是不是应该有一个标准的分析过程，让运维、开发、安全各方能更好的协作？如判断影响范围、分析系统资源是否有瓶颈、查看系统日志报错信息、分析最近发布等等。目前一旦有线上事故，由于分工不同，大家在排查的时候容易出现扯皮的现象，运维说系统资源没问题，开发做最近没做发布，很影响故障的恢复进度。
3. 便利性和安全如何平衡？目前处于安全考虑，开发人员不能登录生产的应用服务器，一些核心系统生产数据库也不能查询数据，只能查看tomcat日志；而运维人员完全不懂系统的功能，tomcat的日志也不看。这样的安全限制在故障排查的时候造成了信息的割裂，难以快速对故障进行定位。展开作者回复: 1. 谁主导线上故障，我觉得有两个指标要考虑：
一个是这个人或者角色要懂技术懂业务，这样出现故障，能对故障进行评级；
另一个是要能调动开发和运维去协调处理，这样出现故障能找到合适的人去处理，不然也只能干着急。
2. 故障排查上：
如果是操作系统、数据库、网络等非应用程序故障，应该是运维负责；
如果是应用服务故障，应该是开发去负责，即使开发最近没有去做发布也应该是开发去查。因为只有开发对于应用程序的结构才清楚，才能找出来问题。排查过程中，运维要给予配合。
3. 应该搭建起来像ELK这样的日志管理系统（可参考《38 | 日志管理：如何借助工具快速发现和定位产品问题 ？》），将应用程序日志也放上去，这样正常情况下就不需要去登录服务器了，直接就可以通过日志工具查看到异常信息。另外，一些特殊情况应该允许开发人员登录服务器排查定位。 3
2019-05-27老师，像大点的公司一般都会有业务监控系统吧，直接用业务监控会不会有帮助？
比如比较著名的CAT（地址：https://github.com/dianping/cat）
像日志监控系统也运维写的吧，是不是开发给一个监控的API就行了？作者回复: 有关这部分内容，可以参考下一篇的内容，会有更详细的介绍。
CAT是很好的业务监控系统，用好了一样可以很有帮助。
日志监控系统不需要自己从头写，开发或者运维搭都可以，搭建好了做一些配置或者二次工作就好了。 3- 2019-05-27这是ITIL要解决的问题。我觉得最主要还是从三个方面来看。一是从流程上，对于事件管理、问题管理、变更管理、服务等级管理等，要有明确的流程。二是要有合适的工具，比如ticket系统，CMDB，监控工具、日志平台等。三是从人员组织来看，要有一线、二线和三线团队的支持，根据所创建的ticket的严重性和紧急性，给予不同level的支持。当然这也是目前流行的devops要解决的问题。
作者回复: 🙏谢谢补充：在对故障评级后，还应该要提交ticket用来跟踪整个故障解决的过程。
3 
2019-05-25新手用野路子解决问题，高手用模型解决问题：
1.给问题评级。紧迫的调动优势资源先解决，一般的往后放放。
2.尽快恢复生产。生产是企业的首要职责，遇到问题优先恢复生产，减少直接损失，然后再正式的解决问题。
3.找到问题出现的位置。“搜集证据”，通过“粗调”在时空上缩小包围圈，再用“精调”明确问题点，运用排除法最终锁定问题。
4.分析原因，修复问题。
5.提出解决方案。钥匙不一定插在锁眼里，要沿着问题的线索不停“倒带”找到根源。再针对根源，站在系统和流程的高度制定解决方案，避免问题复现。
重点：
1.通过故障报警+业务骨干轮值机制，让正确的人第一时间响应问题。
2.通过实战演习，确保应急预案稳定可行。
3.通过使用日志记录和分析工具，积累、整理日常生产信息，出现问题才有得分析，否则重现问题也无济于事。展开作者回复: 👍感谢分享补充！
3
2019-05-25我是做物联网(嵌入式)Linux相关的开发的，感觉有一点就是：解决问题后，总结做的不够。需要不断学习和实践作者回复: 总结还是蛮重要的。因为出了故障，多少反映出整个开发流程可能是存在问题的，比如开发时没有写自动化测试和代码审查，测试时没有充分测试各种路径。总结后，就可能会找出来这些潜在问题，比如说增加针对这类Bug的自动化测试代码，增加代码审查，测试时增加对这类Bug的测试用例，从根源上改进这些问题，从而做的更好。
3
2019-05-26最好的方式是不出现问题，事情做在前面，多做设计评审和测试用例评审，大点的项目要做上线方案评审和应急回滚方案，当然灰度发布几乎是必须，staging环境验证也是必须的。作者回复: 👍对，预防是最好的！只是再怎么预防还是有发生故障的可能，所以各方面准备措施都需要准备齐全。
2
2019-06-27目前线上故障，是直接通过工作群反馈的。 目前大小问题都要立即（包括春节期间）响应处理。一看到有消息，所有人员都绷紧了一条线。 故障评级和对应的处理策略是可以借鉴引入的，轮班制度也需要建立，不至于出现联系不到人的情况（要让所有的研发人员7*24小时待命是不现实的）。作者回复: PagerDuty这个产品可以了解下看看，很适合用来做故障报警工具，不知道国内是否有同类产品。
1
2019-11-25可以用精准测试工具