HJ_ devops / sre

open to work

PKT --:--:--

system online open to remote & relocation

Hamza Jamil

role /

I keep mission-critical, 24/7 infrastructure online — 100+ Linux servers, HA PostgreSQL clusters, and observability that finds problems before users do.

View case files Contact
Linux servers & VMs
100+
Faster incident detection
60%
Years in production
1.5+

telemetry / fig. 01

illustrative
Observability topology One hundred plus Linux VMs run Grafana Alloy, which ships metrics and logs to Prometheus and Loki on a dedicated monitoring server. Grafana reads both stores. Blackbox Exporter probes the master and feeds results to Prometheus. LINUX FLEET 100+ VMS VM 01 alloy VM 02 alloy VM 100+ alloy ALLOY collect + ship BLACKBOX probe master → prometheus metrics logs PROMETHEUS metrics / tsdb LOKI log store GRAFANA dashboards COLLECT SHIP STORE SEE
100+ nodes −60% mttd ha patroni
Illustrative topology — not live telemetry.

01About

Calm infrastructure, quiet on-call.

The systems I run, and how I got here.

Most of my work is invisible when it is done right: servers that stay up, databases that fail over cleanly, and alerts that reach someone before a user notices.

I look after 100+ Linux servers and VMs behind national-scale transport infrastructure, run Patroni-based PostgreSQL clusters, and build the observability layer that shows what is happening across all of it.

I started with the DevOps Bootcamp at TrainWithShubham, building CI/CD pipelines, Terraform infrastructure on AWS, and Kubernetes deployments. Today I work across on-premises and AWS, with daily releases, Ansible-driven configuration, and health checks built into the routine.

I am based in Rawalpindi, Pakistan, and open to remote roles or relocation.

  • On-prem + AWS
  • Patroni / PostgreSQL
  • Prometheus + Grafana
  • Daily releases
  • Ansible at scale
  • Remote / relocation

02Stack

The stack, grouped by job.

No percentage bars, no star ratings — just the tools I use to keep systems running.

  • 01 / SYS

    Linux & Systems

    • Linux servers
    • VMs
    • systemd
    • Shell scripting
    • On-premises
  • 02 / CI

    Automation & CI/CD

    • Jenkins
    • Ansible
    • GitHub
    • Trivy
    • Docker Hub
  • 03 / CTR

    Containers

    • Docker
    • Kubernetes
    • Deployments
    • StatefulSets
    • Ingress
    • HPA
  • 04 / CLD

    Cloud & IaC

    • AWS EC2
    • VPC
    • IAM
    • Load balancers
    • EKS
    • Terraform
    • Cloudflare
    • Hostinger VPS
  • 05 / OBS

    Observability

    • Prometheus
    • Grafana
    • Loki
    • Grafana Alloy
    • Blackbox Exporter
    • ELK stack
    • ICMP / HTTP / TCP probes
  • 06 / DB

    Databases

    • PostgreSQL
    • Patroni
    • HA replication
    • pg_dump / restore
    • NFS backups
    • Redis
  • 07 / APP

    Web & App Stack

    • Nginx
    • uWSGI
    • Daphne
    • Celery Worker / Beat
    • SSL / custom domains
    • On-prem LLM hosting

03Experience

Release history.

