Concept & Definition & Best Practices

Concept & Definition & Best Practices (35)

Concept & Definition & Best Practices

Monday, 04 February 2013 09:54

Performance Optimization of Build Server

Written by

Performance Optimization Checklist of Build Servers

Build Infrastructure Level

1.  Do you really need to build all source code or only the part of code which has changes?

2. Project should be divided into multiple modules/component which can be build independently and should be integrated when it needed.

3. Understand technology and make use of performance related features which will help you. e.g make, visual studio and maven has some feature which help us to compile only code which was changed also, some performance tuning features should be explored.

4. Compile dependent project only there are changes. no need to compile all the time.

5. Distribute application in non-compiled and to be compiled files. e.g src, docs and copy only src to comile. docs files cane be used while creating installer.

6. Plan for disk usage growth upfront.

Application Server level

  1. Apache Server optimization and proper log setting
  2. Disabling unused modules and component which will help performance.
  3. Follow best practices of Module Configuration, Apache Server Configuration etc

 System level

  1. Check if any background task/services is running which is consuming cpu/memory and can be  stopped and not relevant.
  2. Keep system uptodate
  3. Avoid using build server for any other task - If you must edit components or install software, build or edit the components on another machine and copy them over.
  4. Use high speen drive for i/o operations

Build Server application level

http://www.cloudbees.com/sites/default/files/whitepapers/7WaysToOptimizeJenkins.pdf

  1. Keep log files maintenance and truncate regularly. have limited build records.
  2. Move build to document server. not to keep in build server
  3. Take advantage of distribute build server using agents/slaves/nodes etc

 

Versioning in Software Configuration Management?

Reference: This article has been take out from Book Called "The Build Master: Microsoft's Software Configuration Management Best Practices"

Why Worry About Versioning?

  • Having a good version scheme for your software is important for several reasons. The following are the top five things a version scheme allows you to do (in random order):
  • Track your product binaries to the original source files.
  • Re-create a past build by having meaningful labels in your source tree.
  • Avoid "DLL hell" —multiple versions of the same file (library in this case) on a machine.
  • Help your setup program handle upgrades and service packs.
  • Provide your product support and Q/A teams with an easy way to identify the bits they are working with.

So, how do you keep track of files in a product and link them back to the owner? How can you tell that you are testing or using the latest version of a released file? What about the rest of the reasons in the list? This chapter describes my recommendations for the most effective and easiest way to set up and apply versioning to your software. Many different schemes are available, and you should feel free to create your own versioning method.

Ultimately, like most of the other topics in this book, the responsibility to apply versioning to the files in a build tends to fall into the hands of the build team. That might be because it is usually the build team that has to deal with the headaches that come from having a poor versioning scheme. Therefore, it is in their best interest to publish, promote, and enforce a good versioning scheme. If the build team does not own this, then someone who does not understand the full implications of versioning will make the rules. Needless to say, this would not be desirable for anybody involved with the product.

What is the best way to accomplish this? Let's start with the version number and work our way down.

File Versioning

Every file in a product should have a version number; a four-part number separated by periods such as the one that follows seems to be the established best practice. There are many variations of what each part represents. I will explain what I think is the best way of defining these parts.

<major version>.<minor version>.<build number>.<revision>

Major version— The component owner usually assigns this number. It should be the internal version of the product. It rarely changes during the development cycle of a product release.

Minor version— The component owner usually assigns this number. It is normally used when an incremental release of the product is planned instead of a full feature upgrade. It rarely changes during the development cycle of a product release.

Build number— The build team usually assigns this number based on the build that the file was generated with. It changes with every build of the code.

Revision— The build team usually assigns this number. It can have several meanings: bug number, build number of an older file being replaced, or service pack number. It rarely changes. This number is used mostly when servicing the file for an external release.

Build Number

Each build that is released out of the Central Build Lab should have a unique version stamp (also known as the build number). This number should be incremented just before a build is started. Don't use a date for a build number or mix dates into a version number simply because there are so many date formats out there that it can be difficult to standardize on one. Also, if you have more than one build on a given date, the naming can get tricky. Stick with an n=n+1 build number. For example, if you release build 100 in the morning and rebuild and release your code in the afternoon, the afternoon build should be build 101. If you were to use a date for the build number, say 010105, what would your afternoon build number be? 010105.1? This can get rather confusing.

How Versioning Affects Setup

Have you ever met someone who reformats his machine every six months because "it just crashes less if I do" or it "performs better?" It might sound draconian, but the current state of component versioning and setup makes starting from scratch a likely solution to these performance issues, which are further complicated by spyware.

Most of the problems occur when various pieces of software end up installing components (DLLs and COM components) that are not quite compatible with each other or with the full set of installed products. Just one incorrect or incorrectly installed DLL can make a program flaky or prevent it from starting up. In fact, DLL and component installation is so important that it is a major part of the Windows logo requirement.

If you are involved in your product's setup, or if you are involved in making decisions about how to update your components (produce new versions), you can do some specific things to minimize DLL hell and get the correct version of your file on the machine.

Installing components correctly is a little tricky, but with these tips, you can install your components in a way that minimizes the chance of breaking other products on your own.

