Harrison Vance

San Francisco Bay Area / Remote.

• Resolve API and authentication blockers across Turnkey and Hyperliquid ecosystem integrations, unblocking production onboarding.
• Built real-time outage alerting and status visibility so production issues surface before a customer reports them.
• Built Ops-as-Code automations with n8n, webhooks, and internal workflow orchestration, scaling support without adding headcount.
• Authored programmatic triage paths for high-severity incidents, so diagnosis follows the same route regardless of who picks it up.
• Improved engineering handoffs by analyzing logs, isolating bugs, scripting validation checks, and documenting exact reproduction steps.

San Francisco Bay Area / Remote.

• Kept standard technical issues away from core engineering by owning Tier 2 workflows, diagnosing API failures, and building repeatable triage patterns.
• Authored a customer-facing knowledge base translating complex product behavior into clear support and implementation guidance.
• Shortened engineering investigation cycles using Chrome DevTools, Postman, cURL, network traces, and structured log analysis to deliver high-fidelity bug reports.
• Managed complex technical queues by isolating root causes through Datadog, Splunk, CLI debugging, and API testing before routing to senior infrastructure engineers.

Los Angeles, CA.

• Maintained stable daily operations and systems integrity across user-facing workflows, account administration, and operational issue resolution.
• Met strict regulatory and privacy requirements through structured operating procedures and disciplined handling of sensitive data.

A hands-on Technical Support Engineering course: 26 exercises across 9 tracks, each a symptom-only ticket against a genuinely broken system, with a grader that shows the evidence behind every assertion.

• The Symptom: infrastructure courses name the topic before the exercise, which is the one thing a real ticket never does. Practicing on a labelled problem teaches a fix rather than a method.
• The Resolution: every exercise opens with a customer describing what they see and nothing else. No topic, no layer, no hint. Deciding what to look at first is the graded skill, and the grader never just says pass or fail: it prints the assertion, the command it ran, and the raw output it evaluated.
• The Proof: CI asserts all 26 exercises both ways, that each fails in its broken state and passes against its documented solution, against real Docker and kind clusters on every push. An exercise that passes while broken is not broken, and one that fails when fixed is not solvable.
• Not screenshots: the terminal on every page replays output captured by really running those commands, and CI re-checks every byte against a freshly provisioned stack, so a page cannot quietly drift into describing a system that no longer behaves that way.
• Reviewed in the open: AUDIT.md is a 1,563-line end-to-end review recording 51 findings, and every gate in it was made to fail on purpose before it was trusted. It also records the places the review itself reached the wrong conclusion.

An L2 triage copilot that turns an incident evidence bundle into ranked hypotheses, recommended checks, and escalation-ready notes.

• The Symptom: escalations arrive as prose. Engineering needs structure, and producing it by hand is the slow part of triage.
• The Resolution: a FastAPI service that accepts an evidence bundle and returns structured triage, exposed over both REST and the Model Context Protocol from a single deploy, so an agent and a human hit identical logic.
• Observability: every Bedrock call is traced using OpenTelemetry GenAI semantic conventions to Langfuse, and both endpoints are rate limited per client IP.
• Impact: the same triage is callable from a browser, a script, or an n8n workflow without a second implementation to keep in sync.

A monitored Kubernetes workload that recovers from injected faults on its own, with recovery asserted on every push.

• The Symptom: most self-healing claims are untested. A README says a workload recovers; nothing proves it.
• The Resolution: every push creates a real kind cluster, installs kube-prometheus-stack, and injects three faults: a forced liveness failure, a container OOM against its memory limit, and a raw pod deletion.
• The Proof: the build fails if the workload does not come back. Assertions are scoped to one named pod so an unrelated restart cannot satisfy them, and the OOM case requires lastState.terminated.reason to be OOMKilled.
• Closing the loop: a Prometheus alert routes through Alertmanager to a remediation controller that performs a scoped kubectl restart and records deployment state before and after.

Four n8n workflows authored as version-controlled TypeScript and compiled to importable JSON.

• The Symptom: n8n workflows normally live as clicked-together JSON with no review history, so nobody can diff a change.
• The Resolution: workflows authored as TypeScript, compiled to JSON, with CI failing the build when the compiled artifact drifts from its source.
• Not simulated: three of the four call real systems, including live JSON-RPC into the Bedrock agent's MCP tool, newman against a real Postman collection, and container restarts over the Docker Engine API and a live kind cluster.
• Impact: an operations workflow becomes a reviewable artifact instead of tribal knowledge in someone's browser tab.

Four customer-facing API incidents, each reproduced against a local API and each diagnosis verified by assertions.

• The Symptom: 401 and 403 get conflated, 404 gets blamed on the wrong layer, and 429 gets reported as an outage.
• The Resolution: a deterministic lab reproducing a revoked key, insufficient scope, a wrong route, and rate limiting, each with failure and corrective evidence.
• The Proof: every assertion runs in GitHub Actions, so the diagnoses stay correct rather than decaying into stale screenshots.
• Each case ends where it should: the customer response, or the handoff a TSE owes engineering.

A multi-account AWS organization expressed as Terraform, with the guardrails written as code rather than clicked into a console.

• The Symptom: account structure and guardrails get set up by hand, so nobody can review them and nobody can rebuild them.
• The Resolution: an AWS Organization with three OUs and two member accounts, four OU-level service control policies, and an org-wide CloudTrail delivering into an isolated log archive account.
• The Checks: terraform fmt, validate at the root and per module, and tflint run on every push, with Checkov and Trivy advisory.
• The Limit, stated plainly: this is validated, not applied. It has never run against a live organization, and the README says so and lists the evidence worth capturing when it does.