从运维角度谈谈故障定位【未完】

面试时，经常会被问到：在线业务出现故障，该如何定位？

一般刚毕业不久的会回答：我们有监控；看日志等之类的答案。

工作几年的人会回答：从网络，机器，资源等方面排查有没有问题，如果没有问题，再看看日志，找开发核对。

也有人回答这个是开发的问题，我们运维还没有精确到业务层面。

故障定位，这个话题可能很大，不同角色认识是不一样的。对于开发，故障定位往往会根据问题现象，从代码角度去分析，尝试从代码或架构方面进行解决。对于运维而言，故障定位，一般理解为：在线业务的核心功能受到影响，应该如何快速定位到原因。

本文要讨论的范围，也仅限于运维角度进行在线问题故障定位。

运维人员进行故障定位时，遇到主要问题：

1）业务掌握深入程度有限。不像某个应用的开发那样，能很清楚一个小问题的处理逻辑。

2）要对在线业务的稳定性负责。

3）造成故障的原因很多。除了代码bug可能导致问题外，IDC，机器，流量波动等外在条件都会有影响。

4）不同运维人员对于业务理解或运维能力不同。不同的业务运维人员由于经验等不同，遇到故障时的心态、决策等区别很大。

“核心功能告警，执行预案”是运维处理在线故障的思路。但是，当预案执行后，故障仍然存在，该如何做呢？

这时候，就要快速、准确定位出故障原因，至少要知道造成这次故障的一个范围是什么，以便采取相应措施。

网络方面

网络无疑是造成服务故障的第一杀手。

用户->CDN->源站IDC->业务接入层->后端服务

用户->源站IDC->业务接入层->后端服务

服务健康

资源使用

核心依赖

上线变更

容量方面