Discussion on:

IT should establish realistic availability requirements

Just because you have a well defined service level agreement doesn't mean that it will keep the users satisfied. Unless you get the word out about the level of service you are providing, there will be those who don't know about it and will complainwhen there is a well planned outage.

To reduce the odds of this happening, the service level agreement should be sent to all users, in various degrees of detail, on a relatively frequent basis. This repeated publishing will handle new users as well as those users who tend to forget things.

If there tends to be a problem at end of month, quarter or year, a friendly note to the users at this time would also help.

Of course, don't hammer it in too hard. Too many warnings will eventuallybe ignored.

Talking with the users is only part of the process. Users will often give the expected response regarding what is critical to their job, but in fact may be functioning via work arounds.

The other part is looking at actual traffic patterns. The source and destinations, and the applications that make up the traffic flow form a profile of what the users really use. Identify these first, and then validate with user discussions.

Probably the first thing to recognize is that you are probably talking about multiple systems each with its own set of users and pecular access needs. If you try to view everything as a single system, the answer will always be 24 x 7 availability, there will alwyas be some user who needs to do something at any specific time.

Accounting will need very high availability of their systems during peak times (end of month, end of quarter, etc.), but not at others. A customer help desk may need high availability of different systems at different times, probably based on installation and update schedules. Segregate the users and systems. There is no reason that an accounting package upgrade needs to bring down an e-mail server. There is not reason a service pack installation on the support group server needs to bring down the developers' server.

Break your system down into different pieces, each with its own availability requirements and you can keep everyone happy and avoid user downtime without 24 x 7 service.

IT is setting itself up for failure by " establishing availability requirements." The client/customer/end user of a system/application/program and then your identified negotiation process to achieve "realism" can proceed.
Most appropriately senior management ( contracts for outside customers ) must make the final decisions for the cost benefits.

The differentiation of a clients expectations and the Service Level Agreement(s) requirements is critical. We can rarely communicate these nebulous expectations, but we can agree on specific requirements ( and we can measure the attainment of these goals ).

Keeping goals/requirements "SMART" has always helped my people and organizations.

S - Specific
M - Measurable
A - Achievable
R- Realistic
T - Timebound

Best Regards, Ed.

Reading the article, the thing on top of my mind that people will ask is - are there systems that can achieve such availability. There is, and it is on Windows. A company in Massachusettes has this solution for years. Take a look at http://www.marathontechnologies.com.sg .. surprising so little people know about it.

I suspect that this organization can provide reasonably high hardware availability within limits.

Unfortunately, since their definition of a long distance split site is only 55 KM, it would be susceptible to wide area disasters like earthquakes and hurricanes. And if somebody makes a big mistake with siting the backup sites, a large flood could create problems too.

Does this organization have something that would provide a split site that is a thousand or so miles apart? That, properly configured geographically, could increase availability even in the event of a wide spread disaster.

I think the company focus is on system availability slightly more than disaster recovery basically to have zero downtime than have a few hours of recovery time. I've heard of instances where people use the Marathon array to be the master backup nodeof a Doubletake (a disaster recovery application) so that there is a assured running backup site for multiple locations. 55KM may not be extremely long, a long distance I suspect can be further extended since its just a dedicated fiber connection between. The real draw is theres zero downtime and zero data loss that I've not seen achievable in other DR solutions (they all has latency issues that result in some loss of data and downtime)