KIT PREPARATRIO ITIL FOUNDATION

APOSTILA RESUMO - REVISO DOS PONTOS CHAVES

O objetivo deste material revisar e memorizar os conceitos chaves dos processos de
Service Suporte e Service Delivery para lhe preparar para o Exame ITIL FOUNDATION da
EXIN. Este resumo orientado para a prova no idioma Ingls. Este material serve apenas
como apoio, recomendvel que voc leia outras fontes para complementar o seu estudo.
garantido que muitos dos conceitos aqui iro aparecer durante as questes do
exame.

CONCEITOS GERAIS

A ITIL pode ser aplicada a qualquer tipo de empresa e tamanho.

A ITIL no um modelo pronto, deve ser adaptado em cada empresa.
O Gerenciamento de Servios de TI a razo para adotar a ITIL.
Os processos descritos nos livros da ITIL esto em conformidade com o PD0005
(British Standards Institutions Code of Practice for IT Service Management), de
onde a ITIL foi baseada.
O OGC o mantenedor da ITIL, o itSMF um frum para discutir as melhores
prticas.
Os processos do Service Support est focado em processos operacionais, j o
Service Delivery em processos tticos
A ITIL composta de 7 livros:

Os processos entre os Processos Service Support e Service Delivery podem se

sobrepor.
Usurios so aqueles que utilizam os servios de TI no dia-a-dia. Clientes so
aqueles que pagam pelos servios de TI.

Os processos da ITIL buscam a eficincia e eficcia, e as duas palavras tm

sentido diferentes. Eficincia: melhoria no processo, otimizao. Eficcia: dar
resultado esperado.
Aspectos culturais da empresa podem dificultar a implementao de um
Gerenciamento de servios de TI.
Viso: onde a empresa quer chegar no futuro, Misso o propsito da empresa.
Processos so compostos de entradas, tarefas e sadas. Cada Tarefa pode conter
funes: executadas por pessoas ou automatizadas, e regras que definem como
devem ser executadas as tarefas.

Foco dos dois principais livros da ITIL. Os processos do Livro Service Support so
operacionais e do Livro Service Delivery so tticos.
Poltica de Qualidade
Para a melhoria de qualidade, Deming props o Ciclo de Deming (ou crculo). Os quatro
estgios chaves so: planejar, fazer, verificar e agir (em ingls PLAN, DO, CHECK, ACT
PDCA),

RELACIONAMENTO ENTRE OS PROCESSOS

Configuration Management
Gera informaes para o Financial Management for IT para poder fazer a
contabilizao de gastos sobre os ativos de TI
Para o IT Service Continuity Management para considerar os componentes no o
plano de continuidade de TI
Para o Availability Management levantar riscos relacionados disponibilidade
Change Management
Tem relacionamento muito prximo com o processo de Configuration Management
para levantar onde a mudana ir impactar
No Release Management para liberar a correes desenvolvidas
Release Management
Tem dependncia do processo de Change Management.
Utiliza o Configuration Management para registrar os releases.
Incident Management
Deve funcionar em conjunto com os processos de Problem Management e Change
Management.
Configuration Management importante para realizar analise de impacto, identificar
solues de contorno.
Problem Management
Necessita ter implementado j o processo de Incident Management.
Service Level Management
importante j ter os processos de suporte implementados para suportar as SLAs
DICA: muito importante saber quais processos so implementados em conjunto.

SERVICE DESK

uma funo, no um processo.

Ponto Central de contato aumenta a percepo e satisfao dos usurios
Suporte s metas do negcio. Tem como objetivo restaurar o servio o mais rpido
possvel.
Coordena o ciclo de vida do incidente.
Deve registrar todos os incidentes, mesmo que no possa atender na hora.
Fornece suporte 1. Nvel .
2. Nvel de Suporte so os tcnicos com conhecimento maior, ainda so
generalistas.
3. Nvel de Suporte so especialistas ou terceiros contratados
Produz mtricas de performance dos servios
Categorizam os incidentes
Personalidade necessria para a equipe de service-desk
o Paciente
o Comunicativo
o Amigo

o Entusiasmado
o Assertivo
o Emptico
o Honesto
Tipos de Desks
o Call Center: para atender um grande volume de chamadas.
o Help Desk: foco em resolver incidentes relacionados a hardware, software
bsicos.
Service Desk: Integra todos os processos do Gerenciamento de Servios de TI. No s
recebe incidentes, problemas e dvidas, mas tambm faz interface com outras atividades.

INCIDENT MANAGEMENT

