Abstract: A self-managing database system includes a metrics collector to collect metrics data from one or more databases of a computing system and an anomaly detector to analyze the metrics data and detect one or more anomalies. The system includes a causal inference engine to mark one or more nodes in a knowledge representation corresponding to the metrics data for the one or more anomalies and to determine a root cause with a highest probability of causing the one or more anomalies using the knowledge representation. The system includes a self-healing engine, to take at least one remedial action for the one or more databases in response to determination of the root cause.

Abstract: A self-managing database system includes a metrics collector to collect metrics data from one or more databases of a computing system and an anomaly detector to analyze the metrics data and detect one or more anomalies. The system includes a causal inference engine to mark one or more nodes in a knowledge representation corresponding to the metrics data for the one or more anomalies and to determine a root cause with a highest probability of causing the one or more anomalies using the knowledge representation. The system includes a self-healing engine, to take at least one remedial action for the one or more databases in response to determination of the root cause.

Abstract: A self-managing database system includes a metrics collector to collect metrics data from one or more databases of a computing system and an anomaly detector to analyze the metrics data and detect one or more anomalies. The system includes a causal inference engine to mark one or more nodes in a knowledge representation corresponding to the metrics data for the one or more anomalies and to determine a root cause with a highest probability of causing the one or more anomalies using the knowledge representation. The system includes a self-healing engine, to take at least one remedial action for the one or more databases in response to determination of the root cause.

Abstract: Instances of an application pod may be deployed to many different computing environments spanning native cloud installations, SaaS providers, and on-premise data centers. In order to make uniform changes to a distribution of an application pod, a lock manager may receive and schedule lock requests from many different types of utilities. These utilities may schedule exclusive locks on the application pod throughout the different computing environments, such that patches, updates, security protocols, and other changes may be instituted without interference from changes made concurrently by other utilities. The lock manager may schedule immediate and future locks, with lock extensions and lock overrides available for flexibility.

Abstract: A self-managing database system includes a metrics collector to collect metrics data from one or more databases of a computing system and an anomaly detector to analyze the metrics data and detect one or more anomalies. The system includes a causal inference engine to mark one or more nodes in a knowledge representation corresponding to the metrics data for the one or more anomalies and to determine a root cause with a highest probability of causing the one or more anomalies using the knowledge representation. The system includes a self-healing engine, to take at least one remedial action for the one or more databases in response to determination of the root cause.

