图片50
业务模型（或系统部署结构）复杂带来的最直接影响就是定位故障很困难，发现根源问题成本较高，需要多部门合作，开发、运维人员相互配合分析（现在的大规模系统很难找到一个能掌控全局的人），即使这样有时得出的结论也不见得各方都认可。
在开发层面，应对复杂业务的一般思路是采用SOA、微服务化等，但从运维的角度讲，完成微服务化并没有降低业务的复杂度（当然结构肯定变清晰了）。
在这里，又不得不强调工程能力的重要性。在复杂、异构和各种技术栈混杂的业务系统中，如果想定位故障和发现问题，在各个系统中就必须有一个可追踪、共性的东西。然而，在现实中若想用某个“体系”来一统天下，则基本不可能，因为各种非技术因素可能会让这种努力一直停留在规划阶段，尤其是大公司，部门之间的鸿沟是技术人员无法跨越的。
所以，下面给出的几种简单方法和技术，既能在异构系统中建立某种关联，为智能化提供一定的支持，又不要求开发人员改变技术栈或开发框架。
日志标准化：日志包含所约定的内容、格式，能标识自己的业务线、服务层级等。
全链路追踪：TraceID或者RequestID应该能从发起方透传到后端，标识唯一请求。
SLA规范化：采用统一的SLA约定，比如都用“响应时间”来约定性能指标，用“慢速比”来衡量系统健康度。
当这些工程（自动化、标准化）的水平达到一定高度后，我们才有望向智能化方向发展。
故障定位又称为告警关联（Alarm Correlation)、问题确定（Problem Determination）或根源故障分析（Root Cause Analysis），是指通过分析观测到的征兆（Symptom），找出产生这些征兆的真正原因。
在实践中通常用于故障定位的机器学习算法有关联规则和决策树。
还有很多方法，但笔者也在探索中，所以无法推荐一个“最佳”方法。究竟什么算法更适合，只能取决于实践中的效果了。
需要注意的是，并不是用了人工智能或机器学习，故障定位的效果就一定很好，这取决于很多因素，比如特征工程、算法模型、参数调整、数据清洗等，需要不断地调整和学习。还是这句话：智能化的效果不仅仅取决于算法，工程能力也很重要，而且好的数据胜过好的算法。
