Amman, Jordan
DEVOPS ENGINEER3+ YEARS IN PRODUCTION

Infrastructure
that holds
under pressure.

3+YEARS HANDS-ON
06SELECTED SYSTEMS
08TOOL CATEGORIES
24/7PRODUCTION MINDSET
THE OPERATING MODEL

I connect the full path—not isolated tools.

01SOURCEGit / Repos
→
02BUILDCI / Images
→
03SHIPAnsible / Helm
→
04OPERATEObserve / Recover
METRICSLOGSTRACESALERTSRUNBOOKS
01PROFILE

I don’t just deploy software.
I make it operable.

I’m Saied Awad, a hands-on DevOps engineer working across production infrastructure, delivery automation and platform reliability.

At Nixpend, I support environments that span ERPNext/Frappe platforms, APIs, microservices, databases, CI/CD systems and a full observability stack. The work is practical: ship changes safely, diagnose failures across layers, protect data, and make recovery repeatable.

My strongest work happens at the intersection of application, container, network, proxy, database, storage and host—where production problems rarely respect team boundaries.

02CAREER

Production is the
real classroom.

My experience is built around systems that people actually depend on.

2023 — PRESENTAMMAN, JORDAN

CURRENT ROLE

DevOps Engineer

Nixpend — Sequential Technologies

Operate Linux development, testing, monitoring and production infrastructure. Maintain containerized application stacks, Frappe/ERPNext environments, databases, reverse proxies, backup systems and delivery automation across multiple servers and customer sites.

  • Design and maintain branch- and tag-aware Azure DevOps pipelines.
  • Coordinate production releases through GitLab, Ansible and manual approval.
  • Operate Grafana, Prometheus, Loki, Tempo and alerting infrastructure.
  • Troubleshoot incidents spanning queues, storage, TLS, networks and builds.
  • Create runbooks so critical operations can be performed safely by others.
ENGINEERING DEGREEJORDAN

EDUCATION

Bachelor of Engineering

Al-Balqa Applied University

The engineering foundation behind a systems-first approach: understand the whole, reason through constraints, and design practical solutions that can be maintained.

03 / SELECTED WORK

Systems I’ve helped
build and run.

Not demos. Working infrastructure shaped by deployment windows, incidents, storage limits, dependencies and recovery requirements.

01OBSERVABILITY

One view across the whole stack

Operated a centralized platform for infrastructure metrics, container telemetry, logs, traces, alerts and endpoint monitoring.

View architecture ↓
Grafana · Prometheus · Loki · Tempo · OpenTelemetry · Vector
02DELIVERY

A release path built for confidence

Maintained multi-stage delivery from source and image build through manual production approval, multi-server rollout and version validation.

View architecture ↓
Azure DevOps · Docker · GitLab CI/CD · Ansible
03PLATFORM

ERP infrastructure at multi-site scale

Managed independent Frappe benches and customer sites across development, testing, demo and production—not a single installation.

Frappe · ERPNext · MariaDB · Redis · Docker
04KUBERNETES

Stateful workloads, made portable

Built hands-on experience with readiness, ingress, shared databases and persistent storage for ERPNext workloads while continuing to deepen Kubernetes operations expertise.

View architecture ↓
Kubernetes · Helm · ingress-nginx · NFS · CronJobs
05RECOVERY

Backups designed to come back

Operated structured, date-based backups covering databases, public files, private files and site configuration with tested recovery procedures.

rclone · S3-compatible storage · MariaDB · NFS
06APPLICATIONS

Repeatable microservice delivery

Managed registry-driven deployments for public APIs, private APIs and frontend applications with environment-specific configuration.

Docker Compose · Nginx · Registries · Linux

DETAILED CASE STUDIES

Evidence over
tool lists.

Three interview-ready walkthroughs showing the problem, architecture, responsibility and operational constraints behind the work.

01 / DELIVERY ARCHITECTURE

