System and method for aggregating and mapping event features into daily event portraits

Abstract

A computer-implemented method for aggregating and mapping burst event features into daily portraits. The method includes receiving a set of historical data objects indicative of one or more occurrences of a set of burst events, each set of burst events associated with a set of configuration items; determining one or more daily features of the set of burst events; aggregating the one or more daily features at a daily level; performing clustering on the aggregated one or more daily features at the daily level to create one or more daily portrait cluster clusters; and outputting the one or more daily portrait cluster clusters.

Description

Cross-references to related applications

[0001] This patent application claims priority to U.S. Non-Provisional Patent Application No. 18 / 499,182, filed on October 31, 2023, the entire contents of which are incorporated herein by reference. Technical Field

[0002] Various embodiments of this disclosure generally relate to emergency data processing, and more specifically, to aggregating and mapping emergency features into daily emergency profiles using feature engineering and multi-level clustering. Background Technology

[0003] Any change to any type of system carries the risk that the system may no longer function as expected. Furthermore, even if system performance is not immediately affected, changes can trigger subsequent problems and may take time to determine the cause of the performance change.

[0004] For example, in the software field, the deployment, refactoring, or release of software code carries various associated risks, depending on the code being modified. Failure to clearly understand the vulnerability or risk level of a particular code deployment increases the risk of system outages. For enterprises, code deployment always carries risk, while platform modernization is an ongoing process. Technological advancements are significant events for any product, presenting both substantial risks and opportunities for software companies.

[0005] System outages and / or incidents not only incur service level agreement (SLA) penalties for breach of contract, but more importantly, they consume manpower and time due to rework and can negatively impact a company's customer reputation. The costs associated with vulnerabilities entering the production environment are the most exorbitant, triggering a chain reaction and causing direct losses to all downstream teams. Furthermore, after deployment changes, incident response teams may spend significant time identifying the causes of changes in system performance.

[0006] IT operations change requests, which involve changes to the entire information technology (IT) system, can carry varying degrees of risk and impact. In large IT organizations, change-related incidents can account for 70% to 80% of serious incidents, placing a heavy burden on the IT team. Modern IT architectures are increasingly complex. Handling recurring incidents across large systems throughout the IT infrastructure typically involves dispersed personnel and systems, requiring independent work orders and time-sharing responses, resulting in significant efficiency losses for large IT organizations. Analyzing various incidents within the system daily from multiple perspectives helps in incident resolution.

[0007] This disclosure aims to resolve one or more of the aforementioned problems. Summary of the Invention

[0008] In some aspects, the technology described herein relates to a computer-implemented method for aggregating and mapping features of incidents to daily profiles, the method comprising: receiving a set of historical data objects indicating the occurrence of a set of incidents, each incident being associated with a set of configuration items; determining one or more daily features; aggregating the one or more daily features at the daily level; performing clustering on the aggregated one or more daily features at the daily level to create one or more daily profile clusters; and outputting the one or more daily profile clusters.

[0009] In some respects, the technology described herein relates to a method in which the set of historical data objects represents the occurrence of a set of incidents over at least one month.

[0010] In some respects, the technology described herein relates to a method in which the one or more daily characteristics include: the total number of daily incidents, the number of unique configuration items for incidents received daily, the maximum number of times configuration items for incidents occur daily, and the minimum number of times configuration items for incidents occur daily.

[0011] In some respects, the techniques described herein relate to a method in which one or more daily features are extracted from the set of historical data objects.

[0012] In some respects, the technology described herein relates to a method in which the daily features are extracted from one or more text descriptions, each text description corresponding to one or more incidents, each incident being associated with the set of configuration items.

[0013] In some respects, the technology described herein relates to a method in which aggregating the one or more daily features at the daily level includes: summarizing each of the one or more daily features based on a timestamp associated with the set of historical data objects.

[0014] In some respects, the technology described herein relates to a method in which aggregating the one or more daily features at the daily level includes: determining the number of times each of the one or more daily features occurs on each day of a day or multiple days.

[0015] In some respects, the technology described herein relates to a method that further includes: determining an incident cause code and priority for each object in the set of historical data objects.

[0016] In some respects, the technology described herein relates to a method in which clustering is performed on one or more aggregated daily features at the daily level to create one or more daily profile clusters, further comprising: performing the clustering based on the incident cause code and priority of each object in the set of historical data objects.

[0017] In some respects, the techniques described herein relate to a method in which the clustering is performed by an unsupervised machine learning algorithm.

[0018] In some aspects, the technology described herein relates to a system for aggregating and mapping features of incidents to daily profiles, the system comprising: a memory storing processor-readable instructions; and at least one processor configured to access the memory and execute the processor-readable instructions to perform the following operations: receiving a set of historical data objects indicating the occurrence of a set of incidents, each incident being associated with a set of configuration items; determining one or more daily features; aggregating the one or more daily features at the daily level; performing clustering on the aggregated one or more daily features at the daily level to create one or more daily profile clusters; and outputting the one or more daily profile clusters.

[0019] In some respects, the technology described herein relates to a system in which the set of historical data objects represents the occurrence of a set of incidents over at least one month.

[0020] In some respects, the technology described herein relates to a system in which the one or more daily characteristics include: the total number of daily incidents, the number of unique configuration items for incidents received daily, the maximum number of repetitions of configuration items for incidents occurring daily, and the minimum number of repetitions of configuration items for incidents occurring daily.

[0021] In some respects, the technology described herein relates to a system in which one or more daily features are extracted from the set of historical data objects.

[0022] In some respects, the technology described herein relates to a system in which the daily features are extracted from one or more text descriptions, each text description corresponding to one or more incidents, each incident being associated with the set of configuration items.

[0023] In some respects, the technology described herein relates to a system in which aggregating the one or more daily features at the daily level includes: summarizing each of the one or more daily features based on a timestamp associated with the set of historical data objects.

[0024] In some respects, the technology described herein relates to a system in which aggregating the one or more daily features at the daily level includes: determining the number of times each of the one or more daily features occurs on each day of a day or more.

[0025] In some respects, the technology described herein relates to a system that further includes: determining an incident cause code and priority for each object in the set of historical data objects.

[0026] In some respects, the technology described herein relates to a system in which clustering is performed on one or more aggregated daily features at the daily level to create one or more daily profile clusters, further comprising: performing the clustering based on the incident cause code and priority of each object in the set of historical data objects.

[0027] In some aspects, the technology described herein relates to a non-transitory computer-readable medium storing processor-readable instructions that, when executed by at least one processor, cause the at least one processor to perform the following operations: receiving a set of historical data objects indicating the occurrence of a set of incidents, each incident being associated with a set of configuration items; determining one or more daily features; aggregating the one or more daily features at the daily level; performing clustering on the aggregated one or more daily features at the daily level to create one or more daily profile clusters; and outputting the one or more daily profile clusters. Attached Figure Description

[0028] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various exemplary embodiments and, together with the following description, explain the principles of embodiments of this disclosure.

