Abstract: Novel tools and techniques are provided for implementing intelligent alert automation (“IAA”). In various embodiments, IAA receives alert/event feeds from several different alerting and ticketing systems via input Redis queues, and uses a triage system to determine whether to process the alert/event or disregard it. If so, IAA may create a flow instance, assign a unique instance ID, and place the flow instance in one of a plurality of jobs queues based on alert/event type and/or or source. An abattoir system retrieves a flow instance from one of the jobs queues (in order of the queue's priority), and processes the next node or step in the flow instance. The flow instance is placed back into the jobs queue for subsequent processing by the same or different abattoir system until no additional nodes or steps remain in the flow, at which point the flow instance is considered complete.

Abstract: Novel tools and techniques are provided for implementing real-time fault management or real-time fault management system (“RFM”). In various embodiments, RFM may receive alerts from or associated with network devices (e.g., layer 2, 3, and/or 4 devices, or the like) that are disposed in a plurality of disparate networks that may utilize different alert management protocols and/or different fault management protocols. RFM may collect, enrich, normalize, aggregate, and display the alerts in a user interface to facilitate addressing of the alerts by a user. To enable continuous and real-time functionality, RFM may be implemented in a plurality of siloed platforms in a primary data center, with processing of alerts being load balanced across the siloed platforms, with mirrored group of siloed platforms in a secondary data center located geographically distant from the primary data center and configured to be on “hot standby” and to completely take over RFM processing operations.

Abstract: Novel tools and techniques are provided for implementing dashboard for alert storage and history (“DASH”). In various embodiments, DASH provides for consolidated tracking and monitoring of two or more of current (or active) alerts, cleared alerts, and/or transactional information for alerts that are stored within corresponding alert live database that mirrors current alert instance data in a real-time fault management system, alert history database that contains a snapshot of an alert history of each alert or corresponding network device, and/or alert log database that contains a full transaction record of every copy of an alert either over a first duration or having a total data size within a first total data size. DASH also cleans received alert data and/or enriches the alert data, and provides a user interface (“UI”) that enables a user to view, absorb, filter, manage, and/or organize alert data to facilitate addressing of alerts in the network(s).

Abstract: Novel tools and techniques are provided for implementing real-time fault management or real-time fault management system (“RFM”). In various embodiments, RFM may receive alerts from or associated with network devices (e.g., layer 2, 3, and/or 4 devices, or the like) that are disposed in a plurality of disparate networks that may utilize different alert management protocols and/or different fault management protocols. RFM may collect, enrich, normalize, aggregate, and display the alerts in a user interface to facilitate addressing of the alerts by a user. To enable continuous and real-time functionality, RFM may be implemented in a plurality of siloed platforms in a primary data center, with processing of alerts being load balanced across the siloed platforms, with mirrored group of siloed platforms in a secondary data center located geographically distant from the primary data center and configured to be on “hot standby” and to completely take over RFM processing operations.

Abstract: Novel tools and techniques are provided for implementing intelligent alert automation (“IAA”). In various embodiments, IAA receives alert/event feeds from several different alerting and ticketing systems via input Redis queues, and uses a triage system to determine whether to process the alert/event or disregard it. If so, IAA may create a flow instance, assign a unique instance ID, and place the flow instance in one of a plurality of jobs queues based on alert/event type and/or or source. An abattoir system retrieves a flow instance from one of the jobs queues (in order of the queue's priority), and processes the next node or step in the flow instance. The flow instance is placed back into the jobs queue for subsequent processing by the same or different abattoir system until no additional nodes or steps remain in the flow, at which point the flow instance is considered complete.

Abstract: Novel tools and techniques are provided for implementing dashboard for alert storage and history (“DASH”). In various embodiments, DASH provides for consolidated tracking and monitoring of two or more of current (or active) alerts, cleared alerts, and/or transactional information for alerts that are stored within corresponding alert live database that mirrors current alert instance data in a real-time fault management system, alert history database that contains a snapshot of an alert history of each alert or corresponding network device, and/or alert log database that contains a full transaction record of every copy of an alert either over a first duration or having a total data size within a first total data size. DASH also cleans received alert data and/or enriches the alert data, and provides a user interface (“UI”) that enables a user to view, absorb, filter, manage, and/or organize alert data to facilitate addressing of alerts in the network(s).

Abstract: Novel tools and techniques are provided for implementing dashboard for alert storage and history (“DASH”). In various embodiments, DASH provides for consolidated tracking and monitoring of two or more of current (or active) alerts, cleared alerts, and/or transactional information for alerts that are stored within corresponding alert live database that mirrors current alert instance data in a real-time fault management system, alert history database that contains a snapshot of an alert history of each alert or corresponding network device, and/or alert log database that contains a full transaction record of every copy of an alert either over a first duration or having a total data size within a first total data size. DASH also cleans received alert data and/or enriches the alert data, and provides a user interface (“UI”) that enables a user to view, absorb, filter, manage, and/or organize alert data to facilitate addressing of alerts in the network(s).

Abstract: Novel tools and techniques are provided for implementing intelligent alert automation (“IAA”). In various embodiments, IAA receives alert/event feeds from several different alerting and ticketing systems via input Redis queues, and uses a triage system to determine whether to process the alert/event or disregard it. If so, IAA may create a flow instance, assign a unique instance ID, and place the flow instance in one of a plurality of jobs queues based on alert/event type and/or or source. An abattoir system retrieves a flow instance from one of the jobs queues (in order of the queue's priority), and processes the next node or step in the flow instance. The flow instance is placed back into the jobs queue for subsequent processing by the same or different abattoir system until no additional nodes or steps remain in the flow, at which point the flow instance is considered complete.

Abstract: Novel tools and techniques are provided for implementing real-time fault management or real-time fault management system (“RFM”). In various embodiments, RFM may receive alerts from or associated with network devices (e.g., layer 2, 3, and/or 4 devices, or the like) that are disposed in a plurality of disparate networks that may utilize different alert management protocols and/or different fault management protocols. RFM may collect, enrich, normalize, aggregate, and display the alerts in a user interface to facilitate addressing of the alerts by a user. To enable continuous and real-time functionality, RFM may be implemented in a plurality of siloed platforms in a primary data center, with processing of alerts being load balanced across the siloed platforms, with mirrored group of siloed platforms in a secondary data center located geographically distant from the primary data center and configured to be on “hot standby” and to completely take over RFM processing operations.

Abstract: A method and system for training and applying at least two neural networks for matching prospective students to institutions is disclosed This method and system enhances access to high-quality, affordable postsecondary education by predicting the likelihood of success that a given student will have at an institution. This is accomplished by predicting the similarity between a student and institution alumni on both objective and subjective criteria.