Site Reliability / Production Engineer

The problem.

The system already runs unattended most of the time. Whether that is safe depends on whether an abnormal state is visible before it becomes an expensive one. Today that visibility is uneven. Making it even, and keeping it even as the system grows, is the job.

What you would do.

• Define what healthy means for each component, in terms that can be measured rather than felt.
• Build alerting a person can trust at three in the morning. That mostly means deleting alerts.
• Own the incident process: how one is declared, who does what, and what is written afterwards.
• Run the post-mortems and make them about the system rather than the person.
• Drive the reliability work that comes out of them to completion, including the unglamorous half.

What we would want evidence of.

• You have carried a pager for something that mattered and can describe what you changed because of it.
• You have deleted more alerts than you added, and can explain why that improved things.
• You have written a post-mortem that changed a design rather than assigned a cause.
• You can tell a symptom worth waking someone for from one worth a morning ticket.
• You are comfortable being the person who blocks a deploy.

What would make this a bad fit.

This role is a poor fit if reliability engineering means managing a queue of tickets. This is closer to engineering than to operations.

This role is a poor fit if you need an established on-call rotation with enough people in it. The rotation is small. You would help build the case for making it larger.