Whether you’re troubleshooting a slow app, assessing the impact of a vulnerability, or planning a network upgrade, automation can streamline your critical workflow. Within NetBrain, a Dynamic Network Map is the foundation for automation – providing a canvas for you to visually analyze design and diagnostic data.
This webinar will show you how network automation can:
Amena: Good afternoon, and welcome to NetBrain’s webcast on five ways to enhance your workflows with automation. My name is Amena Siddiqi and I’m a senior product marketing manager here at NetBrain. Joining me today is Matt Speidel, one of our senior training engineers. Before we get started, I’d like to go over a few logistics. We’d love to keep the presentation interactive, so please feel free to engage with us via the Q&A panel at any time. We’ll be checking the Q&A during the presentation and responding to questions as we go, and we’ll also save some time at the end of the webcast to answer any remaining questions over the phone.
We’ll be diving deeper into automation with runbooks, but first, for those of you who don’t already know us, we’re the creator of the industry’s leading network mapping and automation platform. Since 2004, our developers have been hard at work listening to feedback from end-users like you to create a platform network engineers truly love. Today, the NetBrain platform powers over 2,000 of the world’s largest networks including one-third of Fortune 100 enterprise networks.
Let’s take a broad view of the concept of automation and where the market is headed. In addition to workflow challenges, emerging technologies like virtualization, SDN, and NFV add a layer of abstraction to the network. This has benefits such as simplifying deployment of new networks, but operations teams struggle to take over these new networks. Our focus today is agile network operations, where NetBrain provides manual task automation, visibility that helps decode the abstraction, and – via API integration – pulls data into a single pane of glass, enabling API trigger diagnostic workflows. This results in better collaboration between network, security, ops and DevOps teams.
Now, looking toward the future, as environments become larger, more complex and more dynamic, it becomes impossible for architects to achieve more than an informed best-guess of the required configuration. This is the challenge that intent-based networking aims to address, but that is a topic for another day.
If you’re a network engineer, you’re probably all too familiar with this feeling. You’re typing furiously into the CLI, issuing show commands to individual devices, checking if configs match as they should, and after hours of sweat and tears, you still don’t know why there is no path to that subnet in that route table. You’ve expended a lot of time and effort and basically got nowhere.
Automation with NetBrain is like replacing the square wheels on your bicycle with round ones. Now you can actually get somewhere and maybe have time for those strategic projects you’ve been putting off. Here is where NetBrain can help. There are essentially two inefficiencies that exist within IT workflows: manual data collection analysis and ineffective collaboration. We conducted an independent survey across over 200 network engineers last year and found that the majority of network workflows remain manual despite network automation. Documentation, troubleshooting, security hardening and response, and change management are all executed directly, one device at a time from within the CLI which 43 percent of engineers report is far too limiting.
Engineers struggle to understand the state of the network. They are overwhelmed with data from various NMS solutions, including ticketing, monitoring, IDS, packet analyzers and logging. They’re tired of playing the game of stare and compare to analyze data from different sources. As complex systems, modern networks are managed by series of specialists such as multicast, datacenter, void, etc., each with pockets of knowledge. One-third of engineers rely on the network hero and his or her tribal knowledge to troubleshoot issues. There is frequently a lack of democratized know-how among the team. Teams struggle to get on the same page during collaboration. Data sharing through text-based data dumps and logs and is hard to point to key insights.
Let’s talk about how NetBrain automation addresses these challenges. In NetBrain, everything begins and ends with a map. NetBrain interprets CLI data to build a rich mathematical model of the network. We often refer to this as a digital twin of the network. NetBrain visualizes the data in the form of dynamic maps. These maps can be enriched with data from third-party data sources such as monitoring tools and ticketing systems and they function similar to a Google Map for your network. They are a single pane of glass, integrating different kinds of information and a searchable database to easily find information you may be looking for.
When NetBrain’s executable runbooks are attached to dynamic maps, they transform the map into a powerful medium for task and workflow automation. A runbook is basically three things: a platform for documenting and codifying network knowledge, a tool for task automation mainly focusing on diagnostics, verification, and compliance, and an enabler for workflow collaboration. Engineers who are working together can capture, annotate and share their findings easily from one place. Our customers use Runbooks to automate documentation, accelerate troubleshooting, make safer network changes and defend the network from attack.
We’ll be delving deeper into each of these aspects of runbooks in this webcast. Today, we’ll be talking about how you can enhance your day-to-day tasks and common workflows using NetBrain’s executable runbook technology. This is a fairly recent technology that we introduced just last year, built on top of our visual programming framework. Runbooks are basically a way to digitize expert knowledge, repetitive tasks, design checks, compliance verifications, and even the results of prior analysis without writing a single line of code. You can use runbooks to codify tribal knowledge, perform hundreds of CLI diagnostics in seconds, trigger a diagnostic workflow based on an event via NetBrain’s third party API integration, leverage thousands of Cisco TAC scripts via NetBrain’s tight integration with Cisco’s Diagnostic Bridge and enable data sharing and collaboration, both within and across teams.
Okay, let’s dive into the five ways NetBrain automation can enhance your existing workflows. Number one: codifying network knowledge. Let’s talk about the issue of tribal knowledge. Imagine a network outage in the middle of the work day at your organization. Now, imagine that no one has any clue what to do because your senior network engineer is on vacation scuba diving in the South Pacific and he or she is the only person who knows anything about that part of the network. This may seem silly, but it’s not far from reality in many IT departments. The prevalence of tribal knowledge results in scenarios like this all the time.
What is tribal knowledge? Tribal knowledge refers to information that’s held closely by a small group of people, possibly even just one person, and is either unintentionally or purposefully held back from the larger group. This is common practice in today’s IT departments, and it’s extremely detrimental to a high-performing technical team. This manifests in several ways. For example, there may be no common knowledge repository. All network diagrams and reports are kept on someone’s personal drive or are buried in email threads. Then there is the issue of a scuba-diving engineer: The network hero becomes a single point of failure if their knowledge and expertise is not replicated among other team members. What if they were to go on vacation, or worse, retire or move to a different job?
Finally, consider the common issue of a slow application. Is it network latency that’s hurting application performance? Could an app server itself be underpowered? Could it even be the end-user’s computer that’s the problem? Since the network is part of a larger collection of interdependent parts, and since no one engineer can know everything about all things, knowledge sharing among engineers and teams is critical. The goal isn’t necessarily to hire an entire team of CCIEs, though that would be pretty cool; it’s to enable engineers with the knowledge and tools they need to address incidents and work across knowledge silos. The answer is to break down barriers and make information easily available to create a team of network heroes by developing a culture of collaboration and knowledge sharing. All right, it’s your turn now. You guys are in the trenches out there. Has tribal knowledge been an issue for your team? Tell us in the Q&A how it’s working or not working for you.
Amena: All right. Great to see all the responses in the chat. Thanks to everyone who has responded and thank you to those still typing. Let’s move on. NetBrain directly addresses the issue of knowledge sharing and collaboration, both on an incident and infrastructure level. One of the core functions of executable runbooks is to enable teams to digitize their best practices, policies, procedures and anything else that might be otherwise living inside someone’s head, on handwritten notes or any departmental playbook.
Runbooks can be used to automate repetitive tasks such as network troubleshooting steps and compliance checks. Let’s see what this looks like within the product. Matt Speidel, one of our senior training engineers is on the call with me today, and he’s got some exciting demos to share. So over to you, Matt.
Matt: All right. Thanks, Amena. To begin, the process of creating a new runbook is incredibly simple. Runbooks not only make knowledge transfer possible but actually quite easy. When you get down to it, a runbook is a series of steps. As we see, there are several different kinds of steps available depending on what you want the user to do. For instance, you can have the user run Qapps which we’ll talk more about in the next section, or you can specify CLI commands for the system to gather.
For instance, I can build a runbook by adding a Qapp or CLI command step. Then, at each step, you simply specify the exact details of what you want the user to do. You can also insert branches into the runbook flow. These branches let you adapt your procedures to different circumstances. You can see how easy it is to build these things. The hard part, of course, is developing procedures that are coherent, relevant and easy to follow, but that’s equally true of traditional methods.
Now, as far as actually using runbooks, users click the runbook button on the task bar and the entire library of procedures that you have established is at your fingertips. When you launch the runbook, a copy of the procedure becomes a permanent part of the dynamic map that you’re using. The whole procedure is quite complex, but it’s presented to the user in a very clear and straightforward way. With each step, the user can see the author’s notes and they can also run the specified task by just clicking the play button.
All the data that’s currently being generated is now a permanent part of the runbook and a permanent part of the map. The same goes for any notes that the user writes. Based on the results of this step, the user will then select which branch to pursue. In this case, the first step is to run the overall health monitor which is a built-in Qapp that monitors the top five causes of network slowness.
Everything on the map is green here, which means that the CPU and memory utilization are below thresholds and so is interface utilization. If the monitor had triggered any alerts, they would color map elements in either red or orange and a little alert icon would have shown up next to the notes. Since there is no trouble found by the overall health monitor, I’m going to select that branch. The next step in this runbook for this branch is to bulk-pull a selection of general CLI commands from each device on the dynamic map and then examine these show commands for abnormalities. You see how easy it is to sort through by device and by show command.
I’m going to go ahead and hand you back over to Amena.
Amena: Thanks, Matt. As we saw in the demonstration, it is extremely easy for programmers and non-programmers alike to create netted runbooks within NetBrain. Next, we’ll talk about how you can use NetBrain to automate diagnostics, performing hundreds of diagnostics in seconds.
To err is human, but to really foul things up, you need a computer. We’ve all been there. You make a simple configuration change that should have no impact on production traffic. Suddenly, your phone begins to ring, or worse, you lose access to the equipment you were working on.
Issues caused by a slight human error are amplified by machines into veritable disaster scenarios, and while manual changes cause the issue in the first place, the irony is only more manual work will fix the problem. While you’re buried under CLI screen after screen, trying to rectify your error, the clock continues to tick. When it comes to troubleshooting an outage, or defending the network from a cyberattack, every minute counts. While saving two hours of grunt work is nice for everyday tasks, saving 20 minutes of critical downtime is invaluable.
All right, your turn again. How do you feel about making manual config changes and working with the CLI? Is it a love or hate relationship? Or shall we say it’s complicated? Tell us in the Q&A panel how it’s working or not working out for you.
Amena: Thanks to everyone who has responded, and thank you to those still typing. Let’s continue. NetBrain automation eliminates repetitive and manual aspects of CLI-based workflows. In NetBrain, we’ve created a parser library that crunches through hundreds of show commands extracting thousands of critical variables, parceling these into Qapps or quick applications. NetBrain analyzes and visualizes issues such as increasing interface errors and mismatched configs right on the dynamic map where the information is presented in the context of the devices that are impacted. Taking it one step further, Qapps form building blocks of NetBrain’s executable runbooks which encapsulate workflows such as highlighting design aspects of specific protocols and technologies, checking against golden templates for configuration drift, running through compliance and security checklists, or common troubleshooting workflows.
Qapps can even be set up to run on a loop to monitor performance data and intermittent issues. To show you how NetBrain instantly extracts data from any CLI output and visualizes it on the map to uncover actionable insights, I’d like to invite Matt back for another demo. Over to you, Matt.
Matt: All right. Thank You, Amena. There’s a couple of ways that you can use the power of the parser library that Amena talked about. One of them is to search for what you want in the map search bar. As an example, let’s say that OSPF neighbors aren’t connecting properly in this newly deployed network segment. I like to search by syntax, so I’m going to go ahead and search for show IP ospf int. That was a very specific search and there’s only one OS present on the map, so I only get two parsers in my results.
I’m going to pop one open and select my variables. Let’s go with the dead and hello timers. I’m going to contrast these two on each interface and make sure everything’s set up correctly. And to pull them, I just click, drag, and drop onto the map and NetBrain’s going to log into each device, issue the show command in question, extract the variables and drop them on the map just that easily. Now, how cool is that? This function is called instant Qapp.
My purpose here is to check that all the hello values are higher than the dead values. To make this easier, I’m going to set background colors for each of these to make the variables stand out from each other. Then, I’ll rearrange them to put hello across from dead rather than next to it. Now, I’m just going to go ahead and check each interface. On fast Ethernet 1/0/17 on Sjc-Dist-3750-01, I have a hello timer of 10 which seems to be standard in this new area of the network, but the dead timer is set to eight instead of the value of 40 that all the other interfaces seem to have. I guess somebody fat-fingered something when they were configuring these switches. Now, that might have been avoided if they’d have used NetBrain change management, but that’s a topic for another time.
In any case, that would have taken me at least an hour to find with traditional CLI. More like three hours knowing me. How about you guys? How long do you think that would take you to find with traditional CLI methods? Now, if you’re going to perform the given check frequently, you can go ahead and save the instant Qapp as a full-blown Qapp just like that. And if you need to make something a little bit more complex, data analysis, visual highlights, etc., you can use these same parser files to create a new Qapp using NetBrain’s visual programming environment. No coding required.
For instance, I could go ahead and build a Qapp like this one that I put together earlier today. It’s not only going to pull the data, but it’s going to analyze it and put visual highlights on the map depending on whether there is a problem. Let’s run this. And as you can see, it gives us a simple and clear visual highlight as to whether the dead timer is greater than the hello timer as it’s supposed to be, or whether it’s less than or equal to that value. And it also gives us an alert to tell us exactly where the problem is. It took me about 15 minutes to make this Qapp from scratch, and now that it’s made, I can run it anytime, or I can use it as part of any of my runbooks. Now, how cool is that?
Now, I’m not going dive into the guts of this Qapp and show you the nuts and bolts of building Qapps right now, but if you want to learn about that, come to my public runbook customization class. It’s completely free of charge and I’m able to offer it almost every week. That’s what I’ve got. Back to you, Amena.
Amena: Thanks, Matt. As we saw in the demonstration, it is extremely easy to collect, parse, analyze, and visualize CLI output with NetBrain. Taking it one step further, wouldn’t it be nice if NetBrain could kick off a runbook workflow without human intervention as soon as your monitoring system detects an issue? Well, we’ve got good news for you. Consider this: You’re sitting around a barbeque campfire with friends when your phone begins to buzz frantically. It’s your boss. A critical file server is locked up and it looks like a ransomware attack. You immediately race to a console, segregate the site of the attack from the rest of the global network, and mitigate the risk. After things settle down, the CIO calls looking for an update. Did we lose any data? How did this ransomware get in? How did it spread? Do we have good backups?
Now it’s time for you to settle in and hunt down clues among the myriads of scanned data available, which is no trivial task. You have to look through multiple tools and logs in order to get a complete picture, scroll through dozens of graphs, log into dozens of devices and wake people up late at night. If only you had, at your fingertips, the information of what went on right at the time of the attack. If only automated scripts kicked up when anomalous activity was detected.
Let’s take a step back and look at a typical tiered escalation workflow. Based on an event trouble ticket, a level-1 engineer will kick off a basic set of diagnostic workflows most likely based on a standard playbook. This will likely involve a lot of manual data collection via CLI collected in the form of raw text. If the level-1 engineer is unable to resolve the issue, the ticket will then be passed along to the level-2 engineer who will most likely repeat the basic diagnosis to verify the data received and then dig a little deeper. The same thing happens again with the level-3 engineer.
This typical NOC workflow is manual and repetitive and involves a lot of duplication of effort to verify data. As a ticket is escalated, the diagnostic data supplied is either too little to draw any conclusions from or too much. For example, in the form of a log dump. NetBrain introduces an additional tier to the typical NOC escalation workflow. We call it level-0 diagnosis, but level-0 diagnosis and automated NetBrain diagnosis is kicked off via API integration as soon as your monitoring or event management system registers an event. Data is immediately collected at the time the issue is detected, and the results of the NetBrain diagnosis are appended to the trouble ticket for troubleshooters to leverage.
Let’s see what this looks like within the product. At this time, I’d like to invite Matt back for another demo to show us what a typical troubleshooting workflow looks like when integrated with ServiceNow. Over to you, Matt.
Matt: All right. Thank you, Amena. I have here a ticket in my ServiceNow system which is reporting, as we see here, a slow application between two points on my network. When the ticket was submitted, the ServiceNow system reached out to NetBrain via API. You just go ahead and click the hyperlink that we see right here, and voila, it generated a dynamic map of the application path using the A to B traffic path calculator. It then ran through a simple runbook to gather diagnostic data for me.
Now, you can look through the data gathered by our tier-0 diagnostics and find the problem, and in this case, right away, it’s already got the data from the first step of the runbook displayed on the map, and in this case, the cause of the slowness is quite painfully obvious. We see that the CPU on this switch, LA-Core1-Demo, is overloaded. It’s at 99 percent. In addition to the overall health monitor, there’s quite a lot of CLI data which is right at my fingertips here in this case. I’m going to open this runbook step and open the result. Let’s start analyzing.
Let’s go to LA-Core1-Demo right here, and we’ve got logs and so forth. Let’s go to Show Process CPU and see what’s taking up so much CPU runtime. Let’s go down the list, and I’m looking at the percentage values for the five-second, one minute and five-minute intervals. Let’s see if we can find anything that’s more than one digit’s worth of capacity here. Let’s see, two percent, three percent. Let’s see. Here we go, 75 to 76 percent, and it looks like that’s the SNMP engine. That process is completely out of control according to this.
Now that the problem is identified, my team can swing into action and fix the problem. Let’s say that this ticket was submitted at 2 a.m., and by the time I get to it at 9 a.m., the problem has gone away. But if this is a problem that’s surfacing intermittently, what am I supposed to do about it? If I can’t analyze what’s happening when it actually occurs, I can’t find the real problem. And remember, you can set up tier-0 diagnostics with any other software platform that is REST-enabled.
For instance, one popular option is to link NetBrain into your intrusion detection system, and then set it to map the given area of the network and gather a specific set of data when any intrusion is reported. And the end result of this is that you have a whole range of data that was gathered while the intrusion was in progress even if you can’t get to the problem until later. This opens up a whole new world for the security team in terms of being able to analyze what actually happened during an intrusion, finding the vulnerabilities, plugging them, and so forth. And that’s just one example. There’s all different types of software platforms that exists in the ecosystem of a modern network. Being able to tie them all together using NetBrain as the hub allows for almost infinite possibilities and vastly improved effectiveness not just for NetBrain but for every single platform in the ecosystem.
So that’s what I’ve got on this topic. Back to you, Amena.
Amena: Thanks, Matt. Great demo. To recap, here’s what a tier-0 troubleshooting workflow looks like with NetBrain. NetBrain’s API server receives alerts from your event management, trouble ticketing, IDS or other monitoring systems. Immediately, depending on the nature of the alert, NetBrain creates a map of the affected devices and launches the appropriate runbook to collect and visualize key data related to the issue. The map is saved and the map link is sent back to the system that generated the alert. Now, when an engineer arrives on the scene, the data is readily available for him or her to investigate.
Let’s pause here and turn it back to you again. What do you think of everything we’ve shown you so far? Would NetBrain be a valuable addition to your team? Why or why not?
Amena: All right. Thanks, everyone for responding. Great to see your messages in the chat. Let’s move on. Let’s continue with the fourth way NetBrain can enhance your workflows with automation by leveraging Cisco’s intellectual capital in the form of thousands of TAC diagnostic scripts. NetBrain has an exciting and innovative technology partnership with Cisco’s Connected Technical Assistance Center or the TAC program. As part of the TAC service, Cisco customers can access expertise from Cisco TAC in the form of diagnostic scripts and then use Cisco’s recommended remediation to fix issues and improve risk management proactively.
NetBrain customers can gain access to these scripts via API integration and leverage NetBrain automation to collect device data and a dynamic map to visualize the diagnostic results. With one click, a NetBrain engineer can trigger a comprehensive diagnostic scan on selected devices from within a dynamic map, and almost instantly, see the results of that scan presented in the same map context. Here’s how that would work.
First, NetBrain will automatically collect the necessary data from the specified network devices using the Cisco’s show tech command. Next, that data will be sent via API to Cisco’s Diagnostic Bridge across a secure gateway. The data will then be crunched through thousands of Cisco scripts to identify known issues. The result of that diagnosis is then returned back to NetBrain along with recommended remediation and then presented visually to the user on the map.
Armed with this knowledge, users can then proactively scan similar devices for potential problems to increase overall reliability and the security posture of the network. I’d like to invite Matt back for another demo. Over to you, Matt.
Matt: All right. Thank you, Amena. I have here a dynamic map of an application path that’s been giving me some trouble. And to get Cisco TAC’s input on the matter, I’ve run this Qapp as part of this runbook. Amena already explained how this Qapp works: it issues a show tech command to each Cisco device on this map and then passes the results back to Cisco TAC through a secure API link. And in turn, TAC analyzes the outputs automatically and sends back a list of recommendations for each device.
First, you get a simple highlight on the map for each device of which ones have been checked – that’s the blue highlight. This path happens to go across all Cisco devices. In this case, all of them were checked, and then the ones that also have a red highlight, these are the ones where an alert issue or more than one alert issue was found. Alert issues are things that Cisco TAC recommends fixing right now. To see what was recommended on any device, I just click Diagnostics List below its name and I can see point by point what problems have been identified and what the recommended solution is. I can just use tooltips to see the details here. And what jumps out at me in this example for this device is that the clock is incorrect. That’s the very first thing I would fix for this device.
If I want to see all the recommendations for all devices gathered together, I have a couple different ways I can do that. First, I can simply click the alerts icon right here in the runbook, and all the recommendations appear as warnings or errors in the Qapp’s results. They’re all listed right here for me and that’s very convenient. The Qapp also gathers everything into a CSV export which I can preview by clicking the CSV icon in the runbook. Of course, when I click export, it downloads a copy to my local computer.
Everything is right here at my fingertips and I can go through it at leisure. How cool is that? For all its amazing power, Cisco TAC integration with NetBrain is really that simple. That’s all I’ve got. Back to you, Amena.
Amena: Wrapping up with the fifth and final way NetBrain enhances your workflows as a medium for collaboration. Why is collaboration so key? Effective collaboration can often represent difference between a well-engineered, timely response to a threat and becoming a hapless victim of a cyberattack. NetBrain’s 2017 State of the Network Engineer survey revealed that the number one challenge when troubleshooting network security issues was the lack of collaboration between network and security teams selected by 72 percent of all respondents.
One of the key benefits of NetBrain is that it serves as a shared forensics console between different teams. Using NetBrain, network and security teams can work together to isolate cyberattacks and implement best practices for network hardening. For network engineers, working with applications teams is frequently even more challenging than working with security teams. When an app is slow, the network is often the first to blame, and the hardest to clear from suspicion. The lack of common ground can be a real barrier to communication.
Using NetBrain as a shared forensic console, all the relevant information can be visualized in the context of a network map making it easier to communicate effectively with other teams. With a single source of truth to back you up, you can easily find and address the problem or clear the network from blame. NetBrain includes some unique collaboration features to ensure a smooth process. For instance, you can add custom notes to a map or runbook and email embedded map links to other team members. Since all diagnostics data is embedded inside the runbook which is attached to a dynamic map, it is extremely easy to share findings and track results within the context of an incident and the devices involved. I’ll hand it over to Matt now to show you what this looks like inside the software. Over to you, Matt.
Matt: All right. Thank you, Amena. As you see, we’re back on the dynamic map that we used in part one. I mentioned before that runbooks become a permanent part of the map when they are launched and the same goes for any data gathered with a runbook and any notes that you put into it as a user. Everything is contained within the dynamic map file within the NetBrain system. That means that if I have to escalate a ticket, the next tier engineer has all of my data and notes right at their fingertips. They don’t have to re-mine my data. They don’t have to duplicate my work in any way, shape, or form. How cool is that? Think of the time savings, not to mention the savings in aspirin.
Another thing that I haven’t mentioned is that multiple users can actually work on the same map at the same time. Remember, this is a thin client. Everything’s running off the server. All data a map pulls is not only retained, it’s available to all users in real time. User sessions and their gathered data are tracked and accessed via this timeline over here on the right-hand side of the map. Anyone viewing the map has access to the data of everyone who’s used it. Fire up a conference call, send around a map and a whole team of engineers can troubleshoot an issue using the same dynamic map. The map doesn’t even have to be in the shared files within NetBrain. Even privately held maps can be easily shared. If you go ahead and save it, you can just click the ahare button right here. I can either share it to specific users within the system very easily, or I can share it via the very same hyperlinks that we saw in the ServiceNow integration.
In fact, every dynamic map automatically has a unique hyperlink. How cool is that? Now, one final point that I’d like to make is that the self-contained nature of NetBrain’s dynamic maps makes them ideal not only for collaboration and escalation but also for post-mortem review, after-action review, whatever you want to call it, of an incident that’s occurred on your network. Everything that’s done regarding the incident in question is right here in the dynamic map as we’ve established. There’s no wasted time reconstructing the sequence of events. You can see who did what, when, what data was pulled, what’s available, who made what notes and so forth.
The best thing about this is if the review concludes that a change needs to be made to the organization’s procedures, then whoever owns those procedures simply needs to go into the Runbook Center, find the runbook in question, open it for editing, make any needed changes and save the runbook. Just like that, anyone who goes to launch that particular runbook, whether it’s a human launching the runbook manually or an API call that’s been told to look for and run that particular runbook, they’ll all be using the updated version of the runbook procedure. Now, how cool is that?
No more worrying about who’s on the right file share. No more worrying about circulating printed binders. No more having to rely on a spiral-bound handwritten notebook in a fireproof box on the NOC Center. I’ve heard stories about that. It’s all right here within your NetBrain deployment. I don’t think I need to expound any more on how this is better than any traditional approach that I’m aware of. That is everything I wanted to show you for this webinar today. I want to thank you for your attention, and back to you, Amena.
Amena: Thanks, Matt. As we’ve seen in today’s webcast, NetBrain inserts easily at crucial points within IT workflows to kick off automatic diagnosis, enhanced collaboration and enable improved knowledge management among team members. To summarize, executable runbooks are a knowledge repository, a diagnostics console and a collaboration medium protecting you from risk and leaving you free for those strategic projects you’ve been meaning to get to. Our customers collaborate using NetBrain executable runbooks in a wide variety of ways to document and ensure compliance, to accelerate network troubleshooting, often working closely with applications teams, to proactively monitor and prevent problems before they become symptomatic or cause an outage, to work with security teams to defend the network from attack, and to make safer network changes which plays a key role in and impacts larger IT projects such as hardware refreshes, data center migrations and network mergers and acquisitions where network changes are notoriously manual, repetitive and prone to error.
It’s worth noting that while automating common network tasks like a configuration check delivers the fastest time to value, the efficiency gains are largely invisible to the business. With NetBrain, task level automation can now be embedded inside executable runbooks that enhance critical workflows and services. Utilizing runbooks will have greater impact and visibility to the business. They allow you to make a stronger case for automation tools.
With that thought, let’s wrap up. If you like what you saw today, you can request a custom demo live through our website at http://netbraintech.com/request-a-demo, or try NetBrain for free in our virtual trial environment. Matt and I will remain on the line for the remainder of the hour to field your questions. So please keep them coming through the Q&A window. We’ll try to answer a number of them out loud over the phone as well. Once again, thanks for joining us.
As demands on the networks increase and they continue to grow and become more complex, it is increasingly challenging for…Learn More
An Executable Runbook is a programmable set of procedures, which can be used by anyone to automatically collect and analyze…Learn More
A recent report making the rounds from Indeni, in partnership with GNS3, has concluded that in order to be more…Learn More