AIOps 2.2 introduces new features leveraging AI for auto resolution of tickets and similarity checks in correlation rules. The release also focuses on redefining the alert and ticket life cycle in AIOps while introducing flexibility to customize the labels for alert and ticket states.
This release also introduces enhancements in ticket templates, rule operators and ITSM integration configuration for faster customer on boarding.
Contents
AIOps 2.2 introduces AI enabled automatic resolution of tickets. This is powered by SmartOps Conversation Designer, Rule Engine and Automation Story. SmartOps Conversation Designer’s NER capability is used to detect the intent of a ticket and to extract entities required for resolving the ticket. Automation Story capability is leveraged to run an automated workflow for resolving the ticket with the details extracted from the ticket as inputs.
A new tab called Automation is available in AIOps for setting up Auto Resolutions. All the intents created in SmartOps conversation designer as well as the Automation Stories created for AIOps (tagged with #autoresolve) in SmartOps is listed. An admin can set-up an Auto Resolution by mapping an intent to an Automation Story.
While creating an Auto Resolution, the user defined inputs required for the Automation Story must be mapped to the entities extracted from the ticket. An admin should also configure the minimum confidence score for intent detection for the Auto Resolution to be triggered.
Users can also view details like average confidence scores for intents and total number of intent detections for analysis.
Users can now use ‘similar’ as an option in similarity criteria of correlation rules. This uses an AI based similarity check to determine semantic similarity between sentences. With this addition, three options are currently available in similarity criteria of correlation rules.
Identical - looks for exact match between values of the selected alert attribute
Empty - looks for values which are blank, for selected alert attribute
Similar by N% - looks for N% of semantic similarity between values of selected alert attribute.
For example, the following alert messages will be treated as similar by using the ‘similar by 80%’ option in similarity criteria. Using this option will allow more alerts to be correlated into a cluster effectively.
Jitter Threshold of IPSLA Operation "UDP Jitter - NewYork Office XYZT - London LD6 RDZ1 (MPLS - Data) on Node ABCDEF-03A-RDZ1 is in Up state with value is 1 milliseconds |
RTT/Latency Threshold of IPSLA Operation "UDP Jitter - NewYork Office XYZT - London LD6 RDZ1 (Internet - Data) on Node ABCDEF-03A-RDZ1 is in Up state with value 151 milliseconds |
Jitter Threshold of IPSLA Operation "UDP Jitter - NewYork Office XYZT - London LD6 RDZ1 (Internet - Data) on Node ABCDEF-03A-RDZ1 is in Up state with value is 1 milliseconds |
Since this option looks for semantic similarity; it works best when used for larger text which also has context – for example alert description or alert message. For alert attributes like resource name, alert source, etc. which do not show a semantic relation, it is recommended to use operators like CONTAINS, IDENTICAL, EMPTY etc.
To add similarity based correlation, follow the steps mentioned below:
Navigate to Infrastructure, click Configuration tab. This displays the Alert Configuration Policy screen as shown in FigureFigure.
To edit the policies, click on icon corresponding to the policy.
To delete a policy, click on icon corresponding to the policy.
To update the status, toggle the Status bar as required.
To add a new correlation policy, click on This displays the Add Correlation Policy screen as shown in FigureFigure.
Define the correlation policy.
To save and add rule for the policy, click Save and Add Rule. This displays the Set Rules block as shown in FigureFigure.
Define the rules for the correlation policy.
To add similarity correlation, select the required attribute and corresponding Operator.
To add more similarity correlation, click on the icon.
Operators available are, Similar, Equals, and Empty.
To save the rule and add a new rule, click on Save and Add New Rule.
To activate the rule, enable the Activate Rule option.
Defined Alert cluster states, ticket states and next actions, with configurable labels
AIOps 2.2 introduces defined states and next possible actions, for both alert clusters and tickets. Each state and action can be given a custom label by an ITOps admin. This allows flexibility to customize the state and action labels for different customers.
For example, the state when an alert cluster is ticketed and assigned to a virtual engineer can be labeled as ‘Open’ for one customer and ‘Active-VE’ for another customer.
The default life cycle for alert cluster states and ticket states in AIOps will be defined as below, using label configuration. The default states for alert clusters will be - OPEN, ACKNOWLEDGED, ACTIVE, ON HOLD and RESOLVED. The default states for tickets will be - OPEN, ACTIVE, ON HOLD and RESOLVED.
Alert states |
Default label |
New alert , Not ticketed yet |
OPEN |
Correlated, Waiting for Acknowledgement |
|
Orphan, Correlated |
|
Correlation Incomplete |
|
Ticketed, Not Assigned |
|
Waiting for first assignment |
|
First Assignment , Internal Team |
|
First Assignment , External Team |
|
Assigned to Virtual Engineer |
ACTIVE |
Assigned to an Engineer |
|
Was assigned to an Engineer, Currently unassigned and with internal team |
|
Was assigned to an Engineer, Currently unassigned and with external team |
|
Was assigned earlier, Currently unassigned |
|
Acknowledged Cluster |
ACKNOWLEDGED |
Never assigned, Currently on Hold |
ON HOLD |
Was assigned earlier, Currently on Hold |
|
Ticket resolved manually |
RESOLVED |
Viewed recommended resolutions and resolved manually |
|
Recovery alert received and AIOPS closed the ticket |
Ticket States |
Default Label |
Not Assigned to a team or a member |
OPEN |
First Assignment , Internal Team |
|
First Assignment , External Team |
|
Assigned to Virtual Engineer |
ACTIVE |
Assigned to an Engineer |
|
Was assigned but currently unassigned |
|
Was assigned but currently unassigned and with internal team |
|
Was assigned but currently unassigned and with external team |
|
Was never assigned, Currently On Hold |
ON HOLD |
Was assigned to an Engineer, Currently On Hold |
|
Ticket Resolved manually |
RESOLVED |
Ticket Resolved manually after Reviewing Recommendations |
|
Ticket resolved by AIOPS after Recovery alert |
The actions available from each state is also defined. Below are the next possible actions from the default alert and ticket states. The labels for actions can be configured by an AIOps admin.
Open |
Acknowledge |
Resolve |
|
Assign |
|
Hold |
|
Active |
Assign |
Hold |
|
Resolve |
|
Recommended Resolution |
|
On Hold |
Assign |
Remove Hold |
|
Resolved |
|
Default ticket states and actions |
|
Open |
Assign |
Hold |
|
Active |
Assign |
Hold |
|
Resolve |
|
Recommended Resolution |
|
On Hold |
Assign |
Remove Hold |
|
Resolved |
|
New operators in policies and rules (ENH)
Two new operators ‘CONTAINS IN’ and ‘EXACT IN’ is available in the list of operators for rule and policy creation. Both these operators accepts multiple values which are comma separated.
"CONTAINS IN" will look for presence of anyone among the comma separated values, in the attribute.
"EXACT IN" will look for exact match of the attribute value with any one among the comma separated values.
ITSM time format in project config (ENH)
From this release, all updates for time field in ITSM will be made in the time zone specified in the Project Specific Time Zone setting. UTC is the default time zone unless otherwise specified in the project settings. Please note that the change is applied for the fields in ITSM corresponding to time data and any time information contained in any other field (like alert description) sill continues to be in UTC.
To specify the time zone, follow the steps mentioned below:
Navigate to Project Configuration tab in Create New Project/Edit Project.
Select the required time zone from ITSM Configuration block.
Ticket template enhancements (ENH)
In this release, ticket templates are introduced in one more ticket update scenario - ‘add new correlated alert into ticketed alert cluster’. With this, admins can now customize the ticket updates in this scenario using ticket template. This is an optional template and needs to be set up only if customization is required.
Also, the options available to AIOps admins is expanded, while using ticket templates. Admins can now refer to base alert, ticketing alert or alert cluster attributes in ticket templates. This feature is available in templates for ticket create and ticket correlate scenarios. For example, during ticket creation, the ticket impact field in ITSM can be updated based on the severity of the alert cluster.