When I started my career in IT, I never imagined that monitoring would become the foundation of my journey toward becoming a DevOps engineer.
Today, I work with observability platforms, infrastructure automation, Terraform, and DevOps practices. But my journey started somewhere completely different: as a Level 1 monitoring agent, watching alerts and opening incidents.
This is the story of how I got here.
Starting My IT Journey
Before entering the IT industry, I did not have a traditional IT background.
I studied Computer Science at university for two years, but due to family reasons, I was not able to complete my degree. After that, I started looking for opportunities where I could continue learning and build a career in technology.
Eventually, I joined a large international supermarket company’s IT organization as a Level 1 Monitoring Agent.
The company operates on a large scale, with thousands of stores and complex IT systems behind them. For someone entering IT for the first time, it was both exciting and overwhelming.
The team was great, the salary was very good, and I wanted to prove that I deserved the opportunity.
I wanted to become the best version of myself.
My First Experience with Monitoring
My first responsibility was infrastructure monitoring.
We used Checkmk to monitor hosts, services, and parts of the application landscape. We also handled what we called application monitoring, including technologies like SAP Process Orchestration (PO), message queues, enterprise service buses, and other integrations.
At the beginning, everything was new.
Every alert, every incident, every technology was something I had to learn.
My daily work involved analyzing Checkmk alerts, creating ServiceNow incidents, following Knowledge Base Articles (KBAs), and trying to resolve issues within the responsibilities of the Level 1 team.
However, I quickly realized something:
I wanted to understand the problems, not just follow instructions.
Sometimes I found solutions myself, but the official process required me to transfer incidents to the appropriate Level 2 or Level 3 resolver teams.
This was a difficult balance.
If the quality team reviewed an incident and I had acted outside the documented process, it could have negatively affected my performance metrics.
But sometimes I took the risk.
I tried to solve problems instead of just moving tickets around.
Luckily, my manager noticed this attitude and recognized my effort. Those moments gave me confidence that I was moving in the right direction.
Becoming an Infrastructure Monitoring SME
After around three months, my manager asked me if I wanted to become the Subject Matter Expert (SME) for infrastructure monitoring within the Level 1 monitoring team.
I was extremely proud.
For someone who had only recently entered IT, becoming an SME felt like a huge achievement.
For almost two years, I worked in this role.
During this time, I focused not only on solving incidents but also on improving how the team worked.
I started creating scripts and tools to make everyday tasks easier for my colleagues.
Examples included:
- Service restart automation
- Host restart automation
- Database troubleshooting scripts
- Tools to speed up store issue resolution
These small improvements helped the monitoring team respond faster and reduced repetitive manual work.
This was also when I discovered the importance of version control.
I introduced GitLab and started managing scripts properly instead of keeping random copies of files.
Looking back, this was one of my first steps toward automation and DevOps thinking.
Discovering the Bigger Picture of Monitoring
Being an SME gave me an opportunity that changed my career path.
I started communicating more with the central monitoring teams responsible for designing, operating, and improving monitoring platforms.
This was my first real introduction to monitoring as an engineering discipline.
Until then, I had viewed monitoring from the perspective of an operator:
- An alert appears.
- A ticket is created.
- A problem is fixed.
But I discovered another side:
- Why are we monitoring this?
- How do we design good alerts?
- How do we collect meaningful data?
- How can monitoring help teams understand their systems?
This was my first introduction to observability.
I realized that monitoring was not just about reacting to failures.
It was about understanding systems.
At that point, I decided that I wanted to become a Monitoring Engineer.
Moving Into Monitoring Engineering
About one and a half years ago, an opportunity appeared.
I joined the monitoring engineering team as a Level 2 Senior IT Professional.
This was a major step forward.
For the first time, I was working directly with monitoring platforms instead of only consuming their alerts.
I started working with:
- Dynatrace
- Grafana
- Synthetic monitoring
- APIs
- Automation
One of my first major tasks was creating HTTP monitors in Dynatrace.
The work was interesting, but after creating many monitors manually through the graphical interface, I started thinking:
“There must be a better way.”
So I built a PowerShell script that could create Dynatrace monitors in bulk through the API.
This was a turning point for me.
I was no longer just using tools.
I was automating them.
Around this time, I was introduced to Terraform and Infrastructure as Code.
That opened another door.
I discovered DevOps.
Becoming a DevOps Engineer
The idea behind DevOps immediately attracted me.
Automation, collaboration, infrastructure as code, repeatable processes — these concepts matched the way I naturally wanted to work.
I did not want to manually repeat tasks.
I wanted to build solutions that scaled.
Four months ago, I was promoted to the Level 3 team as a DevOps Engineer.
My first major project was managing Dynatrace Identity and Access Management using Terraform.
The goal was to automate and standardize:
- Groups
- Policies
- Permissions
- Boundaries
- Management zones
- Problem alerting profiles
- Problem notifications
The project also required working with a strict tagging system and custom modules to manage access based on organizational requirements.
This was my first large-scale Infrastructure as Code project, and it showed me the real power of automation.
Where I Am Today
Currently, I am continuing to deepen my knowledge of Dynatrace and observability.
I am exploring areas such as:
- Real User Monitoring (RUM)
- Host monitoring
- Log monitoring
- Distributed tracing
- OpenPipeline
- Advanced alerting
- Observability automation
I still consider myself a learner.
Technology changes constantly, and nobody knows everything.
But I believe the best way to grow is by building, experimenting, documenting, and sharing what I learn.
Why I Created This Blog
This blog is a place where I document my journey through monitoring, observability, and DevOps.
I want to share:
- Things I learn
- Problems I solve
- Tools I experiment with
- Automation ideas
- Real-world engineering experiences
My journey started with simply watching alerts.
Now I am learning how to build the systems that create those signals.
And the journey continues.