Use your Scheduled Downtime (pt 2)

Part 2         (part 1 is here)

How customers think about availability:

Availability (%) = 100% (Whole time per particular period, Usually per year) - "Huston we have a problem"

And under the "Huston we have a problem" your customers can understand factors which are not directly related to the solution that you provide.

How service provider think about availability:

Availability (%) = 100% (Whole time per particular period, Usually per year) - Unscheduled downtime (%) - Scheduled downtime (%)

Unscheduled downtime is "Huston we have a problem" from the customers formula (and, yep, sometimes service provider must think about things which are not directly related to the solution. As example some government regulations)

Scheduled Downtime is what the service provider reserves for itself as time to optimize the solution.

At first glance, the second formula does not look very fair. After all, with this approach, the solution may look like it is continuously available, although in fact it will not be. It is important to clarify to the customers (I would say even at the Sales stage), what is the Scheduled Downtime and why it is important for both (service provider and customer).

Main: this is an opportunity for the service provider to improve his service, and accordingly customer satisfaction level. I know that this sounds wired, but look.

Availability is critical for business. But this is not the only SLA. For example, there are still such as RTO, RPO and a lot of others.

(RTO is the time period during which the system can remain inaccessible in the event of an accident

RPO is the maximum time period for which data may be lost as a result of an incident)

It is important for the service provider to know how quickly he will be able to restore the service or how much data can be lost in the event of a problem, so as not to be unfounded when agreeing to the SLA.

The worst thing you can hope for is statistics. For example, you may decide that this or other possible causes of downtime are so rare, that you can not take them into account. Believe me: at some point it will blow up. Similarly, you should not expect that you conducted some trainings on the pre-prod environment and you know how to solve the problem in case of its occurrence (besides, your Staging/QC can be as close to Production as possible, but it will never be identical). Even if you think that your expectations based on the mathematical model are right – you are wrong.

There are many vivid examples of what the cost of such imprudence.

 Scheduled downtime can include:

·       Deployment of new releases – However, this can (and even should) be implemented without downtime and be customer non impacting. Also you may like to read this article

·       Prod Environment monkey testing – This would allow you to identify problem areas in the infrastructure, monitoring, response, and the time spent solving the problem.

·       Solution monkey testing (on the production environment) – This will help you to identify problem areas in your solution.

·       Disaster Recovery testing (full and partial) - You can determine how long it takes to switch to the DR environment, how much it meets your requirements, etc.

·       Third parties Patching (if your infrastructure requires this) and any other infrastructure updates.

For sure all mentioned above must first be validated in pre-production environments.

The list goes on. But even given above is enough to understand benefits of using your “Scheduled Downtime”.

As additional, do not forget that the SLA can not be transferred to third parties. If you, for example, use cloud services to provide services to your customers, you can not just copy the SLA of a higher-level provider to you and mirror them to your users. Strangely enough, how many companies forget about this. And how often you can see the advertised availability of 99.99 while the higher level provider gives 99.95%

Certainly the time frame when downtime is possible should be communicated and agreed (may be informal way) with customers. This can be, for example, in the interval from 2 to 2:30 am on the fourth Saturday of the month. However, this does not mean that every fourth Saturday of the month you will use put your system down. Likewise, this does not mean that the system will down during the whole time frame. Just something like a "borderline". But before you actually use your time budget, you must notify your customers. In this way they can plan their business correctly.

SLA is a mutual agreement. Just like a system user insists that his interests are respected, you must insist on observing your rights.

What the user is the downtime for you to some extent is the operating time.

Monitor the use of your scheduled downtime. If for some reason you did not use it for a certain period, do not miss this opportunity. Create for yourself a calendar for using scheduled downtime (with priorities for one or another task). Use this time with maximum benefit for yourself and your customers.

The greatest danger lies in what we do not know. Moreover, you can hardly predict what will happen in the "unexplored" area. But you are quite able to predict the consequences and accordingly know how to react. Using Scheduled Downtime is not a panacea. But this allows you to expand the circle of “known”, and at least little bit reduce the circle of “unknown”. And of course to be more prepared for what the “unknown” can bring to your business.