Will Operations Be Replaced? Exploring the Role, Skills, and Future of DevOps

Will Operations Be Replaced?

This article is aimed at readers who want to understand what operations (运维) actually does, whether they are considering a career in the field or are from non‑operations backgrounds.

Common Questions About Operations

What does operations actually do?

Is operations work interesting?

Does operations have a future?

Will operations be replaced by various technologies?

Although the author usually answers casual questions on Zhihu, this piece attempts to clearly describe the role of operations and leaves the assessment of its prospects to the reader.

What Does Operations Do?

The term "operations" can refer to three layers: the operations engineer, the operations team, and the entire operations service system. Most Zhihu users ask about the engineer level, while few realize the broader service‑system meaning.

Myths About Being Replaced

Cloud services will make operations engineers obsolete.

DevOps or SRE adoption will eliminate operations roles.

Container technology will render operations unnecessary.

Even if the engineer role evolves, the operations service itself will not disappear; it will continue to support the full lifecycle of business services.

Product Lifecycle Hand‑off

A typical product goes through: PM designs a prototype → Dev implements → QA tests → Ops deploys to production → users consume.

During the hand‑off from Dev to Ops, developers focus on functional correctness, while operations engineers ensure runtime quality, stability, and availability.

Whether the hand‑off uses DevOps, SRE, or other models, a broad‑scope operations service is still required. DevOps emphasizes automation and pull‑based delivery to improve efficiency and quality.

Evolving Skills for Modern Operations

Traditional operations must shift from purely OS‑level tasks to include code performance tuning, continuous delivery, containerization, and overall lifecycle management. This transition moves from a "black‑box" to a "white‑box" mindset, requiring deeper code and business insight.

Operations Engineer vs. Operations Development Engineer

Building automation or practicing DevOps inevitably involves operations developers. The author’s experience shows that an operations developer is first and foremost a programmer, not an operations engineer.

Operations developers need both "operations understanding" and "coding ability".

The technical bar for coding is lower than in domains like gaming or e‑commerce.

The bar for operations understanding is also relatively low.

Mastery of the operations tech stack (Linux, git, nginx, Zabbix, Docker, Kubernetes, etc.) is essential.

Many senior operations staff lack time to relearn programming, so when automation projects arise, dedicated developers are needed. Some younger engineers upgrade their coding skills, become operations developers, and earn praise for delivering useful automation.

Effective automation requires two complementary abilities: solid operations knowledge and strong development skills. These can be split between a senior operations engineer who documents detailed requirements and a developer who implements them.

Operations Service System & Skill Quantification

The author presents a personal view of an operations service system, acknowledging that details may vary across teams.

To assess personal growth, the author suggests quantifying skill levels, using MySQL as an example with levels 1‑10. Level 2 is defined as a “popular‑science” level sufficient for daily tasks, while higher levels (4‑5 and above) represent deeper expertise that drives career advancement.

Skill distribution often skews toward breadth over depth; focusing on elevating a few core skills to higher levels yields greater long‑term value.

Conclusion

The author’s personal reflections conclude that operations remains an interesting and promising career path, despite occasional challenges. Talented and motivated individuals are encouraged to join the field.