From Traditional Ops to DevOps: The One Step You’re Missing

Hello everyone, I’m the host “SanFeng” and today I’ll share “From Application Operations to DevOps, You’re Just One Step Away”. Please stay quiet; we’ll have a Q&A after the presentation.

Personal background: I am a teacher at MaGe Education, nicknamed “SanFeng” to remind myself to study, summarize, and improve wildly. I have seven years of frontline Linux experience, having worked at I‑Tu Web, Baidu, and Alibaba in development‑operations roles, and now focus on mobile‑Internet technology and operations platform development.

I research automated operations, Linux system architecture, MySQL management, clustering, caching, mobile‑Internet tech, e‑commerce architecture, and I can independently operate systems while writing code.

The six sections I’ll cover represent the gradual shift of an operations engineer toward an ops‑developer role, ultimately practicing DevOps. DevOps is often seen as a buzzword, but I view it more as a culture rather than just a “development + operations” hybrid.

Every concept has a background. For example, enterprises progress from selling labor (four‑star) to selling products (three‑star), brands (two‑star), and finally standards (one‑star). DevOps provides a standard that companies adapt internally, similar to an interface‑implementation relationship in Java.

Traditional ops can feel like a “step‑mother” to development, handling massive online services without clear standards. Without standardization, automation, and metrics, small companies may chase concepts prematurely, while larger firms face real challenges that require ops to own their processes.

Typical ops work consumes 70‑90% of time on repetitive, boring tasks, leaving little room for learning, personal life, or a sense of achievement. The ROI is low, prompting the need for a breakthrough.

To manage scale, ops must adopt standards, automation, and a “four‑like, two‑learn” mindset:

Like a PD: guide developers.

Like operations: data‑driven ops.

Like a PM: coordinate the whole system.

Like a merchant: “sell” technical capability.

Learn lazy‑automation, standardization, and simple, beautiful designs.

Core ops abilities include business mapping (treating hardware as a skeleton, network as veins, applications as organs), fault handling (understand business logic, improve alert interpretation, ensure complete logs), automation and service‑productization (build platforms that enforce standards), and stability/performance optimization (dependency analysis, disaster recovery, throttling, decoupling, monitoring‑analysis‑optimisation loop).

With the rise of DevOps and AI‑ops, traditional ops must evolve; otherwise, they become obsolete. The ideal future is a two‑way skill set where “ops can code and developers understand ops”.

Developers typically focus on solutions, code, bug fixing, and optimization. When they build ops platforms without ops experience, the tools often miss real needs, forcing ops back to manual scripts.

Learning a programming language (Python, Java, Go, etc.) is essential for ops engineers to build their own tools; the basics are enough to start contributing.

DevOps acts like an interface that each company implements differently. It bridges the gap between development and operations, turning manual support into platform‑enabled self‑service.

The ultimate DevOps goal is to boost overall capability, break professional boundaries, accelerate technical iteration, and increase personal value. To achieve this, focus on two dimensions:

Personal: keep passion, stay curious, continuously learn new technologies.

Company: productize and service‑ify ops skills, spread the ops culture, and foster self‑service awareness among developers.