Install the Correct Version of a Component for the Operating System and Locale
If you have operating system (OS)-specific components, make sure your setup program(s) check which OS you are using and install only the correct components. Also, you cannot give two components the same name and install them in the same directory. If you do, you overwrite the component on the second install on a dual-boot system. Note that the logo requirements recommend that you avoid installing different OS files if possible. Related to this problem is the problem caused when you install the wrong component or typelib for the locale in use, such as installing a U.S. English component on a German machine. This causes messages, labels, menus, and automation method names to be displayed in the wrong language.

Write Components to the Right Places
Avoid copying components to a system directory. An exception to this is if you are updating a system component. For that, you must use an update program provided by the group within Microsoft that maintains the component.

In general, you should copy components to the same directory that you copy the EXE. If you share components between applications, establish a shared components directory. However, it is not recommended that you share components between applications. The risks outweigh the benefits of reduced disk space consumption.

Do Not Install Older Components Over Newer Ones
Sometimes, the setup writer might not properly check the version of an installed component when deciding whether to overwrite the component or skip it. The result can be that an older version of the component is written over a newer version. Your product runs fine, but anything that depends on new features of the newer component fails. Furthermore, your product gets a reputation for breaking other products. We address the issue of whether it makes sense to overwrite components at all. But if you do overwrite them, you don't want to overwrite a newer version.

"Copy on Reboot" If Component Is in Use
Another common mistake is to avoid dealing with the fact that you cannot overwrite a component that is in use. Instead, you have to set up the file to copy on reboot. Note that if one component is in use, you probably should set up all the components to copy on reboot. If you don't, and if the user doesn't reboot promptly, your new components could be mixed with the old ones.

Register Components Correctly; Take Security into Account
Sometimes setups don't properly register COM components correctly, including the proxy and stub. Note that Windows CE requires that you also register DLLs. Note, too, that when installing DCOM components, you must be vigilant about permissions and security.

Copy Any Component That You Overwrite
It is smart to make a copy of any component that you overwrite before you overwrite it. You won't want to put it back when you uninstall unless you're sure that no product installed after yours will need the newer component—a difficult prediction! But by storing the component in a safe place, you make it possible for the user to fix his system if it turns out that the component you installed breaks it. You can let users know about this in the troubleshooting section of your documentation, the README file, or on your Web site. Doing this might not save a call to support, but it does at least make the problem solvable. If the component is not in use, you can move it rather than copying it. Moving is a much faster operation.

Redistribute a Self-Extracting EXE Rather Than Raw Components
If your component is redistributed by others (for instance, your component is distributed with several different products, especially third-party products), it is wise to provide a self-extracting EXE that sets up your component correctly. Make this EXE the only way that you distribute your component. (Such an EXE is also an ideal distribution package for the Web.) If you just distribute raw components, you have to rely on those who redistribute your components to get the setup just right. As we have seen, this is pretty easy to mess up.

Your EXE should support command-line switches for running silently (without a UI) and to force overwriting, even of newer components, so that product support can step users through overwriting if a problem arises.

If you need to update core components that are provided by other groups, use only the EXE that is provided by that group.

Test Setup on Real-World Systems
If you're not careful, you can install all your setup testing on systems that already happen to have the right components installed and the right registry entries made. Be sure to test on raw systems, on all operating systems, and with popular configurations and third-party software already installed. Also, test other products to make sure they still work after you install your components.

 

Hardware Configuration - Hardware Requirements for Build Server

Reference: The Build Master: Microsoft's Software Configuration Management Best Practices

At a minimum, the build lab should have four machines:

Server that contains the Source Code Control program— This is your product. Do you really want this server residing someplace where you have little control over this box?

Debug build machine for the mainline builds— If you don't separate your debug and release machines, you will accidentally ship debug binaries, which is not a good thing.

Release build machine for the mainline builds— This is a "golden goose" that turns out the "gold eggs" of your company or group. Treasure this machine like a princess, and guard it like all the king's fortunes.

Internal release share server— This is one more piece of hardware that stores the "bread and butter" of the group or company. Don't give up control of this hardware to anyone unless your IT department reports through your development group.

Hardware Requirements
Each machine in the preceding list should meet the following requirements:

Number of processors— This depends on the build tool you use. One is usually sufficient, because few build tools really take advantage of multiple processors.

Processor speed— The lab budget dictates this, but the faster the processor, the better it is.

Amount of installed RAM— Max out the machine. RAM is relatively cheap these days, especially when you consider the performance increase you get. Increasing the RAM is usually the first upgrade done when trying to improve the performance of any computer.

Number of hard drives— A minimum of two drives (or partitions) is preferred:

Drive 1 (C:) is for the operating system and installed applications.

Drive 2 (D:) is for building binaries, release shares, or the source database; the minimum space required is roughly ten times the space needed to build your application.

The split partitions are good because if you ever need to format or blow away a drive due to corruption, only part of the project will be affected. The recovery is much faster and easier.

Hard drive type— This is most likely SCSI, but it could be IDE.

Number of power supplies— If you purchase server class hardware (pizza boxes) that belong in racks, you need to consider how many power supplies to order.

Motherboard BIOS version— This does make a difference. Make sure you note what is being used and standardize on it.

 

 

