KIT PREPARATÓRIO ITIL FOUNDATION

APOSTILA RESUMO - REVISÃO 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 Inglês. Este material serve apenas
como apoio, é recomendável que você leia outras fontes para complementar o seu estudo.
É garantido que muitos dos conceitos aqui irão aparecer durante as questões do
exame.

CONCEITOS GERAIS

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

• A ITIL não é um modelo pronto, deve ser adaptado em cada empresa.
• O Gerenciamento de Serviços de TI é a razão para adotar a ITIL.
• Os processos descritos nos livros da ITIL estão em conformidade com o PD0005
(British Standards Institution’s Code of Practice for IT Service Management), de
onde a ITIL foi baseada.
• O OGC é o mantenedor da ITIL, o itSMF é um fórum para discutir as melhores
práticas.
• Os processos do Service Support está focado em processos operacionais, já o
Service Delivery em processos táticos
• A ITIL é composta de 7 livros:

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

sobrepor.
• Usuários são aqueles que utilizam os serviços de TI no dia-a-dia. Clientes são
aqueles que pagam pelos serviços de TI.
 • Os processos da ITIL buscam a eficiência e eficácia, e as duas palavras têm
sentido diferentes. Eficiência: melhoria no processo, otimização. Eficácia: dar
resultado esperado.
• Aspectos culturais da empresa podem dificultar a implementação de um
Gerenciamento de serviços de TI.
• Visão: é onde a empresa quer chegar no futuro, Missão é o propósito da empresa.
• Processos são compostos de entradas, tarefas e saídas. Cada Tarefa pode conter
funções: 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 são
operacionais e do Livro Service Delivery são táticos.

Política de Qualidade
Para a melhoria de qualidade, Deming propôs o Ciclo de Deming (ou círculo). Os quatro
estágios chaves são: planejar, fazer, verificar e agir (em inglês PLAN, DO, CHECK, ACT –
PDCA),
RELACIONAMENTO ENTRE OS PROCESSOS

Configuration Management
• Gera informações para o Financial Management for IT para poder fazer a
contabilização 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 próximo com o processo de Configuration Management
para levantar onde a mudança irá impactar
• No Release Management para liberar a correções desenvolvidas

Release Management
• Tem dependência 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
soluções 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 são implementados em conjunto.

SERVICE DESK

• É uma função, não é um processo.

• Ponto Central de contato – aumenta a percepção e satisfação dos usuários
• Suporte às metas do negócio. Tem como objetivo restaurar o serviço o mais rápido
possível.
• Coordena o ciclo de vida do incidente.
• Deve registrar todos os incidentes, mesmo que não possa atender na hora.
• Fornece suporte 1º. Nível .
• 2º. Nível de Suporte são os técnicos com conhecimento maior, ainda são
generalistas.
• 3º. Nível de Suporte são especialistas ou terceiros contratados
• Produz métricas de performance dos serviços
• Categorizam os incidentes
• Personalidade necessária para a equipe de service-desk
o Paciente
o Comunicativo
o Amigo
o Entusiasmado
 o Assertivo
o Empático
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
básicos.
Service Desk: Integra todos os processos do Gerenciamento de Serviços de TI. Não só
recebe incidentes, problemas e dúvidas, mas também faz interface com outras atividades.

INCIDENT MANAGEMENT

• Objetivos:
o Restaurar o serviço normal o mais rápido possível.
o Minimizar o impacto negativo nos negócios.
o Fornecer um nível de serviço com mais qualidade, dando apoio ao
cumprimento das SLAs.
• Incidente é um evento que não é parte padrão de um serviço, que pode interromper
a tarefa de um usuário.
• Work-around: solução de contorno.
• Service Request: requisição de serviço, não trata-se de um incidente de falha.
• Incidente causa interrupção do serviço.
• Incidente causa a redução no serviço.
• Um incidente tem um Ciclo de Vida:
• Detecção e Gravação
• Classificação e Suporte
• Investigação e Diagnóstico
• Resolução e Recuperação (Recovery)
• Fechamento
• A prioridade do Incidente é composta da combinação de Impacto + Urgência.
• Impacto = efeito do incidente no negócio, quantidade de usuários relacionados.
 • Urgência = tempo necessário para resolver o incidente.