[0029] Figure 1 An exemplary system overview is shown, according to one or more embodiments, for transmitting data to an artificial intelligence model to aggregate and map incidents within the system.

[0030] Figure 2 An exemplary flowchart 200 is shown, according to one or more embodiments, for aggregating and mapping the features of an emergency to a daily emergency profile.

[0031] Figure 3A An exemplary method for determining a daily profile of an emergency is shown according to one or more embodiments.

[0032] Figure 3B An exemplary chart of daily incidents with assigned characteristics is shown according to one or more embodiments.

[0033] Figure 3C An exemplary chart is shown, according to one or more embodiments, of a clustered set of daily incidents with assigned characteristics.

[0034] Figure 4 An exemplary chart is shown, illustrating a comparison of two days' incident data according to one or more embodiments.

[0035] Figure 5 An exemplary chart output is shown for an exemplary date of a recurring burst of events for a specific configuration item, according to one or more embodiments.

[0036] Figure 6 An exemplary chart output of a recurring work order for an emergency on an exemplary date is shown, according to one or more embodiments.

[0037] Figure 7 An exemplary chart output of an emergency primary trigger alarm on an exemplary date is shown, according to one or more embodiments.

[0038] Figure 8 An exemplary graph output showing the minimum time interval between bursts of the same configuration item according to one or more embodiments is shown.

[0039] Figure 9 An exemplary chart output of a frequently occurring sudden event on an exemplary date is shown, according to one or more embodiments.

[0040] Figure 10 This is a flowchart of a method for aggregating and mapping the characteristics of emergencies into daily profiles.

[0041] Figure 11 A computer system 1100 for performing the techniques described herein is shown according to one or more embodiments of the present disclosure. Detailed Implementation

[0042] Various embodiments of this disclosure generally relate to emergency data processing, and more specifically, to aggregating and mapping emergency features into daily emergency profiles using feature engineering and multi-level clustering.

[0043] The subject matter of this disclosure will now be described more fully with reference to the accompanying drawings, which illustrate specific exemplary embodiments by way of example. Embodiments or implementations described herein as “exemplary” should not be construed as being preferred or advantageous over other embodiments or implementations; rather, such description is only intended to reflect or indicate that an embodiment is an “exemplary” embodiment. The subject matter can be presented in many different forms, and therefore, protected or claimed subject matter is intended to be construed as not being limited to any of the exemplary embodiments described herein; the exemplary embodiments provided are for illustrative purposes only. Similarly, claimed or protected subject matter is intended to have a reasonably broad scope of protection. For example, the subject matter can be presented in the form of a method, apparatus, component, or system. Therefore, embodiments can take the form of hardware, software, firmware, or any combination thereof (other than purely software). Thus, the following detailed description is not intended to be construed as limiting.

[0044] Throughout the specification and claims, terms may imply or suggest subtle semantic meanings beyond their explicit literal meaning in the context. Similarly, "in one embodiment" as used herein does not necessarily refer to the same embodiment, and "in another embodiment" does not necessarily refer to different embodiments. For example, the claimed subject matter is intended to encompass all or part of a combination of exemplary embodiments.

[0045] The terms used herein should be interpreted in their broadest reasonable sense, even when used in conjunction with a detailed description of several specific embodiments of this disclosure. In fact, some terms may be emphasized below; however, any term requiring a limiting interpretation will be clearly and specifically defined in the Detailed Description section.

[0046] Software companies are always committed to avoiding system outages caused by unforeseen events such as software or hardware component upgrades or personnel changes. The system described herein can be configured to analyze and / or process event data from IT systems. For example, the system described herein can receive event data streams over multiple time periods. This event data can be further described as information technology (IT) event data. Event data may include, but is not limited to: (1) unforeseen events; (2) alarm information; (3) change data; (4) problems; and / or (5) anomalies.

[0047] An incident is a situation that may interrupt system operation, services, or functions, or cause them to fail. Incidents can be reported manually by customers or staff, automatically recorded by internal systems, or collected through other means. Factors such as hardware failure, software failure, software defects, human error, and / or cyberattacks can all lead to incidents. For example, the deployment, refactoring, or release of software code may trigger incidents. Similarly, system interruptions or performance changes may also detect incidents. Incidents may possess characteristics, which refer to attributes or features associated with the incident. For example, incident characteristics may include, but are not limited to, the severity, urgency, complexity, scope of impact, cause, and / or configuration items corresponding to the incident (such as systems / platforms / products affected by the incident), descriptions in free text, affected business segments, affected categories / subcategories, and / or the assigned handling team for the incident.

[0048] Analyzing various emergencies within the system daily from multiple perspectives is helpful for emergency response. For example, defining, characterizing, or grouping specific emergencies or groups of emergencies received by the system can be useful. Grouping and defining all emergencies received by the system on a specific day is also of great significance. This task is often complex because emergencies can contain a large number of different characteristic categories. For example, emergencies may contain metadata, including fields such as a brief description containing free-form text fields, affected configuration items (CIs), opening time, emergency cause code, priority, etc. Comparing, grouping, or mapping emergencies based on only a single aspect / field may not reflect the complexity of accurately grouping related emergencies.

[0049] One or more embodiments may include systems and methods configured to group and define emergencies at both a single emergency profile level and a daily profile level. The profiles can be formed based on multidimensional features of the emergencies and provide a reference for emergency management. The daily profiles can be compared and grouped with previously determined daily profiles (e.g., through feature construction and clustering techniques). For example, daily profile grouping can help define a baseline, defining a particular daily profile as a normal operating day. Alternatively, the baseline for a normal operating day can refer to a group of daily profiles containing the number of days. The system can be further used to match a specific daily profile with one or more historical daily profiles. The matching results of daily profiles, single emergency profiles, and daily profiles can provide valuable information for emergency management procedures, which are responsible for responding to and handling emergencies.

[0050] One or more embodiments of the systems and methods described herein can reduce the burden on enterprises in the identification, aggregation, mapping, and final handling of incidents. One or more embodiments can process daily incident data to create daily incident profiles. These daily incident profiles can assist IT management systems in better understanding the incidents received throughout the day from a more holistic perspective.

[0051] Figure 1 This illustration shows an exemplary system overview of a data pipeline for enabling an artificial intelligence model to predict and troubleshoot incidents in a system, according to one or more embodiments. For example, data pipeline system 100 may aggregate and send incident data to artificial intelligence model 180, wherein artificial intelligence model 180 is configured to aggregate and map incident features to a daily incident profile through feature engineering and / or multi-level clustering. Data pipeline system 100 may be a platform comprising multiple interconnected components. Data pipeline system 100 may include one or more servers, intelligent networked devices, computing devices, components, and accompanying software for aggregating and processing data.

[0052] like Figure 1 As shown, the data pipeline system 100 may include a data source 101, a collection point 120, a secondary collection point 110, a front-end gateway processor 140, a data storage device 150, a processing platform 160, a data receiving layer 170, a data receiving layer 171, and an artificial intelligence module 180.