Wednesday, 23 May 2012 09:40

More Important Build Definitions

Written by

More Important Build Definitions

Reference: The Build Master: Microsoft's Software Configuration Management Best Practices

It is also important for groups or teams to define these terms on a project-wide basis so that everyone is clear on what he is getting when a build is released.

Pre-build— Steps taken or tools run on code before the build is run to ensure zero build errors. Also involved are necessary steps to prepare the build and release machines for the daily build, such as checking for appropriate disk space.

Post-build— Includes scripts that are run to ensure that the proper build verification tests (BVTs) are run. This also includes security tests to make sure the correct code was built and nothing was fused into the build.

Clean build— Deleting all obj files, resource files, precompiled headers, generated import libraries, or other byproducts of the build process. I like to call this cleaning up the "build turds." This is the first part of a clean build definition. Most of the time, build tools such as NMake.exe or DevEnv.exe handle this procedure automatically, but sometimes you have to specify the file extensions that need to be cleaned up. The second part of a clean build definition is rebuilding every component and every piece of code in a project. Basically the perfect clean build would be building on a build machine with the operating system and all build tools freshly installed.

Incremental build— The secret to getting out a daily build to the test team, regardless of circumstances, is to perform incremental builds instead of daily clean builds. This is also the best way that you can maintain quality and a known state of a build. An incremental build includes only the code of the source tree that has changed since the previous build. As you can guess, the build time needed for an incremental build is just a fraction of what a clean build takes.

Continuous integration build— This term is borrowed from the extreme programming (XP) practice. It means that software is built and tested several times per day as opposed to the more traditional daily builds. A typical setup is to perform a build every time a code check-in occurs.

Build break— In the simplest definition, a build break is when a compiler, linker, or other software development tool (such as a help file generator) outputs an error caused by the source code it was run against.

Build defect— This type of problem does not generate an error during the build process; however, something is checked into the source tree that breaks another component when the application is run. A build break is sometimes referred to or subclassed as a build defect.

Last known good (LKG) or internal developers workstation (IDW) builds— These terms are used as markers to indicate that the build has reached a certain quality assurance criterion and that it contains new high-priority fixes that are critical to the next baseline of the shipping code. The term LKG originated in the Visual Studio team, and IDW came from the Windows NT organization. LKG seems to be the more popular term at Microsoft.

 

Friday, 23 December 2011 12:17

Importance of Automation Tools in SCM

Written by
Importance of Automation Tools in SCM
by John Ferguson Smart

Since the dawn of time, people have been using tools to make their life easier. Tools let you solve a problem at hand more quickly and more efficiently, so that you can spend your time doing more interesting things. The stone axe, for example, enabled your prehistoric hunter to cut up meat more efficiently, thus leaving the tribe with time to do much more satisfying activities such as grilling mammoth steaks and painting on cave walls.

Of course, not all tools are equal, and tools have a tendency to evolve. If you go down to your local hardware store nowadays, you can probably find something even better to chop up your firewood or to chop down a tree. In all things, it is important to find the tool that is most appropriate for the job at hand.

The software industry is no exception in this regard. There are thousands of tools out there, and there is a good chance that some of these can help you work more efficiently. If you use them well, they will enable you to work better and smarter, producing higher quality software, and avoiding too much overtime on late software projects. The hardest thing is knowing what tools exist, and how you can put them to good use.

That's where this book can help. In a nutshell, this book is about software development tools that you can use to make your life easier. And, in particular, tools that can help you optimize your software development life cycle.

The Software Development Life Cycle (or SDLC) is basically the process you follow to produce working software. This naturally involves coding, but there is more to building an application than just cutting code.

You also need a build environment.

When I talk of a build environment, I am referring to everything that contributes to letting the developers get on with their job: coding. This can include things like a version control system (to store your source code) and an issue management system (to keep track of your bugs). It can also include integration, testing, and staging platforms, in which your application will be deployed at different stages. But the build environment also includes tools that make life easier for the developer. For example, build scripts that help you compile, package and deploy your application in a consistent and reproducible manner. Testing tools that make testing a less painful task, and therefore encourage developers to test their code. And much more.

Let's look at a concrete example. My picture of an efficient, productive build environment goes something along the following lines.

You build your application using a finely tuned build script. Your build script is clean, portable, and maintainable. It runs on any machine, and a new developer can simply check the project out of the version control system and be up and running immediately. It just works.

You store your code in a central source code repository. Whenever you commit your code, a build server detects the change to the code base, and automatically runs a full suite of unit, integration, and functional tests. If any problems crop up, you (and the rest of the team) are immediately notified. You have learned from experience that committing small, regular changes makes the integration process go a whole lot smoother, and you organize your work accordingly.

You use an issue tracking system to keep tabs on features to implement, bugs to fix, or any other jobs that need doing. When you commit changes to your source code repository, you mention the issues that this change addresses in the commit message. This message is automatically recorded against these issue in the issue management system. Furthermore, if you say "Fixes #101," the issue automatically will be closed.

Conversely, when you view an issue in the issue management system, you can also see not only the commit messages but also the exact modifications that were made in the source code. When you prepare a release, it is easy to compile a set of reliable release notes based on the issues that were reported as fixed in the issue tracking system since the last release.

