From Network Support to Production Infrastructure

There was a time when Linux itself felt difficult to me. I did not begin my career with a perfect plan to become a DevOps or infrastructure engineer. I began by trying to make myself useful in IT, learning what I could, and taking the next problem seriously enough to understand it.

Seven years later, Linux is still the foundation beneath most of the work I do. The scope is broader now: automation, cloud, Kubernetes, traffic handling, monitoring, mail systems, database operations, logs, and production troubleshooting. But the progression was gradual. It came through regular practice, operational responsibility, mistakes, investigation, and the habit of returning to a problem until I understood more of it.

The uncertain beginning

I completed a BCA, but after graduation I was uncertain about the direction I should take. I attended interviews and initially struggled to find an opportunity. That period was not a dramatic turning point; it was simply a reason to become more practical.

I chose hardware, networking, and cloud-oriented training through Jetking because I wanted a stronger grounding in the parts of IT that make systems usable in the real world. My first work was close to hardware and networking. It taught me that technology is rarely abstract when someone is waiting for a device, connection, application, or system to work again.

Linux entered that picture gradually. At first, it felt unfamiliar and unforgiving. Commands, permissions, services, package management, filesystems, and logs all required a different way of thinking. I did not understand it quickly. What helped was repeated practice. I set up systems, broke configurations, read documentation, tried again, and learned to be more patient with the details.

Linux eventually stopped being a subject I was studying and became the environment in which I worked.

When Linux became professional responsibility

My early system-administration work brought the fundamentals into production operations. I worked with CentOS and other Linux environments, server health, availability monitoring, CPU, memory, and disk investigation, user administration, application patch support, MySQL backups and maintenance, and routine troubleshooting.

Part of that work involved supporting a large distributed retail environment. The specific environment is not important here; the lesson is. When a system supports day-to-day business activity, routine operations need to be disciplined. A backup is not useful because it exists on a checklist. A monitoring alert is not useful because it was generated. Each has to lead to a decision, a check, or a recovery path that can be used when it matters.

Zabbix helped make server health visible. MySQL work taught me to look beyond an application symptom. POS and application support taught me that a user-facing error may originate in a service, database connection, filesystem, network path, or a dependency further away from the visible screen. The foundations were simple but important: check the service, inspect the logs, understand the resource state, make the smallest safe change, and verify the result.

Learning to operate larger Linux environments

Later, I worked with a substantially larger Linux environment across multiple servers and hosting or cloud environments. The responsibility expanded to routine maintenance, monitoring, backups, recovery, VPN and OpenVPN-related troubleshooting, network investigation, filesystem and storage issues, MySQL backup and recovery, basic tuning, and service-level diagnosis.

Managing one Linux machine teaches Linux. Managing many machines teaches operations.

The difference is consistency. A command that works on one host is not enough. Configuration needs to be understandable. Monitoring needs to distinguish normal noise from a meaningful change. Backups need recovery thinking behind them. Documentation becomes part of the operation, not an optional extra. A repeated manual task becomes a candidate for a safer, more repeatable process.

This phase also changed how I approached troubleshooting. I became more interested in the sequence of evidence than in finding one command that appeared to fix a symptom. A full filesystem, a slow service, a VPN complaint, or a database connection issue could each have several possible causes. The practical work was learning how to narrow that space without turning the investigation into guesswork.

Why I moved toward DevOps

As Linux operations became more familiar, I deliberately moved toward DevOps. I completed a DevOps engineering program through Simplilearn and used it as a structured way to study Git, GitHub, Jenkins, CI/CD, Ansible, Docker, and Kubernetes.

The course did not make me capable on its own. The useful part was the practice around it: building projects, getting configurations wrong, rebuilding them, and gradually becoming more confident about the relationship between Linux administration and automation.

I started to see that the gap between operations and development was often not a gap in responsibility. It was a gap in repeatability and feedback. Git-based workflows made changes more reviewable. CI/CD made deployment steps more explicit. Containers made application dependencies easier to describe. Ansible made repeated server work more consistent. Kubernetes introduced a different operating model, but it still depended on the same fundamentals: Linux, networking, storage, permissions, logs, process behavior, and careful validation.

When automation became practical

The next stage was where automation became useful for real operational problems rather than only a learning project. I worked with centralized Zabbix monitoring, Linux monitoring improvements, backup operations, Dockerized Python-based applications, Ansible, centralized server administration, patching, user management, system-information collection, and repeatable CPU, memory, and disk checks.

I also worked around Apache, PHP-FPM, application logs, Git-based workflows, CI/CD, and deployment automation. The work reinforced one lesson that I still use: automation is most useful when you understand the manual process first.

A process usually develops in stages: manual task, repeated task, documented task, automated task, monitored task. Skipping the first stages can automate confusion. Understanding the failure modes, approval points, inputs, and rollback path makes the automation more useful and safer to maintain.

