One place for hosting & domains

      Downtime

      Planned vs. Unplanned Downtime


      Downtime is a part of doing business and some downtime should be factored into any compute environment. Planned downtime is much easier to prepare for because you’ll often be notified will in advance of that planned downtime.  Check your provider’s Service Level Agreement to better understand their Planned Service Outage policies so you know how much notice they are required to give for any scheduled maintenance.

      Best Way to Prepare for Planned Downtime

      It’s always a good practice to have Disaster Recovery Plan in place when you first initiate your environment. Some factors to consider include:

      • Planned Infrastructure Downtime
        • Is your infrastructure backed up in a secondary location?
        • How will users access the environment in that secondary location?
      • Planned Network Downtime
        • Do you have alternate access to your environment through a secondary connection?

      A well-documented Disaster Recovery Plan that is easily accessible to all relative parties will greatly reduce adverse impact on your business during planned downtime. In this case, when your provider notifies you of a planned outage, you will be able to schedule your Disaster Recovery Plan for the appropriate time.

      Best Way to Prepare for Unplanned Downtime

      Unplanned downtime is significantly more difficult to prepare for due to the basic fact that it’s unplanned. As a result, you will not have the luxury of time to implement your disaster recovery plan. In order to best protect yourself against Unplanned Downtime, you’ll need to implement a real time Disaster Recovery Plan where your entire environment is replicated in a remote data center and can automatically be accessed during the unplanned downtime. Factors to consider in this example include:

      • How much time can you allow to pass?
        • Recovery Point Objectives (RPO) determine how much time will pass between the time of the outage and the time that your disaster recovery plan takes over.
          • If your environment is very transactional, you may require real-time replication (synchronous replication) of date between your primary environment and your DR environment. If that’s the case, you’ll want to keep your DR environment within the same metropolitan area so as to adhere to the latency requirements for real-time replication.
            • Keep in mind that if the unplanned downtime in that area is related to a regional natural disaster, your DR site may also be affected.
          • If your environment is less transactional, and you do not require real-time replication, (asynchronous replication) you may want to consider hosting your DR site in a remote location that is not likely to be affected by the same regional anomalies as your primary environment.
      • How will you connect to your DR environment?
          • If you are connecting to your primary environment via a private WAN, will you create a secondary node off your WAN, or connect via an IPSEC VPN across the global routing tables
          • Do you currently employ a dynamic DNS provider to automatically reroute traffic to the DR environment in the event of unplanned downtime in your primary environment?
          • The best way to prepare for any unplanned downtime is to be prepared with an automated disaster recovery plan that will automatically take over when the unplanned outage

      Biggest Mistake When Preparing for Planned Downtime

      The biggest mistake an organization makes when preparing for planned downtime is not keeping their contact lists up to date. Your provider will have a list of contacts that are to be notified when any outage is planned. In the tumultuous world of tech, there is often high turnover and organizations fail to keep records with providers up to date. If a notification goes out to your organization and the contact info the provider has is not up to date, you may never know about the planned downtime. This will result in UNPLANNED downtime.

      Biggest Mistake When Preparing for Unplanned Downtime

      The biggest mistake organizations make when preparing for unplanned downtime is NOT having a plan. Too often, an organization will exhibit a certain amount of hubris because they’ve never had an outage; or they’ve researched the costs of replicating their entire environment and have decided that the cost is greater than the risk, only to learn that they misjudged their tolerance for downtime and have lost significant revenue due to the unplanned downtime.

      Business Continuity

      Business Continuity: It’s not just an industry term. It’s about ensuring your applications work for the people that rely on them. It’s about meeting expectations that you’ve worked tirelessly to set. It’s about protecting your reputation from the inevitable.

      Michael Maggio
      • Director, Technical Architects


      READ MORE



      Source link

      How To Migrate Any Cloud Application With Minimal Downtime


      How to Join

      This Tech Talk is free and open to everyone. Register below to get a link to join the live stream or receive the video recording after it airs.

      Date Time RSVP
      April 27, 2021 11:00–12:00 p.m. ET / 3:00–4:00 p.m. GMT

      About the Talk

      Don’t get stuck with a cloud provider just because you don’t know how to escape! Learn how to migrate with confidence and perform a low or zero-downtime cloud migration of all or part of any application.

      What You’ll Learn

      • How to audit your infrastructure in preparation for a cloud migration
      • How to effectively plan and execute a migration
      • How to build applications with possible future migration in mind

      This Talk Is Designed For

      Business leaders and entrepreneurs who want to avoid vendor lock-in by understanding how software applications move between cloud providers.

      Prerequisites

      Knowledge of web technologies and Infrastructure as a Service (IaaS) products.

      To join the live Tech Talk, register here.



      Source link