Ticket-ops vs SRE: why your incidents keep coming back
TL;DR: ticket-ops optimizes for closing tickets; SRE optimizes for eliminating the causes of tickets. The two models measure success oppositely, staff differently, and age differently: ticket-ops relationships degrade as environments grow, SRE relationships improve.
Here is a pattern we hear in almost every first conversation with a company unhappy with its database provider: the provider is responsive. Tickets get acknowledged fast, engineers are polite, dashboards are green, the monthly report shows SLA compliance. And the same replication lag incident has now occurred four times since January.
The company usually frames this as a quality problem: "they keep fixing it." It is a quality problem but more so, an operating model working exactly as designed. This article explains the difference between the two models, why one of them structurally cannot stop repeat incidents, and how to tell which one you are paying for.
The ticket-ops model, described fairly
Traditional managed operations is built around the ticket lifecycle:
- detect or receive,
- acknowledge within SLA,
- restore service,
- close,
- report.
Its metrics are
- response time,
- resolution time,
- ticket volume handled,
- SLA compliance.
Staffing follows the queue:
- tiered support lines,
- escalation paths,
- shift coverage sized to expected volume.
This model is not stupid. It is auditable, priceable, and scales linearly with headcount, which is why the outsourcing industry standardized on it. For stable environments with genuinely random, non-recurring issues, it is adequate.
Its structural flaw appears the moment incidents have systemic causes. In a ticket-ops model, the restart that clears the symptom closes the ticket. Fast. The cause (an under-provisioned replica, a query pattern that degrades under load, a backup window colliding with peak traffic) survives, and produces the next ticket. Nothing in the model's metrics registers this as failure; response and resolution times look excellent every single time.
Apache Cassandra is the best illustration of why this model fails on demanding engines. Cassandra problems like tombstone buildup, uneven partition distribution, or a misconfigured compaction strategy silently degrade performance before they become visible, and the platform ships with no built-in repair scheduling.
A ticket-ops provider restarts the node and closes the ticket; the compaction strategy is still wrong, so it happens again next month. The relational engines have their own versions: autovacuum left untuned on PostgreSQL, replication lag on MySQL. Same shape, same recurring ticket.
There is also an uncomfortable economic layer. A provider paid per ticket, or judged on ticket throughput, has no structural incentive to reduce ticket volume. Root cause work is expensive engineering that shrinks the metric the business runs on. Individual engineers may care; the model does not.
The SRE model, described fairly
Site reliability engineering starts from a different axiom: every incident is a defect in the system, and repeat incidents are defects in the operating process itself.
Its core practices follow from that axiom.
- Blameless postmortems with published root cause analyses
- Error budgets that convert reliability into an engineering currency
- Automation of everything done twice
- Capacity planning as a scheduled discipline rather than an emergency response.
- And crucially: the team that answers the page has the authority and the mandate to change the system so the page never fires again.
The metrics invert. An SRE team celebrates falling ticket volume; a ticket-ops business would starve on it.
Success is the absence of drama: incidents that never recurred, capacity walls seen quarters ahead, restores tested before they were needed.
The honest costs: SRE talent is more expensive per head, the model demands deep access to your environment (it works best in-your-account, where engineers can change infrastructure, not just observe it), and the first months of an engagement can surface uncomfortable findings, because removing failure classes starts with cataloguing them.
The diagnostic: three questions for your current provider
"Show me the RCA from our last repeat incident." Not the incident report with timestamps; the analysis with a cause and a remediation owner. Ticket-ops produces the former and calls it the latter.
"What have you automated in our environment this year?" SRE leaves a trail of runbooks turned into code. Ticket-ops leaves a trail of closed tickets.
"What did you recommend that we didn't ask for?" Proactive findings are the signature of a team engineering the system rather than servicing the queue. Silence is an answer.
What this looks like in practice
Maxima Consulting runs its managed database service as an SRE practice: 24/7/365 follow-the-sun coverage from Kraków and Pune (incidents hand off between awake teams with context, never waiting for a sunrise), root cause analysis on every significant incident, automation-first operations, and deployment in the client's own accounts so engineers can fix systems rather than merely observe them, all under a 99.99% uptime SLA enforced end to end. It is the same discipline we describe in our complete guide to site reliability engineering.
The longest-running proof is deliberately boring: a global financial institution managing over $3 trillion in assets, over ten years on this service, zero major outages. A decade in which the most remarkable thing is that nothing remarkable happened.
If your incidents keep coming back, the question is not whether your provider can do better. It is whether their operating model allows it. Schedule a discovery session.
