Comment by dansalvato | Hacker News Reader

Comment by dansalvato | Hacker News Reader

Parent Full thread

In my past experience in IT, the ticketing system basically doubled as an aggregated event log, and it was a legitimately good use case. The monitoring software we ran on our thousands of client workstations and servers was extremely powerful and could capture any conceivable metric to use as a trigger for auto-generating a ticket.

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.

I've never seen a ticket system used as just a dumping ground for data in auto-closed tickets. Seems like there would be better solutions for that, particulary for data you want to find later (in my experience, the search capability of ticket systems varies from poor to "don't bother, you won't find what you're looking for")

Anything else, that needs a human to interpret or take action on, yes, ticket systems get extremely wide usage.

Right, I didn't mean using tickets as a generic event log—the assumption is that someone would have set up triggers because they actually have a reason to have the data on hand, and it's a low-friction way of getting what they need without worrying about implementing new tools or systems. In a good human system, the trigger would be disabled once that info is no longer useful. (And in a bad human system it would just stick around until nobody knows what it's for anymore, haha.)

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.

That makes sense, but a part of me is wary of introducing noise at such a scale and drowning out whatever signal remains.

Also ticketing systems in my (very) limited experience tend to be bloated pieces of software, so that adds a fun dimension to it.

Indeed, I learned pretty quickly that maintaining the line between "underreported information" and "information overload" is an indefinite challenge that evolves over time as context changes.

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.

Reply on news.ycombinator.com