leonardo.raponi · Sorocaba, Brazil · Open to remote
█
$ analyze --incident --trace-flow
┌─────────────┐
│ CLIENT │
└──────┬──────┘
│ https / rest
┌──────▼──────┐
│ EDGE / DNS │◀── resolution, tls, routing
└──────┬──────┘
│
┌──────▼──────┐
│ APPLICATION │◀── logs, devtools, api calls
└──────┬──────┘
│
┌─────────┴─────────┐
│ │
┌────▼────┐ ┌─────▼─────┐
│DATABASE │ │INTEGRATION│
│ sql │ │ webhooks │
└────┬────┘ └─────┬─────┘
│ │
└─────────┬─────────┘
│
┌────────▼────────┐
│ INFRASTRUCTURE │◀── linux, containers, vpn
└────────┬────────┘
│
┌──────▼──────┐
│ ROOT CAUSE │
└─────────────┘
$ whoami --detailed
Across nearly ten years in technology — progressing from on-premise infrastructure support to L1 support, L2 support engineering, and strategic account support in SaaS —, I developed a rigorous diagnostic process. When an anomaly occurs in production, mitigating impact is the immediate priority, but the job is only finished once the underlying systemic cause is understood.
My investigative routine pairs SQL queries to inspect raw database states, DevTools and Postman to audit headers and payloads, and log aggregation (Elastic/Kibana) to reconstruct exact incident timelines. I isolate faults through authenticated calls outside the user interface, delivering clean, reproducible test cases to Engineering so permanent fixes can be shipped safely and without back-and-forth.
When a failure class repeats, I don't settle for closing tickets: I specify internal tooling and automations using Python and CRM APIs to detect issues proactively, turning reactive firefighting into continuous operational improvement for the whole team.
$ cat /etc/methodology
I cross-reference application logs, API calls, and database records to map real system behavior. I never assume a service succeeded merely because it returned HTTP 200: I verify persisted data and the integrity of each stage in the workflow.
I isolate issues by extracting actual HTTP requests and reproducing errors in Postman or curl using controlled payloads. Eliminating browser and caching variables gives Engineering a documented, actionable test scenario.
Applying a quick workaround protects the customer during a critical moment, but it doesn't fix the underlying problem. I stay focused on root causes: documenting error patterns and specifying tooling to prevent recurrence.
Thorough investigation must be understandable to the engineer fixing the code and the team managing customer expectations. I author structured post-mortems and internal runbooks that empower teams to act on clear facts.
$ ls -la ~/tooling
When the same class of incident recurs, reactive support becomes a bottleneck. Instead of repeatedly resolving identical tickets, I map the pattern, specify the solution, and build internal tools or automations that proactively catch and handle issues.
[01] built at work
Internal system · designed and shipped
Detects transactions stuck in failure states, classifies them with deterministic rules, and opens a pre-filled ticket before the customer notices.
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 milestones
SaaS platform · L1 → L2 → key accounts
Today I am the technical point of contact for strategic accounts, which means taking critical cases end to end: reproducing the failure, finding which layer it came from, coordinating the fix across the teams involved, and giving the account an honest version of events they can decide on. It was in this period that I specified and shipped the internal tooling above, because part of what made those cases critical was the same thing happening again.
I took the cases first line could not resolve, including the ones that touched platform operations. This is where the method became habit: SQL 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. I escalated to engineering with the evidence already attached, delivered workarounds while the fix shipped, and documented the pattern so the next person recognised it without repeating the investigation.
I started over at first line on purpose, in a domain I did not know. Triage, reproduction and resolution within SLA, escalating what genuinely needed it. The real gain of that period was not technical: it was learning the platform's business rules in depth. Investigation without domain is guesswork with logs attached.
IT services provider · several client environments in parallel
Several 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 connectivity; Microsoft 365, endpoint protection and backup routines. From the outside it looks like a list of technology. In practice, the skill that period built was switching context between environments all day without dropping an open incident.
IT services provider · where the foundation was built
My first three years, remote and on site, across a wide portfolio of clients: Windows and Linux workstations, Windows servers, network equipment, Microsoft 365, endpoint security, digital certificates, backup and recovery routines, and even embedded Linux devices used in retail. It is where I met every layer of the stack in person, with the machine in front of me. It is where the habit of following a problem past my own boundary came from — when you are in the client's room, there is no boundary.
$ cat /proc/capabilities
A — solidly used in production environments. B — continuously practiced in personal homelab and hardware.
Associate Degree in Computer Networks
Uninove
In progress · expected 2027