Service Level Agreements (SLA’s) assure potential customers that your Software as a Service company will live up to your client acquisition team’s promises; however, it is also important to make promises that you can keep, and avoid making promises that are not in anyone’s best interest. Ultimately, you want your new customer to have a long and happy life on your SaaS, and trust is a key component of long-term relationships. Don’t sabotage that with a poor SLA.
Posts Tagged ‘uptime’
Ten steps to keep your site online during a rush of traffic.
Trying to go viral? Planning on a lot of site traffic? Our techs have helped sites stay online during Super Bowl ad campaigns and opening weekend movie premiers. And along the way, they’ve learned what it takes to stay online during a massive flood of traffic.
So before going live with the next greatest Internet meme, here’s a checklist of what to do to keep your site alive:
- Understand the scope of the project. How many people will be exposed to your campaign? What is the expected turnover rate? What time of day do you expect traffic to hit your site? How will your site’s application handle a dramatic increase in visitors?
- Allocate enough time for planning. The right amount of prep time depends on the scope of the project. Is one week really enough time to bring everything together? One month? The bigger the project, the more time you will want in advance to make sure everything goes smoothly.
- Be prepared for all the what-ifs. Expect the unexpected; people, especially visitors to your site, never behave exactly the way you expect them to. Map out all of the scenarios and have a plan ready for them.
- Have a back-up and back-out plan. As much as you prepare for success, never assume that failure is impossible. Failing gracefully can make a big impact on retaining the trust of your visitors. Also, you don’t want to lose valuable data. If your site crashes under the load, make sure you can retrieve the data gathered before the crash.
- Make sure your configuration is scalable. Being able to add an additional web server without downtime means that you won’t interrupt the traffic surge in order to accommodate an unexpected volume of visitors. If your site relies on a database or dedicated application server, make sure you can add more power to these areas, as well.
What Your Web Host is Not Telling You about 100% Uptime
In a perfect world your website would be available all day, every day, completely without fail. In reality, downtime happens. Hosting providers like to guarantee uptime, but what does that really mean? Here are three things your hosting provider isn’t telling you about 100% uptime:
#1 – Uptime is your responsibility, too.
When you talk about uptime, you mean that your site is available to your audience. When a hosting provider talks about uptime, they mean network uptime, and possibly hardware availability if you are using shared resources instead of dedicated servers.
In a dedicated hosting environment, device availability and fault tolerance are your responsibility. If a hard drive fails, did you purchase a RAID configuration to protect yourself? Did you elect to build out a database cluster? Redundant firewalls?
Application availability is also affected by your developers. In many cases, changing a single file can drop your site off the radar, even though the pipes are live and the hardware is functional. Do you have a separate development area to prevent this kind of thing from happening? What controls do you have in place to make sure that only stable edits are pushed live?
#2 – Downtime happens. There is no preventing it.
5 Easy Steps to Move Your Site to a New Host – Without Downtime or Data Loss!
Minimizing traffic loss and preventing downtime in a server migration comes down to planning. If you do not take care when you move your website, significant outages can take place. This translates to a number of potential negative consequences for your business including revenue loss, impact on search engine rankings, and damaged customer relationships.
Most failed server migrations can be traced back to poor planning and/or a lack of careful execution of a plan. If planned and executed right, successful migrations can result in no downtime or data loss. At minimum, you can severely reduce the impact of a server transfer by following this easy 5 step approach.
What you need to pull this off:
- Server environments running parallel at your current host and new host. This is a minimum requirement to transition smoothly because taking your old servers down before uploading your data on new servers equals major downtime.
- The ability to control DNS transfer at the record level with the ability to control Time to Live (TTL) – either through a control panel or via helpful hosting company admins. This is critical in minimizing the time it takes the rest of the Internet to recognize your DNS changes.
- Attention to detail, because without it you may lose critical data.
Step 1: Setup DNS at your new host before the cutover.
A great way to execute this transfer is to set up DNS at your new host before the “real” DNS cutover. In the new host’s name servers, point the appropriate DNS records related to what you are moving (http, etc.) to your current servers at your current host and set TTL reasonably low (about 10-60 minutes). Most networks on the Internet will recognize DNS changes based on Time to Live, which means if you set this up right, once you make that real cutover traffic will flow to the new servers much quicker. By default, this type of transfer would take anywhere from 12-24 hours to be recognized. That is a lot of time to have customers visiting both sets of servers.
Step 2: At the registrar, point your name servers to the new host.
Beware the uptime braggarts.
Be careful about the distinction between uptime and high availability. One should be the goal of your server infrastructure. The other is just a geek bragging right.
Many system administrators will brag about their systems having high uptimes. The uptime of a system is how long it has been running without a reboot. The current longest running uptime, as being tracked by Uptimes Project, is a VMS cluster that has been up just shy of 12 years as of the date this blog was published. Since we strive for 100% uptime, shouldn’t this be an impressive record to share with all of your friends as an exemplary form of sysadmin kung-fu? Actually no, never rebooting your systems fosters a “if it ain’t broke don’t fix mentality” that carries quite a few risks:
- First, if a machine has not been rebooted kernel, OS, and application patches are probably not being kept up-to-date. In today’s age on the Internet this can be a very dangerous practice. Your systems may be vulnerable to known exploits. In addition, if you run into problems with your system, your vendor will require applying recommended patches as a first course of action. It’s better to have these things taken care of before adding to work during a problem. We’ve seen out of date Windows servers need over 4 hours of patches requiring multiple reboots.
- Second, you’re potentially leaving around rotten Easter eggs. By rotten Easter eggs I mean changes to systems that don’t make it through a reboot: production services that should be running, startup scripts that do not work properly, IP addresses that have been added, speed/duplex issues that have been resolved since the machine has been up. So worst case scenario is that your server goes down (either planned or unplanned) and after the reboot you have a server with poor network performance, not all IP addresses are alive, and the database application isn’t running. If the reboot was not planned (a crash) this adds to the confusion when trying to bring the system back online.