[0053] Data source 101 may include internal data 103 and third-party data 199. Internal data 103 may be a data source directly connected to data pipeline system 100. Third-party data 199 may be a data source externally connected to data pipeline system 100, which will be described in more detail below.

[0054] Both internal data 103 and third-party data 199 of data source 101 may contain incident data 102. Incident data 102 may include incident reports containing information about each incident, including one or more of the following: incident number, closure date / time, category, closure code, closure notes, detailed description, brief description, root cause, or assigned handling team. Incident data 102 may include incident reports containing information about each incident, including one or more of the following: incident key, description, summary, tag, incident type, fix version, operating environment, creator, or annotation. Incident data 102 may include incident reports containing information about each incident, including one or more of the following: file name, script name, script type, script description, display identifier, message, submitter type, submitter link, attributes, file change, or branch information. Incident data 102 may include one or more of the following: real-time data, market data, performance data, historical data, utilization data, infrastructure data, or security data. The above are merely examples of information that can be used as data, and this disclosure is not limited to these examples.

[0055] Incident data 102 can be automatically generated by monitoring tools. These tools can generate alarm information and incident data to notify users of high-risk behaviors and IT environment failures. Incident data can also be generated in the form of work orders. Incident data may include metadata, such as text fields, identification codes, and timestamps.

[0056] Internal data 103 can be stored in a relational database containing an incident table. The incident table can be one or more tables, for example, it may include one or more of the following: problems, tasks, risk situations, incidents, or changes. The relational database can be stored in the cloud, connected to a gateway via encryption, and can periodically send and receive updated data with the cloud. The cloud can be a remote cloud service, a local service, or any combination thereof, and may include a gateway connected to a processing application programming interface (API), which is configured to transmit data to collection point 120 or secondary collection point 110. The incident table may contain incident data 102.

[0057] The data pipeline system 100 may include third-party data 199 generated and maintained by third-party data producers. These third-party data producers may generate incident data 102 from Internet of Things (IoT) devices, desktop devices, and sensors. Third-party data producers may include, but are not limited to, Tryambak, Appneta, Oracle, Prognosis, ThousandEyes, Zabbix, ServiceNow, Density, and Dyatrace. Incident data 102 may include metadata indicating that the data belongs to a specific customer or related system.

[0058] Data pipeline system 100 may include secondary collection points 110, which are configured to collect and preprocess burst data 102 from data source 101. Secondary collection points 110 can be used before data is transferred to collection point 120. For example, secondary collection point 110 may be Apache Minifi software. In one example, secondary collection point 110 may run on a microprocessor of a third-party data producer. One instance of secondary collection point 110 may run on each third-party data producer's microprocessor. Supported data formats for secondary collection point 110 include, but are not limited to, JSON, CSV, Avro, ORC, HTML, XML, and Parquet. Secondary collection point 110 may encrypt the burst data 102 collected from the third-party data producer. Encryption methods for the burst data include, but are not limited to, Mutual Authentication Transport Layer Security (mTLS), Hypertext Transfer Security (HTTPS), Secure Shell (SSH), Public Privilege Protocol (PGP), Internet Protocol Security (IPsec), and Secure Sockets Layer (SSL). Secondary data collection point 110 can perform initial transformation or processing on emergency data 102. Secondary data collection point 110 can be used to collect data through various protocols, generate data traceability information in real time, perform data transformation and encryption operations, and prioritize the data.

[0059] Data pipeline system 100 may include collection point 120. Collection point 120 may be a system configured to provide a security framework for routing, transforming, and transmitting data from data source 101 to downstream processing devices (such as front-end gateway processor 140). For example, collection point 120 may be Apache NiFi software. Collection point 120 may receive raw data and corresponding fields such as source name and access time. Collection point 120 may run on a Linux virtual machine (VM) on a remote server. Collection point 120 may include one or more nodes. For example, collection point 120 may receive burst data 102 directly from data source 101. In another example, collection point 120 may receive burst data 102 from secondary collection point 110. Secondary collection point 110 may transmit burst data 102 to collection point 120 using, for example, a site-to-site protocol. Collection point 120 may include stream processing algorithms. The stream processing algorithms may connect to different processors described herein to transfer data from one source to another and modify the data. For each third-party data producer, collection point 120 may have an independent stream processing algorithm. Each stream processing algorithm may contain a processing group. The processing group may include one or more processors. For example, the one or more processors may retrieve incident data 102 from a relational database. The one or more processors may use the processing API of internal data 103 to initiate API calls to the relational database to retrieve incident data 102 from the incident table. The one or more processors may further transmit incident data 102 to a target system, such as a front-end gateway processor 140. Collection point 120 may encrypt data via HTTPS, mTLS, SSH, PGP, IPsec, and / or SSL. Data formats supported by collection point 120 include, but are not limited to, JSON, CSV, Avro, ORC, HTML, XML, and Parquet. Collection point 120 may be configured to write messages to the cluster of front-end gateway processors 140 and communicate with front-end gateway processors 140.

[0060] Data pipeline system 100 may include a distributed event stream processing platform, such as a front-end gateway processor 140. The front-end gateway processor 140 may be connected to collection point 120 and configured to receive data from collection point 120. The front-end gateway processor 140 may be implemented using an Apache Kafka cluster software system. The front-end gateway processor 140 may include one or more message brokers and corresponding nodes. For example, the message broker may be an intermediate computer program module configured to convert messages from the sender's standard message protocol to the receiver's standard message protocol. The message broker may be deployed on a single node of the front-end gateway processor 140. The message broker of the front-end gateway processor 140 may run on a virtual machine (VM) on a remote server. Collection point 120 may send burst event data 102 to one or more message brokers of the front-end gateway processor 140. Each message broker may contain a topic for storing burst event data 102 of the same category. The topic may be an ordered event log. Each topic may contain one or more subtopics. For example, one subtopic may store incident data 102 related to network issues, while another topic may store incident data 102 related to security vulnerabilities reported by third-party data producers. Each topic may further contain one or more partitions. The partitioning is a systematic way of splitting a topic log file into multiple logs, each of which can be deployed on an independent server. Each partition can be configured to store up to one byte of incident data 102. Each topic can be evenly partitioned across one or more message brokers to achieve load balancing and scalability. The front-end gateway processor 140 can be configured to divide received data into multiple customer categories, thereby forming multiple datasets associated with each customer category. These datasets can be stored separately in storage devices, as described in more detail below. The front-end gateway processor 140 can further transfer data to memory and a processor for further processing.

[0061] For example, the front-end gateway processor 140 can be configured to assign specific data to corresponding topics. Alarm sources can be assigned to alarm topics, incident data can be assigned to incident topics, change data can be assigned to change topics, and problem data can be assigned to problem topics.

