SRE {Cloud & DevOps}
engineer_engineer_

Cloud migrations, Kubernetes setups, CI/CD pipelines, observability rollouts and reliability audits. Anything from a one-week infra audit to a multi-month migration.

Yes — I work with teams worldwide, async-first, with overlap hours agreed up front.

We start with a short call, I scope the work into a fixed plan with milestones, and every project ends with documentation, runbooks and a handover session for your team.

Yes. The SRE Retainer covers ongoing reliability work, incident support and monthly reviews — or 30 days of support is included with every project.

An SRE keeps production systems fast, available and cost-efficient by treating operations as an engineering problem: defining SLOs, automating away manual toil, building monitoring and alerting that catches issues before users do, and running structured incident response and postmortems when things break.

Both. For early-stage teams the work is usually foundations — CI/CD, infrastructure as code, monitoring and a sane on-call setup done right the first time. For larger teams it is usually reliability at scale: SLOs, incident process, Kubernetes and cloud cost work.

Yes — in a specific order: first remove idle resources (typically 15–25% of the bill, zero risk), then rightsize from real utilisation data, then schedule non-production environments, and only then lock in savings plans. Reliability is checked at every step; savings that create outages are not savings.

Yes. I work remotely with teams across time zones, keep an overlap window for meetings and pairing, and put everything else in writing — decision docs, runbooks and recorded walkthroughs — so the work never blocks on my calendar.

The explicit goal is the opposite of dependency. Every engagement ends with documentation, runbooks and a handover session so your team owns and operates everything I built. You should not need me for day-two operations — only for the next project.

Day to day: AWS, Kubernetes, Terraform, Docker, GitHub Actions and other CI systems, Prometheus and Grafana for observability, and Python or Go for tooling. The principles — SLOs, automation, capacity planning — transfer to whatever stack you already run.