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 MTTR MTBSI

Tempo mdio entre as falhas (Uptime) Tempo mdio para reparar (Downtime) 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.