Some of that operational thinking appears in the public work studies on centralized cron management and controlled file delivery with Flask, Redis and Nginx. They are sanitized patterns rather than production disclosures, but they reflect the same interest in repeatable operations, controlled access, and validation before change.

Making change safer

The same thinking applied to deployment and configuration work. A change is easier to operate when its inputs are explicit, its dependencies are known, and there is a way to tell whether it succeeded. Git, CI/CD, Bash scripting, Jenkins, Docker, Ansible, remote deployment workflows, backup automation, and centralized cron-management patterns all supported that goal in different ways.

I learned to value small, observable changes over broad edits made under pressure. Before a deployment or configuration update, I try to understand the current state, the intended state, the expected signal after the change, and the rollback path. That does not remove risk, but it makes risk discussable and testable. It also makes troubleshooting later more honest: if a system changed, there should be enough information to connect that change to the behavior that followed.

Moving into production infrastructure

Production infrastructure broadened the set of questions I had to ask. Linux administration remained central, across Ubuntu, CentOS, and RHEL-style environments, but the work often crossed boundaries: process and systemd behavior, CPU and memory pressure, OOM investigation, filesystem and storage management, permissions, networking, backups, recovery, firewall or VPN issues, and maintenance work.

The web and traffic layer added another dimension. I have worked with Nginx, Apache, PHP-FPM, HAProxy, Cloudflare, reverse proxying, load balancing, health checks, backend routing and weighting, SSL/TLS, redirects, security headers, access control, rate limiting, and traffic investigation. The technical details vary by service, but the operating question is familiar: what is actually failing, and where is the first reliable evidence?

A downtime investigation can involve abnormal traffic, an unhealthy backend, an application process, CPU pressure, memory pressure, OOM-killer activity, database behavior, a slow query, web-server behavior, network connectivity, or another dependency. The component reporting an error is not always the component causing it.

That is why I try to keep troubleshooting bounded. When did the problem start? What changed? Which systems are affected, and which are healthy? What do metrics and logs show? Is the issue related to traffic, a backend, the application, resources, storage, a database, or the network path? What is the safest change, how will it be validated, and what is the rollback?

The answer is not always visible immediately. The discipline is to gather enough evidence before making a change that removes it.

Monitoring that informs decisions

Monitoring became more useful as I moved from reacting to individual alerts toward comparing signals over time. My work has included Prometheus, Grafana, Node Exporter, Zabbix, centralized logging, syslog-ng, Elasticsearch-related operations, operational metrics, custom and textfile metrics, mail-queue metrics, alerting, log analysis, log rotation, hourly and daily log organization, and retention or archive workflows.

One practical example is reviewing approximately seven days of server-utilisation metrics to identify systems that repeatedly experienced high CPU or resource usage. The purpose was not to create a number for a report. It was to distinguish a short spike from sustained pressure and support a better recommendation: investigate the workload, optimise the application, redistribute work where appropriate, review CPU and memory sizing, or consider additional resources when the evidence supported it.

This is also where I learned that observability is not only dashboards. Useful logs need to exist, contain the right information, remain manageable, and be retrievable during an incident. Nginx, Apache, HAProxy, Postfix, application, and centralized logs each contribute a different part of the story. Log rotation, retention, organisation, and archive workflows are operational details until the moment an older record is needed to understand what changed.

GCP infrastructure operations: provisioning and operations

GCP is an important part of my current infrastructure responsibility. My work progressed beyond logging into existing virtual machines and operating only what was already there. I became involved in provisioning and maintaining the surrounding infrastructure itself: creating and maintaining projects, creating Compute Engine virtual machines, reviewing machine specifications, working with compute and storage resources, networking and access controls, GKE, container registries, monitoring utilisation, and reviewing infrastructure cost.

That means thinking through an infrastructure lifecycle rather than treating cloud as a service list. A requirement leads to a resource being provisioned, configured, secured for the right access, connected to a workload, monitored, troubleshot, and reviewed again as its utilisation and cost change. The operations continue after the resource is created.

My verified hands-on GCP work includes Compute Engine, GKE, Cloud Storage, VPC, IAM, Artifact Registry, Load Balancing, BigQuery, billing and cost monitoring, and CDN-related work. In practice, that has included VM lifecycle work, selecting or reviewing machine specifications, CPU and memory sizing, disk creation and expansion, persistent-disk sizing, static or external IP-related operations, subnet and network work, firewall and connectivity troubleshooting, IAM and service-account-related administration where applicable, container-image management, load-balancer-based service exposure, GKE node-pool operations, workload deployment and troubleshooting, backup and recovery considerations, and day-to-day cloud infrastructure investigation.

VM capacity, utilisation, and cost review

Capacity work is one way I connect monitoring to an operational decision. I have used Prometheus and Grafana metrics alongside operational data to review server behaviour across periods such as seven days. The goal is to identify machines that repeatedly reach high CPU or resource utilisation, separate sustained pressure from a short spike, understand the frequency and duration of those events, and identify systems that need deeper workload or application investigation.

