What Defines a True DevOps Engineer? Capability Models and Practical Insights

This article is compiled from a guest sharing session of the "Efficient Operations" series, originally published on the official public account.

Guest Introduction

Wang Xiaowei Founder of MaiTu Technology (since 2009), focusing on vertical search for e‑commerce. Over 10 years of experience in internet, gaming, and kernel security, having served as software engineer, senior engineer, technical manager, and director. Currently building a mobile game distribution platform and promoting DevOps adoption and automation.

Topic Overview

The talk is divided into two parts: (1) introducing a theoretical definition of an operations engineer’s capabilities; (2) presenting a DevOps capability model that builds on the first part.

From an Interview

Question 1

Q: How to add/remove a virtual host in Nginx using Python or Shell? A: Insert a server block into

nginx.conf

and handle the rest accordingly.

Question 2

Q: How to structure text logs with Python? A: Use

os.system

to call

awk

(a humorous remark).

These answers reveal two core deficiencies: lack of engineering ability and lack of architectural ability.

Engineering Ability

Problem decomposition.

Defining execution sequences.

Creating idempotent operations.

Architectural Ability

Knowing what should not be known.

Thinking what should not be thought.

Doing what should not be done.

1. Problem Decomposition

For Question 1, the breakdown includes understanding Nginx’s modularity, naming rules, required Python/Shell functions, validation, and deletion handling.

2. Defining Execution Sequence

High‑risk operations (e.g., editing

sudoers

) require a careful sequence: open a root terminal, edit in a separate window, and have a fallback method to restore if corrupted.

3. Idempotent Operations

Management actions modify system state, while status queries retrieve information. Ensuring idempotency means repeated execution yields the same result, allowing eventual consistency between state and information.

DevOps Capability Model

Operating System Capability Model

Fine‑grained role‑based access control.

Configurable privilege delegation.

Pluggable configuration (e.g.,

/etc/security/limits.d

,

/etc/sudoers.d

).

Package management for binaries and source.

Shell scripting support.

Application System Capability Model

Pluggable configuration (e.g., Nginx

sites‑available

).

System health detection (e.g., php‑fpm ping).

Hot‑reload capability.

High availability and disaster recovery (e.g., MySQL binlog recovery).

DevOps Capability Model

Understand OS capability model and use shell for DevOps tasks.

Understand application system capability model and use shell for DevOps tasks.

Possess engineering ability, master shell and general languages (Python/Ruby), and programmatically implement the three engineering abilities for automation.

Know business scenarios and key metrics to align DevOps work with business goals.

Assessing DevOps Qualification

Meet all requirements of the DevOps capability model.

Produce scripts that are idempotent (n and n+1 executions have identical effect).

Produce scripts reusable by other scripts.

DevOps Levels

Level 1: Junior DevOps – uses shell for basic system tasks, possibly aided by tools like Ansible/Fabric.

Level 2: Mid‑level DevOps – handles application deployment and optimization, managing applications at scale.

Level 3: Senior DevOps – combines shell and general languages to define complete business workflows and create reusable interfaces.

Level 4: Architect‑level DevOps – designs deployment architectures, optimizes for high availability, defines script interfaces and standards.

Current State of Dev and Ops

Dev focuses on using general languages (Python/Ruby) to integrate APIs and build large systems, while Ops prefers direct command‑line actions and one‑off scripts. After merging into DevOps, many rely too heavily on automation tools, neglecting fundamental skills.

DevOps principle: Thought precedes tools; over‑reliance on tools without solid fundamentals is detrimental.

Ops Evolution Examples

Case 1: Manual compilation of Nginx and its dependencies – a non‑DevOps approach.

Case 2: Directly editing

nginx.conf

to add a virtual host – another anti‑DevOps practice.

Case 3: Editing

/etc/sysctl.conf

indiscriminately – leads to unmanaged configurations.

Recommended DevOps approaches:

Use package managers (e.g.,

yum install nginx

) instead of source compilation.

Organize Nginx sites using

conf.d

,

sites‑available

, and symbolic links for enable/disable.

Place custom sysctl parameters in

/etc/sysctl.d

files for clarity and CI compatibility.

Dev Evolution

Windows development relies heavily on APIs, while Unix‑like systems favor file‑based configuration and shell scripts, aligning better with DevOps philosophy.

Advice for Developers Transitioning to DevOps

Start as an experienced Ops, mastering the command line and shell.

Understand OS philosophy: pipelines, files as configuration.

Grasp Ops core metrics: high availability, compatibility, idempotency, disaster recovery.

Layer scripts to be modular and reusable while maintaining Ops‑style practices.

Supplement 1: Relationship Between Programming Languages and Shell in DevOps

Python/Ruby orchestrate and launch shell commands via SSH or agents; the actual work remains in shell. Direct SSH is less efficient for many commands, while agents add complexity and reduce Ops transparency.

Recommendation: implement business logic in shell scripts, invoked via SSH or agents, to keep Ops involved.

Supplement 2: Significance of Programming Languages in DevOps

Python/Ruby provide design thinking; shell commands enact system changes. The core of DevOps remains shell and commands.

Supplement 3: Operating System Capability Model

Enhancing OS capabilities means wrapping existing tools (yum, sed, iptables, virsh) into higher‑level business functions, rather than re‑implementing them.