[0062] Data pipeline system 100 may include a software framework for data storage 150. Data storage 150 may be configured for long-term storage and distributed processing. Data storage 150 may be implemented using, for example, Apache Hadoop software. Data storage 150 may store burst data 102 transmitted from front-end gateway processor 140. Specifically, data storage 150 may be used for distributed processing of burst data 102, and a Hadoop Distributed File System (HDFS) within the data storage may be used to organize the communication and storage of burst data 102. For example, HDFS may replicate from any node of front-end gateway processor 140. This replication operation may protect against hardware or software failures of front-end gateway processor 140. The processing may be executed simultaneously in parallel on multiple servers.

[0063] Data store 150 may include HDFS configured to receive metadata such as burst event data. Data store 150 may further utilize MapReduce algorithms to process data. MapReduce algorithms can support parallel processing of large datasets. Data store 150 may further utilize another resource coordinator (YARN) to aggregate and store data. YARN can be used for cluster resource management and task planning of the stored data. For example, a cluster computing framework (such as processing platform 160) may be configured to further utilize the HDFS of data store 150. For example, if data source 101 stops providing data, processing platform 160 may be configured to retrieve data from data store 150 directly or via front-end gateway processor 140. Data store 150 can implement distributed processing of large datasets across a computer cluster through a programming model. Data store 150 may include a master node and HDFS for distributing processing tasks among multiple data nodes. The master node may store metadata, such as the number and location of data blocks. The master node may maintain a file system namespace and manage client access to the files. The master node can contain files and directories and perform file system operations such as naming, closing, and opening files. Data storage 150 can scale from a single server to thousands of machines, each providing local computing and storage capabilities. Data storage 150 can be configured to store event data in unstructured, semi-structured, or structured formats. In one example, multiple datasets related to different customer categories can be stored separately. The master node can store metadata, such as the location of the separately stored datasets.

[0064] Data pipeline system 100 may include a real-time processing framework, such as processing platform 160. In one example, processing platform 160 may be a distributed data stream engine without its own storage layer. For example, the processing platform may be the Apache Flink software platform. In another example, the Apache Spark software platform may be used. Processing platform 160 may support stream processing and batch processing. Stream processing may be a type of data processing that performs continuous real-time analysis on received data. Batch processing may involve receiving discrete datasets for processing in batches. Processing platform 160 may include one or more nodes. Processing platform 160 may aggregate burst data 102 received from front-end gateway processor 140 (such as burst data 102 already processed by front-end gateway processor 140). Processing platform 160 may include one or more operators for transforming and processing the received data. For example, a single operator may filter burst data 102 and then connect to another operator to perform further data transformation. Processing platform 160 may process burst data 102 in parallel. A single operator may be deployed on a single node within processing platform 160. The processing platform 160 can be used to filter data and send only the specifically processed data to a specific data receiving layer. For example, depending on the data source of the emergency data 102 (such as whether the data is internal data 103 or third-party data 199), the data can be transmitted to a separate data receiving layer (such as data receiving layer 170 or data receiving layer 171). In addition, before transmitting the data to the data receiving layer, additional data that is not needed by downstream modules (such as artificial intelligence module 180) can be filtered and removed.

[0065] Processing platform 160 can perform three functions. First, processing platform 160 can perform data validation. The values, structure, and / or format of the data can be matched with the destination schema (such as data receiving layer 170). Second, processing platform 160 can perform data transformation. For example, source fields, target fields, functions, and parameters can be extracted from the data. Based on the extracted data functions, a specified transformation operation can be performed. The transformation can reformat the data for downstream specific use. Users can select a specified format for downstream use. Third, processing platform 160 can perform data routing. For example, processing platform 160 can select the shortest and / or most reliable path to send data to the corresponding receiving layer (such as receiving layer 170 and / or receiving layer 171).

[0066] In one example, processing platform 160 can be configured to transmit a specific dataset to the data receiving layer. For example, processing platform 160 can receive input variables from a specific artificial intelligence module 180. Processing platform 160 can then filter the data received from front-end gateway processor 140 and transmit only the data relevant to the input variables of artificial intelligence module 180 to the data receiving layer.

[0067] Data pipeline system 100 may include one or more data receiving layers (such as data receiving layer 170 and data receiving layer 171). Incident data 102 processed by processing platform 160 may be transmitted to and stored in data receiving layer 170. In one example, data receiving layer 171 may be externally stored on a specific client's server. Data receiving layers 170 and 171 may be implemented in software, including but not limited to PostgreSQL, HIVE, Kafka, OpenSearch, and Neo4j. Data receiving layer 170 may receive internal data 103 processed and transmitted by processing platform 160. Data receiving layer 171 may receive third-party data 199 processed and transmitted by processing platform 160. The data receiving layers may be configured to transmit incident data 102 to artificial intelligence module 180. The data receiving layers may be data lakes, data warehouses, or cloud storage systems. Each data receiving layer may be configured to store incident data 102 in structured or unstructured formats. Data receiving layer 170 may store incident data 102 in various formats. For example, the data receiving layer 170 supports data formats including JavaScript Object Notation (JSON), Comma Separated Values ​​(CSV), Avro, Optimized Row-Column Storage (ORC), Hypertext Markup Language (HTML), Extensible Markup Language (XML), and Parquet. The data receiving layer (such as data receiving layer 170 or data receiving layer 171) can be accessed by one or more independent components. For example, the data receiving layer can be accessed by an unstructured query language (“NoSQL”) database management system (such as a Cassandra cluster), a graph database management system (such as a Neo4j cluster), a post-processing program (such as a Kafka+Flink program), and a relational database management system (such as a Postgres cluster). Therefore, post-processing can be performed before the artificial intelligence module 180 receives the processed data.

[0068] Data pipeline system 100 may include an artificial intelligence module 180. The artificial intelligence module 180 may include machine learning components. The artificial intelligence module 180 may train and / or run machine learning models using the received data. For example, the machine learning model may be a neural network. Nevertheless, it should be noted that the artificial intelligence module 180 may employ other machine learning techniques and frameworks to perform the methods covered by this disclosure. For example, the system and methods may be implemented using other types of supervised and unsupervised machine learning techniques, such as regression problems, random forests, clustering algorithms, principal component analysis (PCA), reinforcement learning, or combinations thereof. The artificial intelligence module 180 may be configured to extract and receive data from data receiving layer 170.

[0069] Figure 2An exemplary flowchart 200 is shown, according to one or more embodiments, for aggregating and mapping the features of an emergency to a daily emergency profile. Figure 2 The process / method can be... Figure 1 Data pipeline system 100 and / or Figure 11 The computer system 1100 is implemented.