Your team now writes unit tests as a matter of habit. It wasn't easy to start with, but over time, coaching and peer programming have convinced everyone of the merits of test-driven development. Automatic test coverage tools help them ensure that their unit tests aren't missing out on any important code. The extensive test suite, combined with the test coverage reports, gives them enough confidence to refactor their code as necessary. This, in turn, helps keep the code at a high level of reliability and flexibility.

Coding standards and best practices are actively encouraged. A battery of automatic code auditing tools checks for any violations of the agreed set of rules. These tools raise issues relating to coding standards as well as potential defects. They also note any code that is not sufficiently documented.

These statistics can be viewed at any time, but, each week, the code audit statistics are reviewed in a special team meeting. The developers can see how they are doing as a team, and how the statistics have changed since last week. This encourages the developers to incorporate coding standards and best practices into their daily work. Because collective code ownership is actively encouraged, and peer-programming is quite frequent, these statistics also helps to foster pride in the code they are writing.

Occasionally, some of the violations are reviewed in more detail during this meeting. This gives people the opportunity to discuss the relevence of such and such a rule in certain circumstances, or to learn about why, and how, this rule should be respected.

You can view up-to-date technical documentation about your project and your application at any time. This documentation is a combination of human-written high-level architecture and design guidelines, and low-level API documentation for your application, including graphical UML class diagrams and database schemas. The automatic code audits help to ensure that the code itself is adequately documented.

The cornerstone of this process is your Continuous Integration, or CI, server. This powerful tool binds the other tools into one coherent, efficient, process. It is this server that monitors your source code repository, and automatically builds and tests your application whenever a new set of changes are committed. The CI server also takes care of automatically running regular code audits and generating the project documentation. It automatically deploys your application to an integration server, for all to see and play around with at any time. It maintains a graphical dashboard, where team members and project sponsors can get a good idea of the general state of health of your appplication at a glance. And it keeps track of builds, making it easier to deploy a specific version into the test, staging, or production environments when the time comes.

None of the tools discussed in this book are the silver bullet that will miraculously solve all your team's productivity issues. To yield its full benefits, any tool needs to be used properly. And the proper use of many of these tools can entail significant changes in the way you work. For example, to benefit from automated testing, developers must get into the habit of writing unit tests for their code. For a continous integration system to provide maximum benefits, they will need to learn to commit frequent, small changes to the version control system, and to organize their work accordingly. And, if you want to generate half-decent technical documentation automatically, you will need to make sure that your code is well-commented in the first place.

You may need to change the way people work, which is never easy. This can involve training, coaching, peer-programming, mentoring, championing, bribing, menacing, or some combination of the above. But, in the long run, it's worth it.

Hi, I am prabhakar, i have read an article about Team Building and i would like to share it with you.All successful businesses and organizations know that teamwork and team synergy is the key to success. A lot of effort and resources are dedicated towards team building exercises and activities. A good team forms the foundation of any company, organization or community. Team building is not an easy task. This is because a team consists of various individuals with distinct personalities, schools of thought and disposition. But effective team building steps can slowly help these individuals to rise above petty differences, working together and complimenting each other to ensure the overall success of the team as well as personal growth of each individual. A discordant and inharmonious team will continue to experience failure even if it comprises of brilliant individuals. Sports are a very good example of this, in team sports like Football, Hockey or Basketball the co-ordination, communication and synergy of the team is what sets the best teams apart rather than individual superstars.

Team building requires dedication and effective skills. Each member of the team must be made to feel an integral and indispensible part of the team so that team strategy and goals can be placed above individual goals.There are various team building games and exercises available but it is only with perfect execution and participation of all members can these be effective. It is also important to resolve any conflicts as soon as possible. Conflicts can be very harmful for team building. Negative feedback, especially in public should be avoided at all cost as it may hamper the team's performance.
Tuesday, 22 February 2011 06:48

Branching and Merging Practices

Written by

Branching and Merging Practices


{slideshare}[slideshare id=7007812&doc=branchingstrategies-110222000920-phpapp02]{/slideshare}
Tuesday, 22 February 2011 06:47

Advance Features of Smart Build Tools

Written by

Advance Features of Smart Build Tools


{slideshare}[slideshare id=6995921&doc=advancefeaturesofsmartbuildandtoolsstudy-110220215438-phpapp02&type=d]{/slideshare}
Tuesday, 22 February 2011 06:13

SCM Process and smartBuild

Written by

SCM Process and smartBuild


{slideshare}[slideshare id=6995905&doc=scmprocessandsmartbuild-110220215121-phpapp01]{/slideshare}

Introduction

The Information Technology Infrastructure Library (ITIL) is a set of concepts and practices for managing Information Technology (IT) services (ITSM), IT development and IT operations.

 

Purpose

ITIL stresses service quality and focuses on how IT services can be efficiently and cost-effectively provided and supported. In the ITIL framework, the business units within an organization who commission and pay for IT services (e.g. Human Resources, Accounting), are considered to be "customers" of IT services. The IT organization is considered to be a service provider for the customers.

 

