部署与运行
可观测性Observability
你可能会问
可观测性到底是什么？服务挂没挂，为什么不能等用户来告诉你？
简单来说
通过日志、指标和追踪了解线上系统是否正常以及问题发生在哪里。
裸奔的服务装了仪表盘同一场故障，两种剧本
拖到第二天早上当晚半小时止血看得见，才管得住
01 · 先这样理解
把抽象概念放进真实场景
通过日志、指标和追踪了解线上系统是否正常以及问题发生在哪里。
换个角度想可观测性像汽车的仪表盘加行车记录仪：时速、油量、故障灯随时可见，出了事故还能调记录还原过程。没有仪表盘的车也能开——直到抛锚在半路。
02 · 点击演示
凌晨两点支付挂了，你什么时候能知道？
突出显示的部分，就是当前概念在整条流程中负责的位置。
- 这一步不存在——
系统在裸奔，出了事也无痕每个请求留痕23:58下单 ✓ 20002:03支付 ✗ 超时 系统健康吗？
不知道，只能「感觉还行」
仪表盘错误率0.1% → 46%！响应200ms → 8s凌晨 2 点支付挂了
没有任何人知道
错误率超过阈值
02:05 报警电话叫醒你
- 一夜事故早上被投诉淹没，没日志只能瞎猜不是没出事，是出了你不知道半小时止血日志直指支付网关超时，回滚搞定报警比用户早，事故就小十倍
1 / 4
Log · 日志记下每件事
03 · 放进真实任务
什么时候会遇到它
事故早知道
报警比用户投诉早十分钟，事故就小十倍。
定位历史问题
「昨晚 8 点为什么变慢」——查指标和日志，不靠猜。
验证每次发布
新版上线后盯错误率和延迟，确认没引入回归。
04 · 想一想
用一个问题检查理解
用户反馈「昨天下午下单一直失败」，但你的系统什么记录都没有。今天该补什么？
查看答案
至少三件：给下单链路加日志（谁、何时、失败原因）；加错误率指标和报警；最好补上请求追踪。这次只能道歉，补上之后，下次才能在用户开口前发现。
最容易踩的坑
没有可观测性的系统不是「没出过事」，只是出了事你不知道。等用户告诉你的时候，影响已经扩大了。