[0070] In step 202, incident data may be received and filtered. Incident data may include incident reports containing relevant information for each incident, including one or more of the following: incident number, closure date / time, category, closure code, closure notes, detailed description, brief description, root cause, or assigned handling team. Incident data may include incident reports containing relevant information for each incident, including one or more of the following: incident key, description, summary, tag, incident type, fix version, operating environment, creator, or annotation. Incident data may further include the incident cause code, priority, supplementary information, and / or assigned handling team in the text description. Incident data may include incident reports containing relevant information for each incident, including one or more of the following: file name, script name, script type, script description, display identifier, message, submitter type, submitter link, attributes, file change, or branch information. Incident data may include one or more of the following: real-time data, market data, performance data, historical data, utilization data, infrastructure data, or security data. The above are merely examples of information that can be used as data, and this disclosure is not limited to these examples. For example, incident data can include all the above-mentioned feature information in the brief description, including the severity, urgency, complexity, scope of impact, cause of the incident, and / or the configuration item corresponding to the incident (such as the system / platform / product affected by the incident), the description content in the free text, the affected business segment, the affected category / subcategory, and / or the assigned handling team of the incident. For example, feature data of incident data can be extracted from the description content of the incident in this step for subsequent processing. In one example, incident data can be filtered to obtain the identifier, the date and time of the incident, the configuration item (CI) affected by the incident, the brief description of the incident, and the priority level of the incident. All of the above can be saved for subsequent analysis. Configuration item (CI) can refer to: (1) a product; (2) the allocation component of a product; or (3) a system that meets the end-use function, has independent requirements, has functional and / or product association relationships, and / or is designated as independently managed in the configuration management system. When an incident occurs, the incident can correspond to a specific configuration item.

[0071] The data can be further filtered to provide incidents and their corresponding external systems (such as their configuration items). In another example, incident data can be received via one or more computers, servers, and / or handheld mobile devices through electronic networks such as the Internet. These electronic networks can be connected to provide incident data automatically generated by external systems through monitoring tools. These monitoring tools can generate alarm information and incident data to notify of high-risk behaviors and IT environment failures, and the incident data can be generated in the form of work orders.

[0072] After completing step 202, the system described herein (such as system 100) can generate a daily portrait in step 204. For example, step 204 can further... Figure 3A The middle boundary.

[0073] Figure 3A An exemplary method for determining a daily profile of an emergency is shown according to one or more embodiments.

