I initially thought of tickets as just customer support, or internal JIRAs, but the article mentions alarms, security findings, and capacity increase requests, so that makes the scale feel more plausible. Still surprising so many tickets go through the system.
So, a lot of tickets generated would simply just be data reports with some info dumped in the ticket description, designed to be auto-closed but possibly useful later as an easily-accessible timestamped reference to some data.
Lots of other auto-generated tickets were "probably not an issue but it should pass over the eyes of someone knowledgable about this server/network" tickets. Like Windows Event Log error roundups, CPU usage spikes, or specific triggers that were set up in the aftermath of some catastrophe to help preemptively avoid a repeat incident.
Anyway, tickets are a great "first line of filtration" where you can take a massive ingest of all different kinds of data (hardware metrics, system logs, network activity), apply meaningful human context ("This pattern could be a sign of xyz"), and store it in a unified database. With that use case, it's easy to imagine a company with millions of customers and millions of servers producing millions of tickets.
Also ticketing systems in my (very) limited experience tend to be bloated pieces of software, so that adds a fun dimension to it.
But the human team is what understands the big-picture context and the way it changes over time, so it makes sense for them to manage the triggers for the "this may be important" tickets—for them to then ingest and discern whether it's important. Ultimately, ticketing software is just a tool designed to distribute context-stamped information to humans who then discern what to do with it.
So I think just like all other productivity software, it's only as good as the human system in place that drives its usage. That explains the bloat as well—it's not its own system, it's a big old suite of tools that are each available to be implemented into a human system if desired, or ignored if not.
Anything else, that needs a human to interpret or take action on, yes, ticket systems get extremely wide usage.
We also had tickets that would trigger scripts upon generation, e.g. an auto-generated "low disk space" ticket would then trigger a basic "disk cleanup" script, and close itself if enough space was freed to clear the threshold. Yes, it's comical that the ticket would do that—but hell, it worked great. It ran agnostically across thousands of differently-configured machines. And whether or not it was a human who clicked the "disk cleanup" button shouldn't determine the usefulness of having that event logged in the ticket database.
Point is, the whole system was a veritable Swiss Army knife that didn't necessarily have to equate a "ticket" (database entry) to "requires human intervention", provided there was a good human system in place to leverage the tool in a way that was productive for them.
but i have 3 different support organizations, all of which are external. no ticket == no accountability, and that matters if and when things get ugly, like lawsuit territory level ugly
I checked just for fun and there are actually a LOT LOT more than 92M tickets in the past year.
heck, there's even a ticket if the office toilet is clogged
I'd rather have tickets for everything and full transparency except for confidential info.
In my experience, corporate bureaucracy is a slowly grown defense mechanism created from an attempt to stop dumbasses and assholes.
If you dont fully pay attention to their theories about what they think is the reason for the suspicious stain on the ground in the parking lot, the queue is going to get flooded. If your Boss belongs to that club oh man god say the division.
“submit a ticket!”
People that don't like issue trackers are people that like spending hours a week manually maintaining spreadsheets, keynotes, or kanban to do the same.