Production operations first, then the training that led there.

  1. now current

    DevOps Engineer

    One Network

    production
    • Built a centralized observability platform with Prometheus, Grafana, Loki, Grafana Alloy and Blackbox Exporter across 100+ Linux servers and VMs; cut mean time-to-detection by 60%.
    • Built Grafana dashboards for CPU, memory, disk, top processes, ICMP ping latency, probe duration and centralized logs; also run a centralized ELK stack with Filebeat, Logstash, Elasticsearch and Kibana.
    • Operate Patroni-based HA PostgreSQL: manual replication setup, replication failure recovery, pg_dump backups to NFS, and restores into newer PostgreSQL versions.
    • Write and run daily Ansible playbooks for configuration changes on database servers and remote toll-plaza booth PCs.
    • Run production applications — uWSGI, Daphne, Nginx and Celery Worker/Beat as systemd services — with daily releases and health checks.
    • Manage AWS EC2 instances inside a VPC with PostgreSQL, Redis and the backend installed directly on the VM; run a Hostinger VPS with custom domains, SSL and Cloudflare.
    • Host an LLM on-premises and reduced manual effort by 70–80% with shell scripting.
  2. internship

    DevOps Engineer (Intern)

    TrainWithShubham

    training
    • Built Jenkins CI/CD pipelines connected to GitHub, using Trivy for security scanning and Docker Hub for image storage.
    • Deployed workloads on Kubernetes with Deployments, StatefulSets, Ingress and Horizontal Pod Autoscaling.
    • Provisioned AWS infrastructure with Terraform: EC2, IAM, VPC, load balancers and EKS.
    • Monitored workloads with Prometheus and Grafana.

04Case files

Four systems. Four constraints.

An observability platform, an AWS delivery path, an HA database topology and a production deployment on plain VMs. Employer systems are described generically; internal details stay internal.

case 01observability

production · internal

Centralized observability for 100+ servers

  1. 01 / collectGrafana Alloyon 100+ VMs
  2. 02 / shipMonitor serverdedicated host
  3. 03 / storePrometheus + Lokimetrics + logs
  4. 04 / seeGrafanadashboards

blackbox / http · tcp · icmp → master health

Problem

With more than 100 Linux servers and VMs across on-premises and AWS, detection depended on someone noticing. The goal was one place to see metrics, logs and connectivity, with probes that catch a dead or isolated node quickly.

What I built

A dedicated monitoring server running Prometheus, Loki and Grafana. Grafana Alloy runs on every VM and ships logs and metrics locally to that server. Blackbox Exporter on replica servers probes the master over HTTP, TCP and ICMP. Grafana surfaces CPU, memory, disk, top processes, logs, ICMP ping latency and probe duration with dashboards and logs.

A separate ELK stack — Filebeat, Logstash, Elasticsearch and Kibana — handles centralized application logs.

Stack

  • Prometheus
  • Grafana
  • Loki
  • Grafana Alloy
  • Blackbox Exporter
  • ELK
  • Linux

Result

100+ servers in one view, mean time-to-detection cut by 60%, and a single dashboard for master/replica health, logs and connectivity.

Internal system — no public repository. Ask me about it.

Monitoring architecture: Grafana Alloy agents on 100+ servers push metrics and logs to a dedicated monitoring server running Prometheus and Loki, visualized in Grafana; Blackbox Exporter on replica VMs probes the master over HTTP, TCP and ICMP.
Fig. 01 / architectureThe production topology: agents, collection, storage, dashboards and external probes. Open the image to read the detailed labels.

case 02ci/cd + iac

training project

AWS delivery path with Terraform and Jenkins

Problem

Build a repeatable path from a GitHub commit to a running AWS environment: infrastructure you can recreate, images you can trust, and a deployment that does not depend on hand-run commands.

What I built

Terraform code for AWS infrastructure — VPC, IAM, EC2, load balancers and EKS. Jenkins pipelines connected to GitHub build the application, scan it with Trivy, build and push Docker images to Docker Hub, and deploy. Kubernetes manifests cover Deployments, StatefulSets, Ingress and Horizontal Pod Autoscaling. Prometheus and Grafana close the loop.

Fig. 02 / delivery flow Simplified pipeline based on the project's toolchain. Terraform provisions the AWS layer before deployment.
  1. 01SourceGitHub
  2. 02Build & testJenkins
  3. 03Security scanTrivy
  4. 04ImageDocker
  5. 05RegistryDocker Hub
  6. 06DeployEC2 / EKS
  7. 07ObservePrometheus + Grafana
Terraform VPC IAM EC2 Load balancers EKS provisioned before deploy

