用途：该技能用于构建帮助团队检测、分诊与预防可靠性事故的监控看板，覆盖服务级看板定义、SLO 健康与错误预算消耗追踪、事件指挥中心视图，以及跨团队看板模式标准化。
前置条件：需要指标管道（Prometheus、OpenTelemetry 或同类厂商方案）、与服务及环境关联的日志/追踪，以及约定的服务分类法（团队、服务、层级、环境）。
看板分层结构：
- 执行可靠性视图：SLO 达成率、事故数量、MTTR 趋势。
- 服务健康视图：RED/USE 指标、依赖健康、发布标记。
- 深入排查视图：按端点的延迟、资源饱和度、错误分类。 每个视图应面向问题作答：客户是否受影响、发生了什么变更、瓶颈在哪里。
核心面板包括：黄金信号（延迟 p50/p95/p99、流量与队列深度、5xx 与超时错误率、CPU/内存/磁盘 I/O/连接池饱和度）；SLO 面板（滚动窗口 5m、1h、24h、30d 的当前 SLI 值、剩余错误预算百分比、快慢窗口燃烧率、多窗口燃烧告警状态）；变更关联（部署标记与配置变更注解、功能开关状态叠加、上下游依赖错误率）。
资料给出部分 PromQL 示例，例如按状态码计算 API 错误率：100 * sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))，以及按路由计算 p95 延迟和 5m/1h 快燃烧率。
运营准则：统一颜色语义（绿=健康、黄=劣化、红=违约）；显式标注单位（ms、req/s、%、cores）；默认时间窗口设为便于排障的范围（15m、1h、6h、24h）；减少单看板面板数量以降低认知负担；在面板描述中直接加入 runbook 链接。
故障排查：面板平坦或为空时，检查标签基数与筛选条件、抓取/写入延迟、指标重命名回归；高基数导致看板变慢时，按稳定维度聚合、用记录规则处理昂贵的分位数与比率查询，并将深入排查看板与 NOC 汇总看板拆分。
相关技能提到 prometheus-grafana、opentelemetry、alerting-oncall、agent-observability。限制方面：资料未提供具体收费、价格、平台支持范围或完整实施步骤，相关内容暂未提供。