[0074] In step 302, the system (e.g., system 100) can access data from a pipeline (e.g., Figure 1 The data receiving layer 170 receives incident data (such as the data output in step 202). The incident data may include all incident data received within a specific time period. For example, the system may receive incident data over a predetermined period of several months or years. To determine a daily profile, at least one week's worth of incident data needs to be analyzed. The incident data may contain a large number of independent incidents and the characteristics corresponding to each incident. Incident characteristics include, but are not limited to, incident number, incident date and time, brief description of the incident, and priority information. The brief description may be free-format text, recording supplementary information about the incident, such as configuration items (CI), the business affected by the incident, the category and subcategory, and the assigned handling team for the incident.

[0075] In step 304, a set of daily features (such as feature generation) is determined for one or more days. For example, daily features may be core information elements related to emergencies within a day. For example, daily features determined for a specific day may include, but are not limited to: (1) the total number of emergencies per day; (2) the number of unique configuration items (CI) per day; (3) the maximum number of repetitions of configuration items per day; (4) the minimum number of repetitions of configuration items per day; (5) the maximum time interval between openings per day under security control (SEC); (6) the minimum time interval between openings per day under security control; (7) the average time interval between openings per day under security control; (8) the maximum time interval between the same configuration items under security control; (9) the minimum time interval between the same configuration items under security control; (10) the average time interval between the same configuration items under security control; (11) the maximum time interval between unique configuration items under security control; (12) the minimum time interval between unique configuration items under security control; (13) the average time interval between unique configuration items under security control; (14) the percentage of unique configuration items with time delays of (t-1), (t-2)...(t-7). These features can help reflect the nature of incidents received within a day. Configuration items (CI) can refer to configuration items as described above. Security controls (SEC) can refer to security controls and can be measures or processes used to protect configuration items from unauthorized access, use, disclosure, interruption, tampering, or destruction. The features can be extracted from the incident data received in step 302. For example, the information can be extracted from a brief description of each incident, time information, and associated configuration items for each incident. Alternatively, the features can be summarized and determined for daily incident data. This operation can be performed based on the timestamps of the incident data received in step 302, and this process can refer to day-level feature aggregation. For example, Figure 3B It can display 350 charts, where each row on the X-axis represents breaking event data for a specific day, and each column on the Y-axis represents a feature. Figure 3B Chart 350 can be displayed, containing a set of exemplary feature information of the incident data received over twenty-two days. This chart can show the number of records corresponding to each daily feature. Therefore, Chart 350 can display the feature aggregation of a set of exemplary incidents received by the system within twenty-two days.

[0076] In step 306, a first clustering algorithm is executed on the daily features (such as the features corresponding to each day) determined in step 304. In addition to the features obtained in step 304, the number of "emergency cause codes" and the number of X-level priorities associated with all emergencies on that day can be recorded daily, and these can also be aggregated and stored. For example, the first clustering algorithm can be applied to a set of days, using the features obtained in step 304 over multiple days, as well as the emergency cause codes and priority values ​​for a single day.

[0077] For example, the clustering algorithm can be executed by the artificial intelligence module 180. The clustering algorithm can be an unsupervised machine learning algorithm that groups data points based on daily features (e.g., by date). The clustering can calculate the similarity between data points and assign them to corresponding clusters based on this similarity. The clustering algorithms may include, but are not limited to, nearest neighbor propagation, agglomerative hierarchical clustering, balanced iterative reduction and clustering using hierarchical methods (BIRCH), density-based spatial clustering with noise (DBSCAN), Gaussian mixture model (GMM), K-means clustering, mean-shift clustering, mini-batch K-means clustering, identifying cluster structure by point sorting (OPTICS), or spectral clustering. Subsequently, the clustering algorithm can output a set of clusters, wherein a first daily cluster can be generated based on similar features, the cause code of an event within a day, and the number of similar clusters at a predetermined priority level within a day.

[0078] For example, Figure 3C Chart 355 can be displayed. Figure 5 The updated version of Chart 350 in section B includes the assigned clusters for each day determined in step 306. For example, the leftmost column Y can now display the clusters assigned to each day by the clustering algorithm. Therefore, a first daily profile cluster can be assigned to each day.

[0079] For example, step 308 can record the "first daily profile cluster" corresponding to each day. The first daily profile cluster can be a cluster assigned to a specific daily profile. If a day is assigned to the same cluster (such as the same daily profile), it means that the day has similar characteristics (such as the characteristics obtained in step 304). For example, a specific cluster may exhibit characteristics such as a small number of sudden events and a large number of maximum repetitions of configuration items within a day.

[0080] For example, the system can be configured to store and save all days and their corresponding features for a specific cluster. The system can be further configured to calculate the average of each day's features to determine summary information for a specific day's profile.

[0081] Analysis can be performed on each daily profile within a specific historical daily profile cluster. For example, the total number of daily incidents, the total number of unique configuration items, the maximum number of repetitions of configuration items, the minimum time interval between occurrences of the same configuration item within a day, and information extracted from metadata can be extracted for each day within a specific historical daily profile cluster. The above information can be aggregated on a daily basis, and the above averages for each cluster can be determined. Figure 4 An exemplary chart 400 is shown, illustrating the comparison of two days' incident data in the example scenario described in this article.

[0082] The method and system described in this paper can be configured to collect and group daily incident data, and the days can be more accurately categorized and grouped according to the complexity of the incidents.

[0083] Figures 5 to 9 Examples of diagrams that can be output by the systems and devices described herein.

[0084] Figure 5 An exemplary graph 500 output is shown for an exemplary date of a burst event that recurs for a specific configuration item, according to one or more embodiments. Figure 6 An exemplary chart 600 output of a recurring work order for an emergency on an exemplary date is shown, according to one or more embodiments.

[0085] For example, both Chart 500 and Chart 600 can be output by the system described herein. Furthermore, after data reception and processing are completed in step 202, the system can be configured to output Chart 500, which lists all configuration items affected by the incident within a specific day. Also, using the techniques and methods described herein, users can quickly view the configuration items most and least affected within a specific day. The system can be further configured to aggregate multiple reported incidents. For example, it can receive duplicate work orders (such as work orders reporting incidents). The daily profile can be configured to identify and output the number of duplicate work orders with closure codes. For example, duplicate work orders may be generated in the following situations: multiple work orders are created for the same issue, work orders are created for resolved historical issues, and work orders are created for issues outside the scope of IT service management. Furthermore, the Y column of Chart 500 can display exemplary configuration item names, and Chart 600 can display the number of duplicate work orders generated for exemplary configuration items within a day. The X-axis of Chart 600 can contain exemplary closure codes. Configuration item closure codes can indicate the code indicating the reason for resolving an incident involving a specific configuration item. The charts can display incidents that can be ignored at the daily level when reported multiple times (such as incidents reported with corresponding work orders). Therefore, the information generated from the daily profiles can be useful for reviewing IT management systems.

[0086] Figure 7 An exemplary graph 700 output shows the output of a primary trigger alarm for an emergency on an exemplary date, according to one or more embodiments. An alarm may refer to a notification generated by a monitoring system and used to report an emergency. The system described herein can aggregate sent alarm types. The system can aggregate all alarm types received on a specific day and plot this information as a graph or output, as shown in graph 1000.

[0087] Figure 8An exemplary graph 800 output is shown, representing the minimum time interval between incidents with the same configuration item according to one or more embodiments. For example, the minimum time interval may be identified and determined in step 202. This time information may be recorded and a graph generated so that users can review and analyze incident data received within a day.

[0088] Figure 9 An exemplary chart 900 output is shown, representing a high-frequency outbreak on an exemplary date, according to one or more embodiments. For example, this summary information may correspond to the features extracted in step 204. Recurring features within a single day can be plotted and displayed as shown in chart 900.

[0089] Figure 10 Flowchart 1000 shows a method for aggregating and mapping the characteristics of emergencies into daily profiles.

[0090] In step 1002, a set of historical data objects may be received, which indicate one or more occurrences of a set of incidents, each set of incidents being associated with a set of configuration items.

[0091] In step 1004, one or more daily characteristics may be determined for the group of incidents.

[0092] In step 1006, the one or more daily features can be aggregated at the daily level.

[0093] In step 1008, clustering can be performed on the aggregated one or more daily features at the daily level to create one or more daily profile clusters.

[0094] In step 1010, one or more daily portrait clusters may be output.

[0095] Figure 11 A computer system 1100 for performing the techniques described herein is shown according to one or more embodiments of the present disclosure.

[0096] In addition to standard desktop computers and servers, any computer system capable of meeting the required storage and processing needs falls within the scope of this disclosure and is applicable to the various embodiments of this disclosure. Such devices may include tablet devices, smartphones, keypad devices, and other types of computer devices, which may be mobile devices or network-distributed devices (i.e., cloud-based devices).

[0097] Unless otherwise expressly stated, it is evident from the following discussion that the terms “processing,” “operation,” “calculation,” “determination,” and “analysis” used throughout this specification refer to the operation and / or processing of a computer, computing system, or similar electronic computing device, that is, the manipulation and / or conversion of data expressed in the form of physical quantities such as electronic quantities into other data expressed in the same physical quantity form.

[0098] Similarly, the term "processor" can refer to any device or device component that processes electronic data, such as converting electronic data in registers and / or memory into other electronic data that can be stored in registers and / or memory. "Computer," "computing device," "computing platform," "computing apparatus," or "server" can all contain one or more processors.

[0099] Figure 11 Computer system 1100 is illustrated. Computer system 1100 may include a set of executable instructions, by which execution of the instructions enables computer system 1100 to perform any one or more methods or computer-based functions disclosed herein. Computer system 1100 may operate as a standalone device or be connected to other computer systems or peripheral devices via a network or other means.

[0100] In a network deployment scenario, computer system 1100 can operate as a server or client computer in a server-client network environment, or as a peer-to-peer (distributed) computer system in a peer-to-peer (distributed) network environment. Computer system 1100 can also be implemented as or integrated into various devices, such as personal computers (PCs), tablets, set-top boxes (STBs), personal digital assistants (PDAs), mobile devices, handheld computers, laptops, desktop computers, communication devices, cordless phones, landline phones, control systems, cameras, scanners, fax machines, printers, pagers, personal trusted devices, network devices, routers, switches, bridges, or any other machine capable of executing a set of instructions (sequentially or otherwise) to perform a specified machine operation. In one specific embodiment, computer system 1100 can be implemented through an electronic device with voice, video, or data communication capabilities. Furthermore, although a single computer system 1100 is shown, the term "system" also encompasses any system and combination of subsystems that individually or jointly execute one or more sets of instructions to achieve one or more computer functions.

[0101] like Figure 11As shown, computer system 1100 may include processor 1102, such as a central processing unit (CPU), graphics processing unit (GPU), or both. Processor 1102 may be a component of various systems. For example, processor 1102 may be part of a standard personal computer or workstation. Processor 1102 may be one or more general-purpose processors, digital signal processors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), servers, network devices, digital circuits, analog circuits, combinations of the above devices, or other existing and future-developed data analysis and processing devices. Processor 1102 can execute software programs, such as manually written code (i.e., programmable code).

