Hands-on experience in production environments — diagnosing LAN outages, securing compromised infrastructure, maintaining Windows/Linux servers, and deploying containerized services. Five years at ProGranite Surfaces and UW Continuum College, then a homelab that formalized everything: dual Proxmox hosts, 30+ Docker containers, TrueNAS ZFS storage, multi-vendor OSPF routing, and AI-agent operations. Today: actively pursuing CCNA 200-301 and RHCSA/RHCE, with a deliberate, methodical path into network and system administration.
Not the standard help-desk-to-sysadmin story. Three things to know about how I got here — and why I built this portfolio the way I did.
IT support at UW Continuum College gave me Tier 1 & 2 discipline. Then ProGranite Surfaces put me in front of production infrastructure — a flat LAN that failed catastrophically, shared hosting that got compromised, Windows and Linux servers that needed maintenance, and a network that I redesigned from scratch with VLAN segmentation. The title was "IT Support Specialist." The work was already system administration.
→ where I came fromProject Hermes is the formalization of everything: dual Proxmox VE hypervisors, TrueNAS Scale with 43TB ZFS RAIDZ1, 30+ Docker containers behind Traefik with Authentik SSO and CrowdSec WAF, 35 VLANs segmented across a Ubiquiti stack. Built to deliberately deepen infrastructure skills — and to document how I actually think and troubleshoot. Two documented incident RCAs with full investigation paths.
→ the engineering workCCNA 200-301 targeting end of 2026. RHCSA/RHCE on the same timeline. The credentials aren't the destination — they're the structured path I chose to formalize what hands-on production work made me good at. Targeting Network & System Administration roles where I can grow with a team, handle real production incidents, and keep building infrastructure that stays up.
→ get in touchThese are two incidents I investigated and resolved in a production environment at ProGranite Surfaces, written in real incident-report format: environment, symptoms, hypotheses ruled out, investigation path, root cause, validation, lessons. Skim the summaries. Read the investigations when you want depth.
// methodologyCalm. Methodical. Bottom-up the OSI model — every time.
// the philosophy that came out of a catastrophic production outage
A stone fabrication facility's entire LAN collapsed during production hours. Every workstation lost connectivity, CNC machines went offline, and phone lines dropped simultaneously. The initial assumption was an upstream ISP or firewall failure — multiple services failing at once usually points to the edge. The actual failure was inside the switching fabric: a switching loop had formed when an unmanaged switch was connected to two wall jacks fed by the same switch stack, creating a Layer 2 broadcast storm that saturated every link on the network. Resolution required physically locating the loop source, breaking the broadcast storm by disabling ports until the loop resolved, then redesigning the flat network with proper VLAN segmentation to prevent recurrence. The redesign was eventually implemented on a UniFi/UDM Pro stack with isolated VLANs for data, voice, production equipment, and guest access.
RC-1 (immediate): An unmanaged desktop switch was connected to two wall jacks both terminating at the HP ProCurve stack, creating a physical Layer 2 switching loop. Broadcast frames circulated indefinitely, producing a broadcast storm that saturated all switch uplinks and prevented legitimate traffic from being forwarded.
RC-2 (contributing): The flat /24 network design with no VLAN segmentation meant there was no broadcast domain isolation. A loop originating in the office could take down CNC machines on the other side of the facility. STP was either not enabled or not covering the unmanaged switch segment, which had no STP capability.
A WordPress site hosted on shared Hostinger/CageFS infrastructure was compromised. The site displayed a defacement page redirecting visitors to a spam domain, and the hosting provider sent a malware detection alert. Initial response — replacing core files and resetting credentials — appeared to resolve the issue. But the compromise persisted through the cleanup. A second infection vector was discovered: PHP backdoor files embedded in the uploads directory using obfuscated base64_decode and eval() payloads, designed to survive a standard file replacement. Complete remediation required a systematic defense-in-depth approach: forensic file analysis, backdoor file removal, credential rotation, WAF deployment, file integrity monitoring setup, and a hardened WordPress configuration.
public_htmlspam-domain[.]com. The defacement was the visible symptom, but the vector was unknown.grep search across public_html for common backdoor signatures: base64_decode, eval() with encoded strings, preg_replace with /e modifier, system(), exec(), shell_exec(). Found two files in wp-content/uploads/2023/ containing obfuscated PHP — hidden among legitimate uploaded images.base64_decode(str_rot13(gzinflate(...))) executed via eval(). The decoded payload checked for specific GET/POST parameters as a trigger — without the trigger key, the file appeared benign. This meant automated scanners could easily miss it.RC-1 (initial compromise): Vulnerable third-party WordPress plugin with an unrestricted file upload CVE allowed attackers to upload PHP backdoor files disguised as legitimate media uploads into wp-content/uploads/.
RC-2 (persistence): The backdoor files used layered obfuscation (base64_decode + str_rot13 + gzinflate + eval) to evade signature-based detection. They were hidden among thousands of legitimate uploaded files and activated only when specific HTTP parameters were present, making them invisible to casual inspection and standard automated scanners.
wp-content/uploads/2023/The lab work didn't appear out of nowhere. It's the formalization of years of production IT support, infrastructure troubleshooting, and operational discipline I developed across two roles.
Production IT in a stone fabrication facility — maintaining the LAN, servers, CNC equipment connectivity, and end-user infrastructure for a ~30-person shop. This is where the incident reports in this portfolio come from.
Tier 1 & 2 technical support in a higher-education environment, supporting faculty, staff, and classroom technology across the UW Continuum College campus.
Infrastructure visibility via Proxmox, Docker health checks, Uptime Kuma monitoring, and automated cron-based diagnostics. Practiced on hardware I own — ready for production environments where uptime matters.
Proxmox cluster health, Docker container status, storage utilization, network latency — on a dark dashboard tuned for at-a-glance reading.
Dual Proxmox VE 8.x nodes — proxmox1 (Ryzen 5 5600G, 80GB RAM) and proxmox2 (Ryzen 5600GT, 64GB RAM). ZFS root, 10 GbE backbone.
TrueNAS Scale (2 instances). Primary pool: 3× Seagate Exos X18 16TB in RAIDZ1 = 32TB usable. Secondary: 1TB zvol for backup staging. NFS shares to both Proxmox hosts.
Python, bash, and systemd, running 24/7 in containers and cron jobs I built and maintain. Automated health checks, security auditing, monitoring, and backup orchestration — all real, all operating in the homelab.
Custom AI agent running cron-driven health checks across the homelab: automated VM diagnostics, security audit orchestration, container health verification, and incident report drafting. Interfaces with the Proxmox API and Docker socket for real-time infrastructure awareness.
Automated weekly security audit covering: WordPress file integrity check against known-good hashes, full recursive malware scan of web roots (base64_decode/eval/gzinflate signature matching), SSH configuration audit (PermitRootLogin, password auth, key-only enforcement), and log review summary. Results logged and alerted via Telegram.
Uptime Kuma monitoring 21 endpoints across the homelab — Proxmox hosts, TrueNAS web UI, Docker containers, Traefik dashboard, Authentik SSO, CrowdSec API, and external services. Push notification alerts via Telegram webhook on status changes. Custom notification templates with severity-based formatting.
Five-minute cron job checking NFS mount health across Proxmox hosts — automatically remounts if dropped, logs failures. ZFS snapshot pipeline: automated daily snapshots on TrueNAS datasets with 14-day retention. Proxmox backup job targeting VM backups to ZFS storage with verified restore capability.
Targeting Network & System Administration roles in the Seattle area. Open to remote where appropriate. CCNA 200-301 and RHCSA/RHCE in deliberate pursuit — targeting end of 2026. A live homelab with dual Proxmox hosts, 30+ containers, and 43TB ZFS storage that I can demo on a call. Two full incident reports from real production environments ready to walk through in detail. And the operator instinct that comes from fourteen years of being the tech-curious person in every room.
