DevOps Engineer

Nexla, briefly

Nexla is the data layer for enterprise AI. We give AI apps and agents the connectivity, context, and governance to work across more than 1,000 enterprise systems in real time, and we process over a trillion records a month doing it. DoorDash, LinkedIn, Johnson & Johnson, Instacart, and LiveRamp run mission-critical data on us. Honorable Mention in the Gartner Magic Quadrant™ for Data Integration Tools, and top-rated by customers on Gartner Peer Insights four years running. Founded 2016, remote-first, headquartered in San Mateo.

Our values are short and we actually use them: Have Empathy. Be Curious. Be Intellectually Honest. Achieve Excellence. Remember to Relax.

**Role, briefly
**Our data plane moves hundreds of billions of rows a day across hundreds of thousands of Kafka topics, with Spark, Flink, Ray, and Redis running on EKS and GKE. You would own its reliability as an engineering problem rather than an operations one: the SLOs that define what working means, the instrumentation that proves it, and the software you write to remove the manual work in between. This is not a cloud-provisioning or CI/CD role. It is Senior level, so your influence is expected to reach past the systems you personally touch.

What you’ll own

• What reliable means, in numbers. Availability, freshness, and latency SLOs that platform and runtime teams actually agree to, error budgets that govern release pace, and the data-aware instrumentation behind them: consumer lag, throughput, partition skew, job latency, error rates. Not host and CPU metrics.
• The stateful data plane itself. Kafka via Strimzi at hundreds of thousands of topics, Spark, Flink, and Ray workloads, Redis clusters, and the EKS and GKE clusters underneath. Broker health, checkpointing, backpressure, failover, upgrades, capacity.
• Toil, treated as an engineering problem. Measure the manual work the team does to keep things running, then write software to remove it. Terraform-provisioned infrastructure, runbooks, and automation, including for air-gapped and private enterprise installs.
• Incidents and what comes after. Lead root-cause analysis on distributed-systems failures, run blameless postmortems, and drive the durable fix. Mitigate fast, then design out the recurrence.

_Senior scope: you set the reliability bar other engineers design against. Changing how teams outside SRE build is part of the job, not a side effect of it.

_**The hard problem
**The failures we hate are the silent ones: a sink that stopped writing and told nobody, a consumer group quietly drifting behind, a checkpoint that stalled. At hundreds of thousands of topics, host and CPU metrics tell you nothing about whether data is actually moving. Making the data plane’s behaviour legible before it breaks is the standing problem on this team.