Objetivos:
o Restaurar o servio normal o mais rpido possvel.
o Minimizar o impacto negativo nos negcios.
o Fornecer um nvel de servio com mais qualidade, dando apoio ao
cumprimento das SLAs.
Incidente um evento que no parte padro de um servio, que pode interromper
a tarefa de um usurio.
Work-around: soluo de contorno.
Service Request: requisio de servio, no trata-se de um incidente de falha.
Incidente causa interrupo do servio.
Incidente causa a reduo no servio.
Um incidente tem um Ciclo de Vida:
Deteco e Gravao
Classificao e Suporte
Investigao e Diagnstico
Resoluo e Recuperao (Recovery)
Fechamento

A prioridade do Incidente composta da combinao de Impacto + Urgncia.

Impacto = efeito do incidente no negcio, quantidade de usurios relacionados.
Urgncia = tempo necessrio para resolver o incidente.

Escalonamento poder ser de duas formas:

Funcional: quando um incidente repassado de um nvel de suporte para outro,
devido ao nvel de conhecimento tcnico.
Hierrquico: quando necessrio acionar o gerente do processo devido ao nvel
autoridade exigido.

PROBLEM MANAGEMENT

Objetivos:
o Estabilizar os servios de TI atravs de:
Minimizar as conseqncias dos incidentes
Identificar a causa raiz dos incidentes
Preveno de incidentes e problemas
Prevenir a recorrncia dos incidentes.
Tarefas:
o Controle de Problemas
o Controle de Erros (inclui abertura de uma RFC para eliminar o erro)
o Preveno proativa
o Identificar tendncias nos incidentes
o Informaes Gerenciais
o Reviso Pos Implementao (PIR)
Problema quando a causa responsvel por um ou mais incidente no
conhecida.

Erro Conhecido (Know Error): quando a causa raiz j conhecida e existe uma
soluo de contorno
Anlise da Causa Raiz o processo para descobrir a causa de um problema.
O Problem Management tem dois sub-processos:
o Problem Control: identificar a causa raiz
o Error Control: acompanhar a erradicao do erro
Poder ser um processo Proativo ou Reativo
necessrio uma RFC (requisio de mudana) para resolver um Erro Conhecido.
Este processo no responsvel por implementar a correo.
Existem duas ferramentas para identificao do erro: Diagrama de Ishikawa e
Analise de Kepner e Tregoe.
Quando a equipe do Gerenciamento de Problemas se foca em fazer anlise de
tendncias dos incidentes est fazendo uma atividade PRO-ATIVA no processo.

Um Erro Conhecido obtido quando:

Diagrama de IshiKawa usado como tcnica para anlise da causa raiz

Um incidente pode ter um problema relacionado que em determinado momento vira um

erro conhecido que para ser eliminado precisa ser aberto uma Requisio de Mudana
(RFC)

Lembre: um erro para ser erradicado da infra-estrutura precisa passar por uma mudana.

CONFIGURATION MANAGEMENT

Objetivos
o Fornecer informao sobre a Infra-estrutura de TI:
Para os outros processos
Para o Gerenciamento de TI
o Possibilitar o controle da infra-estrutura atravs do monitoramento e
manuteno de informaes sobre:
Todos os recursos para prover os servios
Status dos Itens de Configurao
Relacionamento entre os Itens de Configurao.
Tarefas
o Identificao
o Informaes Gerenciais
o Verificao
o Controle
o Controle de Status (Status Accounting)
Asset (Ativo) : um componente fsico (fax, computador, prdio, etc)
Os CIs (Configuration Itens) so armazenados no CMDB (base de configurao) e
no na DSL (biblioteca definitiva de software)
Os CIs so REGISTROS e so compostos de atributos, entre eles
o ID

o Tipo
o Nome
o Custo
o Local
Principais tipos de Relacionamentos entre CIs
o Componente de
o Filho de
o Cpia de
o Relaciona com
o Usado por
O CMDB no um software de Inventrio (asset management), o diferencia que
ele possui RELACIONAMENTOS entre os CIs (Pai Filho)
Base Level o nvel mais baixo, onde os CIs so identificados de forma nica.
O nvel em que a infra-estrutura deve ser quebrada no pode ser muito detalhado
nem muito superficial, deve ser no nvel em que possvel identificar os itens na
infra-estrutura e possa relacion-los com os processos.
Status Accounting uma atividade responsvel por manter o status de um item de
configurao (ex.: ativo, no estoque, instalado, em manuteno, aposentado).
Variant: um item de configurao que tem a mesma funcionalidade que outro,
mas tem uma pequena diferena, exemplo: mais memria RAM.
Baseline: o histrico (fotografia) de um determinador Item de Configurao ou
vrios em determinado tempo, serve para reparar a configurao quando houver
uma mudana mal sucedida.

