DevOps engineer in Nepal
Pipelines, deploys and monitoring built so that shipping is boring — and so failures surface before anyone has to tell you about them.
Why I own this rather than delegate it
I'm Binit Koirala, co-founder at Fasto, where I'm responsible for the backend and the infrastructure it runs on. I didn't arrive at DevOps because I found pipelines exciting. I arrived because writing good backend code is pointless if you can't deploy it confidently or tell what it's doing in production.
In a small team there is nobody to hand this to, and that turns out to be a feature. When the person who wrote the service also owns its deploy and its alerts, the feedback loop is immediate — you feel every bad decision you made about observability.
What good looks like to me
Deploys should be unremarkable
If shipping requires a specific person, a checklist held in someone's head, or a quiet hour when traffic is low, the process is the risk. I automate deploys so they're routine and repeatable — which is also what makes a fast rollback possible when something does go wrong.
Failures should announce themselves
The goal is never zero incidents; it's hearing about them from your monitoring rather than from a customer. That means alerting on symptoms users actually feel — latency, error rates, failed jobs, queue depth — instead of a wall of metrics nobody reads.
Alerts have to stay trustworthy
An alert that fires constantly gets ignored, and once the team learns to ignore it you've lost the real one too. Keeping alerts few, meaningful and actionable matters more than covering every conceivable metric.
Environments should match
"Works on my machine" is a configuration problem. Containerising services with Docker removes a whole category of failure where staging and production quietly disagree — including for mobile release pipelines, where a build that can't be reproduced is a genuine problem.
For a product promising ten-minute delivery, infrastructure isn't a background concern. Every minute of downtime is an order that can't be fulfilled, so reliability is a product feature rather than an engineering nicety.
Stack
- Pipelines: CI/CD, automated tests on the path to production, staged deploys
- Runtime:
Docker, Linux server administration, process management - Data: PostgreSQL operations, migrations that run predictably, backups you have actually restored
- Observability: logging, metrics, uptime monitoring and alerting
A note on backups
The most common infrastructure mistake I see in small teams is a backup that has never been restored. An untested backup is a hope, not a plan — and you find out which one you had at the worst possible moment. Verifying restores is cheap insurance that almost nobody does until after their first bad day.