Production Engineer (IC4)

Overview Ontrac Solutions is seeking a high-aptitude Production Engineer (IC2) to support a large-scale enterprise OS modernization and infrastructure hardening program for one of our enterprise clients. This role is built for an engineer with real software engineering foundations — specifically Python — who has since moved into infrastructure and is comfortable working across OS modernizations (RHEL7 → EL8/EL9), packaging migrations (Chef → CINC), and CI/CD hardening, while simultaneously executing hands-on runbooks, automation, and service onboarding. This is a genuine hybrid role: roughly half build — Python tooling, RPM packaging, pipeline and rollback work — and half operate — runbooks, service onboarding, and Tier-2 break/fix. You will work directly with the client's SRE organization, internal engineering teams, and customer stakeholders from initial definition through final delivery. Candidates who are pure application developers with no Linux fleet exposure, and candidates who are pure operations with no real software engineering behind them, will not clear screening. What your application must clearly show We screen against the requirements below exactly as written — your resume should make these easy to find. Specifics matter more than vocabulary: a resume that restates this posting's terminology without the detail below will not advance. Python you actually wrote, described as software, not as a skills keyword. Name the project, what it did, who depended on it, and how it was tested and shipped. "Python (scripting)" in a skills list will not clear this bar. A GitHub, GitLab, or public repo link is strongly preferred — we look at code. RPM packaging you personally did. Name the .spec files you authored or maintained, how you handled dependencies and versioning, your build tooling (rpmbuild, mock, Koji, or an internal builder), roughly how many packages you owned, and where they were published. A real OS migration you worked on — with version numbers and what actually broke. System Python 2→3, OpenSSL and crypto-policy changes, systemd unit differences, deprecated or renamed packages. We are more interested in the failure modes you hit than in the name of the program. Configuration management you have run in production — Chef (cookbooks, recipes, Ohai, Test Kitchen/InSpec), CINC, Puppet, Ansible, or Salt. Say which resources you wrote and how you tested convergence. Monitoring and logging work you executed. Name the stack, what you onboarded to it, and what you actually instrumented — metrics, dashboards, alert rules, log pipelines — not just the product name. Tier-2 or on-call experience: the rotation you carried, the scale of the fleet behind it, and one incident you personally drove to resolution. CI/CD pipelines you built or hardened , including how rollout and rollback were handled when a change went wrong. Your certifications, named, with dates and credential IDs or verification links — we verify certifications. …