Stack

  • Terraform
  • AWS
  • Jenkins
  • GitHub
  • Trivy
  • Docker
  • Docker Hub
  • Kubernetes / EKS
  • Prometheus
  • Grafana

Result

A reproducible AWS environment and an automated, scanned release path; Kubernetes handles scaling through HPA, while Prometheus and Grafana make the deployed system observable.

No public repository listed for this project.

case 03databases

production · internal

HA PostgreSQL with Patroni

Problem

A single PostgreSQL node is a single point of failure. Replication, failover and restores had to be understood and recoverable, not just configured once.

What I built

A Patroni-managed PostgreSQL cluster: one primary and two replicas, with etcd as the coordination layer that decides the leader. HAProxy routes writes to the primary and reads to replicas. I set up replication manually, handled replication failure recovery, and built pg_dump backups to NFS, including restores into newer PostgreSQL versions.

Stack

  • PostgreSQL
  • Patroni
  • etcd
  • HAProxy
  • pg_dump
  • NFS
  • Linux

Result

Replication failures can be recovered, the cluster has a clear leader, and backups are restorable into newer PostgreSQL versions.

Internal system — no public repository. Ask me about it.

Patroni PostgreSQL cluster topology Clients connect through HAProxy. Writes go to the primary Patroni node and reads go to two replicas. The primary replicates to both replicas, and all nodes report health and leader status to an etcd cluster that handles leader election. CLIENTS web · api · workers HAProxy writes → primary · reads → replicas writes PRIMARY · PATRONI handles writes reads reads REPLICA 1 · PATRONI handles reads REPLICA 2 · PATRONI handles reads replication replication health · leader status etcd cluster leader election · quorum
Fig. 03 / cluster topologySimplified cluster topology. Backup path: pg_dump → NFS; restores tested into newer PostgreSQL versions.
View full topology

case 04production vms

production · internal

Production application deployment on VMs

Problem

No managed platform: the proxy, application servers and background workers all run on VMs, so releases, process supervision, TLS and health checks have to be deliberate.

What I built

Nginx in front of uWSGI and Daphne, with Celery Worker and Beat supervised as systemd services. Daily releases with health checks, plus Ansible playbooks for configuration changes on database servers and remote toll-plaza booth PCs. On AWS, EC2 instances inside a VPC run PostgreSQL, Redis and the backend directly on the VM. On Hostinger VPS, I manage custom domains, SSL and Cloudflare. I also host an LLM on-premises.

Fig. 04 / request pathClient traffic to data, with background jobs supervised alongside the app.
  1. CloudflareDNS · proxy · SSL
  2. Nginxreverse proxy
  3. uWSGI / Daphneapp servers
  4. PostgreSQL · Redisdata on the VM
  5. Celery Worker / Beatsystemd-managed jobs

Stack

  • Nginx
  • uWSGI
  • Daphne
  • Celery
  • systemd
  • Ansible
  • AWS EC2
  • Hostinger VPS
  • Cloudflare
  • SSL

Result

A repeatable daily release routine on infrastructure I control, with supervised processes and health checks after every deploy.

Internal system — no public repository. Ask me about it.

05Training

Records, with no inflated labels.

The AWS item below is a preparation course, not an earned certification.

  1. r-01 training

    DevOps Bootcamp

    TrainWithShubham

    Hands-on CI/CD, Kubernetes, Terraform, AWS and observability with Prometheus and Grafana.

    2025
  2. r-02 preparation course

    AWS SAA-C03 preparation

    Udemy

    Coursework covering AWS Solutions Architect – Associate objectives. Not an earned certification.

    year n/a
  3. r-03 education

    BS Computer Science

    University of Balochistan

    Computer science foundation behind the systems work.

    2019–2023

06Contact

Open a channel.

I am open to remote DevOps / SRE roles and relocation. Email is the fastest route. No form, no backend — just a direct line.

open to remote & relocation

mail hamzajamilhj11@gmail.com
Email me