More on ticketing

---

CLI tools are pleasant to work with in part because of their integration with day-to-day engineering tasks. Context switching is a drag, and I think that it would be hugely convenient if one could interact fluently with ticketing systems via terminal commands — often right alongside log viewing or code editing.

Note: This article is still very much a work in progress.

As a first step towards making this possible, I wrote an API client for Zendesk - a popular ticketing platform that has already implemented lots of interesting endpoints, including event triggers - and started writing a TUI app around that.

This has been really really fun. The ratatui library for Rust is extremely rich and well thought out, even going as far as to provide reference architectures in their documentation which helped me get a head start.

The basic unit of this erstwhile system is of course the ticket, so the first thing I implemented was a ticket browser:

Then a ticket view:

Before moving on to search:

And finally the relationship graph. I looked into a bunch of visualization options, and came up with something like this:

This is where things really started to get interesting. Thinking of what the graph might look like, what relationships are worth focussing on? The requester is certainly important, as is the title and description. Tags are absolutely important, though not always reliable in terms of consistency. Comments / work notes could probably be the most interesting, if we know what to look for. For now, I’m going with an all-of-the-above approach, with comment edges just ignoring common words and phrases and hoping for the best.

I did implement a form of sideloading and pagination in an attempt to make pulling more lots of data from the API more efficient, but I think I may reach a wall soon in terms of pulling down enough data to get the relationships I’m looking for without making the terminal UX much less zippy.

That all being said, the CLI isn’t meant to fully replace rich web applications, particularly for end-users who prefer graphical dashboards. Integrating real-time event-based ticketing into public or internal-facing status pages could further enhance transparency.

What else could be improved?

There’s a lot more that goes into running an effective support operation that waiting for things to break. Documentation can always be iterated on, runbooks can be refined, and the opportunities for fact-finding your product are infinite.

That being said, I think that some form of ’event-based’ ticketing could be a big improvement over the ‘wait and see’ approach. Instead of depending solely on user-initiated tickets, what if support teams could build up an internal understanding of what their customer’s environment and history, without cross-referencing pages of tickets?

I know what you’re thinking - spying on your users is so zeitgesty, tell me more! The military and intelligence sectors have long embraced similar models, creating complex event-processing systems that integrate disparate streams of data into situational awareness platforms. Meanwhile, most enterprise IT support is trapped in loops of redundant questioning, as if each problem were unprecedented. Why do we do this ourselves, you say?

I am not saying that we should spy on users, and I want to be deliberate in saying that any hypothetical program should not collect anything other than the text that we and the user generate within the shared context of tickets.

The thing is, I don’t think that the questioning is due to lack of data. Rather, every system that I’ve used merely structures data in ways that directly accelerate problem-solving. Rather than making connections between events in situ, they farm the work out to some internal analytics appendage that traps any insights behind a set of fields - date, time, user, description, etc.

The familiar experience of funneling logs upwards and slicing and dicing them is a vast improvement over what came before; but it doesn’t do the work to place the user in the problem space. Placing the user and the system and a specific when where why is the first step in triangulating a given issue, and if we could have a footprint of that rather than searching through ticket titles and comments, that would be awesome.

Event-driven architecture and the ticketing imprint

Consider the concept of a ticket ‘imprint’. Rather than viewing tickets as unstructured text blobs, we could treat them as structured artifacts:

Imprint Schema

• Semi-structured data representing information about customer, including their environment and problem space, gathered from past interactions.
  • Predefined Tags (Service, Category, Username, User associations)
  • Emergent Tags (Platforms, Environment, Concentration)

Predefined tags are familiar, and can serve as keys to organize any results. Emergent tags, on the other hand, could be generated from the body of text associated with the predefined tags.

Structured this way, each ticket record could serve as a form of simple intelligence. Successive engineers would be able to quickly ascertain context from previous interventions, hopefully compressing the troubleshooting cycle.

There are also large benefits to building this approach from the ground up, such as implementing RAG (so hot right now) and some really out there web GUI implementations, like this

I’m thinking this might also take the shape of a third project, where the aforementioned TUI made with the Zendesk API client could be configured to work with this new application. Perhaps the architecture could look something like this:

CLI Client                       Web Backend                       Web Frontend
───────────                       ───────────                       ────────────
┌───────────────┐ Analytics ┌───────────────┐ Transactions ┌───────────────┐
│   Imprints    │──────────▶│  Data Service │─────────────▶│Service Catalog│
│   (MongoDB)   │           │  (Clickhouse) │─────────────▶│ User Tickets  │
└───────────────┘           └───────────────┘─────────────▶│ Status Page   │
       ▲                              ▲                    └───────────────┘
       │ API Calls                    │
┌───────────────┐             ┌───────────────┐
│    Client     │────────────▶│ API Gateway   │
│   (CLI TUI)   │             └───────────────┘
└───────────────┘                      ▲
       │                               │
       └───────────────────────────────┤
                                       │
                             ┌───────────────┐
                             │ Authentication│───▶ Messages
                             │   (KeyCloak)  │
                             └───────────────┘

More hopefully to come!