[0102] Computer system 1100 may include memory 1104, which can communicate via bus 1108. Memory 1104 may be main memory, static memory, or dynamic memory, including but not limited to various computer-readable storage media, such as various volatile and non-volatile storage media, including but not limited to random access memory, read-only memory, programmable read-only memory, electrically programmable read-only memory, electrically erasable read-only memory, flash memory, magnetic tape, disk, optical media, etc. In one embodiment, memory 1104 includes cache or random access memory for use by processor 1102. In other embodiments, memory 1104 is independent of processor 1102, such as processor cache, system memory, or other types of memory. Memory 1104 may be an external storage device or database for storing data, such as hard disk, optical disc (CD), digital video disc (DVD), memory card, memory stick, floppy disk, universal serial bus (USB) storage device, or other data storage device. Memory 1104 may store instructions executable by processor 1102. The functions, operations, or tasks shown in the accompanying drawings and described herein can all be implemented by the programmable processor 1102 executing instructions stored in memory 1104. These functions, operations, or tasks are independent of the specific type of instruction set, storage medium, processor, and processing strategy, and can be executed individually or in combination through software, hardware, integrated circuits, firmware, microcode, etc. Accordingly, processing strategies may include multiprocessing, multitasking, parallel processing, etc.

[0103] As shown in the figure, the computer system 1100 may further include a display unit 1110, such as a liquid crystal display (LCD), an organic light-emitting diode (OLED) display, a flat panel display, a solid-state display, a cathode ray tube (CRT), a projector, a printer, or other existing and future-developed display devices for outputting specific information. The display 1110 may serve as an interface for a user to view the operating status of the processor 1102, or specifically as an interface for interfacing with software stored in the memory 1104 or the drive unit 1106.

[0104] Alternatively, computer system 1100 may include input device 1112, which is configured to allow a user to interact with any component of system 1100. Input device 1112 may be a numeric keypad, keyboard, cursor control device (such as a mouse), joystick, touchscreen display, remote control, or other device that can interact with computer system 1100.

[0105] Computer system 1100 may also or alternatively include a disk or optical disk drive unit 1106. Disk drive unit 1106 may include a computer-readable medium 1122, and one or more sets of instructions 1124 (such as software) may be embedded in the computer-readable medium 1122. Furthermore, the instructions 1124 may implement one or more methods or logic described herein. During execution by computer system 1100, the instructions 1124 may reside wholly or partially in memory 1104 and / or processor 1102. Memory 1104 and processor 1102 may also contain the aforementioned computer-readable medium.

[0106] In some systems, computer-readable medium 1122 contains instructions 1124, or receives and executes instructions 1124 in response to propagation signals, enabling devices connected to network 1170 to transmit voice, video, audio, images, or any other data via network 1170. Furthermore, instructions 1124 can be transmitted or received via network 1170 through communication port or interface 1120, and / or via bus 1108. Communication port or interface 1120 may be part of processor 1102 or a separate component. Communication port 1120 may be implemented in software or be a physical connection at the hardware level. Communication port 1120 can be used to connect to network 1170, external media, display 1110, or any other component in system 1100, or combinations thereof. Connection to network 1170 may be a physical connection, such as a wired Ethernet connection, or established wirelessly as described below. Similarly, additional connections to other components of system 1100 may be physical connections or established wirelessly. Alternatively, network 1170 can be directly connected to bus 1108.

[0107] Although computer-readable medium 1122 is indicated as a single medium, the term "computer-readable medium" may include a single medium or multiple media, such as a centralized or distributed database storing one or more sets of instructions, and / or associated caches and servers. The term "computer-readable medium" may also include any medium capable of storing, encoding, or carrying a set of instructions for execution by a processor, or causing a computer system to perform any one or more methods and operations disclosed herein. Computer-readable medium 1122 may be a non-transitory medium and may be a tangible medium.

[0108] Computer-readable medium 1122 may include solid-state memory, such as a memory card or other packaged component integrating one or more non-volatile read-only memories. Computer-readable medium 1122 may be random access memory or other volatile rewritable memory. Alternatively or additionally, computer-readable medium 1122 may include magneto-optical or optical media, such as disks, magnetic tapes, or other storage devices, to capture carrier signals, such as signals transmitted via a transmission medium. Digital files attached to emails, or other independent information files and sets of files, can be considered distribution media belonging to tangible storage media. Accordingly, this disclosure covers any one or more computer-readable media, distribution media, and other equivalent and subsequent alternative media capable of storing data or instructions.

[0109] In another embodiment, dedicated hardware, such as application-specific integrated circuits (ASICs), programmable logic arrays (PLA), and other hardware devices, can be used to implement one or more methods described herein. Applications incorporating the devices and systems described in various embodiments can broadly cover various electronic and computer systems. One or more embodiments described herein can implement related functions through two or more specifically interconnected hardware modules or devices, with related control and data signals transmitted between and via modules, or implemented as part of an ASIC. Accordingly, this system encompasses software, firmware, and hardware implementations.

[0110] Computer system 1100 may be connected to one or more networks 1170. Network 1170 may refer to one or more networks, including wired and wireless networks. Wireless networks may be cellular mobile communication networks, 802.11, 802.16, 802.20, or WiMAX networks. Furthermore, such networks may include public networks (such as the Internet), private networks (such as corporate intranets), or combinations thereof, and may employ various existing or subsequently developed network protocols, including but not limited to TCP / IP-based network protocols. Network 1170 may include direct connections such as wide area networks (WANs, such as the Internet), local area networks (LANs), campus networks, metropolitan area networks, universal serial bus (USB) ports, or any other network capable of enabling data communication. Network 1170 may be configured to connect one computing device to another to enable data interaction between devices. Network 1170 may typically use any form of machine-readable medium to enable information transmission between devices. Network 1170 may include communication methods for transmitting information between computing devices and may be divided into multiple subnetworks. A subnet may allow access to all other components connected to it, or may restrict access permissions between components. Network 1170 may serve as a public or private network connection; for example, it may include a virtual private network, or encryption and other security mechanisms applied over the public Internet.

[0111] According to various embodiments of this disclosure, the methods described herein can be implemented by software programs executable by a computer system. Furthermore, in one exemplary, non-limiting embodiment, the implementation may employ distributed processing, component / object distributed processing, and parallel payment. Alternatively, a virtual computer system processing flow may be constructed to implement one or more of the methods or functions described herein.

[0112] Although this specification describes components and functions that can be implemented in specific implementations with reference to particular standards and protocols, this disclosure is not limited to such standards and protocols. For example, Internet and other packet-switched network transmission standards (such as TCP / IP, UDP / IP, HTML, HTTP, etc.) are typical examples of the prior art. Such standards are periodically replaced by equivalent standards that have essentially the same functionality but are more efficient. Accordingly, alternative standards and protocols that have the same or similar functionality as the standards and protocols disclosed herein are considered equivalent solutions.

[0113] It should be understood that, in one implementation, each step of the method described herein is performed by one or more processors of a processing system (i.e., a computer system) executing instructions (computer-readable code) stored in memory. It should also be understood that the embodiments described herein are not limited to any particular implementation or programming technique, and any suitable technique can be used to implement the functions described herein. Furthermore, the embodiments described herein are not limited to any particular programming language or operating system.

