You might think that IT operations is becoming irrelevant these days, as orchestration and DevOps tools now supposedly do the job for you.

I’m sorry to break it to you, but that’s just a myth. Throw it in the pile with other busted myths, such as the ability to see the Great Wall of China from space, bulls’ hatred of red (they’re actually colorblind), and vitamin C’s effectiveness in curing colds.

But according to this growing meme, software developers are the superheroes of today’s digital enterprises, and everything should be about enabling them to work faster. IT Ops? They’re around to keep the lights on and to get out of the developers’ way as code moves into production.

DevOps isn’t the magical union between developers and operations. Really, it’s just a way for developers to cut operations out of the picture.

IT operations management remains core

The reality is that IT operations teams are more essential than ever for managing complex systems. Production environments, especially those that adopt orchestration and DevOps tools, need good operations teams to guard against even a few seconds of downtime that can cost the business millions of dollars in lost revenues

Organizations faced with this apparent contradiction—developers pushing ops away, despite the fact that operations is more important than ever—should rally around a set of core principles that redefine the role of operations management and keep Ops more relevant than ever.

Think of these principles as your 10 Commandments that will help your operations organization survive—and thrive—in what sometimes looks to them like a DevOps desert.

1. Thou shalt serve no other masters than system availability

A system never going down has been, is, and always shall be the primary measure by which IT operations management is judged. There’s availability, and then there’s everything else. Every organization must make this gospel, or pay the price in lost revenue and angry customers.

2. Thou shalt make no idols in complexity

The simplicity and unification of systems is always better than more stuff. The DevOps world is littered with far too many moving parts, including tools such as Chef, Puppet, Jenkins, Kubernetes, Mesos, PaaS, Docker container managers, and so on, and the list grows bigger all the time. Be wary of anything that has yet to be tested at enterprise scale (which includes most of them).

3. Operations’ expertise shalt not be taken in vain

It’s the operations manager’s responsibility to run and maintain platforms for enabling rapid development of code (IaaS, PaaS, SaaS, container platforms, virtualization, and so on), but it’s also in operations’ discretion to decide if and when those platforms are suitable to be used in production. They, not developers, are the experts here.

4. Thou shalt look at changing requirements as holy

Digital technology is transforming businesses and forcing them to move faster. It is up to IT Ops to embrace and enable that change with agility and flexibility, not hold it back by resisting change.

5. Honor thy developers’ role in this new environment

Enable developers to optimize the process of delivering working code into production, whether it be from continuous integration systems, PaaS environments, or simple FTP drop sites. There’s a whole lot of good in increased developer agility, but that doesn’t negate operations’ vital role.

6. Thou shalt not murder apps that have bad security

Operations teams almost always have stronger expertise in security than do developers. As a matter of corporate policy, operations management should be the last line of defense when it comes to app security.

7. Thou shalt not stray from core Ops functions

Visibility, monitoring, reporting and dashboarding remain fundamental parts of the operations team’s jobs. Organizations should invest in the latest tools to automate these operational procedures.

8. Thou shalt not steal from reliability

While automating operational procedures wherever possible, never do so at the expense of reliability, and only with tools suited to the complexities of operational environments.

9. Thou shalt not bear false witness against thy colleagues

Business people, developers, and operations must work together daily throughout projects. This core philosophy of collaboration is one of the best things about DevOps. Silos are untenable in today’s fast-paced environment.

10. Thou shalt not covet thy neighbor’s tools

Popular or trendy developer tools are fine to use during development, but that doesn’t mean they are suitable for operations to use in production. Don’t fall for the cult of the new. While new-generation automated configuration tools are excellent starting points for treating infrastructure as code, the notion that they can be trusted to replace operations’ role is a pipe dream.

By adhering to these 10 rules, companies can support two-way agility and allow both developers and operations to work collaboratively and smartly toward the mutual goal of continuous development.

Jez Humble and David Farley codified the discipline in their book Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. At the heart of their framework are eight guiding principles. Understanding these principles helps engineering teams design pipelines that are both practical and durable.

The 8 Principles of Continuous Delivery

1. Repeatable, Reliable Process

Use exactly the same release process across every environment — development, integration, QA, staging, and production. When a feature travels a different path into each environment, environment-specific surprises accumulate and undermine confidence in releases. Consistency eliminates the drift that makes deployments unpredictable.

Practical implication: Infrastructure-as-code tools (Terraform, Ansible, Helm) and containerisation (Docker, Kubernetes) make it straightforward to enforce identical environment configurations.

2. Automate Everything

Automate builds, tests, deployments, configuration changes, database migrations, and monitoring checks. Manual steps are inherently slower, less repeatable, and more error-prone than automated ones. Once a process is automated, the marginal cost of running it again approaches zero and the output is consistent.

