Blog

Modernize Your ITSM Environment

by Twain Taylor October 4, 2017 | 7 min read

The demands on organizations and their applications are changing. Reliability is vital to gaining the trust of users. If an app suffers degraded service, let alone complete downtime, for an extended period of time, users will go searching for a replacement out of the increasingly large variety of options. In many cases, app downtime can also cause the reputation of the company to be tarnished. People highly regard apps that are reliable and will end up making them an integral part of their work or life. This means that your DevOps team must be quick to react to and solve customer-impacting app issues. Long periods of unplanned downtimes can be embarrassing and cause a loss of users.

Rapid Transformation Has a Cost

Developing a modern app or transforming an existing and established app means things will break. Downtime is inevitable with the constant need to update and transform — increasingly complex architectures may introduce new vulnerabilities.

An IDC report shows that infrastructure failures and application failures have a huge impact on Fortune 1000 organizations. Each year, billions of dollars are lost due to unplanned downtime. Along with the tangible costs, the brand image of these enterprises is also damaged. If customer satisfaction is important, then app downtimes must be dealt with quickly.

Traditionally, organizations have found that having an ITSM process in place goes a long way in avoiding downtime. While this is true, traditional ITSM processes only go so far. With the complexity of today’s applications and development pipelines, you need an ITSM process that’s based on a modern ops paradigm. What stands in the way of modern ops are the traditional roles of development and operations teams.

A Tale of Two Teams — Developers and Operations

There was a time when developers and operations were two separate entities. Developers would build an app and throw it over the wall to the Operations team to run and maintain, resulting in chaos during downtime. Operations would carry the burden of responding to downtime, and developers had a tendency to assume it was Ops’ problem to handle whatever comes after development, leading to the writing of code that was less likely to be production-ready.

Let’s take a look at the different characteristics of a Developer team and Operations team:

Developers Operations
Look for agility Look for stability
Are exploratory Are risk-averse
Non-linear Sequential
Short-term business needs Long-term business needs

 

Operations teams and Development teams operate at different speeds. While the operations team focuses on stability and reliability, developers focus on building cutting-edge features, and how to come up with something new. This means the two teams are not at the same level, and it can get chaotic during times of emergency and downtimes.

We no longer have room for this divide. In modern DevOps, it is vital that the Development and Operations teams work closely together and are in sync. IT organizations cannot afford to give any one side too much attention, while the other gets neglected. This means that you need a solution that can deliver for and support both of them as equally as possible. For modern IT organizations, this solution has been DevOps.

DevOps is the only, tried-and-true way organizations can consider both agility and reliability. Balancing both will benefit the organization as a whole and will lead to quicker response times during app downtime.

The Three Core Pillars of DevOps — People, Process, and Tools

DevOps is all about integrating Dev and Ops teams so they can build high-quality applications faster. While speed is a key focus of DevOps, quality and reliability are equally important.

If a modern DevOps approach is followed, each of the three core pillars will come with specific needs.

  • People – During downtimes, distributed teams should have a carefully orchestrated response. There should be real-time communication and collaboration between teams to act fast and find the best solution. Teams should all have ownership and accountability over software performance and the customer experience. Leadership should have the insight to determine the operational health and capacity of each team.
  • Process – The DevOps team’s response to incidents should be streamlined according to best practices. Random firefighting approaches should be the exception, not the norm. On-call availability of team members and escalation to the right teams should be automated. Process Automation is key to achieving low MTTRs (mean time to resolution). It’s not viable to continuously reinvent the wheel or cobble together manual processes every time it comes time to surface the right systems context, engage the right people, and more.
  • Tools – Tools should be deeply integrated with each other. With the flood of information that is typical of downtimes, the various data points should be intelligently correlated in a way that highlights impact to services, and data sources should feed into tools that enable agile, real-time workflows

Tools Alone are Not the Solution

Rapid transformation to a DevOps approach has its own challenges. Many organizations try to make the transition by using a lot of tools. However, tools alone are not the answer. In order for a seamless transformation to happen, you need to approach your ITSM toolset in a non-traditional way.

PagerDuty did a study on IT organizations and found out that on average, 47% of organizations use 6+ tools to manage operations. Yet, all those tools only consolidate 27% of the alerts, and these organizations have a failure rate of 80%. This shows that merely adding more tools isn’t the solution. In fact, it just adds to the complexity.

With all the data and alerts coming in from many tools, 85% of teams miss important alerts.

All that information being received at the same time makes it difficult to sort out the most important information that needs to be dealt with. Overloaded with information, teams have availability issues as high as 79%. A complex toolset has ripple effects on both your people and processes.

“Teams still struggle to find the right signal in all the noise.”

Responding to downtime means having to find the right solution and letting the right people know what’s going on. This becomes a very difficult task if you don’t know what the exact problem is and your toolsets just become frustrating to use, instead of making things easier.

Digital Operations Management

The best way to optimize your ITSM toolset is by using a Digital Operations Management platform like PagerDuty. PagerDuty intelligently manages the alert data from existing ITSM and monitoring platforms that your organization already uses, like ServiceNow, enabling teams to proactively detect issues instead of simply responding to customer tickets. The high volume of data generated from these systems is centralized, into a single pane of glass view. All non-actionable alerts are suppressed and don’t notify (but kept to aid in pattern and anomaly detection), and automation seamlessly engages the right people when something breaks. The incidents contain all alerts related to the issue (automatically grouped via machine learning algorithms), and performance data and detailed error logs to help with rapid troubleshooting and remediation. After all this is done, PagerDuty provides granular reports for operations leaders to analyze system efficiency and employee agility. As you make the transition to Modern Ops, an incident resolution tool like PagerDuty is indispensable.

Learn more about how PagerDuty can help you modernize your ITSM environment by checking out the following resources: