leonardo.raponi · Sorocaba, Brazil · Open to remote
█$ traceroute --to root-cause
┌─────────────┐
│ CLIENT │
└──────┬──────┘
│ https / rest
┌──────▼──────┐
│ EDGE / DNS │◀── resolution, tls, routing
└──────┬──────┘
│
┌──────▼──────┐
│ APPLICATION │◀── logs, devtools, api calls
└──────┬──────┘
│
┌─────────┴─────────┐
│ │
┌────▼────┐ ┌─────▼─────┐
│DATABASE │ │INTEGRATION│
│ sql │ │ webhooks │
└────┬────┘ └─────┬─────┘
│ │
└─────────┬─────────┘
│
┌────────▼────────┐
│ INFRASTRUCTURE │◀── linux, containers, vpn
└────────┬────────┘
│
┌──────▼──────┐
│ ROOT CAUSE │
└─────────────┘
$ whoami
Five years in IT infrastructure and networking — Windows Server, Active Directory, DNS, DHCP, VPNs, firewalls, virtualization. Then five more in SaaS platform support, growing from first line to L2 engineering to strategic-account cases.
That combination is the point. When a problem crosses from the application into the network, the database or the infrastructure, I don't hand it off — I follow it.
$ cat /etc/capabilities
From the network packet to the HTTP response. Five years on-premise infrastructure, five on a SaaS platform — I can follow a failure across the whole path instead of stopping at the layer boundary.
SQL against the data, aggregated logs for the timeline, browser DevTools for what the client actually sent, authenticated API calls to reproduce it. I stay on a problem until I reach the root cause, not the symptom.
Closing a ticket is half the job. When a class of failures keeps generating the same painful cases, I specify the system that detects it early, get it built, and run it — turning a reactive cycle into a proactive one.
Root-cause write-ups, documentation, handoffs to Product and Engineering, audit trails. The work of support is only finished when the next person can act on it without asking.
$ ls -la ~/work
Both were specified and shipped at work, built with AI assistance, and are described by function only — how they work and how I understood the problem, with no company data. I'm a support engineer, not a developer: the work here was seeing the pattern, defining what had to exist, and keeping it running.
[01] built at work
Internal system · designed and shipped
Detects transactions stuck in failure states, classifies them with deterministic rules, and opens pre-filled tickets before the customer reports the problem.
scheduled scan ──▶ find stuck records
│
▼
classify (deterministic rules)
│
┌───────────┼───────────┐
▼ ▼ ▼
eligible ambiguous ignored
│ │
▼ ▼
pre-filled human triage
CRM ticket
│
▼
team acts BEFORE the customer reports[02] built at work
Internal tool · designed and shipped
Reads operational metrics from an API and publishes a daily digest to the team's channel, with failure alerting and defensive safeguards.
schedule ──▶ preflight checks
│ (env, auth, upstream reachable)
▼
fetch metrics (API)
│
┌──────────┴──────────┐
▼ ▼
digest ──▶ team channel failure ──▶ out-of-band alert
(never dies silently)$ history | grep career
SaaS platform · L1 → L2 → key accounts
Technical point of contact for strategic accounts, responsible for critical cases end to end: reproducing the failure, isolating which layer it came from, coordinating the fix across teams, and writing the account back a version of events they can act on. Specified and shipped the internal tooling above to remove recurring failures rather than re-solve them.
Handled the technical cases escalated past first line, including the ones that touched platform operations. SQL against the data to see what actually happened, aggregated logs to build the timeline, DevTools for what the browser really sent, authenticated API calls to reproduce it outside the product. Escalations to engineering with the evidence attached, workarounds while the fix shipped, and failure patterns documented so the next person recognised them.
First-line support within agreed SLAs: triage, reproduction, and resolution of everything that came in, escalating what genuinely needed it. Learned the platform and its business rules in depth — the domain foundation my investigations still rest on.
IT services provider · several client environments in parallel
Ran multiple client environments at the same time: Windows Server with Active Directory, DNS, DHCP and file services; site-to-site and client VPNs, firewall rules and network connectivity; Microsoft 365 administration, endpoint protection and backup routines. The work was as much about context-switching between environments without dropping an open incident as it was about any single technology.
IT services provider · where the foundation was built
Remote and on-site support across a wide portfolio of clients. Windows and Linux workstations, Windows servers, network equipment, Microsoft 365, endpoint security, digital certificates, and backup and recovery routines — including embedded Linux devices used in retail. Three years of meeting every layer of a stack in person, which is where the habit of following a problem past my own boundary came from.
$ cat /proc/stack
A — professional experience. B — hands-on practice on my own hardware.
Associate Degree in Computer Networks
Anhanguera
In progress · expected 2027