What this covers in practice:

• Compilation and artifact creation
• Unit, integration, and end-to-end tests
• Security and compliance scans
• Environment provisioning
• Deployment and rollback procedures
• Post-deployment smoke tests

3. Version Control Everything

Source code is the obvious candidate, but the principle extends to configuration files, infrastructure definitions, database schema scripts, deployment scripts, and documentation. A single, authoritative source of truth gives every team member a stable foundation and makes it possible to reproduce any past state of the system reliably.

Commonly overlooked artifacts to version control:

• Application configuration and feature flags
• Database migration scripts
• CI/CD pipeline definitions
• Container image build files (Dockerfiles)
• Runbooks and operational documentation

4. Bring the Pain Forward

Tackle the hard, error-prone, or time-consuming tasks as early as possible in the pipeline. If integration is painful, integrate more often and earlier. If database migrations are fragile, run and validate them in the first post-commit pipeline stage rather than discovering failures late in QA.

Discovering problems early is cheaper — both in calendar time and in engineer effort — than surfacing them close to a production release. Early pain also generates the feedback that drives process improvement.

5. Build In Quality

Quality is not a phase at the end of the pipeline — it is a property built into every stage. Short feedback loops are essential: when a test fails immediately after a commit, the developer who introduced the defect can fix it while the context is still fresh. The longer a bug survives in the codebase, the more expensive it becomes to diagnose and remediate.

Techniques that operationalise this principle include:

• Automated unit and integration tests executed on every commit
• Static analysis and linting as pipeline gates
• Code review enforced before merge
• Automated acceptance tests in a production-like environment
• Shift-left security scanning (SAST, dependency audits)

6. "Done" Means Released

A feature is not done when it passes code review, not when it ships to staging, and not when QA signs off. It is done only when it is running in production and delivering value to users. Adopting this definition of done creates shared accountability across development, operations, and product management and eliminates the ambiguity that causes work to stall between handoffs.

This principle also encourages the use of feature flags and canary releases, which allow code to reach production safely even before a feature is fully exposed to all users.

7. Everyone Is Responsible

"It works on my machine" is not an acceptable outcome. Responsibility for a change extends all the way to production. This requires a cultural shift: developers care about operability, operations teams understand the deployment pipeline, and both collaborate on incident response. Management support and visible leadership buy-in are usually prerequisites for this cultural change to take hold.

Practical enablers include shared on-call rotations, blameless post-mortems, and cross-functional team structures that eliminate hard handoff boundaries between dev and ops.

8. Continuous Improvement

A continuous delivery pipeline is never finished. Teams should measure pipeline performance (lead time, deployment frequency, change failure rate, mean time to restore), identify bottlenecks, and iteratively remove them. Automation is the principal mechanism for this: every manual step that gets automated represents a compounding gain that pays dividends on every subsequent release.

A culture of continuous improvement is the prerequisite. Without the organisational will to inspect and adapt, even a well-designed pipeline will stagnate. Retrospectives, regular pipeline audits, and metrics dashboards all help sustain the improvement mindset.

How the Principles Work Together

These eight principles are mutually reinforcing. Automating everything (Principle 2) is only feasible if everything is under version control (Principle 3). A repeatable process (Principle 1) depends on quality being built in (Principle 5). Shared responsibility (Principle 7) is what makes a "done means released" culture (Principle 6) sustainable over time.

Teams that treat the principles as a checklist rather than an integrated philosophy tend to automate individual steps without achieving the systemic reliability that continuous delivery promises. The goal is a coherent end-to-end pipeline where every stage upholds all eight principles simultaneously.

Further Reading

The authoritative source for these principles is Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble and David Farley (Addison-Wesley, 2010). The DORA State of DevOps research programme publishes annual data on the delivery metrics — deployment frequency, lead time for changes, change failure rate, and mean time to restore — that correspond directly to these principles.

What Is DevOps?

“DevOps” describes a professional movement and cultural philosophy that advocates a collaborative working relationship between software Development and IT Operations. The goal is to achieve a high rate of planned deployments while simultaneously improving the reliability, stability, resilience, and security of production systems.

DevOps is closely related to—but distinct from—Agile. Agile development focuses on delivering working software in smaller, more frequent increments rather than large, infrequent “big bang” releases. DevOps extends this idea by completing the continuous integration and delivery pipeline: it ensures that code is not only built and tested continuously, but is also reliably promoted to production and delivers value to the end user.

