ITILFor Failers

Roberto Gaisergaiser@geekbunker.org@rgaiser

1

INFORMATION TECHNOLOGY INFRASTRUCTURE LIBRARY

The Information Technology Infrastructure Library (ITIL) is a set of concepts and pract ices for Information Technology Services Management (ITSM), Information Technology (IT) development and IT operations.

ITIL gives detailed descriptions of a number of important IT practices and provides comprehensive checklists, tasks and procedures that any IT organization can tailor to its needs. ITIL is published in a series of books, each of which covers an IT management topic.

source: Wikipedia

2

SOFTCORE VERSION3

HARDCORE VERSION4

CERTIFICATION5

DISCLAIMER

• Basic ITIL certification

• Adults only

• Based on real life pain

• Engrish

• Last chance to leave the room!

6

FANTASY

7

REALITY

8

ITIL IN A NUTSHELL

• Created for corporate IT, the fastest way to fix the printer problem.

• Can you apply the same methodology to content provider/ISP?

• "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato

9

ITIL IN A NUTSHELL

• Process == Common Sense

• If you’re not doing anything close to this, you’re doing it wrong.

• Industry standard? Where?

10

CMDB

CMDB

11

CMDB DATA MODEL12

CMDB

• Different People, Different Meaning.

• It is not a standard, ITIL is vague about this.

• It is not a monolithic database that will contain all of your IT configuration data.

13

CMDB• It is not just a database to

store configuration data and/or asset data.

• Doesn’t provide the information that operations need.

• It’s going to filled with outdated information since the beginning.

14

CMDB

• Federated CMDB x Single database

• Tools? Seriously?

• Relationship between asset and configuration, try creating it using the available tools...

15

CHANGE MANAGEMENT

16

CHANGE• All your problems can be fixed

with a checklist or a new process, yeah right!

• If you don’t know what and why is changing in your infrastructure, ITIL its not going to save you.

• Pre-approved changes. Beginning of the End!

• Cannot see the big picture, the relationship between components. The mythical CMDB.

17

CHANGE

• "It's a basic truth of the human condition that everybody lies. The only variable is about what."

• Limited by the knowledge and the skills of the people actually working.

• Agile + Itil. One RFC per sprint...

• Tools to create and manage the RFC.

18

CHANGE

• Correlation between changes and incidents. Monitoring tools are never aware of the RFC being executed.

• Infrastructure always neglected.

• Change record, lost forever on a search tool based on “select like”.

19

CHANGE ADVISORY BOARD• Technical decisions made by

people chosen by their status, not their skills.

• Results in a “Change Calendar”, sometimes even this doesn’t work.

• Gadgets should be banned, the meeting will last 15 minutes.

• The change was approved by the board. All the information requested were provided. Success?

20

INCIDENT MANAGEMENT

21

INCIDENT

• If you do not have a incident process in place, you’re doing...

• Metrics culture

• Everything is an incident:

• the good

• the bad

• the ugly

22

INCIDENT

• Incident SLA are not related to the site availability, user experience or any useful information.

• ex: 4 hours to rebuild a RAID array. So? It’s RAID...

• Patches and workarounds to beat the SLA.

23

PROBLEM MANAGEMENT

24

PROBLEM• Problems are always created

to fix some bizarre metric

• Caused by the lack of planning and foresight.

• Forever alone, forgotten, left behind.

• Let’s create a new metric based on Problem Resolution!

25

SERVICE DESK

26

SERVICE DESK

• If you do not have a Service Desk in place, you’re doing...

• Actually works.

• Tools that work and are easy to use, they exist?

• Knowledge base and incident record. Likely based on “select like”.

27

METRICS CULTURE

28

METRICS CULTURE

• “Oh, people can come up with statistics to prove anything. 14% of people know that.”- Homer Simpson

• Collection of workarounds.

• “There are no incidents related to that” != “If It's Not Broken, Don't Fix It!”

29

METRICS CULTURE

• “He always close the incidents before the SLA”. The same one, over and over again...

• Why change something and risk looking bad in the report?

• Limits innovation.

30

TOOLS

31

TOOLS

• Interface?

• Usability?

• Search?

• Same (ugly) tool for everything, incident, change, CMDB. Webservices anyone?

• Lots of “black ops” systems to provide useful information, and a bunch of “.xls” on a SMB share.

32

POSSIBLE SOLUTIONS

33

POSSIBLE SOLUTIONS

• Stop the Metrics Culture.

• Stop creating checklists and processes, get rid of the bad apples.

• RFCs are similar to code comments or change logs, because they are mandatory doesn't mean that they are useful.

• Ex: “a” or “.”

34

POSSIBLE SOLUTIONS• Create a interface to gather all this

information and make it easy to use. Maybe you have a whole department that do this kind of stuff...

• Encourage people to really solve the problem and create better solutions, not a workaround to close a problem or incident before the SLA.

• Common sense, you don’t need a “book” for that. If you need...

35

QUESTIONS?

36