The result is not an automatic resize. Depending on the evidence, the next recommendation may be to investigate the workload, redistribute work, review CPU and memory specifications, increase resources when justified, or reduce resources only when a system is clearly over-provisioned and it is safe to do so. A technically healthy system can still deserve review when its specification no longer matches its workload.

Cloud operations also have a financial dimension. I have maintained and reviewed infrastructure cost information including VM and disk or storage costs, resource-cost sheets, GCP billing, storage allocation, persistent-disk sizing, and utilisation in relation to the resource specification. The purpose is cost visibility and better sizing decisions, not an assumed savings claim. Infrastructure engineering is not only the question, “Is the server running?” It also includes, “Is this resource appropriate for the workload and its cost?”

My AWS exposure is proportionate and includes EC2, S3, IAM, and VPC. GCP is the stronger cloud-operating story, but in both environments the same fundamentals apply: identity, network boundaries, storage, capacity, cost, deployment, monitoring, and careful troubleshooting.

Kubernetes and application delivery

Kubernetes and GKE introduced another production layer while keeping the same underlying responsibilities. I have worked with Deployments, Pods, Services, ConfigMaps, Secrets, namespaces, RBAC and service accounts, PV/PVC storage, LoadBalancer Services, container images, Artifact Registry, node pools, selectors, taints and tolerations, replicas, rolling deployments, troubleshooting, logs, events, monitoring, and exporters.

This included practical work around application hosting, WordPress and PHP workloads on GKE, controlled SFTP or file-access requirements around workloads, production deployment or migration work, and backup and recovery considerations. The details remain intentionally high level because this is a career story, not a cluster design document.

Kubernetes did not make Linux less relevant. It made it more important to understand how a workload reaches storage, how a service reaches a backend, how identity and permissions affect a request, and how logs and events relate to the desired state. A separate Postfix mail relay on Kubernetes work study shows a sanitized example of how infrastructure responsibilities can cross application delivery, configuration, logging, and operations.

Mail infrastructure and the dependency chain

Mail infrastructure has been another meaningful part of my production work. I have worked with Postfix, SMTP relays, multi-instance Postfix operations, mail queues, deferred and bounced mail, provider delivery errors, relay and connectivity troubleshooting, transport maps, header checks, sender and domain configuration, DKIM-related operations, SPF/DMARC troubleshooting, centralized mail logs, mail-queue monitoring, Prometheus mail-queue metrics, and Kubernetes or GKE mail-relay workloads.

Mail delivery is a chain of dependencies. A useful investigation often follows a message from application to relay, queue, network or DNS behavior, and provider response. That sequence is more valuable than assuming the visible error is the first failure. Queue state, logs, configuration, connectivity, and external responses each need to be correlated before an operational change is made.

Databases as part of operations

I do not present myself as a database specialist, but MySQL and MariaDB work has been part of infrastructure operations throughout my career. That has included backups, restores, user and GRANT administration, connectivity and remote-access troubleshooting, bind and network configuration, maintenance, slow-query investigation, process and query troubleshooting, tuning work, and replication exposure.

The important boundary is knowing when a database symptom may be part of the wider service path. A slow application request can be an application issue, a web-server issue, a database query, resource contention, or a network problem. Database evidence needs to be read alongside system metrics and logs rather than in isolation.

What production troubleshooting taught me

Earlier in my career, I often approached a problem by asking, “What command fixes this?” Over time, the question became less useful than a sequence of better questions.

When did the problem begin? What changed? Which systems are affected? Which systems are healthy? What do the metrics show? What do the logs show? Is traffic involved? Is a backend unhealthy? Is CPU saturated, memory exhausted, disk or storage involved, or has the OOM killer terminated something? Is the application slow? Is a database waiting on a slow query? Is the network path healthy?

Only after that comes the change: what is the safest intervention, how will it be verified, and what is the rollback? Production troubleshooting is about correlation, not guessing. Logs are evidence. A graph is evidence. A service state, a queue, a process tree, a configuration diff, or a recent deployment can all be evidence. The work is connecting those signals without overreacting to one of them.

Seven years later

The biggest change in my work is not one tool. It is the way I connect them.

Linux remains the base. Automation is more useful because I understand the manual operations behind it. Monitoring matters when it informs a decision rather than only generating an alert. Cloud infrastructure carries a cost dimension as well as a technical one. Kubernetes changes the deployment model, but not the need for careful networking, storage, permissions, logs, and recovery thinking.

Certificates and courses can introduce a technology. Practical work builds confidence. I am still learning, and I think that is necessary in infrastructure work. There was a time when Linux itself felt difficult. Today I work across Linux, automation, cloud, Kubernetes, traffic, monitoring, mail infrastructure, and production troubleshooting. That transition did not happen in one jump. It happened through years of repeatedly encountering things I did not understand, learning them, using them, troubleshooting them, and moving to the next problem.

I am still learning.