A method, apparatus, and computing device cluster for generating an execution plan

Abstract

A method for generating an execution plan, the method obtains the site information of the target site; according to the site information and the change process template, obtains the change process of the target site; according to the change process and the version baseline data, obtains the execution plan of the target site. In this application, the method can utilize the change process template designed by technical experts based on the version baseline data and their own work experience, and then render the received site information to the change process template to generate the change process of a specific site. This method helps to lower the technical threshold for the design of the delivery process of complex software systems, relieve the tension of expert resources, and reduce the delivery cost. The method can also use the version baseline data to automatically schedule multiple change steps in the change process of each site, and create a change plan that comprehensively considers factors such as the compatibility between subsystems, the dependencies between steps, the operation time of each step, the performance standards of delivery tools, and the technical limitations of each subsystem.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular, to a method, apparatus, and computing device cluster for generating an execution plan. Background Art

[0002] With the continuous increase in the complexity of software systems, the difficulty of product delivery (including upgrades, expansions, deployments, etc.) has also increased accordingly. Product delivery process designers must deeply master information such as the compatibility between subsystems, the dependencies between steps, the operation duration of each step, the performance standards of delivery tools, and the technical limitations of each subsystem. In addition, they also need to consider the configuration information of the actual customer deployment to precisely design the delivery process. Product implementation and delivery personnel face a relatively high threshold for getting started when configuring subsystem parameters and require manual operations.

[0003] For complex software systems, comprehensive planning and design are essential. During the delivery and implementation phases, since different subsystems are usually responsible for upgrades by different executors, it is necessary to flexibly split the overall plan into dimensions suitable for their respective implementations. In addition, the large-scale deployment of complex software systems in the existing network has also increased the complexity of the delivery process. Summary of the Invention

[0004] To solve the above problems, embodiments of this application provide a method for generating an execution plan. This method helps to lower the technical threshold for designing the delivery process of complex software systems, relieve the shortage of expert resources, and reduce delivery costs. In addition, this application also provides an execution plan generation apparatus and a computing device cluster corresponding to the execution plan generation method.

[0005] For this reason, the following technical solutions are adopted in the embodiments of this application:

[0006] In a first aspect, embodiments of this application provide a method for generating an execution plan. The method is applied to a management platform, and the management platform is used to manage infrastructure. The infrastructure includes at least one site, and at least one site is used to deploy a software system. The method includes: obtaining site information of a target site, where the site information includes relevant information of the software system already deployed at the target site, and at least one site includes the target site; obtaining a change process of the target site according to the site information and a change process template, where the change process template is used to support whether to expand process nodes and whether to generate process nodes based on the site information, a process node is a delivery step when the software system is delivered, and the change process includes the expanded process nodes and / or the generated process nodes; obtaining an execution plan of the target site according to the change process and version baseline data, where the version baseline data is used to schedule the expanded process nodes and / or the generated process nodes in the change process, and the execution plan is used to indicate an upgrade or change of the software system already deployed at the target site.

[0007] In this embodiment, the method can utilize a change process template designed by technical experts based on version baseline data and their own work experience, and then render the change process template according to the received site information to generate a change process for a specific site. This method helps to lower the technical threshold for designing the delivery process of complex software systems, relieve the tension of expert resources, and reduce delivery costs. The method can also use the version baseline data to automatically schedule multiple change steps in the change process for each site, creating a change plan that comprehensively considers factors such as compatibility between subsystems, dependencies between steps, operation time of each step, performance standards of delivery tools, and technical limitations of each subsystem. Such a change plan can ensure that the execution of the delivery process is more efficient and accurate.

[0008] In one embodiment, after obtaining the site information of the target site, the method further includes: performing desensitization processing on the site information.

[0009] In this embodiment, after receiving the site information, the method performs desensitization processing on the site information to prevent the leakage of sensitive information of customers.

[0010] In one embodiment, before obtaining the change process of the target site according to the site information and the change process template, the method further includes: obtaining user requirements input by the user; obtaining the change process of the target site according to the site information and the change process template, including: inputting the user requirements and the site information into the change process template to obtain the change process of the target site.

[0011] In one embodiment, the method further includes: inputting the execution plan of the target site into a data model to obtain a wizard-style change process diagram, where the data model includes various types of metadata required for delivering a software system.

[0012] In this embodiment, the method can input the change plan into a structured data model, and can convert the change plan into a wizard-style change process diagram, enabling implementers to complete the automated upgrade or change of a complex software system at low cost according to the guidance on the change process diagram.

[0013] In one embodiment, the execution plan of the target site exists in the form of a directed acyclic graph (DAG), where the nodes in the DAG represent a delivery step, and the edges in the DAG represent the sequence of delivery steps.

[0014] In this embodiment, the method can generate an execution plan of a DAG, and can utilize the characteristics of the DAG being acyclic and capable of topological sorting to effectively represent and process complex dependency relationships.

[0015] Second aspect, an execution plan generation device is provided in an embodiment of the present application, including: a first processing module, configured to obtain the site information of the target site, where the site information includes the relevant information of the software systems already deployed at the target site, and at least one site includes the target site; a second processing module, configured to obtain the change process of the target site according to the site information and the change process template, where the change process template is used to support whether to expand process nodes and whether to generate process nodes based on the site information, a process node is a delivery step when the software system is delivered, and the change process includes the expanded process nodes and / or the generated process nodes; a third processing module, configured to obtain the execution plan of the target site according to the change process and the version baseline data, where the version baseline data is used to schedule the expanded process nodes and / or the generated process nodes in the change process, and the execution plan is used to indicate the upgrade or change of the software systems already deployed at the target site.

