Selector AI blog

Audit, Validation, and Anomaly Detection Selector Platform Architecture Introduction Observability tools have historically focused on logs and metrics, but not configuration information. This is surprising given how often configuration changes lead to outages as well as their potential to create security vulnerabilities. Enter the Selector Configuration Compliance solution. Operations teams can now audit configuration changes, correlate configuration changes to anomalies, and search for the presence or absence of specific configuration statements. Operations teams can be configuration commandos, with an elite understanding of configuration changes, settings, and consequences. Anomaly Detection The basic workflow is as follows: Selector users can drill down on all correlated information including diff and whole configuration Through this workflow, anomaly detection is much richer, and correlated to likely causes whether it is a fault in the network or a configuration change. Instead of operations teams having to guess at what the likely sources of anomalies are, there is greater clarity, more efficient triage, lower mean time to detect (MTTD), and lower mean time to repair (MTTR). With the impact of the configuration change identified, operations teams can roll back the change if needed, using an approved process. This solution highlights the strength of the selector architecture, capable of correlating any data source or data type, including configuration changes. Configuration Search / Validation Ever been in a situation where you are about to go live with a major new network segment and/or change, and wondered if every configuration was set the way it needed to be? Now you can do a configuration search for the absence or presence of any configuration element. Show me the devices that have this BGP statement. Show me the devices that do not have this ACL statement. All with a natural language query. A Selector customer recently used this capability before going live with a major, highly visible media event, and were very pleased they did, observing that no other solution on the market has this capability. Configuration Audit As with many Selector events, a timeline is constructed so that Selector users can explore a timeline, see correlations, and do drill downs as needed. With the Selector Configuration Change Timeline, operations teams can see when a change was made, what the change was, and who/what made the change. As automation becomes more prevalent, the frequency of changes is likely to increase. Buried in such changes may be configuration changes made by hackers that create significant security vulnerabilities. A configuration change trace / timeline is essential as configuration changes are among the most common sources of outage, performance degradation, and increasingly, security exposures. Conclusion While change management processes may provide a check on what planned changes occur, the outcome of a change is unpredictable and there may be unwanted changes occurring outside of the change management process that operations teams need to know about. Importantly, if there is a correlation between a configuration change and outages / performance degradation, operations teams need to know about that as rapidly as possible, and then return to the desired KPIs as soon as possible.

Introduction A new generation of IT operations tools are emerging that are collectively referred to as “AIOps”. As the name implies, they are IT operations tools that leverage artificial intelligence / machine learning (AI/ML). As there are often questions about how much AI/ML these products use, it is worth exploring an example, the Selector platform. There are three big buckets of AI. Narrow AI is the class of AI that most AIOps tools are in, capable of performing specific tasks, but not human like. General AI is more like human intelligence and Super AI is intelligence that exceeds humans. While the future of General AI and Super AI is unknown, narrow AI is already making significant contributions, dramatically increasing the efficiency and effectiveness of operations teams. Supervised Learning No discussion of AI/ML can exclude a discussion of Supervised Learning, because it is perhaps the most widely discussed and known machine learning approach. Supervised learning is common in classification and regression processing where there is a desire to train a model to learn the relationship between a label (this is a cat, this is a dog,..) and structure in data. There are aspects of AIOps for which supervised learning may be well suited, for example root cause analysis on previously captured anomalies. This blog focuses on rapid anomaly detection, ranking, and contextualization from unlabeled data streaming at a rate of millions of messages per second. Rapid anomaly detection approaches that are already delivering significant value include unsupervised learning and self-supervised learning. Neither require long training times or rely on large datasets of previously labelled data. Unsupervised Learning Unsupervised learning is a way of learning structure without any hints about what that structure is, i.e., labelled data. An example is clustering like structures. This approach is extremely helpful in network health applications where the goal is to contextualize and correlate many different types and sources of data. Unlike static rules-based systems, with unsupervised learning, a dynamically assembled and filtered view of network & applications is created. Analysis adjusts to the available data, rather than using rules-based logic that works best in the presence of specific data. Anomaly sources and connections to other resources are identified. Correlation also occurs across time. A configuration change that occurred before the emergence of the anomaly can be correlated with the anomaly, and operations teams can quickly drill down on what the configuration change was. Other context, such as inventory data can be used to provide a richer view of anomaly sources and connections. A clear and noise-reduced story of health is created, focusing the energies, experience and skills of operations teams on next steps: collaboration and action. Most importantly, this approach discovers anomalies that have never been seen or occurred before. This is critical in increasingly dynamic and complex environments. Self-Supervised Learning Self-supervised learning is an approach that is often asserted as being close to how people learn. Learning by observation. In network health applications, it is common to monitor thousands of specific measurements, and then alert based on threshold violations. Thresholds can be set manually by operations teams or default heuristics can be applied. Both approaches have challenges ranging from the time to maintain, to a flood of false alarms. A better approach is to use self-supervised learning. Observe what is “normal”, and then alert based on algorithmic deviations from a normal-based prediction. In this way, thresholds are not only dynamic, they are automated. Less noise, and less manual threshold setting by operations teams. Conclusion The human imagination, aided by science fiction fantasies created for entertainment purposes, often creates expectations that are ahead of where technology currently is. In the case of AI, that expectation is general AI and super AI. However, narrow AI is real, and applied intelligently, is delivering significant value for operations teams. The use of terms AI/ML and AIOps for anomaly detection are derived from unsupervised learning and self-supervised learning. In addition to approaches that are recognized as “AI/ML”, other algorithms are used, for example recommender systems for ranking.

