ITIL Training - Part 3

8/13/2019 ITIL Training - Part 3

1/55

IT Infrastructure Library (ITIL)Part 3ConfigurationChange - ReleaseCONNECTING BUSINESS &TECHNOLOGY

11/25/20131


2/55

C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y

Agenda

Service Support Model

Configuration Management

Change Management

Release Management

2


3/55


Service support process model


4/55


Agenda

4

Goals of Configuration Management:account for all the IT assets and configurations within the organisation and its

services

provide accurate information on configurations and their documentation to

support all the other Service Management processesprovide a sound basis for Incident Management, Problem Management, Change

Management and Release Management

verify the configuration records against the infrastructure and correct any

exceptions



Change Management

Release Management


5/55


Configuration ManagementScope

Configuration Management definition

Configuration Management covers the identification, recording, andreporting of IT components, including their versions, constituentcomponents and relationships

Major activities Planning.Planning and defining the purpose, scope, objectives, policies and

procedures, and the organisational and technical context, for Configuration

Management. Identification.Selecting and identifying the configuration structures for all the

infrastructure's CIs (allocating identifiers, version numbers, labelling in theCMBD).

Control.Ensuring that only authorised and identifiable CIs are accepted andrecorded, from receipt to disposal.

Status accounting.The reporting of all current and historical data concernedwith each CI throughout its life cycle.

Verification and audit.A series of reviews and audits that verify the physicalexistence of CIs and check that they are correctly recorded in the ConfigurationManagement system.


6/55


Configuration ManagementConcepts (1)

Configuration Management Planning

the strategy, policy, scope and objectives of Configuration Management the organisational context, both technical and managerial

the policies for related processes (Change, Release)

the relevant processes, procedures, guidelines, support tools, roles and

location of storage areas

Configuration Identification and CI Configuration Identification is the selection, identification and labelling of the

configuration structures and CIs, including their respective 'owner' and the

relationships between them

CIs may be hardware, software or documentation (services, servers,

environments, equipment, network components, desktops, mobile units,

applications, licences, telecommunication services, and facilities)


7/55



Configuration Control

It ensures that no CI is added, modified, replaced or removed withoutappropriate controlling documentation e.g. an approved Change request

Configuration status accounting

porting of all current and historical data concerned with each CI throughout its

