There are nights that change you.
You wake up the next morning looking exactly the same. You sit at the same desk. Open the same laptop. Drink the same coffee.
But something is different.
Because during the night, it wasn’t just a system that failed.
Some of your assumptions failed too.
One of those nights happened to me when a storage system went down.
For days afterward, I thought of it as a technical problem.
The storage had failed.
The cluster was affected.
Disks were misbehaving.
Logs were analyzed.
Recovery scenarios were tested for hours.
But as time passed, I realized that none of those things were the real problem.
The real problem was that I had started treating certain assumptions as guarantees.
I’ve spent most of my career around technology. Production systems, ERP platforms, databases, virtualization environments, network architectures. A large part of my professional life has been dedicated to keeping systems alive.
And when you spend enough years doing that, something strange happens.
You develop confidence.
You look at a system and quietly tell yourself:
“Yeah. This is solid.”
Then life teaches you a lesson.
Something can look solid without actually being resilient.
That night taught me the difference.
At some point, I stopped thinking about the technical details and started asking a different question:
Why was I more comfortable than the system itself?
I was comfortable.
There were backups.
There was monitoring.
There were alerts.
There were logs.
Everything that was supposed to make me feel safe was there.
But the system wasn’t safe.
Because that feeling of safety existed mostly in my head.
Not inside the system.
Most people think software is made of code.
I don’t think that anymore.
I think systems are made of assumptions.
This disk won’t fail.
This user won’t accidentally delete something.
This developer won’t make a mistake.
This service will always respond.
This certificate won’t expire unnoticed.
This backup will definitely restore.
This AI won’t make a dangerous recommendation.
Humans are interesting creatures.
When an assumption proves correct a hundred times, we slowly promote it to reality.
Then the hundred-and-first time arrives.
And reality reminds us who’s in charge.
In the days following the storage failure, I noticed something unexpected.
I wasn’t tired of managing systems.
I was tired of managing assumptions.
Every day brought a new one.
Security.
Backups.
Access control.
Human error.
Artificial intelligence.
Different topics.
Same pattern.
None of them were really technology problems.
They were decision problems.
Maybe that’s why many discussions about AI feel incomplete to me.
People talk endlessly about models.
Which model is better?
Which one is faster?
Which one is cheaper?
But in the real world, the problem is rarely the model.
The problem is the decision.
A system giving the correct answer is not the same thing as a system making a safe decision.
A service running is not the same thing as being reliable.
A backup existing is not the same thing as being recoverable.
An alert firing is not the same thing as being useful.
As I’ve gotten older, I’ve realized something uncomfortable:
The most expensive failures in technology are rarely technical failures.
They’re failures of assumptions.
The things we believed were true.
The things we stopped questioning.
Maybe that’s why my curiosity has changed over time.
Early in my career, I was fascinated by new technologies.
New frameworks.
New databases.
New tools.
New platforms.
Now I’m fascinated by different questions.
How does this break?
What happens when this assumption is wrong?
Why did nobody notice this risk?
Why was everyone convinced everything was fine?
Because a system reveals its true character not when it’s working, but when it’s failing.
People are a little like that too.
You learn who someone is during difficult times, not easy ones.
Systems are no different.
And maybe that was the most important lesson that storage failure left behind.
The storage system failed.
It created stress.
Sleepless nights.
Recovery plans.
Technical investigations.
But looking back, the most valuable thing it gave me wasn’t technical at all.
It gave me a question.
A question I hadn’t asked myself in a long time:
What does “safe” actually mean?
I still don’t know if I have a perfect answer.
But I know this:
The problem isn’t that disks fail.
The problem is that people eventually start believing nothing will.