给所有服务统一写一个很高的可用性百分比，未必能指导工程投入。服务质量目标应对应用户真正关心的操作，并说明测量边界、时间窗口与异常处理。
定义用户可感知的结果
登录、订单提交和后台报表可以有不同目标。成功率需要说明哪些请求进入分母，业务校验拒绝是否属于技术失败；耗时目标也应区分同步响应与异步完成。
先验证测量是否可信
检查指标缺失、采样、代理错误和客户端超时是否被覆盖。应用内部记录成功，不代表用户一定收到结果。若当前证据不完整，可以先建立测量，再讨论更精细的目标。
把目标用于取舍
当质量持续偏离目标时，团队应知道是否暂停高风险变更、优先修复哪条路径。不要让目标仅出现在汇报文档里，与排期和资源决策没有关系。
验收一次质量下降
模拟依赖变慢或部分失败，确认指标、告警和处理流程能够反映用户影响。记录没有覆盖的场景，逐步补齐，而不是宣称一套监控能代表所有体验。
常见问题：SLO 和合同 SLA 是同一件事吗？
不是简单等同。内部工程目标与对外承诺的范围和后果可能不同，需要按实际约定分别管理。
技术参考：Prometheus：告警实践。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果你的团队正遇到类似问题，可以从一条关键业务路径开始，整理现状、证据与约束，通过系统架构诊断明确优先级、候选方案和验证范围。