[0114] It should be understood that in the foregoing description of exemplary embodiments, features of the embodiments are sometimes presented in combination in a single embodiment, drawing, or description to simplify this disclosure and aid in understanding one or more inventive concepts. However, this disclosure should not be construed as reflecting an intention that the claimed embodiments require more features than expressly recited in each claim. Rather, as embodied in the following claims, the inventive concept lies in fewer than all the features of the foregoing single disclosed embodiments. Therefore, the claims following the detailed description are hereby expressly incorporated into this detailed description section, each claim constituting an independent embodiment in itself.

[0115] Furthermore, although some embodiments described herein include some but not all features included in other embodiments, those skilled in the art should understand that combinations of features from different embodiments fall within the scope of this disclosure and constitute different embodiments. For example, in the following claims, any claimed embodiments can be used in any combination.

[0116] Furthermore, some embodiments herein are described as methods or combinations of elements thereof, which can be executed by a processor of a computer system or other means of implementing that function. Therefore, a processor equipped with instructions required to execute such methods or method elements constitutes means of executing such methods or method elements. Moreover, the components in the device embodiments described herein are examples of means of implementing the function performed by that component to carry out that function.

[0117] Numerous specific details are set forth in the description provided herein. However, it should be understood that embodiments of this disclosure may be practiced without these specific details. In other instances, well-known methods, structures, and techniques have not been shown in detail to avoid confusion with the understanding of this description.

[0118] Similarly, it should be noted that the term "coupled" in the claims should not be construed as limited to a direct connection; "coupled," "connected," and their derivatives may also be used. It should be understood that these terms are not synonyms. Therefore, the scope of "device A coupled to device B" should not be limited to a device or system where the output of device A is directly connected to the input of device B. That is, there is a path between the output of device A and the input of device B that may include other devices or components. "Coupled" can refer to two or more components having direct physical or electrical contact, or two or more components not in direct contact but still cooperating or interacting with each other.

[0119] Therefore, while the preferred embodiments identified in this disclosure have been described, those skilled in the art will recognize that other further modifications can be made without departing from the spirit of this disclosure, and this disclosure aims to claim protection for all such changes and modifications falling within the scope of this disclosure. For example, any formula given above is merely representative of possible processes. Functions can be added or removed from the block diagram, and operations can be interchanged between functional modules. Steps can be added or removed from the method within the scope of this disclosure.

[0120] The subject matter disclosed above should be considered exemplary and not restrictive, and the appended claims are intended to cover all such modifications, improvements, and other implementations falling within the true spirit and scope of this disclosure. Therefore, to the maximum extent permitted by law, the scope of this disclosure should be determined by the broadest permissible interpretation of the following claims and their equivalents, and should not be limited or restricted by the foregoing specific embodiments. Although various embodiments of this disclosure have been described, it will be apparent to those skilled in the art that further implementations are possible within the scope of this disclosure. Accordingly, this disclosure is not limited except by the appended claims and their equivalents.

Claims

1. A computer-implemented method for aggregating and mapping the characteristics of sudden events into daily profiles, characterized in that, The method includes: Receive a set of historical data objects, which indicate one or more occurrences of a set of incidents, each set of incidents being associated with a set of configuration items; Determine one or more daily characteristics of the set of incidents; Aggregate the one or more daily features at the daily level; Perform clustering on the aggregated one or more daily features at the daily level to create one or more daily profile clusters; and Output one or more daily portrait clusters.

2. The method according to claim 1, characterized in that, The set of historical data objects represents the occurrence of a set of emergencies within at least one month.

3. The method according to claim 1, characterized in that, The one or more daily features include: the total number of daily incidents, the number of unique configuration items received daily for incidents, the maximum number of times configuration items for incidents occur daily, and the minimum number of times configuration items for incidents occur daily.

4. The method according to claim 1, characterized in that, The one or more daily features are extracted from the set of historical data objects.

5. The method according to claim 4, characterized in that, The daily features are extracted from one or more text descriptions, each text description corresponds to a set of incidents, and each incident is associated with the set of configuration items.

6. The method according to claim 1, characterized in that, Aggregating the one or more daily features at the daily level includes summarizing each of the one or more daily features based on the timestamps associated with the set of historical data objects.

7. The method according to claim 1, characterized in that, Aggregating the one or more daily features at the daily level includes determining the number of times each of the one or more daily features occurs on each day of a day or multiple days.

8. The method according to claim 1, characterized in that, Further includes: For each object in the set of historical data objects, determine the cause code and priority of the emergency.

9. The method according to claim 8, characterized in that, At the daily level, clustering is performed on the aggregated one or more daily features to create one or more daily profile clusters, further including: performing the clustering based on the incident cause code and priority of each object in the set of historical data objects.

10. The method according to claim 1, characterized in that, The clustering was performed by an unsupervised machine learning algorithm.

11. A system for aggregating and mapping the characteristics of sudden events into daily profiles, characterized in that, The system includes: A memory, the memory storing processor-readable instructions; and At least one processor is configured to access the memory and execute processor-readable instructions to perform the following operations: Receive a set of historical data objects, which indicate one or more occurrences of a set of incidents, each set of incidents being associated with a set of configuration items; Determine one or more daily characteristics of the set of incidents; Aggregate the one or more daily features at the daily level; Perform clustering on the aggregated one or more daily features at the daily level to create one or more daily profile clusters; and Output one or more daily portrait clusters.

12. The system according to claim 11, characterized in that, The set of historical data objects represents the occurrence of a set of emergencies within at least one month.

13. The system according to claim 11, characterized in that, The one or more daily features include: the total number of daily incidents, the number of unique configuration items received daily for incidents, the maximum number of times configuration items for incidents occur daily, and the minimum number of times configuration items for incidents occur daily.

14. The system according to claim 11, characterized in that, The one or more daily features are extracted from the set of historical data objects.

15. The system according to claim 14, characterized in that, The daily features are extracted from one or more text descriptions, each text description corresponds to a set of incidents, and each incident is associated with the set of configuration items.

16. The system according to claim 11, characterized in that, Aggregating the one or more daily features at the daily level includes summarizing each of the one or more daily features based on the timestamps associated with the set of historical data objects.

17. The system according to claim 11, characterized in that, Aggregating the one or more daily features at the daily level includes determining the number of times each of the one or more daily features occurs on each day of a day or multiple days.

18. The system according to claim 11, characterized in that, Further includes: For each object in the set of historical data objects, determine the cause code and priority of the emergency.

19. The system according to claim 18, characterized in that, At the daily level, clustering is performed on the aggregated one or more daily features to create one or more daily profile clusters, further including: performing the clustering based on the incident cause code and priority of each object in the set of historical data objects.

20. A non-transitory computer-readable medium, characterized in that, The medium stores processor-readable instructions, which, when executed by at least one processor, cause the at least one processor to perform the following operations: Receive a set of historical data objects, which indicate one or more occurrences of a set of incidents, each set of incidents being associated with a set of configuration items; Determine one or more daily characteristics of the set of incidents; Aggregate the one or more daily features at the daily level; Clustering is performed on the aggregated one or more daily features at the daily level to create one or more daily profile clusters; and Output one or more daily portrait clusters.

Images