150 Chapter 8. Planning for Disaster8.1.1.2.4. Available BudgetAs outlined above, service contracts vary in price according to the nature of the services being pro-vided. Keep in mind that the costs associated with a service contract are a recurring expense; eachtime the contract is due to expire you must negotiate a new contract and pay again.8.1.1.2.5. Hardware to be CoveredHere is an area where you might be able to help keep costs to a minimum. Consider for a moment thatyou have negotiated a service agreement that has an on-site technician 24x7, on-site spares — youname it. Every single piece of hardware you have purchased from this vendor is covered, includingthe PC that the company receptionist uses for non-critical tasks.Does that PC really need to have someone on-site 24x7? Even if the PC is vital to the receptionist’sjob, the receptionist only works from 09:00 to 17:00; it is highly unlikely that:• The PC will be in use from 17:00 to 09:00 the next morning (not to mention weekends)• A failure of this PC will be noticed, except between 09:00 and 17:00Therefore, paying on the chance that this PC might need to be serviced in the middle of a Saturdaynight is a waste of money.The thing to do is to split up the service agreement such that non-critical hardware is grouped sepa-rately from more critical hardware. In this way, costs can be kept as low as possible.NoteIf you have twenty identically-configured servers that are critical to your organization, you might betempted to have a high-level service agreement written for only one or two, with the rest covered by amuch less expensive agreement. Then, the reasoning goes, no matter which one of the servers failson a weekend, you will say that it is the one eligible for high-level service.Do not do this. Not only is it dishonest, most manufacturers keep track of such things by using serialnumbers. Even if you figure out a way around such checks, far more is spent after being discoveredthan by being honest and paying for the service you really need.8.1.2. Software FailuresSoftware failures can result in extended downtimes. For example, owners of a certain brand of com-puter systems noted for their high-availability features recently experienced this firsthand. A bug inthe time handling code of the computer’s operating system resulted in each customer’s systems crash-ing at a certain time of a certain day. While this particular situation is a more spectacular example of asoftware failure in action, other software-related failures may be less dramatic, but still as devastating.Software failures can strike in one of two areas:• Operating system• ApplicationsEach type of failure has its own specific impact and is explored in more detail in the following sections.