Introduction In the last blog, Collaboration-Centric AIOps, we discussed how deep integration into common collaboration tools combined with human operations experience, leads to rapid root cause identification and resolution. In this blog, we explore some of the advanced capabilities available to operations experts that allow them to do problem-specific analysis and take problem-specific action. Natural language queries AIOps has to be not just powerful, it has to be usable. The Selector AI analytics engine consists of a relational database, a time series database, a knowledge graph, and other important information repositories. The solution would not be usable if SRE/NetOps teams had to handcraft complex queries for each type of repository. Even the need for complex SQL queries would by itself make the solution cumbersome and slow to use. Selector AI makes it easy to extract data and create visualizations using natural language queries. As Figure 1 shows, significant complexity is hidden behind easy to use, intuitive, natural language queries. These natural language queries can be used to generate on-demand visualizations within collaboration tools and to create widgets for the expert portal. Visualizations look exactly the same in both the collaboration environments and the Selector AI portal, which is itself a differentiating aspect of the Selector AI solution. An important aspect of Selector AI’s natural language queries is its dynamism. As more data is digested, the vocabulary of the language grows. As the solution learns from meta-data that Chicago, for example, is a location, then natural language queries automatically recognize that Chicago is a location. No software update is required, no complex query syntax to identify Chicago as a location, queries automatically learn from meta-data. The knowledge and power of the natural language query is impressive out of the box, but also keeps evolving over time. Natural language queries can be used directly within popular collaboration tools, rendering visualizations that are a) powerful and b) exactly the same as visualizations in the expert portal. Seamless analysis across collaboration tools and expert tools; seamless analysis across operations teams. Gone with archaic hard-coded CLIs. Powerful, intuitive, and dynamic. The next generation approach to extract specific analysis, for specific problems. Expert Portal The proliferation of point tools, for point problems, has led to point portals. Each solution has its own pane of glass. Not just an additional pane of glass, but as a large-screen pane of glass as the only significant interface to the analytics. In the Selector AI solution, operations teams get the same rendering whether they are using a smartphone, a desktop, or a laptop. These screens are sufficient to collaborate for many use cases, regardless of location or device. While an expert portal is the only interface for many tools, it is an option for the Selector AI solution. The option exists primarily because collaboration tools do not support all capabilities, and we know there is additional value we can provide when SRE/NetOps teams are doing a deep dive. The Selector AI Expert portal allows customers to drill down to raw data, see many different data types on a single timeline, and initiate resolution actions. Invoking the expert portal is easily done within collaboration tools. The transition from immersive collaboration to the expert tool is seamless with a contextual hyperlink. This hyperlink can also be used to enrich ticketing systems. Conclusion There is powerful functionality directly integrated into tools like Slack and Microsoft Teams to achieve Selector AI immersive collaboration. There are also times when operations experts need to leverage capabilities not enabled in collaboration tools, and with Selector AI, that transition is seamless; called directly from collaboration tools and rendered the same in both environments. For SRE/NetOps experts, natural language queries are simple but powerful — AI is now usable and understandable. When a resolution is decided, action can be taken directly from Selector AI. For all team members, regardless of their skills, experience, and role, there is a Selector UX fit for the job. AI/ML for operations novices and AI/ML for operations experts.