life-cycle ('development', 'test', 'live' or 'withdrawn)

Configuration verification and audit Configuration verification and audit comprises a series of reviews and audits

that verify the physical existence of CIs and check that the CIs are correctly

recorded in the CMDB and controlled libraries

Configuration baseline

is the configuration of a product or system established at a specific point in

time, which captures both the structure and details of a configuration. It servesas reference


8/55



Configuration Management Database, examples of uses :

Release contents, including component CIs and their version numbers

Component CIs and their version numbers in the test and live environments

CIs affected by a scheduled (authorised) Change

all Requests for Change (RFCs) relating to one particular CI

CIs purchased from a particular supplier within a specific period

CI history

equipment and software at a given location, for example to assist in an audit

CIs that are scheduled to be upgraded, replaced or decommissioned

Changes and Problem records associated with a CI

all CIs affected by a Problem.


9/55



Software and document libraries

A controlled library is a collection of software or document CIs of knowntype and status

Definitive Software Library

the library in which the definitive authorised versions of all software CIs

are stored and protected

Licence Management

to monitor and control software licences, from purchase to disposal


10/55


Configuration ManagementBenefits

Benefits Providing accurate information on CIs and their documentation

Controlling valuable CIs

Facilitating adherence to legal obligations. Enabling the

organisation to reduce the use of unauthorised software

Helping with financial and expenditure planning

Contributing to contingency planning

Supporting and improving Release Management

Improving security by controlling the versions of CIs in use

Allowing the organisation to perform impact analysis and

schedule Changes safely, efficiently and effectively

Providing Problem Management with data on trends


11/55


Configuration managementActivities (1)

Configuration management planning purpose, scope and objectives of Configuration Management

related policies, standards and processes that are specific to thesupport group

Configuration Management roles and responsibilities

CI naming conventions

the schedule and procedures for performing ConfigurationManagement activities: configuration identification, control, statusaccounting, configuration audit and verification

interface control with third parties, e.g. Change Management,suppliers

Configuration Management systems design, including scope and keyinterfaces, covering CMDB, locations of data and libraries, interfaces

housekeeping, including licence management, archiving and theretention period for CIs


12/55



Configuration identification, examples of components : hardware (including network components)

system software, including operating systems

business systems - custom-built applications

packages - commercial off-the-shelf packages, standard products, anddatabase products,

physical databases

environments configuration baselines

software releases

configuration documentation (specifications, licences, maintenanceagreements, SLAs, )

other resources e.g. Users, suppliers, contracts

other documentation (IT business processes, workflow,)

Service Management components and records such as capacity plans, ITservice continuity plans, Incident, etc.


13/55



Configuration identification, structures :

Configuration structures should describe the relationship and position ofCIs in each structure

Typical CI typesare: software products, business systems, systemsoftware, servers, mainframes, workstations, laptops, routers andswitchs


14/55



Configuration identification Relationships between CIs:

'parent/child (software module is part of a program)

Coneected to (a desktop computer is connected to a LAN)

uses another CI (a business service uses an infrastructure server)

Physical and electronic software libraries

Configuration baselines

Release records (current, past and planned) Other Change records (current, past and planned)

the state of system and its documentation when a Change is approved andwhen it is applied

the state of a system and its documentation when a package Release is applied

hardware and software - standard specifications

Naming conventions

Labelling CIs


15/55



Control of CIs

Register all new CIs and versions Update CI record with regard to

status Changes (e.g. development to test, test to live)

updating attributes

changes in ownership or roles

relating new versions of documentation

licence control

Linking CIs to related Incidents, Problem, Change and Release records

Update RFCs with related CIs, status and implementation details

update and archive of CIs and their associated records when are

deleted/decommissioned

protect the integrity of configurations update the CMDB after periodic checking of the existence of physical items

against the CMDB.


16/55



Configuration status accounting Status reports should be produced on a regular basis, listing, for all CIs under

control, their current version and Change history

Configuration verification and audit

Before a major Release or Change, an audit of a specific configuration may be

required to ensure that the Customer's environment matches the CMBD.

Physical configuration audits should be carried out to verify that the 'as-built'configuration of a CI conforms to its 'as-planned' configuration and its associated

documents.

Plans should be made for regular configuration audits to check that the CMBD is

consistent with the physical state of all CIs, and vice versa.

CMDB backups, archives and housekeeping


17/55


Configuration managementKey indicators

Key indicators occasions when the 'configuration' is not as authorised

Incidents and problems that can be traced back to wrongly made

Changes

RFCs that were not completed successfully because of poor impact

assessment, incorrect data in the CMDB, or poor version control the cycle time to approve and implement Changes

licences that have been wasted or not put into use at a particular

location

exceptions reported during configuration audits

Unauthorised IT components detected in use.


18/55


Configuration managementrelations to other processes

(1)

With Incident, Problem andChange Management

With release and ChangeManagement


19/55


Configuration managementExample of attributes (1)

CI Name: the unique name by which this type of CIis known.

Copy or Serial Number: the number that uniquely identifies theparticular instances of this CI- for example, for software the copy number,for hardware the serial number.

Category : Classificationof a CI (e.g. hardware, software, documentationetc).

Type: description of CI type, amplifying 'category' information (e.g.

hardware configuration, software package, hardware device or programmodule).

Model Number(hardware) : model of CI (corresponding, for example, tosupplier's model number e.g. Dell model xxx, PC/aa model yyy).

Warranty expiry date: date when the supplier's warranty expires for theCI.

Version Number: the version number of the CI.

Location: the location of the CI, e.g. the library or media where thesoftware CIs reside, the site/room where a service is located.


20/55



Owner Responsible: the name and/or designation of the ownerresponsible for the CI.

Responsibility Date : date the above owner became responsible for theCI.

Source/supplier : the source of the CI, e.g. developed in-house, bought infrom company xxxxx etc.

Licence: licence number or reference to licence agreement.

Supply Date: date when the CI was supplied to the organisation. Accepted Date: date when theCI was accepted by the organisation as

satisfactorily tested.

Status (current): the current status of the CI; e.g. under 'test', 'live','archived'.

Status (scheduled): the next scheduled status of the CI (with the date or

indication of the event that will trigger the status change).


21/55



Parent CI(s) relationships: the unique CI identifier(s) -

name/copy/number/model/number/ of the 'parent(s)' of thisCI. Child CI(s) relationships: the unique CI identifier(s) of all 'children' of

this CI.

Relationships: the relationship of the CI with all CIs other than 'parent'and 'child' (e.g. this CI 'uses' another CI, this CI 'is connected to' anotherCI, this CI is 'resident on' another CI, this CI 'can access' another CI).

RFC Numbers: id. number of all RFCs affecting this CI.

Change Numbers: the identification number of all Change recordsaffecting this CI.

Problem Numbers: the identification number of all Problem recordsaffecting this CI.

Incident Numbers: the identification number of all Incident recordsaffecting this CI.

Comment: a comment field to be used for textual narrative; for example,

to provide a description of how this version of the CI is different from theprevious version.

A d


22/55


Agenda

22

Goal of Change Management:

Is to ensure that standardised methods and procedures are used for

efficient and prompt handling of all Changes, in order to minimise the

impact of Change-related incidents upon service quality, andconsequently to improve the day-to-day operations of the organisation



Change Management

Release Management

C S


23/55


Change ManagementScope

Change Management definition

Process of controlling Changes to the infrastructure or any aspect ofservices, in a controlled manner, enabling approved Changes withminimum disruption

Perimeter hardware

communications

equipment and software system software

'live' applications software

all documentation andprocedures associatedwith the running, supportand maintenance of livesystems.

Ch M t C t (1)


24/55


Change ManagementConcepts (1)

Main activities

raising and recording Changes assessing the impact, cost, benefits and risk of Changes

developing the business justification and obtaining approval

management and co-ordination of Change implementation

monitoring and reporting on the implementation

closing and reviewing the Change requests

Concepts are process-related and managerial, rather than

technical (create a CABchange advisory board)

The following figures

Basic change management procedures Change model

Ch M t C t (2)


25/55



Ch M t C t (3)


26/55



Change Management Concepts (4)


27/55



Requests of change

RFC number (cross reference to Problemreport number) description and identity of item(s) to be changed

reason for Change, contact proposing the Change

effect of not implementing the Change

version of item to be changed

date that the Change was proposed

Change priority

impact and resource assessment

CAB recommendations

authorisation signature, authorisation date and time

scheduled implementation, location of implementation plan

back-out plan, risk assessment and management

review date, review results

impact on business continuity and contingency plans status of RFC (logged, assessed, rejected, accepted, sleeping)

Change Management Concepts (5)


28/55



Change Advisory Board (CAB), members Change Manager

Customer(s), User manager(s), User group representative(s)

applications developers/maintainers (where appropriate)

experts/technical consultants

services staff (as required)

contractor's or third parties' representatives (as required)

Change models against sizes of change

Critical Outage plan

Change Management Benefits


29/55


Change ManagementBenefits

Benefits

better alignment of IT services to business requirements

increased visibility and communication of Changes to both business andservice-support staff

improved risk assessment

a reduced adverse impact of Changes on the quality of services and on SLAs

better assessment of the cost of proposed Changes before they are incurred

fewer Changes that have to be backed-out

Improved Problem and Availability Management through the use of valuablemanagement information relating to changes

increased productivity of Users - through less disruption and, higher-qualityservices

increased productivity of key personnel through less need for diversion

an enhanced business perception of IT through an improved quality ofservice and a professional approach

Change Management Activities (1)


30/55


Change ManagementActivities (1)

Planning the implementation of operationnal processes

Change logging and filtering Severals formats email, paper, internet from anybody in the organisation

Unique identifier number, links with CIs or Problem number

Filter out any that are totally impractical, return with brief details of the reasonfor the rejection (as required)

Allocation of priorities

Immediate.Causing loss of service or severe usability problems to a largernumber of Users, a mission-critical system, or some equally serious problem.Immediate action required.

High.Severely affecting some Users, or impacting upon a large number ofUsers.

Medium.No severe impact, but rectification cannot be defered until the next

scheduled Release or upgrade. Low.A Change is justified and necessary, but can wait until the next

scheduled Release or upgrade.



31/55



Change categorisation

Minor impact only : delegated authority to authorise and schedule

such Changes

Significant impact : members of the CAB. Documentation should be

circulated for impact.

Major impact : RFC should be referred to the organisation's

Management

CAB meetings :

assessment referral process can be handled electronically via

support tools or email



32/55



Impact and ressource assessment

the impact that the Change will make upon the Customers businessoperation

the effect upon the infrastructure and Customer service, as defined in theSLA, and upon the capacity and performance, reliability and resilience,contingency plans, and security

the impact on other services that run on the same infrastructure (or on

software development projects) the impact on non-IT infrastructures within the organisation - for example,

security, office services, transport, business - Customer Help Desks

the effect of not implementing the Change

The IT, business and other resources required to implement the Change,covering the likely costs, the number and availability of people required, theelapsed time, and any new infrastructure elements required

additional ongoing resources required if the Change is implemented.



33/55



Change approval

levels of approval should be judged by the size or risk of the Change

three principal approval processes : technical, financial, business

Change scheduling

into target Releases (continuity between the Change Managementand Release Management processes)

limit the size of a Release to manageable proportions

implementation over a previously agreed (with the business) period



34/55



Change buiding, testing and implementation

Building : new production module, new version of one or more

software modules, purchasing equipment or services externally,

preparing a hardware modification, producing new or amended

documentation/training

Back-out procedures should be prepared and documented in

advance Testing (performance, security, maintainability, supportability,

reliability/availability, functionality, regression)

scheduling when the least impact on live services, introducing into a

limited environment



35/55



Urgent changes

Change approval is still a prerequisite

Urgent change buiding, testing andimplementation

plan to ensure sufficient staff andresources

testing even after a Change has gonelive

warning as possible to customers andusers

each change iteration must becontrolled

valuable management informationmust not be not lost



36/55



Change review

By CAB members

Purpose :

The change has had the desired effect and met its objectives

Users and Customers are content with the results, or to identify any

shortcomings

there have been no unexpected or undesirable side-effects tofunctionality, availability, capacity/performance, security,

maintainability etc.

the resources used to implement the Change were as planned

the implementation plan worked correctly (so include comments from

the implementers) the Change was implemented on time and to cost

the backout-plan functioned correctly, if needed

Change Management Responsabilities


37/55


Change Management Responsabilities

Change Manager

Receive, log and allocate a priority, in collaboration with the initiator, to all RFCs. Rejectany RFCs that are impractical.

Table all RFC for a CAB meeting, issue an agenda, decide the attendees.

Convene urgent CAB meetings for all urgent RFCs.

After consideration of the advice given by the CAB authorise acceptable Changes.

Coordinate change building, testing and implementation.

Update the change log.

Review all implemented Changes. Refer back any that have been backed out or havefailed. Produce regular reports.

Analyse change trends or apparent problems that occur.

CAB

Review all submitted RFCs. Be available for consultation (urgent Change).

Attend all relevant CAB meetings. Give an opinion on which Changes should be

authorised.

Change ManagementReporting


38/55


g g p g

Change management reports

number of Change requests

number and % of Changes

Rejected, in Change status

emergency Changes

number of Changes awaiting implementation, by category and timeoutstanding

number of implemented Changes, by configuration component and service change backlogs and bottle-necks

costs per Change and cost summaries

business impact of Changes

Changes by business area

frequency of Change to Cis.

Audit for compliance


39/55


IT Infrastructure Library (ITIL)

3-4Release ManagementGoals of Release Management:

to plan and oversee the successful rollout of software and related hardware

to design and implement efficient procedures for the distribution and installation of Changes to IT systems

to ensure that hardware and software being changed is traceable, secure and that only authorised versions are

installed

to communicate and manage expectations of the Customer during the planning and rollout of new Releases

to agree the exact content and rollout plan for the Release, through liaison with Change Management

to ensure that master copies of all software are secured in the Definitive Software Library (DSL)

to ensure that all hardware being rolled out or changed is secure and traceable, using the services ofConfiguration Management


40/55

Release ManagementScope


41/55


g p

Release definition

A collection of new and/or changed Cis wich are tested and introducedinto the live environment together

Main activities

Release ManagementConcepts (1)


42/55


g ( )

Release types

Major software Releases and hardware upgrades,normally containing largeareas of new functionality, some of which may make intervening fixes toPoblems redundant. A major upgrade or Release usually supersedes allpreceding minor upgrades, Releases and emergency fixes.

Minor software Releases and hardware upgrades,normally containing smallenhancements and fixes, some of which may have already been issued asemergency fixes. A minor upgrade or Release usually supersedes all preceding

emergency fixes. Emergency software and hardware fixes,normally containing the corrections to

a small number of known Problems

Release policy and planning

the Realease policy covers Release numbering, frequency and the level in theIT infrastructure that will be controlled by definable Releases



43/55


Release unit

Release unit describes the portion of the IT infrastructure that isnormally released together

Release identification Release should be uniquely

identified according to ascheme defined in the Release

policy For example :

major Releases: Payroll_Systemv.1, v2, v3 etc...

minor Releases: Payroll_Systemv.1.1, v.1.2, v.1.3 etc...

emergency fix Releases:Payroll_System v.1.1.1, v.1.1.2,v.1.1.3 etc



44/55


Type of release

Full release : all components of the Release unit are built, tested, distributedand implemented together

Delta release : includes only those CIs within the Release unit that haveactually changed or are new since the last full or delta Release

Package release : groups individual Releases (full units, delta Releases orboth) together

Definitive Software Library (DSL) a secure compound in which the

definitive authorised versions ofall software CIs are stored andprotected

contains the master copies of allcontrolled software in an

organisation



45/55


Definitive Hardware Store (DHS)

Area for the secure storage of definitive hardware spares (components andassemblies that are maintained at the same level as the comparativesystems within the live environment)

Configuration Management Database (CMDB)

contain the following information in support of the Release Managementprocess:

definitions of planned Releases, including the constituent hardware andsoftware CIs together with a reference to the original Change Requests

records of the CIs impacted by planned and past Releases, covering bothhardware and software

information about the target destination for the Released components (e.g.the physical location for hardware and the servers that will receive thesoftware changes).



46/55


Build Management software and/or hardware should be assembled in a controlled manner to

ensure a reproducible process (called 'build management)

Testing

Functional testing, operational testing, performance testing and integrationtesting

User acceptanceBack Out Plans

Actions to be taken to restore the service if the rollout of a Release, eitherpartially or totally

Part of the risk assessment of the overall rollout plans

Be agreed with the end users as sufficient

Tested

Release ManagementBenefits


47/55


Benefits

greater success rate in the Release of hardware and software consistency in the Release processes

minimisation of the disruption of the service to the business

assurance that the hardware and software in live use is of good (or known) quality, becausethe Releases are built properly)

stable test and live environments (fewer individual implementations)

better use of User resources

minimisation of regression-testing requirements

better expectation setting within the organisation on publication of a Release schedule inadvance

proper control and safeguarding of hardware and software assets

an ability to absorb high rates of change to the live systems

the ability to build and control the software used at remote sites from a central location

easier detection of wrong versions and unauthorised copies of software

reduced time to Release and fewer delays

smoother transitions of Releases from the development activities (projects) to the Customer'sbusiness environment.

Release ManagementActivities (1)


48/55


Release planning

gaining consensus on the Release contents agreeing to the phasing over time and by geographical location,

business unit and customers

producing a high-level Release schedule

conducting site surveys to assess existing hardware and software inuse

planning resource levels (including staff overtime)

agreeing on roles and responsibilities

obtaining detailed quotes and negotiating with suppliers for newhardware, software or installation services

producing back-out plans

developing a quality plan for the Release planning acceptance of support groups and the Customer.



49/55


Designing, building and configuring a release Instructions to assemble a Release, write automated installation

routines, tests plans are a part of the Release (as a Ci)

All software, parameters, test data, run-time should be underConfiguration Management control

Design, build and configure outputs:

Build instructions (sequence of operations)

Purchase orders, licences and warranties for software and hardware

Automated installation scripts and associated test plans

Master copies of the installation media and installation instructions(stored in the DSL)

Back-out procedures.



50/55


Release acceptance

Performed by independent business staff (function of the final system) Verify change procedures by IT staff (installation procedures)

Tested back-out procedures

Outputs of release acceptance

tested installation procedures

tested Release components

tested back-out procedures test results and known defects

support documentation including the system overview; updated supportprocedures; diagnostic aids

operating and administration instructions

contingency and back-out plans

a training schedule for Service Management, support staff and Customers

acceptance test documentation signed by all relevant parties

authorisation to implement the Release (Change Management)



51/55


Rollout planning

producing an exact, detailed timetable of events (resource plan)

listing the CIs to install and decommission (redundant equipment and

software ?)

documenting an action plan by site

producing Release notes and communications to end users

planning communication

purchasing plans

acquiring hardware and software where (procedures to be followed for

the secure storage prior to rollout and the mechanisms to trace the

deployment during the implementation)

scheduling meetings for managing staff and groups involved in theRelease



52/55


Communication, preparation and training

Inform customer liaison staff and support staff (series of rollout meetings) Training sessions

Problems during the rollout phase need to be communicated to all parties

publicise the release mechanism and the contraints to end users

Communication from release management and from service desk

Distribution and installation

build environment => test environment => live environment

processes for procurement, storage, dispatch, receipt and disposal of goods

distributing software, checking that the Release is complete

bringing application software Releases into active use

updating the CMDB

perform a final acceptance test for the end user

Release managementProcess control (1)


53/55


Key performance indicators

Releases built and implemented on schedule, and within budgeted resources very low (ideally no) incidence of Releases having to be backed out due to

unacceptable errors

low incidence of build failures

secure and accurate management of the DSL, quality of the DSL

compliance with all legal restrictions relating to bought-in software

accurate distribution of Releases to all remote sites and on time no evidence of use of unauthorised software at any site

no evidence of payment of licence fees or wasted maintenance effort, forsoftware that is not actually being used at any particular location

no evidence of wasteful duplication in Release building

accurate and timely recording of all build, distribution and implementation

activities within the CMDB

Release managementProcess control (2)


54/55


Management reporting

the number of major and minor Releases per reporting period the number of problems in the live environment that can be

attributed to new Releases, which need only be measured duringthe first few months of a new Release's life

the number of new, changed and deleted objects introduced bythe new Release - e.g. how many modules and programs

the number of Releases completed in the agreed timescales; thisrequires the central Release Management function to publishpredefined targets (service levels or SLAs) for softwaredistributions and other common tasks.

Contact


55/55


Author

Date

Further

Information

Co tact

ContactDevoteam Jean-Marc Chevereau

Phone +33 1 41 48 48 48 / +33 6 64 48 96 99

Email [email protected]

Country France

www.devoteam.com

Algeria

AustriaBelgium

Czech Republic

Denmark

France

Germany

Italy

Jordan

Luxembourg

Morocco

Netherlands

Norway

Poland

RussiaSaudi Arabia

Spain

Sweden

Switzerland

Tunisia

Turkey

United Arab Emirates

United Kingdom

Devoteam Group

This document is not to be copied or reproduced in any way without Devoteam express permission.

Copies of this document must be accompanied by title, date and this copyright notice.

Jean-Marc Chevereau

Janvier 2010
http://www.devoteam.com/http://www.devoteam.com/

ITIL Training - Part 3

Documents

Transcript of ITIL Training - Part 3