It primarily focuses on what processes are needed to ensure high quality IT services; however, ITIL does not provide specific, detailed descriptions about how the processes should be implemented, as they will be different in each organization. In other words, ITIL tells an organization what to do, not how to do it.

 

The ITIL framework is typically implemented in stages, with additional processes added in a continuous service improvement program.

 

 

Benefits
Organizations can benefit in several important ways from ITIL:

· IT services become more customer-focused

· The quality and cost of IT services are better managed

· The IT organization develops a clearer structure and becomes more efficient

· IT changes are easier to manage

· There is a uniform frame of reference for internal communication about IT

· IT procedures are standardized and integrated

· Demonstrable and auditable performance measurements are defined

Processes

ITIL is a series of books that outline a comprehensive and consistent set of process-based best practices for IT Service Management, promoting the ultimate achievement of IT Service Management goals. IT Service Management (ITSM) is the process of managing IT services to effectively and efficiently meet the needs of the customer.

 

Versions

In 2001, version 2 of ITIL was released. The Service Support and Service Delivery books were redeveloped into more concise usable volumes and consequently became the core focus of ITIL. Over the following few years it became, by far, the most widely used IT service management best practice approach in the world.

In May 2007 version 3 of ITIL was published. This adopted more of a lifecycle approach to service management, with greater emphasis on IT business integration.

Where ITIL V2 outlined what should be done to improve processes, ITIL V3 explains clearly how you should go about doing it.

 

ITIL V2 Explained

The Service Management section of ITIL V2 consists of eleven disciplines and is divided into two sections as follows:

 

Service Support:

• Configuration Management

• Service Desk

• Incident Management

• Problem Management

• Change Management

• Release Management

 

Service Delivery:

• Availability Management

• IT Services Continuity Management

• Capacity Management

• Financial Management

• Service Level Management

 

 

Here are the details of Service support components.

 

1. Configuration Management

Objectives:

• Providing information on the IT infrastructure

o To all other processes

o IT Management

• Enabling control of the infrastructure by monitoring and maintaining information

on:

o All the resources needed to deliver services

o Configuration Item (CI) status and history

o Configuration Item relationships

Tasks:

• Identification and naming

• Management information

• Verification

• Control

• Status Accounting

 

Asset: Component of a business process like people, accommodation, computer systems,

paper records, fax machines, etc.

 

Configuration Management Database: A database, which contains all relevant details of

each Configuration Item (CI) and details of the important relationships between CIs.

 

A Configuration Item (CI):

• Is needed to deliver a service

• Is uniquely identifiable

• Is subject to change

• Can be managed

A Configuration Item (CI) has:

• a Category

• Relationships

• Attributes

• a Status

 

Variant: A Configuration Item (CI) that has the same basic functionality as another

Configuration Item (CI) but is different in some small way (ex: has more memory)

 

Baseline: A snapshot of the state of a Configuration Item and any component or related

Configuration Items, frozen in time for a particular purpose (such as the ability to return a

service to a trusted state if a change goes wrong)

 

Configuration Management supports all other processes!

 

Scope vs. Detail

 

Relationships – Common Types:

• Is a component of

• Is a copy of

• Relates to

• Relates with

• Is used by

 

2. Service Desk

Objectives:

• To be the primary point of call for all:

o Calls

o Questions

o Requests

o Complaints

o Remarks

• To restore the service as quickly as possible

• To manage the incident life-cycle (coordinating resolution)

• To support business activities

• To generate reports, to communicate and to promote

 

Different Desks

• Call Center: Handling large call volumes of telephone-based transactions.

• Help Desk: To manage, coordinate, and resolve Incidents as quickly as possible.

• Service Desk: Allowing business processes to be integrated into the Service

Management infrastructure. It not only handles Incidents, Problems and questions,

but also provides an interface for other activities.

 

Service Desk Essentials:

• Single point of contact / Restore service ASAP

• Tasks: Customer Interface, Business Support, Incident Control & Management

Information

• Concentrates on incident lifecycle management

• Incident: Unexpected disruption to agreed service

• Priority determined by business impact and urgency

• Correct assessment of priorities enables the deployment of manpower and other

resources to be in the best interests of the customer

• Escalation and referral

 

3. Incident Management

Objectives:

• To restore normal service as quickly as possible

• Minimize the adverse impact on business operations

• Ensuring that the best possible levels of service quality and availability are

maintained according to SLAs.

 

Incident: Any event which is not part of the standard operation of a service and which

causes or may cause an interruption to or a reduction in the quality of that service.

 

Work-Around: Method of avoiding an Incident or Problem.

 

Service Request: Every Incident not being a failure in the IT Infrastructure.

 

Problem: The unknown root cause of one or more incidents.

 

Known Error: A condition that exists after the successful diagnosis of the root cause of a

problem when it is confirmed that a CI (Configuration Item) is at fault.

Impact on the business + Urgency / Effect upon business deadlines = Priority

 

Category: Classification of a group of Incidents (Application, Hardware, etc.)

Escalation (Vertical Escalation): escalates up the management chain.

Referral (Horizontal Escalation): escalates to a different knowledge group. Routing.

Incident Life-Cycle

• Accept Service Event, Register and Consult the CMDB

