System Administrator · Linux · Infrastructure · Networking
I like knowing why a system works — and why it stopped working.
Linux · Bash · Docker / Compose · Proxmox · Networking · NetBird / VPN · Kubernetes / k3s · GitHub Actions · NFS / SMB · Prometheus / Grafana
I work best when I can understand the whole path: host → network → service → user. I use documentation, search and AI where they make me faster, but I don't treat generated output as understanding. If I can't reason about a change yet, it belongs in a lab first.
|
Kubernetes break/fix training against real cluster state. Disposable infrastructure, repeatable failure scenarios and live validation. Kubernetes · Terraform · Ansible · Troubleshooting |
A disposable Proxmox lab built around repeatability, teardown boundaries and recovery rather than one-off manual setup. Proxmox · OpenTofu · Ansible · Cloud-Init |
|
Documentation pipeline that keeps public engineering docs separate from private operational source-of-truth while still validating and delivering them automatically. Docs-as-code · CI · GitHub Actions · Delivery |
The portfolio itself: bilingual static site, explicit technical evidence and a GitOps promotion path to the live CV. HTML/CSS · GitHub Actions · GitOps · Argo CD |
- Understand before automating. I want to know what the system is doing before I hide it behind tooling.
- Use the right tool, not every tool. Manual work is fine when automation would add more complexity than value.
- Know the boundary. I am comfortable saying when I need documentation, a sandbox, or a second look.
- Keep recovery boring. Backups, known-good state, rollback paths and useful documentation matter more than cleverness.
CKA validation · Proxmox/IaC validation · Docs CI · Docs delivery
More detail without the usual CV skill inflation: self-assessed skills →


