A Guide to Building a Digital Operations Platform

The best practices for building a digital operations platform described here apply not only to OpsAny — they are a handbook for implementing and building most operations platforms.

Step 1: Identify the operations management objects

The first step in building an operations platform is identifying which operations objects you want to manage. They are usually catalogued in layers. This step typically takes 10% of the project time.

Cataloguing resources

Resources are everything other than application systems; we call them all resources.

• Cloud services: WAF, DDoS protection, domains, CDN
• Load balancers: F5, Nginx, Haproxy
• Web servers: Nginx, Tomcat, Apache, JBoss, WebSphere, WebLogic
• Middleware: RabbitMQ, Kafka, ZooKeeper, Redis, Elasticsearch
• Databases: MySQL, PostgreSQL, Oracle, SQL Server, MongoDB, GaussDB, OceanBase
• Operating systems: CentOS, Ubuntu, Windows, UOS, Kylin, EulerOS
• Infrastructure: physical servers, switches, routers, firewalls, security appliances

Cataloguing applications

An application is an independently running application system — for example, an OA system, a CRM system, or an ERP system each counts as one application. Above applications sit application groups, usually called businesses; naming varies by organization.

• Application group: corresponds to a business system, application group, or project
• Application: corresponds to an application system
• Service: corresponds to an independently deployed service module of an application.

Step 2: Analyze each operations object

Once the objects are identified, you can schedule work by object group and work out how each object should be managed. This step typically takes 50% of the project time.

For each operations object, analyze the following:

• Operations processes: catalogue the processes the company commonly uses, to build the ITSM service catalogue. At minimum: service flow diagram, process nodes, process documents.
• Object model: determine which attributes the object needs, to build the CMDB. At minimum: attribute name, attribute ID, attribute data type, attribute description, model relationships.
• Monitoring metrics: determine which metrics the object needs, to build monitoring. At minimum: metric name, metric ID, metric description, alert threshold.
• Inspection metrics: determine which metrics the object needs for inspection. At minimum: metric name, metric ID, metric description, alert threshold.
• Object processes: analyze the relationships between the object and processes, so CMDB and ITSM consumption scenarios can be linked.
• Application analysis: catalogue everything about each application system and produce an "operations management handbook" for it. At minimum: application background, application architecture, deployment details, incident handling, update and deployment, backup.

Step 3: Manage the objects with the platform

Once the objects are catalogued, you start building with the operations platform. This step typically takes 30% of the project time.

Here is how it is done in OpsAny:

Entering management data

Implementation requires familiarity with the platform's features and how to use them; the work is done with those features.

• 1. System initialization, such as enabling MFA, setting the login domain, and configuring email, WeCom, and DingTalk notifications.
• 1. Entering operations objects: OpsAny's 【Resource Platform】 and 【Cloud Management Platform】 are used for this. Resources synced from the cloud platform are written automatically into OpsAny's CMDB, i.e. the Resource Platform. For physical infrastructure, create resource models based on the object models catalogued earlier, then enter data manually or import from Excel — or create collection tasks for automated collection.
• 1. Onboarding operations objects: OpsAny's 【Control Platform】 is used for onboarding. The Community Edition currently supports onboarding hosts and network devices. Different objects have different onboarding methods, and monitoring plugins can be selected at the same time.
• 1. Monitoring validation: once onboarding is complete, validate monitoring.
• 1. Create ticket processes and the ticket service catalogue.

Developing additional plugins

Plugin development uses Shell and Python scripts to build the scripts and plugins the project needs.

• 1. Create the resource models catalogued earlier in the OpsAny Resource Platform, ensuring every resource that needs managing is covered.
• 1. Create asset collection plugins in the OpsAny Control Platform to collect automatically from objects that support it.
• 1. Create metric collection plugins in the OpsAny Control Platform, covering every component running on the operating system.
• 【Enterprise Edition】4. In OpsAny Intelligent Inspection, create inspection plugins and edit the inspection scripts according to the inspection metrics catalogued earlier.

Step 4: Go live, test, and train users

Training before go-live matters. This step typically takes 10% of the project time.

• Resource management validation: Usually using a host as the example object, validate the flows for entering host resources, onboarding hosts, running host jobs, host monitoring, monitoring alerts, host inspection, and using host resources from the Bastion Host.

• Application management validation: Using one application as the example, validate its CI (continuous integration pipeline), artifact repository, and CD (continuous deployment) — the complete CI/CD flow.

• User training: Assign permissions and train users. Note that OpsAny separates page permissions from data permissions: regular users need both page and data permissions, while administrators need only page permissions.

Step 5: Develop custom SaaS applications.

After using OpsAny for a while you may find you need extra features. Don't worry — OpsAny provides complete front-end and back-end development frameworks. Master AI coding tools such as Claude Code and you can build SaaS applications on your own.

See the SaaS Development Guide

---