故障定位，是指在系统或设备发生故障时，识别和确定故障发生的具体位置和原因的过程。故障定位区别于根因定位，故障定位只要找到引起故障的直接原因即可，因为知道直接原因就可以止损了，故障定位核心就是找到止损依据。故障定位通常是在故障发生时来做，而根因定位通常是复盘阶段来做。
围绕 故障定位 的实践、选型、案例和产品内容，按同一阅读路径持续整理。
通过几个方面来建设稳定性体系：建立全面的度量体系、重点加强信息协同/让数据说人话、特定场景下的智能辅助决策
Flashcat的设计初衷是实现一个从数据到平台到场景真正一体化的统一监控，成为服务稳定性保障，特别是故障处理的真帮手。
SLO落地难，有哪些落地方法，Flashcat北极星、灭火图等产品可以帮助你
可观测性不能只关注 metrics、logging、tracing 这些 raw data，还要能够从数据中提取特征，进而推导出观点，最终辅助洞察定位故障。能够辅助定位故障才是可观测性的核心目标，构建数据只是建设底座，离目标还差的很远，千万不要觉得有了数据，就完活了。
市面上已经有很多开源、商业的可观测性类产品，比如 Zabbix、Prometheus、Nightingale、SigNoz、SkyWalking、ELK 等等，而且各类云厂商也会提供自己的可观测性套件，有些规划混乱的云厂商甚至会提供功能重叠的多套产品，这加剧了企业数据孤岛的现状。怎么解？
围绕阿里巴巴 1-5-10 故障目标，说明如何用北极星指标、灭火图、事件墙和多维分析缩短发现、处置与恢复时间，帮助团队建立更快的应急响应机制。
很多公司听说可观测性好，就要上马可观测性项目，自研/采购，各种投入，结果发现效果很差，业务不认可，最终一地鸡毛
稳定性保障，是一切技术工作的出发点和落脚点，也是 IT 工作最核心的价值体现，当然也是技术人员最容易“翻车”的阴沟。8个稳定性保障锦囊，分享给各位技术人员择机使用。
稳定性一号位，或者说稳定性负责人，需要有哪些职责：承担责任，制定目标并拆解量化，确定预算，建立技术保障体系
服务稳定性保障，如何站在用户视角看问题，大家有哪些误解，本文从服务可用性、故障、根本原因、根因定位、业务监控多个方面来讲解
本文将结合实战经验，介绍一种日志分析的实现，分析如何在稳定性保障中用好日志这个维度，以及日志如何与指标、链路相互配合形成故障定位的最佳实践。
灭火图是发现服务健康与否的入口，也是整个故障定位信息系统的核心，从灭火图开始，可以下钻到具体的接口/基础设施/链路分析数据/问题特征/相关事件等关键维度，引导技术团队高效、精准的定位故障。
Datadog 作为监控、可观测性领域的头部厂商，不止是输出工具，更会输出方法论，本文是监控方法论的第三篇，讲解如何排查性能问题