[0016] In one implementation, after obtaining the site information of the target site, the first processing module is further configured to perform desensitization processing on the site information.

[0017] In one implementation, before obtaining the change process of the target site according to the site information and the change process template, the second processing module is further configured to obtain the user requirements input by the user; the second processing module is configured to input the user requirements and the site information into the change process template to obtain the change process of the target site.

[0018] In one implementation, the third processing module is further configured to input the execution plan of the target site into the data model to obtain a wizard-style change flow chart, where the data model includes various types of metadata required for delivering the software system.

[0019] In one implementation, the execution plan of the target site exists in the form of a directed acyclic graph (DAG), the nodes in the DAG represent a delivery step, and the edges in the DAG represent the sequence between the delivery steps.

[0020] Third aspect, a computing device is provided in an embodiment of the present application, including: at least one memory; at least one processor, where the processor is configured to execute the instructions stored in the memory so that the computing device executes the embodiments of the first aspect in all possible implementations.

[0021] Fourth aspect, a computer-readable storage medium is provided in an embodiment of the present application, including computer program instructions, when the computer program instructions are executed by a computing device, the computing device executes the embodiments of the first aspect in all possible implementations.

[0022] Fifth aspect, an embodiment of the present application provides a computer program product including instructions. The computer program product stores the instructions, and when the instructions are executed by a computing device, the computing device implements each possible implementation embodiment of the first aspect.

[0023] Sixth aspect, an embodiment of the present application provides a computing device cluster, including at least one computing device. Each computing device includes a processor and a memory; the processor of at least one computing device is configured to execute the instructions stored in the memory of at least one computing device, so that the computing device cluster executes each possible implementation embodiment of the first aspect.

[0024] Seventh aspect, an embodiment of the present application provides a computer-readable storage medium, including computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes each possible implementation embodiment of the first aspect.

[0025] Eighth aspect, an embodiment of the present application provides a computer program product including instructions. The computer program product stores the instructions, and when the instructions are executed by a computing device cluster, the computing device cluster implements each possible implementation embodiment of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The following briefly introduces the drawings required for the description of the embodiments or the prior art.

[0027] Figure 1 It is a schematic structural diagram of a software management system provided in an embodiment of the present application;

[0028] Figure 2 It is a schematic diagram of a scenario where a user uses the software management system provided in an embodiment of the present application;

[0029] Figure 3 It is a schematic structural diagram of a cloud management platform provided in an embodiment of the present application;

[0030] Figure 4 It is a schematic flowchart of the cloud management platform executing the functions of the software management system provided in an embodiment of the present application;

[0031] Figure 5 It is a flowchart of a method for generating an execution plan provided in an embodiment of the present application;

[0032] Figure 6 It is a structural diagram of a device for generating an execution plan provided in an embodiment of the present application;

[0033] Figure 7 It is a schematic structural diagram of a computing device provided in an embodiment of the present application;

[0034] Figure 8Schematic diagram of an architecture of a computing device cluster provided in an embodiment of the present application;

[0035] Figure 9 Another schematic diagram of an architecture of a computing device cluster provided in an embodiment of the present application. Detailed implementation manners

[0036] Next, the technical solutions in the embodiments of the present application will be described with reference to the accompanying drawings in the embodiments of the present application.

[0037] As used herein, the term "and / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B may represent: A exists alone, A and B exist simultaneously, and B exists alone. The symbol " / " in this article represents an "or" relationship between associated objects. For example, A / B represents A or B.

[0038] Terms such as "first" and "second" in the specification and claims of this application are used to distinguish different objects, rather than to describe a specific order of the objects. For example, the first response message and the second response message are used to distinguish different response messages, rather than to describe the specific order of the response messages.

[0039] In the embodiments of the present application, words such as "exemplary" or "for example" are used to represent examples, illustrations, or explanations. Any embodiment or design solution described as "exemplary" or "for example" in the embodiments of the present application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific manner.

[0040] In the description of the embodiments of the present application, unless otherwise specified, the meaning of "a plurality" refers to two or more. For example, a plurality of processing units refers to two or more processing units; a plurality of elements refers to two or more elements.

[0041] Before introducing the technical solutions protected by the present application, several professional terms related to the technical solutions protected by the present application are explained in advance, which are respectively:

[0042] A software system is a complex collection of components and layers, with the goal of providing specific functions and services. Software systems usually include applications, databases, middleware, operating systems, network protocols and communications, security, user interfaces, dependency libraries and frameworks, configuration files, test codes and other elements. The delivery process of a software system is divided into multiple stages, including project initiation, demand research, system development, system pilot, system promotion, continuous integration and continuous deployment, monitoring and feedback, blue-green deployment and grayscale release, containerization and infrastructure as code, and project closing. Among them, the continuous integration and continuous deployment stage is the key link to achieve rapid software delivery, which accelerates the entire software delivery process from code writing to deployment through automation and process optimization. The practical content of this stage mainly includes automated construction, automated testing and automated deployment.

[0043] A site refers to the specific customer site where the software is deployed in software delivery, including the customer's data center or branch structure, and the software and hardware environment deployed at these locations.

[0044] An execution plan is a detailed description of the change operations that need to be performed to transform the current state into the target state. Change operations can include create (CREATE), delete (DELETE), and update (UPDATE) operations. CREATE operations are operations that require the creation of new resources. DELETE operations are operations that require the removal of old resources. UPDATE operations are operations that require the modification of existing resources. These operations ensure that changes to resources are executed precisely as planned.

[0045] Next, the technical solution provided by this application is introduced.

