[Progress News] [Progress OpenEdge ABL] Disaster Recovery & Business Continuity for Digital Products

Status
Not open for further replies.
S

Suzanne Scacca

Guest
Disaster recovery isn’t just something you have to think about as a home or business owner. If you build digital products, you need to think about how things like natural disasters, coding errors, MIA employees and other situations may negatively impact what you’ve built. We’ll go over some things you can do to create a plan to prepare and deal with these unfortunate situations.

When you build a website or app, the majority of your focus is going to be on all the good that comes from it. The leads from search engines. The engaged users. The growing profits.

I hate to be a Debbie Downer, but are you also thinking about what happens if things go wrong with the product? I’m not talking about a product that isn’t being well-received by users. That’s the kind of problem that can be worked out by the UX design process.

No, what I’m talking about is a situation that’s out of your control. Natural disasters. Server outages. Security breaches. Those sorts of things.

What’s your plan if something bad happens to the products you’ve built? In other words, how are you going to get them back online? And what sort of measures are you putting in place ahead of time to minimize the impact of a disaster?

This is what a disaster recovery and business continuity plan and checklist will help you sort out.

Putting Together Your Disaster Recovery and Business Continuity Checklist​


Obviously, you don’t want anything bad to happen to the products you build. Many of the disasters I mentioned above can’t be avoided though. What can be avoided is the high costs associated with them.

So if you’re able to put together a disaster recovery and business continuity plan as you build a product, you can help to prevent disasters, prepare for the ones that do occur and mitigate your losses.

Let’s take a look at what that looks like with regards to a website or app:

1. Anticipate Your Disasters​


Create a list of all the disasters that can negatively impact your product. Don’t be afraid to think outside the box.

For instance, these are some of the more common types of disasters that can cause a product to go down or otherwise be disrupted:


  • A utility failure at the server level that causes your product (and all the other ones hosted there) to go down. We see this kind of thing all the time with popular applications that use AWS technologies.


  • A cybersecurity breach. While distributed denial of service (DDoS) attacks will take a product offline completely, other kinds of security breaches can be just as harmful—like a hacker that defaces a product.


  • A coding error that breaks a key component or the entire product. In some cases, they’re caused by human error. In others, the issue goes beyond cleaning up a mistyped string of code. When two pieces of software conflict, they can break your site, replace it with the white screen of death, and force you to do trial-and-error to identify the culprits (not to mention find software replacements so that the conflict doesn’t occur again).


  • An unexpected traffic surge that takes your product offline. While many of these surges can be anticipated—like around the holidays or big sales events—some cannot. If a blog post on your site were to go viral, for instance, your server might not be able to handle an onslaught of traffic.

These disasters have to do with the technology of your product as well as the technologies that support it. But there are other disasters that can do your products harm.

For example, natural disasters might not harm the product itself or force it offline since most web hosting companies have a system of failover built in at the server level. However, natural disasters like floods, hurricanes and blizzards might cause power outages on your end or, worse, physically displace you.

If you are an integral part of a product’s ability to stay online and to thrive, your absence or inability to manage the product could be considered a disaster. So don’t forget to factor in how a disaster within your own life—or that of other team members—should be dealt with in order to ensure that you can continue to manage the product even if your home base is under water, so to speak.

It’s not just physical disasters you have to think about either. Consider what would happen if you or another key team player were to go MIA. Just like natural disasters, it’s not easy to anticipate personal illness, injuries or tragedies. While it might not be a nice thing to think about, it’s important to consider how that would affect things.

So go ahead and create your list of disasters. This will help you determine how extensive the damage would be to your product and brand if any of them were to occur. Then work backward and devise a plan to safeguard against these threats.

2. Be Proactive in Protecting Your Product​


Next, come up with a list of things you can do to be proactive about protecting it from different kinds of disaster. Here are some ideas:

Security
Every website or app you build should be secured at every level—the server, the product itself and the browser.

Review your hosting plan to see how things are looking security-wise. Check the following:

  • The server facility’s on-site security
  • Software and hardware security hardening
  • Monitoring and communications with regards to your product’s security

Also, check to see what type of security add-ons they offer. For example:

  • SSL certificates
  • CDNs
  • Advanced security protection and monitoring

Depending on the type of data that passes through your website, it may be worth paying more to harden your security at the server level. You may also want to add more security features at the product level via plugins or extensions. For example:

  • Two-factor authentication at the login
  • Password strength requirements for all users
  • Anti-malware protections
  • Spam blockers for contact and comment forms
  • Secured checkout software

Security isn’t just good for protecting your product from disaster. It’s also vital for keeping your users’ privacy and data safe.

