How to build new application-oriented O & M management ideas

How to build new application-oriented O & M management ideas
GuideO & M requires breakthroughs in thinking, from Ops to DevOps, from projects to products, from resources to applications. Many problems have been plagued and are being considered. Why does most CMDB projects fail? Why is O & M automation rather than IT automation more discussed? Why is online problems always a black box for O & M personnel? Let's take a look at these questions.

Today, I would like to share with you a new idea-building a new application-oriented O & M management thinking and taking this idea to find new O & M solutions. Therefore, I would like to summarize the abstract application-oriented management as follows:

In the ITIL era, we all know the concept that CMDB is the metadata center of IT service systems, and now applications should be the metadata of CMDB. The O & M capability is built on the application-oriented dimension, and the application-oriented IT capability is divided into three parts:

CMDB is the IT resource management system.

What resources are used to support an application? The server occupied by applications is a kind of resource, memory occupied is a kind of resource, storage occupied is a kind of resource, and load balancing is a kind of resource. However, you must note that this resource is not more of a backend service, such as The IaaS service or PaaS service.

Action

Application changes are categorized by roles in many scenarios, such as application delivery and application upgrade. These scenarios are for Dev/Test/Ops. There is also a change in the routine maintenance process for Ops-only scenarios, such as application migration and application resizing. Actions Apply to resources. For example, if the version of an application is changed, and the application is scaled up, the application resources are added. Traditional O & M in the past always focuses on understanding fragmented O & M automation capabilities.

Status

To measure the health status or quality of an application, we need to collect various status data to support applications in various scenarios, such as monitoring fault discovery needs and fault recovery needs, application Service optimization needs.

The failure of CMDB construction is partly due to system reasons, but it is more about methodology. We always think that we have found a strong driving force to build resource maintenance processes and scenarios. In fact, these are our own ideas. The Infrastructure Department of the data center manages all configuration and management of the CMDB. The resource department does not care about and cannot care about the Upper-layer applications associated with the resources.

Therefore, I advocate the hierarchical construction of CMDB. The business layer and the resource layer can be separately constructed. However, the application of CMDB must be the primary architecture, and the construction of CMDB on the resource layer should be improved. After the application-centered IT resource lifecycle management is established, the breadth of the resource continues to expand the depth of automation.

However, you must note that the information of CMDB is divided into two categories: instance information and connection information, also known as topology information. Topology information needs to be built and maintained based on our daily work ideas. For example, the architecture view is the input required in the process of R & D and maintenance handover, that is, the application architecture document. The deployment view refers to the data centers and nodes in which the application is deployed online. The infrastructure topology is physical overlay, which expresses the relationship at the infrastructure layer. The business flow view is divided into the capability view built by application services and end-to-end services, similar to the access flow topology.

From the application perspective, the resource information can be well maintained. Now let's consider how to support the application's actions. This scenario can truly solve the power and value of CMDB data maintenance. Provides complete application automation and O & M automation capabilities from an application-oriented perspective. Application automation integrates Dev, Test, Staging, Prod, and other environments to build end-to-end automation capabilities for users. A typical scenario is the delivery pipeline, as shown below:

An end-to-end delivery pipeline can be divided into four standardized processes, which are divided vertically into stages, environments, actions, roles, and other concepts.

Phase

It is the logical division of the delivery stage. For an enterprise's product, the construction standard is a single delivery pipeline, rather than multiple delivery pipelines. A single delivery pipeline can ensure the consistency of the entire delivery process. It is generally divided into R & D, testing, prerelease, and production O & M stages.

Environment

The environment is further subdivided into the above four stages. There will be multi-environment problems in each stage, such as the test stage, The UAT environment and the SIT environment. In the production stage, there are formal production clusters and disaster tolerance backup clusters.

Action

The delivery capability is implemented by action, which is a series of capability orchestration. This action can be divided into deployment actions and additional actions. The deployment action is to complete the standardization process of an environment deployment, such as initializing the environment, installing the package, and so on. Additional actions are the actions to be completed for a specific environment, such as user acceptance testing, it may run automated tests and so on. The deployment action must ensure consistency between different environments. This is the basic capability of the deployment script and prevents the results from being different due to the alienation of the action.

At the action layer, you can also encapsulate a large number of automated processes, tool capabilities, and so on. These capabilities are tailored to all application scenarios.

Role

When performing these actions, different environments can target different roles. This is permission control. It is usually divided into development, testing, and O & M roles, but in the enterprise, the division of roles will be more detailed. Secondly, this role also changes with the change of management mode, testers may deploy the production environment.

This automation capability is not O & M automation, But IT automation. The IT automation platform can be built by O & M to ensure scalability and plug-in capabilities. The ability to expand is the need for capabilities to be extended to different roles. Plug-ins can integrate the tool capabilities of different roles in the past to implement a DevOps-oriented application delivery platform.

Back to O & M automation, the application-oriented automation scenario can still be achieved through the service orchestration model. However, when it comes to other O & M Resources, it gradually loses its connection with applications. This is especially true in terms of ease of management. For example, for database maintenance, we certainly like to maintain and change database instances, rather than adding an application dimension. In the automation of Iaas and PaaS capabilities, resource-oriented action service orchestration can be implemented to automate O & M.

Status is actually an application-oriented measurement method. The closer a measurement is to the application and the closer it is to the service, the more effective the measurement is. Monitoring is a type of measurement. We often take the monitoring alarm capability and fault detection as the core means. However, from this dimension, the flood of alarms is inevitable. We constantly improve the accuracy of alarms, and implement alarm convergence and alarm Association. Our practice is to visualize the alert hierarchy Panel. In terms of time, alarms are displayed in a unified manner. The alert weight for the application layer increases, and the alert weight for the underlying layer decreases to measure the health status of applications. Second, in a unified dashboard, people's thinking will change, and the underlying alarm capabilities will constantly form decision-making reference data, rather than as a direct problem, or even alert consistency. This is because the data is associated with applications.

The new application-oriented O & M management thinking is effective and provides solutions for many unsolved problems in the past, this is also why I have repeatedly stressed the need to "establish an organizational system centered on application O & M + O & M R & D. Applications are business-oriented, so applications are the most driving force.

From: http:// OS .51cto.com/art/201611/522832.htm

Address: http://www.linuxprobe.com/operation-maintenance-management.html