复杂业务逻辑下的智能告警与故障定位该怎么做？

随着出行业务的发展与行业技术的革新，滴滴在业务上和技术上都在与时俱进，这个过程中呈现了其独有的特点与难点。

在业务上，滴滴既要有严谨的交易逻辑和计算复杂的业务系统，又要有强一致性事务等特性的在线系统，要保证这类系统的稳定是最有挑战的。在交易中，每一笔订单的完整性、每一个状态的正确性、每一次支付的准确性都不能有毫末之差 。除了在业务完备性上的挑战，滴滴出行业务还具有典型的早、晚高峰期和平峰期的潮汐现象, 以及大、中、小城市的不同业务规模的业务特点，此外，还面临像元旦、端午、中秋、十一等节假日带来的瞬时或持续的大流量冲击。

在技术上，随着滴滴核心业务完成微服务化改造、服务全面上云，以及应对重大故障的同城多活、异地多活的架构积极演进，这无疑给服务通信的可靠性、服务治理、容错与止损、分布式追踪、日志管理、指标集成与观测都带来不小的挑战，与此同时，服务的可观测性自然也极其困难。

总之，滴滴业务是一种典型的具有交易特征的复杂业务逻辑，同时面临着大流量、海量数据，并且正在不断进行技术动态演进的技术模型。随着业务的不断发展，业务的熵增以及系统的架构复杂度也越来越高，多系统交叉影响的可能性越来越大，如何快速发现故障、定位、止损，以及避免类似的故障再次发生都成为了新的挑战与难题。

可观测性

开始之前，我们先聊聊业界热门词：可观测性。它起源于几十年前的控制理论，可观测性通常指通过观测系统的输出来衡量系统内部的状态的能力。如果可以仅使用输出信息（即遥测器数据）来衡量当前状态，则被认为系统是“可观测的”。 

日志、追踪、度量的目标与结合

图片来源：https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html

如今在业界，它被应用于提高分布式系统的性能与稳定性。通过依靠可观测性系统生成的数据（例如日志、指标和跟踪）测量系统当前状态的能力，来保持 IT 环境中的系统正常运行。

业务可观测性现状

滴滴业务场景特点与复杂度如前言，这里重点说下滴滴出行业务的可观测性实践的现状。

       

稳定性研发

在研发方向，我们紧紧依托业务特点，为业务提供例如NUWA业务框架、DiPRC组件、日志、Metric指标、Trace等标准业务组件，同时我们也把稳定性相关抓手预埋进组件里，比如超时治理、自动降级、业务放火能力，机器人依赖指标等。以及在架构上的全面云化、同城双活、异地多活、服务化改造与治理等，更详细见👉基于Go语言的滴滴DevOps重塑之路。

稳定性建设

在稳定性建设上滴滴一直在坚定不移的投入：为了应对系统的流量冲击而做的定期全链路压测、子链路压测等容量摸底与优化，在研发环节为了应对变更带来的风险而做的部署规范、分级发布、配置变更等。在运维环节通过告警自动化、告警管理平台、精准化提高故障的感知能力。以及在平时的巡检、重大节假日的“护堤”（滴滴内部重大节日的稳定性专项）等建设项。

稳定性运营

在建立好基础的研发与稳定性等能力后，如果没有很好的执行，就如同马其诺防线一样，看似坚不可摧，实则很容易被突破，因此我们在稳定性文化建设上也颇费心思，通过周会、海报、技术运营活动等手段，定期宣导稳定性红线、推广框架、工具的使用。在各个业务团队