By High availability environments do not stay static after initial deployment. Infrastructure changes, application versions diverge between primary and backup nodes, and configuration drift accumulates across patching cycles. None of these gaps surface until a real outage forces discovery, at which point the cost in downtime, troubleshooting coordination, and business stakeholder pressure is already compounding.
In this interview on TFiR, Cassius Rhue, Vice President, Customer Experience at SIOS Technology, walks through the most common HA validation gaps enterprises face today, the difference between switchover and failover testing, real-world examples where routine testing caught critical failures before production incidents, and how to build a sustainable HA testing practice that aligns with business patching and disaster recovery schedules.
Guest: Cassius Rhue, Vice President, Customer Experience at SIOS Technology
Show: TFiR
Here is what every platform engineer, DBA, and IT operations team responsible for mission-critical systems needs to know.
Technical Deep Dive
Q: Why is assuming an HA environment will work because it was tested once a dangerous strategy?
Cassius Rhue, Vice President, Customer Experience at SIOS Technology, explains that HA environments are not static. Patch maintenance, application upgrades, and configuration changes introduce new failure conditions that were not present during the original test. Discovering a misconfigured backup service or a skipped update step during an actual outage, rather than during a planned test, creates exactly the chaos and business stakeholder scrutiny that HA is supposed to prevent. Beyond confirming technical readiness, regular testing builds the operational muscle memory teams need to act without panic when a real event occurs.
“Assuming that it will work because it worked once is not a great strategy. It introduces a lot of risk to the business.” — Cassius Rhue, Vice President, Customer Experience, SIOS Technology
Q: What are the most common gaps in HA validation that organizations miss?
Rhue identifies three recurring gaps. First, teams fail to validate architectural parity between primary and backup systems, particularly in cloud environments where compute, network, and storage sizing on the backup node may not match the production workload. Second, organizations stop validation at confirming that application and database services start on the backup, without confirming that client applications can actually connect to those services. Third, testing is scoped only to hard server failures, leaving application-level crash recovery unvalidated by the HA software.
“Having applications or services up and available on the server is a great step. But if clients cannot connect to actually use that service, then you’re not really available.” — Cassius Rhue, Vice President, Customer Experience, SIOS Technology
Q: What is the difference between a switchover and a failover test, and which is simpler to run?
A failover test involves hard crashing a node and validating crash recovery. It does not exercise the application shutdown path because services are terminated abruptly rather than gracefully stopped. A switchover is a manual, user-initiated operation in the SIOS LifeKeeper solution where services are gracefully stopped on the primary in the correct order, fencing is applied as the primary transitions to secondary role, and services are then gracefully started in the correct order on the new primary. A switchover is less invasive than a hard crash but more comprehensive because it validates both the shutdown sequence and the startup sequence, including application health checks on the new primary.
“A switchover is a much simpler test, and it validates both the shutdown operation and that applications and services are started in the right order on the new primary system.” — Cassius Rhue, Vice President, Customer Experience, SIOS Technology
Q: How can teams validate HA readiness without taking applications offline?
Rhue recommends starting with a runbook inspection before any live testing. Teams should verify that every assumption and configuration detail documented in the runbook matches the actual system state on both primary and backup nodes. This visual inspection catches mismatches in configuration files, missing packages, or undocumented changes made during maintenance without requiring any downtime. It also narrows the scope of subsequent live testing, reducing the time applications need to be offline during a planned maintenance window.
“A lot of issues can be eliminated in just validating against your own runbooks and validating that your configuration is accurate.” — Cassius Rhue, Vice President, Customer Experience, SIOS Technology
Q: What is the biggest organizational challenge when testing HA environments in production?
Rhue identifies securing business stakeholder agreement for the maintenance window as the primary challenge. On systems where one hour of downtime can cost $300,000, stakeholders are highly resistant to planned downtime even for proactive testing. The path forward is articulating the financial trade-off directly: a controlled, planned maintenance window with a known cost and duration is categorically less expensive than an unplanned extended outage caused by a configuration gap that could have been caught in advance.
“Taking a proactive measure might cost one fixed amount at a particular time in the year. But having a downtime extended by hours because you discovered the backup server is not configured properly, you want to avoid that.” — Cassius Rhue, Vice President, Customer Experience, SIOS Technology
Q: How does a like-for-like QA environment reduce HA testing risk in production?
Rhue advises building a QA environment that mirrors production with the same services, databases, and applications that will be made highly available, along with test clients and sufficient mock data. This environment allows teams to validate architecture, procedures, and runbooks before touching production, which reduces both the frequency and the duration of production maintenance windows required for live HA testing. Rhue is explicit that a QA environment reduces but does not eliminate the need for production testing. Production validation remains necessary.
“It reduces how much testing you would have to do on a frequent basis. But you still need to test in your production environment.” — Cassius Rhue, Vice President, Customer Experience, SIOS Technology
Q: What real-world example shows how routine HA testing caught a hidden misconfiguration before an outage?
Rhue describes a recent engagement where a partner was setting up a system for an end customer and engaged SIOS to validate the installation. During the first validation test, the team discovered that one protected service was configured for automatic start, meaning it would start outside of the HA solution’s control. When a service starts this way, it serves stale data because it is not under HA monitoring and recovery. In some configurations, a service starting in this state can also lock out all other clients from accessing the data. Catching and correcting the configuration before production deployment prevented both a data integrity issue and a potential access outage.
“Finding that prevents an outage, it prevents an error, and it prevents data integrity issues because you’ve detected it early and corrected the configuration.” — Cassius Rhue, Vice President, Customer Experience, SIOS Technology
Q: What happens when client software is hard-coded to a physical server IP address in an HA environment?
Rhue describes a case where an end customer had deployed the SIOS LifeKeeper high availability solution protecting several databases and applications, but all client software had been configured to point to the physical server IP address of the primary node. When a failover occurred and services started on the backup server, every client lost connectivity because the hard-coded IP address no longer resolved to the active node. Routine testing in the customer’s environment identified the misconfiguration, the client configurations were updated, and a retest confirmed that failover and client reconnection became seamless.
“Testing and validating in the customer’s environment helped us find that early, make that change and adjustment, and then get things corrected and retested in a way in which the failover and client reconnectivity became seamless.” — Cassius Rhue, Vice President, Customer Experience, SIOS Technology
Q: What does a real production outage look like when HA testing was skipped entirely?
Rhue describes a business-critical production down event involving a client who declined SIOS validation services, did not perform their own post-maintenance testing, and had no QA environment. A data center power outage triggered a failover to the backup server, where the database immediately failed because packages updated on the primary during maintenance had not been installed on the backup. After the database was stabilized, the application itself failed because configuration parameters stored in a local config file on the primary had never been replicated to the backup. The incident required simultaneous coordination across on-call engineers from the application team, the database team, and external vendors, with on-call staff who were not the original architects of the system.
“Instead of it being a simple failover where everything starts up seamlessly on the backup without clients noticing, that turned into a major outage event and cost them significantly.” — Cassius Rhue, Vice President, Customer Experience, SIOS Technology
Q: How should organizations rethink HA testing as AI workloads and cloud-native applications are added to the environment?
Rhue argues that HA and resiliency must be treated as requirements from the start of any new workload project, not addressed after deployment. This means factoring recovery from power failure, application failure, and database failure into the requirements phase, the architecture phase, and the design phase. Runbooks should be built to reflect the HA strategy for every workload. Rhue also notes that AI tools can assist in developing these designs, validating architectures, and generating runbooks based on workload requirements. Regardless of tooling, routine testing must be built into the ongoing strategy for each workload.
“It can’t be something that you think about at the end after all of these projects and workloads have been deployed. It’s something they need to be thinking about during the requirements phase, during the architecture phase, during the design phase.” — Cassius Rhue, Vice President, Customer Experience, SIOS Technology
Q: Where should teams start when building a regular HA testing practice and what cadence is realistic?
Rhue recommends anchoring the HA testing cadence to the existing business patching and update schedule. If an organization runs monthly patching, the HA test plan should include time to validate in the QA environment before each production rollout. Organizations that run quarterly or biannual disaster recovery exercises should layer HA validation into those exercises. The starting framework is driven by two questions: how often does the production environment get updated, and what regulatory, certification, or business requirements govern disaster recovery frequency for the specific industry.
“Use your business requirements as the groundwork or framework for how often you do the testing. How often do you need to update your production nodes? How often do you need to do disaster recovery scenarios?” — Cassius Rhue, Vice President, Customer Experience, SIOS Technology
Q: How can automation reduce the burden of continuous HA validation for stretched IT teams?
Rhue points to automation frameworks that integrate test functionality for applications, services, and HA environments as the most practical way to reduce friction and increase testing frequency. SIOS provides an extensive command line interface that supports automation through scripting or tools that interface with a CLI or API. This allows teams to automate end-to-end patch maintenance workflows including deploying patches, restarting applications, testing failover, testing failback, and testing switchover and switchback. Both Linux and Windows operating systems provide native commands to stop databases or crash application services, which can be combined with HA CLI commands to validate that recovery occurs correctly without manual intervention.
“SIOS has an extensive command line interface that you can use for automating either through scripting or through automated tools that simply interface with a CLI or API.” — Cassius Rhue, Vice President, Customer Experience, SIOS Technology
Resources & Documentation
- SIOS Technology, provider of the SIOS LifeKeeper high availability solution for Linux and Windows environments protecting mission-critical databases and applications
***
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: When it comes to high availability, most enterprises assume that their high availability setup will hold when needed. Their teams build it carefully, they tested it and it works just fine and then they moved on. But HA environments don’t stay static. Infrastructure changes, new workloads arrive, configuration drift also happens and most teams never go back to validate when whether that setup that was created once will actually hold under real conditions until a real outage hits, which leads to chaos, panic and of course, downtime. And today we have with us once again Cassius Rhue, Vice President of Customer Experience at SIOS Technology, to walk us through the simplest way to actually know if your HA setup will hold today. Cassius, first of all, it’s great to have you back on the show.
Cassius Rhue: Yeah, it’s great to be here. It’s good to hear your voice and good to see you and enjoy being with you and looking forward to diving into our topic today.
Swapnil Bhartiya: Yeah, it is really exciting to talk to you and I think this is also very, very important topic. It’s more or less like it’s not as same as that your car has airbag or seat belt and it will work when you need it. You need to keep testing, you need to keep checking. Most organizations don’t do that. They assume that their HA environment will work when they need it, but they don’t regularly test it. Can you talk about why is that assumption that hey, you know what, we have a very stable SDA setup which we tested once. Why is that assumption so risky and what are the most common gaps that you see in HA validation today?
Cassius Rhue: Great. Yeah, those are two great questions. Let me break them apart into two. First, it’s a risky assumption when you’re making changes, you’re doing updates even when you do the initial deployment. To think that everything’s going to work fine without doing actual testing during an actual outage or an emergency. That’s not the moment that you want to discover that a backup service is misconfigured or incomplete or that when you are doing maintenance that you forgot a step on the backup server whereas you were able to validate things were running correctly on the production. But maybe you skipped an item. So assuming, assuming that it will work because it worked once is not a great strategy. And it introduces a lot of risk to the business. A lot of risk that’s unnecessary for the business. And when an emergency happens, that’s when you discover those incompatibilities that leads to, as you mentioned in the intro, that leads to chaos, that leads to panic, that leads to business stakeholders wanting to understand what happened and what were the gaps. So testing and practice are critical components of business resilience planning. They show that you have a well planned and thought out solution. When you’re updating your servers, either through patch maintenance or you’re doing updates to the application versions on upgrades, doing that testing reduces the risk and helps you build muscle memory. So it’s not just an exercise of will it work, but it’s also an exercise of do we understand how to operate in an actual outage event and get you that muscle memory so that when an actual event happens you’re not going to panic? You know, as far as the most common gaps I see, you know, one of the worst gaps we used to see early on was the gap between customers that did nothing at all and those that did just something. And that always leads to panic when you do nothing. When you have done updates and you don’t test a failover or switch over. When you’ve done upgrades of your application and you’ve not validated that they were updated correctly on both target and source, that gap used to be a really prevalent thing. And thankfully most customers realize that they have to do some validation. But I still see gaps with customers and their strategy for testing. The first gap that I notice a lot of is just the gap of not validating your actual architecture. So with the emergence of cloud and that usage growing and increasing, we see a lot of customers taking advantage of cloud resources and forgetting to validate in their architecture. Did they have the right sizing for compute or network or storage? That’s the first gap that I see is just not understanding. Are the systems identical in size? Are they both capable of handling the actual workload? And then once they have identified the architectural challenges and verified there are no gaps there, there’s still gaps around failover testing to make sure that client applications can connect. Some clients that we’ve worked with in the past simply wanted to check off did their application or database or service start after a system failure test. But you have to take that a bit further. Having applications or services up and available on the server, the source or primary or target or backup, whichever language you use, that’s a great step. But if clients cannot connect to actually use that service, then you’re not really available. And then lastly, I’d say that there are customers who who tend to forget to validate what happens if their application crashes. They focus their testing solely on hard server outages, but they forget that applications also need to be validated. If they crash, can the HA software successfully recover it.
Swapnil Bhartiya: Is there a simple way to test whether an HA setup really works? And if yes, what does that process looks like? And how does it differ from. From traditional failover testing?
Cassius Rhue: Yeah, great, Great question. So I’ll break it up and say that a lot of the traditional testing has been focused solely on can we do a failover, can we hard crash or hard power off a node, and will it recover? Will the backup server take over operations for the application and databases? And there are other ways to do that validation. There are simpler ways. One with the sios lifekeeper solution. One of the easiest ways is what we call a switchover, and that’s a manual user operation where services are gracefully stopped on your primary system and then in the correct order, gracefully restarted on the backup server. The difference is in a failover scenario, you’re going to hard crash a box and you’re going to. That failover doesn’t validate that you’re able to successfully stop the application, so it doesn’t go through any shutdown procedures. You’re just doing crash recovery. A switchover is a much simpler test, and it validates both the shutdown operation, making sure that applications are shut down in the right order, that fencing is in place as the server transitions from its role as a primary to its role as a secondary or backup, and then also that applications and services or databases are started in the right order on the new primary system, and that fencing is now in place. And that’s a much less invasive test than hard crashing a node, but it also is a more comprehensive test because it’s going to hit the shutdown scenarios as well as the startup scenarios, and then also add into that for many HA solutions on the startup scenario, they’re going to validate that the application is running correctly. One other thing to add to that simple test, a lot of issues can be eliminated in just validating against your own runbooks and validating that your configuration is accurate. So many of our customers create runbooks, and a very simple, easy thing to do is to validate that the assumptions and configuration details outlined in your runbook actually match the actual system. And so that can actually be done without crashing a node or taking applications offline. It’s an inspection, a visual inspection first. And then, of course, we can move into these scenarios of testing a switchover or even the hard failover scenario.
Swapnil Bhartiya: Can you talk about what are the biggest challenges organizations face when testing HA environments in production, and how can they reduce risk while still building confidence in their system?
Cassius Rhue: Yeah, so one of the biggest Challenges. I’d say the biggest challenge I have seen organizations face when trying to test HA environments in production is securing agreement from the business stakeholders for the maintenance window required for that testing. That’s also getting business justification and building a story for the key stakeholders to sign off. We’re talking about Systems where even one hour of downtime could be as expensive as $300,000. These stakeholders are very hesitant to have those systems offline. And so the challenge becomes, for those who are responsible for maintaining those systems, who are responsible for guaranteeing that the system will be available in a crisis, that failover will work, is making those stakeholders aware that doing this proactive testing, while it may cost some time for the system be offline or in maintenance mode, it also adds some resource costs that you can explain to them the savings that happen when you’re not in chaos mode, when you’re not scrambling to figure out what happened, why the backup server is not properly configured, or why there’s an error between application versions, or why some particular client application is unable to reconnect. So articulating the value will help you overcome that challenge. For businesses that are really hesitant to take a maintenance window for that the other way to, you know, so reducing that risk or hesitancy is just articulating the value of doing testing in advance, right? Making them aware that taking a proactive measure might cost one fixed amount at a particular time in the year where it’s least critical to the business. But having a downtime extended by hours because you discovered the backup servers and not configured properly, clients are hard coded to a particular address or data hasn’t been synced properly. You want to avoid that and just explain to the business that in the long run, doing that testing reduces the cost and risk of chaos. Another way that I advise our customers to reduce the risk and reduce that kind of hesitancy about using HA production systems for all of your testing is to make a like for like copy of your production environment, right? So that’s establishing a QA environment that has the same services, databases or applications that are going to be made highly available, making sure you have test clients and that you have sufficient mock data and other supporting software in this QA environment. And then you can go through a lot of your tests and have the confidence that things are going to work because you’ve validated a lot of your architecture, you validated a lot of your procedures and runbook, and that does reduce the risk. Now, I want to say that reduces the risk and the hesitancy of testing and production, but it does not eliminate it. You still need to test in your production environment. It just reduces how much testing you would have to do on a frequent basis.
Swapnil Bhartiya: Is it possible for you to share a real world example where routine HA testing uncovered a hidden issue that would have only surfaced during an actual outage and would have actually caused downtime and chaos?
Cassius Rhue: Yeah, we actually have two in fact, one is very recent, as recent as earlier this week. So in the first one, we were actually working with a partner who was setting up a system for an end customer, and they engaged with us to do some testing to make sure that after their installation and updates that the system was working correctly. And our very first validation test, we discovered that one of the protected services was misconfigured. In this particular case, the service was set to what’s called automatic start. So it actually would start outside of the HA solution. And when that occurs, the data that it would serve up would be stale data because it was not a part of the HA monitoring and recovery. By detecting that early, we were able to go in, change the configuration so that it would not start outside of the HA solutions control, and make sure that it was always going to be pointing to the latest set of data, you know, if that had been found during a real world scenario. Just think of how long it may have been before the end customer discovered that they were receiving stale data. Or in some examples related to this particular environment, the client application can start in a way in which it no longer allows anyone else to access the data. And so finding that prevents an outage, it prevents an error, and it prevents data integrity issues because you’ve detected it early, you’ve corrected the configuration, and then you went on to further validate that things are working properly with the HA solution. A second one related to that, to a client realizing that they had configured all of their client software. So our end customer had an HA solution in place using our sios lifekeeper high availability solution. They were protecting several databases and applications. Their clients, however, were configured originally to point to the physical server IP address. And so once the application services and databases failed over to the backup, those clients could not connect because they had been hard coded. Testing and validating in the customer’s environment helped us find that early, make that a change and adjustment, and then get things corrected and retested in a way in which the failover and client reconnectivity became seamless. And that’s something you don’t want to find during an actual outage, because of course, when there’s an outage, you’re having to troubleshoot, you’re having to do a lot more root cause analysis, you’re opening tickets with multiple vendors, you’re trying to coordinate understanding and what are the symptoms and signs and problems. And one thing that often gets overlooked, if the applications or databases are up and running, then you’re having to go look and see, okay, what happened with clients and that and that panic and chaos and that moment where you are scrambling is something that can be missed. So testing in real world scenarios helped us find that before it became an issue in an actual disaster. And then one. Recently we had a client that did an upgrade of their primary system, but forgot to actually do the upgrade on the backup system. And they called us in because they wanted to do some testing. And what we found is that there was a configuration file that needed to be updated on both servers. And that was something that we needed to make sure that they were able to run through. And that allowed us to to find the issue, update the configuration file, and also update their runbook. So now going forward, they know the procedures and steps they have to do for updates of the operating system, updates of their critical database, updates of their client application, and they know how to test it in a proper manner and where to validate that things were done correctly. And so that saves them a lot of time. Of course, if you’re in an actual disaster, you’re looking at, okay, well why didn’t this work? And you’re starting with troubleshooting steps. And often these are the little nuances that you might miss. While there are 21 executives wondering why their business is losing money by the second.
Swapnil Bhartiya: Now let’s flip this coin. Can you walk us through a scenario where an HA environment looked perfectly healthy, but the absence of routine testing led to real problems when a flailover event actually happened?
Cassius Rhue: That’s a great question and it’s a very vivid example in my mind because of how many different organizations were involved in this particular incident and how long it took to resolve and remediate the problem and the fact that it was a business critical system and a live production down event. So we did have a client who set up their system with our software and they went through some what they considered to be routine maintenance. It was actually turned out to be more than routine maintenance. But for time constraint pressures, or business pressures or stakeholder involved pressure, this particular client opted, you know, first to decline services that we offer for validation and testing. And then second, they also decline to do that testing themselves to make sure during their maintenance window that they that the failover would work or that the applications would run on the backup. A third thing that we’ve kind of touched on earlier, they also did not have a test environment where they could run these updates prior to rolling them out to production. And so all of the updates were made on their production system. Things appeared to be healthy on the production node. They had an outage, a power outage in their data center. Things attempted to fail over to the backup server. And that’s when they discovered that there were during the upgrade of the primary, there were some configuration changes that were made. There were also some libraries and packages that had been updated to a newer version that did not exist on their target system or their secondary. When it came time to start the database, the database failed with some errors related to those updated packages that were missing the application. When they were able to troubleshoot the database and get it to a running and working state, the actual application failed because there were some configuration parameters that had been made on the primary and stored locally in a config file had not been replicated or synced to the backup server. In a scramble, you have a team member from their organization, from the application team trying to troubleshoot what’s going on, why the application won’t start. A lot of times you have in an emergency like that, you may not have the architect of the application available. And so you’re dealing with an on call engineer from the app team, an on call engineer from the database team. You may be dealing with folks that are not as familiar with the system. And in that emergency situation, this particular customer was trying to figure all of these things out at one time. You know, ultimately their resolution was to update the packages on that target system, update the configuration file and update the database so that it would all start and run that outage. Instead of it being a simple failover, power failed in the primary data center. Everything starts up seamlessly on the backup without clients noticing it. Instead, that turned into a major outage event and cost them a significantly. Whereas a routine test would have identified all of these issues and would have saved the business a lot of money.
Swapnil Bhartiya: Now let’s talk about one of the biggest topics these days is AI. As enterprises take on AI workloads, of course, cloud, native applications and mission critical database, which is already in the wheelhouse of Cyrus. Either way, how should organizations rethink HA testing as part of their broader resilience and business continuity strategy thanks to these new workloads, especially around AI?
Cassius Rhue: Yeah, that’s a great Question. I think you hit it in your lead into the question. Organizations have to think of HA and resiliency as a part of their strategy. It can’t be something that you think about at the end after all of these projects and workloads have been deployed. It’s something that they need to be thinking about during the requirements phase, during the architecture phase, during the design phase, as the project plans are developed, thinking about, how will we recover from a disaster, how will we recover from a power fail or from an application failure, database failure? And building that resilience, building that monitoring, building that concept for high availability into the architecture layer, leveraging it as a part of your runbooks and making sure that for whatever strategy you have deployed, that you’re making sure that you test it. And then one of the things that AI tools provide, they will give you a lot of capabilities for developing these designs, for validating these architectures, for even creating some of these runbooks based on your requirements, based on what workloads you have involved. And then, of course, as we’ve been talking about over and over again, is making sure that you build routine testing into that strategy.
Swapnil Bhartiya: Let’s assume that there are teams who are just starting to build a regular HA testing practice. Where should they start and what does a realistic cadence look like for them?
Cassius Rhue: Yeah, that’s a good question. If you’re, if you’re just starting by building out an HA test infrastructure, right? So let’s assume that you’ve made sure you’re doing a like for, like copy of production. What you want to look at is what we tend to see with a lot of customers and recommend is what is your business cadence, Right? So there are a lot of organizations that are doing monthly patching. And so you want to make sure you’re matching your HA testing to the cadence of the business. If you’re doing patching every three weeks, then you want to make sure your test environment is set up and that your plan is. Your project plans include time for you to test and validate in that QA environment before you start doing the rollout on your production system. There are also organizations that in addition to their monthly patching or update strategy, they’re also doing like a quarterly or biannual disaster recovery exercise. And so I would say start with looking at your business requirements. How often do you need to update your production nodes? How often do you need to do disaster recovery scenarios either to satisfy a business requirement, a regulatory requirement, or a certification requirement for your, your particular industry and use that as the groundwork or framework for how often you do the testing?
Swapnil Bhartiya: Are there specific tooling or automation approach that makes continuous HA validation more practical without burdening already stretch it teams and how does SIOs help there?
Cassius Rhue: That is a really good question and great thing for teams that are thinking about testing or trying to make that burden lighter. Automation can play a huge role in reducing the friction, reducing the cost, and increasing the frequency of doing that testing. A lot of tools exist out there, so I won’t name specific ones, but what you want to look for is a framework that allows you to integrate key test functionality for your applications or services and your HA environment. We talked about tests that do hard failures and then making sure that applications and services restart. So you want to look for automation tools that allow you to have a framework that can simulate node failures that can activate the HA solution functionality. A lot of HA solutions like Siosios has an extensive command line interface that you can use for automating either through script scripting or through automated tools that simply interface with a CLI or API and that allows you to say which particular commands are most important for your test environment. If you’re for example doing patch maintenance, you can automate everything from deploying the patches, restarting the application, testing the failover, testing a fail back, testing a switch over switchback. There are lots of commands in each operating system, whether it’s Linux windows that allow you to do things to crash application services or stop databases. And then you can use those automated HA tools or HA clis to validate that things recover properly.
Swapnil Bhartiya: Cassius, thank you so much. This has been a great conversation. Thank you for breaking this down so clearly and giving our viewers something they can actually act on. And I would recommend encourage everybody who is watching it to check out science technology to learn more about how they can help their organizations protect mission critical systems. Cassius, once again thank you for joining us and I look forward to chat with you again. Thank you.
Cassius Rhue: Thank you so much for having me and look forward to our next conversation.
