Rethinking Ops: Application‑Centric Management and Modern CMDB Strategies

Introduction

Operations need a breakthrough in thinking, moving from Ops to DevOps, from project to product, and from resources to applications. It questions why most CMDB projects fail, why automation discussions focus on Ops rather than IT, and why online incidents are often blamed on Ops.

1. Application‑Centric Ops Management New Thinking

Proposes building ops capability around applications, dividing IT capability into three parts:

1. CMDB as IT Resource Management System

Defines the resources an application consumes—servers, memory, storage, load balancers—often presented as backend services (IaaS/PaaS).

2. Actions

Application changes include delivery, upgrade (Dev/Test/Ops) and pure Ops scenarios such as migration and scaling. Actions affect resources, e.g., version changes or resource additions.

3. State

Collecting various state data to measure application health, supporting monitoring, fault recovery, and service optimization.

2. New Thinking on CMDB Construction

2.1 Reasons CMDB Projects Fail

Failures stem more from methodology than technology; projects often rely on internal assumptions without involving the owners of the underlying resources.

2.2 Layered CMDB Construction

Separate business‑level and resource‑level CMDBs, but prioritize an application‑level CMDB and derive the resource‑level CMDB from it. Distinguish instance information from topology (connection) information, which should be built from architecture diagrams and service documentation.

2.3 Supporting Application Actions

When application‑level data is complete, CMDB can support actions, delivering full automation for both application and ops workflows.

3. Building End‑to‑End Automation for Users

Connect Dev/Test/Staging/Prod environments into a delivery pipeline divided into four standardized processes: stage, environment, action, and role.

Stage

Logical division of delivery phases (development, testing, pre‑release, production) ensuring a single pipeline for consistency.

Environment

Further subdivision within each stage (e.g., UAT, SIT, production clusters, backup clusters).

Action

Automation is realized through a sequence of capabilities; actions split into deployment actions (environment setup, package installation) and supplemental actions (e.g., automated tests for user acceptance).

Role

Roles (dev, test, ops, etc.) determine who executes actions; role definitions evolve with management models, enabling IT‑level automation rather than pure ops automation.

4. New Thinking on Alert Construction

State is a metric; monitoring provides alerts. To avoid alert fatigue, visualize alerts in layered panels, giving higher weight to application‑level alerts and lower weight to infrastructure alerts, turning alerts into decision‑making data rather than direct problems.

Conclusion

Application‑centric ops management offers concrete solutions to long‑standing problems and justifies building an organization centered on “application ops + ops R&D”. Applications are closest to business and thus the strongest driver.