This is a 2-part series focusing on the use case and possible solution for supporting support engineers (read part 1 here). The series explores one key aspect of this month’s theme of Virtualization – troubleshooting in tech-support.  As more tasks become automated and support teams deal with an increasing variety of software and customers, the act of virtualizing these efforts can lead to a few troubles of their own.  

Written by Puneet Pandit, Founder and Chief Executive Officer of Glassbeam

Advanced Troubleshooting and Automation

In the previous blog, we looked at possible systems/processes that can help L1/L2 support teams be more optimized. In this blog, we can continue that thought process and look at how L3/L4 troubleshooting processes can be optimized.

For L3/L4 type of issues, what if there was:

• A log vault that allows the support engineer to get access to the current and the historical logs

• An interface to create and view configuration of a system as defined by the support engineer. Configuration need not be a single view, but can be defined in multiple ways

• An interface to define and view attributes whose changes need to be tracked

• An interface to view related cases, bugs, KBs, E-mails – Requires integration with Bug, KB, Case and E-mail databases.

• An interface to plot relevant statistical attributes and if required, overlay critical events, configuration changes over the time series graph to cross correlate.

• An interface to search the logs and also look at / plot trends across install base

• A rules engine that allows creation of complex rules/KPIs

• An interface that allows easy analyses across stack, where the components of the stack can be dynamically defined.

• An interface that provides a canvas that can contain all the required data to solve a given problem (one recipe for each type of problem). – This would require an interface that allows the support engineer to add content from various sources into the canvas, filter each source based on requirement, and represent each source in ways that help faster problem resolution. This canvas could contain data from configuration data, changes in configuration, events/syslog entries, statistical trend of various parameters, Known issue report, list of systems that face similar issues, related bugs, related cases, related knowledge base, related E-mail discussions etc.

• An option to save the entire canvas as a recipe to be used to solve problems of specific type They could also assign a KPI to know if a problem has been triggered or not. A set of such saved canvas/dashboards can be used by Support engineers to access all details related to solve a particular type of problem and hence solve problems faster without having to reinvent the wheel every time.

Again, the above list is neither comprehensive or detailed, but provides an overview of interfaces, systems, processes that can be put in place to make things easier for the L3/L4 support, but not only providing a common set of tools, but also allowing the approach to be customized to one’s own need.

Beyond Internal support teams – reaching end customers

In the last sections on the topic of “Troubleshooting troubles”, we looked at how troubleshooting steps can be generalized and how a holistic approach can be arrived at building tools/systems/processes that can significantly enhance the productivity of a support group.

While optimizing internal support operations is important for a product manufacturer, what would be even better is the reduction in the number of support calls. End users lack tools and knowledge to troubleshoot problems and hence more often than not, they open a support ticket with the product manufacturer. What if the solutions we discussed in the previous blogs are made available even to the end user (even if partially), through a self-support portal? Wouldn’t that enable end users to self-support themselves for most common issues? The end user self-support portal can comprise of:

• Health check portal – A portal that provides key indicators of the systems health and configuration

• Capacity/performance portal – This would help the customer understand performance and capacity trends in his data center, which can help in planning better.

• A search interface – To search across all the logs generated from the system installed at the customer’s data centers, including logs from other devices. This could also include data from case management system and Knowledge base.

• A rules engine – Which would help the customer set thresholds/KPIs related to their environment

• Cross stack canvas – A canvas that allows the end user to analyze events across the stack.

• A personalization option to customize the dashboards/reports exposed to the customers to their needs

Product manufacturers can add additional resources onto this portal or integrate the above list into their already existing portal.

In conclusion, the higher level troubleshooting approach is very similar across all support groups, including customers even if the specifics are completely different. Building a software that caters to the specifics will not only constrain its implementation across support groups but will also be inflexible to solve even a single support group’s requirement. What support needs is a framework and tools that allow them to quickly customize the application to their needs. It is the balance between out of the box features while still keeping it completely and easily customizable.

About the Author

Puneet Pandit: Founder and Chief Executive Officer of Glassbeam

Puneet has served as chief executive officer of Glassbeam since its inception in 2009. He is focused on Glassbeam’s mission to disrupt the market for Big Data business applications and machine data analytics.

Glassbeam was incubated inside Orchesys, a professional services firm focused on enterprise storage. Prior to founding Orchesys, Puneet was a senior director at Network Appliance, where he led the database and business applications solutions group focused on driving the $300 million “Oracle on NetApp” market with cross functional initiatives across joint R&D, sales, services and marketing programs. Prior to NetApp, Puneet was a strategic advisor at Ernst & Young and a management consultant at Tata Unisys.

He holds a Bachelor of Science in electrical engineering from Punjab University and MBA from The University of Chicago.