• Classification

• Solve

• Closure

 

Reporting is VERY important.

• Daily reviews of individual Incident and Problem status against service levels

• Weekly management reviews

• Monthly management reviews

• Proactive service reports

 

4. Problem Management

Objectives:

• Stabilizing IT services through:

o Minimizing the consequences of incidents

o Removal of the root causes of incidents

o Prevention of incidents and problems

o Prevent recurrence of Incidents related to errors

• Improving productive use of resources

Tasks:

• Problem Control

• Error Control (including raising RfCs – Request for Change)

• Proactive Prevention

• Identifying Trends

• Management Information

• Posit Implementation Review (PIR)

Goal is to get from reactive or proactive. Stop problems from occurring / recurring.

Inputs:

• Incident details

• Configuration details

• Defined work-arounds

Outputs:

• Known Errors

• Requests for Change

• Updated Problem Records including work-arounds and/or solutions

• Response to Incident Management from Matching Management Information

Problem Control

• Identification

• Classification

• Assign Resources

• Investigation and Diagnosis

• Establish Known Error

Error Control

• Error Identification and Recording

• Error Assessment

• Recording Error / Resolution (Send out RfC)

• Error Closure

 

Known Error: An Incident or Problem for which the root cause is known and for which a

temporary Work-around or a permanent alternative has been identified.

 

Proactive Problem Management:

• Trend Analysis

• Targeting Support Action

• Providing Information to the Organization

 

Known Errors resulting from Development should be made known to the Helpdesk.

 

Reporting is also key for Problem Management.

5. Change Management

Objective: To implement approved changes efficiently, cost-effectively and with minimal

risk to the existing and to the new IT infrastructure. Only approved changes made, risk

and cost minimized.

Change Management Tasks:

• Filtering Changes

• Managing Change Process

• Managing Changes

• Chairing CAB and CAB/EC

• Review and Closure

• Management Information

Inputs:

• Requests for Change (RfC)

• CMDB

• Forward Schedule of Changes (FSC)

Outputs:

• Forward Schedule of Changes (FSC)

• Requests for Change (RFC)

• CAB minutes and actions

• Change management reports

Impact of change:

• Category 1

o Little impact on current services. The Change Manager is entitled to

authorize this RfC.

• Category 2

o Clear impact on services. The RfC must be discussed in the Change

Advisory Board. The Change Manager requests advice on authorization

and planning.

• Category 3

o Significant impact on the services and the business. Considerable

manpower and/or resources needed. The RfC will have to be submitted to

the board level (CAB/EC – Change Advisory Board / Executive

Committee)

 

Priority Setting:

• Urgent

o Change necessary now (otherwise severe business impact)

• High

o Change needed as soon as possible (potentially damaging)

• Medium

o Change will solve irritating errors or missing functionality (can be

scheduled)

• Low

o Change leads to minor improvements

 

A change backout plan must always be possible.

 

Change management always ends with a review of the change.

 

Change: The addition, modification, or removal of approved, supported or baselined

hardware, network, software, application, environment, system, desktop build or

associated documentation.

Request for Change: Form or screen, used to record details of a request for a change to

any CI within an infrastructure or to procedures and items associated with the

infrastructure.

Forward Schedule of Changes (FSC): Schedule that contains details of all the Changes

approved for implementation and their proposed implementation dates.

 

Change Management Process

1. Request for a Change

2. Registration and Classification

3. Monitoring and Planning

4. Approve

5. Build & Test

6. Authorize Implementation

7. Implementation

8. Evaluate

 

6. Release Management

Objectives:

• Safeguard all software and related items

• Ensure that only tested / correct version of authorized software are in use

• Ensure that only tested / correct version of authorized hardware are in use

• Right software, right time, right place

• Right hardware, right time, right place

Tasks:

• Define the release policies

• Control of the Definitive Software Library (DSL)

• Control of the Definitive Hardware Storage (DHS)

• Distribute Software and Associated CIs

• Carry out S/W audits (using CMDB)

• Manage the software releases

• Oversee build of the software releases

 

Releases are done under the control of Change Management.

 

DSL : Definitive Software Library. Reliable versions of software in a single logical

location. However, software may be physically stored at different locations.

 

Release Policy:

• Release Unit

• Full / Package / Delta Releases

• Numbering

• Frequency

• Emergency Change

 

Version Control:

• Development

• Testing

• Live

• Archive

 

Process:

• Software Control and Distribution (operational)

• Change Management (control)

• Configuration Management (control and administration)

 

Only process which creates its own policy.

 

Here are the details of Service Delivery components.

1. Availability Management

Objectives:

• To predict, plan for and manage the availability of services by ensuring that:

o All services are underpinned by sufficient, reliable and properly

maintained CIs

o Where CIs are not supported internally there are appropriate contractual

agreements with third party suppliers

o Changes are proposed to prevent future loss of service availability

• Only then can IT organizations be certain of delivering the levels of availability

agreed with customers in SLAs.

 

Aspects of Availability:

• Reliability

• Maintainability: Maintenance you do yourself, as a company

• Resilience: Redundancy

• Serviceability: Maintenance done by someone else

 

Availability Information is stored in an Availability Database (ADB). This information is