CHANGE MANAGEMENT

Objetivos:
o Implementar mudanas aprovadas de forme eficiente com o menor custo e
menor risco.
Tarefas:
o Filtrar Mudanas
o Gerenciar o Processo de Mudanas (no executa o desenvolvimento)
o Presidir as reunies do CAB (Conselho)
o Reviso e Fechamento
o Informaes Gerenciais
RFC (Request For Change) o registro de uma mudana, possui detalhes da
mudana.
FSC (Foward Schedule of Changes) a agenda programada para mudanas.
PSA (Project Service Availability) possui detalhes das mudanas para atender as
SLAs devido a FSC.
Categoria de Mudanas
o MINOR o prprio Change Manager pode aprovar
o SIGNIFICANT necessita da aprovao do CAB
o MAJOR necessita aprovao do conselho administrativo da empresa
o URGENT/EMERGENCY -existe o CAB/EC que o conselho para
aprovao de mudanas urgentes.
Processo de Mudana
o Registro, Aceite, Priorizao.
o Categorizao, Autorizao, Desenvolvimento, Teste, Agendamento
o Implementao e Back out (retroceder)

o Reviso e Fechamento
Um plano de backout (retrocesso) deve existir sempre que possvel
O processo termina com a reviso da mudana

RELEASE MANAGEMENT

Objetivos:
o Guardar com segurana todos os softwares e itens relacionados.
o Garantir que apenas softwares e hardware testados e aprovados estejam
em uso.
Tarefas:
o Definir polticas de liberaes
o Controlar a Biblioteca de Software Definitiva (DSL)
o Controlar a Depsito de Hardware Definitivo (DHL)
o Distribuir softwares e items associados (CIs)
o Gerenciar as liberaes de softwares
o Acompanhar a liberao dos softwares
um processo dependente do Change Management e do Configuration
Management.
responsvel pelo Roll out da mudana na infra-estrutura
DSL (Definitive Software Library) onde so armazenadas todas as cpias fsicas
de softwares autorizados.
DHS (Definitive Hardware Store) uma rea para armazenar componentes de
hardwares, uma espcie de estoque de peas de TI.
Definies de Release:
o Release: uma coleo de mudanas autorizadas
o Release Unit: uma poro da infra-estrutura de TI que normalmente
liberada junto.
o Roll-out: entrega, instalao de novas mudanas ou novos CIs pela
organizao.
Tipos de Releases:
o Delta: release parcial de CIs que tm mudado ou so novos desde o ltimo
release. um release no muito confivel porque no foi testado com todos
os componentes juntos.
o Package: releases individuais de unidades FULL, DELTA ou ambos sendo
agrupados em forma de um pacote.

Full: possui todos os componentes do release. um release mais confivel

pois todos os componentes foram testados juntos.

SERVICE LEVEL MANAGEMENT

Balancear a Demanda dos Servios de TI e o Fornecimento dos Servios de TI

conhecendo os requisitos de negcio e capacidades da TI.
Objetivos:
o Manter um relacionamento entre cliente fornecedor
o Melhorar a especificao e entendimento dos requisitos do servio
o Balancear a demanda do cliente e o custo da proviso do servio
o Mensurar os nveis de servios
o Buscar melhoria na qualidade
Service Catalog uma lista de servios oferecidos pela TI
Service Level Requirements so as necessidades dos clientes em relao ao
servio de TI
Service Level Agreement um acordo entre TI / CLIENTE no um documento
tcnico, tambm no um contrato.
Operation Level Agreement um acordo entre TI e a sua equipe interna, pode ser
usado linguagem tcnica
Underpinning Contract um contrato realizado com prestadores de servio externo.
um processo que tem foco no custo x qualidade

As SLAS precisam ser monitoradas e revisadas constantemente.

FINANCIAL MANAGEMENT FOR IT SERVICES

Objetivos:
o Fornecer informao e controlar os custos da entrega de servios de TI que
suportam a necessidades de negcio dos clientes.

Atividades Principais de Finanas de TI

Principais custos de TI:

