About Joseph Tracy

I'm Joseph Tracy, an infrastructure engineer in Seattle with over two decades in systems administration and engineering. Most of that time has been spent on the side of the work where something has already gone wrong, across Linux and Windows server estates, enterprise scale-out storage, virtualization, campus networks, and the monitoring layers that are supposed to catch all of it before anyone has to call.

I have held nearly every seat in the operations stack. Sole IT administrator running an entire organization's systems on call around the clock. Escalation point for a fleet of several hundred servers across global data centers. Campus infrastructure for a continuing care community, and data center operations before that.

The work was the same in each of them. Find out what is actually wrong with a system somebody else built, while people are waiting on the answer, and be able to show why the answer is right.

What I do now

I work as a backline Senior Enterprise Distributed Network Attached Storage (NAS/SAN) Technical Support Services Engineer, supporting enterprise customers and frontline Technical Support Services Engineers. Cases reach me after the earlier tiers have eliminated the obvious causes, which means the remaining explanations are the ones that need the system read closely.

Most of my work clusters in one part of the platform: the systems that connect a storage cluster to its support infrastructure and report on its own health. In practice that means break/fix on

• remote support connectivity, including migrations from legacy Secure Remote Services to Connectivity/SupportAssist services and the failures that block them
• telemetry transmission from the cluster back to support services
• cluster health check evaluation frameworks that stop producing accurate assessments
• the cluster-wide event log and its notification paths, covering SMTP, quota alerts, and event delivery
• the job engine, where failed jobs put file system data integrity at risk
• certificate and management-plane failures across all of the above

That is a narrower claim than "storage engineer," deliberately. The file system, the protocol stack, the network, and directory services each have their own experts, and on a serious escalation the useful person is the one whose lane the failure sits in.

It is also a lane that fails without announcing itself. When this layer breaks, the cluster keeps serving data and nobody opens a Severity 1. It surfaces later, as a health check that has not run in six weeks, an alert that was never delivered, or a support case the cluster could not open on its own.

The escalation side of the role runs alongside it. I lead live investigations during production-impacting incidents, coordinate cross-functional strategy on critical service requests, and handle the high-complexity, politically sensitive ones where technical accuracy and customer confidence both have to survive the call. I mentor colleagues on troubleshooting method and escalation management, work with engineering and field teams on intricate product issues, and have contributed feedback that fed into platform improvements.

How I work a problem

The method is evidence-based diagnostic troubleshooting, and I hold to it whether the case is a two-hour investigation or a multi-day escalation.

Evidence comes before conclusion, always. Log analysis, system output evaluation, and direct investigation of the running system, not inference from what the configuration is supposed to do. The documented system and the running system diverge over time in ways that are nobody's fault and everybody's problem.

Then deconstruct the failure. A multifaceted system failure is several problems presenting as one symptom, and isolating the boundary between them is most of the work.

I trained in this formally through Kepner-Tregoe structured problem solving: state the problem precisely, define what it is and what it is not, and let the distinctions narrow the field. A named method survives pressure, gets a room onto the same page, and can be audited afterward. An instinct does none of those things.

Before I act, I name the evidence that would disprove the working theory and go look for it. A conclusion nobody attempted to break is a guess with better posture, and the cost of finding that out later is paid by whoever inherits the system.

Then the resolution becomes an action plan, not a fix. A targeted plan states what will be changed, in what order, what it is expected to do, and how the outcome gets verified. Where the underlying cause allows it, the plan addresses recurrence and not only the symptom, because a case that closes and reopens in three weeks was never resolved. That is also where mean time to resolution actually moves: in the cases that stop coming back.

How I build

Scripting problems away is an old habit. I have written PowerShell that created seventy-plus Active Directory accounts from spreadsheet data with validation and duplicate checking built in so the errors were caught before they reached production, and pushed registry patches to 215 servers in a single run instead of touching them one at a time. In the current role, bash is a daily tool for cutting through logs at a volume where reading them by hand stopped being possible some time ago.

What changed over the last few years is not the language. A script that solves one problem once is a convenience. Work that is versioned, tested, documented, and built to fail safely, run twice without consequence, and record its decisions instead of only its actions is something a colleague can run at three in the morning without calling anyone.