A release path built for confidence

PROBLEM

Changes needed to move safely from source repositories into multiple production servers without losing branch, tag or approval controls.

MY RESPONSIBILITY

Pipeline design, image builds, branch and tag handling, deployment automation, troubleshooting and release validation.

CHALLENGES

Environment-specific configuration, controlled production promotion, multi-server rollout and clear verification after deployment.

ARCHITECTURE
Azure Repos→
Azure Pipelines→
Docker Build→
Registry→
Manual Approval→
GitLab Pipeline→
Ansible→
Production Servers→
Version Check

Azure DevOps · GitLab CI/CD · Docker · Ansible · Bash

02 / OBSERVABILITY ARCHITECTURE

Signals that connect incidents to causes

PROBLEM

Infrastructure, containers and applications produced separate signals, making cross-layer diagnosis slower and less reliable.

MY RESPONSIBILITY

Operate data collection, dashboards, log and trace pipelines, alerting components and the infrastructure behind the monitoring stack.

CHALLENGES

Consistent labels, useful retention, service discovery, noisy alerts and tracing failures across application and infrastructure boundaries.

ARCHITECTURE
Applications & Servers→
Vector / Exporters / OTel→
Prometheus / Loki / Tempo→
Grafana→
Alerts & Investigation

Grafana · Prometheus · Loki · Tempo · OpenTelemetry · Vector

03 / HANDS-ON KUBERNETES

Stateful ERP workloads, approached honestly

PROBLEM

ERPNext workloads combine web services, workers, databases, shared files, scheduled jobs and ingress requirements that must stay coordinated.

MY RESPONSIBILITY

Hands-on configuration and troubleshooting across Helm, ingress, readiness, shared services and persistent storage in testing environments.

CHALLENGES

Readiness dependencies, NFS-backed persistence, shared database access, scheduled jobs and safe recovery. This is an active depth-building area—not a claim of running hyperscale clusters.

ARCHITECTURE
Ingress→
Web / Socket.IO→
Workers→
Shared Database→
Persistent Volumes→
Backups / CronJobs

Kubernetes · Helm · ingress-nginx · StatefulSets · PV/PVC · NFS

04INCIDENT LESSON

WHEN “START THE SERVICE” ISN’T ENOUGH

Recovery needs context,
not just a restart.

A failed Frappe queue stopped appointment reminders. Restoring it would have released obsolete queued messages all at once.

I identified the second-order risk and improved the recovery procedure: inspect and remove stale jobs before bringing workers back. That is how I approach operations—restore service without creating the next incident.

DETECT→UNDERSTAND→CONTAIN→RECOVER→IMPROVE
05CAPABILITIES

A broad toolkit.
One systems view.

Tools are useful when they reduce risk, clarify ownership and make good operations repeatable.

01

Containers

Docker · Compose · Dockerfiles · Registries · Networking · Volumes

02

Kubernetes

K8s · Helm · Ingress · StatefulSets · PV/PVC · CronJobs · NFS

03

Delivery

Azure Pipelines · GitLab CI/CD · Ansible · Git · Azure Repos

04

Observability

Prometheus · Grafana · Loki · Tempo · OTel · Alertmanager

05

Data

MariaDB · PostgreSQL · MongoDB · Redis · S3-compatible storage

06

Edge & security

Nginx · Traefik · Cloudflare · Zero Trust · TLS · pfSense

07

Cloud

GCP · Oracle Cloud · Scaleway · CloudStack · VMware · Proxmox

08

Automation

Ansible · Bash · YAML · rclone · Cron · operational runbooks

HOW I WORK

01

Trace the whole path.

Application → container → network → proxy → database → storage → host.

02

Automate the repeatable.

Pipelines, scripts and playbooks replace fragile operational memory.

03

Design for recovery.

A backup only matters when the restore path is clear and tested.

04

Leave a runbook.

The next engineer should be able to act safely without guessing.