Site reliability engineering
Reliability isn’t the absence of incidents. It’s finding out quickly, limiting how much breaks, and recovering without heroics. I help teams build that into the platform instead of into a few people’s memory.
Sound familiar?
- You hear about outages from customers before your monitoring.
- Alerts fire so often that the important ones get lost.
- Releases are the main cause of incidents, and rolling back is a project in itself.
- Recovery depends on one or two people who know where everything is.
- No shared definition of “reliable enough”, so every conversation about risk starts from zero.
How I approach it
I’ve carried the pager: 24/7 on-call for mission-critical environments, and Tier-1 platforms at a fintech with 50M+ registered users. That shapes the work. The aim is fewer and better signals, releases that fail safely, and recovery that is written down and rehearsed.
In practice that means objectives for what users actually experience, observability wired to them, rollouts that are gradual and reversible, and incident lessons turned into platform changes rather than runbook footnotes.
What you get
- 01
Reliability assessment
Where the platform fails today, how you would find out, and how long recovery takes, riskiest gaps first.
- 02
SLOs and alerting
Objectives tied to user-facing behavior, with alerts that page on symptoms instead of noise.
- 03
Observability
Metrics, logs, and traces across services, on the stack you have or one that fits better.
- 04
Safe delivery
Canary and progressive rollouts, health checks, and rollback paths that are tested rather than assumed.
- 05
Incident and recovery practice
Incident analysis, disaster-recovery design, and runbooks your team can follow under pressure.
What I work with
Where I’ve done this
- Case study · Enterprise PlatformOperationalizing an enterprise Kubernetes platformIstio canary deployments, Dynatrace tracing and SLO monitoring, and Splunk logging, brought together as one production operating model.
- Case study · HealthcareRe-architecting mission-critical ETL for event-driven scaleDisaster recovery through backup Composer environments, DAG synchronization, and Terraform-driven environment reconstruction.
- Case study · EdTechSimplifying an over-built Kubernetes platform onto Cloud RunOne digest-based release path, where a failed release has been shown to leave production untouched.
From my experience
- Maya Operated and improved Tier-1 platforms across KYB, Identity, and Connect while maintaining SLOs.
- Kollab Maintained 99.9% uptime in a 24/7 on-call setup and helped reduce incident-resolution time by ~40%.
How an engagement runs
- Discovery call. We talk through your environment, what is hurting, and whether I am the right person to help.
- Assessment. I review the systems involved and write down what I find, with recommendations in priority order.
- Plan. We agree what changes first, what it should achieve, and how we will know it worked.
- Implementation. Hands-on work alongside your team, through code and review rather than console clicks.
- Handover. Documentation and walkthroughs so your engineers own the result, with ongoing support if you want it.
Questions
Do we need SLOs if we’re a small team?
A few, not a framework. One or two objectives for what users notice most will do more than a dashboard of everything.
Which observability tools do you work with?
Datadog, Dynatrace, Grafana and Loki, Splunk, and CloudWatch among others. The first goal is making the tools you have answer the right questions, before adding new ones.
Is this a one-off review or ongoing work?
Either. A reliability assessment stands on its own; implementation and ongoing support are available if you want them.