How DevOps works here, with one part-time engineer

Christian Drexler

For a long time I was the ops department. A couple of cloud servers, scheduled jobs, domains, DNS, a few APIs that other things depended on. None of it was hard on its own. Together it was a dozen moving parts, and moving parts break at 3 am. I would fix a dead job half asleep and forget by lunch what I had done. The next time it broke, the fix lived nowhere.

An ops team was never on the table; the company is small on purpose. What I needed was one careful person and a way of working that did not depend on us being awake at the same time.

The idea

That person is Ammar. He works part-time, from another time zone, and I could count our live calls on one hand. Everything else goes through a repository.

The repo is the only place where work changes hands. It has a to-do file, which is his inbox. When I need something, I write it there, with the context and what done looks like. He picks it up when his day starts, ticks it off, and leaves a note under it. Questions go in the same file, next to the task, so question and answer stay together.

Next to the to-do file sits an inventory: what runs where, what it is for, what depends on it. When something breaks, the first question is answered before anyone starts typing.

Secrets never travel through chat. They live in a password manager, the repo refers to them by name, and a script pulls them in at run time. Nobody has ever pasted a key into a message, so nobody has ever had to rotate one because of a message.

And every change is a commit. A new cron line, a DNS record, a service moved to another box: it lands in git with a short message that says why. Nothing lives in someone's head. If Ammar is on holiday, or I am, the state of everything is in the history, not in a person.

Six months in

Quiet. That is the honest description. I still get a message when something breaks, but from a probe, not a customer, and most mornings the to-do file has an item or two ticked that I wrote the evening before. What used to be a 3 am problem is now a line in a file, handled during somebody's working hours.

The surprising part was not the uptime. It was how much calmer I got once I stopped carrying the inventory in my head. You do not notice the weight until it is in a file.

What it costs

Attitude, mostly. The rule is short and strict: if it is not written down, it does not exist. A fix applied by hand on a server and not committed is one the next deploy will undo, and that is nobody's fault but the hand. A task mentioned in passing is not a task. The first month is uncomfortable, because writing things down is slower than doing them. After that it is the only way you can imagine working.

It also costs a little trust. Async means I do not watch him work. I read the commits and the notes, and that is the better view anyway.

If you recognise the 3 am part

You do not need an ops department. You need one careful person, a repo they treat as the single source of truth, a to-do file, an inventory, a password manager, and the habit of committing everything. It is not a clever setup, and that is why it keeps working.

It is also one of the things I help people set up. If you run a small company and your servers are still a 3 am problem, have a look at the development services or just write to me.