DevOps Engineer interview question · Most asked
Your on-call gets hundreds of pages a week. How do you fix the alerting?
Summary
Measure pages and their actionability, then page only on user-facing symptoms with SLO burn-rate alerts, demote cause-based alerts (CPU, restarts) to dashboards or tickets, require a runbook for every page, and review the noisiest alerts every week.
Longer Answer
Multi-window burn-rate alerts (for example 14.4x over 1 h confirmed over 5 min) catch real incidents quickly and ignore blips. Keep a few predictive cause alerts that truly precede outages (certificate expiry, disk full soon).
Key Points
- Symptoms, not causes.
- SLO burn-rate paging.
- Every page actionable with a runbook.
- Continuous alert review.
Deep dive: DevOps in Production: 300 Pages a Week
Explanation
What interviewers look for
A data-driven, SLO-based approach and attention to on-call health.
More most-asked DevOps Engineer questions
- Design a CI/CD pipeline for a containerised microservice from commit to production.
- Pods keep restarting with OOMKilled under load. How do you investigate and fix it?
- How do you handle database schema migrations in an automated deployment pipeline?
- How do you handle secrets in CI/CD pipelines securely?
- What happens when you type a URL into a browser and press Enter?
- A rollback after a release made the outage worse because the database had already been migrated. How do you design releases so rollbacks are always safe?
- What are DORA metrics, and how would you use them without gaming them?
- Every deployment produces a burst of 502s. What do you check?