Service Catalogue
The OGC defines Service Catalogue as a “written statement of IT services, default levels and options.” Service management is best organized according to a catalogue of services and is measured against service level baselines. New products or service become a part of the release process and involve business stakeholders in relationship to a newly established SLA. In reality, any service comprises a collection of configured items to include what ITIL® refers to as “People, Process, and Technologies”. This is a common theme IT Service Management.
Service Configuration and CMDB
The accurate collection and documentation of all service related configuration items or CI’s is facilitated through a single or set of configuration management databases, known as the (CMDB). The CMDB store each of the configuration items, but more importantly, it formally documents their relationships. Any information related to delivery of service will have some need of configuration management information systems data. For example, the CMBD is used as a component of problem resolution, the design of an SLA, human resource planning, accounting and compensation.
Figure 14: Configuration Management, Definitive Software and Hardware and CMDB
Part of the CMDB is the recording of running process, a.k.a. the “game plan or play book” used to support a set of system operations as governed by policy and associated with maintaining functional service level. Historically, data centers have used the process known as the Run Book, or “RunBook” to assure documentation of critical processes necessary to maintain and troubleshoot any system in the path of critical operations or service. This practice is common in financial industries managing operational risks for compliance with Basel II, Sarbanes-Oxley Act, section 404, and with FISMA.
 RunBook
A RunBook is a document containing detailed procedures that collectively keep a mission critical system running. A RunBook is sometimes viewed as an element of the Business Continuity Plan (BCP) or a step in the execution of Disaster Recovery (DR). This is because RunBooks are written to assure that an equally skilled technician might step in and administer any system until such time that normal staffing and conditions apply. RunBooks are a system current document with all the required information needed to understand how a service or system is kept running. RunBooks are not project plans, and do not maintain information unless it is "in use" and a part of the working system.
A RunBook is used to verify and gather the location of all operational information. A production RunBook is evidence of documentation and control over a service or system. It provides information on "how" to run procedures without necessarily providing background for the process. RunBooks are detailed instructions that a user references when performing the process.
On a per system instance, a RunBook can document a small set of operational procedures and reference various guidelines. On a larger scale, a service oriented RunBook details the combination of systems and their dependencies in keeping a service available. This is a valid form of meeting both BCP and various other levels of compliance requirements. Determining this requirement can be as follows:
A RunBook is Service Oriented vs. single system oriented. When documentation does not meet the requirements mentioned above, it is probable that listing the device in an inventory system is sufficient and further documentation is not required.
Where the availability of a critical or core business function depends upon the accurate working of interdependent systems, it is advisable to have a business owner who assures the current and complete Service RunBook. As is true for any controlled system, the RunBook explains day to day system procedures, but additionally adds some or all of the following elements:
- Functional Overview
- Functional Overview Diagram
- List of Interfaces
- System Overview
- System Overview Diagram (s)
- Network Management Process
- Hardware
- Hardware Management Process
- Software Development and Release
- Third Party Vendor / Software Management
- Performance Monitoring Process
- Database Administration Process
- Quality Assurance
- Vendor Information
- Back Up Processes
- Disaster Recovery Process
- Security
- Problem Management
- Configuration Overview:
- Server/ HW/OS
- Application
- Database Configuration
- Daily cycle
- Fail-over
- Maintenance
- Troubleshooting and Error Messages
- Glossary
- List of files
- Financial Processes
- Test procedure
RunBooks bring visibility to an aggregation of documents and details that collectively support service availability or product delivery.
A RunBook is complete when its contents satisfy the mission of informing support engineer of necessary steps to maintain expected operating service. RunBooks can be maintained as a word report that is output from a single database system or from a collection of systems. The process for generating RunBook information can take many forms but the result must always be valid current procedures to operate and maintain service. RunBooks are populated by both business owners and technology support personnel.
The RunBook processes assure many critical IT controls as defined by CobiT® numbered control process symbols. Completing a RunBook satisfies the requirement known as Acquire and Implement, AI4 “Enable Operation and Use”. To meet this control requirement is the most mutually rewarding aspect of information technology and audit. The implementation of a well-tuned RunBook is to the benefit of both business and enterprise stakeholders across all areas of IT service.
“Knowledge about new systems needs to be made available. This process requires the production of documentation and manuals for users and IT, and provides training to ensure proper use and operations of applications and infrastructure.”
Visibility over IT Controls means visibility over supporting runtime documentation. Our exit strategy leaves each client with a dashboard similar to this:
|
