In IT service management, “firefighting” has become a metaphor for much of the work. Someone or something starts a digital fire, and we put it out. Firefighting captures the reactive nature of IT service, the stressful, unplanned events that can make the job brutal.
Firefighting is the reason sysadmins should be ecstatic about machine learning. Algorithms will not replace IT people. Rather, machine learning will begin to shift IT service from firefighting to “fireproofing.”
Fireproofing is what it sounds like: anticipating and preventing problems rather than waiting for them. For most of IT history, fireproofing has been impossible because it would require human beings to analyze outrageous amounts of data.
If machine learning algorithms can ingest trillions of data points, find meaningful patterns, and share them with us, we have a chance to prevent fires. Even better, machine learning algorithms might be able to address problems without any human intervention.
Let’s explore a few of the fireproofing opportunities:
Now that software and infrastructure are consumed as services, resource utilization is dynamic. Take disc space as an example. IT knows that it’s cost-efficient to increase and decrease disc space according to demand. An ecommerce site, for instance, might increase disc space in preparation for winter holidays. But, if there’s an unexpected spike in July, the site could be caught unprepared.
That’s where machine learning can make a significant difference. An algorithm that analyzes mass amounts of traffic, log files, transactional data, and other information could, hypothetically, determine if the company will max out disc space days before it does. In that case, IT can preemptively increase disc space to account for the surprise spike and prevent the firefighting scenario.
My car recently had a software bug, and I found out the hard way. It finally rained in Israel, and my windshield wipers wouldn’t work. When I brought the car to the dealer, they discovered there was a software bug and fixed it with an update. I got off easy. If the software-powered brakes, steering, or accelerator had a bug instead, there’s a chance you wouldn’t be reading this article.
By 2020, Gartner estimates there will be more than 20 billion IoT devices in circulation. Whereas most IT problems are inconveniences and drain productivity, IoT problems can be life-threatening. Expect algorithms to automatically monitor and update connected cars, alarm systems, medical devices, industrial equipment, and other devices with safety implications.
Most IT departments create scripts to complete tasks and solve basic problems. A script can automate the creation of new employees’ email addresses. Likewise, when those employees forget their passwords on the second day of work, a script can generate new ones.
The problem is that scripts have limitations in self-service. The user who visits a knowledge base for troubleshooting usually finds manual steps to address the problem, not a one-click fix. Machine learning may change that.
At first, algorithms will convert tickets into articles or suggest new knowledge base entries based on ticketing, search, and usage data. That way IT can provide self-service troubleshooting steps before users ask for them. Eventually, machine learning algorithms will continuously monitor applications and run preprogrammed scripts to fix issues before they affect the user.
In 2017, machine learning algorithms will analyze data to predict and prevent IT issues. They will shift IT from firefighting to fireproofing, especially in resource utilization, IoT, and self-service. This transformation will lower costs, improve efficiency, reduce errors, and enhance user experiences.
As a result, machine learning will free sysadmins to focus on problems that require creativity. They will become shepherds to the machines. Programming, calibrating, and monitoring algorithms will become an integral part of the IT service skillset. The fireproofing era of IT service will drive IT service departments to be more resourceful and less reactive.
This article was originally published in insideBIGDATA.