[0046] Generally speaking, process design is very complex for the delivery of complex software systems. During the continuous integration and continuous deployment phases, designers must have a deep understanding of multiple key factors, such as the compatibility between subsystems in the software system, the dependencies between steps, the operation time of each step, the performance standards of the delivery tools, and the technical limitations of each subsystem. In addition, they also need to combine the customer's actual deployment configuration information to accurately design the delivery process. This process is time-consuming and labor-intensive, and usually requires the participation of senior experts to complete. Faced with many customer locations with poor network connectivity and geographical isolation, expert resources have become a bottleneck, which has a serious impact on the efficiency of delivery operations.

[0047] In view of this, an embodiment of the present application provides a method for generating an execution plan. This method can utilize a change process template designed by technical experts based on version baseline data and their own work experience, and then render the change process template according to the received site information to generate a change process for a specific site. This method helps to lower the technical threshold for designing the delivery process of complex software systems, relieve the tension of expert resources, and reduce delivery costs.

[0048] This method can also use the version baseline data to automatically schedule multiple change steps in the change process for each site, creating a change plan that comprehensively considers factors such as compatibility between subsystems, dependencies between steps, operation time of each step, performance standards of delivery tools, and technical limitations of each subsystem. Such a change plan can ensure that the execution of the delivery process is more efficient and accurate.

[0049] Figure 1 It is a schematic structural diagram of a software management system provided in an embodiment of the present application. As Figure 1 shown, the software management system 100 may include an information collection tool 110, a design tool 120, and an implementation tool 130.

[0050] The information collection tool 110 is used to collect site information required for delivery design. The site information may be related information of the software system deployed at the customer's site, such as the list of software systems, version numbers, deployment scale, deployment form, non-standard configuration, etc. The site information can be stored in a configuration management database (CMDB), or in certain configuration files, or other various systems. Among them, the list of software systems refers to listing all software products and components deployed at the customer's site to ensure that the delivery team understands all software entities existing in the environment. The version number refers to recording the version information of each software component in the software system. The deployment scale refers to describing the deployment scale of the software system, including the number of users, concurrency, data volume, etc. The deployment form refers to indicating the deployment architecture of the software system, such as monolithic application, microservices, containerization, or cloud services, etc. The non-standard configuration refers to recording the non-standard configuration of the software system at the customer's site, which may be customized to meet specific business requirements.

[0051] Exemplarily, as Figure 1 shown, the information collection tool 110 may include a data collection framework 111, a data collection script 112, and a data desensitization module 113.

[0052] The data collection framework 111 can provide a systematic method for collecting, processing, and storing data. It can integrate multiple data sources, such as databases, file systems, and network interfaces, to provide a unified access point for data collection. The data collection framework 111 is suitable for tools that handle large-scale data streams, such as Apache Flume and Logstash, to ensure stable data transmission. Developers can add or modify data collection and processing components according to requirements to adapt to different data collection scenarios. In addition, the data collection framework 111 has a fault tolerance mechanism to ensure recovery in case of failures during data collection, thus ensuring data integrity. Before the data enters the storage system, the data collection framework 111 can perform preprocessing operations, including filtering, transformation, and aggregation. At the same time, the data collection framework 111 also includes the function of monitoring the data collection status and recording logs for problem troubleshooting and analysis.

[0053] In the embodiment of this application, the software management system 100 customizes a set of data collection frameworks 111 to instruct each subsystem in the software system to provide the data sources it needs to collect as required, such as site information, and then uniformly schedules and executes.

[0054] The data collection script 112 is customized and written to meet specific data collection requirements, and it can achieve personalized collection of specific data sources. The data collection script 112 can be configured to run automatically to reduce manual operations and improve work efficiency. The data collection script 112 can contain complex logic to handle various data collection scenarios, including conditional judgment and loop processing. It can also parse and process different formats of data, such as JavaScript object notation (JSON), Extensible Markup Language (XML), comma-separated values (CSV), etc. In addition, the data collection script 112 can also contain an error handling mechanism, such as retry logic, to handle temporary failures that may occur during data collection. The data collection script 112 can also be used to test and verify the data collection process to ensure that the collected data is both accurate and effective.

[0055] In the embodiment of this application, the data collection framework 111 provides a stable and scalable platform to support complex data collection tasks, while the data collection script 112 provides flexibility and customization capabilities to adapt to specific data collection requirements. The two can be used in combination to effectively complete the collection of site information.

[0056] After receiving the local site information, the data desensitization module 113 performs desensitization processing on the local site information. For example, the data desensitization module 113 filters out sensitive information in the local site information to prevent the leakage of customers' sensitive information. These sensitive information can be information such as the customer's Internet Protocol (IP) address, password, secret key, etc.

[0057] The design tool 120 is used to generate a change plan for the local site according to the local site information, the change process template, and the version baseline data.

[0058] Exemplarily, as Figure 1 shown, the design tool 120 may include a template management module 121, a data management module 122, a process orchestration module 123, and a plan generation module 124.

[0059] The template management module 121 is used to manage the change process template and provide the change process template to the process orchestration module 123. Among them, the change process template is a standardized document designed to guide the various steps of a project or organization in change management. It helps to ensure the transparency, consistency, and standardization of the change process, thereby minimizing the impact of changes on the organization and business operations. The change process template can include a change request form, a change management process, a change management system template, a project change management form template, a project plan change process template, a change management plan template, a change management roadmap template, a change request template, a change control process template, etc. By using these templates, the design tool 120 can more effectively manage and control changes in the project, thereby ensuring the achievement of project goals.

