A SaaS logistics organization operates an automated dispatch platform on Google Cloud. High-priority route-settlement API requests generate direct transaction revenue and carry strict contractual SLA financial penalties for downtime. Conversely, secondary background reporting queries carry no financial penalties and minimal operational impact. Currently, the reliability engineering team monitors system health using a single, aggregated Service Level Indicator (SLI) that measures the ratio of successful requests across all combined HTTP endpoints against a unified 99.9% Service Level Objective (SLO). During a recent release, a bug in background reporting endpoints produced a surge of HTTP 5xx errors that consumed 85% of the total monthly error budget. This triggered an automatic freeze on all feature deployments, despite the revenue-generating route-settlement APIs remaining at 100% availability. How should the Cloud Architect adjust the monitoring and reliability design to align technical service level objectives with business impact?
- Deconstruct the aggregated monitoring design by establishing distinct SLIs for route-settlement APIs versus background reporting endpoints, and assign independent SLOs and separate error budgets aligned with the business criticality of each service tier.Cevap
- BDefine the target 99.9% availability threshold directly as the active SLI metric in Cloud Monitoring, and set up static threshold alerts to notify on-call engineers whenever total 5xx request rates exceed 0.1% within any 5-minute rolling window.
- CIncrease the overall unified SLO target from 99.9% to 99.99% across all combined service endpoints to expand the absolute error budget buffer and absorb error spikes from secondary reporting queries.
- DDeploy a dedicated cold-standby multi-region disaster recovery deployment for background reporting endpoints to eliminate secondary reporting failures from consuming primary operational error budgets.