This section outlines the sequence of Escalation and Remediation tasks and lists the different components that are interacting with the VMware Telco Cloud Service Assurance.

Escalation steps in VMware Telco Cloud Service Assurance is as follows:

  1. From the Rules UI, a user should have a list of escalation policy with create, update, and delete options
  2. An escalation policy can have multiple escalation paths. Each escalation path must have one condition defined based on which the path will be executed. Each escalation path includes a list of remediation actions (mapped to the existing remediation actions from the Actions UI or instinctively creating a remediation action that will be added to the available remediations).

    For example, if the certainty of the event is between x and y, create a service ticket. If the certainty is between y and z, create a critical jira ticket and send a notification to a slack channel of network adminstrators. If the certainty is between z and 100, trigger the VMware Telco Cloud Automation Heal Life Cycle Action.

  3. Users can split the escalation path from level 0 through level 5. Each level includes an action.
  4. Each level will have a custom time delay that must expire before moving to the next level.
  5. The user must define how to stop the escalation.
  6. When an event matches the Escalation Rule, a policy is triggered in the backend and you can see the Escalation status in the Tasks UI.
Remediation steps in VMware Telco Cloud Service Assurance is as follows:
  1. From the Rules UI, a new Remediation Rule is created, and the Rules UI is integrated with the events to provide all the known root causes and Anomaly events. You can pick any of the events and create a rule entry to remediate that event.
  2. Once the rule is created and activated (generally it takes 5 to 10 mins post creation), the evaluator in the policy engine starts monitoring the events for any matching criteria.
  3. Once the policy engine evaluates the events and identifies a rule that has been activated against the event, it triggers the policy application by invoking the tasks in underlying actions configured inside remediation rule.
  4. Once an action is complete, the UI notification is generated with the details of the action and its result.
  5. In addition to automated rule-based remediation, end users can also trigger actions from the notification UI. Each notification entry in the UI is provided with an option to trigger some actions manually without need for any rules to be created.
  6. The result of an action is reported back to the notification UI.