Using OSS machine learning to predict backwards not forwards

There’s a lot of excitement about what machine-led decisioning can introduce into the world of network operations, and rightly so. Excitement about predictions, automation, efficiency, optimisation, zero-touch assurance, etc.

There are so many use-cases that disruptors are proposing to solve using Artificial Intelligence (AI), Machine Learning (ML) and the like. I might have even been guilty of proposing a few ideas here on the PAOSS blog – ideas like closed-loop OSS learning / optimisation of common processes, the use of Robotic Process Automation (RPA) to reduce swivel-chairing and a few more.

But have you ever noticed that most of these use-cases are forward-looking? That is, using past data to look into the future (eg predictions, improvements, etc). What if we took a slightly different approach and used past data to reconcile what we’ve just done?

AI and ML models tend to rely on lots of consistent data. OSS produce or collect lots of consistent data, so we get a big tick there. The only problem is that a lot of our manually created OSS data is riddled with inconsistency, due to nuances in the way that each worker performs workflows, data entry, etc as well as our own personal biases and perceptions.

For example, zero-touch automation has significant cachet at the moment. To achieve that, we need network health indicators (eg alarms, logs, performance metrics), but also a record of interventions that have (hopefully) improved on those indicators. If we have inconsistent or erroneous trouble-ticketing information, our AI is going to struggle to figure out the right response to automate. Network operations teams tend to want to fix problems quickly, get the ticketing data populated as fast as possible and move on to the next fault, even if that means creating inconsistent ticketing data.

So, to get back to looking backwards, a machine-learning use-case to consider today is to look at what an operator has solved, compare it to past resolutions and either validate the accuracy of their resolution data or even auto-populate fields based on the operator’s actions.

Hat tip to Jay Fenton for the idea seed for this post.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

2 Responses

  1. I was sure you were going to talk about fault analysis or root-cause analysis when I started reading this! Of course there’s a fair bit of ‘traditional’ data analysis that goes in to fault analysis already. AI could dig a little deeper. Think: five-whys. Not just pointing out that this customers service has failed because: router port > link layer down > DWDM link down > DWDM port failure… but AI could ask why: Port mis-configured. Why: reconfiguration process not followed. Why: Scheduled maintenance overran…

    But, yes, I like the ideas. (Semi) automation by learning how the operator resolved issues in the past.

  2. Hi James,
    Exactly! Not only that, but for me the truly exciting potential of machine-led decision processes is to completely close the loop on key processes in future. This means symptoms -> diagnosis -> treatment -> learning/reinforcement for the next instance / iteration that comes along. With poor quality data in the diagnosis / treatment phases, a closed-loop solution will only reinforce bad data, making it a continually degrading solution rather than continually improving.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.