Much of the conversation around DevOps is about helping developers get faster, easier access to production systems and shortening release cycles. That focus on developers leads naturally to a concentration on so-called “Day One” tasks—the Dev side of the equation—often to the exclusion of “Day Two” operations: the Ops side of things.
The reason for this imbalance lies in DevOps’ origin story. The narrative centers on developer frustration with risk-averse operations procedures that prevented rapid, frequent deployments. There is truth in that account, but it is more complicated than the myth suggests. Operations professionals are risk-averse for good reason: when things go wrong in production, Ops bears highly visible, public blame with little safety net.
That said, a reasonable aversion to risk can be taken too far. Combine it with a professional identity built around individual servers and manual procedures, and you get people becoming bottlenecks for huge processes—reaching for the keyboard for tasks that should long since have been automated away.
What Does DevOps Actually Mean for Ops?
The most significant benefit DevOps has delivered to operations teams is forcing a hard conversation about moving from artisanal, handcrafted IT infrastructure to industrial, scalable models that do not require a human in the loop for routine tasks. This cultural shift was crystallised in the well-known pets versus cattle analogy—treating servers as interchangeable units rather than irreplaceable individuals—but the transition is far from complete.
There is still a meaningful gap between the rhetoric of software-defined infrastructure and desired-state automation and practical, day-to-day operational uptake of those frameworks. Filling that gap requires a genuine transition away from traditional Ops models, with pervasive, intelligent automation augmenting—rather than replacing—the capabilities of experienced sysadmins.
This is not the automation of cron jobs and shell scripts, which experienced sysadmins have used for decades. Modern serverless and cloud-native frameworks remove the persistent coupling of infrastructure components to individual business services. Workloads now move, grow, and shrink in response to user demand, and infrastructure reconfigures itself top to bottom automatically. The promise of dynamic resource management that earlier virtualisation technologies hinted at is now becoming operational reality.
Why “Set It and Forget It” Automation No Longer Works
In a dynamic, cloud-native environment, operational automation can no longer operate on a static “set it and forget it” model. Every automated process needs real-time contextual awareness of its surroundings and how they are constantly changing. Without that visibility, you get situations like:
- Backup scripts faithfully backing up a server that has become a peripheral part of the application infrastructure, while the cloud services running the bulk of application logic are not meaningfully integrated into the disaster recovery plan.
- OS patching pipelines running against ephemeral instances whose average lifespan is shorter than the patch cycle—work that could be eliminated entirely by patching the base image templates instead.
- Automation that continues to run simply because no one is sure what might break if it stops—a signal that it is time for deliberate chaos engineering to find out.
To keep operational automation aligned with business reality, every automated process should be reviewed regularly across three dimensions: need, function, and ownership.
Three Questions Every Ops Team Should Ask About Their Automation
1. Who Needs This Automation?
Every piece of automation that runs should be traceable—however indirectly—to a business requirement. Useful questions to ask include:
- Does this serve a clear operational goal? “This ensures our infrastructure scales seamlessly in response to user demand” is a solid justification.
- Is the goal still valid given current architecture? “This keeps operating systems patched” is a legitimate aim, but if provisioned OS instances are replaced faster than the patch cycle, patching the base image template may be all that is needed.
- Is inertia the only reason this still runs? “We’ve always done it this way and aren’t sure what would happen if we stopped” is a prompt to run a controlled experiment—deliberately disable the process in a non-production environment and observe.
2. What Is the Function of This Automation?
The technology landscape continues to shift rapidly. Virtualisation was barely settled when cloud computing arrived; cloud computing was still maturing when containerisation accelerated; containerisation is still evolving alongside serverless architectures. Automation written for one era can carry hidden assumptions that make it fragile or redundant in the next.
Ops teams should borrow a practice from software development: refactoring. Review automation regularly to remove outdated assumptions, eliminate technical debt, and take advantage of newer capabilities. The function of a script or workflow that made sense in a bare-metal or early-virtualisation context may need to be redesigned completely for a container-native or serverless environment.
3. Who Owns This Automation?
Every piece of automation needs a named owner—someone responsible for maintaining it over time and accountable when it breaks. Developers have long discussed the concept of technical debt: the compounding cost of unmaintained code. Operational automation accumulates the same kind of debt when no one maintains it.
Historically, sysadmins took pride in the uptime of individual servers. That sense of ownership needs to migrate: from the individual server to the overall infrastructure, and to the automation and management tooling that ensures its availability and performance over time. The cattle-not-pets principle applies to the infrastructure; the ownership and craftsmanship principle applies to the automation that manages it.
Ops Is the Other DevOps
As Ops becomes increasingly about building and managing automation rather than administering individual systems, the boundary between Dev and Ops begins to dissolve. Development teams are taking on production responsibility—”picking up the pager”—while operations teams are writing progressively more sophisticated code to fulfil the infrastructure promises that applications depend on.
Traditional Ops tasks are evolving or disappearing, and new roles are emerging in their place. The role of automation architect—someone who designs, maintains, and governs the systems that keep infrastructure running—is becoming more strategically important than any role that primarily involves logging into individual servers or network devices. Operations professionals navigating this transition have a great deal to learn from the software engineering practices that developers have refined over the past decade: version control for infrastructure code, code review, testing, refactoring, and clear ownership models.
In the long run, the term “DevOps” may come to describe not developers versus non-developers, but two distinct types of software engineer: one focused on business logic and user-facing features, and one focused on the architectural foundations and automation that make reliable delivery possible at scale. Getting there requires Ops to be taken as seriously as Dev in the tools, practices, and culture that organisations build around continuous delivery.
This article is adapted from a piece originally published on DevOps.com. The original author was affiliated with Moogsoft, which at the time of writing had a strategic partnership with Microsoft.