[0060] In the embodiment of the present application, the change process template is designed by technical experts according to the version baseline data and their own work experience. The change process template is used to support whether to expand a certain process node and whether to generate a certain process node based on the local site information. A process node represents a delivery step when the software system is delivered. For example, the change process template can support determining whether a corresponding process node is displayed according to the fields in the local site information and the version baseline data. For another example, the change process template can support generating multiple process nodes for a subsystem with multiple deployed copies according to the local site information.

[0061] The data management module 122 is used to manage the preset version baseline data, such as adaptively and dynamically adjusting the version baseline data according to the changes in the version, and can provide the version baseline data to the plan generation module 124. Among them, the version baseline data refers to the stable state of the project at a specific time point in project management and software development, and this state covers multiple aspects such as software documents, designs, codes, configurations, and test cases. The version baseline is a key tool to ensure project consistency and stability. It provides a reference point and baseline for the project, helping to control project changes and risks.

[0062] In the embodiments of the present application, the version baseline data is used to schedule the process nodes of the change process. The version baseline data may include upgrade paths (used to describe which source version can be upgraded to which target version), compatibility baselines between subsystems, estimated delivery durations of each subsystem, performance baselines of delivery tools, dependencies between subsystems, change orders between multiple logical modules or subsystems, product materials, and other data. The version baseline data is usually carried by unstructured documents and cannot be consumed by code.

[0063] The version baseline data may also include information such as change time window planning values and concurrency. Among them, the change time window planning value usually refers to the time window reserved for change operations in project management and system maintenance. This time window is used to plan and execute system changes to reduce the impact on the business. For example, in the maintenance of information technology (IT) systems or software, the change time window may be the business off-peak period, so that system upgrades or configuration changes can be carried out without affecting users. The planning of the change time window needs to consider factors such as business requirements, system stability, and the work arrangements of the maintenance team.

[0064] Concurrency refers to the number of requests that the system can handle at the same time, which reflects the load capacity and performance of the system. In multithreaded programming and system design, high concurrency means that more threads or processes can be managed and scheduled for execution by system resources (such as the central processing unit (CPU), memory, etc.) at the same time. The level of concurrency directly affects the performance and response ability of the system. For example, in performance testing, the performance of the system under high load can be evaluated by simulating high-concurrency scenarios, including response time and throughput. The optimization of concurrency can be achieved by methods such as increasing hardware resources, optimizing code logic, and using concurrency control mechanisms (such as mutex locks, semaphores).

[0065] After receiving the user requirements input by the user and the site information collected by the information collection tool 110, the process orchestration module 123 can input the user requirements and the site information into the change process template, render the change process template, and determine which process nodes are expanded and which process nodes are generated. The process orchestration module 123 can constitute the change process of the site according to the expanded process nodes and / or the generated process nodes.

[0066] The change process can exist in the form of "deliverables", so that the change process can be imported into the implementation tool of the customer's site for change implementation. In some cloud service scenarios, the network environment construction of the customer and the service for generating the change plan are not in the same network environment, so it is necessary to use the offline package method for transmission.

[0067] If the design tool 120 receives the user requirements input by the user, it can transfer the user requirements to the process orchestration module 123. The process orchestration module 123 can input the user requirements and the site information into the change process template to obtain the change process of the site. Optionally, after the change process is orchestrated, the process orchestration module 123 can integrate the operation nodes corresponding to the user requirements into the change process to obtain the integrated change process.

[0068] The plan generation module 124 is used to automatically schedule multiple process nodes (i.e., delivery steps) in the change process of the site by using the version baseline data to generate a change plan. The specific implementation process is as follows:

[0069] The plan generation module 124 can take the intersection of the subsystem list in the version baseline data and the subsystem list of the site in the change process to obtain the subsystem list involved in this delivery. The plan generation module 124 can compare the source version of the upgrade path in the version baseline data with the actual version of the site in the change process to determine whether the software system deployed at the site is upgraded or changed. The plan generation module 124 can generate the change order of each subsystem based on the compatibility baseline and dependency relationship between subsystems in the version baseline data. The plan generation module 124 can generate the parallel or serial rules between steps based on the performance baseline of the delivery tool in the version baseline data. The plan generation module 124 can calculate how many time windows are needed and the delivery steps to be executed in each time window based on the estimated delivery duration of each subsystem and the planned value of the change time window in the version baseline data.

[0070] The plan generation module 124 can, according to the concurrency degree, summarize information such as the list of subsystems involved in this delivery, whether to upgrade or change, the change order of each subsystem, the parallel or serial rules between steps, how many time windows are required, and the delivery steps to be executed in each time window into an execution plan of a directed acyclic graph (DAG). By leveraging the characteristics of DAG, such as being acyclic and capable of topological sorting, it can effectively represent and handle complex dependency relationships.

[0071] A DAG is a special graph structure composed of vertices (nodes) and directed edges, and there are no cycles in the graph. Vertices (nodes) refer to the basic units in the graph, representing data, tasks, states, etc. Directed edges refer to the arrows connecting two vertices, representing the one-way relationship from one vertex to another. Acyclic means that there is no path in the graph that starts from a vertex, passes through several edges, and then returns to that vertex. An important property of a DAG is that it can be topologically sorted. Topological sorting arranges all the vertices in a DAG into a linear sequence such that for each edge in the graph, the starting vertex comes before the ending vertex. Topological sorting can be used for task scheduling, dependency relationship parsing, etc. In this application, each node of the DAG represents a delivery step. Each edge of the DAG represents the sequence order between steps. The delivery steps to be executed in each time window are marked by wireframes.

[0072] The implementation tool 130 is used to guide the software system deployed at the local site to be upgraded or changed according to the change plan.

[0073] The implementation tool 130 can pre-construct a structured data model, which is used to define various types of metadata required for the delivery of complex software systems. This metadata can be used by the software management system 100 to generate a wizard-style delivery process and can also be used to automatically create documents for technicians to refer to. In this way, a consistent data source among multiple systems is achieved.

