Automated Self-Healing Server Rotation for Rapid Repair

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In large-scale computing systems, managing and maintaining hundreds of servers is challenging due to issues like power outages, memory leaks, and software crashes, which can disrupt services and are difficult to address promptly without degrading performance.

Innovation Solution

An automated self-healing system that monitors performance metrics, identifies at-risk messaging servers, and initiates repairs by removing them from rotation, validating the repairs, and reintegrating them once completed, ensuring minimal disruption to front-end applications.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If manual monitoring and repair of servers is performed, then system reliability can be maintained through human intervention, but the response time is slow (hours or days) and service disruption occurs

Engineering Contradiction:
Improvesystem reliabilityVSAvoidresponse time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system implements automated self-healing capabilities where the computer automatically detects server issues, removes problematic servers from rotation, initiates repairs, validates repairs through API calls, and reintegrates servers without human intervention. This self-service approach reduces response time from hours or days to seconds or minutes while maintaining system reliability.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system performs preliminary actions by continuously monitoring server performance metrics and proactively identifying at-risk servers before complete failure occurs. The automated system prepares repair actions in advance and executes them immediately upon detecting issues, preventing service disruption rather than responding after failure.

Inventive Principle:
Principle #10Preliminary action

2Stability of the object's composition

If servers are taken offline for repair, then system stability is maintained by removing faulty components, but service availability decreases during the repair process

Engineering Contradiction:
Improvesystem stabilityVSAvoidservice availability
Core Design Contradiction:
Stability of the object's compositionVSProductivity

Solution Approach 1:

The system maintains continuity of useful action by keeping multiple servers in rotation so that when one server is removed for repair, other servers continue to handle requests. The automated repair process occurs in the background while the system continues to operate, and the repaired server is quickly reintegrated to restore full capacity, minimizing service availability impact.

Inventive Principle:
Principle #20Continuity of useful action

Solution Approach 2:

The system temporarily discards faulty servers from the active rotation to maintain stability, then quickly recovers them through automated repair processes. The discarded servers are restored and reintegrated into service, maximizing their utilization while maintaining system stability during the repair window.

Inventive Principle:
Principle #34Discarding and recovering

3Loss of time

If automated repair processes are implemented, then response time is reduced from hours to seconds, but system complexity increases due to additional monitoring and validation mechanisms

Engineering Contradiction:
Improverepair timeVSAvoidsystem complexity
Core Design Contradiction:
Loss of timeVSDevice complexity

Solution Approach 1:

The automated repair system implements multi-functional components that perform multiple tasks: monitoring server performance metrics, detecting issues, removing servers from rotation, initiating repairs, validating repairs through API calls, and reintegrating servers. This universal approach consolidates what would otherwise require separate systems into a unified automated process, managing complexity while achieving rapid response times.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system implements continuous feedback loops where server performance metrics are monitored, issues are detected, repair actions are executed, and validation is performed through API calls to confirm successful repair. This feedback mechanism enables automated decision-making and rapid response without requiring complex human intervention protocols.

Inventive Principle:
Principle #23Feedback

4Productivity

If multiple servers are kept in rotation for load balancing, then service availability is maintained, but the risk of having at-risk servers affects overall system performance

Engineering Contradiction:
Improveservice availabilityVSAvoidsystem performance
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The automated monitoring system continuously self-evaluates server health by monitoring performance metrics and automatically identifies at-risk servers in the rotation. This self-service approach ensures that servers maintaining the rotation are healthy, preserving both service availability and system performance without manual intervention.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system implements continuous feedback monitoring of server performance metrics to detect at-risk servers before they fail. This feedback mechanism allows the system to proactively remove problematic servers from the rotation, maintaining high service availability while ensuring only healthy servers handle requests, thus preserving overall system performance.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS9367379B1Automated self-healing computer system
Publication Date: 2016.06.14 T MOBILE INNOVATIONS LLC
  • US9367379B1 patent drawing
  • US9367379B1 patent drawing
  • US9367379B1 patent drawing

AI summary

A server. The server comprises a processor, a memory, and an application that receives an alert message corresponding to an error and a performance metric value in a messaging server, wherein the messaging server is one of a plurality of servers in a rotation that supports a front-end application in a system, identifies a course of action for repair, determines that the number of active servers in the rotation is above a predefined threshold number of active servers, removes the messaging server from the rotation, notifies a system administrator of the removal, the identified error, and the performance metric value, repairs the messaging server by implementing the identified course of action, validates the messaging server by running application programming interface (API) calls, places the repaired messaging server in the rotation, and notifies the system administrator of repair details and API call results.