8 Common Misconceptions About Operations and How to Overcome Them

Error 1: Operations Is Only for Operations People

This misconception must be corrected first because it determines team positioning and future development. Limiting operations to the responsibilities of ops staff prevents growth and reduces perceived value, making the team appear low‑value. The correct view is that operations staff should continuously push operability standards and awareness into product and development processes, making operations a shared responsibility and part of feature implementation.

Error 2: Operations Is a Cost Center

There are two layers of understanding: the first layer sees ops as managers of IT service resources, responsible for controlling usage and avoiding waste; the second layer assumes ops cannot directly generate revenue, so the focus is on limiting cost, especially labor cost.

Controlling resource costs is indeed part of ops, but it is only one dimension of value. A highly operable system improves service quality, which many domestic teams rely on. A strong ops team can drive overall IT performance, leading to higher profit and market share, as shown in the 2014 DevOps Report.

The second layer’s issue was already addressed in Error 1: treating ops merely as maintenance. Modern practice promotes ops value and moves toward IT operations.

Error 3: Ops’ Only Duty Is Stability

Stability (availability) is not created solely by maintenance; it is a shared responsibility of all product roles. While ops processes increase availability, the root of availability lies in the collective effort of product teams.

Ops should not be seen merely as fire‑fighters. True operations become invisible when the system is designed for operability. I categorize application ops into three stages:

Stage 1: Ops can see business and align processes with business needs, ensuring high availability from a user perspective.

Stage 2: Ops no longer sees business directly; the architecture is highly service‑oriented, making all services alike, resembling IT operations.

Stage 3: The ops entity disappears; operability is embedded in the development system. Teams develop, deploy, monitor, and change their own services, while ops provides standards, platforms, and mechanisms.

High‑efficiency ops requires full visualization of processes, which leads to controllability and advanced automation, and this visualization should be propagated into the online business architecture as a key operability metric.

Error 4: Ops Should Stay Behind the Scenes

This view, common in “high‑efficiency ops” discussions, treats ops as supporters. I disagree; ops must adopt a user‑centric stance, establishing rules and execution power to drive internal development improvements, moving from backstage to the front line.

Error 5: DevOps Is Ops’ Lifeline

DevOps is not a lifeline for ops; it is a broader software development paradigm shift—from traditional engineering to agile and then DevOps—bringing many roles together.

In the waterfall era, development, testing, and maintenance were isolated. Agile fused development and testing. As internet‑scale business demands grew, maintenance alone could not keep up, so ops capabilities (high‑availability design, monitoring, automation) must be integrated early in the development lifecycle.

Error 6: DevOps Equals Automation

Automation is important but does not define DevOps. Automation is a technical requirement; DevOps is a cultural and organizational practice, not merely a technology problem. The goal should be user‑value‑driven automation across ops, development, and testing.

Error 7: APM Represents Ops Presence

APM (Application Performance Monitoring) is valuable but does not represent ops. APM mainly addresses code performance issues for developers. If an ops team seeks presence through APM, it indicates a lack of deeper impact.

ITIL’s service capability management aligns with performance management, and APM is one method to achieve it.

Error 8: Internet‑Scale Ops Is the Best Model

Internet‑scale ops works for some scenarios but not all. Companies like BAT have very different ops models, especially at the application layer. Ops practices are highly contextual; blindly copying internet‑scale models can be ineffective, particularly for traditional industries that need careful adaptation.

Other Common Misconceptions

Additional myths include believing that “business ops can skip ops system development,” that “ops system development is simple,” or that “ops cannot participate in architecture design.” In reality, ops must understand its scenarios, modes, and core requirements, and should be involved early in architecture to drive improvements. Ops is also crucial for startups, even if its value is not yet recognized.

Article originally published by the WeChat public account “Internet Operations Talk”.