[0074] In this application, the implementation tool 130 can input the change plan into the structured data model and convert the change plan into a wizard-style change flow chart, enabling implementers to complete the automated upgrade or change of a complex software system at low cost according to the guidance on the change flow chart.

[0075] It should be understood that the functional modules, functional devices, etc. involved in the above software management system 100 can also be implemented in software or hardware, specifically depending on the actual situation, and are not limited here. Additionally, the functional modules, functional devices, etc. involved in the above software management system 100 can be arranged separately or integrated, and are not limited here.

[0076] The above is the introduction of the software management system 100 provided by the embodiments of the present application. It can be understood that the above software management system 100 can be configured on a cloud management platform. For example, it can be deployed on at least one virtual machine or container instance, so that the cloud management platform can provide software management delivery services. Of course, the software management system 100 can also be configured on nodes other than the cloud management platform. For example, it can be deployed in at least one data center or on at least one server, which can be determined according to the actual situation and is not limited here. Among them, the cloud management platform can provide pages related to public cloud services for users to remotely access public cloud services. In this embodiment, users can purchase software management services provided by the software management system 100 on the cloud management platform in advance. For the convenience of understanding, the interaction form between users and the cloud management platform is described below.

[0077] As Figure 2 shown, the interaction between users and the cloud management platform mainly includes: users log in to the cloud management platform 200 through the web page of the client, select and purchase cloud services (i.e., software management services) related to the software management system 100 in the cloud management platform 200. After purchase, users can generate the software management system 100 on the cloud management platform 200 based on the functions provided by the software management service. Among them, the cloud management platform 200 is mainly used to manage the infrastructure for running software management services. Exemplarily, the infrastructure of software management services can include multiple data centers set in different regions, and each data center includes multiple servers. The data center can provide basic resources for software management services, such as computing resources, storage resources, etc. Therefore, when users purchase and use software management services, they mainly pay for the resources used. When users use software management services, they can input their requirements for software management services through the configuration interface, application program interface (API), or interface interacting with users provided by the cloud management platform 200. Then, the cloud management platform 200 can generate software management services that match the user's requirements according to the requirements input by the user (or other software / hardware, etc.).

[0078] In addition, some modules in the software management system 100 can be configured on the cloud side and some on the end side, so as to realize software management services through the end-cloud collaboration method. In addition, the software management system 100 can also be all configured on the end side, which can be determined according to the actual situation and is not limited here.

[0079] The cloud management platform 200 can include multiple cloud services, regarding different cloud services as a large number of existing sites in the live network and distinguishing different forms. The deployment situation and version situation of each site cloud service are different. Exemplarily, as Figure 3As shown in the figure, the local cloud service may include a database, disaster recovery, a storage pool, an artificial intelligence (AI) cloud service, network components, common components, and a cloud resource pool.

[0080] The database is the core component in the cloud management platform 200 for storing, managing, and processing data.

[0081] The disaster recovery service ensures the high availability of data and services in the event of a disaster.

[0082] The storage pool is a practice in cloud computing to integrate and share storage resources, allowing local cloud service providers to dynamically and efficiently allocate resources according to demand.

[0083] The AI cloud service provides AI-related computing capabilities and services, including machine learning, data analysis, and natural language processing, etc., to help enterprises achieve intelligent transformation.

[0084] The network components include virtual networks, load balancers, virtual private clouds, etc., which ensure network connectivity, security, and reliability in the local cloud service.

[0085] The computing components include CPUs, graphics processing units (GPUs), etc., which provide computing resources for the local cloud service.

[0086] Common components such as Linux server cluster systems, Nginx, HAProxy, etc., provide load balancing and traffic distribution for the local cloud service, ensuring the high availability and performance of the service.

[0087] The cloud resource pool is where local cloud service providers pool computing resources such as server time, network storage, and other IT resources together and provide services for multiple customers according to the multi-tenant model. Resource pooling enables local cloud service providers to optimize resource utilization and provide measurable services.

[0088] Such as Figure 4 As shown in the figure, when the cloud management platform 200 executes the functions of the software management system 100, it can be divided into pre-delivery pre-operations, pre-delivery preparations, delivery implementation, and post-implementation inspection phases.

[0089] In the pre-delivery pre-operations phase, after a new version of the software system is released, the cloud management platform 200 can receive information input by R & D personnel into the cloud service, such as cloud service name, cloud service version, paths supported by the cloud service, etc. The cloud service information can be imported into the data management module 122 in the design tool 120, allowing the data management module 122 to dynamically adjust the version baseline data.

[0090] The cloud management platform 200 can receive the node information during the upgrade entered by experts. Taking the upgrade of the cloud resource pool base as an example, the node information can be execution conditions, operation descriptions, operation impacts, involved cloud services, upgrade dependencies, etc. The cloud management platform 200 can import the node information into the template management module 121 of the design tool 120. The template management module 121 can draw the node information entered by experts as process nodes and arrange the nodes into a standard change process template according to the upgrade scenario.

[0091] The cloud management platform 200 can instruct the information collection tool 110 to collect the site information of the existing network site and import the desensitized site information into the design tool 120. The design tool 120 renders the change process template according to the site information to render a site-specific delivery plan, personalized implementation guide, personalized software package, and personalized construction period plan.

[0092] The cloud management platform 200 can instruct the design tool 120 to generate an execution plan based on the execution process and version baseline data of the selected site and import the execution plan into the implementation tool 130.