o Transferncia
o Hardware
o Softwares
o Pessoas Staff
o Servios de Terceiros
o Prdios (Acomodao)
Tipos de custos:
o Fixo: no afetado pela quantidade de uso
o Varivel: afetado pela quantidade de uso
o Direto: custos que podem ser alocados unicamente a um produto, servio
ou centro de custo. Exemplo: Pessoas, Contratos
o Indireto ou OVERHEAD: o pode ser alocado direitamente a um produto,
servio ou centro de custo. um custo Overhead que deve ser rateado.
o CAPITAL = so custos oriundo de compra de ativos fsicos (computadores,
prdios)
o OPERATIONAL = custo operacional para rodar a TI (custos de pessoas)
Um MODELO DE CUSTO precisa ser definido e acordado antes de realizar a
COBRANA (CHARGE). Modelo de custo forma que vai ser distribudo os custos.
Tipos de Precificao:
o At Cost
o Cost Plus
o Going Rate
o Market Rate
o Fixed Price
Formas de Cobrana:
o No Charging (sem cobrana) : a TI tratada como um centro de suporte.
o Notional Charging: a TI tratada como um centro de Custo

Actual Charging

CAPACITY MANAGEMENT

Objetivos:
o Determinar a capacidade dos recursos de TI de forma correta e com custos
justificveis para atender os nveis acordados com os clientes.
Processo que ajuda a predizer os investimentos necessrios em TI
Possui 3 sub-processos:

o Business Capacity Management requisitos futuros do negcio

o Resource Capacity Management recursos necessrios para os
servios
o Demand Management - controlar o uso dos servios de TI atravs de
Differential Charging (cobrana diferencial, cobrar o excedente)
Modelling para estimar a carga de trabalho
o Analise de Tendncia (trends)
o Modelagem Analtica (Analytical)
o Modelagem por simulao
o Modelagem por baseline
Application Sizing: dimensionamento para implementar uma nova aplicao
CDB (Capacity Data Base) - contm mtricas para criar o plano de
capacidade.

AVAILABILITY MANAGEMENT

Objetivos:
o Predizer, planejar e gerenciar a disponibilidade dos servios de TI
assegurando que:
Todos os servios esto apoiados em CIs confiveis, e mantidos de
forma apropriada.
Onde os CIs no forem mantidos internamente dever procurar a
contratao de terceiros.

Mudanas so propostas para prevenir a perda futura da

disponibilidade dos servios.
o A TI esteja certa da disponibilidade dos servios acordados em SLAs com
os clientes.
Disponibilidade dos servios de TI, busca satisfazer as necessidades dos usurios,
atender os acordos de SLAs estabelecidos.
Aspectos da Disponibilidade:
o Reliability
o Mantainability: a manuteno feita pela equipe interna de TI.
o Resilence: redundncia.
o Serviceability: manuteno feita por terceiros.
Single Points of Failure (SPOF): identifica atravs de mapas quais componentes
esto influenciando na disponibilidade do servio.
Este processo tambm se preocupa com os planos de recuperao dos servios.
Consideraes sobre a Segurana dos Servios
o Confidencialidade (Confidenciality)
o Integridade (Integrity)
o Disponibilidade (Availability)
Principais mtodos para o Gerenciamento da Disponibilidade:
o Component Failure Impact Analysis (CFIA)
o Fault Tree Analysis (FTA)
o The CCTA Risk Analysis and Management Method (CRAMM)
o Systems Outage Analysis (SOA)

Component Failure Analysis

Fault Tree Analysis

Clculo da Indisponibilidade

Um servio no est disponvel para o cliente se as funes que o cliente requisitar no

estiverem em funcionamento normal.

MTBF

Tempo mdio entre as falhas (Uptime)

MTTR

Tempo mdio para reparar (Downtime)

MTBSI

Tempo mdio entre Incidentes (MTTR + MTBF)

IT SERVICE CONTINUITY MANAGEMENT

Por que fazer planejamento de contingncia?

o Aumento da dependncia dos negcios sobre a TI.
o Reduz o tempo e custo para fazer a recuperao quando acontecer o
desastre.
o Sobrevivncia
o Evitar imagem negativa perante os clientes e mercado.
Busca a reduo da vulnerabilidade dos servios de TI
Utiliza a Anlise de RISCO. Baseado no CCTA (Computer Risk Analysis and

Management Methodology (CRAMM)).

Contra-medidas Opes de Recovery

o Fazer nada
o Backup Manual
o Arranjos Recprocos (acordos entre duas empresas)
o Cold Gradual Recovery > 72 h
o Warm Intermediate Recovery > 24 a 72 h
o Hot Immediate Recovery - 0 a 8 h
Os planos de recovery devem ser testados regularmente para garantir maior
confiabilidade.