used to create the Availability Plan. SLAs provide an input to this process.

 

Unavailability Lifecycle

 

MTTR: Mean Time to Repair (Downtime) – Time period that elapses between the

detection of an Incident and it’s Restoration. Includes: Incident, Detection, Diagnosis,

Repair, Recovery, Restoration.

 

MTBF: Mean Time Between Failures (Uptime) – Time period that elapses between

Restoration and a new Incident.

 

MTBSI: Mean Time Between System Incidents – Time period that elapses between two

incidents. MTTR + MTBF.

 

“An IT service is not available to a customer if the functions that customer requires at

that particular location cannot be used although the agreed conditions under which the IT

service is supplied are being met”

 

Simplistic Availability Calculation:

 

Agreed Service Hours – Downtime 100

------------------------------------------ X ----

Agreed Service Hours 1

2. IT Service Continuity Management

Why plan?

• Increases Business dependency on IT

• Reduced cost and time of recovery

• Cost to customer relationship

• Survival

 

Many businesses fail within a year of suffering a major IT disaster.

 

Business Impact Analysis:

 

Risk Analysis:

• Value of Assets

• Threats

• Vulnerabilities

 

Risk Management:

• Countermeasures

• Planning for potential disasters

• Managing a disaster

 

Risk Analysis: Based on the CCTA Computer Risk Analysis and Management

Methodology (CRAMM)

 

Options:

1. Do nothing

2. Manual workarounds

3. Reciprocal arrangements

4. Gradual Recovery (cold standby)

5. Intermediate Recovery (warm standby)

6. Immediate Recovery (hot standby)

 

Cold start = accommodation. Environmental controls; power and communications

 

Hot start = cold start + computing equipment and software

 

7 Sections of the Plan:

1. Administration

2. The IT Infrastructure

3. IT Infrastructure management & Operating procedures

4. Personnel

5. Security

6. Contingency site

7. Return to normal

 

Test and Review:

• Initially then every 6 to 12 months and after each disaster

• Test it under realistic circumstances

• Move / protect any live services first

• Review and change the plan

• All changes made via the CAB – Change Advisory Board

 

Contingency Plan:

• Assists in fast, controlled recovery

• Must be given wide but controlled access

• Contents (incl. Admin, Infrastructure, People, Return to normal)

• Options (incl. Cold & Hot Start)

• Must be tested regularly – without impacting the live service

3. Capacity Management

Objective:

To determine the right, cost justifiable, capacity of IT resources such that the Service

Levels agreed with the business are achieved at the right time.

Objectives:

• Demand Management

o Business Capacity Management

• Workload Management

o Service Capacity Management

• Resource Management

o Resource Capacity Management

While doing the above, also need to do:

• Performance Management

o Internal and External Financial Data

o Usage Data

o SLM Data / Response Times

 

CDB – Capacity Data Base – Contains all Metrics, etc. Used to create a Capacity

Management Plan. Performance Management Data populates the CDB.

 

Essentials:

• From Customer Demands to Resources

• Demand Management

• Workload Management

• Performance Management

• Capacity Planning

• Defining Thresholds and Monitoring

 

Application Sizing: To estimate the resource requirements to support a proposed

application change to ensure that it meets its required service levels.

Modeling:

• Trend Analysis

• Analytical Modeling

• Simulation Modeling

• Baseline Models

• Used to Answer the “What If… “ questions

• Data for Modeling comes from the CDB

 

4. Financial Management

Objectives:

To provide information about and control over the costs of delivering IT services that

support customers business needs.

Costing is a must!

Input cost units recommended by ITIL:

• Equipment Cost Units (ECU)

• Organization Cost Units (OCU)

• Transfer Cost Units (TCU)

• Accommodation Cost Units (ACU)

• Software Cost Units (SCU)

Equipment = hardware

Organization = staff

Transfer = costs which IT incurs acting as an agent for the customer, they do not appear

as a cost against the IT department’s budget

Accommodation = buildings

Software = software

 

Different Cost Types:

• Fixed - unaffected by the level of usage

• Variable - varying according to the level of usage

• Direct - usage specific to one service

• Indirect or Overhead – usage not specific to one service

• Capital – not diminished by usage

• Revenue or running – diminish with usage

 

Charging Objectives:

• Recover from customers the full costs of the IT services provided

• Ensure that customers are aware of the costs they impose on IT

• Ensure that providers have an incentive to deliver and agreed quality and quantity

of economic and effective services

 

Charging and Pricing Options:

Charging:

• No Charging – IT treated as support center

• Notional Charging – IT treated as cost center

• Actual Charging

 

Pricing:

• Recover of Costs – IT treated as a service center

• Cost Price Plus – IT treated as a profit center

• Market Prices – IT treated as a profit center

 

Support and Cost centers used “soft charging” in which no money changes hands; service and profit centers use “hard costing” in which money is transferred between bank

accounts

 

Profit centers focus on the value of the IT service to the customer

 

Good Financial Management minimizes the risks in decision making

 

Three Main Processes:

 

Budgeting: The process of predicting and controlling the spending of money within the

enterprise and consists of periodic negotiation cycle to set budgets (usually annual) and