Abstract: A system enables initiation of request driven peak-hour builds to override “off-peak” patching schedules for updating server applications. An “off-peak” patching schedule is generated to minimize disruption from installing builds of patches. Notwithstanding the “off-peak” patching schedule, a tenant administrator initiates request driven peak-hour builds when some performance failure occurs during peak business hours. For example, the tenant administrator may generate a service request that includes incident data that is usable to identify and/or develop a particular patch for resolving the performance failure. Based on the service request, the “off-peak” patching schedule is overridden to expedite an out-of-sequence installation of a particular patch. In this way, a tenant administrator that becomes aware that some performance failure is disrupting information workers during a peak usage time-range (e.g.

Abstract: In non-limiting examples of the present disclosure, systems, methods and devices for monitoring telemetry data from a cloud-based application service are presented. Telemetry data for a plurality of operations for the cloud-based application service may be analyzed, wherein the analysis comprises comparing a first time series with a second time series, and where data from the second time series relates to operations that were executed prior in time compared with execution of operations related to the first time series. One or more operational changes in the cloud-based application service may be identified based on the analysis, and at least one telemetry monitor may be dynamically configured based on the one or more operational changes that were identified.

Abstract: In non-limiting examples of the present disclosure, systems, methods and devices for monitoring telemetry data from a cloud-based application service are presented. Telemetry data for a plurality of operations for the cloud-based application service may be analyzed, wherein the analysis comprises comparing a first time series with a second time series, and where data from the second time series relates to operations that were executed prior in time compared with execution of operations related to the first time series. One or more operational changes in the cloud-based application service may be identified based on the analysis, and at least one telemetry monitor may be dynamically configured based on the one or more operational changes that were identified.

Abstract: A system enables initiation of request driven peak-hour builds to override “off-peak” patching schedules for updating server applications. An “off-peak” patching schedule is generated to minimize disruption from installing builds of patches. Notwithstanding the “off-peak” patching schedule, a tenant administrator initiates request driven peak-hour builds when some performance failure occurs during peak business hours. For example, the tenant administrator may generate a service request that includes incident data that is usable to identify and/or develop a particular patch for resolving the performance failure. Based on the service request, the “off-peak” patching schedule is overridden to expedite an out-of-sequence installation of a particular patch. In this way, a tenant administrator that becomes aware that some performance failure is disrupting information workers during a peak usage time-range (e.g.

Abstract: A support data generation system detects an indication of a problem within a flighted infrastructure. Based on the detected indication, a feature undergoing implementation within the flighted infrastructure is identified. The identification occurs automatically after the indication is detected. An alert comprises the detected indication and the identified feature is generated and output on a user interface.

Abstract: A system enables initiation of request driven peak-hour builds to override “off-peak” patching schedules for updating server applications. An “off-peak” patching schedule is generated to minimize disruption from installing builds of patches. Notwithstanding the “off-peak” patching schedule, a tenant administrator initiates request driven peak-hour builds when some performance failure occurs during peak business hours. For example, the tenant administrator may generate a service request that includes incident data that is usable to identify and/or develop a particular patch for resolving the performance failure. Based on the service request, the “off-peak” patching schedule is overridden to expedite an out-of-sequence installation of a particular patch. In this way, a tenant administrator that becomes aware that some performance failure is disrupting information workers during a peak usage time-range (e.g.

Abstract: Methods and systems for managing a flighted software feature. One embodiment provides a system for disabling a flighted software feature enabled for selected users in a computing environment. The system includes a memory storing instructions and an electronic processor coupled to the memory. The electronic processor configured to execute the instructions to determine a set of related service requests submitted by a plurality of users in the computing environment, and, for each of the plurality of users, query a server servicing the user for a list of flighted software features enabled for the user during a predetermined time period. The electronic processor is also configured to determine, based on the list of flighted software features enabled for each of the plurality of users during the predetermined time period, a common flighted software feature, and automatically disable the common flighted software feature for at least one of the plurality of users.

Abstract: A system enables initiation of request driven peak-hour builds to override “off-peak” patching schedules for updating server applications. An “off-peak” patching schedule is generated to minimize disruption from installing builds of patches. Notwithstanding the “off-peak” patching schedule, a tenant administrator initiates request driven peak-hour builds when some performance failure occurs during peak business hours. For example, the tenant administrator may generate a service request that includes incident data that is usable to identify and/or develop a particular patch for resolving the performance failure. Based on the service request, the “off-peak” patching schedule is overridden to expedite an out-of-sequence installation of a particular patch. In this way, a tenant administrator that becomes aware that some performance failure is disrupting information workers during a peak usage time-range (e.g.

Abstract: Methods and systems for managing a flighted software feature. One embodiment provides a system for disabling a flighted software feature enabled for selected users in a computing environment. The system includes a memory storing instructions and an electronic processor coupled to the memory. The electronic processor configured to execute the instructions to determine a set of related service requests submitted by a plurality of users in the computing environment, and, for each of the plurality of users, query a server servicing the user for a list of flighted software features enabled for the user during a predetermined time period. The electronic processor is also configured to determine, based on the list of flighted software features enabled for each of the plurality of users during the predetermined time period, a common flighted software feature, and automatically disable the common flighted software feature for at least one of the plurality of users.

Abstract: Aspects of the present disclosure relate to systems and methods for dynamically updating in-app help to reflect help content associated with submitted issues. In one aspect, submitted issues data categorized by issue topics associated with a service is received. An active summary of the submitted issues data is generated for presentation in a control panel. The active summary may indicate at least one issue topic category having a highest number of submitted issues within a time span. Help content associated with the at least one issue topic category having the highest number of submitted issues within the time span may be sent to the service for updating an in-app help pane of an application associated with the service to reflect the help content.

Abstract: A support data generation system detects an indication of a problem within a flighted infrastructure. Based on the detected indication, a feature undergoing implementation within the flighted infrastructure is identified. The identification occurs automatically after the indication is detected.