Mastering the ‘Dao, Fa, Shu, Qi’ of IT Operations: From Philosophy to Tools

Introduction

We discuss the “Dao, Fa, Shu, Qi” of technical operations, sharing years of experience and inviting discussion.

Dao – The Philosophy

Dao refers to the focus on business continuity in technical operations. It emphasizes that when a system crashes, continuity planning is essential, otherwise all prior work is wasted.

Fa – The Methodology

Technical Operations Perspective

Fa covers quality, cost, efficiency, and security. Quality includes SRE, high availability, monitoring, and logging. Cost includes FinOps and dynamic scaling. Efficiency includes automation tools and DevOps. Security includes audit, DevSecOps, and application/network security.

Application Perspective

From the application side, Fa involves end‑to‑end construction covering requirements, release, deployment, and daily management/security.

Ops Object Perspective

Fa is explained from eight angles of an ops object: model, resource, relationship, action, metric, event, status, and process.

Shu – The Techniques

DevOps Technical Operations Standard

Reference the “DevOps Capability Maturity Model” by China Academy of Information and Communications Technology as a practical standard.

SRE Reliability Engineering

SRE practices include project requirement analysis, system analysis, high‑availability risk analysis, capacity modeling, observability, stress testing, throttling, and the creation of operation manuals covering background, architecture, emergency plans, FAQs, and fault handling.

FinOps

FinOps helps engineering, finance, and business teams collaborate on spending decisions, managing capacity and cost to maximize business value.

GitOps

GitOps stores code and configuration in Git and uses CI/CD pipelines for operations, e.g., managing hosts with Terraform.

Continuous Operations

From standardization to tooling, automation, data‑driven, and intelligent operations, emphasizing the difference between mere tooling and true automation, and the role of data governance and AIOps.

Qi – The Tools and Platforms

Building an ops platform requires more than products; it needs solid design logic.

Underlying Design Logic of Ops Tools

Command‑oriented / workflow driven.

Declarative / target‑state oriented (e.g., Kubernetes, Ansible).

Data‑driven (AIOps, operational big data).

Event‑driven (fault self‑healing workflows).

Management Logic of Ops Platforms

Resource management (CMDB, cloud, container platforms).

On‑boarding (agent/SSH/protocol).

Execution (install, backup, user creation).

Monitoring (metrics, logs).

CMDB and Resource Management

CMDB is layered (asset, resource, application) and its value lies in data consumption for monitoring, automation, and inspection. Without consumption scenarios, CMDB investments fail.

Conclusion

When selecting or building ops tools, consider both application and resource dimensions; applications consume resources, and resources serve applications.