上线
上线只是开始，维护阶段才是工程的真正考验。核心目标：让线上问题「可发现 → 可定位 → 可解决」。
关注点全景
| 类别 | 内容 | 文章 |
|---|---|---|
| 应用监控 | 异常监控、性能监控 | 异常监控 / 性能监控 |
| 日志与告警 | 统一日志、告警分级、On-call | 日志与告警 |
| 埋点 | 事件埋点、用户行为、ABTest | 埋点 |
| 应急响应 | Runbook、限流熔断降级、复盘 | 应急响应 |
推荐方案
| 类型 | 自建 | 第三方 |
|---|---|---|
| 异常监控 | 日志 + Sentry-like 后端 | Sentry（最推荐） |
| 性能监控 | PerformanceObserver + 自建上报 | Sentry Performance、阿里云 ARMS |
| 埋点 | 自研 + ClickHouse + Grafana | 神策、GrowingIO、友盟、PostHog |
| 日志 | Loki + Grafana / ELK | Datadog、Sentry Logs |
| 报警 | Prometheus + AlertManager | 钉钉机器人、PagerDuty |
应急核心原则
先止损、再查根因。5 分钟内必须采取行动（回滚 / 切流量 / 限流 / 降级）。
详细 SOP 和 Runbook 模板见 应急响应。
避坑指南
- 采样上线：线上 PV 大，全量上报会拖垮接口和存储
- 关联用户：异常和性能数据带上 userId，才能复现
- 隐私合规：上报前对敏感字段脱敏（手机号、身份证、token）
- 不要等到出事才接监控：上线第一天就要有
- 报警要分级：P0 电话、P1 钉钉、P2 看板，避免告警麻木
- Runbook 必须写：出事时按图索骥，不靠脑子回忆
- blameless 复盘：找系统问题，不找人背锅
- 状态页很重要：主动告诉用户「我们正在修复」，比让用户在 Twitter 骂强一万倍
面试话术
「上线后我们搭了四层体系：① 监控（Sentry + 自建）发现异常；② 统一日志带 requestId 定位问题；③ 告警按 P0~P4 分级，钉钉 + 状态页；④ 每个核心服务有 Runbook，出事按 SOP 5 分钟内止损。复盘走 blameless post-mortem，重点是让系统更难出错，不是找人背锅。」