KIT PREPARATÓRIO ITIL FOUNDATION
APOSTILA RESUMO - REVISÃO DOS PONTOS CHAVES


O objetivo deste material é revisar e memor...
•   Os processos da ITIL buscam a eficiência e eficácia, e as duas palavras têm
       sentido diferentes. Eficiência: mel...
RELACIONAMENTO ENTRE OS PROCESSOS

Configuration Management
   • Gera informações para o Financial Management for IT para ...
o Assertivo
           o Empático
           o Honesto
   • Tipos de Desks
           o Call Center: para atender um grand...
•   Urgência = tempo necessário para resolver o incidente.




 •   Escalonamento poderá ser de duas formas:
 •   Funciona...
o Problem Control: identificar a causa raiz
           o Error Control: acompanhar a erradicação do erro
   •   Poderá ser...
Lembre: um erro para ser erradicado da infra-estrutura precisa passar por uma mudança.


CONFIGURATION MANAGEMENT




   •...
o Relaciona com
         o Usado por
 •   O CMDB não é um software de Inventário (asset management), o diferencia é que
  ...
RELEASE MANAGEMENT




 •   Objetivos:
         o Guardar com segurança todos os softwares e itens relacionados.
         ...
o   Full: possui todos os componentes do release. É um release mais confiável
    pois todos os componentes foram testados...
SERVICE LEVEL MANAGEMENT

   •   Balancear a Demanda dos Serviços de TI e o Fornecimento dos Serviços de TI
       conhece...
FINANCIAL MANAGEMENT FOR IT SERVICES

   •   Objetivos:
          o Fornecer informação e controlar os custos da entrega d...
o   Actual Charging
CAPACITY MANAGEMENT




  •   Objetivos:
         o Determinar a capacidade dos recursos de TI de forma correta e com cust...
o    A TI esteja certa da disponibilidade dos serviços acordados em SLAs com
               os clientes.
   •   Disponibil...
Fault Tree Analysis




Cálculo da Indisponibilidade




Um serviço não está disponível para o cliente se as funções que o...
MTBF              Tempo médio entre as falhas (Uptime)
MTTR              Tempo médio para reparar (Downtime)
MTBSI        ...
Upcoming SlideShare
Loading in …5
×

Resumo ITIL FOUNDATION Ingles

1,588 views

Published on

Resumo ITIL FOUNDATION (Termos em Ingles)

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,588
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
60
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Resumo ITIL FOUNDATION Ingles

  1. 1. 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.
  2. 2. • 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),
  3. 3. 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
  4. 4. 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.
  5. 5. • 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:
  6. 6. 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)
  7. 7. 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
  8. 8. 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
  9. 9. 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.
  10. 10. o Full: possui todos os componentes do release. É um release mais confiável pois todos os componentes foram testados juntos.
  11. 11. 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.
  12. 12. 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
  13. 13. o Actual Charging
  14. 14. 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.
  15. 15. 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
  16. 16. 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.
  17. 17. 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.

×