See why EMA says Resolve's acquisition of Ayehu creates a "one-stop/must-stop for Intelligent IT Automation." Check it Out

How Hyperautomation Addresses Incident Response

Hyperautomation brings a variety of existing capabilities together for powerful automation and orchestration functionality. Watch how it can address incident response at the speed of compute to reduce incident severity, the number of incidents, the mean time to resolution, and more.

Learn more about hyperautomation and watch additional demos in our on-demand webcast: What is Hyperautomation and Why Should You Care?

Applying hyperautomation to incident response connects an event ticketing system or AIOps event system to an automatic response, but then it takes the process much further by querying the device that the event affected, and identifying what the device supports by capturing information from an auto-discovery and dependency mapping tool.

From there, the process advances to identify what applications are affected and proactively checks all of those applications. But that's not all. The hyperautomation process looks for similar configuration items (CIs) that might lead to a similar event. By analyzing the data to identify those other CIs, the automation can take additional proactive measures the identify the applications supported, perform proactive checks and potential remediations.

Video Transcription

Isaac Sacolick: Marcus, I've been bringing up incident response a couple of times on this webinar. Everybody wants to reduce the number of incidents and improve resolutions, and avoid letting an incident become a major outage. How does Hyperautomation solve this problem?

Marcus Rebelo: Great question. Hyperautomation is this overarching function that brings a variety of existing capabilities together. And by bringing all these capabilities together, you're really leveraging those tools in their functions and that's pretty powerful. So it means that there can be this link from the original event, whatever that particular system is, and what it supports, what can be affected, and having all this being addressed at the speed of compute, which reduces all kinds of things like the severity of an incident, the number of incidents and the mean time to resolution.

So, I think now is a good time to step in to give a bit of an overview on it. So, in speaking of how this all ties together, you're talking about some event system or AIOps event system that's going to pick something up, and you're going to automatically respond to it. A lot of people do this today. So there's an automated response that's going to occur. Where it comes into really leveraging additional functionality is in querying that device and identifying what it supports, whether that's to a CMDB or DDM, some kind of discovery data and dependency mapping tool that's going to capture that information. And then I can identify what applications are affected from there, and then go proactively check all of the things that that one device supports. So that's step two, after we do the response.

But then, taking it a step further, what other CIs look similar that may have the same type of issue? We don't know. This is just analysis of the data. But by identifying those similar CIs, we can now take proactive measures to identify the applications that those support, perform those proactive checks and potential remediations against it. So with that, let's take a look and see what this looks like in terms of an automation orchestration here. So I'm starting off here from an event. Essentially, this is an event console which is capturing information that's already been discovered and mapped and has the dependencies.

And I can see this event has a bunch of detail associated to it, what the particular services it's failed, what the status is. And here's the response that's going to occur for it. So automatically, these two are tied together. Event happens. It triggers automation. Automation does that response, which is that first part of that flow we just went through. Once this response has occurred, these are the steps that's going to happen, defined by your process. And then we're going to take a look at the next level, which is the hyperautomation piece.

Now we're going to go identify the items associated for that CI. What other applications or business services assets does it support? And let's go take that list and actively check to see if there's anything going on with it. So then, we're going to go ahead and go through that entire process. There could be one application. There could be 20. So really, if it's a shared database, for example, it could really support a lot of different things. Then after that, we want to get into identifying similar or like types of CIs, and then what they support, and go through that whole process.

Now, what you're seeing here is these blue boxes represent a whole bunch of sub automations or processes that are running. And there's one here called a troubleshooting automation. That's really slick cause it's an app, it's a universal app troubleshooting automation, which, once you input some data on things like config files, services that it runs, and where log files are, et cetera, it's going to automatically be able to troubleshoot that application and figure out the problem. Now, that all ties together. And then of course, at the end, we want to give somebody something to look at to make an intelligent decision. And that's going to be where we provide some kind of either list or some email or something that's actionable for those individuals that are monitoring it.

Isaac Sacolick: This was pretty awesome, Marcus. It just makes me think of a lot of the groups that I've worked with in terms of how they struggle with incident management. And it creates this vicious cycle, right? When the IT team has too many incidents, it's taking too much time to resolve them, that business confidence starts to erode and they start saying, "Hey, we can't get the things that we need to get done. We can't get our digital transformation work done. We can't improve customer experiences, or in some cases, our customers are hurting because of this."

So, a big part of really solving for that problem is being able to handle them more reliably, handling them more efficiently, then using the time saved to go back and start addressing root causes, to start figuring out which areas of technical debt to go and address. And then from there, organizations start having fewer issues to go solve for, and they can really start focusing on the more proactive things that their business is asking them to do.

Share This Video

Marcus Rebelo

About the Author, Marcus Rebelo:

Marcus Rebelo serves as the director of sales engineering at Resolve, where he works with the Fortune 1000, leading telcos, and global MSPs to design and implement creative IT automation solutions that enable more agile, efficient IT operations. With more than two decades of experience in networking, software, and hardware technologies, Marcus has deep expertise designing and architecting IT solutions that create strong foundations for innovation.

His love of technology started with his first Basic programming course in the early 1980s and since then he has held positions ranging from the service desk to complex service development across a wide variety of organizations including NTT Communications, IPsoft, BMC Software, Wipro, and Hewlett Packard. In his current role at Resolve, he has grown the sales engineering team to a global organization and worked with numerous customers on their journey to automation success. He frequently speaks at industry events on automation, digital transformation, and cybersecurity topics.

Follow Marcus Rebelo:

Learn More About Our IT Automation and AIOps Platform at Our Resource Center