Evaluating Your Business Processes and Customizing Events

Before using SL1 to manage event escalation, your organization must include certain business processes or standard operating procedures:

Collect and identify critical, major, and minor events.
Customize events, if necessary, to meet business requirements, such as service level agreements (SLAs).
Identify the technical and business units that should be involved in event escalation.

These tasks are described in this section.

Use the following menu options to navigate the SL1 user interface:

To view a pop-out list of menu options, click the menu icon ().
To view a page containing all of the menu options, click the Advanced menu icon ().

Identifying Critical, Major, and Minor Events

Before you can define the escalation procedures for your enterprise, you must determine the severity of events. If you are already using SL1, you can use the Events page to collect information about events. You can also examine existing incident records (from outside the system).

In SL1, events are categorized by severity:

Critical Events indicate a condition that can seriously impair or curtail service and require immediate attention (such as service or system outages).
Major Events indicate a condition that impacts service and requires immediate investigation.
Minor Events indicate a condition that does not currently impair service, but needs to be corrected before it becomes more severe.
Notice Events indicate a condition that does not affect service but about which users should be aware.
Healthy Events indicate that a device or condition has returned to a healthy state. Frequently, a healthy event is generated after a problem has been fixed.

To determine the severity of an event to your enterprise, ask yourself the following questions about each targeted event:

Is there service degradation?

What levels of degradation are considered Critical? Major? Minor?

Is there an impact on crucial business processes?

What levels of impact are considered Critical? Major? Minor?

Are internal or external customers affected?

How many customers must be affected before the event is considered Critical? Major? Minor?

Will revenue be lost?

Is this issue more or less expensive than other pending issues?

Will schedules be affected?

How likely must delays be before the event is considered Critical? Major? Minor?

Is there potential for hard failure?

How great must this potential be before the event is considered Critical? Major? Minor?

Customizing Pre-Defined Events

After identifying the severity of common events for your business, you might want to customize the default events in SL1 to fit your business requirements.

SL1 includes pre-defined events for common syslog, trap, and SNMP messages, as well as pre-defined events for when SL1 executes user-defined policies. Pre-defined events include event severity, but after identifying events and defining their severity levels for your organization, you can edit the pre-defined severity of events to match your business requirements.

For example, SL1 includes the event "DNS: Nameserver not responding". By default, SL1 assigns this event a severity of "Major". Suppose that your organization determines that this event is a critical event for your business.

To change the severity of the event "DNS: Nameserver not responding":

Go to the Event Policies page (Events > Event Policies):

In the Event Policies page, type "DNS: Nameserver Not" in the search bar at the top of the page. The Event Policies page displays only the event you want: the event "DNS: Nameserver not responding".

To edit the severity of the event, click the Actions menu () and select Edit. The Event Policy Editor page appears.

Click the Event Message tab and select a new value in the Event Severity field. For example, change the value from Major to Critical.
Click the Save button to save the new severity. When this event occurs on any device in your network, SL1 displays an event message with the new Critical severity.
For more information about creating your own custom event policy and editing other parameters of an event policy, see the Events section.

Customizing Pre-Defined Events in the SL1 Classic User Interface

After identifying the severity of common events for your business, you might want to customize the default events in SL1 to fit your business requirements.

SL1 includes pre-defined events for common syslog, trap, and SNMP messages, as well as pre-defined events for when SL1executes user-defined policies. Pre-defined events include event severity, but after identifying events and defining their severity levels for your organization, you can edit the pre-defined severity of events to match your business requirements.

To change the severity of the event "DNS: Nameserver not responding":

Go to the Event Policy Manager page (Registry > Events > Event Manager):

On the Event Policy Manager page, type "DNS: Nameserver Not" in the filter-while-you-type search box at the top of the Event Policy Name column. The Event Policy Manager page displays only the event you want: the event "DNS: Nameserver not responding".

To edit the severity of the event, click the wrench icon () to the left of the event name. The Event Policy Editor page appears.

Select a new value in the Event Severity field. For example, change the value from Major to Critical.
Click the Save button at the bottom of the page to save the new severity. When this event occurs on any device in your network, SL1 displays an event message with the new Critical severity.
For more information about creating your own custom event policy and editing other parameters of an event policy, see the Events section.

Identify Technical Units and Business Units for Event Escalation

When defining an escalation policy, you must determine which technical and business units to include during an escalation. You must also determine each unit's position in the escalation chain.

For the example in Example Escalation Processes, we defined the following units and established their position in the escalation chain):

Operations staff. Events are initially handled by the Operations unit.
Director of Operations. If the Operations staff does not acknowledge or resolve an event within a predetermined timespan, the event escalates to the Director of Operations.
Customer Satisfaction Representative. If the Director of Operations does not acknowledge or resolve an event within a predetermined timespan, the event escalates to a Customer Satisfaction Representative.
Director of Customer Service. If the Customer Satisfaction Representative does not acknowledge or resolve an event within a predetermined timespan, the event escalates to the Director of Customer Service.
Tier-3 Support Engineer. If the Director of Customer Service does not acknowledge or resolve an event within a predetermined timespan, the event escalates to a Tier-3 Support Engineer.
Chief Engineer. If the Tier-3 Support Engineer does not acknowledge or resolve an event within a predetermined timespan, the event escalates to the Chief Engineer.
Director of Implementation. If the Chief Engineer does not acknowledge or resolve an event within a predetermined timespan, the event escalates to the Director of Implementation.
Vice President of Service Delivery. If the Director of Implementation does not acknowledge or resolve an event within a predetermined timespan, the event escalates to the Vice President of Service Delivery.

Within these units, you must specify which personnel should receive emails during escalation. The units and their position in the escalation chain might differ for your enterprise.