A service-level agreement sounds suspiciously like paperwork, which, to me anyway, sounds either boring or easy to ignore, or both. But service-level agreements (SLAs) can’t be ignored. This particular form of paperwork comes in many flavors, and affects IT in some important ways.
Generally, an SLA stands as a reminder and guarantee of what a customer should receive from a provider. These days, SLAs matter more than ever. In an increasingly distributed world, SLAs hold a lot of power in the relationships between users and service providers, whether that means end users and their IT team in larger organizations, or IT teams and users accessing services and applications from third-party vendors. So it’s critical to see under the covers of an SLA. If an SLA’s benchmarks aren’t met, it can lead to extended outages, unhappy users, and perhaps most importantly, revenue loss.
Entering into an SLA without any visibility into the provider’s side of equation can present a lot of challenges. Ideally, IT won’t enter blindly into a provider-written SLA, but will have some control over what’s promised. In a cloud-based, distributed IT environment, IT teams are ever more dependent on the network to stay up and running for apps to serve users. It’s really hard to know if providers are holding up their end of the SLA bargain if their networks aren’t visible.
When the service or app with the SLA attached to it is humming along nicely, that agreement may be just fine sitting on the shelf with the other boring paperwork. However, when something’s not right in the application delivery path, IT teams have to dust off the SLA to find out what they can expect for restored service or recovery. Then the tricky part comes in: making sure that providers are meeting the requirements of the SLA. Metrics or key performance indicators (KPIs) in an SLA might include reliability or uptime assurances, performance benchmarks, application response or helpdesk response times, and guarantees of certain numbers for selected metrics, like mean time between failures (MTBF) or mean time to resolution (MTTR).
At Your Service (Level)
Clearly, these SLAs are now running the lives of many techies—so you need to make sure they are working for you. After the SLA’s ink is dry, you don’t have to depend on the provider to tell you whether its benchmarks and agreements are being met. Monitoring software can actually do this for you, from a single dashboard. That also helps prove to a vendor or provider where the issue lay, whether in the app or the network.
Online retailer eBay uses AppNeta’s PathView to validate the metrics promised in service-level agreements with third-party contact center providers. This is especially handy for eBay’s VoIP software to ensure that customer calls don’t have quality degradation issues. AppNeta’s PathView tool sees into any network, whether it’s part of your infrastructure or not, and whether it’s wired or WiFi. That lets users gauge how third-party providers’ apps are performing.
One key feature of PathView is the ability to set up alerts that match app-specific SLAs. This is extremely useful to find out what’s going on during a slowdown or outage, or if you’re noticing recurring problems. PathView also gathers specific network metrics to see when an ISP is running slow and the network performance is affecting application performance. PathView’s monitoring gets detailed, down to one-minute granularity on latency, data loss and jitter. This continuous monitoring extends to VoIP and unified communications quality, which has been very useful to eBay. Its partners access one dashboard for real-time data.
Treat the SLA as a living, working document, and use the right tools to see if you’re getting what you signed off on. Keep those providers honest and your users happier. Do you get what you bargained for in your SLAs? Let us know.