I've been doing this for 20 years, having been involved in every level of system architecture and operations. But let me tell you a secret: I still break things every week. Yes, you heard that right. Sometimes small, sometimes annoying, and sometimes errors that make me think, "wow, how did I miss that?" The real issue isn't avoiding breaking things; because that's almost impossible. The issue is how quickly you understand what you broke, how you fix it, and most importantly, what you learn from that mistake.
The most expensive mistake of my career wasn't a line of code or a wrong command; it was often saying "yes" to projects that later became difficult to manage. But the situation I experienced this week was a good example of the "breaking" cycle in a system administrator's daily life, on a more micro scale.
Is Breaking an Art, or an Inevitable Outcome?
In engineering, striving for perfection while expecting zero errors is, in my opinion, unrealistic. As systems become more complex, as different components come together, as interactions increase, and when you factor in the human element, the probability of making mistakes multiplies. In fact, some "breaking" situations arise when trying new things, pushing limits. This is an inseparable part of innovation and learning.
For me, "breaking" is often the fastest way to understand the limits of a system or to realize a detail I've overlooked. Sometimes a configuration change, sometimes the deployment of a new feature, or sometimes just an optimization effort can lead to unexpected results. The important thing is to view these situations not as disasters, but as learning opportunities.
What Did I Break Most Recently? A SystemD Timer Adventure
Last month, I was working on a systemd timer that ran in the background of my side project, collecting and processing financial data at regular intervals. This timer called a small script written in Python. The script's job was simple: fetch data from an external API, process it, and write it to a database. This seemingly simple operation turned into a headache due to a small mistake of mine.
The symptom of the problem was this: when I woke up in the morning, I saw that some data on the dashboard hadn't been updated. My first check was journalctl -u my-service.timer. I noticed that the timer was running, but the systemd unit was frequently restarting. OOM-killed messages in the logs caught my attention.
systemctl status my-service.service
journalctl -u my-service.service
When I started investigating, I saw that I was using a time.sleep() command for 360 seconds (6 minutes) under a certain condition within the script. My goal was to avoid hitting the external API's rate limits. However, when running this script as a systemd service, I had set a soft limit like MemoryHigh=50M in the service definition. Normally, the script ran below this limit, but even while sleeping, memory usage sometimes exceeded this limit (instantaneous memory spikes from the Python interpreter and libraries). systemd then marked the service as OOM-killed and restarted it.
⚠️ The OOM-killed Trap
When using a
sleepcommand or making long-term waits in asystemdservice, it's important to consider the cgroup limits you've set for the service, such asMemoryHighorMemoryMax. Even while waiting, the process might momentarily exceed its allocated memory, leading to it beingOOM-killed.
The solution was actually simple: I removed the sleep command and added a smarter polling-wait mechanism that checked the API's rate limits. That is, I made the waiting dynamic, either when an error code came from the API or when there was a header indicating when I could make the next request. Additionally, I made the MemoryHigh value in the systemd unit definition a bit more flexible and used Restart=on-abnormal instead of Restart=on-failure so that unexpected exits would be managed better.
Lessons Learned from My Breakages
These kinds of situations constantly remind me of some fundamental principles:
- Observability: If my systems don't have enough metrics, logs, and traces, the debugging process turns into a nightmare. Without
journaldand Prometheus metrics, finding this problem would have taken much longer. - Monitoring: Anomaly-based monitoring can signal something even before it "breaks." The
OOM-killedlogs were actually an anomaly and should have triggered an alert immediately. - Idempotency: Designing every operation to produce the same result when run multiple times is critical. In my scenario, since data processing was idempotent, even if the service restarted, the data wasn't corrupted, only delayed.
- Simplicity and Clarity: The simpler a solution, the fewer errors it contains and the easier it is to understand. A dynamic strategy is always better than a fixed waiting period like
sleep 360. - Don't Be Afraid to Make Mistakes: Making mistakes is human nature. The important thing is to accept the mistake, learn quickly, and build systems to avoid making the same mistake again.
Error Culture and Growth
Whether developing an ERP for a manufacturing company, working on an internal platform for a bank, or even on the backend of my own side project, we always have the luxury of making mistakes. The point is to minimize the cost of these mistakes and maximize the benefit from them. In a team or individual career, openly discussing errors and finding solutions, rather than hiding them, is the fastest way to learn and grow.
For me, the question "What did I break this week?" is actually another side of the question "What did I learn this week?" Every mistake prepares me for the next step more consciously and competently. This is one of the most valuable lessons 20 years of experience has taught me.
So, what do you think? What was your most expensive mistake, and what did you learn from it? Feel free to share in the comments.
