Software Failures - Red Hat ENTERPRISE LINUX 3 - INTRODUCTION TO SYSTEM ADMINISTRATION Administration Manual

150
8.1.1.2.4. Available Budget
As 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; each
time the contract is due to expire you must negotiate a new contract and pay again.
8.1.1.2.5. Hardware to be Covered
Here is an area where you might be able to help keep costs to a minimum. Consider for a moment that
you have negotiated a service agreement that has an on-site technician 24x7, on-site spares — you
name it. Every single piece of hardware you have purchased from this vendor is covered, including
the 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's
job, 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:00
•
Therefore, paying on the chance that this PC might need to be serviced in the middle of a Saturday
night 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.
Note
If you have twenty identically-configured servers that are critical to your organization, you might be
tempted to have a high-level service agreement written for only one or two, with the rest covered by a
much less expensive agreement. Then, the reasoning goes, no matter which one of the servers fails
on 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 serial
numbers. Even if you figure out a way around such checks, far more is spent after being discovered
than by being honest and paying for the service you really need.

8.1.2. Software Failures

Software 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 in
the 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 a
software 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
•
Applications
•
Each type of failure has its own specific impact and is explored in more detail in the following sections.
Chapter 8. Planning for Disaster