企业IT故障定位指诊断故障直接原因或根因，故障定位有助于故障恢复动作更加有效。故障定位通常是整个故障过程中耗时最长的环节，定位的目标围绕在快速恢复的基础上，而非寻找问题根因，后者由问题管理负责。通常大部分可用性故障，要借助运维专家经验的假设判断或已知预案的执行得到解决，但仍有部分故障，尤其是性能、应用逻辑、数据故障需要多方协同与工具支持。故障定位的方法通常包括专家经验驱动的假设尝试、测试复现、预案启动、代码分析四种，这个过程涉及对日志、链路、监控、数据感知、知识管理五类工具。随着系统复杂性不断提升，依靠专家经验驱动的假设尝试准确率会下降，如何将数字化手段结合专家经验，融入到协同机制中，这考验故障定位场景的设计水平。

1.定位方法

1） 专家经验驱动的假设尝试

随着企业的应用系统架构由原来单体架构向分布式微服务架构发展，以及研发、运维团队对高可用架构的重视与投入，越来越多的系统在服务级别的可用性、可靠性、健壮性更强，再加上配套的监控工具完善，一般的服务级别不可用故障有更好的应对方案。当前运维面临的故障定位问题，主要是：

• 海量并发下，故障的快速传染，单个服务异常影发了大量异常的出现，如何在大量异常服务中判断根因服务。

• 判断应用逻辑层面的异常，比如功能、菜单级别的故障，如何更加主动、从容的找到逻辑上的故障点，并作出应急。

• 应用逻辑故障的问题定位与 “故障传染”场景类似，如何在大量病态的功能中找到根因功能，并对功能进行降级等恢复是难点。

• 判断数据异常产生的异常，数据异常不仅仅指数据完全不可用，而是在大部分数据正常下，找到个别数据不可用的问题。

在面对上面的故障时，整体的自动化能力还有较大提升空间，基于运维专家经验驱动的假设性尝试诊断与恢复仍是当前主要的应对手段。要让运维专家经验发挥得更好，需要重点关注四件事：

• 专家技能的持续提升。应用逻辑、数据异常问题对于传统运维专家通常是黑盒子，运维专家需要转换角色主动去了解应用逻辑功能，上下游调用链、数据流向、应用配置、数据库流水等要素。

• 运维前移。了解软件层的黑盒子，除了主动对线上系统进行学习，还要落实前移工作，比如：标准化前移，推动软件更加可维护；基础平台前移，用平台推动软件标准化；交付前移，标准化、自动化软件交付链路；测试前移，围绕系统稳定性进行主动的体验、接口、压力测试，提升稳定性等等。

• 技能的沉淀与传承。依靠经验最大挑战是应对人员不在故障处理现场的问题，技能的沉淀与传承是运维管理需要考虑的问题。前者针对技能经验的知识化，重点关注知识生产、保鲜、共享；后者针对岗位设置、培训、值班管理等机制。

• 工具赋能。应用日志、交易报文、应用流水等是了解软件逻辑和数据的主要方案，组织要为专家提供方便的工具。这个思路同样适用于运维以外的专家，比如在故障协同中将应用日志、功能级的性能等数据以在线工具方式分享给研发、测试团队也是一个有效的赋能手段。

2） 已知预案启动

对于疑难杂症或重大故障，我们认为故障诊断过程中，应该采用两条操作路径，一是前面提到的基于专家经验的尝试性的诊断，另一点是围绕已知预案的尝试启动。已知预案指提前对故障场景进行描述，并制定应急操作步骤。在预案的启动中，我们做了几件事：

• 预案线上化。线上化的预案主要解决当前线下文档式预案不可用、不好用的问题。采用乐高式拼装的方式，将应急策略卡片化，支持将多个策略拼装成一个应急场景下的预案。

• 预案自动化。预案线上化后就能将预案的策略自动化、社交化，比如根据链路关注自动化的触达应急策略到关联方，将预案应急的协同在社交 IM 进行处置等。具体的预案场景设计将在场景部分中进行介绍。