• Escalonamento poderá ser de duas formas:

• Funcional: quando um incidente é repassado de um nível de suporte para outro,
devido ao nível de conhecimento técnico.
• Hierárquico: quando é necessário acionar o gerente do processo devido ao nível
autoridade exigido.

PROBLEM MANAGEMENT

• Objetivos:
o Estabilizar os serviços de TI através de:
• Minimizar as conseqüências dos incidentes
• Identificar a causa raiz dos incidentes
• Prevenção de incidentes e problemas
• Prevenir a recorrência dos incidentes.
• Tarefas:
o Controle de Problemas
o Controle de Erros (inclui abertura de uma RFC para eliminar o erro)
o Prevenção proativa
o Identificar tendências nos incidentes
o Informações Gerenciais
o Revisão Pos Implementação (PIR)
• Problema é quando a causa responsável por um ou mais incidente não é
conhecida.
• Erro Conhecido (Know Error): quando a causa raiz já é conhecida e existe uma
solução de contorno
• Análise 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 erradicação do erro
• Poderá ser um processo Proativo ou Reativo
• É necessário uma RFC (requisição de mudança) para resolver um Erro Conhecido.
Este processo não é responsável por implementar a correção.
• Existem duas ferramentas para identificação do erro: Diagrama de Ishikawa e
Analise de Kepner e Tregoe.
• Quando a equipe do Gerenciamento de Problemas se foca em fazer análise de
tendências dos incidentes está fazendo uma atividade PRO-ATIVA no processo.

Um Erro Conhecido é obtido quando:

Diagrama de IshiKawa usado como técnica para análise 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 Requisição de Mudança
(RFC)
Lembre: um erro para ser erradicado da infra-estrutura precisa passar por uma mudança.

CONFIGURATION MANAGEMENT

• Objetivos
o Fornecer informação sobre a Infra-estrutura de TI:
 Para os outros processos
 Para o Gerenciamento de TI
o Possibilitar o controle da infra-estrutura através do monitoramento e
manutenção de informações sobre:
 Todos os recursos para prover os serviços
 Status dos Itens de Configuração
 Relacionamento entre os Itens de Configuração.
• Tarefas
o Identificação
o Informações Gerenciais
o Verificação
o Controle
o Controle de Status (Status Accounting)
• Asset (Ativo) : é um componente físico (fax, computador, prédio, etc)
• Os CIs (Configuration Itens) são armazenados no CMDB (base de configuração) e
não na DSL (biblioteca definitiva de software)
• Os CIs são REGISTROS e são 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 Cópia de
o Relaciona com
o Usado por
• O CMDB não é um software de Inventário (asset management), o diferencia é que
ele possui RELACIONAMENTOS entre os CIs (Pai – Filho)
• Base Level é o nível mais baixo, onde os CIs são identificados de forma única.
• O nível em que a infra-estrutura deve ser quebrada não pode ser muito detalhado
nem muito superficial, deve ser no nível em que é possível identificar os itens na
infra-estrutura e possa relacioná-los com os processos.
• Status Accounting é uma atividade responsável por manter o status de um item de
configuração (ex.: ativo, no estoque, instalado, em manutenção, aposentado).
• Variant: é um item de configuração que tem a mesma funcionalidade que outro,
mas tem uma pequena diferença, exemplo: mais memória RAM.
• Baseline: é o histórico (fotografia) de um determinador Item de Configuração ou
vários em determinado tempo, serve para reparar a configuração quando houver
uma mudança mal sucedida.

CHANGE MANAGEMENT

