Oh no, the dreaded email server alert. There are few faster ways to ruin a systems administrator’s day. It’s not just diagnosing, working, and resolving the issue; it’s the inevitable bombardment of emails and update requests that are about to ensue. The countdown to chaos has begun.
Hopefully, these types of issues are rare, but they will happen on occasion. There needs to be a better way to streamline the processes and communication surrounding the unwelcome server outage (and other network and systems alerts).
The service desk has spent years of training and process improvement on automating notifications and providing visibility into anything that impacts the organization from a technology perspective. Network and systems admins can leverage the resources of the service desk to automate communication and expedite resolutions for some of the issues they deal with. In this post, we’ll look specifically at why some alerts from network and systems monitoring software should trigger incidents in the service desk, and how network and systems admins can lean on
ITSM practices to make their lives easier.
Trigger an Incident From a Monitoring Alert
Certain alerts (like an email server alert) can and should be automatically converted to incidents in the service desk. SolarWinds
recently introduced an integration between the Orion
® Platform and
SolarWinds® Service Desk just for that reason.
IT leaders can decide which alerts should trigger incidents within the service desk. Let’s take a look at why this is beneficial, and then we’ll look at which alerts might qualify as incidents.
From a systems or network administrator’s perspective, there are two important reasons why certain alerts should be integrated with the service desk.
First, it automates most of the necessary communication with the rest of the IT organization. Service desk technicians are going to receive tickets about this potential outage, and they’re going to spend a lot of time troubleshooting unless they know what the systems admin already knows. Rather than requiring the systems admin to email the help desk manager (who then needs to communicate it to the rest of the team), the priority incident will call immediate attention to the issue for everyone who works in the
help desk. If a server outage alert automatically spawns a ticket, it will be visible to everyone working on the service desk side, as will any updates or related tickets. Every update to that incident record (or problem record, if it applies) can share information back to the alert so that all stakeholders are working with the same set of evolving data.
Second, there may be important data within the service desk platform that can help identify or resolve the issue. Email servers, for example, should exist as configuration items (CIs) in the service desk. These CIs carry records of incidents, problems, and changes that have impacted them. If IT recently performed some sort of maintenance or update to a server, it will be identified in the record. One click into the change record can provide valuable insight for the systems administrator tasked with maintaining the server and addressing the current alert.
The service desk team can also assist in the process of finding a resolution. If an application is down, incoming tickets can indicate a problem, and ITIL practices can support getting escalations and getting to a resolution. Not only can the service desk streamline communication to impacted users, but it can also incorporate
change management planning and
risk assessment in pushing out a timely solution.
Which Types of Monitoring Alerts Should Trigger Incidents?
This really depends on the structure and operations within the IT organization. Start by asking, “which types of alerts are causing immediate disruption to employees?”
Those types of issues will often result in an
influx of tickets, so the service desk should be aware of them. Network or bandwidth-related alerts, certain server alerts, application alerts, and certain website alerts might all trigger service desk incidents.
Almost everything IT introduces and maintains behind the scenes has an impact on employees, but certain issues will create immediate impediments in their daily tasks. These alerts should trigger tickets. Some on-premise servers might only be used by IT or small factions of the organization. Alerts pertaining to those servers may not be critical to service desk technicians. On the other hand, email server outages can paralyze entire business units, so it’s imperative to loop in the service desk.
Service desk technicians can connect related tickets, creating a problem and streamlining updates to the impacted users.
Live chat agents can provide visibility into the issue, perhaps recommending alternative options for employees who depend on whichever server or application is down. The team can also create a prominent message for the service portal to prevent new tickets. While the employees wait for a resolution, at least they’re aware of what’s going on.
On the back end, automation rules and SLAs can help expedite resolutions to certain network and systems problems. The service desk can include rules for keywords such as “warning” or “critical” so that every time an alert triggers an incident with that language, the service desk treats it with critical priority. Applications alerts that trigger incidents can be automatically routed to application support. Same goes for network alerts. The service desk can also include specific SLAs to ensure these tickets are viewed and/or commented on in a timely fashion.
The key is to get all IT stakeholders on the same page, and identify which types of network and systems alerts might benefit from the capabilities of the service desk. If there’s historical data, mass communication needs, and advanced process requirements involved, the service desk can probably help.
