Observability-driven development (ODD) extends test-driven development by making the observability data and alerting needed to understand software behavior an acceptance criterion for every backlog item. It asks teams to design features so platform engineers can determine what the software is doing now, what it did operationally, and whether it delivers expected value. section 2.2.2
ODD addresses failures where a feature appears healthy but an automatic guardrail or configuration change causes unexpected behavior. Without the relevant telemetry, developers and platform engineers can spend hours debugging before discovering the real cause. section 2.2.2
Apply ODD during design and implementation by:
- Asking what data must be generated or made accessible to establish confidence in a feature’s behavior. section 2.2.2
- Adding telemetry and alerting requirements alongside functional tests, rather than treating diagnosis as a later operational task. section 2.2.2
- Testing control behavior explicitly, including thresholds and expected throttling, while collecting evidence that confirms the control operated correctly. section 2.2.2
Diagnosing unexpected traffic throttling
New services exceed a service-mesh traffic threshold intended for external sources. Developers first spend three hours debugging, and the platform team spends another three hours investigating. Activating network logs exposes the policy behavior; correcting the configuration then takes ten minutes. ODD would have required the telemetry and alerts needed to identify the throttle earlier. section 2.2.2
As observability improves, correlated data can support diagnosis, troubleshooting, portfolio-level performance analysis, and clearer evidence of platform value. Without disciplined design, users may create fragile spreadsheets that break whenever data structures change. section 5.0