• Objetivos:
o Implementar mudanças aprovadas de forme eficiente com o menor custo e
menor risco.
• Tarefas:
o Filtrar Mudanças
o Gerenciar o Processo de Mudanças (não executa o desenvolvimento)
o Presidir as reuniões do CAB (Conselho)
o Revisão e Fechamento
o Informações Gerenciais
• RFC (Request For Change) é o registro de uma mudança, possui detalhes da
mudança.
• FSC (Foward Schedule of Changes) é a agenda programada para mudanças.
• PSA (Project Service Availability) possui detalhes das mudanças para atender as
SLA’s devido a FSC.
• Categoria de Mudanças
o MINOR – o próprio Change Manager pode aprovar
o SIGNIFICANT – necessita da aprovação do CAB
o MAJOR – necessita aprovação do conselho administrativo da empresa
o URGENT/EMERGENCY -existe o CAB/EC que é o conselho para
aprovação de mudanças urgentes.
• Processo de Mudança
o Registro, Aceite, Priorização.
o Categorização, Autorização, Desenvolvimento, Teste, Agendamento
o Implementação e Back out (retroceder)
 o Revisão e Fechamento
• Um plano de backout (retrocesso) deve existir sempre que possível
• O processo termina com a revisão da mudança
RELEASE MANAGEMENT

• Objetivos:
o Guardar com segurança todos os softwares e itens relacionados.
o Garantir que apenas softwares e hardware testados e aprovados estejam
em uso.
• Tarefas:
o Definir políticas de liberações
o Controlar a Biblioteca de Software Definitiva (DSL)
o Controlar a Depósito de Hardware Definitivo (DHL)
o Distribuir softwares e items associados (CIs)
o Gerenciar as liberações de softwares
o Acompanhar a liberação dos softwares
• É um processo dependente do Change Management e do Configuration
Management.
• É responsável pelo Roll out da mudança na infra-estrutura
• DSL (Definitive Software Library) é onde são armazenadas todas as cópias físicas
de softwares autorizados.
• DHS (Definitive Hardware Store) é uma área para armazenar componentes de
hardwares, uma espécie de estoque de peças de TI.
• Definições de Release:
o Release: é uma coleção de mudanças autorizadas
o Release Unit: é uma porção da infra-estrutura de TI que normalmente é
liberada junto.
o Roll-out: entrega, instalação de novas mudanças ou novos CIs pela
organização.
• Tipos de Releases:
o Delta: release parcial de CI’s que têm mudado ou são novos desde o último
release. É um release não muito confiável porque não foi testado com todos
os componentes juntos.
o Package: releases individuais de unidades FULL, DELTA ou ambos sendo
agrupados em forma de um pacote.
o Full: possui todos os componentes do release. É um release mais confiável
pois todos os componentes foram testados juntos.
SERVICE LEVEL MANAGEMENT

• Balancear a Demanda dos Serviços de TI e o Fornecimento dos Serviços de TI

conhecendo os requisitos de negócio e capacidades da TI.
• Objetivos:
o Manter um relacionamento entre cliente fornecedor
o Melhorar a especificação e entendimento dos requisitos do serviço
o Balancear a demanda do cliente e o custo da provisão do serviço
o Mensurar os níveis de serviços
o Buscar melhoria na qualidade
• Service Catalog – é uma lista de serviços oferecidos pela TI
• Service Level Requirements – são as necessidades dos clientes em relação ao
serviço de TI
• Service Level Agreement é um acordo entre TI / CLIENTE não é um documento
técnico, também não é um contrato.
• Operation Level Agreement é um acordo entre TI e a sua equipe interna, pode ser
usado linguagem técnica
• Underpinning Contract é um contrato realizado com prestadores de serviço 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 informação e controlar os custos da entrega de serviços de TI que
suportam a necessidades de negócio dos clientes.

Atividades Principais de Finanças de TI

• Principais custos de TI:

o Transferência
o Hardware
o Softwares
o Pessoas – Staff
o Serviços de Terceiros
o Prédios (Acomodação)
• Tipos de custos:
o Fixo: não é afetado pela quantidade de uso
o Variável: é afetado pela quantidade de uso
o Direto: custos que podem ser alocados unicamente a um produto, serviço
ou centro de custo. Exemplo: Pessoas, Contratos
o Indireto ou OVERHEAD: ão pode ser alocado direitamente a um produto,
serviço ou centro de custo. É um custo Overhead que deve ser rateado.
o CAPITAL = são custos oriundo de compra de ativos físicos (computadores,
prédios)
o OPERATIONAL = custo operacional para rodar a TI (custos de pessoas)
• Um MODELO DE CUSTO precisa ser definido e acordado antes de realizar a
COBRANÇA (CHARGE). Modelo de custo é forma que vai ser distribuído os
custos.
• Tipos de Precificação:
o At Cost
o Cost Plus
o Going Rate
o Market Rate
o Fixed Price
• Formas de Cobrança:
o No Charging (sem cobrança) : a TI é tratada como um centro de suporte.
o Notional Charging: a TI é tratada como um centro de Custo
o Actual Charging
CAPACITY MANAGEMENT

• Objetivos:
o Determinar a capacidade dos recursos de TI de forma correta e com custos
justificáveis para atender os níveis acordados com os clientes.
• Processo que ajuda a predizer os investimentos necessários em TI
• Possui 3 sub-processos:
o Business Capacity Management –requisitos futuros do negócio
o Resource Capacity Management – recursos necessários para os
serviços
o Demand Management - controlar o uso dos serviços de TI através de
Differential Charging (cobrança diferencial, cobrar o excedente)
• Modelling – para estimar a carga de trabalho
o Analise de Tendência (trends)
o Modelagem Analítica (Analytical)
o Modelagem por simulação
o Modelagem por baseline
• Application Sizing: dimensionamento para implementar uma nova aplicação
• CDB (Capacity Data Base) - contém métricas para criar o plano de
capacidade.

AVAILABILITY MANAGEMENT

• Objetivos:
o Predizer, planejar e gerenciar a disponibilidade dos serviços de TI
assegurando que:
 Todos os serviços estão apoiados em CIs confiáveis, e mantidos de
forma apropriada.
 Onde os CIs não forem mantidos internamente deverá procurar a
contratação de terceiros.
  Mudanças são propostas para prevenir a perda futura da
disponibilidade dos serviços.
o A TI esteja certa da disponibilidade dos serviços acordados em SLAs com
os clientes.
• Disponibilidade dos serviços de TI, busca satisfazer as necessidades dos usuários,
atender os acordos de SLAs estabelecidos.
• Aspectos da Disponibilidade:
o Reliability
o Mantainability: é a manutenção feita pela equipe interna de TI.
o Resilence: redundância.
o Serviceability: manutenção feita por terceiros.
• Single Points of Failure (SPOF): identifica através de mapas quais componentes
estão influenciando na disponibilidade do serviço.
• Este processo também se preocupa com os planos de recuperação dos serviços.
• Considerações sobre a Segurança dos Serviços
o Confidencialidade (Confidenciality)
o Integridade (Integrity)
o Disponibilidade (Availability)
• Principais métodos 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

Cálculo da Indisponibilidade

Um serviço não está disponível para o cliente se as funções que o cliente requisitar não
estiverem em funcionamento normal.
MTBF Tempo médio entre as falhas (Uptime)
MTTR Tempo médio para reparar (Downtime)
MTBSI Tempo médio entre Incidentes (MTTR + MTBF)

IT SERVICE CONTINUITY MANAGEMENT

• Por que fazer planejamento de contingência?

o Aumento da dependência dos negócios sobre a TI.
o Reduz o tempo e custo para fazer a recuperação quando acontecer o
desastre.
o Sobrevivência
o Evitar imagem negativa perante os clientes e mercado.
• Busca a redução da vulnerabilidade dos serviços de TI
• Utiliza a Análise de RISCO. Baseado no CCTA (Computer Risk Analysis and
Management Methodology (CRAMM)).
• Contra-medidas – Opções de Recovery
o Fazer nada
o Backup Manual
o Arranjos Recíprocos (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.