the day-to-day monitoring of the current budgets. Key influence on strategic and tactical

plans.

 

IT Accounting: The set of processes that enable the IT organization to fully account for

the way its money is spent (particularly the ability to identify costs by customer, by

service, by activity).

 

Charging: The set of processes required to bill a customer for the services applied to

them. To achieve this requires sound IT Accounting, to a level of detail determined by

the requirements of the analysis, billing, and reporting procedures.

 

5. Service Level Management

Balance between the Demand for IT services and the Supply of IT services by knowing

the requirements of the business and knowing the capabilities of IT.

Objectives:

• Business-like relationship between customer and supplier

• Improved specification and understanding of service requirements

• Greater flexibility and responsiveness in service provision

• Balance customer demands and cost of services provision

• Measurable service levels

• Quality improvement (continuous review)

• Objective conflict resolution

 

Tasks:

• Service Catalog

• Service Level Requirements

• Service Level Agreement

• Operational Level Agreements (OLA) and Contracts

• Service Specsheet

• Service Quality Plan

• Monitor, Review and Report

• Service Improvement Programs

• Customer Relationship Management

 

Minimum Requirements for an Agreement:

• Period

• Service Description

• Throughput

• Availability

• Response Times

• Signature

 

Other Possible Clauses:

• Contingency arrangements

• Review procedures

• Change procedures

• Support services

• Customer responsibilities

• Housekeeping

• Inputs and Outputs

• Changes

 

Ideally contracts are based on targets in the SLA

 

SLAs must be monitored regularly and reviewed regularly

• Monitor to see if service is being delivered to specification

• Review to see if service specification is still appropriate

 

Overview of the ITIL v3 library

Five volumes comprise the ITIL v3, published in May 2007:

1. ITIL Service Strategy

2. ITIL Service Design

3. ITIL Service Transition

4. ITIL Service Operation

5. ITIL Continual Service Improvement

Service Strategy

As the center and origin point of the ITIL Service Lifecycle, the ITIL Service Strategy volume provides guidance on clarification and prioritization of service-provider investments in services. More generally, Service Strategy focuses on helping IT organizations improve and develop over the long term. In both cases, Service Strategy relies largely upon a market-driven approach. Key topics covered include service value definition, business-case development, service assets, market analysis, and service provider types. List of covered processes:

  • Service Portfolio Management
  • Demand Management
  • IT Financial Management
  • Supplier Management

Service Design

The ITIL Service Design volume provides good-practice guidance on the design of IT services, processes, and other aspects of the service management effort. Significantly, design within ITIL is understood to encompass all elements relevant to technology service delivery, rather than focusing solely on design of the technology itself. As such, Service Design addresses how a planned service solution interacts with the larger business and technical environments, service management systems required to support the service, processes which interact with the service, technology, and architecture required to support the service, and the supply chain required to support the planned service. Within ITIL v2, design work for an IT service is aggregated into a single Service Design Package (SDP). Service Design Packages, along with other information about services, are managed within the service catalogs. List of covered processes:

  • Service Catalogue Management
  • Service Level Management
  • Risk Management
  • Capacity Management
  • Availability Management
  • IT Service Continuity Management
  • Information Security Management
  • Compliance Management
  • IT Architecture Management
  • Supplier Management

Service Transition

Service transition, as described by the ITIL Service Transition volume, relates to the delivery of services required by a business into live/operational use, and often encompasses the "project" side of IT rather than "BAU". This area also covers topics such as managing changes to the "BAU" environment.

List of processes:

  • Service Asset and Configuration Management
  • Service Validation and Testing
  • Evaluation
  • Release Management
  • Change Management
  • Knowledge Management

Service Operation

Best practice for achieving the delivery of agreed levels of services both to end-users and the customers (where "customers" refer to those individuals who pay for the service and negotiate the SLAs). Service operation, as described in the ITIL Service Operation volume, is the part of the lifecycle where the services and value is actually directly delivered. Also the monitoring of problems and balance between service reliability and cost etc are considered. The functions include technical management, application management, operations management and Service Desk as well as, responsibilities for staff engaging in Service Operation.

List of processes:

  • Event Management
  • Incident Management
  • Problem Management
  • Request Fulfillment
  • Access Management

Continual Service Improvement (CSI)

Aligning and realigning IT services to changing business needs (because standstill implies decline).

Continual Service Improvement, defined in the ITIL Continual Service Improvement volume, aims to align and realign IT Services to changing business needs by identifying and implementing improvements to the IT services that support the Business Processes. The perspective of CSI on improvement is the business perspective of service quality, even though CSI aims to improve process effectiveness, efficiency and cost effectiveness of the IT processes through the whole lifecycle. To manage improvement, CSI should clearly define what should be controlled and measured.

CSI needs to be treated just like any other service practice. There needs to be upfront planning, training and awareness, ongoing scheduling, roles created, ownership assigned, and activities identified to be successful. CSI must be planned and scheduled as process with defined activities, inputs, outputs, roles and reporting.

List of processes:

  • Service Level Management
  • Service Measurement and Reporting
  • Continual Service Improvement
----------------------------------------------------------------------------------------------------------------------------------

Page 1 of 3