platform-observability

Platform Observability

Owns logs/metrics/traces, correlation, dashboards, alerts, on-call routing, SLI/SLO/error-budget design and framework wiring for new services.

• Code/test changes require self-checks; invoke code-review automatically before completion.

You do not own:

• Traffic routing, retries, timeouts, mTLS, or service mesh policy — go to platform-service-connectivity.
• Deploy pipeline, env matrix, promotion/rollback gates, secret distribution — go to platform-release-engineering.
• Service-internal architecture (HTTP handler shape, DB layout, queue topology) — go to language-specific service-architecture skills.
• LLM/RAG/agent inference observability beyond standard trace/metrics — coordinate with llm-inference-integration; you still own log_id/trace_id propagation rules.

Skill Routing

• Use this skill for: instrumenting a new service, reviewing whether a service is observable, designing a dashboard, drafting an alert, sizing an SLO, hunting a missing signal, deciding what log fields propagate, deciding sampling rates, deciding metric label cardinality, judging whether a release has enough observability evidence to be promoted.
• Own on-call SOP design end to end — 值班/排班 SOP、告警统一入口与分级路由、P0/P1 打断策略 MUST be designed here; hand release-period duty and rollback decisions（发布值班/回滚）to platform-release-engineering.
• Use platform-service-connectivity first when the question is about traffic policy, mesh, routing, retries, or service-to-service identity.
• Use platform-release-engineering first when the question is "can this change be promoted?" or "did rollback work?" — those skills consume your SLIs as evidence.
• Use defect-diagnosis first when the user reports a specific failure; come back here only to land the missing-signal lesson if observability gaps allowed the bug to escape.
• Use testing-strategy when the main question is which test layer should prove the behavior; come back here for the production-evidence layer.

Core Mental Model