• 预案融入故障处置过程。将预案的执行与应急处置场景工具整合在一起，作为一个标准化的动作，一方面持续实战使用中不断的发现预案存在不足，另一方面故障处置驱动预案设计者更加重视预案的编写。

3） 测试复现

复杂系统的故障定位必然是一个跨团队协同的过程，测试复现是一个协同定位的解决方案。从岗位看，测试与 bug 打交道的机会最多，对于逻辑、数据引发的故障更敏感。测试复现与定位问题用什么方法，因为不专业不作说明，以下从运维赋能测试复现问题的角度列一下运维需要提前准备的支持：

• 让测试能够更快的获得问题描述，问题表现的截图，工单系统的在线流转，或基于 chatOps的信息传递都是好的解决方案。

• 让测试方便的查生产环境的异常日志，能看到获得网络服务的 500 错误，还是空指针等等信息。

• 按接口细分访问状况，包括成功率，交易量，耗时等。

• 定期同步测试系统，将生产已知缺陷数据在线化，辅助测试定位。

• 在线获得配置信息，查看应用配置项的生产设置情况。

4） 代码分析

虽然开发可能不清楚复杂系统完整的上下游关系，部署架构，但一定是最清楚具体逻辑、数据的人角色。与测试复现提到的类似，运维也要为研发团队提供应急协同的工具。除上面为测试提供的工具适用于研发外，运维还要为开发提供线上程序版本、配置信息、各功能号的性能信息等数据。性能管理， AIOps等场景的工具应用，将有利于研发团队在故障定位环节，提升代码分析能力。

2. 定位工具

1） 日志

对于运维而言，日志是运维了解硬件及软件内部逻辑的一面窗口。以软件为例，从系统生命周期看，由于运维没有参与到软件的需求分析、系统设计、编码开发、质量测试等阶段，当系统交接到生产环境时，软件日志是运维了解系统运行状况的重要手段。日志记录了从业务、中间件、系统等全链路信息，可以有效监控IT系统各个层面，从而有效的调查系统故障，监控系统运行状况。利用日志，运维可以了解用户行为操作，服务请求调用链路，功能调用是否成功，失败原因等信息，是故障定位的重要手段，帮助运维人员快速定位问题。

传统运维依靠人力从日志中排查故障原因，主要通过 grep、sed等指令利用关键词（error, fail, exception等）进行搜索，或利用基于规则的日志提取方法，通过传统方式手动设置正则表达式来解析日志。这不仅对代码要求高，而且要求运维人员对系统和业务有着丰富的经验。随着系统的日趋复杂化，日志显现出数量庞大、无固定模式、不易读懂等特点。仅凭借管理员在海量日志中手动查看日志记录，需要登陆每一台服务器，一次次重定向文件，操作繁琐， 不利于故障定位。所以，构建一体化的日志分析平台和利用人工智能的技术对日志进行分析是解决当前日志分析的方向，实现分散日志的归集，并在日志数据之上建立日志数据二次加工，提升故障定位能力。

2） 链路

这里提的链路主要包括纵向与横向的依赖关系，纵向关系指从生产对象的部署关系建立的从基础设施、网络、计算资源服务器、存储、虚拟机、容器、主机、应用系统、应用、服务的关系，通常围绕应用系统进行扩散；横向关系主要从服务调用关系，通过通过业务进行构建关系链。从技术实现上，我觉得可以围绕 CMDB 与 PAAS 平台两个平台建设之上持续完善链路关系。其中 CMDB 应该将关系定位为 CMDB 最重要的配置数据之一，如果当前的 CMDB 到了以业务为中心的配置管理方案，那么集成必要的关系发现、关系绘制构建、关系消费的能力是下一代 CMDB 的重点（ CMDB 的发展可以分为：满足 IT 资源管理线上化，支撑运维平台化互联互通，以业务为中心的配置管理，基于关系为核心的知识图谱）。PAAS 平台，侧重指企业以微服务为应用平台，或是面向云原生的应用平台。通常应用平台为了解平台上的系统的可维护性与可靠性，服务调用链有配套的解决方案，运维需要对平台现有链路关系进行在线的获取。