That standard comes straight out of operations, where the cost of an unattended process doing the wrong thing quietly is measured in how long it takes anybody to notice. It is the standard I hold my own code to.

Writing serves the same purpose. An argument that survives being written out is usually sound, and one that collapses on the page was going to collapse in a design review with an audience. The projects and articles here are where the current work lives.

Depth now, and direction

The proven depth is enterprise storage and the operating systems underneath it: PowerScale, Isilon, and OneFS, Linux internals and troubleshooting, Windows Server and Active Directory, VMware and Hyper-V, campus networking, and monitoring through SolarWinds Orion and SCOM. That is what I can be handed with no ramp.

The active direction is Ansible, Terraform, CI/CD tooling, Kubernetes, and the AWS and Azure platforms. That work is real, and it is younger than the operations depth.

The honest version of the claim is that what transfers from two decades of support work is the threat model and not the toolchain: a specific, slightly paranoid sense of how unattended automation fails in production, acquired by being the person who answered when it did. The tools take months. The instinct took considerably longer, and it applies to whichever tool comes next.

Work history

• Senior PowerScale Technical Support Services Engineer

  Dell Technologies December 2018 to present

  Backline support for enterprise customers and frontline engineers on enterprise scale-out NAS. Escalation and collaboration point for high-complexity service requests, mentoring on troubleshooting and escalation management, and product feedback feeding platform improvements.

• System Analyst II, Operations Command Center

  TEKsystems, on site at Starbucks September to November 2018

  Data center operations across Linux, Windows, and IBM i. VMware vSphere administration, guest migrations, resource optimization, change management, and coordination on regional outages.

• Network Systems Administrator III

  Horizon House June 2016 to February 2018

  Campus infrastructure for a continuing care retirement community: 196 wireless access points, more than 55 virtualized Windows servers, SolarWinds Orion and SCOM monitoring, a SQL Server 2012 to 2014 migration, and the Active Directory account automation above.

• Senior Network Operations Center Systems Administrator

  Concord Technologies May 2015 to June 2016

  Escalation point for more than 750 physical and virtualized Windows and Linux servers across global data centers.

• Information Technology Administrator

  Seattle Children's Theatre December 2012 to May 2015

  The entire IT function: systems, network, database, and help desk, on call around the clock. Being the only person who can fix it is an unusually direct education in ownership.

• Technical Support Analyst and Junior Network Administrator

  McKesson April 2008 to April 2010

  Electronic medical records and Practice Partner support. Recognized as a Technical Performance Superstar.

• Earlier

  Tier 2 and tier 3 software support, from 2003

  Tier 2 and tier 3 support across software and systems.

Training

• Red Hat System Administration I and II (RH124 and RH134), instructor-led, across RHEL 8 and 9, with System Administration I again for RHEL 10 and the RH024 technical overview. These are course completions and not the RHCSA examination.
• Kepner-Tregoe structured problem solving, 45 hours.
• Kubernetes and container fundamentals through KubeAcademy.
• PowerScale Administration and Advanced Administration, 40 hours each, with troubleshooting methodology and OneFS knowledge transfer coursework.
• Generative AI coursework covering ethics, model concepts, and ecosystem, alongside internal evaluation and feedback work on AI tooling for support workflows.
• Network Design and Administration coursework, 117 credits, Seattle Central College.

Where the work gets tested

Everything published here is built and tested on my own time, on a personal virtualization host running Linux and storage virtual machines. It is a working bench for exercising scripts against realistic filesystems and services before publication, and for rehearsing failure modes on a schedule I choose.

It is a personal machine, not a production estate and not employer hardware, and I claim no infrastructure at scale outside of work. Nothing here derives from customer environments or internal systems. It is built against public documentation and my own lab.

I am open to contract and consulting work in infrastructure automation, diagnostics, storage operations, and modernization reviews, and to full-time roles where escalation-grade troubleshooting and automation ownership are the substance of the job and not a line in the description. If any of that overlaps with what you are building, the connect page reaches me directly.