Mastering Operations Automation: 8 Proven Practices for DevOps Success

1. Automation Needs Overall Planning

Without a holistic plan, automation feels like building isolated tools without a progressive strategy.

Identify boundaries through layered systems to construct a DevOps automation tool stack rather than relying on a single tool.

Do not assume that configuration tools like Puppet, Salt, or Ansible can solve all automation problems.

Automation should be driven by operational scenarios, balancing cost and benefit— don’t automate for automation’s sake.

Abstract each component as a service: infrastructure (IaaS), configuration, processes (ITIL), architecture (PaaS), data, monitoring, etc.

Continuous integration platforms are a special mainline for application delivery, covering automated build, test, and deployment across teams.

Monitoring should be data‑driven: first data, then monitoring.

Map services to layers, keeping lower‑level resources simple and avoiding internal dependencies such as DNS or LVS.

Prohibit internal system calls via ops paths to simplify inter‑service dependencies, aiming for deployment as simple as installing a package.

Identify operational scenarios; different business forms require different automation focus.

2. Standardization Is the Foundation

Automation platforms must be experience‑delivery platforms, not just technology platforms.

Clarify three questions for any automation platform:

What problems does it solve?

What benefits can be achieved?

Who are the users?

Standardization reflects the precision and courage of one’s operational understanding.

Standardization makes people and systems more efficient: speed is doing things quickly, effectiveness is doing them correctly.

In practice, standardization drives configuration simplification and service‑oriented APIs, enabling stateless, highly available services.

Configuration standardization simplifies management.

Service‑oriented components expose APIs for easier management.

Stateless services with dual‑center redesign improve availability.

3. Start with Continuous Delivery

Begin with continuous integration or CMDB as the mainline; continuous delivery benefits multiple teams.

Continuous deployment can be built jointly by development, testing, and operations, reducing resistance.

Continuous delivery also pushes internal standardization such as environment and application standardization.

Continuous integration alone is not the whole automation story; higher‑level business workflow automation and lower‑level OS automation are also needed.

Our current continuous deployment solutions include a Cloud Foundry‑based UAE platform and a non‑intrusive ops solution that packages deployment capabilities as standard events.

4. DevOps’s Four Views

Cultural view: break down departmental walls and foster deep collaboration. Value view: continuous improvement, shared responsibility, waste elimination, user focus. Thinking view: lean, value‑driven, cross‑domain, agile. Tool view: automation platform suite + data platform suite.

DevOps is about aligning the two ends of user‑service capability for optimal integration.

5. Leverage Testing and Research

Automation requires support from development and testing; small code changes on the dev side can simplify complex operational systems.

Examples include configuration management via a unified

define.conf

that abstracts environment differences, and a name‑service center that maps service names to instances, reducing manual DNS handling.

6. No Strong Dependency on CMDB

CMDB is not a prerequisite for automation; it is used in specific scenarios such as resource request automation or metadata back‑fill.

Automation may query CMDB for resource information during certain workflows.

Automation may write back changes to CMDB to keep metadata synchronized.

For small‑scale businesses with infrequent changes, CMDB can be simplified to record resource ownership and usage.

7. Aim for NoOps

Automation targets “no‑ops” for each operational responsibility—server delivery, application delivery, component delivery—by exposing capabilities via APIs and visualized self‑service interfaces.

8. Docker and Similar Technologies Do Not Eliminate Ops

The impact on operations comes from productized capabilities built on these technologies, such as combining IaaS with Docker for service scheduling, or integrating naming services with micro‑service architectures.

For example, coupling IaaS platforms with Docker and naming services enhances service discovery and fault tolerance.

Thus, DevOps requires both operational (Ops) and development (Dev) competencies.