3） 监控

以往，监控往往被定位为“监测”的角色，即只负责发现异常，将报警发出来即尽到监控职责。站在运维业务连续性保障的最终价值看，监控要在“监”的基础上，增加“控”在故障恢复角度的要求，而要实现“控”前，需要监控具备定位问题的能力。监控提升故障定位能力，可以考虑以下几个点：

• 对于已知异常的监控策略，在监控发现问题后，对已知异常探测点结果进行清晰的描述。

• 对于多个监控告警进行告警事件的收敛管理，基于 CMDB 关系数据进行初步的定位。

• 利用监控数据与 AIOps算法，构建智能化的故障定位场景应用，增加故障定位的能力。

对于监控方面的内容将有专门的章节作介绍，这里不再展开。

4） 数据感知

数据感知不仅仅是将数据可视化，而是要从更高维度去感知系统运行状况。传统应用监控主要采用 “点”的方式不断完善监控，即当出现新的漏洞或事件，则在监控系统增加相应运行“点”的数据采集，并加上对数据的预警策略达到预警的效果。这种“点”的监控方式更多的是打补丁的方式，是一种“事后”、“被动”、“加固”的思路，为了提高监控能力需要利用每个运维同事的专家经验转变成“事前”、“主动”、“预防”为主，以“事后”、“被动”、“加固”为辅思路。要实现 “事前”、“主动”、“预防”，需要将以“点”为主的监控视角，转变成“面”的视角（可以理解为上帝视角，自上而下），这种”面“的视角是对现有监控方式的一个补充，是应对应用越来越复杂、业务连续性要求越来越高问题的要求。我觉得数据感知有以下的特征：

• 全景感知。举一反三，面的思维，主动思考同类的感知，主动消费己有的数据库、日志的数据。

• 数据基线。感知系统 “健康状态”，利用同比、环比的基线比对，利用多维度组合的可视化、即时的信息推送、数据驱动的自动化操作让运维能够更快、更全面的感知异常。

• 业务为中心。关注影响业务的点，比如：是否影响业务服务可用性、性能、功能、体验。

• 数据驱动。消费 &落地关系数据库、内存数据库、日志数据，与关系/链路的配置数据多维关联，形成评价系统是否“健康”的多维度指标。

5） 知识管理

知识管理是一个大家都知道应该要做，但大部分都没做好的事情。原因可能有很多，比如：在管理上，执行环节领导关注度不够有关，前三天很热，后续推进不足，缺少持续的管理、有效的奖惩措施；在运营上，知识需要融入员工工作流程中，这需要知识的运营方参与运维工作流程的设计，在流程和线上化场景中整合知识的生产过程；在技术上，知识库没有与运维场景工具整合在一起，知识的生产、加工，与知识的应用脱节，知识用得少无法验证知识数据的准确性，引发对知识的信任问题。但是，可以预见，随着系统架构复杂性越来越高，数据量越来越大，当前主要依靠运维专家现场经验驱动的临断决策解决问题的模式在未来受到的挑战会越来越大。尤其是对于未知故障的应急管理成为当前运维组织重中之重需要解决的问题。

以手工维护为主的知识库也许可以向基于下一代智能技术实现的知识图谱发展，增强生产对象与对象关系的描述能力，将对故障定位起来至关重要的作用。比如，运维知识图谱能赋能故障的决策，将运维知识图谱融入到运维应急工具中，可以将运维人员的故障定位决策过程数字化，构建决策支持知识图谱，借助机器对海量定位决策操作行为进行穷举式遍历。如果运维知识图谱准确性有保证，可以预见还能够支持数据源/指标/文本异常检测、基于人工故障库/数据挖掘的故障诊断、故障预测、故障自愈、 成本优化、资源优化、容量规划、性能优化等场景。

LinkSLA官网