[0093] In the pre-delivery preparation stage, the cloud management platform 200 can perform pre-delivery risk closed-loop (such as risk identification, risk assessment, risk planning, risk monitoring, risk communication, etc.), software package and file preparation (such as software package construction, version control, documentation, license and compliance documents, backup and recovery plans, etc.), and delivery tool preparation (such as deployment tools, configuration management tools, monitoring and logging tools, testing tools, containerization and virtualization tools, backup tools, disaster recovery tools, etc.).

[0094] In the delivery implementation stage, the cloud management platform 200 can instruct the implementation tool 130 to enable the on-site implementation personnel to perform implementation operations in a wizard-like manner, visually view the progress and details of each implementation node, and view the personalized implementation guide and implementation construction period plan. The implementation tool 130 can create operations such as wizard-like changes, project creation, project execution, and post-execution inspection.

[0095] In the post-implementation inspection stage, after the implementation is completed, the cloud management platform 200 can export a report on the side of the implementation tool 130 and perform post-delivery inspection based on the report.

[0096] The above is the introduction to the software management system provided by the embodiments of the present application. Next, based on the above content, the simulation method provided by the embodiments of the present application will be introduced.

[0097] Exemplarily, Figure 5The figure shows a schematic flowchart of an execution plan generation method provided by an embodiment of the present application. It can be understood that the execution plan generation method can be executed by the design tool 120 in the software management system 100 described above. The specific implementation process is as follows:

[0098] Step S501: Obtain the site information of the target site.

[0099] After receiving the site information, the design tool 120 performs desensitization processing on the site information. For example, the design tool 120 filters out sensitive information in the site information to prevent the leakage of customers' sensitive information. Such sensitive information can be information such as customers' IP addresses, passwords, and secret keys.

[0100] Step S502: Obtain the change process of the target site according to the site information and the change process template.

[0101] After receiving the user requirements and the site information input by the user, the design tool 120 can input the user requirements and the site information into the change process template, render the change process template, and determine which process nodes are expanded and which process nodes are generated. The design tool 120 can constitute the change process of the site according to the expanded process nodes and / or the generated process nodes. The change process can exist in the form of "deliverables", so that the change process can be imported into the implementation tool of the customer site for change implementation. In some cloud service scenarios, the customer's network environment construction and the service of change plan generation are not in the same network environment, so it is necessary to use the offline package method for transmission.

[0102] If the design tool 120 receives the user requirements input by the user, it can input the user requirements and the site information into the change process template to obtain the change process of the site. Optionally, the design tool 120 can integrate the operation nodes corresponding to the user requirements into the change process to obtain the integrated change process.

[0103] Step S503: Obtain the execution plan of the target site according to the change process and the version baseline data.

[0104] The design tool 120 is used to automatically schedule multiple process nodes (i.e., delivery steps) in the change process of the site by using the version baseline data to generate a change plan. The specific implementation process is as follows:

[0105] The design tool 120 can take the intersection of the subsystem list in the version baseline data and the subsystem list at the local site in the change process to obtain the subsystem list involved in this delivery. The design tool 120 can compare the source version of the upgrade path in the version baseline data with the actual version at the local site in the change process to determine whether the software system deployed at the local site has been upgraded or changed. The design tool 120 can generate the change order of each subsystem based on the compatibility baseline and dependency relationship between subsystems in the version baseline data. The design tool 120 can generate the parallel or serial rules between steps based on the performance baseline of the delivery tool in the version baseline data. The design tool 120 can calculate how many time windows are needed and the delivery steps to be executed in each time window based on the estimated delivery duration of each subsystem and the planned value of the change time window in the version baseline data.

[0106] The design tool 120 can summarize information such as the subsystem list involved in this delivery, whether it has been upgraded or changed, the change order of each subsystem, the parallel or serial rules between steps, how many time windows are needed, and the delivery steps to be executed in each time window into an execution plan of a DAG according to the degree of concurrency. By utilizing the characteristics of the DAG having no loops and being able to perform topological sorting, it can effectively represent and process complex dependency relationships.

[0107] In the embodiment of the present application, the design tool 120 can utilize a change process template designed by technical experts based on the version baseline data and their own work experience to render the received local site information to the change process template to generate a change process for a specific local site. This method helps to lower the technical threshold for the design of the delivery process of complex software systems, relieve the tension of expert resources, and reduce the delivery cost. The design tool 120 can also automatically schedule multiple change steps in the change process for each local site by using the version baseline data, creating a change plan that comprehensively considers factors such as compatibility between subsystems, dependency between steps, operation time of each step, performance standards of delivery tools, and technical limitations of each subsystem. Such a change plan can ensure that the execution of the delivery process is more efficient and accurate.

[0108] Based on the content described above, the embodiment of the present application provides an execution plan generation device 600. As Figure 6 shown, the device 600 includes:

[0109] The first processing module 610 is used to obtain the site information of the target site. The site information includes the relevant information of the software systems already deployed at the target site. At least one site includes the target site. The second processing module 620 is used to obtain the change process of the target site according to the site information and the change process template. The change process template is used to support whether to expand process nodes and whether to generate process nodes based on the site information. A process node is a delivery step when the software system is delivered. The change process includes the expanded process nodes and / or the generated process nodes. The third processing module 630 is used to obtain the execution plan of the target site according to the change process and the version baseline data. The version baseline data is used to schedule the expanded process nodes and / or the generated process nodes in the change process. The execution plan is used to indicate the upgrade or change of the software systems already deployed at the target site.

[0110] In one implementation, after obtaining the site information of the target site, the first processing module 610 is further used to desensitize the site information.

[0111] In one implementation, before obtaining the change process of the target site according to the site information and the change process template, the second processing module 620 is further used to obtain the user requirements input by the user. The second processing module is used to input the user requirements and the site information into the change process template to obtain the change process of the target site.

