Listen, if you stay in this game long enough, you realize that hardware is fleeting, software is a vapor, but a poorly defined Jira ticket is eternal.
I recently watched a junior engineer attempt to clean up our backlog. He stopped at a ticket created in late 2013: “OPS-4092: Deprecate legacy NFS export on storage-node-02.” He laughed and said, “We don’t even have a storage-node-02. We don’t even have that datacenter anymore.”
He thought it was a joke. I didn’t laugh. I remembered when we racked storage-node-02. I remembered when we decommissioned it in 2017, migrated the share to a virtual appliance, then to AWS EFS in 2020, and finally to a managed Kubernetes storage class last year. Four entire geological epochs of infrastructure have risen, sedimented, and fossilized under that ticket. Yet OPS-4092 remains, open, unassigned, and pristine.
We like to think of our ticketing systems as mirrors of our infrastructure. But if you look closely, the opposite is true. The infrastructure is merely a series of unstable, fleeting implementations of our tickets.
The Archaeology of the Ghost Ticket
To understand why OPS-4092 cannot be closed, you must understand the concept of organizational scar tissue. Every infrastructure migration is a compromise between what we planned to do, what we actually did, and the parts we ran out of budget to finish.
When storage-node-02 was shut down, 95% of the data was moved. The remaining 5% belonged to a crontab run by an billing script written in Perl by a contractor who vanished in 2015. Nobody knew what the script did, but if it didn’t run, the finance department didn’t get their end-of-month reports, and when finance doesn’t get their reports, payroll gets delayed.
So, we built a proxy. We pointed the old IP address at a VM that faked the NFS export, which eventually pointed to an S3 bucket. OPS-4092 was updated: “NFS moved to proxy. Need to rewrite Perl script to use S3 API directly before closing.”
That rewrite was estimated at “two days.” That was eight years ago.
The Ticket as the Actual State Machine
We treat tickets as tasks to be checked off, assuming that “done” is a binary state. But in the real world of enterprise systems, “done” is a luxury. The ticket isn’t a task; it has become the state machine itself. The infrastructure changes around it, but the ticket remains the only source of truth that the problem still exists.
To keep these ghosts alive across migrations, we write automation. Not to fix the problem, but to manage the persistence of the ticket across different cloud providers.
#!/usr/bin/env bash
# JIRA-4092-persistence-daemon.sh
# Run this via systemd to make sure we don't accidentally close the ticket
# during the next "lift and shift" migration.
TICKET_ID="OPS-4092"
JIRA_API="https://jira.corp.internal/rest/api/2/issue/${TICKET_ID}"
# Check if the host we are supposed to deprecate even exists in DNS
if ! host storage-node-02.internal >/dev/null 2>&1; then
# The physical hardware is gone, but the debt remains.
# Update the ticket summary to match the current decade's buzzwords.
CURRENT_BUZZWORD="Cloud-Native Serverless Storage Class"
curl -s -X PUT \
-H "Content-Type: application/json" \
-H "Authorization: Bearer ${JIRA_TOKEN}" \
-d "{\"fields\": {\"summary\": \"[MIGRATE] Move legacy NFS from ${CURRENT_BUZZWORD} to next-gen equivalent\"}}" \
"${JIRA_API}"
echo "Refreshed ticket ${TICKET_ID} for the cloud era."
fi
This script is funny because it is true. It represents the endless loop of modern systems administration. We do not solve problems; we simply translate them into newer, more expensive abstraction layers.
The Comfort of Eternal Debt
Why doesn’t anyone just close it? Why doesn’t the VP of Infrastructure click “Resolve” and be done with it?
Because closing the ticket requires taking responsibility for the unknown. As long as OPS-4092 is open, the risk is managed. It is a known unknown. It is documented. If the billing system breaks, we point at the ticket and say, “Ah, yes, the legacy NFS issue. We have a ticket for that.”
If we close the ticket, the connection between the modern Kubernetes cluster and that ancient Perl billing script is severed in our minds. The debt is still there, but now it is unmapped. It becomes a landmine in the dark.
We keep the ticket open because we need the monument. We need to look at the backlog and see our history written in the comments. It is the only diary we have.
The serial console on the legacy SAN expansion shelf just started spamming SCSI sense key 3 errors.
