Fffffuuuuconf 2010 Presentation

1. ITIL
For Failers
Roberto Gaiser
gaiser@geekbunker.org
@rgaiser
1

2. INFORMATION TECHNOLOGY
INFRASTRUCTURE LIBRARY
The Information Technology Infrastructure Library (ITIL) is a
set of concepts and pr actices 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

3. SOFTCORE VERSION
3

4. HARDCORE VERSION
4

5. CERTIFICATION
5

6. DISCLAIMER
• Basic ITIL certification
• Adults only
• Based on real life pain
• Engrish
• Last chance to leave the room!
6

7. FANTASY
7

8. REALITY
8

9. 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

10. ITIL IN A NUTSHELL
• Process == Common Sense
• Ifyou’re not doing anything
close to this, you’re doing it
wrong.
• Industry standard? Where?
10

11. CMDB
CMDB
11

12. CMDB DATA MODEL
12

13. CMDB
• Different People, Different
Meaning.
• Itis not a standard, ITIL is
vague about this.
• Itis not a monolithic
database that will contain all
of your IT configuration
data.
13

14. CMDB
• Itis 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

15. CMDB
• Federated CMDB x Single
database
• Tools? Seriously?
• Relationship between asset
and configuration, try
creating it using the available
tools...
15

16. CHANGE MANAGEMENT
16

17. 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

18. 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

19. CHANGE
• Correlationbetween 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

20. 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

21. INCIDENT MANAGEMENT
21

22. 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

23. INCIDENT
• IncidentSLA 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...
• Patchesand workarounds to
beat the SLA.
23

24. PROBLEM MANAGEMENT
24

25. 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

26. SERVICE DESK
26

27. 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

28. METRICS CULTURE
28

29. 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

30. 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

31. TOOLS
31

32. 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

33. POSSIBLE SOLUTIONS
33

34. 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

35. 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

36. QUESTIONS?
36