[0112] In one implementation, the third processing module 630 is further used to input the execution plan of the target site into the data model to obtain a wizard-style change flow chart. The data model includes various types of metadata required for delivering the software system.

[0113] In one implementation, the execution plan of the target site exists in the form of a directed acyclic graph (DAG). The nodes in the DAG represent a delivery step, and the edges in the DAG represent the sequence of delivery steps.

[0114] Among them, the first processing module 610, the second processing module 620, and the third processing module 630 can all be implemented by software or by hardware. Exemplarily, next, taking the first processing module 610 as an example, the implementation manner of the first processing module 610 is introduced. Similarly, the implementation manners of the second processing module 620 and the third processing module 630 can refer to the implementation manner of the first processing module 610.

[0115] As an example of a software functional unit, the first processing module 610 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the above computing instance may be one or more. For example, the first processing module 610 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers for running the code may be distributed in the same region or in different regions. Further, the multiple hosts / virtual machines / containers for running the code may be distributed in the same availability zone (AZ) or in different AZs, and each AZ includes one data center or multiple geographically proximate data centers. Usually, one region may include multiple AZs.

[0116] Similarly, the multiple hosts / virtual machines / containers for running the code may be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Usually, one VPC is set within one region. For cross-region communication between two VPCs within the same region and between VPCs in different regions, a communication gateway needs to be set in each VPC, and the interconnection between VPCs is realized through the communication gateway.

[0117] As an example of a hardware functional unit, the first processing module 610 may include at least one computing device, such as a server, etc. Alternatively, the first processing module 610 may also be a device implemented by an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). Among them, the above PLD may be implemented by a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0118] The multiple computing devices included in the first processing module 610 may be distributed in the same region or in different regions. The multiple computing devices included in the first processing module 610 may be distributed in the same availability zone (AZ) or in different AZs. Similarly, the multiple computing devices included in the first processing module 610 may be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Among them, the multiple computing devices may be any combination of computing devices such as servers, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), and generic array logic (GALs).

[0119] It should be noted that in other embodiments, the first processing module 610 may be used to execute any step in the method as Figure 5 shown, the second processing module 620 may be used to execute any step in the method as Figure 5 shown, the third processing module 630 may be used to execute any step in the method as Figure 5 shown. The steps to be implemented by the first processing module 610, the second processing module 620, and the third processing module 630 can be specified as needed. The entire function of the apparatus 600 is implemented by the first processing module 610, the second processing module 620, and the third processing module 630 respectively implementing different steps in the method as Figure 5 shown.

[0120] Figure 7 This is a schematic structural diagram of a computing device provided in an embodiment of the present application. As Figure 7 shown, the computing device 700 includes a bus 710, a processor 720, a memory 730, and a communication interface 740. The processor 720, the memory 730, and the communication interface 740 communicate with each other through the bus 710. The computing device 700 may be a server, a computer, a portable notebook, a cabinet, etc. It should be understood that the present application does not limit the number of processors and memories in the computing device 700.

[0121] The bus 710 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of simplicity of representation, Figure 7 only one line is shown in, but it does not mean that there is only one bus or one type of bus. The bus 710 may include a path for transmitting information between various components of the computing device 700 (for example, the processor 720, the memory 730, and the communication interface 740).

[0122] The processor 720 can be any one or more of processors such as a central processing unit (CPU), a graphics processing unit (GPU), a micro processor (MP), or a digital signal processor (DSP).

[0123] The memory 730 may include volatile memory, such as random access memory (RAM). The memory 730 may also include non-volatile memory, such as read-only memory (ROM), flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

[0124] The memory 730 stores executable program code, and the processor 720 executes the executable program code to respectively implement the functions of the foregoing multiple modules, such as the first processing module 610, the second processing module 620, and the third processing module 630, etc., so as to implement the method as Figure 5 shown. That is, the memory 730 stores instructions for executing the method as Figure 5 shown.

[0125] Alternatively, the memory 730 stores executable code, and the processor 720 executes the executable code to respectively implement the functions of the foregoing modules, so as to implement the method as Figure 5 shown. That is, the memory 730 stores instructions for executing the method as Figure 5 shown.

[0126] The communication interface 740 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 700 and other devices or a communication network.

[0127] The embodiments of the present application also provide a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smart phone.

[0128] As Figure 8As shown, the computing device cluster includes at least one computing device 700. Instructions for executing the method as shown in Figure 5 may be stored in the memory 730 of one or more of the computing devices 700 in the computing device cluster.

[0129] In some possible implementations, the memory 730 of one or more of the computing devices 700 in the computing device cluster may also separately store partial instructions for executing the method as shown in Figure 5 . In other words, a combination of one or more computing devices 700 can jointly execute the instructions for executing the method as shown in Figure 5 .

[0130] It should be noted that the memories 730 in different computing devices 700 in the computing device cluster may store different instructions, respectively for executing partial functions of the above-mentioned first processing module 610. That is, the instructions stored in the memories 730 of different computing devices 700 can implement the functions of one or more of the above-mentioned second processing module 620 and third processing module 630.

[0131] In some possible implementations, one or more computing devices in the computing device cluster can be connected through a network. Among them, the network can be a wide area network or a local area network, etc. Figure 9 Shows a possible implementation. As shown in Figure 9 , two computing devices, namely computing device 700A and computing device 700B, are connected through a network. Specifically, they are connected to the network through the communication interfaces in each computing device. In this type of possible implementation, the memory 730 in computing device 700A stores instructions for executing partial functions of the above-mentioned first processing module 610, second processing module 620, and third processing module 630. At the same time, the memory 730 in computing device 700B stores instructions for executing other partial functions of the above-mentioned first processing module 610, second processing module 620, and third processing module 630.

