Smart Resiliency Module for Automated Application Self-Healing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional monitoring systems fail to automatically resolve application failures and degradements, leading to undetected intermittent issues and customer impacts, as they lack automatic fail-over and self-healing capabilities, requiring manual scripting for each application, database, and storage, which is time-consuming and inconsistent across platforms.
Innovation Solution
A platform and language agnostic smart resiliency module that creates a workflow-based plug and play framework for automatic script execution, monitoring health thresholds, and triggering API calls to collect and fix issues, enabling self-healing processes and fail-over to new availability zones, with data orchestration in JSON, XML, or YAML formats.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional monitoring systems are used to detect application failures, then detection capability is provided, but automatic resolution capability is lacking
Solution Approach 1:
The system enables self-service automation by having the monitoring system automatically trigger and execute fail-over scripts when failures are detected, eliminating the need for manual intervention. The workflow engine automatically manages the entire fail-over process from detection to execution, making the system self-resolving rather than requiring human operators.
Solution Approach 2:
The system implements preliminary action by pre-configuring fail-over scripts and workflows in advance. When a failure is detected, the pre-prepared automation workflows are immediately triggered and executed, enabling rapid automatic response without needing to create or configure scripts at the moment of failure.
2Reliability
If separate scripts are created for each application, database, and storage to satisfy data center migration rules, then resiliency compliance is achieved, but consistency and development time are compromised
Solution Approach 1:
The system implements a universal workflow engine that can execute the same fail-over automation across multiple different applications, databases, and storage systems. Instead of creating separate custom scripts for each component, a single unified workflow framework handles all fail-over scenarios consistently, reducing development effort while maintaining compliance.
Solution Approach 2:
The system segments the fail-over process into standardized, reusable workflow components that can be independently configured and executed. By breaking down the automation into modular segments (detection, decision, execution, verification), the system can apply consistent patterns across different applications without requiring complete separate script development for each one.
3Productivity
If conventional monitoring systems notify issues but do not automatically resolve them, then monitoring capability is provided, but customer impact is increased
Solution Approach 1:
The system implements continuous feedback loops where the monitoring system constantly checks application health, automatically triggers fail-over workflows when thresholds are breached, and verifies resolution status. This closed-loop feedback mechanism ensures rapid detection and automatic resolution, minimizing customer impact by continuously monitoring and responding to failures in real-time.
Solution Approach 2:
The system maintains continuous monitoring and automatic response capabilities without interruption. The workflow engine operates continuously, constantly evaluating system health and immediately executing fail-over actions when needed, ensuring uninterrupted protection against failures rather than periodic or manual checks.
Data Source
AI summary
Various methods, apparatuses/systems, and media for automatically fixing health of a certain component of an application are disclosed. A processor sets a corresponding predetermined threshold value for health of each component of a plurality of components of an application required for running the application; constantly monitors health of the plurality of components. When it is determined, in response to constantly monitoring, that the health of a certain component has reached to a value that is equal to the corresponding predetermined threshold value of the certain component, the processor automatically calls corresponding application programming interface (API) to trigger automated processes that includes collecting all necessary data corresponding to fixing of the health of the certain component related to the application from a plurality of data sources; creating a data file on demand that includes the necessary data; and fixing the health of the certain component based on the data file.