Backups
When a disaster takes your product offline, there’s no time to waste. Every second that your product is down is costing you money.

By saving daily backups of your product, you won’t have to stress about that. You might also want to consider saving a backup to your backup. I once had a plugin crash on me mid-restoration and it killed the previous 30 days of backups on me. So not relying on just one set of backups or one tool to manage them with will be useful.

Applications
Another thing to consider is where you do your work. If your workflow isn’t managed from the cloud, then any damage done to your machine (or a teammate’s machine) could be just as harmful as a lost backup of your product.

Check to ensure that all:

  • Your apps are cloud-based
  • Your communications are taking place over secure, cloud-based platforms
  • The work that’s being done—from note-taking to designing—is saved in the cloud and not on individual devices

It’s also important that all of these tools be collaborative. If a key team member disappears, so too could all the information locked away inside the app they control.

Team
This isn’t like school where you have fire drills (or whatever kinds of crazy drills they’re doing these days). However, it’s still important for your team members to be aware of the safeguards you have in place in case disaster strikes.

For starters, saving your disaster recovery checklist in the cloud—in a place that everyone has access to—will be useful. This way, whoever is available post-disaster will know where to turn to get things back up and running again.

Also, having a chain of command set up ahead of time is a good idea. For instance, let’s say you’re the lead designer for the product. If your system should crash or you go MIA for whatever reason, other people should automatically know who is going to pick up your responsibilities.

In order for this to work, your processes (and everyone else’s) will need to be well-documented and saved in the cloud so they’re easy to replicate. Same goes for your project management system. It should be kept up to date so there’s no question as to where things stand with your products.

Insurance
Whether you work alone or on a team, having insurance that protects you in the case of equipment loss is a must. While it’s critical to ensure that your product stays online, it’s just as vital that you’re able to get back online if your systems fail—and without having to take a huge financial hit in doing so.

For freelancers, you can get these types of protections built into your renters or home insurance if your area is particularly susceptible to natural disasters.

3. Create a Post-Disaster Plan​


Different disasters will call for different kinds of recovery steps. As you put together your post-disaster plan, you might want to think about creating different plans based on the types of disasters you noted earlier.

Here are some steps to consider adding to your plan or plans:

  • Confirm that the product is down or that a feature is broken for everyone (and not just someone’s particular browser).
  • Identify what caused the error or issue.
  • Notify all related parties about the situation—internally within your team and externally with any clients or partners.
  • Restore the most recent backup, if possible.
  • Post-restoration, walk through the product one page or screen at a time to ensure everything is intact.

Something to consider is what you’re going to do if a critical part of your product stops working. That in and of itself is a disaster.

Make a list of the most critical functions of your product. For example:

  • Login
  • eCommerce and all the features associated with it—from product search to checkout
  • Live chat or chatbot
  • Customer support portal
  • Forms—contact, subscriber, comment, reservation and so on

While a security and uptime monitoring system can tell you if there are issues with downtime, they won’t tell you if a key component of your product breaks. So this means keeping an eye on your product and regularly testing it. It would also be helpful to add a feedback form or widget to your site to encourage your users to submit error and bug reports as they encounter them.

Add recovery steps and workarounds for each of your critical features to your plan. These may include:

  • Troubleshoot the broken feature.
  • Deactivate app or plugin and install a replacement.
  • Test restored feature and associated configurations (like email notifications).

One other thing to factor into your planning is what to do if your users are negatively impacted. I’m talking like a major security breach where their data has been stolen. Here are some ways you might address this situation:

  • Send out messages on social media to inform customers of the issue—from a website that’s gone temporarily offline to a big security breach.
  • Email users and customers who may or may not have been affected and give them an action plan. For instance, request that they change their password right away.
  • Activate additional support for customer service channels to manage complaints, questions, concerns, etc.
  • Engage your legal representative.

Even if this isn’t in your wheelhouse, it’s something that the owner of the product will need to do. So it’s good to have these items in your plan so that you remember to check in with them and ensure that they’ve done everything to keep users satisfied with the product despite the bad situation.

Wrap-up​


The consequences of a disaster can be mighty ugly. For instance, a product without a recent backup could mean having to rebuild all of it from scratch. On the other hand, a hacked product might be simple enough to restore, but restoring brand trust with all the users whose data was hacked will not be.

You don’t want to wait for a disaster to occur to react to it. If you can be proactive about protecting your product from disaster, implementing measures to restore it, and minimizing the negative impacts now, you can downgrade many of these events from “disaster” to “that was a close one.”

Continue reading...
 
Status
Not open for further replies.
Top