Requirements
The requirements analysis was completed by a cross-functional team representing the key stakeholders. The critical requirements are:
Service availability so that measured unplanned downtime is less than two hours a year.
Applications are written to support an Oracle 9i RAC database.
Components must be easily expandable to increase capacity without requiring a redesign of the application environment or data center infrastructure.
In case of a disaster, the applications must be running on the secondary site within 6 hours. Planned transfer to the alternate site should occur in less than 30 minutes. Note that the unplanned disaster case has a greater time allowance than the planned disaster case. This is specified so that the disaster plan can be exercised while the service level is maintained, but an actual disaster may require additional time to accommodate safe transfer to the secondary site.
The marketing department wants to perform data analysis on the information collected by the system. This analysis does not have to be done on live operational data so it is not a critical requirement, but marketing wants the data to be accumulated daily.
Services Required
The required system services are:
Customer management system (CMS™), which is accessed by a variety of external and contract vendors. This service provides a single point of management for all of the Company's customers.
E-commerce database services. These services include storage and management of outbound marketing information, as well as any applications that interface to the other back-office applications.
Several Oracle 9i RAC database instances located at the primary data center will provide these services.
A number of systems, such as web, authentication, and directory servers, provide the supporting infrastructure for these services. These systems are not described here.
Service Level Expected
The Company realizes that the systems are expected to grow over time. However, even the best planners cannot accurately predict potential changes, especially for the new development being done on e-commerce applications. To balance the Company's application availability requirements with the rate of expected change, the ITO developed a schedule for planned system changes. This schedule helps to restrict changes to planned times that the users can rely on for planning purposes. Every effort is made to enable rollback of any scheduled changes within a short period of time. Thus, if a regression occurs, the Company can return the system to operation by rolling back the changes. TABLE 6-1 lists the schedule for planned service changes. At all other times, the Company expects the services to be operational.
| Planned Service Changes | CMS | E-commerce |
|---|---|---|
| Major software updates | Annually | Biannually |
| Minor software updates | Biannually | Quarterly |
| Scheduled patch maintenance | Monthly | Monthly |
| Emergency patch maintenance | As needed | As needed |
| Hardware platform replacement | Annually | Annually |
| Hardware upgrades | Quarterly | Quarterly |
Performance problems are another source of service outages. The ITO operations staff continuously monitors the performance of the systems for the following conditions:
Hung processes
Processes consuming more CPU time than expected
Available CPU resources
Low memory conditions
Unbalanced I/O workloads
In addition, the development of new software requires the delivery of a probe that can be used to test the operation of the software. The Company distributes this probe throughout the Company, and the operations staff will monitor the performance results looking for anomalies.