DevOps Engineer

There was a time when the people who built software and the people who kept it running belonged to separate organizations. One side was measured on shipping new features quickly. The other was measured on not disturbing the servers. Those two measures collided head-on. Every additional release raises the chance of something breaking, so the operations side had every reason to bundle deployments into one event a month.

Releases became a Friday night ritual. A month of changes went out at once, someone watched the dashboards until dawn, and when something misbehaved, just working out which of the changes caused it burned hours. The procedure lived in one person's head, too — connect to the server, upload the files, run a handful of commands in the right order. If that person took a week off, nothing shipped that month. And when something broke, the argument ended where it always ended: "it worked on my machine" against "the server was fine until yesterday."

DevOps is the turn away from that wall. Rather than deploying carefully and rarely, deploy in small pieces often and make it cheap to undo when it goes wrong. That only holds if everything previously done by hand runs on its own. The DevOps engineer builds and maintains the path that does it.

The day goes into the road a change travels after it's merged, and into watching what happens on that road.

1. Fixing the deployment path. CI/CD is the system that automatically checks merged code and, if nothing is wrong, carries it all the way to the server. When checks that used to take five minutes grow to twenty, engineers start putting off merging, so hunting down the slow step and shrinking it is steady work rather than a one-time setup.
2. Managing infrastructure in writing rather than by hand. Infrastructure as code (IaC) means describing in a file how many servers to run and with what settings, then having the environment built from that file. Nobody can explain why a hand-configured server is set up the way it is; a written description can be read, reviewed, and reverted.
3. Making what's happening visible. Observability is the practice of planting logs and metrics ahead of time so the state of a running system can be read from outside. The hard part is where to set the alerts. Alert on every small slowdown and 40 notifications pile up in a day, at which point the one real outage alert gets ignored along with the rest.
4. Getting things back when they stop. A rollback returns the system to the previous version. Restore users first, find the cause second — never the other way around. When they hold the on-call rotation, the alerts reach them at night too.
5. Making engineers self-sufficient. If spinning up a fresh environment means filing a request with this one person every time, that person becomes the bottleneck. Reducing it to a single command and writing down how to use it is about half the job.

The role touches nearly every discipline, but the closest daily contact is with the people writing the server side.

Backend developers are in constant contact. Together they decide how to stand up the storage or the external connection a new feature needs, and how far to open up autoscaling, the mechanism that adds servers automatically when load spikes. With frontend developers the conversation is mostly about deploy speed and about preview environments where a change can be seen before it reaches users.

With security engineers the friction is usually about permissions. The more freely engineers can release on their own, the faster the work moves and the wider the surface for accidents. Instead of picking one of the two, the usual settlement is to log who did what and require one extra confirmation for the small set of genuinely dangerous actions.

At smaller companies this seat carries several jobs at once. Pagedeck, at forty-five people, has nobody dedicated to reliability and nobody dedicated to security; one DevOps engineer and the backend developers split that work between them. The moment the seats separate is usually the moment one person can no longer hold two kinds of work at the same time — taking outage alerts while writing new features means the alerts always win and the features keep slipping.

"The deploy pipeline takes 20 minutes now, so everyone's putting off merging."

The automated checks have gotten slow enough to drag on development speed, and that needs fixing.

"Roll it back first, then look at the cause."

Cut off what users are experiencing now; the investigation can wait ten minutes.

"Don't file that with DevOps, just run the command yourself."

There's already an automated path for it, so no person needs to be in the loop.

Pagedeck used to release every other Thursday evening. Two weeks of changes went out together, so when something went sideways, isolating which change caused it took over an hour, and during that hour saving a document failed intermittently.

The first thing the DevOps engineer did after joining was shrink the size of a release. Checks and deployment were automated so changes could go out several times a day, and the undo procedure was reduced to one button. Something Theo fixes in the afternoon reaches users half an hour later. When it does go wrong, there is only the one change from those 30 minutes to examine, and finding the cause dropped from an hour to a few minutes.

The most common misreading is "the person who manages the servers." They do handle infrastructure, so it looks right. But the output of this seat isn't a well-managed server; it's a state where engineers can ship on their own. Once the role hardens into taking requests and doing the work on someone's behalf, every release waits on a person, and engineers respond by saving changes up and shipping them in one batch. That's the every-other-Thursday evening the whole thing was meant to eliminate, back again.

Knowing DevOps only as a job title is the other one. Recruiting posts use it that way, so the reading is a fair one. The word originally described a way of working that joins the building side to the running side. Hire one person for the title and leave everyone else working as before, and the wall has only moved. If the team still doesn't know how its own code behaves on a server, the person who understands an outage and the person who can fix it are still two different people.