KIT PREPARATÓRIO ITIL FOUNDATIONAPOSTILA 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 QualidadePara 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 Pacienteo Comunicativoo Amigoo Entusiasmadoo Assertivo

o Empático o Honesto

Tipos de Deskso 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 Problemaso Controle de Erros (inclui abertura de uma RFC para eliminar o erro)o Prevenção proativao Identificar tendências nos incidenteso Informações Gerenciaiso 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 raizo 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

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

Tarefaso Identificação o Informações Gerenciaiso Verificaçãoo Controleo 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 IDo Tipoo Nomeo Custoo Local

Principais tipos de Relacionamentos entre CIso Componente deo Filho de o Cópia deo 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çaso Gerenciar o Processo de Mudanças (não executa o desenvolvimento)o Presidir as reuniões do CAB (Conselho)o Revisão e Fechamentoo 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 aprovaro SIGNIFICANT – necessita da aprovação do CABo MAJOR – necessita aprovação do conselho administrativo da empresao 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çõeso 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 softwareso 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 fornecedoro Melhorar a especificação e entendimento dos requisitos do serviçoo Balancear a demanda do cliente e o custo da provisão do serviçoo Mensurar os níveis de serviçoso 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ênciao Hardwareo Softwareso Pessoas – Staffo Serviços de Terceiroso Prédios (Acomodação)

Tipos de custos: o Fixo: não é afetado pela quantidade de usoo Variável: é afetado pela quantidade de usoo Direto: custos que podem ser alocados unicamente a um produto, serviço

ou centro de custo. Exemplo: Pessoas, Contratoso 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 Costo Cost Pluso Going Rateo Market Rateo 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ócioo Resource Capacity Management – recursos necessários para os

serviçoso 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çãoo 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 Reliabilityo 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ênciao 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 nadao Backup Manual o Arranjos Recíprocos (acordos entre duas empresas)o Cold Gradual Recovery > 72 ho Warm Intermediate Recovery > 24 a 72 ho Hot Immediate Recovery - 0 a 8 h

Os planos de recovery devem ser testados regularmente para garantir maior confiabilidade.