可观测性与服务等级目标（SLO） 是做什么的？
概述
你无法运维、调试或改进你看不见的东西。可观测性是设计时就融入的，而不是在第一次故障后才匆忙补救。每次事故的第一个问题都是“什么变了？谁受到了影响？”——一个无法回答这个问题系统，会把五分钟就能解决的修复变成一场考古挖掘。
原则（通用）
- 三大信号。 发出结构化日志（机器可解析，而非自由文本）、指标（计数、速率、持续时间）和链路追踪（请求在服务间的路径）。一个请求从头到尾携带一个关联 ID/链路追踪 ID。
- 为每个服务表面仪表化黄金信号：每个端点/操作的速率、错误、持续时间（RED），以及资源饱和度。一个新端点直到变得可观测才算“完成”。
- 健康是一个端点，而不是猜测。 将存活探针（“我还在运行吗？”）和就绪探针（“我能处理流量吗？”）作为独立的检查暴露出来。
- 为关键用户旅程定义 SLO，配合衡量它们的SLI和错误预算，使可靠性与功能之间的权衡成为明确、数据驱动的选择。
- 根据症状触发告警，而不是原因。 当用户受到影响时（SLO 燃烧、就绪探针失败）才呼叫值班人员，而不是对每个内部告警都响应。每个告警必须是可操作的——一个无人响应的告警训练人们忽略所有告警。
机制（此技术栈）
- 结构化 JSON 日志输出到 stdout，由平台收集（例如 AKS → Azure Monitor / Log Analytics）。服务中禁止自由文本日志。
- 应用服务器和 PostGraphile 中使用 OpenTelemetry；将链路追踪和指标导出到 Azure Monitor / Application Insights（或 Prometheus/Grafana）。
- 关联 ID 在整个数据路径中传播——在边缘生成，通过 Browser → App → PostGraphile 传递，携带上下文头部，附加到每个日志行和 Span 上。
- 每个 HTTP 路由和 GraphQL 操作的 RED 指标；Postgres 慢查询日志 +
pg_stat_statements。 - 存活/就绪端点连接到 Kubernetes 探针（参见
cloud-delivery-aks）。就绪探针反映真实的依赖健康状态（能否访问数据库？），而不仅仅是进程在运行。 - 前端： 将 Web Vitals 和客户端错误报告到同一个后端。
- 每个用户旅程的 SLO，配合仪表板和燃烧速率告警。
何时扩展此实践
一个预发布/本地项目应先实施结构化日志和健康端点，推迟 SLO/告警，直到有真实用户需要保护时才实施。在第一个决策记录中声明当前模式。
完整理论基础：宪法第 IX 条和第 XVI 条，位于 engineering-constitution/references/engineering-constitution.md。