故障定位，是指在系统或设备发生故障时，识别和确定故障发生的具体位置和原因的过程。故障定位区别于根因定位，故障定位只要找到引起故障的直接原因即可，因为知道直接原因就可以止损了，故障定位核心就是找到止损依据。故障定位通常是在故障发生时来做，而根因定位通常是复盘阶段来做。
围绕 故障定位 的实践、选型、案例和产品内容，按同一阅读路径持续整理。
本文从用户视角重新定义系统稳定性，提出通过北极星指标、灭火图、信息协同、事件中心和智能辅助决策建设稳定性体系，让技术团队、业务方和故障应急团队围绕同一套可量化事实协作。
Flashcat 的设计初衷是实现从数据、平台到故障处理场景的一体化统一监控，解决采集、兼容、告警、定位路径和稳定性保障落地问题。
分析经典 SLO（CSLO）在故障处理场景中的适用边界，介绍以 BLO 做故障发现、以服务层 SLO 做故障定位的稳定性实践。
可观测性体系的目标不是堆 metrics、logs、traces，而是帮助技术团队快速发现故障、定位直接原因并完成止损。本文从故障生命周期、结果类指标、数据特征、观点和洞察几个层次，说明面向故障处理的可观测性应该如何建设。
市面上已经有很多开源、商业的可观测性类产品，比如 Zabbix、Prometheus、Nightingale、SigNoz、SkyWalking、ELK 等等，而且各类云厂商也会提供自己的可观测性套件，有些规划混乱的云厂商甚至会提供功能重叠的多套产品，这加剧了企业数据孤岛的现状。怎么解？
围绕阿里巴巴 1-5-10 故障目标，说明如何用北极星指标、灭火图、事件墙和多维分析缩短发现、处置与恢复时间，帮助团队建立更快的应急响应机制。
可观测性建设不是越早越好。本文从覆盖完备性和能力完备性两个维度说明：如果业务监控、应用监控、组件监控、资源监控、网络监控和端监控还没打牢，先补监控体系通常比直接上可观测性项目 ROI 更高。
稳定性保障的关键，是把业务可用性目标、故障发现定位止损、冗余切换、降级熔断、限流、弹性伸缩、灰度发布和云服务治理串成可执行闭环。本文总结 8 个稳定性保障实践，适合 SRE、运维和研发团队用于故障响应与可靠性建设。
稳定性一号位或稳定性负责人应承担什么职责：承担结果责任，制定可分解可量化的稳定性目标，锁定预算，并建立提升确定性、降低门槛的技术保障体系。
服务稳定性保障中，服务可用性、故障、根本原因、故障定位和业务监控经常被混用。本文从用户视角解释这些概念的边界、统计口径和实践影响。
本文结合稳定性保障实践，说明日志分析如何在成本、效果和落地风险之间取舍，并介绍用网关日志生成业务指标、与指标和链路追踪联动、再通过 Flashcat 串联多数据源的日志分析路径。
Flashcat 灭火图是故障发现和定位的入口，通过服务、模块、组件、基础设施等层级化健康视图，聚合时延、流量、错误、饱和度等指标，并串联指标、日志、链路、事件等下钻分析能力。
本文整理 Datadog 高效监控系列中的故障调查方法：从最高层工作指标开始，逐层检查资源指标和事件，并用预先设计的仪表盘加快性能问题定位。
监控工具和告警越来越多，故障定位却越来越慢。根因通常不是监控不够，而是告警、指标、日志、变更、拓扑、业务影响和响应流程没有统一到同一个稳定性工作台。
事件墙不是附属页面，而是根因分析时间线。把发布、配置、Kubernetes、云事件、告警和运营动作放到同一时间窗口，才能更快判断故障前后发生了什么变化。
