The main theme today is why we built our Current DevOps platform on CMDB. This process is mainly divided into four parts: The first part is about why DevOps platform needs strong CMDB and how to build CMDB model. The last part is about CMDB sharing of China Merchants Bank headquarters.

The above four blocks are mostly related to our daily work, such as our front-end service construction platform, which includes some of our research and development, research and development process, demand management process, and our code base. The service interaction process may be the platform construction of our continuous interaction.

The latter is our service operation platform. Our operation and maintenance department is more involved in some of our monitoring, inspection, maintenance and alarm events. Service operation platform is the so-called some operation analysis, such as our APM, such as some of our distributed link monitoring, such as some of our statistical analysis platform.

The CMDB it is no longer as before our so-called ITIL proposed the concept of asset management, we now Internet transformation process, the key to the construction of our CMDB around a CMDB application delivery process, around the application process of CMDB delivery around two parts, the first is the basic platform, the second is the yellow below this one, It is our IAAS resource pool, including computing, storage, network and public cloud services.

In the above section, we set up some kind of CMP resource pool management based on the following services. We call the service support platform, around all of these service support platforms, is to provide some substantive, effective data for the top four blocks, do the whole automation process.

The continuous delivery platform is divided into three parts. One is centered on application visualization and automated deployment. The so-called CD is what we call automated deployment.

Automated deployment includes containers and so on. The second is application-specific change management, such as log analysis, log monitoring, and page analysis. The third is to apply the assembly line ability and continuous improvement as the core, that is, we do CD first, then we do some continuous feedback of OPS.

When it comes to research and development, many traditional enterprises are mostly outsourcing manufacturers, and it is difficult to control our research and development. That’s why I put CI at the bottom, which is also a difficult step in traditional enterprises.

In DevOps, we have CMDB, which serves as a link between the previous and the next. It goes down to our basic resources, the automatic creation capability of the infrastructure layer, and goes up to the so-called PaaS services of our operation and maintenance platform. The value of operations is the ability to deliver. The ability to automate can eventually form a button that the platform can deliver directly to the R&D side.

CMDB stands for IT resource management. We are all about application-centric value delivery. Why application-centric? What is it capable of? So if I have this application and it’s on top of the OS, what the OPERATING system is, what the configuration of the system is, what business it belongs to, this layer of the Internet might be called the service tree.

In the service tree, for example, which system the application belongs to, and which large business architecture the system belongs to. And then you go down to this cluster and this machine, what it actually consumes, its storage, its database, and then you go down to some network.

Why focus on apps? As a result, there are many scenarios that can be done, such as continuous delivery, automated job changes and version launching. As long as the operation and maintenance personnel make changes, the data status can be fed back to THE CMDB in real time. For example, if I add a machine now, the machine I add may be known only to the users according to the previous route.

Now many businesses in the Internet architecture, some enterprises do some gray release. In doing so, you need to know exactly which IP addresses have new versions and which IP addresses have not yet been updated. Who’s going to do this? CMDB, which can only be done by monitoring changes.

So why we say IT resource management is application-oriented IT resource management, IT is life cycle management.

CI maintenance in CMDB is mainly divided into two layers, one is the earliest basic layer, and the other is the application layer, which is what we need to build.

At present, each platform is independent. What kind of ways should we influence it? For example, if I have a fault impact analysis, I have monitored that I have a fault, so now everyone’s practice is to send an alarm email to the relevant person in charge, he sees the email to do manual positioning, after positioning the manual to do repair actions in the change platform.

Why can’t some simple actions heal themselves? For example, my monitoring platform detects that the tablespace usage is insufficient. Is there an automatic tablespace expansion script in the change platform? This can be linked to a self-healing action via CMDB, as long as the person in charge knows that it has been fixed. DevOps builds on the premise that object relationships are maintained, and very accurately, before you can support the automation capabilities at the top.

Common scenarios including uplines, downlines, fault self-healing, continuous deployment and so on are all need strong CMDB process, it’s very stressed the CMDB inside we all are based on object to support, such as we are facing an application as an object, or I face to a device for the object, so I for this object, or for the application, I want to know what kind of automation capabilities it can exude from the top.

Here’s why the LIFE cycle of IP applications is supported by CMDB capabilities. For example, the last new business system: apply for a resource change order from the beginning of the process, and the online management staff can receive the work order after the leader’s application is approved. Notify system deployment capabilities. Most of the system deployment capabilities, we now do virtualization, such as some CMP interfaces, can be fully automated creation capabilities. Go to the next step to check whether the out-of-band device is created successfully. To the automated operation and maintenance platform, pull the new OS from the CMDB to deploy what middleware and dependency packages, such as a one-click installation.

Further down from the IT change center is the application build and test environment. During the build process, the environment is ready and ready to deploy the package. Is the package built on the machine or something directly distributed?

We have two lines: launch the release process in the release process, and the release process will automatically go to CMDB to pull the data we maintain, including the specific package and version, as well as the maintenance script of this package, and push it to our system after successful deployment to run our automated regression test case.

After passing the service verification, THE CMDB obtains the status. Then the monitoring platform can deploy the monitoring Agent. This is our very standard online process, which can fully achieve one-click automation, such as one-click capacity expansion, DISASTER recovery switchover and other scenarios.

Finally, I would like to talk about the CMDB construction process of CMDB again. At present, the CMDB construction first is to build an application CMDB, and then build the assembly line capacity on the basis of CMDB. The key principle in this is that it took a lot of time to figure this out.

  • The application CMDB must provide unified application metadata management capabilities, regardless of the application type

  • The core appeal of application CMDB construction is application life cycle management

  • Application CMDB must be application-centric, not base resource-centric

  • The application of CMDB must build an elastic relationship with IT resources from an application perspective

  • CMDB supports unified management of application resources, actions, and status

  • The application of CMDB should be based on a unified base resource layer CMDB

  • The core scenario for using CMDB is continuous delivery