[0132] Figure 9 The connection method between the computing device clusters as shown in Figure 5 is considered because the method provided in this application as shown in Figure 5 requires a large amount of data storage. Therefore, it is considered to hand over the functions implemented by other partial modules of the above-mentioned first processing module 610, second processing module 620, and third processing module 630 to computing device 700B for execution.

[0133] It should be understood that Figure 9 the functions of computing device 700A shown in Figure 9 can also be completed by multiple computing devices 700. Similarly, the functions of computing device 700B can also be completed by multiple computing devices 700.

[0134] The embodiments of the present application also provide another computing device cluster. The connection relationship between the computing devices in the computing device cluster can be similarly referred to Figure 7 and Figure 8 the connection method of the computing device cluster. The difference is that in the memory 730 of one or more computing devices 700 in the computing device cluster, the same instructions for executing the method as shown in Figure 5 can be stored.

[0135] In some possible implementation manners, the memory 730 of one or more computing devices 700 in the computing device cluster may also separately store partial instructions for executing the method as shown in Figure 5 . In other words, the combination of one or more computing devices 700 can jointly execute the instructions for executing the method as shown in Figure 5 .

[0136] It should be noted that the memories 730 in different computing devices 700 in the computing device cluster may store different instructions for executing partial functions of the computing device 700. That is, the instructions stored in the memories 730 of different computing devices 700 can implement the functions of one or more of the above-mentioned first processing module 610, second processing module 620, and third processing module 630.

[0137] The embodiments of the present application also provide a computer program product containing instructions. The computer program product can be software or a program product containing instructions that can run on a computing device or be stored in any available medium. When the computer program product runs on at least one computing device, it causes at least one computing device to execute the method as shown in Figure 5 .

[0138] The embodiments of the present application also provide a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid-state drive), etc. The computer-readable storage medium includes instructions that instruct the computing device to execute the method as shown in Figure 5 .

[0139] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the various embodiments of the present application.

Claims

1. A method for generating an execution plan, characterized in that: The method is applied to a management platform, the management platform is used to manage infrastructure, the infrastructure includes at least one bureau point, the at least one bureau point is used to deploy a software system, and the method includes: Acquire station point information of a target station point, wherein the station point information includes relevant information of the software system deployed at the target station point, and the at least one station point includes the target station point; According to the station point information and the change process template, a change process of the target station point is obtained, wherein the change process template is used to support whether to expand a process node and whether to generate a process node based on the station point information, wherein the process node is a delivery step when the software system is delivered, and the change process includes the expanded process node and / or the generated process node; According to the change process and version baseline data, an execution plan for the target station is obtained. The version baseline data includes a compatibility baseline, an estimated delivery time and dependencies between subsystems. The compatibility baseline is used to verify the version consistency between subsystems. The estimated delivery time is used to allocate nodes to be executed within a time window. The dependencies are used to construct a directed acyclic graph DAG and determine the execution order of the nodes. The version baseline data is used to indicate the scheduling of the expanded process nodes and / or the generated process nodes in the change process. The execution plan is used to indicate the upgrade or change of the software system deployed at the target station.

2. The method according to claim 1, characterized in that: After acquiring the station point information of the target station point, the method further includes: The site information is desensitized.

3. The method according to claim 1, characterized in that Before obtaining the change process of the target station according to the station information and the change process template, the method further includes: Obtain user input for user needs; The step of obtaining the change process of the target station point according to the station point information and the change process template includes: The user requirements and the site information are input into the change process template to obtain the change process of the target site.

4. The method according to any one of claims 1 to 3, characterized in that: The method further comprises: The execution plan of the target site is input into a data model to obtain a wizard-style change flow chart, wherein the data model includes various metadata required for delivering the software system.

5. The method according to any one of claims 1 to 3, characterized in that: The execution plan of the target station exists in the form of a DAG, a node in the DAG represents a delivery step, and an edge in the DAG represents a sequence between delivery steps.

6. An execution plan generation device, characterized in that: include: A first processing module is configured to obtain site information of a target site, wherein the site information includes relevant information of a software system deployed at the target site, wherein the device is applied to a management platform, wherein the management platform is used to manage infrastructure, wherein the infrastructure includes at least one site, wherein the at least one site is used to deploy a software system, and wherein the at least one site includes the target site; A second processing module is used to obtain a change process of the target station according to the station information and a change process template, wherein the change process template is used to support whether to expand a process node and whether to generate a process node based on the station information, wherein the process node is a delivery step when the software system is delivered, and the change process includes an expanded process node and / or a generated process node; The third processing module is used to obtain the execution plan of the target station according to the change process and version baseline data, the version baseline data includes the compatibility baseline, estimated delivery time and dependency relationship between subsystems, the compatibility baseline is used to verify the version consistency between subsystems, the estimated delivery time is used to allocate nodes to be executed within the time window, the dependency is used to build DAG and determine the execution order of the nodes, the version baseline data is used to indicate the scheduling of the expanded process nodes and / or the generated process nodes in the change process, and the execution plan is used to indicate the upgrade or change of the software system deployed at the target station.

7. A computing device cluster, characterized in that: include: at least one computing device, each computing device comprising a processor and a memory; The processor of the at least one computing device is used to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that: The method comprises computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes the method according to any one of claims 1 to 5.

9. A computer program product comprising instructions, characterized in that The computer program product stores instructions, which, when executed by a computing device cluster, enable the computing device cluster to implement the method according to any one of claims 1 to 5.

Images