Symptom: the ticket is closed, the customer is happy and you could not tell a colleague what actually fixed it. If that sounds familiar, you are not alone, and it is worth treating as a fault to diagnose rather than a quirk of busy weeks. A fix you cannot explain is a fix you will have to rediscover. Below is a plain diagnosis of why support engineers end up there, and a short treatment that costs about twenty minutes per incident: explain what you just learned to a beginner, in writing, while the details are still fresh.<\/p>\n
You restart a service, clear a cache or roll back a setting, and the problem disappears. The pressure to move on to the next ticket is real. Because you are not sure which of your three actions did the work, you record “resolved after restart” and close it. Two weeks later a different engineer meets the same alert, reads your note and restarts the service again, only to find it does not help this time. The note had the outcome but not the understanding.<\/p>\n
The third cause is the one a teaching exercise fixes directly. The moment you imagine a beginner reading your note, you find out which parts of the reasoning you cannot supply.<\/p>\n
Right after the incident, before you pick up the next ticket, do the following.<\/p>\n
Whenever you hit an “unknown”, resolve it properly: reproduce the problem in a test environment and apply the actions one at a time. A home lab is ideal for this, and a hands-on tutorial like setting up a safe practice space for DevOps at home<\/a> shows how to build one cheaply. Reproducing the fault turns a lucky fix into knowledge.<\/p>\n Give the finished note to someone newer than you and ask one question: “What would you do if this alert fired tonight?” If their answer matches what you did, the note works. If they ask something your note does not answer, you have found the next gap, and you can patch it immediately. Over time you should see fewer repeat tickets that start from the same confusion and fewer escalations that begin with “I do not know why this worked last time”.<\/p>\n This method has limits, and it is better to be upfront about them.<\/p>\n A pile of private notes helps one person. Shared and public notes help many. For internal material, a team wiki works. For general lessons stripped of anything sensitive, consider a public blog. MyBlogPad<\/a> is a blogging network where a blog gets its own subdomain, sign-in is through Google, and several people can contribute; the service describes itself as free to start. Short “what I learned” posts there double as a visible record of how you reason, which is useful the next time someone asks what you have been working on.<\/p>\n To make this concrete, here is the shape of a good entry. Title: “Why the nightly job reported success but produced an empty file”. Symptom: reports arrive blank every Monday. First belief: the job crashed silently. Actions: checked logs, reran manually, widened the disk quota. Which one mattered: unknown until I reran it in a test copy, where only the quota change failed to help. Cause: a source folder was being rotated at the same moment the job started, so it read nothing. Quick check: compare the folder’s modification time with the job’s start time. Nothing in that entry is clever, yet it would have saved me two hours the previous month.<\/p>\nVerification: how to tell the treatment is working<\/h2>\n
Contraindications<\/h2>\n
\n
Prescription: give the notes a home<\/h2>\n
A sample entry, trimmed<\/h2>\n