DevOps is sometimes mischaracterized as a rejection of ITIL (IT Infrastructure Library) or ITSM (IT Service Management). In practice, ITIL and ITSM remain useful codifications of the business processes that underpin IT Operations. Disciplines such as service design, incident management, and problem management are entirely compatible with—and often necessary for—a mature DevOps workflow. The goal of DevOps is not simply to increase deployment velocity; it is to deploy features quickly without causing chaos, and to detect and correct incidents rapidly when they do occur.

The Three Basic DevOps Principles (The Three Ways)

The “Three Ways” framework, drawn from DevOps literature, provides a concise model for understanding how high-performing engineering organizations operate.

The First Way: Systems Thinking

The First Way emphasizes optimizing the performance of the entire system, not individual silos. A local improvement that creates a bottleneck elsewhere—or that optimizes one team’s throughput at the expense of another’s—is not a real improvement. This principle applies across the full value stream: from business requirements, through Development, through IT Operations, and out to the customer.

The Second Way: Amplify Feedback Loops

The Second Way is about creating fast, right-to-left feedback loops. Shortening the cycle between an action and its observable consequences allows teams to detect problems early, understand their root causes, and correct them before they compound. This is the foundation of practices such as automated testing, continuous integration, production monitoring, and blameless post-mortems.

The Third Way: Culture of Continual Experimentation and Learning

The Third Way focuses on cultivating a culture that values two complementary things: continual experimentation (which requires accepting risk and learning from both success and failure) and the understanding that repetition and deliberate practice are prerequisites to mastery. This is why practices such as game days, chaos engineering, and internal learning programs are central to mature DevOps organizations.

5 Underrated DevOps Tools Worth Using Every Day

The DevOps ecosystem tends to spotlight newer, cloud-native platforms—Kubernetes, Terraform, Argo CD—while overlooking a set of older, battle-tested utilities that quietly do essential work. Constant improvement is a DevOps value, but improvement does not always mean replacement. The five tools below are lightweight, require minimal configuration, and provide genuine insight into or control over your infrastructure.

1. RANCID (Really Awesome New Cisco confIg Differ)

RANCID is a suite of utilities that automates the collection and revision-control of network device configurations. It connects to routers, switches, and other network equipment, retrieves their running configurations, and commits any changes to a version control repository. This gives operators a full audit trail of configuration changes and makes rollback straightforward. For teams that have not yet migrated to full network-as-code tooling, RANCID is a pragmatic starting point for configuration management.

2. Cacti

Cacti is a round-robin database (RRD)-based statistics graphing tool primarily aimed at network equipment. It polls devices via SNMP (Simple Network Management Protocol) to collect metrics such as interface utilization, CPU load, and memory usage, then renders those metrics as time-series graphs. While modern observability stacks offer richer capabilities, Cacti remains a reliable, low-overhead option for baseline network visibility—particularly in environments where heavier platforms are impractical.

3. lldpd (Link Layer Discovery Protocol Daemon)

LLDP (Link Layer Discovery Protocol) is one of the most underutilized networking protocols in general-purpose Linux environments. Running lldpd on a server causes it to advertise itself to—and receive advertisements from—directly connected network neighbors. The practical result: you can instantly determine which physical switch port a server is connected to, which peer devices are adjacent, and what their capabilities are. This information is invaluable when troubleshooting physical connectivity, validating cabling, or documenting topology.

4. iPerf

iPerf is a network performance measurement tool designed to measure achievable bandwidth between two endpoints. It operates as a client/server pair: one host runs iPerf in server mode and listens for connections; the other runs in client mode and sends traffic. The result is an accurate measurement of throughput, latency, and packet loss across the path between the two hosts. iPerf is essential for validating network capacity after infrastructure changes, diagnosing bottlenecks, and establishing performance baselines before deploying latency-sensitive applications.

5. MUSSH (Multi-host SSH Wrapper)

MUSSH is a shell script wrapper around SSH that allows a single command to be executed across multiple hosts—either sequentially or in parallel. Before configuration management tools like Ansible, Chef, or Puppet became ubiquitous, MUSSH was a common way to push ad-hoc changes or run diagnostic commands fleet-wide. Even today it remains useful for quick, targeted operations where invoking a full orchestration tool would be overkill. Its simplicity is its strength: no agent installation, no inventory database, just SSH.

Why These Tools Still Matter

What RANCID, Cacti, lldpd, iPerf, and MUSSH share is a focus on access and visibility. Each tool gives engineers a clearer, more direct view of what is happening in their infrastructure—which machines are reachable, how the network is performing, what changed in a device’s configuration, and where a cable is physically plugged in. That kind of low-level situational awareness is a prerequisite for fast incident response and reliable operations, regardless of which higher-level platforms sit above it.

In a mature DevOps organization, newer tooling and older utilities coexist. The right question is not “is this tool modern?” but “does this tool solve the problem reliably?” For the use cases above, the answer is still yes.