Itil v3 operação de serviço

  • 3,389 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,389
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
178
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. ITIL Versão 3Operação de ServiçoITIL V3 - Operação de Serviço - Página: 1 de 423
  • 2. O Core ITIL é composto por cinco publicações. Cada umadelas fornece a orientação necessária para umaabordagem integrada, tal como exigido pela ISO / IEC20000 padrão especificação:• Estratégia de Serviço• Design de Serviços• Transição de Serviço• Operação de Serviço• Melhoria de Serviço Continuada.ITIL V3 - Operação de Serviço - Página: 2 de 423
  • 3. I N D I C EPrefácio .............................................................................................................12Prefácio da OGC........................................................................................................... 12Prefácio Arquiteto Chefe............................................................................................... 13Prefaciar............................................................................................................14Informações de contato ................................................................................................ 14Agradecimentos.................................................................................................15Arquiteto-chefe e autores ............................................................................................. 15ITIL autoria da equipe................................................................................................... 15Mentores ....................................................................................................................... 15Outras contribuições..................................................................................................... 15O ITIL Grupo Consultivo..................................................................................................16Revisores.........................................................................................................................161 Introdução ......................................................................................................171.1 Visão Geral ............................................................................................................. 181,2 Contexto.................................................................................................................. 191.2.1 Gestão de Serviços ................................................................................................191.2.2 Boas práticas no domínio público...........................................................................191.2.3 ITIL e boas práticas em Gestão de Serviços ..........................................................211.2.3.1 Estratégia de Serviço.................................................................................................. 231.2.3.2 Design de Serviços..................................................................................................... 231.2.3.3 Transição de Serviço .................................................................................................. 241.2.3.4 Operação de Serviço .................................................................................................. 241.2.3.5 Melhoria de Serviço Continuada.................................................................................. 241,3 Propósito................................................................................................................. 261,4 Uso.......................................................................................................................... 261,5 Visão geral do capítulo ........................................................................................... 272 Gerenciamento de Serviço como uma prática ................................................282.1 O que é Gerenciamento de Serviços?................................................................... 282.2 O que são serviços?............................................................................................... 302.2.1 O valor proposição..................................................................................................302.3 Funções e processos em todo o ciclo de vida....................................................... 312.3.1 Funções..................................................................................................................312.3.2 Processos...............................................................................................................312.3.3 Especialização e coordenação em todo o ciclo de vida..........................................322.4 Operação fundamentos Serviço............................................................................. 332.4.1 Finalidade objetivo / / objetivo.................................................................................332.4.2 Âmbito ....................................................................................................................332.4.3 Valor para os negócios...........................................................................................342.4.4 Otimização do desempenho do Serviço de Operação............................................352.4.5 Processos dentro de Operação de Serviço ............................................................352.4.5.1 Gestão de Eventos ..................................................................................................... 352.4.5.2 Incidentes e Gestão de Problemas.............................................................................. 352.4.5.3 Cumprimento de Requisição ....................................................................................... 362.4.5.4 Gerenciamento de Acesso .......................................................................................... 362.4.6 Funções dentro de Operação de Serviço ...............................................................362.4.6.1 Service Desk............................................................................................................... 372.4.6.2 Gestão Técnica........................................................................................................... 372.4.6.3 Gestão de Operações de TI ........................................................................................ 372.4.6.4 Gerenciamento de Aplicativos..................................................................................... 372.4.6.5 Interfaces para outros estágios Serviço Lifecycle Management ................................... 38ITIL V3 - Operação de Serviço - Página: 3 de 423
  • 4. 3 Operação princípios do serviço ......................................................................393,1 Funções, grupos, equipes, departamentos e divisões .......................................... 40Alcançar 3,2 equilíbrio na Operação de Serviço.......................................................... 423.2.1 TI interna ver contra vista de negócios externo ......................................................423.2.2 Estabilidade em relação a capacidade de resposta................................................463.2.3 A qualidade do serviço versus custo do serviço .....................................................493.2.4 reativa contra proativo ............................................................................................523,3 prestação de serviços............................................................................................. 573,4 a participação do pessoal de operação em Design de Serviços e Transição deServiço .......................................................................................................................... 583,5 Saúde Operacional................................................................................................. 593,6 Comunicação.......................................................................................................... 613.6.1 Reuniões.................................................................................................................623.6.1.1 A reunião de Operações ............................................................................................. 633.6.1.2 Departamento reuniões de grupo ou equipe................................................................ 643.6.1.3 reuniões com clientes ................................................................................................. 643,7 Documentação........................................................................................................ 664 Operação processos de serviço .....................................................................674.1 Gestão de Eventos ................................................................................................. 694.1.1 Finalidade objetivo / / objetivo.................................................................................694.1.2 Âmbito ....................................................................................................................694.1.3 Valor para os negócios...........................................................................................704.1.4 Políticas / princípios / conceitos básicos.................................................................714.1.5 as atividades de processo, métodos e técnicas......................................................734.1.5.1 Evento ocorre ............................................................................................................. 744.1.5.2 Notificação de eventos................................................................................................ 744.1.5.3 Detecção de eventos .................................................................................................. 754.1.5.4 Evento filtragem.......................................................................................................... 754.1.5.5 Significado de eventos................................................................................................ 754.1.5.6 correlação de eventos................................................................................................. 774.1.5.7 Gatilho........................................................................................................................ 774.1.5.8 Resposta seleção ....................................................................................................... 784.1.5.9 Rever as acções ......................................................................................................... 814.1.5.10 evento Close............................................................................................................. 814.1.6 Triggers interfaces de entrada e saída / inter-processo..........................................824.1.7 Gestão da Informação ............................................................................................834.1.8 Métricas..................................................................................................................844.1.9 Desafios, Fatores Críticos de Sucesso e riscos......................................................854.1.9.1 Desafios ..................................................................................................................... 854.1.9.2 Fatores Críticos de Sucesso ....................................................................................... 854.1.9.3 Riscos......................................................................................................................... 864.1.10 Projeto de Gestão de Eventos..............................................................................864.1.10.1 Instrumentação ......................................................................................................... 864.1.10.2 mensagens de erro ................................................................................................... 874.1.10.3 de detecção de eventos e mecanismos de alerta....................................................... 874.1.10.4 Identificação de limiares............................................................................................ 884.2 Gestão de Incidentes.............................................................................................. 894.2.1 Finalidade objetivo / / objetivo.................................................................................894.2.2 Âmbito ....................................................................................................................894.2.3 Valor para os negócios...........................................................................................904.2.4 Políticas / princípios / conceitos básicos.................................................................904.2.4.1 Prazos ........................................................................................................................ 904.2.4.2 Modelos de Incidentes ................................................................................................ 904.2.4.3 grandes incidentes...................................................................................................... 914.2.5 As atividades de processo, métodos e técnicas.....................................................924.2.5.1 identificação de incidentes .......................................................................................... 934.2.5.2 registro de incidentes.................................................................................................. 94ITIL V3 - Operação de Serviço - Página: 4 de 423
  • 5. 4.2.5.3 categorização de incidentes........................................................................................ 954.2.5.4 priorização de Incidentes ............................................................................................ 974.2.5.5 O diagnóstico inicial .................................................................................................... 994.2.5.6 escalada de incidentes................................................................................................ 99Nota sobre alocação de Incidentes ..........................................................................................................1004.2.5.7 Investigação e Diagnóstico........................................................................................ 1004.2.5.8 Resolução e Recuperação ........................................................................................ 1014.2.5.9 Fechamento de Incidentes ........................................................................................ 102Regras para reabertura incidentes ................................................................................1034.2.6 Triggers interfaces de entrada e saída / inter-processo........................................1034.2.7 Gestão da Informação ..........................................................................................1044.2.8 Métricas................................................................................................................1054.2.9 Desafios, Fatores Críticos de Sucesso e riscos....................................................1064.2.9.1 Desafios ................................................................................................................... 1064.2.9.2 Fatores Críticos de Sucesso ..................................................................................... 1074.2.9.3 Riscos....................................................................................................................... 1074,3 Cumprimento de Requisição ................................................................................ 108Finalidade 4.3.1 meta / / objetivo...................................................................................1084.3.2 Âmbito ..................................................................................................................1084.3.3 Valor para os negócios.........................................................................................1094.3.4 Políticas / princípios / conceitos básicos...............................................................1094.3.4.1 Modelos Pedido........................................................................................................ 1094.3.5 as atividades de processo, métodos e técnicas....................................................1104.3.5.1 seleção do menu....................................................................................................... 1104.3.5.2 aprovação Financeiro................................................................................................ 1104.3.5.3 aprovação Outros ..................................................................................................... 1104.3.5.4 Cumprimento ............................................................................................................ 1114.3.5.5 Encerramento ........................................................................................................... 1114.3.6 Triggers interfaces de entrada e saída / inter-processo........................................1114.3.7 Gestão da Informação ..........................................................................................1124.3.8 Métricas................................................................................................................1124.3.9 Desafios, Fatores Críticos de Sucesso e riscos....................................................1124.3.9.1 Desafios ................................................................................................................... 1124.3.9.2 Fatores Críticos de Sucesso ..................................................................................... 1134.3.9.3 Riscos....................................................................................................................... 1134,4 Gerenciamento de Problemas.............................................................................. 1154.4.1 Finalidade objetivo / / objetivo...............................................................................1154.4.2 Âmbito ..................................................................................................................1154.4.3 Valor para os negócios.........................................................................................1154.4.4 Políticas / princípios / conceitos básicos...............................................................1164.4.4.1 Modelos de problemas.............................................................................................. 1164.4.5 as atividades de processo, métodos e técnicas....................................................1164.4.5.1 detecção de problemas............................................................................................. 1174.4.5.2 registro Problema...................................................................................................... 1184.4.5.3 Categorização Problema........................................................................................... 1194.4.5.4 Priorização de Problemas ......................................................................................... 1194.4.5.5 Investigação e Diagnóstico de Problemas ................................................................. 1194.4.5.6 Soluções Alternativas................................................................................................ 1234.4.5.7 Levantando um registro de Erro Conhecido............................................................... 1244.4.5.8 A resolução de problemas......................................................................................... 1244.4.5.9 Encerramento Problema ........................................................................................... 1254.4.5.10 Revisão grande problema ....................................................................................... 1254.4.5.11 Os erros detectados no ambiente de desenvolvimento............................................ 1264.4.6 Triggers interfaces de entrada e saída / inter-processo........................................1264.4.7 Gestão da Informação ..........................................................................................1284.4.7.1 CMS ......................................................................................................................... 1284.4.7.2 Banco de Dados Erro Conhecido .............................................................................. 1284.4.8 Métricas................................................................................................................1304.4.9 Desafios, Fatores Críticos de Sucesso e riscos....................................................131ITIL V3 - Operação de Serviço - Página: 5 de 423
  • 6. 4,5 Gerenciamento de Acesso ................................................................................... 1324.5.1 Finalidade objetivo / / objetivo...............................................................................1324.5.2 Âmbito ..................................................................................................................1324.5.3 Valor para os negócios.........................................................................................1324.5.4 Políticas / princípios / conceitos básicos...............................................................1334.5.5 as atividades de processo, métodos e técnicas....................................................1334.5.5.1 Solicitação de acesso ............................................................................................... 1334.5.5.2 Verificação................................................................................................................ 1344.5.5.3 Prever direitos........................................................................................................... 1344.5.5.4 status de identidade de Monitoramento..................................................................... 1364.5.5.5 acesso acompanhamento e rastreamento................................................................. 1364.5.5.6 Remoção ou restritiva de direitos .............................................................................. 1374.5.6 Triggers interfaces de entrada e saída / inter-processo........................................1384.5.7 Gestão da Informação ..........................................................................................1394.5.7.1 Identidade................................................................................................................. 1394.5.7.2 Os usuários, grupos, funções e grupos de serviço..................................................... 1404.5.8 Métricas................................................................................................................1414.5.9 Desafios, Fatores Críticos de Sucesso e riscos....................................................1414,6 As atividades operacionais de processos cobertos de fases do ciclo de vida deoutros .......................................................................................................................... 1434.6.1 Gestão da Mudança .............................................................................................1434.6.2 Gerenciamento da Configuração..........................................................................1434.6.3 Gerenciamento de Liberação e Implantação ........................................................1444.6.4 Gerenciamento da Capacidade ............................................................................1444.6.4.1 Capacidade e Performance Monitoring...................................................................... 1454.6.4.2 capacidade ou manipulação desempenho incidentes relacionados............................ 1464.6.4.3 Capacidade e tendências de desempenho................................................................ 1474.6.4.4 Armazenamento de dados de gerenciamento de capacidade .................................... 1474.6.4.5 Gerenciamento da Demanda .................................................................................... 1484.6.4.6 Workload Management ............................................................................................. 1484.6.4.7 Modelação e aplicações de dimensionamento........................................................... 1494.6.4.8 Planejamento de Capacidade ................................................................................... 1494.6.5 Gerenciamento de Disponibilidade.......................................................................1504.6.6 Gestão do Conhecimento .....................................................................................1514.6.7 Gerenciamento Financeiro para Serviços de TI....................................................1524.6.8 Gestão da Continuidade de Serviço de TI............................................................1525 atividades operação comum Serviço ............................................................ 1545,1 Monitoramento e controle..................................................................................... 1575.1.1 Definições.............................................................................................................1575.1.2 Controle Loops monitor ........................................................................................1585.1.2.1 malha de controle Complexo do Monitor.................................................................... 1605.1.2.2 O ITSM Monitor de Controle de Loop ........................................................................ 1625.1.2.3 definir o que precisa ser monitorado.......................................................................... 1655.1.2.4 Monitoramento Interno e Externo e Controle ............................................................. 1655.1.2.5 Definir objectivos para monitoramento e controle ...................................................... 1665.1.2.6 Tipos de monitoramento............................................................................................ 1685.1.2.7 Monitoramento em ambientes de teste...................................................................... 1715.1.2.8 Relatórios e ação...................................................................................................... 1715.1.2.9 auditorias Operação de Serviço ................................................................................ 1725.1.2.10 Medição, métricas e KPIs........................................................................................ 172Medição.....................................................................................................................................................173Métrica ......................................................................................................................................................173Indicadores Chave de Desempenho ........................................................................................................1735.1.2.11 Interfaces para práticas de outros serviços do Ciclo de Vida.................................... 174Monitoramento Operacional e Melhoria de Serviço Continuada....................................1745,2 Operações de TI ................................................................................................... 1765.2.1 Management Console / Ponte de Operações.......................................................176ITIL V3 - Operação de Serviço - Página: 6 de 423
  • 7. 5.2.2 Job Scheduling .....................................................................................................1775.2.3 Backup e Restauração .........................................................................................1785.2.3.1 backup...................................................................................................................... 1795.2.3.2 Restaurar.................................................................................................................. 1815.2.4 impressão e de saída ...........................................................................................1815.3 Gestão Mainframe ................................................................................................ 1835,4 Management Server e suporte............................................................................. 1845,5 Gerenciamento de Rede ...................................................................................... 1865,6 Armazenamento e Arquivo................................................................................... 1885,7 Database Administration ...................................................................................... 1905,8 Diretório de Gestão de Serviços .......................................................................... 1925,9 Desktop Support................................................................................................... 1935,10 Middleware Gestão............................................................................................. 1945,11 Gestor da Internet / Web .................................................................................... 1965,12 Instalações e Data Management Centre............................................................ 1975.12.1 Dados estratégias Centro...................................................................................1985,13 Gestão de Segurança da Informação e Operação de Serviço.......................... 2005.13.1 Policiamento e relatórios.....................................................................................2005.13.2 Assistência técnica .............................................................................................2015.13.3 controle de segurança operacional.....................................................................2015.13.4 Seleção e habilitação..........................................................................................2015.13.5 Treinamento e conscientização ..........................................................................2025.13.6 políticas e procedimentos documentados...........................................................2025,14 Melhoria das actividades operacionais .............................................................. 2035.14.1 automação de tarefas manuais...........................................................................2035.14.2 Rever atividades improvisadas ou procedimentos..............................................2035.14.3 Auditorias Operacionais......................................................................................2035.14.4 Usando o Gerenciamento de Incidentes e de Problemas...................................2035.14.5 Comunicação......................................................................................................2035.14.6 A educação ea formação....................................................................................2046 Organizador para Operação de Serviço ....................................................... 2056.1 Funções ................................................................................................................ 2056.1.1 Funções e atividades............................................................................................2076,2 Service Desk......................................................................................................... 2106.2.1 Justificação e do papel do Service Desk ..............................................................2106.2.2 Posto de objectivos de serviço .............................................................................2116.2.3 estrutura organizacional Service Desk .................................................................2126.2.3.1 Posto de Serviço Local.............................................................................................. 2126.2.3.2 Service Desk centralizado......................................................................................... 2136.2.3.3 Service Desk Virtual.................................................................................................. 2146.2.3.4 Siga o Sol ................................................................................................................. 2156.2.3.5 grupos Posto de serviço especializado...................................................................... 2166.2.3.6 Ambiente .................................................................................................................. 2166.2.3.7 Nota sobre a construção de um único ponto de contato............................................. 2176.2.4 pessoal Service Desk ...........................................................................................2176.2.4.1 Os níveis de pessoal................................................................................................. 2176.2.4.2 Os níveis de especialização...................................................................................... 2196.2.4.3 Formação ................................................................................................................. 2216.2.4.4 retenção de pessoal.................................................................................................. 2226.2.4.5 Superusuários........................................................................................................... 2236.2.5 Posto de métricas de serviço................................................................................2246.2.5.1 cliente / usuário pesquisas de satisfação................................................................... 2266.2.6 A terceirização do Service Desk...........................................................................2286.2.6.1 As ferramentas comuns e processos......................................................................... 2296.2.6.2 metas de SLA ........................................................................................................... 2306.2.6.3 A boa comunicação................................................................................................... 230ITIL V3 - Operação de Serviço - Página: 7 de 423
  • 8. 6.2.6.4 Propriedade dos dados ............................................................................................. 2316.3 Gestão Técnica..................................................................................................... 2326.3.1 papel de Gestão Técnica......................................................................................2326.3.2 Técnicas objectivos de gestão..............................................................................2336.3.3 genéricos técnicos actividades de gestão ............................................................2336.3.4 organização Gestão Técnica................................................................................2366.3.5 Manutenção Design e Técnico de Apoio Técnico e..............................................2376.3.6 Técnicas de Gestão de métricas ..........................................................................2376.3.7 documentação Gestão Técnica ............................................................................2396.3.7.1 A documentação técnica........................................................................................... 2396.3.7.2 programações de manutenção.................................................................................. 2396.3.7.3 Inventário de Habilidades.......................................................................................... 2396,4 TI Gestão de Operações ...................................................................................... 2416.4.1 Funções de Gerenciamento de Operações de TI.................................................2416.4.2 Operações de TI objectivos de gestão .................................................................2436.4.3 Operações de TI Gestão de organização.............................................................2436.4.4 Operações de TI métricas de gestão....................................................................2446.4.5 Operações de TI Gestão de documentação .........................................................2456.4.5.1 Procedimentos Operacionais Padrão ........................................................................ 2456.4.5.2 Operações Logs........................................................................................................ 2456.4.5.3 Shift Schedules e Relatórios ..................................................................................... 2466.4.5.4 Horário de Operações............................................................................................... 2476,5 Gerenciamento de Aplicativos.............................................................................. 2476.5.1 papel Gerenciamento de Aplicativos ....................................................................2476.5.2 Aplicação objectivos de gestão.............................................................................2486.5.3 Gestão de princípios de aplicação........................................................................2496.5.3.1 Construir ou comprar? .............................................................................................. 2496.5.3.2 Modelos Operacionais .............................................................................................. 2506.5.4 Aplicação de Gestão do Ciclo de Vida..................................................................2506.5.4.1 Requisitos................................................................................................................. 2526.5.4.2 Desenho................................................................................................................... 2536.5.4.3 Construção ............................................................................................................... 2546.5.4.4 Implantar .................................................................................................................. 2546.5.4.5 Operar ...................................................................................................................... 2556.5.4.6 Otimizar.................................................................................................................... 2556.5.5 Aplicação de Gestão de actividades de carácter genérico ...................................2566.5.6 Aplicação de Gestão de organização ...................................................................2596.5.6.1 papéis organizacionais.............................................................................................. 2616.5.7 Aplicação funções de gerenciamento e responsabilidades ..................................2636.5.7.1 Aplicações Gerentes / ou chefes de equipa............................................................... 2636.5.7.2 Aplicações Analista / Arquiteto .................................................................................. 2646.5.8 Gestão de métricas de aplicação..........................................................................2656.5.9 documentação Gerenciamento de Aplicativos......................................................2666.5.9.1 Application Portfolio .................................................................................................. 2666.5.9.2 Requisitos da Aplicação............................................................................................ 2676.5.9.3 mudanças de uso e Casos........................................................................................ 2686.5.9.4 documentação de projeto.......................................................................................... 2696.5.9.5 Manuais.................................................................................................................... 2706,6 Serviço de Operação papéis e responsabilidades............................................... 2716.6.1 Posto de Serviço papéis.......................................................................................2716.6.1.1 Service Desk Manager.............................................................................................. 2716.6.1.2 Supervisor de Service Desk ...................................................................................... 2716.6.1.3 Posto de Serviço Analistas........................................................................................ 2726.6.1.4 Superusuários........................................................................................................... 2726.6.2 Técnicas funções de gerenciamento ....................................................................2726.6.2.1 Os gerentes técnicos / ou chefes de equipa .............................................................. 2726.6.2.2 Os analistas técnicos / Arquitetos.............................................................................. 2736.6.2.3 Operador Técnico ..................................................................................................... 2746.6.3 Operações de TI funções de gerenciamento........................................................274ITIL V3 - Operação de Serviço - Página: 8 de 423
  • 9. 6.6.3.1 TI Gerente de Operações.......................................................................................... 2746.6.3.2 Líderes Turno ........................................................................................................... 2756.6.3.3 Operações de TI Analistas ........................................................................................ 2756.6.3.4 Operadores de TI...................................................................................................... 2756.6.4 Gestão funções de aplicativo................................................................................2766.6.4.1 Aplicações Gerentes / ou chefes de equipa............................................................... 2766.6.4.2 Aplicações Analista / Arquiteto .................................................................................. 2766.6.5 Gestão de papéis de Eventos...............................................................................2776.6.5.1 O papel do Service Desk........................................................................................... 2776.6.5.2 O papel do Técnico e Gerenciamento de Aplicativos................................................. 2786.6.5.3 O papel da TI Gestão de Operações......................................................................... 2786.6.6 Gestão de Incidentes papéis ................................................................................2786.6.6.1 Gerente de Incidentes............................................................................................... 2786.6.6.2 Primeira linha............................................................................................................ 2796.6.6.3 de segunda linha....................................................................................................... 2796.6.6.4 Terceira linha............................................................................................................ 2796.6.7 A realização de papéis Pedido .............................................................................2806.6.8 Problema funções de gerenciamento ...................................................................2806.6.8.1 Gestor Problema....................................................................................................... 2806.6.8.2 resolução de problemas Grupos................................................................................ 2816.6.9 Acesso funções de gerenciamento.......................................................................2816.6.9.1 O papel do Service Desk........................................................................................... 2826.6.9.2 O papel do Técnico e Gerenciamento de Aplicativos................................................. 2826.6.9.3 O papel da TI Gestão de Operações......................................................................... 2836,7 Serviço Organização Estruturas de Operação .................................................... 2846.7.1 Organização pela especialização técnica.............................................................2846.7.2 Organização pela atividade ..................................................................................2866.7.3 Organização para gerenciar processos................................................................2886.7.4 Organização de Operações de TI por geografia...................................................2896.7.5 híbridos estruturas de organização.......................................................................2926.7.5.1 Funções combinadas................................................................................................ 2936.7.5.2 Aplicação de Organização e Gestão Técnica ............................................................ 2956.7.5.3 Geografia.................................................................................................................. 2956.7.5.4 Técnica Combinada e estrutura de Gerenciamento de Aplicativos............................. 2967 considerações de tecnologia ........................................................................ 2987,1 requisitos genéricos.............................................................................................. 2997.1.1 Auto-Ajuda............................................................................................................2997.1.2 Fluxo de Trabalho ou processo motor ..................................................................2997.1.3 Integrado CMS......................................................................................................2997.1.4 Descoberta de Implantação / / licenciamento de tecnologia.................................2997.1.5 O controle remoto.................................................................................................3007.1.6 utilitários de diagnóstico .......................................................................................3007.1.7 Relatórios..............................................................................................................3007.1.8 Dashboards ..........................................................................................................3017.1.9 Integração com o Business Service Management................................................3017.2 Gestão de Eventos ............................................................................................... 3027,3 Gerenciamento de Incidentes............................................................................... 3037.3.1 Integrado ITSM tecnologia....................................................................................3037.3.2 Fluxo de Trabalho e escalonamento automatizado ..............................................3037,4 cumprimento Pedido............................................................................................. 3047,5 Gerenciamento de Problemas.............................................................................. 3057.5.1 Integrated Service Management Technology .......................................................3057.5.2 Gestão da Mudança .............................................................................................3057.5.3 Integrado CMS......................................................................................................3057.5.4 Banco de Dados Erro Conhecido .........................................................................3057,6 Gerenciamento de Acesso ................................................................................... 3077,7 Service Desk......................................................................................................... 308ITIL V3 - Operação de Serviço - Página: 9 de 423
  • 10. 7.7.1 Telefonia...............................................................................................................3087.7.2 Ferramentas de suporte .......................................................................................3087.7.2.1 Banco de Dados Erro Conhecido .............................................................................. 3097.7.2.2 os scripts de diagnóstico........................................................................................... 3097.7.2.3 interface web de Auto-Ajuda ..................................................................................... 3097.7.2.4 O controle remoto ..................................................................................................... 3107.7.3 Planejamento da Continuidade dos Serviços de TI para ferramentas de suporteITSM..............................................................................................................................3118 considerações sobre a aplicação.................................................................. 3128,1 mudança de gestão, em Operação de Serviço.................................................... 3138.1.1 Mudança desencadeia..........................................................................................3138.1.2 Avaliação de Mudança .........................................................................................3138.1.3 Medição de mudança bem sucedida ....................................................................3148.2 Operação de Serviços e Gerenciamento de Projetos ......................................... 3158,3 Avaliação de risco e gestão na Operação de Serviço......................................... 3168,4 pessoal operacional em Design de Serviços e Transição................................... 3178,5 Planejamento e implementação de tecnologias de gerenciamento de serviços 3188.5.1 As licenças............................................................................................................3188.5.1.1 licenças dedicados.................................................................................................... 3188.5.1.2 licenças partilhadas................................................................................................... 3188.5.1.3 licenças Web ............................................................................................................ 3188.5.1.4 Serviço sob demanda ............................................................................................... 3198.5.2 Implantação ..........................................................................................................3208.5.3 verifica a capacidade............................................................................................3208.5.4 O tempo de implantação de tecnologia ................................................................3208.5.5 Tipo de introdução................................................................................................3219 Desafios, Fatores Críticos de Sucesso e riscos............................................ 3239,1 Desafios ................................................................................................................ 3239.1.1 A falta de compromisso com a equipe de desenvolvimento e projeto ..................3239.1.2 financiamento Justificando....................................................................................3249.1.3 Desafios para os Gestores operação de serviço ..................................................3249,2 Fatores Críticos de Sucesso ................................................................................ 3279.2.1 Gestão de apoio ...................................................................................................3279.2.2 O apoio às empresas............................................................................................3289.2.3 Campeões ............................................................................................................3289.2.4 Recrutamento e retenção .....................................................................................3299.2.5 formação em Gestão de Serviços.........................................................................3299.2.6 Ferramentas adequadas.......................................................................................3309.2.7 Validade dos testes ..............................................................................................3309.2.8 Medição e comunicação.......................................................................................3319,3 Riscos ................................................................................................................... 3329.3.1 Serviço de perda...................................................................................................3329.3.2 Os riscos para a operação de serviço de sucesso ...............................................332Posfácio........................................................................................................... 334Apêndice A: orientações da indústria Complementar ...................................... 335A1 COBIT.................................................................................................................... 336A2 ISO / IEC 20000 .................................................................................................... 338A3 CMMI ..................................................................................................................... 339Balanced Scorecard A4.............................................................................................. 339A5 de Gestão da Qualidade ....................................................................................... 340A6 ITIL eo Quadro OSI............................................................................................... 340Apêndice B: Comunicação na Operação de Serviço ....................................... 342Comunicação B1 rotina operacional .......................................................................... 342Comunicação B2 entre os turnos ............................................................................... 345ITIL V3 - Operação de Serviço - Página: 10 de 423
  • 11. B3 Relato de Desempenho......................................................................................... 346IT Performance Serviço.................................................................................................346Equipe do Serviço de Operação ou desempenho departamento ..................................348Infra-estrutura ou o desempenho do processo..............................................................350B4 Comunicação em projetos .................................................................................... 352A comunicação relacionada com alterações B5........................................................ 354B6 comunicação relacionada com exceções............................................................. 356Comunicação B7 relação às emergências................................................................. 358B8 A comunicação com os usuários e clientes.......................................................... 360Anexo C: Kepner Tregoe e .............................................................................. 362C1 Definindo o problema...............................................................................................363C2 Descrevendo o problema .........................................................................................363C3 Estabelecer as possíveis causas .............................................................................363C4 Testando a causa mais provável..............................................................................364C5 Verificando a verdadeira causa................................................................................364Anexo D: Diagramas de Ishikawa.................................................................... 365Apêndice E: Descrição detalhada de Gestão de Instalações........................... 367E1 Gestão de Edifícios ............................................................................................... 368E2 Equipamentos de Hospedagem............................................................................ 369Gerenciamento de energia E3.................................................................................... 370E4 condicionamento ambiental e sistemas de alerta................................................. 372E5 Segurança ............................................................................................................. 374E6 Controle de Acesso Físico .................................................................................... 374E7 envio e recebimento.............................................................................................. 374E8 Envolvimento em Gestão de Contratos................................................................ 375Manutenção E9........................................................................................................... 376Anexo F: Controle de Acesso Físico................................................................ 377Glossário ......................................................................................................... 382Lista de siglas ............................................................................................................. 382Lista de definições ...................................................................................................... 386ITIL V3 - Operação de Serviço - Página: 11 de 423
  • 12. PrefácioPrefácio da OGCDesde a sua criação, ITIL cresceu e se tornou a abordagem mais aceita para ogerenciamento de serviços no mundo. No entanto, juntamente com este sucessovem a responsabilidade de assegurar que a orientação mantém o ritmo com umambiente de negócios em constante mudança global. Requisitos degerenciamento de serviços são inevitavelmente moldado pelo desenvolvimentode tecnologia, modelos de negócios revistos e as expectativas dos clientes cadavez maior. A nossa mais recente versão do ITIL foi criado em resposta a estesdesenvolvimentos.Esta é uma das cinco publicações principais que descrevem as práticas degerenciamento de serviços de TI que compõem a ITIL. Eles são o resultado deum projeto de dois anos para revisar e atualizar a orientação. O número deprofissionais de gerenciamento de serviços de todo o mundo que ajudaram adesenvolver o conteúdo dessas publicações é impressionante. Sua experiênciae conhecimentos que contribuíram para o conteúdo para trazer-lhe um conjuntoconsistente de alta qualidade orientação. Isto é apoiado pelo desenvolvimentocontínuo de um sistema de qualificação abrangente, juntamente com formaçãoacreditada e consultoria.Se você faz parte de uma empresa global, um departamento ou uma pequenaempresa, ITIL dá acesso a conhecimento de classe mundial de gestão deserviços. Essencialmente, ele coloca os serviços de TI onde eles pertencem - nocentro de operações de negócios de sucesso.Peter FanningAtuando ExecutivoOffice of Government CommerceITIL V3 - Operação de Serviço - Página: 12 de 423
  • 13. Prefácio Arquiteto ChefeITIL Service orientação Prática de Gestão está estruturado em torno do Ciclo deVida do Serviço. Comum em todo o ciclo de vida é a prática geral em si, que sebaseia em processos, funções, atividades, modelos organizacionais e demedição, que, juntos, permitem IT Service Management (ITSM) para integrarcom os processos de negócio, fornecer valor mensurável e evoluir a indústria deITSM em frente na nossa busca da excelência no atendimento.Em nenhum outro lugar do ITIL Service Lifecycle faz o efeito de como atuarcomo prestadores de serviços tocar os clientes intimamente como operações deserviços. Este é o lugar onde a estratégia, design, transição e melhorias sãoentregues e apoiada em uma base dia-a-dia.A publicação traz Operação de Serviço Gerenciamento de Serviços de vida parao negócio, e a prestação de contas para a execução dos serviços, as pessoasque os criam e da tecnologia que permite que eles são monitorados, controladose entregue nesta fase do Ciclo de Vida do Serviço.Esta publicação vai ajudar a orientar-nos a todos para alcançar a excelência doserviço e ver o valor de ITSM em uma ampla visão de negócios com foco dela.Se você é novo para a prática de ITIL ou um profissional experiente, aorientação nesta publicação irá expandir sua visão e conhecimento de como sero provedor de serviços de best-of-breed, através da implementação deOperação de Serviço.Há um ditado que diz que a aprendizagem é 20/20. A orientação na Operaçãode Serviço é destilado de mais de 20 anos de experiência em ITSM porespecialistas mundiais, empresários e profissionais de ITSM e as liçõesaprendidas por eles sobre o serviço de excelência realmente é e como alcançá-lo.Qualquer pessoa envolvida em serviços de operação irá beneficiar da orientaçãonas páginas seguintes desta publicação. Operação de Serviço oferece o melhoraconselhamento e orientação de todo o mundo e um caminho para o que épossível em seu futuro.Sharon TaylorArquiteto Chefe, Práticas ITIL Service ManagementITIL V3 - Operação de Serviço - Página: 13 de 423
  • 14. PrefaciarEsta publicação abrange e supera os aspectos operacionais do ITIL ServiceSupport e Service Delivery publicações e também cobre a maior parte do escopode Gestão TIC infra-estrutura. Ele também incorpora aspectos operacionais doplanejamento para implementar, gerenciamento de aplicações, gerenciamentode ativos de software e publicações de Gestão de Segurança.Os princípios básicos de boas práticas de serviços de TI de gestão enquadradano âmbito de versões anteriores do ITIL permanecem inalteradas. O sensocomum permanece o bom senso!No entanto, as tecnologias, ferramentas e relações mudaram significativamente,mesmo em período de tempo relativamente curto desde a última versão do ITILfoi concluída. Embora esta publicação re-usos e atualizações material relevantedas versões anteriores se for caso disso, também inclui muitos novos conceitose práticas da indústria para dar cobertura completa de melhores práticas deorientação para a Operação de hoje serviço em um único volume, para osnegócios de hoje e ambiente tecnológico .Informações de contatoTodos os detalhes sobre a gama de material publicado sob a bandeira ITILpodem ser encontradas em www.best-management-practice.com/itilSe você gostaria de nos informar de quaisquer alterações que possam sernecessárias para esta publicação por favor, registrá-los em www.best-management-practice.com/changelogPara mais informações sobre qualificação e acreditação da formação, visitewww.itil-officialsite.com. Alternativamente, favor contatar:APMG Service DeskEspada CasaTotteridge EstradaHigh WycombeBuckinghamshireHP13 6DGTel: +44 (0) 1494 452450E-mail: servicedesk@apmgroup.co.ukITIL V3 - Operação de Serviço - Página: 14 de 423
  • 15. AgradecimentosArquiteto-chefe e autoresSharon Taylor (Aspect Group Inc) Arquiteto ChefeDavid Cannon (HP) AutorDavid Wheeldon (HP) AutorITIL autoria da equipeO ITIL equipe de criação contribuiu para este guia através de comentários sobreo conteúdo e alinhamento em todo o conjunto. Então, graças também sãodevidos a outros autores do ITIL, especificamente Jeroen Bronkhorst (HP), GaryCase (Pink Elephant), Ashley Hanna (HP), Majid Iqbal (Carnegie MellonUniversity), Shirley Lacy (ConnectSphere), Vernon Lloyd (Fox IT ), IvorMacfarlane (Guillemot Rock), Michael Nieves (Accenture), Stuart Rance (HP),Colin Rudd (itens) e George Spalding (Pink Elephant).MentoresChristian Nissen e Paul WilkinsonOutras contribuiçõesUm número de pessoas contribuíram generosamente seu tempo e conhecimento para estapublicação operação de serviço. Jim Clinch, como OGC Gerente de Projeto, agradece o apoioprestado pela HP para a equipe de criação no desenvolvimento desta publicação e,particularmente, a contribuição de Peter Doherty e Stroud Robert, e para o apoio de JennyDugmore, Convenor do Grupo de Trabalho ISO / IEC 20000, Janine Eves, Carol Hulm, AidanLawes e Michiel van der Voort.Os autores também gostariam de agradecer a Stuart Rance e Ashley Hanna, da Hewlett-Packard, Christian F Nissen (Itilligence), Maria Jarra (Itilligence), Eu Jin Ho (UBS), JanBjerregaard, (Sun Microsystems), Jan Oberg (Oberg Parceiros ), Lars Zobbe Mortensen (ZobbeConsult & Zoftware), Mette Nielsen (Carlsberg TI), Michael Imhoff (IBM), Niels Berner (NovoNordisk), Nina Schertiger (HP), Signe-Marie Hernes Bjerke (DNV), Steen Sverker Nilsson(Westergaard CSM), Ulf Myrberg (Bita), Russell Jukes, Debbi Jancaitis, Sheldon Parmer, RamonAlanis, Tim Benson e Nenen Ong da Hewlett-Packard TI, Jaye Thompson, Dee Seymour,Andranik Ziyalyan, Young Chang, Lauren Abernethy, abril McCowan, Becky Wershbale, RobGarman, Scott McPherson, Sandra de panificação, Rick Streeter, Leon Gantt, Charlotte Devine,Greg Algorri, Maria Fischer, Bill Thayer e Diana Osberg da Empresa The Walt Disney Companyde TI, Dennis Deane e João Sowerby da DHL, Richard Fahey e Chris Hughes de Serviços deEntrega Global da HP Aplicação, Cindi Locker e Dhiraj Gupta da Companhia ProgressiveCasualty Insurance, Peter Doherty e Robert Stroud, da Computer Associates e Tillston Paulo daHewlett-Packard, Brian Jakubec, Vernon Blakes, Angela Chin, Colin Lovell , Ken Hamilton, RoseITIL V3 - Operação de Serviço - Página: 15 de 423
  • 16. Lariviere, Jenny McPhee, Tom Nielsen, Roc Paez, Lloyd Robinson, Paul Wilmot, Jeanette e KenSmith Wendle da Hewlett-Packard.A fim de desenvolver práticas de gestão ITIL Service para refletir as melhores práticas actuais eproduzir publicações de valor duradouro, OGC amplas consultas com as diferentes partesinteressadas em todo o mundo em todas as fases do processo. OGC também gostaria deagradecer às seguintes pessoas e suas organizações, por suas contribuições à orientaçãorefrescante ITIL a:O ITIL Grupo ConsultivoPippa Bass, OGC; Tony Betts, Independente; Signe-Marie Hernes Bjerke, Det Norske Veritas;Alison Cartlidge, Xansa; Diane Colbeck, DIYmonde Solutions Inc; Ivor Evans, DIYmondeSolutions Inc; Karen Ferris, ProActive; Malcolm Fry, Fry-Consultores , João Gibert,Independente; Colin Hamilton, RENARD Consulting Ltd; Lex Hendriks, EXIN; Carol Hulm, BritishComputer Society-ISEB; Tony Jenkins, DOMAINetc; Phil Montanaro, EDS; Alan Nance,ITpreneurs; Christian Nissen, Itilligence; Página Don, Marval Grupo; Bill Powell, IBM; SergioRubinato Filho, CA; James Siminoski, SOScorp; Robert E. Stroud, CA; Jan van Bon, informe-IT;Ken Wendle, HP, Paul Wilkinson, Getronics PinkRoccade; Takashi Yagi, Hitachi.RevisoresJorge Acevedo, Computec SA; Balaji Alapilla; Valerie Arraj, INTEQ; Colin Ashcroft, Cidade deLondres, William Bagley, Amgreetings; Martijn Bakker, Getronics PinkRoccade; Jeff Bartrop, BT& Atendimento ao Cliente direto; Rajesh Basava Amatyappa Bellary, Satyam, John Bennett ,Centram Ltd; Ian Bevan, Fox IT, Enrico Boverino, CA; Bart Van Brabant, Post; Ronald Browning,CA; Stephen Bull, Serra de Sistemas; Bradley Busch, InTotality; Howard Carpenter, IBM; LiangCheng, IBM, John Clark, HP; Nicole Conboy, Nicole Conboy & Associates; Sharon Dale, AquipInternacional; Sandra Daly, Dawling Consultoria; Tony Domínio, Blue Yonder, Michael Donahue,IBM; Ken Doughty, André J. Emmell, DKMStech; Matthew Evans, Processo Worx, Juan AntonioFernandez, Quint Wellington Redrood; Karen Ferris, proativa Serviços; Juan José Figueiras,Globant; Liz Gallacher; Rae Garrett, Pink Elephant, Klaus Goedel, HP; David Gooda, GenesysConsultoria; Detlef Gross, Automação Consulting Group GmbH; Matthias Hall, Universidade deDundee, John Hannan, melhores práticas de TI; Jonas Hansen, MMIT; Oliver Hast, Scoops; JabeHickey, IBM; Graham Hill, Metisc; Kevin Hite, Microsoft; Sergio Hrabinski, Xelere; Scott Jaegar,Plexant; Chris Jay; Chunyang Jia, Microsoft; Masthan Kadhar Kadhar, Cognizant, Tony Kelman-Smith, HP; Peter Koepp, Independente; Joanne Kopcho, a Capgemini América; Rene van Kuijen;Debbie Langenfield, IBM; Horacio Laprea; Sarah Lascelles, Interserve Projeto Services Ltd, PeterLoos , Accenture Services GmbH, Marcos Lopez, da Microsoft; Emmanuel Marchand, Advens;James Marmion, Yell Group, Jesus Martin, Ibermatica SA; Luis Moran, Independente; SteveMorgan, KPMG; Ron Morton, HP; Philip Mougis, TCS; Richard Mulholland, IBM; Ron Muns, IDH;Darren Murtagh, Retravision; Krisna Nugraha, Cleon Consultoria; Shuichi Owa, Niandc; SampoPasanen, Efecte; Rodrigo Pementa, Pink Elephant, Eddy Peters, CTG; Steve Phelan, LuaMacaco; Carol Piccus, CA; Poul Mols Poulsen, Coop Norden TI; Roger Purdie, A Arte de Serviço;Glen Ralph, iCore Ltd; Padmini Ramamurthy, Satyam Computer Services Ltd; Keith Reynolds,NSS Consultoria; Manfred Rieder, HP; Stephanie Roddy, Camelot Group; Mieke Roelens, CTA;Frances Scarff, OGC; Markus Schiemer, a Unisys; Barbara Schiesser, Swiss TIC; Klaus Seidel,Microsoft; Migel Sergey; Mamak Shafai; Prakash Sharma; Gilbert Silva, Techbiz Informatica Ltd;Jim Siminoski, Soscorp; Dierk Soellner, Mod-gruppe , José Estêvão, do Departamento deTransportes, Governo dos EUA; Michala Sterling, Mid Sussex Conselho Distrital; Helen Sussex,Logic ACMG; Rohan Thuraisingham, Friends Provident Management Services Ltd, MateusTolman, Sandvik, Cheryl Tovizi, MWH Global; Frank Victor, Victor GmbH ; Corde Wagner;Christoph Wettstein, CLAVIS KLW AG; Andi Wijaya, IBM; Aaron Wolfe, Pink Elephant, MikeYang, IBM; Younghoon Youn, IBM.ITIL V3 - Operação de Serviço - Página: 16 de 423
  • 17. 1 IntroduçãoEsta publicação fornece as melhores práticas de aconselhamento e orientaçãosobre todos os aspectos da gestão do dia-a-dia operação de uma organizaçãode tecnologia da informação (TI). Abrange questões relacionadas com aspessoas, processoes de tecnologia, infra-estrutura e relaçãos necessária paragarantir a elevada qualidade, o fornecimento eficaz de Serviços de TI necessáriopara atender às necessidades de negócio.O advento de novas tecnologias e as linhas ténues entre agora os silos detecnologia tradicionais de hardware, redes, telefonia e software aplicaçãosgestão significa que uma abordagem atualizada para a gestão operação deserviços é necessária. Organizaçãos estão cada vez mais propensos aconsiderar formas de prestação de TI na sua melhor custar e flexibilidade, com aintrodução de utilidade TI, pay-per-use serviços de TI, fornecimento de TIvirtuais, dinâmicas capacidade e Adaptive Enterprise Computing, bem como emtarefas de abastecimento e terceirização opções.Estas alternativas têm levado a uma miríade de relações de negócios de TI,tanto interna como externamente, que aumentaram em complexidade, tantoquanto as tecnologias que estão sendo gerenciados têm. Negócio dependênciasobre essas relações complexas é cada vez mais crítico para a sobrevivência eprosperidade.ITIL V3 - Operação de Serviço - Página: 17 de 423
  • 18. 1.1 Visão GeralOperação de Serviço é a fase em ITSM Ciclo de Vida que é responsável por"business-as-usual" atividades.Operação de Serviço pode ser visto como a "fábrica" de TI. Isto implica ummaior foco nas atividades do dia-a-dia e infra-estrutura que são utilizados paraprestar serviços. No entanto, esta publicação é baseada no entendimento deque o objetivo primordial da Operação de Serviço é para entregar e suportarserviços. Gestão da infra-estrutura ea operacional atividades devem sempreapoiar esta finalidade.Processos bem planejados e implementados será em vão se a operação do dia-a-dia desses processos não é bem conduzido, controlado e gerenciado. Nemserá serviço melhorias será possível se dia-a-dia para monitorizar atuação,Avaliar métricos dados e recolher não são sistematicamente realizadas durantea Operação de Serviço.Operação equipe de serviço deve dispor de processos e ferramentas de apoioque lhes permitam ter uma visão global da operação de serviço e de entrega (enão apenas a parte componentes, como o hardware, aplicações de software eredes, que compõem o fim-de-final serviço a partir de um perspectiva denegócios) E para detectar quaisquer ameaças ou falhas de serviço qualidade.Dado que os serviços podem ser fornecidos, no todo ou em parte, por um oumais parceiros /fornecedor organizaçãos, o Operação de Serviço ver de fim-de-final serviço deve ser ampliada para abranger os aspectos externos deprestação de serviços - e onde compartilhada necessária ou interfaceprocessoes e são necessárias ferramentas para gerenciar fluxos de trabalhointer-organizacionais.Operação de Serviço não é nem uma unidade organizacional nem um únicoprocesso - mas inclui vários funçãos e muitos processos e actividades, queestão descritos nos Capítulos 4, 5 e 6ITIL V3 - Operação de Serviço - Página: 18 de 423
  • 19. 1,2 Contexto1.2.1 Gestão de ServiçosTI é um termo comumente utilizado que muda de significado com o contexto. Apartir da perspectiva de primeira, TI sistemas, aplicaçãos e infra-estrutura sãocomponentes ou subconjuntos de um produto maior. Eles permitem ou sãoincorporados em processos e serviços. A partir da segunda perspectiva, é umaorganização com seu próprio conjunto de capacidades e recursos. Organizaçõesde TI podem ser de vários tipos, tais como funções de negócios, unidades deserviços partilhados e unidades de nível empresarial do núcleo.A partir da terceira perspectiva, é uma categoria dos serviços utilizados pelasempresas. Eles são tipicamente aplicações de TI e infra-estrutura que sãoempacotados e oferecidos como serviços por organizações de TI interna ouexterna provedor de serviçoss. TI custars são tratados como despesascomerciais. A partir da quarta perspectiva, é uma categoria de negócio ativossque fornecem um fluxo de benefícios para seus proprietários, incluindo, mas nãolimitado a, lucros, receitas e lucro. Os custos de TI são tratados comoinvestimentos.1.2.2 Boas práticas no domínio públicoOrganizações operar em ambientes dinâmicos com a necessidade de aprendere se adaptar. Existe uma necessidade de melhorar atuação enquanto gestoratrade-offs. Sob pressão semelhante, clientes procuram vantagem de prestadoresde serviços. Eles perseguem estratégias de sourcing que melhor servem o seuinteresse próprio negócio. Em muitos países, as agências governamentais eorganizações sem fins lucrativos empresas têm uma propensão similar aoterceirizar para o bem da operacional eficácia. Isso coloca uma pressãoadicional sobre os prestadores de serviços para manter uma vantagemcompetitiva em relação às alternativas que os clientes possam ter. O aumentoem terceirização se particularmente expostas prestador de serviços internos àconcorrência incomum.Para lidar com a pressão, organizações referência se contra colegas e procurarpara fechar lacunas em capacidades. Uma forma de fechar essas lacunas é aadoção de boas práticas em toda a indústria. Existem várias fontes de boaspráticas, incluindo estruturas públicas, padrãos e do conhecimento depropriedade de organizações e indivíduos (ver Figura 1.1).ITIL V3 - Operação de Serviço - Página: 19 de 423
  • 20. Figura 1.1 Fonte de Prática Gestão de ServiçosEstruturas públicas e as normas são atraentes quando comparados comconhecimento de propriedade:• Conhecimento proprietário, está profundamente enraizado nasorganizações e, portanto, difícil de adotar, replicar ou transferir, mesmocom a cooperação dos proprietários. Tal conhecimento é muitas vezes naforma de conhecimento tácito que é indissolúvel e mal documentadas.• Conhecimento proprietário é personalizado para o contexto local e asnecessidades específicas do negócio, a ponto de ser idiossincrático. Anão ser que os destinatários de tais conhecimentos têm correspondênciacircunstâncias, o conhecimento não pode ser tão eficaz em uso.• Proprietários de conhecimento proprietário esperam ser recompensadospor seus investimentos de longo prazo. Eles podem fazer talconhecimento disponível apenas em termos comerciais, por meio decompras e licenciamento acordos.• Publicamente disponíveis quadros e padrãos, tais como ITIL, Objetivos deControle para TI (COBIT), CMMI, eSCM-SP, PRINCE2,ISO 9000, ISO20000 e ISO 27001 são validados através de um conjunto diversificado deambientes e situações, em vez de limitada experiência de um únicoorganização. Eles estão sujeitos a ampla rever através de váriasorganizações e disciplinas. Eles são controlados por diversos conjuntosde parceiros, fornecedors e concorrentes.• O conhecimento das estruturas públicas é mais provável a seramplamente distribuído entre uma grande comunidade de profissionaispor meio de treinamento disponíveis publicamente e certificado. É maisfácil para as organizações a adquirir tais conhecimentos por meio domercado de trabalho.ITIL V3 - Operação de Serviço - Página: 20 de 423
  • 21. Ignorando estruturas públicas e padrões podem desnecessariamente colocaruma organização em desvantagem. As organizações devem cultivar seu próprioconhecimento proprietária em cima de um corpo de conhecimento baseado emquadros públicos e padrões. Colaboração e coordenação entre as organizaçõessão mais fáceis com base compartilhada práticas e padrões.1.2.3 ITIL e boas práticas em Gestão de ServiçosO contexto desta publicação é o ITIL Quadro como uma fonte de boas práticasServiço de Gestão de. ITIL é usado por organizações em todo o mundo paraestabelecer e melhorar as capacidades de gerenciamento de serviços. ISO / IEC20000 fornece um padrão formal e universal para organizações que buscam terseus recursos de gerenciamento de serviço auditado e certificado. Enquanto anorma ISO / IEC 20000 é um padrão a ser alcançado e mantido, ITIL oferece umcorpo de conhecimento útil para alcançar o padrão.A Biblioteca ITIL tem o seguinte componentes:• ITIL Core: melhores práticas de orientação aplicável a todos os tipos deorganizações que prestam serviços a uma empresa de• ITIL Orientação complementar: um conjunto complementar depublicações com orientações específicas para os setores da indústria,tipos de organização, modelos operacionais e tecnologia arquiteturas.O Core ITIL é composto por cinco publicações (ver Figura 1.2). Cada uma delasfornece a orientação necessária para uma abordagem integrada, conformeexigido pela norma ISO / IEC 20000 padrão especificação:• Estratégia de Serviço• Design de Serviços• Transição de Serviço• Operação de Serviço• Melhoria de Serviço Continuada.ITIL V3 - Operação de Serviço - Página: 21 de 423
  • 22. Figura 1.2 ITIL NúcleoCada publicação aborda as capacidades que têm impacto direto sobre umserviço de provedor atuação. A estrutura do núcleo é na forma de um ciclo devida. Ele é interativo e multidimensional. Ele garante que organizaçãos sãocriados para alavancar as capacidades em uma área de aprendizagem emelhorias em outras. O Núcleo é esperado para dar estabilidade, estrutura eforça para Serviço de Gestão de capacidades, com duráveis princípios, métodose ferramentas. Isso serve para proteger os investimentos e proporcionar a basenecessária para a aprendizagem, medição e melhoria.A orientação em ITIL pode ser adaptado para as mudanças de uso em váriosnegócios ambientes e estratégias organizacionais. Orientação Complementarfornece flexibilidade para implementar o núcleo em uma variada gama deambientes. Os médicos podem seleccionar Orientação Complementar conformenecessário, para proporcionar tracção para o núcleo num contexto comercialdeterminada, tanto quanto os pneus são seleccionados com base no tipo definalidade do automóvel, e as condições da estrada. Isto é para aumentar adurabilidade e a portabilidade de conhecimento ativoss e proteger osinvestimentos em capacidades de gerenciamento de serviços.ITIL V3 - Operação de Serviço - Página: 22 de 423
  • 23. 1.2.3.1 Estratégia de ServiçoO Estratégia de Serviço volume fornece orientação sobre como projeto,Desenvolver e implementar o Gerenciamento de Serviço, não apenas como umaorganização capacidade mas também como um estratégico ativos. Sãofornecidas orientações sobre os princípios subjacentes à prática de Gestão deServiços, que são úteis para o desenvolvimento de políticas de gerenciamentode serviços, diretrizs e processoes entre o ITIL Serviço Ciclo de Vida. OrientaçãoEstratégia serviço é útil no contexto de Design de Serviços,Transição deServiço,Operação de Serviço e Melhoria de Serviço Continuada. Os tópicosabordados na Estratégia de Serviço incluem o desenvolvimento dos mercados,interno e externo, serviço ativos, catálogo de serviços e implementação deestratégia através do Ciclo de Vida do Serviço. Gestão Financeira,Gestão dePortfólio de Serviços, Desenvolvimento Organizacional e Estratégico Riscosestão entre outros grandes temas.Organizações usam a orientação para definir objetivos e expectativas dedesempenho para servir clientes e espaços de mercado e para identificar,selecionar e priorizar oportunidades. Estratégia de Serviço se de garantir que asorganizações estão em uma posição para lidar com a custars e os riscosassociados ao seu portfólio de serviçoss e são criados não só para operacionaleficácia mas para o desempenho diferenciado. As decisões feitas em relação àEstratégia de Serviço tem conseqüências de longo alcance, incluindo aquelescom efeito retardado.Organizações que já praticam ITIL usar este volume para orientar umaestratégica rever de suas capacidades baseadas em ITIL Service Management emelhorar o alinhamento entre esses recursos e suas estratégias de negócios.Este volume de ITIL incentiva os leitores a parar e pensar sobre por que algoestá a ser feito antes de pensar em como fazer. Respostas para o primeiro tipode questões estão mais próximas de negócio do cliente. Estratégia de Serviçoexpande o escopo do Quadro de ITIL além do público tradicional de profissionaisde ITSM.1.2.3.2 Design de ServiçosO volume de Design de Serviços fornece orientação para a concepção edesenvolvimento de serviços e processos de gerenciamento de serviços. Eleabrange os princípios de design e métodos para converter objetivos estratégicosem portfólios de serviços e bens de serviço. O âmbito do Design de Serviçosnão se limita a novos serviços. Ele inclui as mudanças e melhorias necessáriaspara aumentar ou manter valor para os clientes durante o ciclo de vida dosserviços, a continuidade dos serviços, a realização de nível de serviços econformidade com padrãos e regulamentos. Ele orienta as organizações sobrecomo desenvolver capacidades de design para Gerenciamento de Serviços.ITIL V3 - Operação de Serviço - Página: 23 de 423
  • 24. 1.2.3.3 Transição de ServiçoO Transição de Serviço volume fornece orientação para o desenvolvimento emelhoria de capacidades para a transição de serviços novos e modificados emoperaçãos. Esta publicação fornece orientação sobre como o exigências deEstratégia de Serviço codificados em Design de Serviços são efetivamenterealizados em Operações de Serviço ao controlar a riscos de fracasso e ruptura.A publicação combina práticas em Gerenciamento de Liberação,ProgramaGestão e Gestão de Risco e coloca-os no contexto da prática de Serviço deGestão de. Ele fornece orientações sobre o gerenciamento da complexidaderelacionada a alterações nos serviços e gestão de serviços processoes, evitandoconsequências indesejáveis, permitindo a inovação. Orientação é fornecidasobre a transferência do controlar de serviços entre clientes e provedor deserviçoss.1.2.3.4 Operação de ServiçoEste volume incorpora práticas na gestão de Operação de Serviços. Incluiorientação sobre a realização eficácia e eficiência na entrega e suporte deserviços, de modo a garantir um valor para o cliente e o provedor de serviços.Estratégico objetivos são, em última análise realizada através de operações deserviços, portanto, tornando-se uma crítica capacidade. São fornecidasorientações sobre como manter a estabilidade em operações de serviços, o quepermite mudanças de escala, design, escopo e níveis de serviço. Organizaçõessão fornecidos com processo detalhado diretrizs, métodos e ferramentas parauso em dois grandes controle de perspectivas: reativa e pró-ativa. Gestores eprofissionais são fornecidos com o conhecimento que lhes permite tomarmelhores decisões em áreas como a gestão do disponibilidade de serviços, ademanda controle, otimização capacidade agendamento de utilização, dasoperações de fixação e problemas. São fornecidas orientações sobre operaçõesde apoio através de novos modelos e arquiteturas, tais como serviçoscompartilhados, utilidade computação, serviços web e comércio móvel.1.2.3.5 Melhoria de Serviço ContinuadaEste volume oferece orientação instrumental na criação e manutenção de valorpara os clientes através de uma melhor projeto, Implantação e operação deserviços. Ele combina os princípios, práticas e métodos de Qualidade Gestão,Gestão da Mudança e Melhoria de Capacidade. Organizações aprender aperceber melhorias incrementais e de larga escala em serviço qualidade,operacional eficiência e continuidade dos negócios. Orientação é fornecida paraligar os esforços de melhoria e resultados com Service Design de Serviços,Estratégia e Transição de Serviço. A realimentação de circuito fechado sistema,Com base no Plan-Do-Check-Act (PDCA) modelo especificado no ISO / IEC20000, É estabelecido e capaz de receber entradas para mudar a partir dequalquer planejamento perspectiva.ITIL V3 - Operação de Serviço - Página: 24 de 423
  • 25. A gestão do dia-a-dia operacional da Serviços de TIs é significativamenteinfluenciado pela maneira como um organizaçãoS estratégia geral de TI serviçofoi definido e quão bem os processos de ITSM foram planejadas eimplementadas. Esta é a quarta publicação no Gerenciamento de Serviços ITILsérie Práticas e as outras publicações sobre Estratégia de Serviço, Desenho deServiço e Transição de Serviço deve ser consultado para melhores práticasorientação sobre esses importantes etapas anteriores à operação do serviço.Operação de Serviço é extremamente importante, pois é no dia-a-diaoperacional que eventos ocorrer o que pode adversamente impacto qualidadedo serviço. A forma como uma organização Infra-estrutura de TI e seusprocessos de apoio ITSM são operados terá mais direta e imediata influência decurto prazo sobre serviço qualidade.ITIL V3 - Operação de Serviço - Página: 25 de 423
  • 26. 1,3 PropósitoOperação de Serviço é uma fase crítica do ITSM ciclo de vida. Bem planejado eprocessos bem implementados será em vão se a operação do dia-a-dia dessesprocessos não é bem conduzido, controlado e gerenciado. Nem vai atendermelhorias será possível se dia-a-dia para monitorar atuação, Avaliar métricosdados e recolher não são sistematicamente realizadas durante a Operação deServiço.Operação equipe de serviço deve dispor de processos e ferramentas de apoioque lhes permitam ter uma visão global da operação de serviço e de entrega (enão apenas a parte componentes, tais como hardware, software aplicaçãos eredes, que compõem o fim-de-final serviço a partir de uma perspectiva denegócios) e para detectar qualquer ameaças ou falhas de serviço qualidade.Dado que os serviços podem ser fornecidos, no todo ou em parte, por um oumais parceiros /fornecedor organizações, o Operação de Serviço vista de pontaa ponta-de serviço deve ser estendido para abranger os aspectos externos deprestação de serviços - e onde compartilhada necessária ou interfaceprocessoes e são necessárias ferramentas para gerenciar fluxos de trabalhointer-organizacionais.1,4 UsoEsta publicação deve ser usada em conjunto com as outras quatro publicaçõesque compõem o Serviço ITIL Ciclo de Vida.Os leitores devem estar cientes de que a melhor prática diretrizs em volumeseste e outros não são destinados a ser prescritiva. Cada organização é único edeve "adaptar e adotar" a orientação para suas próprias necessidadesespecíficas, ambiente e cultura. Isso envolverá tendo em conta a dimensão daorganização, competências /recursos, cultura, financiamento, prioridades e ITSMexistentes maturidade e modificando a orientação adequada para atender àsnecessidades da organização.Para as organizações encontrando ITIL, pela primeira vez, a forma inicial dealguns avaliação comparar os processos atuais da organização e práticas comas recomendadas pelo ITIL seria um ponto de partida muito valioso. Estasavaliações são descritos em mais pormenor no ITIL Melhoria de ServiçoContinuada publicação.Onde existem lacunas significativas, pode ser necessário para resolvê-los emetapas ao longo de um período de tempo para atender às prioridades de negócioda organização e manter o ritmo com o que a organização é capaz de absorvere pagarITIL V3 - Operação de Serviço - Página: 26 de 423
  • 27. 1,5 Visão geral do capítuloCapítulo 2 introduz o conceito de Serviço de Gestão de como uma prática. Aqui,Gerenciamento de Serviços está posicionada como uma estratégica eprofissional componente de qualquer organização. Este capítulo também forneceuma visão geral da operação de serviço como um componente crítico da Práticade Gestão de Serviços.Os princípios fundamentais da operação de serviço são abordados no Capítulo 3desta publicação. Estes princípios delinear alguns dos conceitos e princípiosbásicos em que o restante da publicação se baseia.Capítulo 4 abrange os processos realizados dentro de Operação de Serviço - amaioria dos processos de operação de serviço são reativos devido à natureza dotrabalho a ser realizado para manter Serviços de TIs numa condição estávelrobusto. Este capítulo também abrange processos proactivos de enfatizar que oobjetivo da Operação de Serviço é a estabilidade - mas não de estagnação.Operação de Serviço deve ser constantemente procurando maneiras de fazer ascoisas melhor e de forma mais econômica, e os processos de dinamização têmum papel importante a desempenhar aqui.Capítulo 5 abrange uma série de atividades de serviços comuns de operação,que são grupos de atividades e procedimentos realizadas por Funções operaçãode serviço. Estes especializados, e muitas vezes técnicas, atividades não sãoprocessos no verdadeiro sentido da palavra, mas todos eles são vitais para acapacidade de oferecer qualidade de serviços de TI no ideal custar.Capítulo 6 cobre os aspectos organizacionais da Operação de Serviço - osindivíduos ou grupos que realizam processos de serviço de operação ouatividades - e inclui algumas orientações sobre estruturas de organização deserviços de Operação.Capítulo 7 descreve as ferramentas e tecnologia que são usados durante aOperação de Serviço.Capítulo 8 aborda alguns aspectos da implementação que precisam serconsiderados antes da operacional fase do ciclo de vida torna-se ativa.Capítulo 9 destaca os desafios, Fatores Críticos de Sucesso e riscos enfrentoudurante Operação de Serviço, Enquanto o Posfácio resume e conclui apublicação.ITIL não está sozinha na prestação de orientação para os gestores de TI e osapêndices delinear algumas das estruturas complementares fundamentais,metodologias e abordagens que são comumente usados em conjunto com ITILdurante Operação de ServiçoITIL V3 - Operação de Serviço - Página: 27 de 423
  • 28. 2 Gerenciamento de Serviço como uma prática2.1 O que é Gerenciamento de Serviços?Serviço de Gestão de é um conjunto de capacidades especializadasorganizacionais para o valor de clientes, sob a forma de serviços. Ascapacidades de assumir a forma de funçãos e processoes para gerenciamentode serviços ao longo de um ciclo de vida, Com especializações emestratégia,projeto, Transição, operação e melhoria contínua. Os recursosrepresentam um serviço organizaçãoS capacidade, Competência e confiançapara a ação. O ato de transformar recursos em serviços de valor está no centrode Gerenciamento de Serviço. Sem esses recursos, uma organização de serviçoé meramente um conjunto de recursos que por si só tem relativamente baixovalor intrínseco para os clientes.Definição de Gerenciamento de ServiçoService Management é um conjunto de capacidades especializadasorganizacionais para o valor aos clientes na forma de serviços.Capacidades organizacionais são moldadas pelos desafios que eles terão desuperar. Um exemplo desta situação é como em 1950 Toyota desenvolvidascapacidades únicas de superar o desafio de menor escala e capital financeiroem relação aos seus rivais americanos. Toyota desenvolvidas novascapacidades em engenharia de produção, gestão de operações e gestãofornecedors para compensar sua incapacidade de pagar grandes estoques,fazer componentes, produzir matérias-primas ou possuir as empresas que osproduzem. [Fonte: Magretta, Joan 2002. O que é gestão: Como funciona e porque negócio é de todos. O Free Press.] Capacidades de gerenciamento deserviços são igualmente influenciado pelos seguintes desafios que o distinguemde outros serviços sistemas de criação de valor, tais como mineração,manufatura e agricultura:• Natureza intangível dos produtos de saída e intermediário de processosde serviços: difícil de medir, controlar e validar (ou provar).• A demanda está intimamente ligado com o cliente ativoss: Usuários eativos dos clientes, tais como processos, aplicaçãos, documentos etransaçãos chega com a demanda e estimular a produção de serviços.• Alto nível de contato para os produtores e consumidores de serviços:tampão Pouca ou nenhuma entre o cliente, o front-office e back-office.• A natureza perecível serviço saída e serviço capacidade: Não há valorpara o cliente de garantia da continuidade do fornecimento de consistentequalidade. Provedores precisam garantir um suprimento constante dedemanda dos clientes.ITIL V3 - Operação de Serviço - Página: 28 de 423
  • 29. No entanto, Serviço de Gestão de é mais do que apenas um conjunto decapacidades. É também um profissional prática suportado por um extenso corpode conhecimento, experiência e habilidades. Uma comunidade global deindivíduos e organizações dos setores público e privado promove seucrescimento e maturidade. Esquemas formais existem para a educação,formação e certificado de praticar organizações e indivíduos influenciar suaqualidade. Indústria melhores práticasA pesquisa, acadêmica e formal padrãoscontribuir para o seu capital intelectual e tirar dele.As origens do Gerenciamento de Serviço estão em empresas de serviçostradicionais, tais como companhias aéreas, bancos, hotéis e empresas detelefonia. Sua prática tem crescido com a adoção pelas organizações de TI deuma abordagem orientada a serviços para gestão de TI aplicaçãoa infra-estrutura e processos. Soluções para os negócios problemas e suporte paranegócios modelos, estratégias e operaçãos são cada vez mais sob a forma deserviços. A popularidade de serviços partilhados e terceirização contribuiu para oaumento do número de organizações que são provedor de serviçoss, incluindounidades organizacionais internas. Este, por sua vez, reforçou a prática deGestão de Serviços e, ao mesmo tempo imposta maiores desafios em cima dele.ITIL V3 - Operação de Serviço - Página: 29 de 423
  • 30. 2.2 O que são serviços?2.2.1 O valor proposiçãoDefinição de serviçoUm serviço é um meio de entregar valor aos clientes, facilitando resultadosclientes querem alcançar, sem a posse de determinado custars e riscos.Os serviços são um meio de entregar valor aos clientes, facilitando os resultadosque os clientes querem alcançar, sem a posse de custos e riscos específicos.Serviços de facilitar os resultados através do aumento da atuação associado detarefas e a redução do efeito de restrições. O resultado é um aumento naprobabilidade de resultados desejados.Figura 2.1 Uma conversa sobre a definição e significado de serviçosITIL V3 - Operação de Serviço - Página: 30 de 423
  • 31. 2.3 Funções e processos em todo o ciclo de vida2.3.1 FunçõesFunçãos são unidades de organizações especializadas para executar certostipos de trabalho e responsável pela específico resultados. Eles são auto-suficientes, com capacidades e recursos necessária para a sua atuação e osresultados. Os recursos incluem métodos de trabalho interno para as funções.Funções têm seu próprio corpo de conhecimentos, que se acumula com aexperiência. Eles fornecem estrutura e estabilidade para as organizações.Funções são um meio de estruturar as organizações, de modo a implementar oprincípio da especialização. Funções normalmente definem papels ea autoridadeassociado e responsabilidade para um desempenho específico e os resultados.Coordenação entre funções através compartilhada processoes é um padrãocomum na organização projeto. Funções tendem a otimizar seus métodos detrabalho a nível local, para se concentrar nos resultados atribuídos. Fracacoordenação entre as funções, combinados com um foco para dentro, leva asilos funcionais que impedem o alinhamento e feedback crítico para o sucessodo organização como um todo. Processo modelos ajudar a evitar esse problemacom hierarquias funcionais, melhorando a coordenação inter-funcional econtrolar. Processos bem definidos pode melhorar a produtividade dentro eatravés de funções.2.3.2 ProcessosProcessos são exemplos de circuito fechado sistemas, pois fornecem mudar ede transformação para um objetivo e utilizar o feedback para a auto-reforço eauto-ação corretiva (ver Figura 2.2). É importante levar em consideração todo oprocesso, ou como um processo encaixa outra.Figura 2.2 Um processo básicoITIL V3 - Operação de Serviço - Página: 31 de 423
  • 32. Definições de processos descrevem ações, dependências e seqüência.Processos de ter as seguintes características:• Mensuráveis: Nós somos capazes de medir o processo de uma maneirarelevante. É o desempenho conduzido. Os gerentes querem medircustar,qualidade e outras variáveis, ao passo que os profissionais estãopreocupados com a duração e a produtividade.• Resultados específicos: A razão de um processo existe é entregar umresultado específico. Este resultado deve ser individualmenteidentificáveis e contáveis. Enquanto podemos contar mudanças, éimpossível contar quantas Service Desks foram concluídas.• Clientes: Todo processo de entrega de seus resultados primários para umcliente ou das partes interessadas. Elas podem ser internas ou externas àorganização, mas o processo tem de satisfazer as suas expectativas.• Responde a um específico evento: Enquanto um processo pode sercontínuo ou iterativo, deve ser feita com um gatilho específico.As funções são muitas vezes confundidos com os processos. Por exemplo,existem conceitos errados sobre Gerenciamento da Capacidade ser um Serviçode Gestão de processo. Primeiro, Gerenciamento da Capacidade é umaorganização capacidade com processos especializados e métodos de trabalho.Quer se trate de uma função ou de um processo depende inteiramente o projetode organização. É um erro supor que Gerenciamento da Capacidade pode serapenas um processo. É possível medir e controlar capacidade e para determinarse ele é adequado para um determinado fim. Assumindo que é sempre umprocesso, Com contável discreto resultados, pode ser um erro.2.3.3 Especialização e coordenação em todo o ciclo de vidaEspecialização e coordenação são necessários no ciclo de vida abordagem.Feedback e controle entre o funçãos e processos dentro e entre os elementosdo ciclo de vida de tornar isso possível. O padrão dominante do ciclo de vida é oprogresso seqüencial a partir de SS através SO-SD-ST e volta a SS por meio deCSI. No entanto, esse não é o único padrão de acção. Cada elemento do ciclode vida fornece pontos de feedback e controle.A combinação de múltiplas perspectivas permite uma maior flexibilidade econtrole em ambientes e situações. A abordagem do ciclo de vida imita arealidade da maioria das organizações onde a gestão eficaz requer a utilizaçãode múltiplas controle de perspectivas. Os responsáveis pelaprojeto,desenvolvimento e melhoria de processos para Serviço de Gestão depode adotar uma perspectiva de controle baseada em processos. Osresponsáveis pela gestão acordos, contratos e serviços pode ser melhor servidopor uma perspectiva de controle do ciclo de vida baseado em fases distintas.Ambos controle benefício perspectivas de sistemas pensando. Cada perspectivade controle pode revelar padrões que podem não ser evidentes a partir do outro.ITIL V3 - Operação de Serviço - Página: 32 de 423
  • 33. 2.4 Operação fundamentos Serviço2.4.1 Finalidade objetivo / / objetivoO objectivo da Operação de Serviço é coordenar e executar as atividades eprocessos necessários para fornecer e gerenciar serviços em níveis acordadospara os negócios usuários e clientes. Operação de Serviço é tambémresponsável pela gestão contínua da tecnologia que é usada para entregar esuportar serviços.Processos bem desenhados e bem implementado será de pouco valor se o dia-a-dia operação desses processos não é bem conduzido, controlado egerenciado. Nem será serviço melhorias será possível se dia-a-dia paramonitorizar atuação, Avaliar métricos dados e recolher não sãosistematicamente realizadas durante a Operação de Serviço.2.4.2 ÂmbitoOperação de Serviço inclui a execução de todas as actividades em cursoexigidos para entregar e suportar serviços. O escopo de Operação de Serviçoinclui:• Os próprios serviços. Qualquer atividade que faz parte de um serviçoestá incluído na Operação de Serviço, quer seja executado pelaPrestadora de Serviço, um externo fornecedor ou o usuário ou clientedesse serviço• Gestão de processos de serviços. O gerenciamento e execução deprocessos de gerenciamento de serviço são muitos realizada emoperação de serviço, apesar de uma série de processos de ITIL (comoMudança e Gerenciamento de Capacidade) originam-se no Design deServiços ou Transição de Serviço fase do Serviço Ciclo de Vida, Elesestão em usar continuamente em operação do serviço. Alguns processosnão são incluídos especificamente na operação de serviço, tais comoEstratégia Definição, o projeto real do próprio processo. Esses processosse concentrar mais no longo prazo planejamento e atividades demelhoria, que estão fora do escopo direto de Operação de Serviço, noentanto, Operação de Serviço fornece entrada e influencia estesregularmente, como parte do ciclo de vida de Gerenciamento de Serviço.• Tecnologia. Todos os serviços requerem alguma forma de tecnologiapara entregá-los. Gerenciando essa tecnologia não é uma questãoseparada, mas uma parte integrante da gestão dos próprios serviços.Portanto, uma grande parte desta publicação está preocupada com agestão da infra-estrutura utilizada para prestar serviços.• Pessoas. Independentemente do que serviços, processoes e tecnologiasão geridos, todos eles são sobre pessoas. São as pessoas que dirigem ademanda para o organizaçãoS serviços e produtos e são as pessoas queITIL V3 - Operação de Serviço - Página: 33 de 423
  • 34. decidem como isso será feito. Em última análise, são as pessoas quegerenciam a tecnologia, processos e serviços. A falha em reconhecer istoirá resultar (e resultou) na falha de Serviço de Gestão de projetos2.4.3 Valor para os negóciosCada estágio no Serviço ITIL Ciclo de Vida fornece valor ao negócio. Porexemplo, o valor do serviço é modelado em Estratégia de Serviço; O custar doserviço é projetado, previsto e validado em Design de Serviços e Transição deServiço, E medidas para a otimização são identificados em Melhoria de ServiçoContinuada. O operação de serviço é onde estes planos, projetos e otimizaçõessão executados e medidos. A partir de um cliente ponto de vista, Operação deServiço é onde o valor real é visto.Há um lado para baixo a este, no entanto:• Uma vez que o serviço foi projetado e testado, é esperado para executardentro do orçamento e Retorno sobre Investimento metas estabelecidasno início do ciclo de vida. Na realidade, porém, muito poucasorganizações planejar de forma eficaz para os custos de gestão contínuados serviços. É muito fácil de quantificar os custos de um projeto, masmuito difícil de quantificar o que o serviço vai custar depois de três anosde funcionamento.• É difícil de obter, durante o financiamento operacional fase, para corrigirprojeto falhas ou imprevistos exigências - uma vez que este não faziaparte da proposta de valor original. Em muitos casos, é apenas depois dealgum tempo de operação que estes problemas superfície. A maioria dasorganizações não tem um mecanismo formal para rever serviçosoperacionais para o projeto e valor. Isto é deixado para a Incidentes eGerenciamento de Problemas para resolver - como se ele é puramenteuma questão operacional.• É difícil obter financiamento adicional para ferramentas ou ações(incluindo formação), que visa melhorar a eficiência de Operação deServiço. Isto é em parte porque eles não estão diretamente ligadas aofunçãoalidade de um serviço específico e em parte porque há umaexpectativa do cliente que estes custos deveriam ter sido construído nocusto do serviço desde o início. Infelizmente, a taxa da tecnologia mudaré muito elevado. Pouco depois de uma solução foi implantada que vaigerir eficazmente um conjunto de serviços, a nova tecnologia se tornadisponível, que pode fazê-lo mais rápido, mais barato e mais eficaz.• Uma vez que um serviço está em funcionamento há algum tempo, torna-se parte do linha de base do que a espera do negócio Serviços de TIs. Astentativas de otimizar o serviço ou utilizar novas ferramentas paragerenciá-lo de forma mais eficaz são vistos como bem-sucedido apenasse o serviço tem sido muito problemática no passado. Em outraspalavras, alguns serviços são um dado adquirido e qualquer ação paraITIL V3 - Operação de Serviço - Página: 34 de 423
  • 35. otimizá-los é percebido como "fixação de serviços que não estãoquebrados".Esta publicação sugere uma série de processos, funções e medidas que visamabordar essas áreas.2.4.4 Otimização do desempenho do Serviço de OperaçãoOperação de Serviço é otimizard de duas maneiras:• Longo prazo a melhoria incremental. Isto baseia-se na avaliação daatuação e saída de todos os processos de operação de serviço, funçãos esaídas ao longo do tempo. Os relatórios são analisados e uma decisãosobre se a melhoria é necessária e, em caso afirmativo, qual a melhorforma de implementá-lo através de Design de Serviços e Transição. Osexemplos incluem o desenvolvimento de um novo conjunto deferramentas, as alterações processo projetos, a reconfiguração da infra-estrutura, etc Este tipo de melhoria é abordado em detalhes napublicação Melhoria de Serviço Continuada.• Curto prazo, a melhoria contínua de trabalho práticas dentro dosprocessos de serviço de operação, funções e tecnologia em si. Estes sãogeralmente pequenas melhorias que são implementadas sem qualqueralteração para a natureza fundamental de um processo ou de tecnologia.Exemplos incluem afinação,carga de trabalho equilíbrio, reafectação depessoal e formação, etcEmbora ambos estes são discutidos em detalhe dentro do escopo de Operaçãode Serviço, o Melhoria de Serviço Continuada publicação proporcionará umquadro e alternativas em que a melhoria pode ser conduzido como parte doapoio global da objetivo de negócios.2.4.5 Processos dentro de Operação de ServiçoHá uma série de Operação de Serviço chave processoes que devem ligar emconjunto para proporcionar uma estrutura de suporte eficaz geral IT. A estruturageral é brevemente descrito aqui e, em seguida, cada um dos processos édescrito em mais detalhe no Capítulo 4.2.4.5.1 Gestão de EventosGestão de Eventos monitora todos eventos que ocorrem em todo o Infra-estrutura de TI, Para monitorizar normais operação e para detectar e aumentaras condições de exceção.2.4.5.2 Incidentes e Gestão de ProblemasITIL V3 - Operação de Serviço - Página: 35 de 423
  • 36. Gerenciamento de Incidentes concentra-se na restauração dos serviçosinesperadamente degradados ou interrompidos para usuários o maisrapidamente possível, a fim de minimizar a actividade impacto.Gerenciamento de Problemas envolve: análise de causa raiz para determinar eresolver a causa da incidentes, atividades pró-ativas para detectar e prevenirfuturos problemas / incidentes e um Erro Conhecido sub-processo para permitiro rápido diagnóstico e resolução se novos incidentes ocorrem.2.4.5.3 Cumprimento de RequisiçãoCumprimento de Requisição é o processo de tratamento com Solicitação deServiços - muitos deles realmente menor, de menorrisco, Mudanças -inicialmente através da Service Desk, Mas utilizando um processo semelhanteao que separado de Gerenciamento de Incidentes mas com CumprimentoPedido separado registros / tabelas - se necessário ligados ao incidente ouGrave problema(S) que iniciou a necessidade para a solicitação. Para ser umasolicitação de serviço, é normal que alguns pré-requisitos a serem definidos ecumpridos (por exemplo, as necessidades de ser comprovada, repetível, pré-aprovado, proceduralized).A fim de resolver um ou mais incidentes, problemas ou erros conhecidos,alguma forma de mudar pode ser necessária. Menor, muitas vezes padrão, asalterações podem ser tratadas através de um processo de Cumprimento deRequisição, mas maiores, mudanças de maior risco ou pouco frequentes devempassar por um formal Gestão da Mudança processo.2.4.5.4 Gerenciamento de AcessoGerenciamento de Acesso é o processo de concessão de autorização usuárioodireito de usar um serviço, Limitando o acesso a usuários não-autorizados. Ele ébaseado em ser capaz de identificar com precisão os usuários autorizados egerenciar sua própria capacidade de acessar serviços como exigido durante asdiferentes fases de seus Recursos Humanos (RH) ou contratual ciclo de vida.Gerenciamento de acesso também tem sido chamado de identidade ou DireitosGestão em algumas organizações.2.4.6 Funções dentro de Operação de ServiçoProcessos por si só não vai resultar em eficaz Operação de Serviço. Uma infra-estrutura estável e adequadamente pessoas qualificadas são necessáriostambém. Para conseguir isso, Operação de Serviço depende de vários gruposde pessoas qualificadas, todos focados em uso de processos para coincidir coma capacidade da infra-estrutura às necessidades do negócio.ITIL V3 - Operação de Serviço - Página: 36 de 423
  • 37. Estes grupos são classificados em quatro principais funçãos, aqui e discutido emdetalhes no Capítulo 6.2.4.6.1 Service DeskO Service Desk é o principal ponto de contato para os usuários quando há umainterrupção do serviço, por Solicitação de Serviços, ou até mesmo para algumascategorias de Requisição de Mudança. O Service Desk fornece um ponto decomunicação com os usuários e um ponto de coordenação para vários gruposde TI e processos2.4.6.2 Gestão TécnicaGestão Técnica fornece detalhadas habilidades técnicas e recursos necessáriospara suportar o curso operação do Infraestrutura de TI. Gestão Técnica tambémdesempenha um papel importante na projeto, Testes, liberar e melhoria dasServiços de TIs. Em pequenas empresas, é possível gerenciar essa experiênciaem um único departamento, mas as grandes organizações são normalmentedividida em vários departamentos especializados tecnicamente.2.4.6.3 Gestão de Operações de TITI Gestão de Operações executa a diária operacional atividades necessáriaspara gerenciar a infra-estrutura de TI. Isso é feito de acordo com o desempenhoPadrãos definido durante Design de Serviços. Em algumas organizações este éum departamento único e centralizado, enquanto em outros algumas atividadese funcionários são centralizados e alguns são fornecidos por departamentosdistribuídos ou especializada. Gestão de Operações de TI tem duas funções quesão únicas e são geralmente formais estruturas organizacionais. Estes são osseguintes:• Operações de TI Controle, O qual é geralmente composta por deslocarsde operadores e que assegura que as tarefas rotineiras operacionais sãorealizadas. Controle de Operações de TI também irá fornecer centralizadomonitoramento e controlar actividades, geralmente usando umaOperações Ponte ou Centro de Operações de Rede.• Facilities Management refere-se à gestão da TI física ambiente,Geralmente centros de dados ou salas de informática. Em muitasorganizações técnica e Aplicação de Gestão de são co-localizado comOperações de TI em grandes centros de dados.2.4.6.4 Gerenciamento de AplicativosApplication Management é responsável pela gestão Aplicaçãos ao longo do seuciclo de vida. A função de gerenciamento de aplicativos suporta e mantémaplicações operacionais e também desempenha um importante papel no projeto,ITIL V3 - Operação de Serviço - Página: 37 de 423
  • 38. teste e melhoria de aplicações que fazem parte dos serviços de TI.Gerenciamento de Aplicativos é geralmente dividida em departamentos combase no portfólio de aplicativos do organização, Permitindo assim mais fácil deespecialização e de mais apoio focado.2.4.6.5 Interfaces para outros estágios Serviço Lifecycle ManagementExistem vários outros processos que serão executados ou apoiados duranteOperação de Serviço, Mas que são conduzidas durante outras fases do Serviçode Gestão de Ciclo de Vida. Isto será discutido na parte final do capítulo 4 eincluem:• Gestão da Mudança, Que é um importante processo que deve estarintimamente ligado ao Gerenciamento da Configuração e Gerenciamentode Liberação. Esses tópicos são cobertos principalmente no Transição deServiço publicação.• Capacidade e Gerenciamento de Disponibilidade, Que são abordados napublicação Service Design.• Gestão Financeira, Que é coberto no Estratégia de Serviço publicação.• Gestão do Conhecimento, que é coberto na publicação Transição deServiço.• Serviços de TI Continuidade, que é coberto no Design de Serviçospublicação.• Serviço de Relatórios e Mensuração, que são cobertos no Melhoria deServiço Continuada publicação.ITIL V3 - Operação de Serviço - Página: 38 de 423
  • 39. 3 Operação princípios do serviçoAo considerar Operação de Serviço é tentador focar apenas no gerenciamentodo dia-a-dia e tecnologia como um fim em si mesmos. No entanto, Operação deServiço existe dentro de um contexto muito maior. Como parte do Ciclo de Vidado Gerenciamento de Serviços, é responsável pela execução e realização deprocessos que otimizar o custar e qualidade de serviços. Como parte doorganização, É responsável por permitir o negócio para cumprir o seu objetivos.Como parte do mundo da tecnologia, que é responsável pelo bomfuncionamento do componentes que os serviços de apoio. Os princípios destecapítulo são destinadas a ajudar os praticantes operação de serviço para atingirum equilíbrio entre todos estes papels e se concentrar em gerir eficazmente osaspectos do dia-a-dia, mantendo uma perspectiva de um contexto maior.ITIL V3 - Operação de Serviço - Página: 39 de 423
  • 40. 3,1 Funções, grupos, equipes, departamentos e divisõesA publicação Operação de Serviço usa vários termos para referir-se a maneirapela qual as pessoas estão organizadas para executar processos ou atividades.Existem várias definições publicadas para cada termo e não é o propósito destapublicação para entrar no debate sobre qual é a melhor definição. Por favor,note que as definições a seguir são genéricas e não prescritivos. Eles sãofornecidos apenas a definir os pressupostos e para facilitar a compreensão domaterial. O leitor deve adaptar esses princípios para a organização práticasusado em sua própria organização.• Função: Uma função é um conceito lógico que se refere ao povo emedidas automatizadas que executam um processo definido, umaatividade ou uma combinação de processos ou atividades. Emorganizações maiores, uma função pode ser dividido e realizado pordiversos departamentos, equipes e grupos, ou pode ser incorporadodentro de uma única unidade organizacional (por exemplo, Service Desk).Em organizações menores, uma pessoa ou grupo pode executar múltiplasfunções - por exemplo, um Gestão Técnica departamento pode tambémincorporar a função de Service Desk.• Grupo: Um grupo é um número de pessoas que são, de algum modosemelhante. Nesta publicação, os grupos se referem a pessoas quedesempenham atividades semelhantes - embora eles possam trabalharem tecnologia diferente ou relatório em diferentes estruturasorganizacionais ou mesmo em empresas diferentes. Os grupos sãogeralmente não formal organização estruturas, mas são muito úteis paraa definição de processos comuns em toda a organização - eg garantir quetodas as pessoas que resolver incidentes completar a Grave incidente damesma maneira. Nesta publicação "grupo" o termo não se refere a umgrupo de empresas que pertencem a uma mesma entidade.• Equipe: Uma equipe é um tipo mais formal do grupo. Estas são aspessoas que trabalham em conjunto para alcançar um comum objetivo,Mas não necessariamente na estrutura mesma organização. Os membrosda equipe podem ser co-localizado, no trabalho ou em vários locaisdiferentes e operar virtualmente. Equipes são úteis para a colaboração,ou para lidar com uma situação de natureza temporária ou transitória.Exemplos de equipes incluem projeto equipes, aplicação desenvolvimentoequipes (geralmente composto por pessoas de várias unidades denegócios diferentes) e de incidentes ou problema resolução equipes.• Departamento: Departamentos são estruturas de organização formal queexistem para executar um conjunto específico de atividades definidas emuma base contínua. Departamentos têm uma estrutura de relatórioshierárquica com os gestores, que geralmente são responsáveis pelaexecução das atividades e também para o dia-a-dia de gestão do pessoaldo departamento.ITIL V3 - Operação de Serviço - Página: 40 de 423
  • 41. • Divisão: Uma divisão refere-se a uma série de serviços que foramagrupadas, muitas vezes por geografia ou linha de produtos. A divisão énormalmente auto-suficiente e é capaz de planejar e executar todas asatividades em um cadeia de suprimentos.• Papel: Um papel refere-se a um conjunto de comportamentos ligados ouações que são realizadas por uma pessoa da equipe ou grupo em umcontexto específico. Por exemplo, um Gestão Técnica departamento de TIpode desempenhar o papel de Gerenciamento de Problemas aodiagnosticar o causa raiz de incidentes. Este mesmo departamentotambém se podem esperar para jogar vários outros papéis em momentosdiferentes, por exemplo, pode avaliar a impacto das alterações (Gestãoda Mudança de papel), gerenciar a atuação de dispositivos sob seucontrole (papel Gerenciamento da Capacidade), etc A escopo do seupapel e que desencadeia-los a desempenhar esse papel são definidospelo relevante processo e acordado por seu gerente de linha.ITIL V3 - Operação de Serviço - Página: 41 de 423
  • 42. Alcançar 3,2 equilíbrio na Operação de ServiçoOperação de Serviço é mais do que apenas a execução repetitiva de umconjunto padrão de procedimentos ou atividades. Todos funçãos, processos eatividades são projetadas para fornecer um nível e acordado de serviços, masque tem que ser entregue em uma constante mudança ambiente.Isso forma um conflito entre a manutenção do status quo e adaptação àsmudanças do negócio e ambientes tecnológicos. Um dos papéis fundamentaisserviço de operação é, portanto, para lidar com este conflito e para alcançar umequilíbrio entre conjuntos conflitantes de prioridades.Esta seção da publicação destaca algumas das principais tensões e conflitos eidentifica como as organizações de TI podem reconhecer que eles estãosofrendo de um desequilíbrio, tendendo mais para um extremo ou outro. Eletambém proporciona algum alto nível diretrizs sobre a forma de resolver oconflito e, assim, avançar para uma abordagem de melhores práticas. Cadaconflito, portanto, representa uma oportunidade de crescimento eaperfeiçoamento.3.2.1 TI interna ver contra vista de negócios externoO conflito mais fundamental em todas as fases do ITSM Ciclo de Vida é entre avisão de TI como um conjunto de serviços de TI (a visão empresarial externo) eavisão de TI como um conjunto de tecnologia componentes (TI interna ver).• A visão externa de TI é a forma como os serviços são experimentados porsua usuários e clientes. Eles nem sempre entendem, nem se preocupamcom os detalhes do que a tecnologia é usada para gerenciar essesserviços. Todos eles estão preocupados é que os serviços sejamentregues conforme necessário e acordado.• A visão interna de TI é a maneira pela qual os componentes de TI esistemas são geridas para realizar os serviços. Desde sistemas de TI sãocomplexas e diversas, isso muitas vezes significa que a tecnologia égerida por várias equipes ou departamentos diferentes - cada um dosquais está focado em alcançar um bom atuação e disponibilidade desistemas de suas.Ambas as visões são necessárias quando a prestação de serviços. Oorganização que se concentra apenas em negócios exigências sem pensarsobre como eles estão indo entregar vai acabar fazendo promessas que nãopossam ser mantidos. A organização que se concentra apenas em sistemasinternos, sem pensar sobre quais os serviços que suportam vai acabar comserviços caros que oferecem pouco valor.ITIL V3 - Operação de Serviço - Página: 42 de 423
  • 43. O potencial para a papel conflito entre as vistas externas e internas é o resultadode muitas variáveis, incluindo o maturidade da organização, a sua gestãocultura, Sua história, etc Isso faz com que um equilíbrio difícil de conseguir, eamaioria das organizações tendem mais para um papel que o outro.Naturalmente, nenhuma organização será totalmente internamente ouexternamente focado, mas encontra-se numa posição ao longo de um espectroentre os dois. Isto é ilustrado na Figura 3.1:Figura 3.1 Atingir um equilíbrio entre o foco externo e internoA Tabela 3.1 resume alguns exemplos das características de posições extremasnas extremidades do espectro. O objetivo desta tabela é para ajudar asorganizações a identificar para não que eles estão mais próximos extrema, paraidentificar vida real cargos para os quais as organizações devem aspirar.Foco interno extrema Foco externo extremaFoco principal Desempenho e gestão deInfraestrutura de TI dispositivos,sistemas e pessoal, com poucaconsideração para o resultado finalna De serviços de TIAtingir elevados níveis de desempenhode TI serviço com pouco respeito àscomo ele é alcançadoMétricos • Foco no desempenhotécnico, sem mostrar o queisso significa para osserviços de• Interna métricas (porexemplo, a disponibilidadeda rede) informou aonegócio, em vez de serviçoatuação métricas.• Focalizar Externa Metrics semmostrar o pessoal interno comoestes são derivados ou comoeles podem ser melhorados• Pessoal interno são esperadospara elaborar as suas própriasmétricas para medir odesempenho interno.ITIL V3 - Operação de Serviço - Página: 43 de 423
  • 44. Cliente/usuárioexperiência• Alta consistência daentrega, mas apenasoferece uma porcentagemdo que a empresa precisa.• Usa um "empurrão"abordagem para a entrega,ou seja, prefere ter umconjunto padrão deserviços para todosunidade de negócioss.• Consistência pobres deentrega• "Ele consiste de boas pessoascom boas intenções, mas nemsempre pode executar • De modo reativo operação.• Usa um "pull" abordagem paraa entrega, ou seja, prefereoferecer serviçospersonalizados a pedidoOperaçõesestratégia• Operações padrão em todaa linha• Todos os novos serviçosprecisam se encaixar noatual arquitetura eprocedimentos.• Várias equipes de entrega etecnologias múltiplas• As novas tecnologias exigemabordagens novas operaçõese, muitas vezes novaOperações de TI equipes.Procedimentose manualConcentre-se puramente em comogerenciar a tecnologia, não sobrecomo o seu desempenho se refereaos serviços de TIConcentra-se principalmente sobre oque precisa ser feito e quando e menosem como isso deve ser alcançadoEstratégia decusto• A redução de custosalcançada puramente pormeio da consolidação detecnologia• Otimização de operacionalprocedimentos e recursos• Negócio impacto de custarcorte freqüentemente sóentendeu depois• Retorno sobre oInvestimento cálculos estãofocados exclusivamente naredução de custos ou"períodos de retorno.• Orçamento alocados com basena qual a unidade de negóciosé percebida a ter maiornecessidade• Unidades de negócio menosarticulados ou vocal muitasvezes têm serviços inferiorescomo não há financiamentosuficiente alocado para os seusserviços.Treinamento O treinamento é realizado como umaprendizado, onde a equipe deOperações novo tem que aprendera forma como as coisas têm de serfeitas, por que não• O treinamento é realizado emum projetoA projecto base• Não há cursos de treinamentopadrão desde operacionalprocedimentos e tecnologiaestão mudandoconstantemente.Equipe deoperações• Pessoal especializado,organizado de acordo coma especialidade técnica• Equipe de trabalho no falso• Equipe generalista, organizadoem parte de acordo com atécnica capacidade e, emparte, de acordo com a relaçãoITIL V3 - Operação de Serviço - Página: 44 de 423
  • 45. pressuposto de que arealização técnico bom é omesmo que bom clienteserviço.com unidade de negócios• Dependência de heroísmo,onde os funcionários saem desua maneira de resolverproblemas que poderiam tersido evitadas por uma melhorinterna processoes.Tabela 3.1 Exemplos de foco interno e externo extremaIsto não quer dizer que a concentração externa não é importante. Todo o pontode Serviço de Gestão de é fornecer serviços que satisfaçam as objetivos daorganização como um todo. É crítico para os serviços de estrutura em tornoclientes. Ao mesmo tempo, é possível para comprometer a qualidade deserviços por não pensar sobre como eles serão entregues.Edifício Operação de Serviço com um equilíbrio entre o foco interno e externoexige uma abordagem a longo prazo, dedicado refletida em todas as fases doServiço de ITSM Ciclo de Vida. Isso vai exigir o seguinte:• Uma compreensão de que os serviços são utilizados pela empresa e porquê.• A compreensão da importância relativa e impacto desses serviços nonegócio.• Um entendimento de como a tecnologia é utilizada para fornecer Deserviços de TIs.• Envolvimento de Operação de Serviço em Melhoria de ServiçoContinuada projetos que visam identificar formas de entregar mais,aumentar serviço qualidade e menor custar.• Procedimentos e manuais que delineiam o papel de Operações de TI emtanto a gestão da tecnologia e da entrega de serviços de TI.• Um conjunto claramente diferenciada de métricos de informar a empresasobre a realização dos objectivos de serviço, e de informar os gestores deTI na eficiência e eficácia de Operação de Serviço.• Todos a equipe de TI Operações entender exatamente como o atuaçãoda tecnologia afeta a entrega de serviços de TI e, por sua vez como estasafetam o negócio e os objetivos de negócio.• Um conjunto de serviços padrão entregue de forma consistente a todosUnidade de Negócioss e um conjunto de não-padrão (por vezespersonalizada) serviços prestados a unidades de negócios específicas -junto com um conjunto de Procedimento Operacional Padrãos (POPs)que pode satisfazer os dois conjuntos de exigências.• Acustar estratégia que visa equilibrar as exigências de diferentesunidades de negócio, com a redução de custos através da otimizaçãodisponíveis da tecnologia existente ou o investimento em novastecnologias - e um entendimento da estratégia de custo por todos osenvolvidos TI recursos.ITIL V3 - Operação de Serviço - Página: 45 de 423
  • 46. • Um valor-base, em vez de baseado em custo, Retorno sobre oInvestimento estratégia.• Envolvimento de Operações de TI pessoal no Design de Serviços eTransição de Serviço fases do ITSM Ciclo de Vida.• Entrada de e feedback para Melhoria de Serviço Continuada paraidentificar áreas onde há um desequilíbrio e os meios para identificar eaplicar melhorias.• A comunicação clara e treinamento plano para o negócio. Embora muitasorganizações são bons no desenvolvimento de planos de comunicaçãopara projetos, isso muitas vezes não se estende em sua operacional fase.3.2.2 Estabilidade em relação a capacidade de respostaNão importa o quão boa a funcionalidade é de um De serviços de TI e nãoimporta o quão bem ele foi concebido, será que vale muito menos se o serviçocomponentes não estão disponíveis ou se realizar de forma inconsistente.Isto significa que, Operação de Serviço necessidades para assegurar que aInfraestrutura de TI é estável e disponível como projetado. Ao mesmo tempo,operação de serviço precisa reconhecer que os negócios ea TI exigênciasmudar.Algumas dessas mudanças são evolutivas. Por exemplo, a funcionalidade,atuação e arquitetura de uma plataforma podem mudar ao longo de vários anos.Cada mudança traz consigo uma oportunidade de proporcionar melhores níveisde serviço para o negócio. Em mudanças evolutivas, é possível planejar a formade responder à mudança e, assim, manter a estabilidade, respondendo àsmudanças.Muitas mudanças, porém, acontecer muito rapidamente e às vezes sob extremapressão. Por exemplo, uma unidade de negócios inesperadamente ganha umcontrato que requer adicionais serviços de TI, mais capacidade e mais rápidotempo de respostas. A capacidade de responder a este tipo de mudança, semafetar outros serviços é um desafio significativo.Muitas organizações de TI não são capazes de alcançar este equilíbrio e tendema se concentrar em qualquer estabilidade da infra-estrutura de TI ou acapacidade de responder às mudanças rapidamente.ITIL V3 - Operação de Serviço - Página: 46 de 423
  • 47. Figura 3.2 Atingir um equilíbrio entre o foco na estabilidade e capacidade derespostaA Tabela 3.2 resume alguns exemplos das características de posições emextremos do espectro. O objetivo desta tabela é para ajudar as organizações aidentificar para não que eles estão mais próximos extrema, para identificar vidareal cargos para os quais as organizações devem aspirar.Foco extremo na estabilidade Foco extremo na respostaFoco principal • Tecnologia• Desenvolvimento eaperfeiçoamento de técnicasde gestão de TI e processoes.• Saída para o negócio• Concorda com asalterações necessáriasantes de determinar oque vai demorar paraentregá-los.Típico problemasexperimentadoTI pode demonstrar que estácumprindo com os POPs e Acordo deNível Operacionals (ANO), mesmoquando não há desalinhamento claropara negócios exigênciasA equipe de TI não estãodisponíveis para definir ouexecutar tarefas de rotina, porqueeles estão ocupados em projetospara novos serviçosCrescimento datecnologiaestratégia• Estratégia de crescimento combase na análise da demandaexistente na actual sistemas• Novos serviços estão resistiu eUnidade de Negócioss vezes,• Tecnologia adquirida paracada requisito de novosnegócios• Usando múltiplastecnologias e soluçõesITIL V3 - Operação de Serviço - Página: 47 de 423
  • 48. tomar posse de "seus própriossistemas para ganhar acesso anovos serviços.para soluçõessemelhantes, paraatender às necessidadesde negócios ligeiramentediferentes.A tecnologiautilizada paraentregar Deserviços de TIsA tecnologia existente ou padrão a serutilizado; serviços devem ser ajustadaspara funcionar dentro de parâmetrosexistentesMais de provisionamento.Nenhuma tentativa foi feita paramodelar a nova serviço na infra-estrutura existente. Tecnologianova e dedicada é adquirido paracada novo projetoGerenciamentoda Capacidade• Previsões com base emprojeções de corrente carga detrabalhos• Sistema atuação é mantida emníveis consistentes atravésafinação e gestão da procura,E não por previsão de cargade trabalho e gestão.• Previsões com base emnegócios futuros atividadepara cada serviçoindividualmente e nãolevam em conta aatividade de TI ou outrosserviços de TI• Cargas de trabalhoexistentes não sãorelevantes.Tabela 3.2 Exemplos de extremo foco na estabilidade e capacidade de respostaA construção de uma TI organização que alcança um equilíbrio entre aestabilidade e capacidade de resposta em Operação de Serviço exigirá asseguintes ações:• Garantir o investimento em tecnologias e processos que são adaptativasao invés de rígida, por exemplo, virtual servidor e aplicação tecnologia eda utilização de Mudança do modelos (ver Transição de Serviçopublicação).• Construir uma forte Gerenciamento de Nível de Serviço (SLM) processoque está ativo a partir do Design de Serviços fase para a Melhoria deServiço Continuada fase do ITSM Ciclo de Vida.• Promover a integração entre SLM e os processos de design de outrosserviços para garantir mapeamento adequado de requisitos de negóciopara TI operacional actividades e componentes da Infraestrutura de TI.Isso torna mais fácil para modelar o efeito de mudanças e melhorias.• Iniciar mudanças na primeira fase apropriada no Ciclo de Vida de ITSM.Isso irá garantir que tanto funcional (de negócios) e capacidade degerenciamento (TI operacional) exigências pode ser avaliado e construídoou alterado juntos.• Garantir o envolvimento da TI no negócio muda tão cedo quanto possívelno mudar processo para assegurar escalabilidade, Consistência ecapacidade de concretização de De serviços de TIs sustentar mudançasde negócios.ITIL V3 - Operação de Serviço - Página: 48 de 423
  • 49. • Operação de Serviço equipes devem fornecer informações para o cursoprojeto e refinamento da arquiteturas e serviços de TI (ver Design deServiços e Serviço de publicações estratégia).• Implementar e usar SLM para evitar situações onde os negócios e osgerentes de TI e pessoal de negociar informal acordos.3.2.3 A qualidade do serviço versus custo do serviçoOperação serviço é necessário para entregar consistentemente o nível acordadode serviços de TI para a sua clientes e usuários, enquanto que, ao mesmotempo mantendo custars e recurso utilização em um nível ideal.Figura 3.3 representa o investimento realizado para entregar um serviço emníveis crescentes de qualidade.Figura 3.3 a qualidade do serviço de balanceamento e custoNa Figura 3.3, um aumento do nível de qualidade geralmente resulta em umaumento no custo do serviço, e vice-versa. No entanto, o relação nem sempre édiretamente proporcional:• Logo no início do serviço de ciclo de vida é possível conseguir aumentossignificativos na qualidade de serviço, com uma quantidade relativamentepequena de dinheiro. Por exemplo, melhorar o serviço disponibilidade de55% para 75% é bastante simples e não pode exigir um investimentoenorme.• Mais tarde no ciclo de vida do serviço, mesmo pequenas melhorias naqualidade são muito caros. Por exemplo, melhorar a disponibilidade doITIL V3 - Operação de Serviço - Página: 49 de 423
  • 50. mesmo serviço de de 96% para 99,9% pode exigir grandes investimentosem tecnologia de alta disponibilidade e pessoal de apoio e ferramentas.Embora isso possa parecer simples, muitas organizações estão sob fortepressão para aumentar a qualidade do serviço e reduzir os seus custos. NaFigura 3.3, a relação entre custo e qualidade às vezes é inversa. É possível(normalmente dentro da gama de optimização) para aumentar a qualidade ereduzir custos. Isto é normalmente iniciado dentro de Operação de Serviço etransportados por Melhoria de Serviço Continuada. Alguns custos podem serreduzidos gradualmente ao longo do tempo, mas as economias mais custospode ser feita apenas uma vez. Por exemplo, uma vez que uma ferramenta desoftware duplicado foi eliminada, não pode ser eliminada de novo para reduçãode custos adicionais.Alcançar um equilíbrio ideal entre custar e qualidade (mostrado entre as linhaspontilhadas na Figura 3.3) é uma chave papel de Serviço de Gestão de. Não háindústria padrão para o que este intervalo deve ser, uma vez que cada serviçoterá uma gama diferente de optimização, dependendo da natureza do serviço edo tipo de objetivo de negócio sendo atendidas. Por exemplo, a empresa podeestar preparado para gastar mais para alcançar alta disponibilidade em umserviço de missão crítica, enquanto ele está preparado para conviver com abaixa qualidade de uma ferramenta administrativa.Determinar o equilíbrio de custo e de qualidade deve ser feito durante oEstratégia de Serviço e Design de Serviços Ciclo de Vida fases, embora emmuitas organizações é deixada para o Operação de Serviço equipes - muitosdos quais não têm, geralmente, todos os fatos ou a autoridade para ser capazde fazer este tipo de decisão.Infelizmente, também é comum encontrar organizações que estão gastandograndes quantidades de dinheiro, sem realização de quaisquer melhorias clarasna qualidade. Novamente, Melhoria de Serviço Continuada será capaz deidentificar a causa da ineficiência, avaliar o equilíbrio ideal para esse serviço eformular um corretivo plano.Atingir o equilíbrio correto é importante. Foco muito em qualidade resultará emDe serviços de TIs que oferecem mais do que o necessário, a um custo maior, epode levar a uma discussão sobre a redução do preço dos serviços. Foco muitono custo resultará em TI entrega ou sob orçamento, Mas colocar o negócio emrisco através de sub-padrão de serviços de TI.Nota especial: o quão longe é demais?Ao longo dos últimos anos, as organizações de TI estão sob pressão para cortarcustos. Em muitos casos, isto resultou em otimizard e custos qualidade. Mas,noutros casos, os custos foram reduzidos até ao ponto em que passou aITIL V3 - Operação de Serviço - Página: 50 de 423
  • 51. padecer de qualidade. Na primeira, os sinais eram sutis - pequenos aumentosde incidente resolução vezes e um ligeiro aumento no número de incidentes.Com o tempo, porém, a situação se tornou mais grave como o pessoaltrabalhava longas horas para lidar com múltiplas carga de trabalhos serviços ecorreu em infra-estrutura envelhecida ou ultrapassada.Não há cálculo simples para determinar quando os custos foram cortados longedemais, mas SLM bom é crucial para a tomada clientes conscientes da impactode corte muito longe, tão reconhecer esses sinais e sintomas podem melhorarmuito a organizaçãoCapacidade s para corrigir esta situação.Exigência de Nível de Serviços - juntamente com uma compreensão clara doobjeto social da serviço e os riscos potenciais - vai ajudar a garantir que oserviço é entregue ao custo adequado. Eles também ajudam a evitar"superdimensionamento" do serviço simplesmente porque o orçamento estádisponível, ou "sob dimensionamento", porque a empresa não entender ogerenciamento exigências da solução. Ou resultado fará com que a insatisfaçãodo cliente e despesa ainda mais quando a solução é re-engenharia ou retro-equipada com os requisitos que deveriam ter sido especificados durante aDesign de Serviços.Figura 3.4 Atingir um equilíbrio entre o foco no custo e qualidadeTabela 3.3 apresenta alguns exemplos das características de posições em ladosextremos do espectro de custo / qualidade. O objetivo desta tabela é para ajudaras organizações a identificar para não que eles estão mais próximos extrema,para identificar vida real cargos para os quais as organizações devem aspirar.Extremo foco na qualidade Foco extremo no custoFoco principal Cumprindo o nível de qualidade exigidopela empresa, independentemente doReunião orçamento e reduzindocustarsITIL V3 - Operação de Serviço - Página: 51 de 423
  • 52. que é precisoTípicoproblemasexperimentado• Orçamentos crescentes• De serviços de TIs geralmenteentregar mais do que énecessário para o sucesso donegócio• Crescentes exigências demaiorqualidade serviços.• Ele limita a qualidade deserviço com base no seuorçamento disponibilidade• Escaladas da empresapara obter mais serviçosde TI.GestãoFinanceiraEle geralmente não tem um método decomunicação do custo de serviços deTI. Contabilidade métodos baseiam-senum método de agregados (porexemplo, custo de TI por usuário).O relatório financeiro é feitopuramente em valoresorçamentados. Não há nenhumamaneira de ligar as atividades deTI para a entrega de serviços deTI.Tabela 3.3 Exemplos de extremo foco na qualidade e custoAlcançar um equilíbrio irá garantir a entrega do nível de serviço necessário paraatender negócios exigências a uma óptima (em oposição a menor possível) ocusto. Isso vai exigir o seguinte:• Um processo de Gestão Financeira e ferramentas que podem esclarecero custo da prestação de serviços de TI, e qual o modelo de métodosalternativos de prestação de serviços em diferentes níveis de custo. Porexemplo, comparando o custo de fornecimento de um serviço dedisponibilidade de 98% ou menos 99,9% de disponibilidade, ou o custo daprestação de um serviço com ou sem funcionalidade adicional.• Assegurar que as decisões em torno custo versus qualidade são feitaspelos gestores adequadas durante Estratégia de Serviço e Design deServiços. TI operacional gerentes não são geralmente equipados paraavaliar oportunidades de negócios e só deve ser solicitado a tomardecisões financeiras que estão relacionadas a alcançar a eficiênciaoperacional.3.2.4 reativa contra proativoUm reactivo organização é aquele que não age a menos que seja solicitado afazê-lo por uma externa motorista, E.g. um requisito de negócio novo, umaaplicação que tem sido desenvolvido ou escalada em reclamações feitas porusuários e clientes. Uma triste realidade em muitas organizações é o foco nagestão reactiva erroneamente como o único meio para assegurar serviços quesão altamente consistente e estável, ativamente desencorajar comportamentopró-ativo da equipe operacional. A ironia infeliz desta abordagem é que oinvestimento em esforço desanimador proativo Serviço de Gestão de pode,finalmente, aumentar o esforço e custo das atividades reativas e mais riscoestabilidade e consistência nos serviços.ITIL V3 - Operação de Serviço - Página: 52 de 423
  • 53. Uma organização pró-ativa está sempre procurando maneiras de melhorar asituação atual. Ele continuamente varredura interna e externa ambientes,procurando sinais de potencialmente impactar mudanças. Comportamento pró-ativo é geralmente visto como positivo, especialmente uma vez que permite quea organização para manter a vantagem competitiva em um ambiente emmudança. No entanto, ser muito activa podem ser caros e podem resultar empessoal ser distraído. A necessidade de equilíbrio no comportamento reativo eproativo consegue muitas vezes o resultado ideal.Geralmente, é melhor para gerenciar serviços de TI de forma proativa, masconseguir isso não é facilmente planejado ou alcançado. Isto porque aconstrução de uma organização de TI pró-ativa é dependente de muitasvariáveis, incluindo:• O maturidade do organização. Quanto mais tempo a organização foientregar um conjunto consistente de De serviços de TIs, o mais provávelé entender a relação entre a TI e os negócios ea Infraestrutura de TI eserviços de TI.• O cultura da organização. Algumas organizações têm uma cultura queestá focada na inovação e são mais propensos a ser proativo. Outros sãomais propensos a se concentrar sobre o status quo e, como tal, sãosusceptíveis de resistir mudar e ter mais foco reativo.• O papel que a TI desempenha no negócio e do mandato que a TI tem deinfluenciar o estratégia e táticas da empresa. Por exemplo, uma empresaonde o CIO é um membro do conselho é provável que tenha umaorganização de TI que é muito mais pró-ativo e ágil do que uma empresaonde a TI é vista como um administrativo despesas gerais.• O nível de integração de processos e ferramentas de gestão. Níveissuperiores de integração vai facilitar um melhor conhecimento dasoportunidades.• A maturidade e escopo de Gestão do Conhecimento na organização, oque é visto especialmente em organizações que têm sido capazes dearmazenar e organizar dados históricos de forma eficaz - especialmenteDisponibilidade e Gerenciamento de Problemas dados.De uma perspectiva de maturidade, é claro que as organizações mais novasterão prioridades diferentes e experiências de uma organização maisestabelecida - o que é melhores práticas para uma organização madura nãopode atender um jovem organização. Portanto, um desequilíbrio pode resultar deuma organização ou ser menos ou mais maduro. Considere o seguinte:• Organizações menos maduras (ou organizações com novos serviços deTI ou tecnologia), geralmente, mais reativa, simplesmente porque elesnão sabem todas as variáveis envolvidas na execução de seus negóciose oferecer serviços de TI.ITIL V3 - Operação de Serviço - Página: 53 de 423
  • 54. • A equipe de TI em organizações mais recentes tendem a ser generalistasporque não está claro exatamente o que é necessário para entregarestáveis serviços de TI para o negócio.• Incidentes e problemas em organizações mais novas são bastanteimprevisíveis, pois a tecnologia é relativamente nova e mudançasrapidamente.• Organizações mais maduras tendem a ser mais pró-ativa, simplesmenteporque têm mais dados e relatórios disponíveis e conhecer os padrõestípicos de incidentes e fluxos de trabalho. Assim, eles prevêem exceçõesmuito mais facilmente.• O pessoal que trabalha em organizações maduras também geralmentetendem a ter relacionamentos mais estáveis entre a equipe de TI e osnegócios e por isso pode ser mais proativo sobre o encontro de negóciosem constante mudança exigências - isto é especialmente verdadeiroquando a TI é vista como um estratégico componente do negócio.Figura 3.5 Atingir um equilíbrio entre ser muito reativa ou proativa tambémITIL V3 - Operação de Serviço - Página: 54 de 423
  • 55. A Tabela 3.4 resume alguns exemplos das características de posições emextremos do espectro. O objetivo desta tabela é para ajudar as organizações aidentificar para não que eles estão mais próximos extrema, para identificar vidareal cargos para os quais as organizações devem aspirar.Extremamente reativo Extremamente proativaFoco principal Responde às necessidades denegócios e incidentes só depois queeles são relatadosAntecipa negócios exigênciasantes de serem comunicados eproblemas antes que elas ocorramOs problemastípicosexperimentado• Preparando-se para oferecernovos serviços leva um longotempo, porque cada projeto étratado como se fosse oprimeiro• Incidentes similares ocorramnovamente e de novo, comonão há nenhuma maneira detendências los• Rotatividade de pessoal é altaeo moral é geralmente baixo,como a equipe de TI semanter em movimento deprojeto para projeto, semalcançar um conjunto,duradouras estável de Deserviços de TIs• Dinheiro é gasto antes queos requisitos sãodemonstrados. Em algunscasos em que compraitens que nunca serãousados porque antecipouas exigências erradas ouporque o projeto estáparado• A equipe de TI tendem ater estado no organizaçãopor um longo tempo etendem a assumir que elessabem os requisitos denegócio melhor do que aempresa fazPlanejamento deCapacidadeEspere até que haja capacidadeproblemas e, em seguida, adquirir acapacidade excedente para durar atéque o incidente relacionado com acapacidade próximaAntecipar problemas decapacidade e gastar dinheiro emprevenção estes - mesmo quandoo cenário é improvável que issoaconteçaPlanejamento daContinuidade dosServiços de TI• Não planos existir até depoisde um grande evento oudesastre• Ela planeja foco narecuperação de chavesistemas, mas sem garantirque a empresa pode recuperarseus processosOver-planejamento (E sobre osgastos) de TI Opção derecuperaçãos. Geralmenterecuperação imediata é fornecidopara a maioria De serviços de TIs,independentemente da suaimpacto ou prioridadeGestão daMudança• As alterações são muitasvezes não registrado, ouregistrado no último minuto,como Mudança deemergências• Não é tempo suficiente para oimpacto adequada e custaravaliaçãosAs alterações são solicitados eaplicado mesmo quando nãoexiste uma necessidade real, istoé, uma quantidade significativa detrabalho para fixar os artigos quenão são quebradosITIL V3 - Operação de Serviço - Página: 55 de 423
  • 56. • As alterações são poucoestudado e controlado, o queresulta num elevado númerode incidentesTabela 3.4 Exemplos de comportamento extremamente reativo e proativoEmbora o comportamento pró-ativo em Operação de Serviço geralmente é bom,também há momentos em que o comportamento reativo é necessário. O papelde Operação de Serviço é, portanto, para alcançar um equilíbrio entre ser reativae pró-ativa. Isso vai exigir:• Formal Gerenciamento de Problemas e Gerenciamento de Incidentesprocessos, integrada entre Operação de Serviço e Melhoria de ServiçoContinuada.• A habilidade de ser capaz de priorizar falhas técnicas, bem como asdemandas de negócios. Isso precisa ser feito durante a operação deserviço, mas os mecanismos precisam ser postas em prática duranteEstratégia de Serviço e Design. Estes mecanismos podem incluircategorização incidente sistemas, escalada procedimentos e ferramentaspara facilitar impacto avaliação para mudanças.• Dados de configuração e Gestão de Ativos para fornecer dados, quandonecessário, economizando projetos do tempo e tomar decisões maisprecisas.• Participação permanente do SLM na Operação de Serviço.ITIL V3 - Operação de Serviço - Página: 56 de 423
  • 57. 3,3 prestação de serviçosTodo o pessoal Operação de Serviço devem estar plenamente conscientes deque eles estão lá para "prestar serviço" para o negócio. Eles devem fornecer umoportuno (resposta rápida e entrega rápida dos exigências), profissional e cortêsserviço para permitir que a empresa para realizar suas próprias atividades - deforma que o comercial clienteS necessidades são satisfeitas eo negócioprospera.É importante que os funcionários são treinados não apenas em como entregar eapoiar De serviços de TIs, mas também na forma em que o serviço a serfornecido. Por exemplo, funcionários que são capazes e prestar serviços deforma eficaz ainda pode causar insatisfação do cliente significativo se eles sãoinsensíveis ou de desprezo. Por outro lado, nenhuma quantidade de seragradável para um cliente irá ajudar se o serviço não está sendo entregue.Um elemento crítico de ser proficiente provedor de serviços está a colocar tantaênfase no recrutamento e treinamento de pessoal para desenvolver competênciaem lidar com clientes e gestão relaçãos e interações como eles fazem emcompetências técnicas para a gestão de TI ambiente.ITIL V3 - Operação de Serviço - Página: 57 de 423
  • 58. 3,4 a participação do pessoal de operação em Design deServiços e Transição de ServiçoÉ extremamente importante que o pessoal de operação de serviço estãoenvolvidas em Design de Serviços e Transição de Serviço e, potencialmente,também na Estratégia de Serviço, onde apropriado.Uma chave para alcançar o equilíbrio na Operação de Serviço é um conjuntoeficaz de processos de design de serviço. Estes proporcionarão TI Gestão deOperações com:• Definição clara de serviço de TI objetivos e atuação critérios• Ligação de serviço de TI especificaçãos para o desempenho doInfraestrutura de TI• Definição de operacional requisitos de desempenho• Um mapeamento de serviços e tecnologia• A capacidade de modelar o efeito de mudanças na tecnologia emudanças para as empresas exigências• Apropriado custar modelos (por exemplo, cliente ou serviço baseado)para avaliar o retorno do investimento e redução de custos estratégias.A natureza do TI Gestão de Operações envolvimento deve ser cuidadosamenteposicionadas. Design de Serviços é uma fase na Serviço de Gestão de Ciclo deVida utilizando um conjunto de processos, e não um função independente daoperação do serviço. Como tal, muitas das pessoas que estão envolvidas emDesign de Serviços virá de TI Gestão de Operações.Isso não só deve ser incentivado, mas Operação de Serviço pessoal deve sermedido em seu envolvimento em atividades de design de serviço - e taisatividades devem ser incluídas no descrição do trabalhos e papels, etc Isto iráajudar a assegurar a continuidade entre os requisitos de negócios e tecnologiaprojeto e operação e que também irá ajudar a assegurar que o que é concebidatambém pode ser operado. Operações de TI equipe de Gestão também devemser envolvidos durante Transição de Serviço para garantir a consistência e paragarantir que o negócio declarado e capacidade de gerenciamento sãocumpridos.Recursos devem estar disponíveis para estas actividades e o tempo requeridodeve ser levado em conta, se for caso dissoITIL V3 - Operação de Serviço - Página: 58 de 423
  • 59. 3,5 Saúde OperacionalMuitas organizações acham que é útil para comparar a monitoramento econtrolar de Operação de Serviço de vigilância da saúde e de controle.Neste sentido, o Infraestrutura de TI é como um organismo que tem sinais vitaisque podem ser monitorados para verificar se ele está funcionando normalmente.Isto significa que não é necessário monitorizar continuamente semprecomponente de cada TI sistema para assegurar que este está a funcionar.Saúde operacional pode ser determinado através do isolamento de algumasimportantes "sinais vitais" em dispositivos ou serviços que são definidas comoessenciais para a boa execução de um Função de Negócios Vital. Esta poderiaser a utilização de largura de banda de um segmento de rede, ou a utilização damemória em uma grande servidor. Se estes sinais estão dentro dos limitesnormais, o sistema é saudável e não necessita de maior atenção. Esta reduçãona necessidade de monitorização extensa resultará em redução de custos eoperacional equipes e departamentos que estão focados em áreas apropriadaspara serviço sucesso.No entanto, tal como com os organismos, é importante para verificar a sistemasmais minuciosamente ao longo do tempo, para verificar se há problemas quenão afetam imediatamente os sinais vitais. Por exemplo, um disco pode estarfuncionando perfeitamente, mas poderia estar chegando ao Tempo médio entrefalhas (MTBF) limiar. Neste caso, o sistema deve ser retirado de serviço e dadoum exame completo ou "exame de saúde". Ao mesmo tempo, deve sublinhar-seque o resultado final deve ser o funcionamento saudável do serviço como umtodo. Isto significa que exames de saúde sobre os componentes deve serequilibrada contra cheques de serviço o "fim-a-fim". A definição do que precisaser monitorado e que é saudável em relação saudável é definida durante aDesign de Serviços, especialmente Gerenciamento de Disponibilidade e SLM.Saúde operacional é dependente da capacidade de prevenir incidentes eproblemas, investindo em infra-estrutura confiável e de fácil manutenção. Isto éconseguido através de boas disponibilidade projeto e Gerenciamento deProblemas pró-ativa. Ao mesmo tempo, Health operacional é tambémdependente da capacidade de identificar falhas e localizá-los de forma eficaz, demodo que eles têm um mínimo impacto sobre o serviço. Isso requer Incident (depreferência automático) forte e Gerenciamento de Problemas.A idéia de Saúde Operacional também levou a uma área especializada chamada"Sistemas de auto-cura. Trata-se de um aplicação de gerenciamento dedisponibilidade, capacidade, conhecimento de Incidentes e Problemas e refere-se a um sistema que foi concebido para suportar as condições operacionaismais severas e para detectar, diagnosticar e recuperar a maioria dos incidentese Erro Conhecidos. Sistemas de auto-cura são conhecidos por nomesITIL V3 - Operação de Serviço - Página: 59 de 423
  • 60. diferentes, por exemplo, sistemas autônomos, sistemas adaptativos e SistemasDinâmicos. Características dos sistemas de auto-cura incluem:• Resiliência é projetado e construído para o sistema, por exemplo, váriosdiscos redundantes ou processadores de múltiplos. Isso protege osistema contra hardware falha uma vez que é capaz de continuar afuncionar, utilizando o hardware repetido componente.• Software, dados e resiliência do sistema operacional também é projetadopara o sistema, por exemplo, bancos de dados espelhado (onde umbanco de dados é duplicado em um apoio dispositivo) e disco stripingtecnologia (onde pedaços individuais de dados são distribuídos atravésde uma matriz de disco - de modo que resulta uma falha no disco deperda de apenas uma parte dos dados, que pode ser facilmenterecuperado usando algoritmos).• A capacidade de deslocar processamento de um dispositivo físico paraoutro, sem qualquer interrupção do serviço. Esta poderia ser umaresposta a uma falha ou porque o dispositivo está a atingir níveis deutilização elevados (alguns sistemas são projetados para distribuir oprocessamento carga de trabalhos de forma contínua, para fazer o melhoruso disponível capacidade, O qual também é conhecido comovirtualização).• Embutido monitoramento utilitários que permitem que o sistema paradetectar eventos e para determinar se estes representam normaisoperaçãos ou não.• Um mecanismo de correlação (ver parágrafo 4.1.5.6 em Gestão deEventos). Isto irá permitir que o sistema para determinar o significado decada evento e também para determinar se há qualquer resposta a esseevento predefinido.• Um conjunto de ferramentas de diagnóstico, tais como script dediagnósticos, falta de árvores e uma base de dados de Erro Conhecidos ecomum solução alternativas. Estes são utilizados tão logo um erro fordetectado, para determinar a resposta adequada.• A capacidade de gerar um chamar por intervenção humana, gerando umaalertar ou a geração de um incidente.Embora o conceito de Saúde Operacional não é um conceito central doOperação de Serviço, Muitas vezes é uma metáfora útil para ajudar a determinaro que precisa ser monitorado e freqüência para realizar a manutençãopreventiva.O que e quando para monitorar operacional saúde deve ser determinado emDesign de Serviços, Testado e aperfeiçoado durante Transição de Serviço eotimizard em Melhoria de Serviço Continuada, Conforme necessário.ITIL V3 - Operação de Serviço - Página: 60 de 423
  • 61. 3,6 ComunicaçãoUma boa comunicação é necessária com outras equipes de TI e departamentos,com usuários e clientes internos, e entre as equipes de serviço de operação edepartamentos próprios. Questões muitas vezes pode ser evitado ou atenuadocom comunicação adequada.Esta seção tem como objetivo resumir a comunicação que deve ocorrer emoperação de serviço. Esta não é uma separada processo, Mas uma lista deverificação do tipo de comunicação que é necessário para a operação de serviçoeficaz.Um princípio importante é que toda a comunicação deve ter uma finalidade ouuma acção resultante. As informações não devem ser comunicados a menosque haja um público claro. Além disso, esse público deveria ter se envolvidoativamente na determinação da necessidade de que a comunicação eo que elesvão fazer com a informação.Uma descrição mais detalhada dos tipos de comunicação típico em operação deserviço está contida no Apêndice B da presente publicação, em conjunto comuma descrição da audiência típica e as acções que se destinam a ser tomadascomo resultado de cada comunicação. Estes incluem:• Rotina operacional comunicação• A comunicação entre deslocars• Relatórios de desempenho• Comunicação em projetos• Comunicação relacionada com alterações• Comunicação relacionada com exceções• Comunicação relacionada a emergências• Treinamento sobre processos novos ou personalizado e design deserviços• Comunicação de estratégia e design para Operação de Serviço equipes.Por favor, note que não há meio de comunicação definitivo, nem existe um localfixo ou de freqüência. Em algumas organizações de comunicação tem queocorrer nas reuniões. Outras organizações preferem usar e-mail ou acomunicação inerente à sua Serviço de Gestão de ferramentas.Assim, deverá ser um política em torno da comunicação dentro de cada equipeou departamento e para cada processo. Embora este deve ser formal, a políticanão deve ser complicado ou complexo. Por exemplo, um gerente pode exigir quetodas as comunicações relativas a mudanças devem ser enviadas por e-mail.Enquanto isso é especificado em POPs do departamento (em qualquer formaque eles existem), não há necessidade de criar uma política separada para ele.ITIL V3 - Operação de Serviço - Página: 61 de 423
  • 62. Embora o conteúdo típico de comunicação é bastante consistente uma vez osprocessos foram definidos, os meios de comunicação estão mudando a cadanova introdução da tecnologia. A lista de alternativas está crescendo e, hoje,inclui:• E-mail, ao tradicional clientes ou dispositivos móveis• Mensagens SMS• Pagers• Mensagens instantâneas e web-based chats• Voz sobre Protocolo de Internet (VoIP) utilitários que podem transformarqualquer dispositivo conectado a um meio de comunicação de baixo custo• Utilitários reunião por teleconferência e virtuais, revolucionaram reuniõesque estão agora realizadas através de longas distâncias• DocumentoDe partilha de serviços públicos.Os meios de comunicação em si está fora do escopo desta publicação. Noentanto, os seguintes pontos devem ser observados:• A comunicação é fundamental e os meios de comunicação devemgarantir que eles servem este objetivo. Por exemplo, a necessidade parauma comunicação segura pode eliminar a possibilidade de alguns dosmeios acima referidos. A necessidade de qualidade pode eliminaralgumas opções de VoIP.• É possível utilizar qualquer meio de comunicação, desde que todos daspartes interessadass compreender como e quando a comunicaçãoocorrerá.3.6.1 ReuniõesOrganizações diferentes formas de comunicação diferentes. Onde asorganizações são distribuídos, eles tendem a confiar em e-mail e instalações deteleconferência. Organizações que possuem processos de serviços maismaduros e ferramentas de gestão tendem a confiar nas ferramentas e processosde comunicação (por exemplo, usando um Gerenciamento de Incidentesferramenta para aumentar e acompanhar incidentes, em vez de solicitar e-mailou telefone para chamadas de atualizações).Outras organizações preferem se comunicar utilizando reuniões. No entanto, éimportante não entrar no modo pelo qual o trabalho a tempo só é feito, ou degestão está envolvido, é durante uma reunião. Além disso, face-a-face tendem aaumentar custars (por exemplo, o tempo de viagem, passou em discussõesinformais, bebidas, etc), assim que os organizadores da reunião deve equilibraro valor da reunião com o número ea identidade dos participantes e do tempoque eles passam, e chegar, a reunião.ITIL V3 - Operação de Serviço - Página: 62 de 423
  • 63. O propósito das reuniões é comunicar de forma eficaz para um grupo depessoas sobre um conjunto comum de objetivos ou atividades. As reuniõesdevem ser bem controlada e breve, eo foco deve ser a facilitar a acção. Umaboa regra é não realizar uma reunião, se a informação pode ser comunicada deforma eficaz por meios automáticos.Uma série de fatores são essenciais para o sucesso de reuniões. Embora estespossam parecer senso comum, às vezes são negligenciados:• Estabelecer e comunicar uma agenda clara para garantir que a reuniãoatinge seu objetivo e ajudar o facilitador evitar participantes de oi-jacking"da reunião.• Assegurar que as regras para participar são compreendidos. Asorganizações tendem a ter um conjunto formal de regras de reuniões, quevariam de relativamente informal para muito formal (por exemplo, regrasRoberts da Ordem).• Fazer uso de estacionamentos ou notas que registro questões que nãosão diretamente relevantes para o objetivo da reunião, mas que podemser chamados em caso de necessidade de discussão surge.• Ata da reunião: as regras devem ser definidas sobre quando os minutossão tomadas. Minutos são utilizados para lembrar as pessoas que estãoatribuídas ações e acompanhar o andamento das ações delegadas. Elestambém são úteis para garantir que multifuncionais decisões e ações sãoacompanhadas e seguidas por.• Use técnicas para incentivar o nível adequado de participação. Umatécnica ao discutir melhorias, por exemplo, é a "manter, parar, começar atécnica. Os participantes são encorajados a lista de itens que elesgostariam de manter, coisas que precisam ser parado e iniciativas ouações que eles gostariam de ver iniciada.Exemplos de reuniões típicos são apresentados a seguir:3.6.1.1 A reunião de OperaçõesReuniões operações são normalmente realizadas entre os gestores da TIoperacional departamentos, equipes ou grupos, no início de cada dia de trabalhoou semana. O objetivo deste tipo de reunião é fazer com que o pessoal ciente dequalquer assunto relevante para Operações (como alteração de horários, osnegócios eventos, programas de manutenção, etc) e dar uma oportunidade parao pessoal para levantar quaisquer questões de que tenham conhecimento. Estaé uma oportunidade para assegurar que todos os departamentos de um centrode dados são sincronizados.Em organizações geograficamente dispersas, pode não ser possível ter umaúnica reunião de Operações diária. Nestes casos, é importante para coordenar aagenda das reuniões e assegurar que cada reunião tem dois componentes:ITIL V3 - Operação de Serviço - Página: 63 de 423
  • 64. 1. A primeira parte da reunião vai cobrir aspectos que se aplicam aoorganização como um todo, por exemplo, novas políticas, mudanças queafetam todas as regiões e negócios eventos que abrangem todas asregiões.2. A segunda parte da reunião vai cobrir aspectos que se aplicam apenas àregião local, por exemplo, local operaçãohorários s, as mudanças deequipamento local, etcA reunião de Operações geralmente é presidido pelo Operações de TI Gerenteou um gerente de operações sênior e com a participação de todos os gerentes esupervisores (exceto aqueles cujos deslocars não estão em serviço). Também éútil ter pelo menos um representante do Service Desk na reunião, de modo queeles estão cientes de todas as situações que podem dar origem a incidentes.Oportunidades para melhorar os serviços ou processos devem ser capturados,se levantou, e encaminhado para a equipe responsável pela Melhoria de ServiçoContinuada.3.6.1.2 Departamento reuniões de grupo ou equipeEstas reuniões são essencialmente o mesmo que o encontro de Operações,mas destinam-se a um grupo de TI único departamento ou equipe. Cada gerenteou supervisor transmite a informação a partir da reunião de Operações que érelevante para a sua equipe.Além disso, estas reuniões também abranger o seguinte:• Uma discussão mais detalhada de incidentes, problemas e as mudançasque ainda estão sendo trabalhados, com informações sobre:• Progredir até à data• A confirmação de que ainda precisa ser feito• Tempo estimado para conclusão• Pedido de adicional recursos, se for necessário• Discussão de possíveis problemas ou preocupações• A confirmação da equipe disponibilidade para deveres roster• Confirmação de horários de férias.3.6.1.3 reuniões com clientesDe tempos em tempos, será necessário a realização de reuniões com clientes,independentemente do nível de serviço regular Comente reuniões. Os exemplosincluem:• Acompanhamento após incidentes graves. O objectivo destas reuniões épara reparar o relação com os clientes, mas também para garantir que eletenha todas as informações necessárias para evitar a recorrência. OsITIL V3 - Operação de Serviço - Página: 64 de 423
  • 65. clientes também têm a oportunidade de fornecer informações sobre onegócio imprevisto impactos. Estas reuniões são úteis em concordarações para os tipos semelhantes de incidentes que podem ocorrer nofuturo.• Um forum cliente, que pode ser usado para uma variedade de finalidades,incluindo testes de ideias para novos serviços ou soluções, ou reunindoexigências para serviços novos ou revista ou procedimentos. Um fórumcliente é geralmente um encontro regular com os clientes para discutiráreas de interesse comum.ITIL V3 - Operação de Serviço - Página: 65 de 423
  • 66. 3,7 DocumentaçãoTI Gestão de Operações e todas as técnicas e Aplicação de Gestão de equipese departamentos estão envolvidos na criação e manutenção de uma série dedocumentos. Estes são detalhados nos capítulos 4, 5 e 6 da presente publicaçãoe incluem o seguinte:• Participação na definição e manutenção de processo manuais para todosos processos em que estão envolvidos dentro Estes irão incluir processosem outras fases do IT Service Management Ciclo de Vida (E.g.Gerenciamento da Capacidade,Gestão da Mudança,Gerenciamento deDisponibilidade), Bem como para todos os processos que fazem parte daOperação de Serviço fase.• Estabelecer a sua própria técnica procedimentomanuais s. Estes devemser mantidos atualizados e novo material deve ser adicionado comotorna-se relevante, sob controle de alterações. Deve ser lembrado que osseus procedimentos devem sempre ser estruturada de forma a satisfazero objetivos e constrangimentos definidos no nível mais alto Serviço deGestão de processos, tais como SLM. Por exemplo, um procedimentotécnico para o gerenciamento de servidors deve sempre garantir que visaalcançar o disponibilidade e atuação níveis acordados no Acordo de NívelOperacionals e Acordo de Nível de Serviços (SLAs).• Participação na criação e manutenção de planejamento documentos, porexemplo, e Capacity Plano de disponibilidades e a TI Plano deContinuidade do Serviços.• Participação na criação e manutenção do Portfólio de Serviços. Issoincluirá a quantificação custars e que institui a operacional viabilidade decada proposta serviço.• Participação na definição e manutenção da ferramenta de Gestão deServiços instrução de trabalhos, a fim de satisfazer relatório exigênciasITIL V3 - Operação de Serviço - Página: 66 de 423
  • 67. 4 Operação processos de serviçoOs processos listados no ponto 2.4.5 são discutidos em detalhe neste capítulo.Como referência, a estrutura geral é brevemente descrito aqui e, em seguida,cada um dos processos é descrito em mais detalhe mais adiante no capítulo.Por favor, note que o papels para cada processo e as ferramentas utilizadaspara cada processo são descritos nos capítulos 6 e 7, respectivamente.• Gestão de Eventos é o processo que monitoriza todos os acontecimentosque ocorrem através do Infraestrutura de TI para permitir o normal,operação e também para detectar e aumentar as condições de excepção.• Gerenciamento de Incidentes concentra-se o serviço para restaurarusuários o mais rapidamente possível, a fim de minimizar a actividadeimpacto.• Gerenciamento de Problemas envolve análise de causa raiz paradeterminar e resolver a causa de eventos e incidentes, atividades pró-ativas para detectar e prevenir futuros problemas / incidentes e um ErroConhecido sub-processo para permitir o rápido diagnóstico e resolução senovos incidentes ocorrem.NOTA: Sem essa distinção entre incidentes e problemas, e manter incidenteseparado e Grave problemas, existe o perigo de que:• Incidentes será fechado também no início do ciclo de suporteglobal e não haverá ações tomadas para prevenir a reincidência -de modo que os mesmos incidentes terão de ser fixado e outravez, ou• Incidentes será mantida aberta para que análise de causa raizpode ser feito e visibilidade será perdido quando o de usuárioSserviço era, na verdade restaurard - metas de SLA para que nãopode ser cumprida mesmo que o serviço foi restaurado dentro dasexpectativas dos usuários. Isto muitas vezes resulta de um grandenúmero de incidentes abertos, muitos dos quais nunca serãofechado a menos que uma "purga" periódica é realizada. Isso podeser muito desmotivador e pode impedir a visibilidade eficaz dasquestões atuais.• Cumprimento de Requisição envolve a administração de cliente ousolicitações de usuários que não são gerados como um incidente de umatraso de serviço ou interrupção inesperada. Algumas organizaçõespodem escolher para lidar com esses pedidos como um categoriaDeincidentes e gerenciar as informações através de um Gerenciamento deIncidentes sistema - mas outros podem escolher (por causa de grandesvolumes ou de negócios prioridade de tais pedidos) para facilitar ofornecimento de capacidades de Cumprimento de Requisiçãoseparadamente através do Cumprimento de Requisição processo.ITIL V3 - Operação de Serviço - Página: 67 de 423
  • 68. Tornou-se popular prática utilizar um processo formal de cumprimento desolicitação para gerenciar clientes e usuários pedidos de todos os tipos depedidos, que incluem instalações, movimentos e suprimentos, bem comoaqueles específicos para De serviços de TIs. Estes pedidos não estãogeralmente ligados à mesma SLA medidas e separando o registros e ofluxo de processo está a emergir como melhores práticas em muitasorganizações.• Gerenciamento de Acesso: Este é o processo de concessão de usuáriosautorizados o direito de usar um serviço, ao restringir o acesso a usuáriosnão-autorizados. Ele é baseado em ser capaz de identificar com precisãoos usuários autorizados e gerenciar sua própria capacidade de acessarserviços como exigido durante as diferentes fases de seus recursoshumanos (RH) ou contratual ciclo de vida. Gerenciamento de acessotambém tem sido chamado de identidade ou Direitos Gestão em algumasorganizações.Além disso, existem vários outros processos que serão executados ou apoiadosdurante operação de serviço, mas que são conduzidas durante outras fases doServiço de Gestão de Ciclo de Vida. O operacional aspectos destes processosserá discutido na parte final deste capítulo e incluem:• Gestão da Mudança, Um grande processo que deve estar estreitamenteligada à Gerenciamento da Configuração e Gerenciamento de Liberação.Esses tópicos são cobertos principalmente no Transição de ServiçoPublicação.• Capacidade e Gerenciamento de Disponibilidade, Os aspectosoperacionais do que são abordados nesta publicação, mas que sãoabordados com mais detalhes no Design de Serviços publicação.• Gestão Financeira, Que é coberto no Estratégia de Serviço publicação.• Gestão do Conhecimento, Que é coberta na publicação Transição deServiço.• Continuidade do Serviço de TI, que é coberta na publicação ServiceDesign.• Serviço de Relatórios e Mensuração, que são abordados na publicaçãoMelhoria de Serviço ContinuadaITIL V3 - Operação de Serviço - Página: 68 de 423
  • 69. 4.1 Gestão de EventosUm evento pode ser definido como qualquer ocorrência detectável ou discernívelque tem importância para a gestão do Infraestrutura de TI ou a entrega de Deserviços de TI e avaliação do impacto um desvio poderá causar aos serviços. Oseventos são tipicamente notificações criadas por um serviço de TI, Item deConfiguração (CI) ou monitoramento ferramenta.Eficaz Operação de Serviço é dependente de saber o estado da infra-estrutura edetectar qualquer desvio do normal ou esperado operação. Isto é proporcionadopelo bom monitoramento e controlar sistemas, que são baseados em dois tiposde ferramentas:• monitoramento ativo ferramentas que CIs enquete chave para determinaro seu estado e disponibilidade. Quaisquer exceções irá gerar um alertarque precisa ser comunicada para a ferramenta apropriada ou equipe paraa ação• monitoramento passivo ferramentas que detectam e correlacionaroperacional alertas ou comunicações geradas pela CEI.4.1.1 Finalidade objetivo / / objetivoA capacidade de detectar eventos, entendê-los e determinar a ação de controleadequados por Gestão de Eventos. Gestão de Eventos é, portanto, a base parao Monitoramento Operacional e Controle (ver Anexo B).Além disso, se estes eventos são programados para comunicar informaçõesoperacionais, assim como avisos e excepções, eles podem ser usados comobase para a automatização de rotina muitos Gestão de Operações atividades,por exemplo, a execução de scripts em dispositivos remotos, ou enviar trabalhospara o processamento, ou mesmo dinamicamente equilibrar a demanda por umserviço em vários dispositivos para melhorar atuação.Gestão de Eventos, portanto, fornece o ponto de entrada para a execução demuitos Operação de Serviço processos e atividades. Além disso, ele forneceuma forma de comparar o desempenho real e comportamento contra projetopadrãos e SLAs. Como tal, Gestão de Eventos, também fornece uma base paraGarantia de Serviço e Comunicação, e melhoria dos serviços. Isso é abordadoem detalhes na publicação Melhoria de Serviço Continuada.4.1.2 ÂmbitoGestão de Eventos pode ser aplicado a qualquer aspecto de Serviço de Gestãode que tem de ser controlada, e que pode ser automatizado. Estes incluem:• Item de Configuraçãos:ITIL V3 - Operação de Serviço - Página: 69 de 423
  • 70. • Alguns CIs serão incluídos porque eles precisam ficar em umestado constante (por exemplo, um interruptor em uma redeprecisa ficar e ferramentas de Gestão de Eventos confirmar issorespostas de monitoramento para pings).• Alguns CIs serão incluídos porque a sua estado precisa mudarcom freqüência e Gestão de Eventos pode ser usado paraautomatizar esse e atualizar o CMS (por exemplo, a atualização deum arquivo servidor).• Condições ambientais (por exemplo, detecção de incêndio e fumaça)• Monitoramento de licenças de software para uso para garantir ótima /legal a utilização de licença e alocação• Segurança (Por exemplo, detecção de intrusão)• Normal atividade (Por exemplo, rastrear a utilização de um aplicação ou odesempenho de um servidor).A diferença entre monitoramento e Gestão de EventosEstas duas áreas são muito intimamente relacionados, mas ligeiramentediferente na natureza. Gestão evento é focado na geração e detecção denotificações significativas sobre o estado da Infraestrutura de TI e serviços.Embora seja verdade que o monitoramento é necessário para detectar e rastrearessas notificações, o monitoramento é mais amplo do que Gestão de Eventos.Por exemplo, os instrumentos de controlo irá verificar o estado de um dispositivopara assegurar que está a funcionar dentro de limites aceitáveis, mesmo que odispositivo não está a gerar eventos.Em termos mais simples, Gerenciamento de Eventos trabalha com asocorrências que são especificamente gerados a ser monitorado. Monitoramentoacompanha essas ocorrências, mas que também irá procurar activamentecondições que não geram eventos.4.1.3 Valor para os negóciosGestão valor evento para o negócio é geralmente indirecto, no entanto, épossível determinar a base para o seu valor como se segue:• Gestão de Eventos oferece mecanismos para o início detecção deincidentes. Em muitos casos, é possível que o incidente a ser detectada eatribuída a um grupo apropriado para a acção antes de qualquer realserviço interrupção ocorre.• Gestão de Eventos torna possível para alguns tipos de automatizadoatividade para ser monitorizada por excepção - removendo assim anecessidade de caros e recurso controlo em tempo real intensivo,enquanto reduz tempo de inatividade.ITIL V3 - Operação de Serviço - Página: 70 de 423
  • 71. • Quando integrados em outro Serviço de Gestão de processos (tais como,por exemplo, disponibilidade, ou Gerenciamento da Capacidade), Gestãode Eventos pode sinalizar mudanças de status ou exceções que permitemque a pessoa ou equipe para realizar resposta precoce, melhorandoassim a atuação do processo. Isto, por sua vez, permitirá a actividade debeneficiar de Gestão de serviço mais eficaz e mais eficiente em geral.• Gestão de Eventos oferece uma base para automatizado operaçãos,aumentando a eficiência e permitindo caros recursos humanos a seremutilizados para o trabalho mais inovador, como projetoing novafuncionalidade ou melhoria ou a definição de novas formas em que aempresa pode explorar a tecnologia para aumentar a vantagemcompetitiva.4.1.4 Políticas / princípios / conceitos básicosHá muitos tipos diferentes de eventos, por exemplo:• Eventos que significam regular funcionamento:• notificação de que uma marcada carga de trabalho completou• umusuário tem conectado para usar uma aplicação• um e-mail chegou ao seu destinatário.• Eventos que significam uma excepção• um usuário tenta fazer logon em um aplicativo com a senhaincorreta• uma situação inusitada ocorreu em um processo de negócio quepode indicar uma exceção que exige investigação de novosnegócios (por exemplo, uma página da web alertar indica que umsite de autorização de pagamento não está disponível -impactando aprovação financeira do negócio transaçãos)• CPU de um dispositivo está acima da taxa de utilização aceitável• uma varredura do PC revela a instalação de software nãoautorizado.• Eventos que significam incomum, mas não excepcional, operação. Estessão uma indicação de que a situação pode exigir mais pertomonitoramento. Em alguns casos, a condição irá resolver-se, porexemplo, no caso de uma combinação invulgar de carga de trabalhos - asua conclusão, a operação normal é restaurard. Em outros casos, aintervenção do operador podem ser necessários, se a situação é repetidoou se continua por muito tempo. Essas regras ou políticas são definidasnos Objectivos de monitoramento e controle para esse dispositivo ouserviço. Exemplos deste tipo de evento são:• AservidorUtilização da memória atinge até 5% da sua máximaaceitável atuação nível• O tempo de conclusão de uma transação é 10% maior do que onormal.ITIL V3 - Operação de Serviço - Página: 71 de 423
  • 72. Duas coisas são significativos sobre os exemplos acima:• Exatamente o que constitui o funcionamento normal versus anormal,contra uma exceção? Não existe uma regra definitiva sobre isso. Porexemplo, um fabricante pode prever que um referência da utilização damemória 75% é o ideal para aplicação X. No entanto, descobriu-se que,sob as condições específicas da nossa organização,tempo de respostascomeçam a degradar acima utilização de 70%. A próxima seção iráexplorar como esses números são determinados.• Cada conta com o envio e a recepção de uma mensagem de algum tipo.Estes são geralmente referidos como notificações de eventos e eles nãoacontecem por acaso. Os próximos parágrafos vai explorar exatamentecomo os eventos são definidos, gerado e capturado.ITIL V3 - Operação de Serviço - Página: 72 de 423
  • 73. 4.1.5 as atividades de processo, métodos e técnicasFigura 4.1 O processo de Gestão de EventosFigura 4.1 é uma representação de alto nível e genérico de Gestão de Eventos.Ele deve ser usado como um ponto de referência e definição, em vez de umfluxograma de Gestão real do evento. Cada atividade neste processo é descritoabaixo.ITIL V3 - Operação de Serviço - Página: 73 de 423
  • 74. 4.1.5.1 Evento ocorreEventos ocorrem continuamente, mas nem todos eles são detectados ouregistados. Portanto, é importante que todos os envolvidos no projeto,desenvolvimento, gestão e suporte De serviços de TIs e a Infraestrutura de TIque são executados entende que tipos de evento precisa ser detectado.Isso é discutido no parágrafo 4.1.10.1, intitulado "Instrumentação".4.1.5.2 Notificação de eventosMais CIs são projetados para comunicar certas informações sobre si mesmosem uma de duas maneiras:• Um dispositivo é interrogado por uma ferramenta de gestão, que recolhealguns dados segmentados. Isso é muitas vezes referido como voto.• O CI gera uma notificação quando certas condições são satisfeitas. Acapacidade para produzir estas notificações tem de ser concebido econstruído para o CI, por exemplo um gancho de programação inseridonuma aplicação.As notificações de eventos pode ser patenteado, caso em que apenasferramentas de gestão do fabricante pode ser utilizada para detectar eventos.Mais CIs, no entanto gerar notificações de eventos usando um aberto padrãotais como o SNMP (Simple Network Management Protocol).CIs Muitos estão configurado para gerar um conjunto padrão de eventos, combase na experiência do designer do que é necessário para operar o CI, com acapacidade de gerar outros tipos de eventos de ligando o mecanismo degeração de evento relevante. Para outros tipos de ignição por compressão, dealguma forma de software "agente" terá de ser instalado, a fim de dar início aomonitoramento. Muitas vezes, esse recurso de monitoramento é livre, mas àsvezes há um custar para o licenciamento da ferramenta.Em um mundo ideal, a Design de Serviços processo deve definir quais eventosprecisam ser geradas e especificar como isso pode ser feito para cada tipo deIC. Durante Transição de Serviço, As opções de geração de eventos seriadefinido e testado.Em muitas organizações, no entanto, a definição de quais eventos geram é feitopor tentativa e erro. Sistema gerentes usam o conjunto padrão de eventos comoum ponto de partida e, em seguida, ajustar o IC ao longo do tempo, para incluirou excluir eventos conforme necessário. O problema com esta abordagem é queela só leva em conta as necessidades imediatas da equipe gerenciamento dodispositivo e não facilita a boa planejamento ou melhoria. Além disso, torna-semuito difícil de monitorar e gerenciar o serviço sobre todos os dispositivos eITIL V3 - Operação de Serviço - Página: 74 de 423
  • 75. funcionários. Uma abordagem para combater este problema consiste em rever oconjunto de eventos, como parte das atividades de melhoria contínua.Um princípio geral de notificação de eventos é que a mais significativa os dadosque ele contém e do público mais segmentado, mais fácil é para tomar decisõessobre o evento. Operadores são frequentemente confrontados por codificadaerro mensagens e não têm idéia de como responder a elas ou o que fazer comeles. Dados significativos de notificação e claramente definidos papels eresponsabilidades precisam ser articulados e documentados durante Transiçãode Serviço Design e Serviços (ver também o parágrafo 4.1.10.1 em"Instrumentação"). Se papels e as responsabilidades não são claramentedefinidas, em uma ampla alertar, Ninguém sabe quem está fazendo o que e issopode levar a coisas que estão sendo perdidas ou duplicadas esforços.4.1.5.3 Detecção de eventosUma vez que uma notificação de eventos foi gerado, ele será detectado por umagente rodando no mesmo sistema, ou transmitida directamente para umaferramenta de administração especificamente concebido para ler e interpretar osignificado do evento.4.1.5.4 Evento filtragemO objetivo da filtragem é decidir se a comunicar a evento de uma ferramenta degestão ou ignorá-lo. Se ignorado, o evento geralmente será gravada em umarquivo de log no dispositivo, mas nenhuma outra ação será tomada.A razão para a filtragem é que nem sempre é possível transformar Eventonotificação fora, mesmo que uma decisão foi feita de que não é necessário paragerar esse tipo de evento. Também pode ser decidido que apenas o primeiro deuma série de repetidas Evento notificações serão transmitidos.Durante a etapa de filtragem, o primeiro nível de correlação é realizada, isto é, adeterminação de se o evento é informativa, de aviso ou de exceção (veja opróximo passo). Esta correlação é feita geralmente através de um agente quereside no CI ou numa servidor para que o IC está ligado.A etapa de filtragem não é sempre necessário. Para alguns itens deconfiguração, cada evento é significativo e move directamente no motor de umaferramenta de gestão de correlação de, mesmo se for duplicada. Além disso, elepode ter sido possível desligar todos os indesejados Evento notificações.4.1.5.5 Significado de eventosITIL V3 - Operação de Serviço - Página: 75 de 423
  • 76. Cada organização terá sua própria categorização da importância de um evento,Mas sugere-se que pelo menos as seguintes três categorias amplas serrepresentado:• Informativo: Isto refere-se a um evento que não exige qualquer acção enão representa uma excepção. Eles são normalmente armazenados nosistema ou serviço arquivos de log e mantido por um período pré-determinado. Informativa eventos são normalmente utilizados paraverificar o status de um dispositivo ou serviço, ou para confirmar aconclusão bem sucedida de uma atividade. Informativa eventos tambémpodem ser usados para gerar estatísticas (tais como o número deusuários conectado a uma aplicação durante um certo período) e comoentrada para investigações (como os trabalhos que concluída com êxitoantes do transação fila de processamento pendurado). Exemplos deinformação eventos incluem:• Um usuário faz logon em um aplicação• Um trabalho na fila de lote concluída com êxito• Um dispositivo está online• Uma transação é concluída com êxito.• Aviso: Um aviso é uma evento que é gerado quando um serviço oudispositivo se aproxima de um limiar. Avisos destinam-se a notificar apessoa adequada, processo ou ferramenta para que a situação pode serverificada eo tomadas as medidas adequadas para prevento umaexceção. Advertências não são tipicamente criados para um dispositivofalha. Embora haja algum debate sobre se a falha de um dispositivoredundante é um aviso ou uma exceção (desde que o serviço ainda estádisponível). Uma boa regra é que cada falha deve ser tratado como umaexceção, já que o risco de um incidente impactando o negócio é muitomaior. Exemplos de avisos são:• Utilização de memória em um servidor é atualmente a 65% ecrescente. Se atingir 75%, tempo de respostas serádemasiadamente longo e OLA para o departamento seráultrapassado.• A taxa de colisão em uma rede aumentou 15% em relação a últimahora.• Exceção: Uma excepção significa que um serviço ou dispositivo estáoperando de forma anormal (no entanto, que tenha sido definido).Tipicamente, isto significa que um e OLA SLA foram violados eo negócioestá sendo afetado. Exceções podem representar um total falha,Funcionalidade prejudicada ou degradadas atuação. Observe, porém, queuma exceção nem sempre representa uma incidente. Por exemplo, umaexceção pode ser gerada quando um dispositivo não autorizado fordetectado na rede. Isso pode ser gerenciado usando qualquer um Graveincidente ou um Requisição de Mudança (Ou mesmo ambas), de acordocom o organizaçãoIncidentes s e Gestão da Mudança políticas. Exemplosde exceções incluem:ITIL V3 - Operação de Serviço - Página: 76 de 423
  • 77. • Aservidor é baixo• O tempo de resposta de um padrão transação em toda a redereduziu-se a mais de 15 segundos• Mais de 150 usuários ter conectado ao General Ledger aplicaçãoconcorrentemente• Um segmento da rede não está respondendo às solicitações derotina.4.1.5.6 correlação de eventosSe um evento é significativo, uma decisão tem de ser feita sobre o queexatamente é o significado e as ações que precisam ser tomadas para lidar comisso. É aqui que o significado do evento é determinado.Correlação é normalmente feito por um "Correlação Engine , geralmente partede uma ferramenta de gerenciamento que compara o evento com um conjuntode critérios e regras de uma ordem prescrita. Estes critérios são freqüentementechamados de Regras de Negócios, embora eles geralmente são bastantetécnico. A idéia é que o evento pode representar algum impacto sobre aactividade e as regras pode ser utilizado para determinar o nível e tipo deimpacto comercial.Um mecanismo de correlação é programado de acordo com os padrões dedesempenho criados durante Design de Serviços e qualquer orientaçãoadicional específico para a operação ambiente.Exemplos do que mecanismos de correlação levará em conta incluem:• Número de eventos similares (por exemplo, esta é a terceira vez que omesmo usuário tenha se conectado com a senha incorreta, um aplicativode negócios relata que houve um padrão incomum de uso de um telefonemóvel que poderia indicar que o dispositivo for perdido ou roubado)• Número de CIs gerando eventos semelhantes• Se uma acção específica está associada com o código de dados ou nocaso• Se o evento representa uma excepção• Uma comparação das informações em caso de utilização com um padrãomáximo ou mínimo (por exemplo, o dispositivo tem uma excedido limiar?)• Se os dados adicionais é necessário para investigar o evento ainda mais,e possivelmente até mesmo uma coleção de dados por solicitação deoutro sistema ou banco de dados• Categorização do evento• A atribuição de um prioridade nível ao evento.4.1.5.7 GatilhoITIL V3 - Operação de Serviço - Página: 77 de 423
  • 78. Se a correlação atividade reconhece um evento, A resposta será necessária. Omecanismo utilizado para iniciar a resposta, que é chamada de um gatilho.Existem muitos tipos diferentes de disparadores, cada um desenhadoespecificamente para a tarefa, tem de iniciar. Alguns exemplos incluem:• Incidente Gatilhos que geram uma registro no Gerenciamento deIncidentes sistema, Iniciando assim o Gerenciamento de Incidentesprocesso• Alterar gatilhos que geram uma Requisição de Mudança (RFC), iniciandoassim a Gestão da Mudança processo• Um gatilho resultante de um RFC aprovado que tenha sido aplicada, masfez com que o evento ou a partir de uma alteração não autorizada quetenha sido detectado - em qualquer dos casos, este será referido ChangeManagement para investigação• Scripts que executam ações específicas, como enviar trabalhos de grupoou reiniciar um dispositivo• Sistemas de paginação que irá notificar uma pessoa ou equipe do eventopelo telefone celular• Gatilhos de banco de dados que restringem o acesso de um usuário aosregistros ou domínios específicos, ou que criar ou excluir entradas nobanco de dados.4.1.5.8 Resposta seleçãoNeste ponto do processo, há uma série de opções de respostas disponíveis. Éimportante notar que as opções de resposta pode ser escolhido em qualquercombinação. Por exemplo, pode ser necessário para manter a entrada de logpara referência futura, mas, ao mesmo tempo aumentar o evento para umaGestão de Operações membro da equipe para a ação.As opções no fluxograma são exemplos. Diferentes organizações terão opçõesdiferentes, e têm a certeza de ser mais detalhada. Por exemplo, haverá umagama de respostas auto para cada tecnologia diferente. O processo dedeterminar qual é apropriada e a forma de executar, não estão representadosneste fluxograma. Algumas das opções disponíveis são:• Evento registrado: Independentemente do que atividade é realizado, éuma boa idéia ter um registro do evento e quaisquer ações subseqüentes.O evento pode ser registrado como um registro de eventos na Gestão deEventos ferramenta, ou pode simplesmente ser deixada como umaentrada no registro do sistema do dispositivo ou aplicação que gerou oevento. Se este for o caso, porém, é preciso que haja uma ordempermanente para o pessoal adequado Gestão de Operações paraverificar os registros em uma base regular e instruções claras sobre comoutilizar cada log. Também deve ser lembrado que as informações doITIL V3 - Operação de Serviço - Página: 78 de 423
  • 79. evento nos logs podem não ser significativos até que um incidente ocorre,e onde o Gestão Técnica pessoal usar os logs para investigar onde oincidente originou. Isto significa que o evento de Gestão procedimentospara cada sistema ou a equipe precisa definir padrãos sobre comoeventos longos são mantidos nos registros antes de serem arquivados eexcluídos.• Resposta automática: Alguns eventos, são bem que a respostaadequada já foi definido e automatizado. Esta é, normalmente, comoresultado da boa projeto ou da experiência anterior (geralmenteGerenciamento de Problemas). O gatilho irá iniciar a ação e, em seguida,avaliar se ela foi concluída com êxito. Se não, um incidente ou Graveproblema será criada. Exemplos de respostas auto incluem:• Reiniciando um dispositivo• Reiniciando um serviço• Apresentar um trabalho em lote• A alteração do parâmetro em um dispositivo• Bloqueio de um dispositivo ou aplicação para protegê-lo contra oacesso não autorizado.Nota: bloqueio de um dispositivo pode resultar em negação de serviçoautorizado usuários, que pode ser explorada por um atacante deliberada -cuidado tão grande deve ser tomado quando decidir se esta é uma açãoapropriada automatizado. Se esta resposta for usado, ele pode serprudente também combinar isso com uma chamar por intervençãohumana, de modo que a acção automatizada pode ser prontamenteverificado e aprovado.• Alertar e intervenção humana: Se o evento requer intervenção humana,que terá de ser escalado. O objetivo do alerta é para garantir que apessoa com as competências adequadas para lidar com o evento énotificado. O alerta vai conter todas as informações necessárias para quea pessoa para determinar a ação apropriada - incluindo a referência aqualquer documentação necessária (manuais do usuário, por exemplo). Éimportante notar que este não é necessariamente o mesmo que oescalada funcional de um incidente, Onde a ênfase é sobre a restauraçãodo serviço dentro de um prazo acordado (o que pode exigir umavariedade de atividades). O alerta requer uma pessoa, ou equipe, paraexecutar uma ação específica, possivelmente em um dispositivoespecífico e, possivelmente, em um momento específico, por exemplo,trocar um cartucho de toner de uma impressora quando o nível estábaixo.• Incidente,problema ou mudar? Alguns eventos representam uma situaçãoem que a resposta adequada terá de ser tratado através do incidente,problema ou Gestão da Mudança processo. Estes são discutidos abaixo,mas é importante salientar que um único incidente pode dar início aqualquer um ou uma combinação destes três processos - por exemplo,ITIL V3 - Operação de Serviço - Página: 79 de 423
  • 80. um não-crítico servidor falha é registrado como um incidente, mas comonão há solução alternativa, Um Grave problema é criada para determinaro causa raiz e resolução e um RFC é logado para mudar o local da cargade trabalho para um servidor alternativo enquanto o problema é resolvido.• Abra uma RFC: Há dois lugares no processo de Gestão de Eventos,onde um RFC podem ser criados:• Quando ocorre uma exceção: Por exemplo, uma varredura deum segmento de rede revela que dois novos dispositivos foramadicionados sem a autorização necessária. Uma forma de lidarcom esta situação é o de abrir um RFC, que pode ser usado comoum veículo para o processo de gestão da mudança para lidar coma exceção (como uma alternativa para o método mais convencionalde abertura de um incidente que seriam encaminhadas através doService Desk ao Gerenciamento de Mudanças). Investigação peloGerenciamento de Mudanças é apropriado aqui desde alteraçõesnão autorizadas implicam que o processo de Gerenciamento deMudança não foi eficaz.• Correlação identifica que um mudar é necessário: Neste caso, oevento correlação atividade determina que a resposta adequada aum evento é algo para ser mudado. Por exemplo, um atuaçãolimiar tiver sido atingido, e um parâmetro de um servidor principalprecisa de ser ajustado. Como a atividade correlação determinarisso? Foi programado para o fazer, quer no Design de Serviçosprocessar ou porque isso já aconteceu antes e Gerenciamento deProblemas ou Gestão de Operações atualizou o Mecanismo deCorrelação de tomar esta ação.• Abra uma Grave incidente: Tal como acontece com uma RFC, umincidente pode ser gerado imediatamente quando uma exceção édetectada, ou quando o motor de correlação determina que um tipoespecífico ou combinação de eventos representa um incidente. Quandoum registro de incidentes é aberto, as informações, tanto quanto possível,deve ser incluído - com links para os eventos em questão e, se possíveluma completa script de diagnóstico.• Abrir ou vincular a um Grave problema: É raro que um registro deproblema a ser aberto sem incidentes relacionados (por exemplo, comoresultado de um Análise de falha de serviço (Ver Design de Serviçospublicação) ou maturidade avaliação, Ou por causa de um númeroelevado de tentativas rede erros, apesar de um falha ainda não ocorreu).Na maioria dos casos esta etapa refere-se à ligação de um incidente a umregistro de problema existente. Isso vai ajudar a Gerenciamento deProblemas equipes para reavaliar a gravidade e impacto do problema, Epode resultar numa alteração prioridade a um problema de circulação.No entanto, é possível, com algumas das ferramentas mais sofisticadas,para avaliar o impacto dos incidentes e também para elevar um registroITIL V3 - Operação de Serviço - Página: 80 de 423
  • 81. de problema automaticamente, quando assim o permitam, para permitir aanálise de causas básicas para começar imediatamente.• Tipos especiais de incidente: Em alguns casos, um evento irá indicaruma exceção que não impactam diretamente qualquer De serviços de TI,Por exemplo, uma unidade de condicionamento de ar redundante falha,ou a entrada não autorizada para um centro de dados. Diretrizs paraestes acontecimentos são as seguintes:• Um incidente deve ser registrado usando um incidente Modelo queé adequado para o tipo de excepção, por exemplo, um incidente deOperações ou Segurança Incidente (ver parágrafo 4.2.4.2 paramais detalhes de Incidentes Modelos).• O incidente deve ser escalada para o grupo que gerencia esse tipode incidente.• Como não há interrupção, o Modelo de Incidente usado devereflectir que esta era uma operacional em vez de emitir umaserviço questão. As estatísticas não seria normalmente reportadopara os clientes ou usuários, a menos que possam ser utilizadospara demonstrar que o dinheiro investido em redundância foi umbom investimento.• Estes incidentes não devem ser utilizados para calcular tempo deinatividade, E pode de facto ser utilizado para demonstrar comoproactiva TI tem sido tornar os serviços disponíveis.4.1.5.9 Rever as acçõesCom milhares de eventos que estão sendo gerados a cada dia, não é possívelformalmente rever cada evento individual. No entanto, é importante verificar quetodos os eventos significativos ou exceções foram tratadas de forma adequada,ou para acompanhar as tendências ou contagens de tipos de eventos, etc Emmuitos casos, isso pode ser feito automaticamente, por exemplo votação umservidor que havia sido reiniciado usando um script automático para ver se eleestá funcionando corretamente.Nos casos em que os acontecimentos tenham iniciado o incidente, problema e /ou mudar, A revisão de Acção não deve duplicar quaisquer críticas que têm sidofeitos como parte desses processos. Pelo contrário, a intenção é a de assegurarque a transição entre a Gestão de Eventos processo e outros processos ocorreucomo projetado e que a ação esperada, de fato, ocorrer. Isso irá garantir queincidentes, problemas ou mudanças originadas dentro Gestão de Operaçõesnão se perder entre as equipes ou departamentos.O Comente também será utilizado como entrada para a melhoria contínua eaavaliação e auditar do Gestão de Eventos processo.4.1.5.10 evento CloseITIL V3 - Operação de Serviço - Página: 81 de 423
  • 82. Alguns eventos irá permanecer aberto até que uma certa acção tem lugar, porexemplo, um evento que é ligado a uma abertura incidente. No entanto, amaioria dos eventos não são abriu ou fechado.Eventos informativos são simplesmente registrados e então usado como entradapara outros processos, como backup e Storage Management. Auto-respostaeventos irá tipicamente ser fechada através da geração de um segundo evento.Por exemplo, um dispositivo gera um evento e é reiniciado através de respostaautomática -, logo que o dispositivo é sucesso de volta online, ele gera umevento que efetivamente fecha o ciclo e limpa o primeiro evento.Às vezes é muito difícil relacionar o evento aberto e as notificações perto quantoeles são em diferentes formatos. É ideal que os dispositivos na infra-estruturaproduzir eventos "abertos" e "fechar" no mesmo formato e especificar amudança de status. Isto permite que o passo de correlação no processo defacilmente adaptar as notificações de abrir e fechar.No caso de eventos que geraram um incidente, problema ou mudar, Estesdevem ser formalmente encerrada com um link para o adequado registro a partirde outro processo.4.1.6 Triggers interfaces de entrada e saída / inter-processoGestão de Eventos pode ser iniciado por qualquer tipo de ocorrência. A chave édefinir qual dessas ocorrências é importante e que precisa ser colocada emprática. Gatilhos incluem:• Exceções a qualquer nível de CI atuação definido na projetoespecificaçãos, OLAs ou SOPs• As exceções a um sistema automatizado procedimento ou um processo,por exemplo, uma rotina mudar que tem sido atribuída a um construirequipe não foi concluído a tempo• Uma excepção a uma processo de negócio que está sendo monitoradopela Gerência de Eventos• A conclusão de uma tarefa ou trabalho automatizado• Aestado mudar em um dispositivo ou registro de dados• Acesso de um aplicação ou banco de dados por um usuário ouprocedimento automatizado ou trabalho• Uma situação em que um dispositivo de banco de dados ou aplicações,etc atingiu um predefinido limiar de desempenho.Gestão de Eventos pode fazer interface com qualquer processo que requermonitoramento e controlar, Especialmente aqueles que não necessitam demonitorização em tempo real, mas que exigem alguma forma de intervençãoapós um evento ou grupo de eventos. Exemplos de interfaces com outrosprocessos incluem:ITIL V3 - Operação de Serviço - Página: 82 de 423
  • 83. • Interface com aplicações de negócio e / ou processos de negócios parapermitir que eventos de negócios potencialmente importantes a seremdetectadas e corrigidas (por exemplo, um aplicativo de negócios relataanormal atividade num clienteO relato de que podem indicar algum tipode fraude ou segurança violação).• O principal ITSM relaçãos são com Incidente, Problema e Gerenciamentode Mudanças. Estas interfaces são descritas com algum pormenor noponto 4.1.5.8.• Capacidade e Gerenciamento de Disponibilidade são fundamentais nadefinição do que eventos são significativos, o que adequado limiars deveser e como responder a eles. Em troca, Gestão de Eventos melhorará aatuação e disponibilidade de serviços por responder a eventos quandoeles ocorrem e, relatando acontecimentos reais e padrões de eventospara determinar (por comparação com as metas de SLA e KPIs) sehouver algum aspecto da infra-estrutura projeto ou operação que podeser melhorado.• Gerenciamento da Configuração é capaz de usar os eventos paradeterminar o status atual de qualquer IC na infra-estrutura. Comparandoeventos com o autorizado linha de bases no Sistema de Gerenciamentoda Configuração (CMS) vai ajudar a determinar se existe não autorizadaMudar atividade a ter lugar no organização (Ver Transição de Serviçopublicação).• Gestão de Ativos (Coberto com mais detalhes no Design de Serviços epublicações de transição) pode usar o Gerenciamento de eventos paradeterminar o ciclo de vida estado de ativoss. Por exemplo, um eventopode ser gerado para indicar que um novo activo foi configurado comsucesso e é agora operacional.• Os eventos podem ser uma fonte rica de informações que podem serprocessados para inclusão em Gestão do Conhecimento sistemas. Porexemplo, os padrões de desempenho pode ser correlacionada com aactividade e utilizado como entrada para futura concepção e estratégiadecisões.• Gestão de eventos podem desempenhar um importante papel no sentidode garantir que o potencial impacto em SLAs é detectado precocemente equalquer falhas são rectificadas, logo que possível, de modo que oimpacto na serviço alvos é minimizado.4.1.7 Gestão da InformaçãoInformações-chave envolvidos em Gestão de Eventos inclui o seguinte:• Mensagens SNMP, que são uma forma padrão de comunicar informaçãotécnica sobre o estado de componentes de um Infraestrutura de TI.• Gestão da Informação Bases (MIBs) de dispositivos de TI. Uma MIB é obanco de dados em cada dispositivo que contém informações sobre odispositivo, incluindo o seu sistema operacional, o BIOSITIL V3 - Operação de Serviço - Página: 83 de 423
  • 84. versão,configuração dos parâmetros do sistema, etc A capacidade deinterrogar MIBs e compará-los a uma norma é fundamental para sercapaz de gerar eventos.• Vendedor monitoramento ferramentas de software agente.• Motores de correlação conter regras para determinar o significado earesposta apropriada aos eventos. Detalhes sobre este são fornecidos noparágrafo 4.1.5.6.• Não há eventos padrão Registro para todos os tipos de evento. Oconteúdo exato e formato do registro dependem das ferramentas queestão sendo usadas, o que está sendo monitorado (por exemplo, umservidor e a Gestão da Mudança ferramentas terá dados muito diferentese, provavelmente, usar um formato diferente). No entanto, existem algunsdados-chave que é normalmente exigido em cada evento para ser útil emanálise. Deve incluem tipicamente o:• Dispositivo• Componente• Tipo de falha• Data / hora• Parâmetros em exceção• Valor.4.1.8 MétricasPara cada período de medição em questão, o métricos para verificar o eficácia eeficiência do Gestão de Eventos processo deve incluir o seguinte:• Número de eventos por categoria• Número de eventos por significado• Número e porcentagem de eventos que necessitaram de intervençãohumana e se esta foi realizada• Número e porcentagem de eventos que resultou em incidentes oumudanças• Número e porcentagem de eventos provocados por existir problemas ouerros conhecidos. Isto pode resultar numa alteração na prioridade detrabalho em que o problema ou Erro Conhecido• Número e porcentagem de eventos repetidos ou duplicados. Isso vaiajudar na afinação do Mecanismo de Correlação de eliminar a geração deeventos desnecessário e pode também ser utilizada para auxiliar noprojeto de melhor funcionalidade evento geração em novos serviços• Número e porcentagem de eventos indicando atuação problemas (porexemplo, o crescimento do número de vezes que um aplicação excedeu asua transação limiars nos últimos seis meses)• Número e porcentagem de eventos indicando potencial disponibilidadequestões (failovers por exemplo, para dispositivos alternativos, ouexcessivo carga de trabalho swapping)• Número e percentual de cada tipo de evento por plataforma ou aplicaçãoITIL V3 - Operação de Serviço - Página: 84 de 423
  • 85. • Número e proporção de eventos em comparação com o número deincidentes.4.1.9 Desafios, Fatores Críticos de Sucesso e riscos4.1.9.1 DesafiosHá um número de desafios que podem ser encontrados:• Um desafio inicial pode ser a obtenção de financiamento para asferramentas necessárias e esforço necessários para instalar e explorar osbenefícios das ferramentas.• Um dos maiores desafios é definir o nível correto de filtragem. Definir onível de filtragem incorretamente pode resultar em um ser inundado comrelativamente insignificante eventos, ou não ser capaz de detectareventos relativamente importantes, até que seja tarde demais.• A implantação do necessário monitoramento agentes em toda ainfraestrutura de TI inteira pode ser uma tarefa difícil e demoradaatividade exigindo um compromisso contínuo por um longo período detempo - há um perigo de que as atividades podem surgir outras quepoderiam desviar recursos e atrasar o lançamento.• Adquirir as habilidades necessárias pode ser demorado e caro.4.1.9.2 Fatores Críticos de SucessoA fim de obter o financiamento necessário um Business Case convincente deveser preparado mostrando como os benefícios da efetiva Gestão de Eventospodem ultrapassar de longe a custars - dando um retorno positivo sobre oinvestimento.Um dos mais importantes é QCA atingir o nível correto de filtragem. Isto écomplicado pelo facto de a importância das alterações eventos. Por exemplo,um usuário login em um sistema hoje é normal, mas se o usuário deixa oorganização e tenta entrar é uma segurança violação.Há três chaves para o nível correcto de filtragem, da seguinte forma:• Integrar a Gestão de evento em toda a Serviço de Gestão de processossempre que possível. Isto assegurará que apenas os eventossignificativos para estes processos são descritos.• Concepção de novos serviços com Gestão de Eventos em mente (isto édiscutido em detalhes no parágrafo 4.1.10).• Tentativa e erro. Não importa o quão completamente Gestão de Eventosé preparado, haverá aulas de eventos que não são devidamente filtrados.Gestão de Eventos deve, portanto, incluir um formal processo para avaliara eficácia de filtragem.ITIL V3 - Operação de Serviço - Página: 85 de 423
  • 86. Adequado planejamento é necessário para a distribuição do software do agentede monitoramento em toda a infra-estrutura de TI inteiro. Isto deve serconsiderado como um projeto com prazos realistas e recursos adequados sendoalocado e protegidos durante todo o período de duração do projeto.4.1.9.3 RiscosA chave riscos são realmente os já mencionados acima: a incapacidade de obterfinanciamento adequado, garantindo o nível correto de filtragem, ea falha paramanter a dinâmica na implementação de agentes de controlo necessárias emtodo o Infraestrutura de TI. Se algum destes riscos não são os destinatários quepoderia adversamente impacto sobre o sucesso da Gestão de Eventos.4.1.10 Projeto de Gestão de EventosGestão de Eventos eficaz não é projetado, uma vez por serviço foi implantadoem Operações. Desde Gestão de Eventos é a base para o acompanhamento daatuação e disponibilidade de um serviço, as metas exatas e mecanismos demonitoramento devem ser especificadas e acordadas durante a disponibilidade eGerenciamento da Capacidade processos (ver Design de Serviços publicação).No entanto, isso não significa que a Gestão de Eventos foi projetado por umgrupo de controle remoto sistema desenvolvedores e, em seguida, liberado paraGestão de Operações juntamente com o sistema que tem de ser gerida.Também não quer dizer que, uma vez desenvolvido e acordado, Gestão deEventos se torna estática - dia-a-dia operaçãos vai definir adicional eventos,prioridades, alertars e outras melhorias que irão alimentar através da MelhoriaContínua processo volta Estratégia de Serviço,Design de Serviços etcOperação de Serviço funçãos deverão participar na projeto do serviço e comoela é medida (ver secção 3.4).Para Gestão de Eventos, As áreas de concepção específicos incluem oseguinte.4.1.10.1 InstrumentaçãoInstrumentação é a definição do que pode ser monitorado sobre CIs e damaneira em que o seu comportamento pode ser afetado. Em outras palavras, ainstrumentação é sobre como definir e projetar exatamente como monitorar econtrolar o Infraestrutura de TI e De serviços de TIs.Instrumentação é parte de um conjunto de decisões que precisam ser feitas e,em parte, sobre a criação de mecanismos para executar essas decisões.Decisões que precisam ser tomadas incluem:ITIL V3 - Operação de Serviço - Página: 86 de 423
  • 87. • O que precisa ser monitorado?• Que tipo de acompanhamento é necessária (por exemplo, ativa oupassiva; atuação ou saída)?• Quando precisamos de gerar um evento?• Que tipo de informação deve ser comunicada no evento?• Quem são as mensagens destinados?Mecanismos que precisam ser projetados incluem:• Como os eventos ser gerados?• O IC já tem mecanismos de geração de eventos como um recurso padrãoe, em caso afirmativo, qual destes será utilizado? São suficientes ou nãoo CI precisa ser personalizado para incluir mecanismos adicionais ouinformações?• Os dados que serão usados para preencher o Evento Registro?• São eventos gerados automaticamente ou se o CI tem que ser buscado?• Onde vai ser eventos registrados e armazenados?• Como os dados complementares ser recolhidas?Nota: Uma interface forte existe aqui com o aplicaçãoS design. Todas asaplicações devem ser codificadas de tal maneira que significativa e detalhadoerro mensagens / códigos são gerados no ponto exato de falha - De modo queestes podem ser incluídos no evento e permitir rápida diagnóstico e resolução dacausa subjacente. A necessidade da inclusão e teste de mensagens de erro dotipo é descrita em mais detalhe no Transição de Serviço publicação.4.1.10.2 mensagens de erroMensagens de erro é importante para todos componentes (hardware, software,redes, etc.) É particularmente importante que todos os aplicativos são projetadospara suportar Gestão de Eventos. Isso pode incluir o fornecimento demensagens de erro significativo e / ou códigos que indicam claramente o pontoespecífico de falha ea causa mais provável. Em tais casos, o teste de novoaplicaçãos deve incluir o teste de precisão evento geração.Novas tecnologias como Java Management Extensions (JMX) ou HawkNL ™fornecer as ferramentas para a construção de distribuídos, baseados na web,soluções modulares e dinâmica para a gestão e monitoramento dispositivos,aplicações e serviçoOrientados por redes. Estes podem ser usados para reduzirou eliminar a necessidade de os programadores para incluir erro mensagensdentro do código - permitindo um nível importante de normalização e de código-independência.4.1.10.3 de detecção de eventos e mecanismos de alertaITIL V3 - Operação de Serviço - Página: 87 de 423
  • 88. Bom Gestão de Eventos projeto também incluem a concepção e população dasferramentas utilizadas para filtrar, correlacionar e escalar Eventos.O Mecanismo de Correlação especificamente terá de ser preenchido com asregras e critérios que irão determinar o significado e subseqüente ação paracada tipo de evento.Projeto completo do evento detecção e alertar mecanismos requer o seguinte:• Conhecimento do negócio em relação para qualquer processo denegócioes a ser gerido através de Gestão de Eventos• Conhecimento detalhado do Exigência de Nível de Serviços do serviço aser suportado por cada CI• Conhecimento de quem vai ser o apoio à CI• Conhecimento do que constitui normal e anormal operação da CI• Conhecimento do significado de vários eventos semelhantes (na CImesmo ou semelhante vários CIs• Uma compreensão do que eles precisam saber para apoiar o CIefetivamente• Informações que podem ajudar na diagnóstico de problemas com o CI• Familiaridade com incidente códigos de prioridade e categorização demodo que, se é necessário criar um Grave incidente, Esses códigospodem ser fornecidos• O conhecimento de outros CIs que pode ser dependente da CI afectado,ou os IC da qual depende• Disponibilidade de Erro Conhecido informações de fornecedores ou deexperiência anterior.4.1.10.4 Identificação de limiaresLimiars mesmos não estão definidos e gerenciados através de Gerenciamentode Eventos. No entanto, a menos que estas sejam devidamente projetado ecomunicado durante a instrumentação processo, Será difícil determinar qual onível de atuação é apropriada para cada IC.Além disso, a maioria dos limiares não são constantes. Eles consistemtipicamente de uma série de variáveis relacionadas. Por exemplo, o númeromáximo de concorrentes usuários antes tempo de resposta retarda vai variardependendo do que outros trabalhos estão ativos no servidor. Esteconhecimento é muitas vezes só ganhou por experiência, o que significa que osmotores de correlação tem que ser continuamente atento e atualizado atravésdo processo de Melhoria de Serviço Continuada.ITIL V3 - Operação de Serviço - Página: 88 de 423
  • 89. 4.2 Gestão de IncidentesEm ITIL terminologia, um incidenteÉ definido como:Uma interrupção não planejada a um De serviços de TI ou redução do qualidadede um serviço de TI. Falha de um item de configuração que ainda não tenhaimpacto serviço É também um incidente, por exemplo falha de um disco a partirde um conjunto de espelho.Gerenciamento de Incidentes é o processo para lidar com todos os incidentes, oque pode incluir falhas, perguntas ou perguntas relatados pela usuários(usualmente através de um telefone chamar ao Service Desk), Pela equipetécnica, ou automaticamente detectado e reportado pelo evento monitoramentoferramentas.4.2.1 Finalidade objetivo / / objetivoO principal objetivo do processo de Gerenciamento de Incidentes é restaurarnormal operação de serviço o mais rapidamente possível e minimizar os efeitosadversos impacto em operações comerciais, Garantindo assim que os melhoresníveis possíveis de qualidade de serviço e disponibilidade são mantidos.Operação de serviço Normal é definida aqui como operação de serviço dentroSLA limites.4.2.2 ÂmbitoGerenciamento de Incidentes inclui qualquer evento que perturbe, ou o quepoderia interromper, um serviço. Isso inclui eventos que são comunicadosdiretamente pelos usuários, seja por meio da Central de Serviços ou através deuma interface de Gestão de Eventos a ferramentas de gerenciamento deincidentes.Os incidentes podem também ser comunicados e / ou registrados pela equipetécnica (se, por exemplo, eles percebem algo desagradável com um hardwareou rede componente eles podem denunciar ou fazer um incidente e remetê-lopara o Posto de Serviço). Isso não significa, entretanto, que todos os eventossão incidentes. Muitas classes de eventos não estão relacionados a interrupçõesem tudo, mas são indicadores de operação normal ou são simplesmenteinformativa (ver secção 4.1).Embora ambos os incidentes e solicitação de serviços são relatados para oService Desk, isso não significa que eles são os mesmos. Solicitações deserviço não representam uma interrupção do serviço acordado, mas são umamaneira de atender a clienteS precisa e pode ser uma abordagem metaacordada em um SLA. Solicitações de serviços são tratados pelo Cumprimentode Requisição processo (ver secção 4.3).ITIL V3 - Operação de Serviço - Página: 89 de 423
  • 90. 4.2.3 Valor para os negóciosO valor do Gerenciamento de Incidentes inclui:• A capacidade de detectar e resolver incidentes o que resulta em menortempo de inatividade para o negócio, o que por sua vez significa umamaior disponibilidade do serviço. Isto significa que a actividade é capazde explorar a funcionalidade do serviço, como desenhado.• A capacidade de alinhar a TI atividade às prioridades comerciais emtempo real. Isto é porque Gerenciamento de Incidentes inclui acapacidade de identificar as prioridades de negócios e alocardinamicamente recursos conforme necessário.• A capacidade de identificar potenciais melhorias aos serviços. Istoacontece como resultado da compreensão do que constitui um incidente etambém de estar em contacto com as actividades de negócio operacionalpessoal.• O Service Desk pode, durante seu tratamento de incidentes, identificaradicional serviço ou formação exigências encontradas em TI ou onegócio.Gerenciamento de Incidentes é altamente visível para o negócio, e por isso émais fácil de demonstrar o seu valor do que a maioria das áreas em Operaçãode Serviço. Por esta razão, Gerenciamento de Incidentes é muitas vezes um dosprimeiros processos a serem implementadas em Serviço de Gestão de projetos.A vantagem de fazer isso é que Gerenciamento de Incidentes pode ser usadopara destacar outras áreas que precisam de atenção - proporcionando assimuma justificativa para as despesas com a implementação de outros processos.4.2.4 Políticas / princípios / conceitos básicosHá algumas coisas básicas que precisam ser levados em conta quando seconsidera e decidiu Gerenciamento de Incidentes. Estes são tratados nestaseção.4.2.4.1 PrazosPrazos deve ser aprovada para todas as fases de tratamento de incidente (estesirão diferir dependendo da prioridade nível do incidente) - com base na respostaglobal e incidente resolução alvos dentro de SLAs - e capturados como alvosdentro Olas e Subjacente Contratos (UCs). Todos grupo de apoios deve serplenamente consciente destes prazos. As ferramentas de gerenciamento deserviços devem ser usadas para automatizar prazos e aumentar o incidentecomo necessário com base na regras pré-definidas.4.2.4.2 Modelos de IncidentesITIL V3 - Operação de Serviço - Página: 90 de 423
  • 91. Muitos incidentes não são novos - eles envolvem lidar com algo que jáaconteceu antes e pode acontecer de novo. Por esta razão, muitas organizaçõesvai encontrá-lo útil para pré-definir Incident padrão Modelos - e aplicá-los aosincidentes adequadas quando eles ocorrem.Um modelo de Incidentes é uma forma de pré-definir os passos que devem sertomadas para lidar com uma processo (Neste caso, um processo para tratar umtipo particular de incidente) de uma forma acordado. Ferramentas de suportepode então ser utilizado para administrar o processo desejado. Isso irá garantirque padrão incidentes são tratados em um caminho pré-definido e dentro deprazos pré-definidos.Incidentes que requerem um tratamento especializado pode ser tratada destaforma (por exemplo, segurançaIncidentes relacionados podem serencaminhadas para Gestão de Segurança da Informação e capacidade- OuatuaçãoIncidentes relacionados que seriam encaminhadas para Gerenciamentoda Capacidade.O Modelo de Incidente deve incluir:• Os passos que devem ser tomadas para lidar com o incidente• A ordem cronológica estas etapas devem ser tomadas, com quaisquerdependências ou co-processamento definidos• Responsabilidades; quem deve fazer o que• Prazos e limiars para a conclusão das ações• Escalada procedimentos; que deve ser contactado e quando• Qualquer necessárias evidências de preservação de atividades(particularmente relevante para segurança- E capacidadeRelacionadaincidentes).O modelos deve ser entrada para as ferramentas de manipulação de incidentede suporte a ser utilizado e, em seguida, as ferramentas devem automatizar otratamento, gestão e escalada do processo.4.2.4.3 grandes incidentesUm separado procedimento, Com prazos mais curtos e maiores urgência, Deveser utilizado para principais incidentes. A definição do que constitui umincidente grave deve ser acordado e, idealmente, mapeado para a priorizaçãoincidente geral sistema - De tal forma que eles serão tratados através doincidente de grandes proporções processo.Nota: As pessoas às vezes usam terminologia solta e / ou confundir umincidente grave com uma problema. Na realidade, um incidente continua a serum incidente para sempre - pode crescer em impacto ou prioridade para setornar um grande incidente, mas um incidente nunca se torna um problema. UmITIL V3 - Operação de Serviço - Página: 91 de 423
  • 92. problema é a causa subjacente de um ou mais incidentes e continua a ser umaentidade separada sempre!Alguns incidentes menor prioridade também pode ter de ser tratado por esteprocesso - devido ao impacto potencial - e algumas grandes incidentes pode nãoprecisar de ser tratada desta forma, se a causa e resoluçãos são óbvias e doprocesso de incidente normal pode facilmente lidar dentro da meta acordadaresolução vezes - desde que o impacto é baixo!Sempre que necessário, o procedimento de incidente grave deve incluir oestabelecimento dinâmico de uma equipe grande incidente separado, sob aliderança direta do Gerente de Incidentes, formulada para se concentrar sobreeste incidente só para garantir que adequada recursos e foco são fornecidospara encontrar uma solução rápida. Se o Service Desk Gerente também é ocumprimento da papel do Gerente de Incidentes (digamos em um pequenoorganização), Então uma pessoa separada pode precisar de ser designado paraliderar a equipa de investigação principal incidente -, de modo a evitar o conflitode tempo ou prioridades - mas, em última análise deve informar o Gerente deIncidentes.Se a causa do incidente tem de ser investigada, ao mesmo tempo, então oGestor de Problemas estaria envolvido bem mas o Gestor de Incidentes deveassegurar que serviço restauração e causa subjacente são mantidos separados.Durante todo, o Service Desk seria garantir que todas as atividades sãoregistradas e usuários sejam plenamente informados do progresso.4.2.5 As atividades de processo, métodos e técnicasO processo a ser seguido durante a gestão de um incidente é mostrado na figura4.2. O processo inclui as seguintes etapas.ITIL V3 - Operação de Serviço - Página: 92 de 423
  • 93. Figura 4.2 Incidente de fluxo de processo de Gestão de4.2.5.1 identificação de incidentesITIL V3 - Operação de Serviço - Página: 93 de 423
  • 94. Trabalho não pode começar a lidar com um incidente até que seja conhecidoque um incidente. É geralmente inaceitável, a partir de um perspectiva denegócios, Esperar até que um usuário é impactado e os contatos do ServiceDesk. Na medida do possível, todas as chaves componentes devem sermonitoradas para que falhas ou potenciais falhas são detectadas cedo para quea Gerenciamento de Incidentes processo pode ser iniciado rapidamente.Idealmente, os incidentes devem ser resolvidos antes que eles tenham umimpacto sobre os usuários!Por favor, consulte a secção 4.1 para mais detalhes.4.2.5.2 registro de incidentesTodos incidentes deve ser totalmente registradas e data / hora marcada,independentemente de eles são criados através de um Service Desk telefonechamar ou se detectada automaticamente através de um evento alertar.Nota: Se o Service Desk e / ou pessoal de apoio visitar o clientes para lidar comum incidente, eles podem ser convidados para lidar com novos incidentes ",enquanto eles estão lá". É importante que, se isso for feito, uma separada Graveincidente é registrado para cada incidente adicional tratado - para garantir queuma histórica registro é mantido e crédito é dado para o trabalho realizado.Toda a informação relevante sobre a natureza do incidente devem serregistrados, de forma que um registro histórico completo é mantida - e de modoque se o incidente tem de ser encaminhado para outro grupo de apoio(S), queterá todas as informações relevantes para a mão para ajudá-los.A informação necessária para cada incidente é provável que inclua:• Número de referência único• Categorização incidente (muitas vezes dividido em entre dois e quatroníveis de sub-categorias)• Incidente urgência• Incidente impacto• Priorização incidente• Data / hora da gravação• Nome / ID da pessoa e / ou grupo a gravação do incidente• Método de notificação (telefone, automático, e-mail, pessoalmente, etc)• Nome do departamento / / telefone / localização de usuário• Call-back método (e-mail, telefone, etc)• A descrição dos sintomas• Incidente estado (Ativo, esperando, fechado, Etc)• Relacionado CI• Grupo de apoio / pessoa para a qual o incidente é alocado• Relacionado problema/Erro ConhecidoITIL V3 - Operação de Serviço - Página: 94 de 423
  • 95. • Atividades realizadas para resolver o incidente• Resolução data e hora• Fecho categoria• Data e hora de encerramento.Nota: Se o Service Desk não funcionar 24/7 e responsabilidade de primeira linhaincidente registro e manipulação de passes para outro grupo, como Operaçõesde TI ou suporte de rede, fora do horário de Service Desk, em seguida, estesfuncionários precisam estar igualmente rigorosa sobre o registro de detalhes doincidente. Formação integral e consciência tem de ser fornecida para essepessoal sobre esta questão.4.2.5.3 categorização de incidentesParte do registro inicial deve ser adequado para alocar incidente categorizaçãode codificação para que o tipo exato do chamar é gravada. Isto será importantemais tarde quando se olha para tipos de incidentes / freqüências paraestabelecer tendências para o uso em Gerenciamento de Problemas,Gestão deFornecedores e outras atividades de ITSM.Por favor, note que a seleção para Solicitação de Serviços neste processo nãoimplica que Solicitações de serviços são incidentes. Este é simplesmente oreconhecimento do fato de que solicitações de serviço são, por vezesincorretamente registrada como incidentes (por exemplo, um usuárioincorretamente entra o pedido como incidente a partir da interface web). Estaverificação será detectar tais solicitações e garantir que eles são passados parao Cumprimento de Requisição processo.Multi-nível categorização está disponível na maioria das ferramentas -geralmente a três ou quatro níveis de complexidade. Por exemplo, um incidentepodem ser categorizados como mostrado na Figura 4.3.ITIL V3 - Operação de Serviço - Página: 95 de 423
  • 96. Figura 4.3 categorização incidente Multi-nívelTodas as organizações são únicos e, portanto, é difícil dar uma orientaçãogenérica sobre as categorias de organização Deve usar-se, em especial aosníveis mais baixos. No entanto, não é uma técnica que pode ser usada paraajudar a alcançar uma organização de um conjunto completo e correcto dascategorias - caso se parte do zero! Os passos envolvem:1. Segure um de brainstorming sessão entre o relevante grupo de apoios,envolvendo a Autoridade SD e gestores de incidentes e problemas.2. Use esta sessão para decidir o "melhor palpite" categorias de nívelsuperior - e incluir um outro categoria. Configurar as ferramentasrelevantes de registro para usar essas categorias por um períodoexperimental.3. Use as categorias por um período experimental de curta duração (temposuficiente para que várias centenas de incidentes a cair em cadacategoria, mas não muito tempo que uma análise vai demorar muitotempo para executar).4. Faça uma análise dos incidentes registrados durante o períodoexperimental. O número de incidentes registrados em cada categoria denível superior irá confirmar se as categorias valem a pena - e uma análiseITIL V3 - Operação de Serviço - Página: 96 de 423
  • 97. mais detalhada da categoria "outros" deve permitir a identificação dequaisquer adicionais de nível superior categorias que serão necessários.5. Uma análise de distribuição dos incidentes em cada categoria de nívelmais alto deve ser usado para determinar as categorias de nível inferiorque serão necessárias.6. Comente e repetir estas actividades após um período adicional - de,digamos, um a três meses - e novamente regularmente para garantir queeles permaneçam relevantes. Esteja ciente de que quaisquer mudançassignificativas para categorização pode causar algumas dificuldades paracomunicação de incidentes de tendências ou de gestão - então elesdevem ser estabilizados, a menos que as mudanças são realmentenecessárias.Se um esquema de categorização existente está em uso, mas não é pensado deforma satisfatória, a idéia básica da técnica sugerida acima pode ser usado pararever e alterar o regime existente.NOTA: Às vezes, as informações disponíveis no momento de um incidente éregistrado pode ser incompleto, enganosas ou incorretas. Portanto, é importanteque a categorização do incidente é verificada e atualizada, se necessário, nomomento da chamada de encerramento (em separado fecho campo decategorização, de forma a não danificar a categorização original) - consulte oparágrafo 4.2.5.9.4.2.5.4 priorização de IncidentesOutro aspecto importante de registrar todos os incidente é concordar e alocarum código de priorização apropriada - como isso vai determinar como oincidente é tratado tanto por ferramentas de apoio e pessoal de apoio.Priorização pode normalmente ser determinado tendo em conta tanto o urgênciado incidente (o quão rápido a empresa precisa de um resolução) E o nível deimpacto que está causando. Uma indicação do impacto é frequentemente (masnão sempre) o número de usuárioestá sendo afetado. Em alguns casos, e muitoimportante, a perda de serviço para um único usuário pode ter um impactogrande negócio - tudo depende de quem está tentando fazer o que - para osnúmeros por si só não é suficiente para avaliar global prioridade! Outros fatoresque também podem contribuir para os níveis de impacto são:• Risco para a vida ou saúde• O número de serviços afectados - pode ser de vários serviços• O nível das perdas financeiras• Efeito sobre reputação empresarial• Brechas regulatórias ou legislativas.ITIL V3 - Operação de Serviço - Página: 97 de 423
  • 98. Uma forma eficaz de cálculo destes elementos e derivando um nível deprioridade geral para cada incidente é dado na Tabela 4.1:ImpactoAlto Médio BaixoAlto 1 2 3Urgência Médio 2 3 4Baixo 3 4 5Código de prioridade Descrição Tempo de resolução alvo1 Crítico 1 hora2 Alto 8 horas3 Médio 24 horas4 Baixo 48 horas5 Planejamento PlanejadoTabela 4.1 sistema de prioridades simples codificaçãoEm todos os casos, orientação clara - com exemplos práticos - deve serfornecida para todo o pessoal de apoio que lhes permitam determinar a urgênciacorreta e níveis de impacto, então a prioridade correta é alocado. Taisorientações devem ser produzidos durante nível de serviço negociações.No entanto, deve notar-se que haverá ocasiões em que, por causa daoportunidade de negócio particular ou o que quer, os níveis de prioridade normaltem que ser substituído. Quando um usuário está convencido de que o nível deprioridade de um incidente deve exceder normais diretrizs, o Service Deskdevem cumprir tal pedido - e que, posteriormente passa a ser incorreta issopode ser resolvido como um problema de nível off-line de gestão, em vez deuma disputa que ocorre quando o usuário está usando o telefone.Algumas organizações podem também reconhecer VIPs (altos executivos,funcionários, diplomatas, políticos, etc), cujos incidentes seriam tratados em ummaior prioridade do que o normal - mas, nesses casos, este é o melhor servidose documentado dentro do guidance fornecido ao Service Desk pessoal sobrecomo aplicar os níveis de prioridade, por isso são todos conscientes das regrasacordadas para VIPs, e que cai nesta categoria.Deve notar-se que um incidentePrioridade s pode ser dinâmico - se ascircunstâncias mudarem, ou se um incidente não for resolvida dentro SLA vezesalvo, em seguida, a prioridade deve ser alterado para refletir a nova situação.ITIL V3 - Operação de Serviço - Página: 98 de 423
  • 99. Nota: algumas ferramentas podem ter restrições que dificultam automaticamentepara calcular atuação contra SLA alvos se uma prioridade é alterado durante otempo de vida de um incidente. No entanto, se as circunstâncias mudam, amudança de prioridade deve ser feito - e, se necessário ajustes manuais feitospara ferramentas de relatórios. Idealmente, as ferramentas com tais restriçõesnão devem ser selecionados.4.2.5.5 O diagnóstico inicialSe o incidente foi encaminhado através do Service Desk, o Analista de ServiceDesk deve realizar inicial diagnóstico, Tipicamente enquanto o usuário aindaestá no telefone - se o chamar é levantada desta maneira - para tentar descobrirtodos os sintomas do incidente e determinar exatamente o que deu errado ecomo corrigi-lo. É nesta fase que script de diagnósticos e erro conhecidoinformação pode ser mais valiosa do que permite o diagnóstico precoce epreciso.Se possível, o Analista de Service Desk vai resolver o incidente, enquanto ousuário ainda está no telefone - e fechar o incidente se o resolução é bemsucedida.Se o Analista de Service Desk não pode resolver o incidente, enquanto o usuárioainda está no telefone, mas há uma perspectiva de que o Service Desk pode sercapaz de fazê-lo no prazo acordado sem a ajuda de outra grupo de apoios, oanalista deve informar o utilizador sobre as suas intenções, dar ao usuário onúmero de referência incidente e tentar encontrar uma solução.4.2.5.6 escalada de incidentes• Escalada funcional. Tão logo torna-se claro que o Service Desk é incapazde resolver o incidente em si (ou quando os tempos alvo para primeiro-ponto resolução foram ultrapassados -! Que ocorrer primeiro), o incidentedeve ser imediatamente encaminhado para um apoio adicional.Se o organização tem um grupo de apoio de segundo nível e ServiceDesk acredita que o incidente pode ser resolvido por esse grupo, devereferir-se o incidente para eles. Se é óbvio que o incidente terá maisprofundo conhecimento técnico - ou quando o grupo de segundo nível,não tem sido capaz de resolver o incidente dentro de vezes acordado (oque ocorrer primeiro), o incidente deve ser imediatamente encaminhadopara o terceiro adequado nível apoiar grupo. Observe que os grupos deterceiro nível de suporte podem ser internos - mas eles também podemser terceiros, tais como software fornecedors ou hardware fabricantes oumantenedores. As regras para a escalada e tratamento de incidentesdevem ser acordados na Olas e UCs com grupos de apoio interno eexterno, respectivamente.ITIL V3 - Operação de Serviço - Página: 99 de 423
  • 100. Nota: Propriedade de Incidentes permanece com o Service Desk!Independentemente de onde um incidente é referido durante a sua vida, apropriedade do incidente permanece com o Service Desk em todos osmomentos. O Service Desk permanece responsável pelo controle doprogresso, mantendo os usuários informados e, finalmente, para aIncidentes Fecho.• Escalada hierárquica. Se os incidentes são de natureza grave (porexemplo Prioridade 1 incidentes), os gerentes de TI apropriadas deve sernotificado, para fins informativos, pelo menos. Escalada hierárquicatambém é utilizado se a investigação "e DiagnósticoEResolução eRecuperaçãoPassos estão demorando muito ou provando muito difícil.Hierárquica escalada devem continuar até a cadeia de gestão para queos gerentes seniores estão conscientes e podem ser preparadas e tomaras medidas necessárias, tais como alocação adicional recursos ouenvolvendo fornecedors / mantenedores. Escalada hierárquica também éusado quando há disputa sobre a quem o incidente é alocado.Escalada hierárquica pode, naturalmente, ser iniciada pelo afectadausuários ou cliente gestão, como entenderem - é por isso que éimportante que os gerentes de TI estão cientes, para que possam prevere preparar-se para qualquer escalada tal.Os níveis exatos e prazos para escalonamento funcional e hierárquica precisaser aprovada, tendo em conta SLA alvos, e incorporados em ferramentas deapoio, que podem então ser usados para polícia e controlar o fluxo do processodentro de prazos acordados.O Service Desk deve manter o usuário informado de qualquer escaladarelevante que tem lugar e garantir a Grave incidente é atualizado de acordo paramanter uma história cheia de ações.Nota sobre alocação de IncidentesPode haver muitos incidentes numa fila com o mesmo prioridade nível - por issovai ser o trabalho do Service Desk e / ou Gerenciamento de Incidentes pessoalinicialmente, em conjunto com os gestores das diversas grupo de apoios paraque os incidentes são escalados, para decidir a ordem em que os incidentesdevem ser pego e trabalhado ativamente. Esses gerentes devem garantir que osincidentes são tratados de modo verdadeiro negócio prioridade e que osfuncionários não estão autorizados a "cereja-pick dos incidentes que escolher!4.2.5.7 Investigação e DiagnósticoNo caso de incidentes em que o usuário está apenas em busca de informações,o Service Desk deve ser capaz de fornecer esta muito rapidamente e resolver aITIL V3 - Operação de Serviço - Página: 100 de 423
  • 101. solicitação de serviço - mas se um culpa está sendo relatado, este é umincidente e é provável que requerem algum grau de investigação e diagnóstico.Cada um dos grupos de apoio envolvidos com o tratamento de incidentes iráinvestigar e diagnosticar o que está errado - e todas essas atividades (incluindodetalhes de quaisquer medidas tomadas para tentar resolver ou recriar oincidente) devem ser devidamente documentados no registro de incidente paraque um histórico completo registro de todas as actividades é mantida em todosos momentos.Nota: O tempo valioso muitas vezes pode ser perdido se investigação e acçãode diagnóstico (ou mesmo resolução ou recuperação ações) são executadas emsérie. Sempre que possível, essas atividades devem ser realizadas em paralelopara reduzir prazos gerais - e ferramentas de apoio devem ser concebidos e / ouselecionados para permitir isso. No entanto, cuidados devem ser tomados paracoordenar as atividades, atividades especialmente de resolução ou derecuperação, caso contrário, as ações de diferentes grupos podem entrar emconflito ou complicar ainda mais a resolução!Esta investigação é provável que incluem ações como:• Estabelecer exatamente o que deu errado ou sendo procurado pelousuário• Compreender a ordem cronológica de eventos• Confirmando o pleno impacto do incidente, incluindo o número evariedade de usuários afetados• Identificar quaisquer eventos que possam ter provocado o incidente (porexemplo, uma recente mudar, Alguma ação do usuário?)• Buscas conhecimento procurando ocorrências anteriores por pesquisaranterior Incidente/Grave problemas e / ou Banco de Dados de erroconhecidos ou fabricantes /fornecedors logs de erros ou bancos dedados de Conhecimento.4.2.5.8 Resolução e RecuperaçãoQuando um potencial resolução foi identificado, este deve ser aplicado etestado. As ações específicas a serem realizadas e as pessoas que serãoenvolvidas na tomada de recuperação acções podem variar, dependendo danatureza do culpa - Mas pode envolver:• Pedindo o usuário para realizar atividades direcionadas em seu topoprópria mesa ou o equipamento remoto• O Service Desk implementar a resolução ou centralmente (por exemplo,reiniciar um servidor) Ou remotamente usando o software para assumir ocontrole do computador do usuário para diagnosticar e implementar umaresoluçãoITIL V3 - Operação de Serviço - Página: 101 de 423
  • 102. • Especialista grupo de apoioestá sendo solicitado a implementar ações derecuperação específicas (por exemplo suporte de rede reconfigurar umroteador)• Um fornecedor de terceiros ou mantenedor sendo solicitados a resolver afalha.Mesmo quando uma resolução foi encontrado, testes suficientes devem serrealizados para garantir que a ação de recuperação é completa e que a serviçofoi totalmente restaurard para o utilizador (es).NOTA: em alguns casos, pode ser necessário que dois ou mais grupos de tomarseparadas, embora talvez coordenadas as acções de recuperação, para umaresolução global a ser implementado. Em tais casos, Gestão de Incidentes devecoordenar as actividades e estabelecer contactos com todas as partesenvolvidas.Independentemente das medidas tomadas, ou que faz deles, o Grave incidentedeve ser atualizado de acordo com todas as informações e detalhes para queuma história cheia é mantido.O grupo deve passar resolver o incidente de volta para o Service Desk parafecho ação.4.2.5.9 Fechamento de IncidentesO Service Desk deve verificar se o incidente está totalmente resolvido e que osusuários estão satisfeitos e dispostos a aceitar o incidente pode ser fechado. OService Desk também deve verificar o seguinte:• Categorização encerramento. Verificar e confirmar que a categorizaçãoincidente inicial foi correta ou, onde a categorização posteriormenteacabou por ser incorreta, atualizar o registro para que uma categorizaçãofechamento correto é registrada para o incidente - que procuramaconselhar ou orientação do grupo de Resolução (s), se necessário.• Pesquisa de satisfação do usuário. Realizar uma pesquisa desatisfação do usuário de call-back ou e-mail para o percentual acordadode incidentes.• Documentação do incidente. Perseguir todos os detalhes pendentes egarantir que o registro de incidentes é totalmente documentado para queum registro completo histórico em um nível suficiente de detalhe écompleta.• Em curso ou recorrentes problema? Determinar (em conjunto com osgrupos resolvedor) se é provável que o incidente poderia ocorrer e decidirse qualquer acção preventiva é necessária para evitar isto. Em conjuntocom a Gerenciamento de Problemas, Levantar um registro de problemaem todos esses casos para que a ação preventiva é iniciada.ITIL V3 - Operação de Serviço - Página: 102 de 423
  • 103. • Formal fecho. Encerrar formalmente o Grave incidente.Nota: Algumas organizações podem optar por utilizar um período de fechamentoautomático em específico, ou mesmo todos, incidentes (por exemplo incidenteserá automaticamente fechado depois de dois dias úteis se mais contato é feitopela usuário). Onde esta abordagem deve ser considerado, ele deve primeiroser totalmente discutido e acordado com os usuários - e amplamente divulgadopara que todos os usuários e equipe de TI estão cientes disso. Pode serinapropriado para usar este método para certos tipos de incidentes - comoincidente graves ou aqueles que envolvem VIPs, etcRegras para reabertura incidentesApesar de todo o cuidado adequado, haverá ocasiões em que incidentes serepetir, apesar de terem sido formalmente fechado. Por causa de tais casos, éaconselhável ter regras pré-definidas sobre se e quando um incidente pode serreaberto. Pode fazer sentido, por exemplo, a concordar que, se persistir oincidente no prazo de um dia útil, então ele pode ser reaberto -, mas que paraalém deste ponto um novo incidente deve ser levantada, mas ligado ao incidenteanterior (s).O tempo exato limiar/ Regras podem variar entre organizações individuais - masregras claras devem ser acordados e documentados e orientação dada a todosService Desk pessoal, de modo que a uniformidade é aplicada.4.2.6 Triggers interfaces de entrada e saída / inter-processoIncidentes pode ser acionado de diversas maneiras. A rota mais comum équando um usuário toca o Posto de Serviço ou completa um web-based telaincidente registro, mas cada vez mais incidentes são criados automaticamenteatravés Gestão de Eventos ferramentas. A equipe técnica pode notar potencialfalhas e levantar um incidente, ou pedir o Service Desk para o fazer, de modoque a culpa podem ser abordados. Alguns incidentes podem também surgir noinício do fornecedors - que pode enviar alguma forma de notificação de umadificuldade potencial ou real que precisa de atenção.As interfaces com Gerenciamento de Incidentes incluem:• Gerenciamento de Problemas: Gerenciamento de Incidentes faz parte dototal processo de tratar problemas no organização. Os incidentes sãomuitas vezes causados por problemas subjacentes, que devem serresolvidos para evitar que o incidente se repita. Gerenciamento deIncidentes fornece um ponto onde estes são relatados.• Gerenciamento da Configuração fornece os dados utilizados paraidentificar e progredir incidentes. Uma das utilizações da CMS é identificarequipamento defeituoso e para avaliar a impacto de um incidente. ÉITIL V3 - Operação de Serviço - Página: 103 de 423
  • 104. também usado para identificar os utilizadores afectados por problemaspotenciais. O CMS também contém informações sobre as categorias deincidente deve ser atribuído a que grupo de apoio. Por sua vez,Gerenciamento de Incidentes pode manter a estado de CIs com defeito.Ele também pode ajudar Gerenciamento de Configuração para auditar ainfra-estrutura quando se trabalha para resolver um incidente.• Gestão da Mudança: Sempre que um mudar é necessário paraimplementar um solução alternativa ou resolução, este terá que serregistrada como um RFC e progrediu através do Gerenciamento deMudança. Por sua vez, Gerenciamento de Incidentes é capaz de detectare resolver os incidentes que surgem de mudanças fracassadas.• Gerenciamento da Capacidade: Gerenciamento de Incidentes fornece umgatilho para atuação monitoramento onde parece haver uma atuaçãoproblema. Gerenciamento da Capacidade pode desenvolver soluçõespara incidentes.• Gerenciamento de Disponibilidade; usará dados Gerenciamento deIncidentes para determinar a disponibilidade de De serviços de TIs e olharpara onde o incidente ciclo de vida pode ser melhorada.• SLM: A capacidade de resolver os incidentes em uma hora especificada éuma parte fundamental de entregar um nível acordado de serviço.Gerenciamento de Incidentes permite SLM para definir respostasmensuráveis para as interrupções de serviço. Ele também fornecerelatórios que permitem a SLM rever SLAs objetivamente e regularmente.Em particular, Gerenciamento de Incidentes é capaz de ajudar a definironde os serviços estão em seu ponto mais baixo, de modo que SLM podedefinir ações como parte da Melhoria de Serviço Programa (SIP) -consulte o Melhoria de Serviço Continuada publicação para maisdetalhes. SLM define os níveis aceitáveis de serviço em que obras degerenciamento de incidentes, incluindo:• Incidente tempo de respostas• Impacto definições• Alvo vezes fix• Definições de serviço, que são mapeados para usuários• Regras para serviços requerentes• Expectativas para fornecer feedback para usuários.4.2.7 Gestão da InformaçãoA maioria das informações utilizadas no Gerenciamento de Incidentes vem dasseguintes fontes:• As ferramentas de gerenciamento de incidentes, Que contêminformações sobre:• Incidente e problema história• Categorias de incidentes• Medidas tomadas para resolver os incidentesITIL V3 - Operação de Serviço - Página: 104 de 423
  • 105. • Script de diagnósticos, que pode ajudar os analistas de primeiralinha para resolver o incidente, ou pelo menos reunir informaçõesque irão ajudar os analistas de segunda ou terceira linha resolvê-lomais rápido.• Grave incidentes, Que incluem os seguintes dados:• Número de referência único• Incidente classificação• Data e hora da gravação e quaisquer atividades subseqüentes• Nome e identidade da pessoa gravar e atualizar o registro deincidentes• Nome /organização/ Detalhes de contato do usuário afetado (s)• Descrição dos sintomas de incidentes• Detalhes de quaisquer medidas tomadas para tentar diagnosticar,solucionar ou recriar o incidente• Incidente categoria,impacto,urgência e prioridade• Relação com outros incidentes, problemas, alterações ou ErroConhecidos• Fecho detalhes, incluindo o tempo, categoria, As medidas tomadase identidade de pessoa fechando a registro.Gerenciamento de Incidentes também exige o acesso ao CMS. Isso irá ajudá-loa identificar os CIs afetados pelo incidente e também para estimar o impacto doincidente.O Banco de Dados de erro conhecido fornece informações valiosas sobrepossível resoluçãos e solução alternativas. Isso é discutido em detalhes noparágrafo 4.4.7.2.4.2.8 MétricasO métricos que devem ser monitorados e reportados para julgar o eficiência eeficácia do Gerenciamento de Incidentes processo, Ea sua operação, Irãoincluir:• Número total de incidentes (como um controlar medida)• Distribuição dos incidentes em cada fase (por exemplo, registrado,trabalho em andamento,fechado etc)• Tamanho do backlog de incidentes atual• Número e percentual de incidente graves• O tempo médio para conseguir a resolução de incidentes ou evasão,discriminadas por código de impacto• Percentual de incidentes tratados dentro concordaram tempo de resposta(Incidentes de tempo de resposta alvos podem ser especificados nosSLAs, por exemplo, por impacto e urgência códigos)• Média custar por incidente• Número de incidentes reabertas e como uma percentagem do totalITIL V3 - Operação de Serviço - Página: 105 de 423
  • 106. • Número e percentual de incidentes atribuídos incorretamente• Número e percentual de incidentes classificados incorretamente• Percentual de Incidentes fechada pelo Service Desk sem referência aoutros níveis de apoio (muitas vezes referido como "o primeiro ponto decontato")• Número e porcentagem de incidentes processados por agente ServiceDesk• Número e percentagem de casos resolvidos remotamente, sem anecessidade de uma visita• Número de incidentes tratados por cada incidente Modelo• Distribuição dos incidentes por hora do dia, para ajudar a identificar egarantir picos de correspondência recursos.Os relatórios devem ser produzidos sob a autoridade do Gerente de Incidentes,que deverá elaborar um calendário e lista de distribuição, em colaboração com oService Desk e grupo de apoiomanipulação de incidentes s. As listas dedistribuição deve incluir pelo menos De serviços de TIs Gestão e especialistagrupo de apoios. Considere também tornando os dados disponíveis parausuários e clientes, por exemplo, através de relatórios de SLA.4.2.9 Desafios, Fatores Críticos de Sucesso e riscos4.2.9.1 DesafiosOs seguintes desafios irão existir para o sucesso Gerenciamento de Incidentes:• A capacidade de detectar incidentes tão cedo quanto possível. Issoexigirá educação da usuárioincidentes s relatórios, o uso de Super Users(ver parágrafo 6.2.4.5) e do configuração de Gestão de Eventosferramentas.• Convencer todo o pessoal (equipes técnicas, bem como usuários) quetodos os incidentes devem ser registrados, e incentivar o uso de auto-ajuda baseado na web capacidades (que pode acelerar a assistência ereduzir recursos exigências).• Disponibilidade de informações sobre problemas e Erro Conhecidos. Issovai permitir que a equipe de Gerenciamento de Incidentes de aprendercom incidentes anteriores e também para acompanhar o estado deresoluçãos.• Integração no CMS para determinar relaçãos entre IC e para se referir àhistória de CIs ao realizar suporte de primeira linha.• Integração na SLM processo. Isso vai ajudar Gerenciamento deIncidentes corretamente para avaliar a impacto e prioridade de incidentese auxilia na definição e execução escalada procedimentos. SLM tambémserão beneficiados com as informações aprendidas durante oGerenciamento de Incidentes, por exemplo, para determinar se nível deserviço atuação metas são realistas e realizáveis.ITIL V3 - Operação de Serviço - Página: 106 de 423
  • 107. 4.2.9.2 Fatores Críticos de SucessoOs seguintes fatores serão fundamentais para a Gestão de Incidentes desucesso:• Um bom Service Desk é a chave para o Gerenciamento de Incidentes desucesso• Objectivos claramente definidos que trabalhar para - conforme definido noSLA• Adequado clienteOrientada para o pessoal de apoio e tecnicamentetreinamento com os níveis de habilidade corretos, em todas as fases doprocesso de• Ferramentas de apoio integrados de conduzir e controlar o processo de• Olas e UCs que são capazes de influenciar e moldar o comportamentocorreto de todo o pessoal de apoio.4.2.9.3 RiscosO riscos para Gestão de Incidentes de sucesso são realmente semelhantes aalguns dos desafios e no verso de alguns dos Fator Crítico de Sucessosmencionados acima. Eles incluem:• Sendo inundados com incidentes que não podem ser tratados dentro deprazos aceitáveis devido à falta de disposição ou devidamente treinadosrecursos• Incidentes atolando e não progrediu como pretendido, porque deferramentas de suporte inadequados para levantar alertars e progressopronta• Falta de fontes de informação adequados e / ou oportuna porque deferramentas inadequadas ou falta de integração• Descasamentos de objetivos ou ações por causa de OLAs mal alinhadosou não-existente e / ou UCs.ITIL V3 - Operação de Serviço - Página: 107 de 423
  • 108. 4,3 Cumprimento de RequisiçãoO termo "Solicitação de ServiçoÉ utilizado como uma designação genérica paramuitos tipos diferentes de exigências que são colocadas em cima doDepartamento de TI pela usuários. Muitos deles são realmente pequenasmudanças - baixo risco, Que ocorrem com frequência, baixo custar, Etc (porexemplo, um pedido para alterar uma senha, um pedido para instalar umsoftware adicional aplicação em uma estação de trabalho especial, um pedidopara mudar alguns itens de equipamentos de mesa) ou talvez apenas umaquestão solicitando informações -, mas a sua escala e freqüentes, de baixo risconatureza significa que eles são melhor tratadas em separado por uma processo,Em vez de serem autorizados a congestionar e obstruir o incidente normal eGestão da Mudança processos.Finalidade 4.3.1 meta / / objetivoCumprimento de Requisição é o processo de lidar com solicitações de serviçodos usuários. O objetivos do processo de Cumprimento de Requisição incluem:• Para fornecer um canal para que os usuários solicitar e receber serviçosde padrão para que uma aprovação pré-definida e qualificação processoexiste• Para fornecer informações aos usuários e clientes sobre o disponibilidadede serviços e os procedimento para a obtenção• Para fonte e entregar o componentes de pedidos padrão de serviços (porexemplo, licenças de software e mídia)• Para ajudar com informações gerais, reclamações ou comentários.4.3.2 ÂmbitoO processo necessário para satisfazer um pedido variará dependendoexactamente o que está a ser pedido - mas pode ser geralmente dividido em umconjunto de actividades que têm de ser executadas. Algumas organizações vaiser confortável para que as solicitações de serviço ser tratado por meio de suaGerenciamento de Incidentes processos (e ferramentas) - com solicitações deserviço que está sendo tratado como um tipo particular de incidente(Utilizandouma classificação de alto nível sistema identificar os "incidentes" que estão emSolicitações de Serviço fato).Notar, contudo, que há uma diferença significativa aqui - um incidente égeralmente uma imprevista evento enquanto que uma solicitação de serviçogeralmente é algo que pode e deve ser planejado!Portanto, numa organização onde um grande número de solicitações de serviçotêm que ser tratados e onde as ações a serem tomadas para o cumprimentodesses pedidos são muito variados ou especializados, pode ser apropriado paraITIL V3 - Operação de Serviço - Página: 108 de 423
  • 109. lidar com solicitações de serviço como um fluxo de trabalho totalmente separada- e para gravar e gerenciá-los como um separado registro tipo.Isto pode ser particularmente apropriado se a organização optou por alargar oescopo do Service Desk para expandir apenas relacionados a TI questões eusar a mesa como um ponto focal para outros tipos ou solicitação de serviço -por exemplo, um pedido para atender a uma copiadora ou mesmo indo tão longea ponto de incluir, por exemplo, a construção de questões de gestão, tais comoa necessidade de substituir uma montagem de luz ou reparar um vazamento noencanamento.Nota: em última análise, caberá a cada organização decidir e documentar o queele vai lidar com pedido através do processo de Cumprimento de Requisição eque outros terão que passar por Change Management mais formal. Semprehaverá áreas cinzentas que impedem a orientação genérica de ser útil prescrito.4.3.3 Valor para os negóciosO valor de Cumprimento de Requisição é fornecer acesso rápido e eficaz aosserviços padrão que funcionários da empresa pode usar para melhorar suaprodutividade ou a qualidade de serviço de negócios e produtos.Cumprimento de Requisição efetivamente reduz a burocracia na solicitação erecebimento de acesso a serviços novos ou já existentes, reduzindo assim ocustar da prestação destes serviços. Centralizando cumprimento tambémaumenta o nível de controlar sobre esses serviços. Este por sua vez, podeajudar a reduzir custos através da negociação centralizada com fornecedors, epode também ajudar a reduzir o custo do suporte.4.3.4 Políticas / princípios / conceitos básicosMuitos Solicitação de Serviços será frequentemente recorrente, portanto, umpré-definido processo fluxo (a modelo) Pode ser concebido de modo a incluir asetapas necessárias para cumprir o pedido, a pessoas físicas ou grupo de apoiosenvolvidos prazos, alvo e escalada caminhos. Solicitações de serviçosgeralmente ser satisfeitas através da implementação de um Mudança Padrão(Veja a Transição de Serviço publicação para obter mais detalhes sobreAlterações padrão). A posse de solicitações de serviço reside com o ServiceDesk, Que monitora, escalada, expedições e muitas vezes cumpre a usuáriopedido.4.3.4.1 Modelos PedidoAlgumas solicitações de serviço irá ocorrer com freqüência e vai exigir lidar deuma forma consistente, a fim de atender concordou nível de serviços. Paraapoiar este, muitas organizações desejam criar modelos pré-definidos pedidoITIL V3 - Operação de Serviço - Página: 109 de 423
  • 110. (que normalmente incluem algum tipo de pré-aprovação por Gestão daMudança). Isto é similar em conceito à idéia de Modelos de Incidentes jádescritos no parágrafo 4.2.4.2, mas aplicada a solicitações de serviço.4.3.5 as atividades de processo, métodos e técnicas4.3.5.1 seleção do menuCumprimento de Requisição oferece grandes oportunidades de auto-ajudapráticas, onde os usuários podem gerar uma solicitação de serviço usando atecnologia que links em Serviço de Gestão de ferramentas. Idealmente, osusuários devem ser oferecido um seleção menu tipo através de uma interfaceweb, para que eles possam escolher e detalhes de entrada de solicitações deserviço a partir de uma lista pré-definidas, onde as expectativas apropriadaspode ser definido, dando entrega de destino e / ou implementação metas / datas(em linha com as metas de SLA). Onde as organizações estão oferecendo umaauto-ajuda de suporte de TI capacidade para os usuários, não faria sentido paracombinar isso com um Cumprimento de Requisição sistema como descrito.Ferramentas especializadas web para oferecer este tipo de experiência "carrinhode compras" pode ser utilizado em conjunto com interfaces diretamente para oback-end ferramentas integradas de ITSM, ou outra mais geral processo denegócio automação ou Enterprise Resource Planning (ERP), ferramentas quepodem ser utilizadas para o gerenciamento das atividades de Cumprimento deRequisição.4.3.5.2 aprovação FinanceiroUm importante passo extra que é provável que seja necessário quando se lidacom um solicitação de serviço é a de aprovação financeira.A maioria das solicitações terão alguma forma de implicações financeiras,independentemente do tipo de acordos comerciais no local. O custo de cumprir opedido deve primeiro ser estabelecida. Pode ser possível concordar preços fixospara "padrão" - e pedidos de aprovação prévia para tais pedidos pode ser dadocomo parte do organizaçãoS anual global gestão financeira. Em todos os outroscasos, uma estimativa do custo deve ser produzido e apresentado ao usuáriopara aprovação financeira (o usuário pode precisar de procurar aprovação a suagestão / cadeia financeira). Se a aprovação for dada, além de cumprir o pedido,a processo Deve também incluir carregamento (Faturamento ou a tarifação) parao trabalho feito - se a carga está no local.4.3.5.3 aprovação OutrosEm alguns casos a autorização adicional pode ser necessária - comorelacionados à conformidade ou aprovação mais ampla de negócios.ITIL V3 - Operação de Serviço - Página: 110 de 423
  • 111. Cumprimento de Requisição deve ter a capacidade de definir e verificar essasaprovações, quando necessário.4.3.5.4 CumprimentoO real cumprimento atividade irá depender da natureza do Solicitação deServiço. Alguns pedidos mais simples pode ser preenchido pelo Service Desk,Atuando como suporte de primeira linha, Enquanto outros terão de serencaminhados para grupos de especialistas e / ou fornecedors para ocumprimento.Algumas organizações podem ter grupos especializados de atendimento (parapegar, embalar e despachar ") - ou pode ter alguns terceirizados de atendimentoatividades para um fornecedor de terceiros (s). O Service Desk deve monitorar eperseguir o progresso e manter usuários informado durante todo,independentemente da fonte de realização real.4.3.5.5 EncerramentoQuando a solicitação de serviço foi cumprido deve ser remetido ao Service Deskpara fecho. O Service Desk devem passar pelo processo de encerramentomesmo como descrito anteriormente no ponto 4.2.5.9 - verificar se o usuárioestá satisfeito com o resultado.4.3.6 Triggers interfaces de entrada e saída / inter-processoA maioria dos pedidos será acionado, quer através de um usuário chamando oService Desk ou um usuário de completar alguma forma de auto-ajuda baseadona web tela de entrada para fazer seu pedido. Este último, muitas vezes,envolvem uma seleção de uma carteira de pedidos disponíveis types.Theinterfaces primárias com Cumprimento de Requisição incluem:• Service Desk /Gerenciamento de Incidentes: Solicitações de serviçospode vir em muitos através do Service Desk e pode ser inicialmentetratado através do processo de Gerenciamento de Incidentes. Algumasorganizações podem escolher que todos os pedidos são tratados por estavia - mas outros podem optar por ter um processo separado, por razões jádiscutidas anteriormente neste capítulo.• A forte ligação também é necessário entre Cumprimento de Requisição,Solte, Ativos e Gerenciamento da Configuração - Como alguns pedidosserá para o desenvolvimento de novo ou atualizado componentes quepode ser implantado automaticamente. Em tais casos, a "libertação" podeser pré-definido, construído e testado, mas só implantada a pedido poraqueles que querem a "libertação". Após a implantação, o CMS terá queser atualizado para refletir a mudar. Se for o caso, os cheques de licençade software / atualizações também será necessário.ITIL V3 - Operação de Serviço - Página: 111 de 423
  • 112. Se for caso disso, será necessário relacionar Pedidos relacionados a TI deserviço para qualquer incidentes ou problemas que iniciaram a necessidade parao pedido (como seria o caso em qualquer outro tipo de modificação).4.3.7 Gestão da InformaçãoCumprimento de Requisição depende das informações das seguintes fontes:• As solicitações de serviço conterá informações sobre:• O que serviço está sendo solicitado• Que tenha solicitado e autorizado o serviço• Que processo será usada para executar o pedido• A quem foi atribuído e que medidas foram tomadas• A data ea hora em que o pedido foi registrado, bem como a data ehora de todas as ações tomadas• Detalhes encerramento.• Pedidos de Alteração: Em alguns casos, a Cumprimento de Requisiçãoprocesso será iniciado por um RFC. Isto é típico em que o Solicitação deServiço refere-se a um IC• O Portfólio de Serviços, Para permitir que o escopo de solicitação deserviço concordou em ser identificado• Políticas de Segurança irá prescrever qualquer controle a ser executadoou cumprido aquando da prestação do serviço, por exemplo garantia deque o solicitante está autorizado a acessar o serviço, ou que o softwareestá licenciado.4.3.8 MétricasO métricos necessária para julgar a eficácia e eficiência de Cumprimento deRequisição irá incluir o seguinte (cada métrica precisa ser discriminadas por tipode pedido, dentro do prazo):• O número total de solicitações de serviço (como um controlar medida)• Composição da solicitação de serviços, em cada fase (e.g. logged WIP,fechado, Etc)• O tamanho da carteira atual de pedidos de serviço pendentes• A média de tempo para lidar com cada tipo de solicitação de serviço• O número ea porcentagem de solicitações de serviço concluído dentro devezes alvo acordados• A média custar por tipo de solicitação de serviço• Nível de cliente satisfação com o tratamento de solicitações de serviço(medido em alguma forma de pesquisa de satisfação).4.3.9 Desafios, Fatores Críticos de Sucesso e riscos4.3.9.1 DesafiosITIL V3 - Operação de Serviço - Página: 112 de 423
  • 113. Os seguintes desafios serão enfrentados ao introduzir Cumprimento deRequisição:• Claramente definir e documentar o tipo de solicitações que serão tratadasno processo de Cumprimento de Requisição (e aqueles que quer passarpelo Service Desk e ser tratado como um incidente ou aqueles queprecisam passar por formais Gestão da Mudança) - Para que todos ospartidos são absolutamente clara sobre o alcance.• Estabelecimento de auto-ajuda de front-end capacidades que permitem ausuários para interagir com sucesso com o Cumprimento de Requisiçãoprocesso.4.3.9.2 Fatores Críticos de SucessoA realização de pedido depende do seguinte Fator Crítico de Sucessos:• Acordo de que os serviços serão normalizados e que está autorizado asolicitá-los. O custar destes serviços também deve ser acordado. Istopode ser feito como parte do processo de SLM. Qualquer variaçãos dosserviços também deve ser definido.• Publicação dos serviços aos usuários, como parte do Catálogo deServiços. É importante que essa parte do Catálogo de Serviços deve serfacilmente acessados, talvez na Intranet, e deve ser reconhecida como aprimeira fonte de informação para os usuários que buscam acesso a umserviço.• Definição de um padrão cumprimento procedimento para cada um dosserviços a ser solicitados. Isto inclui todas as políticas de aquisição ecapacidade de gerar ordens de compra e ordens de serviço• Aúnico ponto de contato que pode ser usado para solicitar o serviço. Issoé muitas vezes fornecido pelo Service Desk ou por meio de um pedido deintranet, mas pode ser por meio de um pedido automatizado directamentepara o cumprimento de solicitação ou aquisição sistema.• De auto-atendimento ferramentas necessárias para fornecer umainterface de front-end para os usuários. É essencial que estes integraçãocom as ferramentas de back-end de atendimento, muitas vezes geridosatravés de Incidente ou Gestão da Mudança.4.3.9.3 RiscosRiscos que podem ser encontrados com Cumprimento de Requisição incluem:• Mal definidas escopo, Onde as pessoas não são claras sobre o queexatamente o processo é esperado para lidar com• Interfaces de usuário mal projetadas ou implementadas para que osusuários têm dificuldade em obter os pedidos que eles precisamITIL V3 - Operação de Serviço - Página: 113 de 423
  • 114. • Mal projetados ou operados de back-end processos de atendimento, quesão incapazes de lidar com o volume ou a natureza dos pedidos queestão sendo feitos• Inadequado monitoramento de modo que as capacidades exactasmétricos não podem ser recolhidas.ITIL V3 - Operação de Serviço - Página: 114 de 423
  • 115. 4,4 Gerenciamento de ProblemasITIL define um "problemaComo a causa de um ou mais incidentes.4.4.1 Finalidade objetivo / / objetivoGerenciamento de Problemas é o processo responsável pela gestão do ciclo devida de todos os problemas. O primário objetivos de Gerenciamento deProblemas são para evitar problemas e incidentes resultantes de acontecer,para eliminar incidentes recorrentes e minimizar o impacto de incidentes que nãopodem ser evitados.4.4.2 ÂmbitoGerenciamento de Problemas inclui as atividades necessárias para diagnosticaro causa raiz de incidentes e determinar o resolução para aqueles problemas.Também é responsável por assegurar que a resolução é implementado atravésda adequada controlar procedimentos, especialmente Gestão da Mudança eGerenciamento de Liberação.Gerenciamento de Problemas também vai manter as informações sobre osproblemas e apropriado solução alternativas e resoluções, de modo que osorganização é capaz de reduzir o número e impacto de incidentes ao longo dotempo. A este respeito, Gestão de Problemas tem uma interface com forteGestão do Conhecimento, E ferramentas como o Banco de Dados de erroconhecido serão utilizados para ambos.Apesar de Incidentes e Gestão de Problemas são processos separados, elesestão intimamente relacionados e geralmente usam as mesmas ferramentas, epodem usar categorização semelhante, impacto e prioridade codificaçãosistemas. Isto irá assegurar a comunicação eficaz ao lidar com incidentes eproblemas relacionados.4.4.3 Valor para os negóciosGerenciamento de Problemas trabalha em conjunto com Gerenciamento deIncidentes e Gestão da Mudança para garantir que De serviços de TIdisponibilidade e qualidade são aumentados. Quando os incidentes sãoresolvidos, informações sobre a resolução é gravado. Com o tempo, estainformação é utilizada para acelerar o tempo de resolução e identificar soluçõespermanentes, reduzindo o número eo tempo de resolução de incidentes. Istoresulta em menos tempo de inatividade e menos interrupções dos sistemascríticos de negócio.Valor adicional é derivado a partir do seguinte:ITIL V3 - Operação de Serviço - Página: 115 de 423
  • 116. • Maior disponibilidade de serviços de TI• Maior produtividade do negócio ea equipe de TI• Redução das despesas em soluções ou correções que não funcionam• Redução em custar esforço em combate a incêndios ou resolverincidentes repetidos.4.4.4 Políticas / princípios / conceitos básicosExistem alguns conceitos importantes de Gerenciamento de Problemas quedevem ser levados em conta desde o início. Estes incluem:4.4.4.1 Modelos de problemasMuitos problemas será única e vai exigir gerir de forma individual -, mas épossível que alguns incidentes possam ocorrer por causa de problemasdormentes ou subjacente (por exemplo, onde o custo de uma resoluçãopermanente será elevada e uma decisão foi tomada não ir em frente com umasolução cara - mas para "viver com o problema).Bem como a criação de um Grave erro conhecido no banco de dados de errosconhecidos (ver parágrafo 4.4.5.7) para garantir mais rápido diagnóstico, Acriação de um Problema Modelo para lidar com esses problemas no futuro podeser útil. Isto é muito similar em conceito à idéia de Modelos de incidentes jádescritos no parágrafo 4.2.4.2, mas aplicada a problemas, bem como incidentes.4.4.5 as atividades de processo, métodos e técnicasGestão problema consiste em dois processos principais:• Reativo Gerenciamento de Problemas, O qual é geralmente executadocomo parte da operação de serviço - e é, portanto, abrangidos nestapublicação• Gerenciamento de Problemas pró-ativa que é iniciada em Operação deServiço, Mas geralmente conduzido como parte da Melhoria de ServiçoContinuada.O Gerenciamento de Problemas reativa processo é mostrada na Figura 4.4. Esteé um gráfico simplificada para mostrar o fluxo de processo normal, mas narealidade, alguns estados pode ser iterativo ou variações podem ter que serfeitas, a fim de lidar com situações particulares.ITIL V3 - Operação de Serviço - Página: 116 de 423
  • 117. Figura 4.4 problema de fluxo de processo de Gestão de4.4.5.1 detecção de problemasÉ provável que as múltiplas formas de detectar problemas vai existir em todas asorganizações. Estas incluem:ITIL V3 - Operação de Serviço - Página: 117 de 423
  • 118. • Suspeita ou detecção de uma causa de um ou mais incidentes pelacentral de serviços, o que resulta numa Grave problema sendolevantadas - a mesa pode ter resolvido o incidente mas não determinouuma causa definitiva e suspeita que é provável que volte a ocorrer, entãovai levantar um registro de problema para permitir que a causa subjacentepara ser resolvido. Alternativamente, pode ser imediatamente óbvio desdeo início que um incidente, ou incidentes, foi causado por um problemaimportante, portanto, um registro de problema será levantado semdemora.• Análise de um incidente por um técnico grupo de apoio o que revela queexiste um problema subjacente, ou seja susceptível de existir.• Detecção automática de uma infra-estrutura ou aplicação culpa, Usandoevento/alertar ferramentas automaticamente para levantar um incidenteque pode revelar a necessidade de um registro de problema.• A notificação de um fornecedor ou contratante que existe um problemaque tem de ser resolvido.• Análise de incidentes como parte de Gerenciamento de Problemas pró-ativa - Resultando na necessidade de levantar um registro de problema,de modo que a falha subjacente pode ser investigada.Análise frequente e regular de dados de incidentes e problemas devem serrealizados para identificar as tendências que se tornam perceptíveis. Isso vaiexigir categorização significativo e detalhado de incidentes / problemas eapresentação de relatórios regulares de padrões e áreas de grande ocorrência.Top 10 de relatórios, com drill-down capacidades para níveis mais baixos, é útilna identificação de tendências.Mais detalhes de como detectado tendências devem ser manipulados sãoincluídos na publicação Melhoria de Serviço Continuada.4.4.5.2 registro ProblemaIndependentemente do detecção método, todos os detalhes relevantes doproblema devem ser registrados para que um histórico completo registro existe.Esta deve ser a data ea hora estampadas para permitir adequada controlar eescalada.Uma referência cruzada deve ser feito para o incidente (s) que iniciou o registrode problema - e todos os detalhes relevantes devem ser copiados do Graveincidente(S) para o registro de problema. É difícil ser exato, como casos podemvariar, mas geralmente isso irá incluir detalhes, tais como:• Usuário detalhes• Detalhes do serviço• Detalhes do equipamento• Data / hora inicialmente logadoITIL V3 - Operação de Serviço - Página: 118 de 423
  • 119. • Prioridade e detalhes de categorização• Descrição incidente• Detalhes de todos diagnóstico ou tentativa de recuperação açõestomadas.4.4.5.3 Categorização ProblemaOs problemas devem ser classificados na mesma maneira como incidentes (e éaconselhável utilizar os mesmos códigos sistema) De modo que a verdadeiranatureza da problema pode ser facilmente rastreada no futuro e significativagestão da informação podem ser obtidos.4.4.5.4 Priorização de ProblemasOs problemas devem ser priorizados na mesma forma e pelas mesmas razõescomo incidentes - mas a frequência e impacto de incidentes relacionadostambém devem ser levados em conta. A codificação sistema descritaanteriormente na Tabela 4.1 (que combina com impacto urgência para dar umnível de prioridade global) pode ser usado para dar prioridade problemas damesma forma que ele pode ser utilizado em caso de incidentes, embora asdefinições e orientação para suportar pessoal sobre o que constitui umproblema, e as respectivas serviço alvos em cada nível, tem, obviamente, serconcebido em separado.Prioritização problema deve também ter em conta a gravidade dos problemas.Gravidade neste contexto refere-se a quão sério é o problema do ponto de vistade infra-estrutura, por exemplo:• O sistema pode ser recuperado, ou ele precisa ser substituído?• Quanto vai custar?• Quantas pessoas, com o que habilidades, que serão necessários paracorrigir o problema?• Quanto tempo vai demorar para resolver o problema?• Quão extenso é o problema (por exemplo, quantos são afetados CIs)?4.4.5.5 Investigação e Diagnóstico de ProblemasUma investigação deve ser conduzida para tentar diagnosticar o causa raiz doproblema - a velocidade e natureza desta investigação irá variar dependendo daseveridade do impacto, e urgência do problema - mas o nível apropriado derecursos e perícia deve ser aplicada para encontrar um resolução proporcionalao código atribuída prioridade e o alvo de serviço no local para que o nível deprioridade.Há uma série de técnicas de resolução de problemas úteis que podem serusados para ajudar a diagnosticar e resolver problemas - e estes devem serITIL V3 - Operação de Serviço - Página: 119 de 423
  • 120. utilizadas como apropriado. Tais técnicas são descritas em mais detalhe maisadiante nesta secção.O CMS deve ser usada para ajudar a determinar o nível de impacto e paraajudar a identificar e diagnosticar o ponto exacto de falha. O Know banco dedados de erros (BDEC) também deve ser acessado e problema decorrespondência de técnicas (como pesquisas por palavras-chave) deve serusado para ver se o problema ocorreu antes e, em caso afirmativo, paraencontrar a resolução.Muitas vezes, é valiosa para tentar recriar o fracasso, de modo a entender o quedeu errado, e então tentar várias formas de encontrar o mais adequado erentável resolução ao problema. Para fazer isso de forma eficaz, sem causarmais perturbações ao usuários, uma teste sistema Será necessário que espelhaa ambiente de produção.Há muitos problemas de análise, diagnóstico e técnicas de resolução depesquisas disponíveis e muito tem sido feito nesta área. Algumas das técnicasmais úteis e freqüentemente usados incluem:• Análise cronológica: Ao lidar com um problema difícil, muitas vezes hárelatos conflitantes sobre o que exatamente aconteceu e quando. É,portanto, muito útil brevemente para documentar todos os eventos emordem cronológica - para fornecer um cronograma de eventos. Issomuitas vezes faz com que seja possível ver os eventos que pode ter sidoprovocado por outros - ou para descontar quaisquer reivindicações quenão são suportados pela seqüência de eventos.• Análise de Valor dor: Este é o lugar onde uma visão mais ampla é tomadoda impacto de um incidente ou problema ou incidente / problema tipo. Emvez de apenas analisar o número de incidentes / problemas de umdeterminado tipo em um determinado período, uma análise mais profundaé feito para determinar exatamente qual o nível de dor foi causada aoorganização/ Negócio por estes incidentes / problemas. A fórmula podeser concebido para calcular este nível de dor. Normalmente, isso podeincluir tendo em conta:• O número de pessoas afetadas• A duração do tempo de inatividade causado• O custar para o negócio (se este pode ser facilmente calculada ouestimada).Ao tomar todos esses fatores em conta, uma imagem muito maisdetalhada dos incidentes / problemas ou incidentes / problemas tipos queestão causando mais dor pode ser determinado - para permitir um focomelhor sobre as coisas que realmente importam e merecem maiorprioridade na resoluçãoITIL V3 - Operação de Serviço - Página: 120 de 423
  • 121. • Kepner e Tregoe: Charles Kepner e Benjamin Tregoe desenvolveu umamaneira útil de análise do problema, que pode ser usado formalmentepara investigar mais profundamente enraizados problemas. Eles definidapelas seguintes etapas:• definindo o problema• descrevendo o problema em termos de identidade, localização,tempo e tamanho• determinar eventuais causas• testando a causa mais provável• verificar a verdadeira causa.O método é descrito em maior detalhe no Apêndice C.• Brainstorming: Muitas vezes pode ser valiosa para reunir as pessoasrelevantes, seja fisicamente ou por meios electrónicos, e para "debater" oproblema - com pessoas jogando idéias sobre o que a causa potencialpode ser e possíveis ações para resolver o problema. Sessões debrainstorming pode ser muito construtiva e inovadora, mas é igualmenteimportante que alguém, talvez Gestor do Problema, documenta aresultado e as ações acordadas e mantém um grau de controlar nasessão (s).• Diagrama de Ishikawas: Kaoru Ishikawa (1915-1989), um líder emjaponês qualidade controle, desenvolveu um método de documentar ascausas e efeitos que podem ser úteis para ajudar a identificar onde algopode estar errado, ou ser melhorado. Tal esquema é tipicamente oresultado de um de brainstorming sessão em que solucionadores deproblemas pode oferecer sugestões. O objectivo principal é representadopelo tronco do diagrama, e os factores principais são representados comoramos. Factores secundários são então adicionados como hastes, eassim por diante. Criando o diagrama estimula a discussão e muitasvezes leva a uma maior compreensão de um complexo problema. Umdiagrama de exemplo é dado no Apêndice D.• Análise de Pareto: Esta é uma técnica de separação de importantescausas potenciais de questões mais triviais. Os seguintes passos devemser tomados:1. Faça uma tabela listando as causas e sua freqüência como umaporcentagem.2. Organize as linhas na ordem decrescente de importância das causas, ouseja, a causa mais importante primeiro.3. Adicionar uma coluna de percentagem cumulativa para a mesa. Por estaetapa, o gráfico deve ser algo como a Tabela 4.2, que ilustra 10 causasde rede falha num organização.Falhas na redeITIL V3 - Operação de Serviço - Página: 121 de 423
  • 122. Causas Percentagem do total Computação Acumulativo%Controlador de Rede 35 0% 35 35Corrupção de arquivo 26 35% 26% 61Resolução de conflitos 19 61% 19% 80Servidor OS 6 80% 6% 86Scripting erro 5 86% 5% 91Não testado mudar 3 91% 3% 94Erro do operador 2 94% 2% 96Falha de backup 2 96% 2% 98Tentativas de intrusão 1 98% 1% 99Falha de disco 1 99% 1% 100Tabela 4.2 Pareto ranking de causa4. Criar um gráfico de barras com as causas, na ordem de sua porcentagemdo total.5. Sobrepor um gráfico de linha das percentagens cumulativas. O gráficocompleto é ilustrado na Figura 4.5.6. Desenhar linha a 80% em relação ao eixo y paralelo ao eixo x. Emseguida, cair na linha, no ponto de intersecção com a curva sobre o eixox. Este ponto do eixo x separa as causas importantes e causas triviais.Esta linha é representada como uma linha tracejada na Figura 4.5.ITIL V3 - Operação de Serviço - Página: 122 de 423
  • 123. Figura 4.5 Importantes causas contra trivialA partir deste gráfico, é claro, para ver que há três causas principais para a redefalha no organização. Estes devem, por conseguinte, ser dirigida em primeirolugar.4.4.5.6 Soluções AlternativasEm alguns casos, pode ser possível encontrar um solução alternativa aosincidentes causados pela problema - Forma temporária de superar asdificuldades. Por exemplo, uma alteração manual pode ser feita a um ficheiro deentrada para permitir que um programa de completar com sucesso o seuITIL V3 - Operação de Serviço - Página: 123 de 423
  • 124. funcionamento e permitir a facturação processo para completarsatisfatoriamente, mas é importante que o trabalho de um permanente resoluçãocontinua quando tal se justifique - neste exemplo, a razão para o arquivo setornar corrompido, em primeiro lugar deve ser encontrada e corrigida para evitarque isso aconteça novamente.Nos casos em que uma solução é encontrada, por isso é importante que oregistro de problema permanece em aberto, e os detalhes da solução sãosempre documentado dentro do Grave problema.4.4.5.7 Levantando um registro de Erro ConhecidoLogo que o diagnóstico está completa, e em particular quando a solução foiencontrado (ainda que isto pode não ser ainda uma resolução permanente), umaGrave erro conhecido devem ser levantadas e colocadas na Banco de Dados deerro conhecido - De modo que, se mais incidentes ou problemas, eles podemser identificados e a serviço restaurarD mais rapidamente.No entanto, em alguns casos, pode ser vantajoso aumentar a Gravar ErroConhecido ainda mais cedo no processo global - apenas para efeitos deinformação, por exemplo, - o mesmo que o diagnóstico não pode ser completaou uma solução encontrada, por isso não é aconselhável para definir umquestão processual concreta exatamente quando um registro de Erro Conhecidodeve ser levantada. Isso deve ser feito tão logo torna-se útil para o fazer!A base de dados de erro conhecido e a forma como deve ser usada sãodescritas em mais pormenor no ponto 4.4.7.2.4.4.5.8 A resolução de problemasIdealmente, assim que uma solução foi encontrado, deverá ser aplicada pararesolver o problema - mas na realidade salvaguardas podem ser necessáriospara assegurar que este não causa dificuldades adicionais. Se algum mudar emtermos de funcionalidade é necessária isto exigirá um RFC para ser levantada eaprovados antes a resolução pode ser aplicado. Se o problema é muito grave euma correção urgente é necessária por razões de negócios, então uma RFC deemergência deve ser tratado pelo Emergency Change Advisory Board (ECAB).Caso contrário, o RFC deve seguir o estabelecido Gestão da Mudança processopara esse tipo de mudança - ea resolução deve ser aplicada apenas quando amudança foi aprovada e agendada para liberar. Enquanto isso, o BDEC deve serusado para ajudar a resolver rapidamente quaisquer outras ocorrências deincidentes / problemas que ocorrem.Nota: Pode haver alguns problemas para os quais um Business Case para aresolução não pode ser justificado (por exemplo, onde o impacto é limitado, maso custar de resolução seria extremamente elevado). Nesses casos, uma decisãoITIL V3 - Operação de Serviço - Página: 124 de 423
  • 125. pode ser tomada para deixar o Grave problema abrir, mas de usar umadescrição solução no registro de erro Conhecido para detectar e resolverquaisquer recorrências rapidamente. Cuidados devem ser tomados para usar ocódigo apropriado para marcar o registro de problema aberto para que ele nãoconta contra o atuação da equipa de execução do processo e de forma que oretrabalho não autorizado não ocorre.4.4.5.9 Encerramento ProblemaQuando qualquer mudar foi concluído (e com sucesso revered), e a resoluçãotem sido aplicada, o Grave problema Deve ser formalmente fechado - Como nocaso de ocorrerem relacionado Grave incidentes que ainda estão abertos. Averificação deve ser executada neste momento para garantir que o registrocontém uma descrição histórico completo de todos eventos - e se não, o registrodeve ser atualizado.O estado de qualquer relacionado Grave erro conhecido deve ser atualizadopara mostra que a resolução tenha sido aplicada.4.4.5.10 Revisão grande problemaDepois de todos os grandes problema (Conforme determinado pelaorganizaçãoS prioridade sistema), Enquanto ainda estão frescas as memóriasde análise deverá ser conduzida para aprender quaisquer lições para o futuro.Especificamente, a revisão deverá analisar:• Essas coisas que foram feitas corretamente• Essas coisas que foram feitas erradas• O que poderia ser feito melhor no futuro• Como prevenir a recorrência• Se houve qualquer responsabilidade de terceiros e se as ações deacompanhamento são necessários.Estas revisões podem ser usados como parte de atividades de treinamento econscientização para os funcionários de apoio - e as lições aprendidas devemser documentados em apropriada procedimentos, instrução de trabalhos, scriptde diagnósticos ou registros de erro conhecidas. O Gestor de Problemas facilitaa sessão e documentos todas as ações acordadas.O conhecimento aprendido com a revisão deve ser incorporado em uma serviçorever reunião com o empresa cliente para assegurar a cliente está ciente dasações e os planos para evitar futuras incidente graves ocorra. Isso ajuda amelhorar a satisfação do cliente e assegurar o negócio que Operação deServiços está a lidar com incidentes de maior responsabilidade e trabalhandoativamente para evitar que se repitam no futuro.ITIL V3 - Operação de Serviço - Página: 125 de 423
  • 126. 4.4.5.11 Os erros detectados no ambiente de desenvolvimentoÉ raro para qualquer novo aplicaçãos, ou sistemas de software liberars para sercompletamente erroLivre. É mais provável que, durante o teste de tais novasaplicações, sistemas ou versões de um sistema de prioridades serão utilizadospara erradicar o mais sério culpas, mas é possível que pequenas falhas não sãorectificadas - muitas vezes por causa do equilíbrio que tem de ser feita entre ofornecimento de novas funcionalidades para o negócio, o mais rapidamentepossível e garantir código totalmente livre de falhas ou componentes.Quando uma decisão é feita para lançar algo para o ambiente de produção queinclui deficiências conhecidas, estes devem ser registrados como ErrosConhecidos no BDEC, juntamente com detalhes de solução alternativas ouatividades de resolução. Deve haver um passo formal no teste de sinal fora-deque assegura que esta transferência ocorre sempre (ver Transição de Serviçopublicação).A experiência tem mostrado, se isso não acontecer, ele vai levar a um apoiomuito maior custars quando o usuários começar a sentir as falhas e aumentar osincidentes que têm de voltar a ser diagnosticado e resolvido tudo de novo!4.4.6 Triggers interfaces de entrada e saída / inter-processoA grande maioria dos Grave problemas será desencadeada em reação a um oumais incidentes, e muitos vão ser levantada ou iniciada através equipe deService Desk. Registros outro problema, e os correspondentes Registros de erroconhecido, pode ser desencadeada em testes, particularmente as últimas fasesde testes, como Usuário Teste de aceitação / Trials (UAT), se for tomada adecisão de ir em frente com um liberar mesmo que alguns culpas sãoconhecidos. Fornecedores podem desencadear a necessidade de algum Graveproblemas através da notificação de possíveis falhas ou deficiências conhecidasem seus produtos ou serviços (por exemplo, um aviso pode ser dado em relaçãoao uso de um CI em particular e um registro de problema pode ser aumentadopara facilitar a investigação pela equipe técnica da condição de CIs no prazo oorganizaçãoS Infraestrutura de TI).O primário relação entre Incidentes e Gerenciamento de Problemas foi discutidoem pormenor nos pontos 4.2.6 e 4.4.5.1. Outras interfaces-chave incluem oseguinte:• Transição de Serviço• Gestão da Mudança: Gerenciamento de Problemas assegura quetodo resoluçãos ou solução alternativas que requerem um mudar aum CI são submetidas através do Gerenciamento de Mudançaatravés de um RFC. Gestão da Mudança irá monitorar o progressodessas alterações e manter Gerenciamento de ProblemasITIL V3 - Operação de Serviço - Página: 126 de 423
  • 127. aconselhou. Gerenciamento de Problemas também está envolvidoem corrigir a situação causada pelas mudanças fracassadas.• Gerenciamento da Configuração: Gerenciamento de Problemasusa o CMS para identificar CIs com defeito e também paradeterminar a impacto de problemas e resoluçãos. O CMS tambémpode ser utilizado para formar a base para a BDEC e manter ouintegrar-se com os registos de problemas.• Gerenciamento de Liberação e Implantação: É responsável porrolando correções de problemas fora no viver ambiente. Elatambém ajuda a assegurar que o associado erro conhecidos sãotransferidos do desenvolvimento Banco de Dados de erroconhecido no banco de dados de erro vivos conhecidos.Gerenciamento de Problemas irá auxiliar na resolução deproblemas causados por falhas durante o processo de liberação.• Design de Serviços• Gerenciamento de Disponibilidade: Está envolvido com adeterminação de como reduzir tempo de inatividade e aumentar aprodutividade. Como tal, tem uma estreita relação com a Gestãode Problemas, especialmente as áreas pró-ativas. Grande parte dagestão da informação disponível no Gerenciamento de Problemasserá comunicada ao Gerenciamento de Disponibilidade.• Gerenciamento da Capacidade: Alguns problemas requereminvestigação pelas equipes de capacidade de gestão e técnicas,por exemplo, atuação questões. Gerenciamento da Capacidade irátambém ajudar a avaliar as medidas pró-ativas. Gerenciamento deProblema fornece informações gerenciais em relação ao qualidadedas decisões tomadas durante o Planejamento de Capacidadeprocesso.• De serviços de TI Continuidade: Problema atos de gestão comoum ponto de entrada Gerenciamento da Continuidade do Serviçoonde um problema significativo não for resolvido antes de começara ter um grande impacto sobre o negócio.• Melhoria de Serviço Continuada• Gerenciamento de Nível de Serviço: A ocorrência de incidentes eproblemas afeta o nível de prestação de serviços medidos pelaSLM. Gerenciamento de Problemas contribui para melhorias nanível de serviços, e suas informações de gestão é utilizado como abase de uma parte do SLA rever componentes. SLM tambémfornece parâmetros dentro dos quais obras Problema de gestão,como impacto informação e os efeitos sobre os serviços depropostas de resoluções e medidas pró-ativas.• Estratégia de Serviço• Gestão Financeira: Auxilia na avaliação do impacto das propostasresoluçãos ou solução alternativas, bem como Análise de Valordor. Gerenciamento de Problema fornece gestão da informaçãosobre o custar de resolver e prevenir problemas, que é usadoITIL V3 - Operação de Serviço - Página: 127 de 423
  • 128. como entrada para o orçamentação e contabilidade sistemas eCusto Total de Propriedade cálculos.4.4.7 Gestão da Informação4.4.7.1 CMSO CMS vai realizar detalhes de todo o componentes da Infraestrutura de TI bemcomo o relaçãos entre estes componentes. Ele vai atuar como uma fonte valiosapara o problema diagnóstico e para avaliar o impacto dos problemas (porexemplo, se este disco é baixo, os dados que estão no disco, o que serviçosusar esses dados, o que usuários usar esses serviços?). Como ele também irárealizar detalhes das atividades anteriores, ele também pode ser usado comouma fonte valiosa de dados históricos para ajudar a identificar as tendências oufraquezas potenciais - uma parte essencial do Gerenciamento de Problemaspró-ativa (Ver Melhoria de Serviço Continuada publicação).4.4.7.2 Banco de Dados Erro ConhecidoA finalidade de um Banco de Dados de erro conhecido é permitir oarmazenamento de conhecimento prévio de incidentes e problemas - e comoeles foram superados - para permitir mais rápido diagnóstico e resolução serepitam.O Grave erro conhecido deve manter detalhes exatos da culpa e os sintomasque ocorreram, juntamente com detalhes precisos de qualquer ação ou soluçãoalternativa de resolução que podem ser tomadas para restaurar o serviço e / ouresolver o problema. Um incidente contagem também será útil para determinar afrequência com que os incidentes são susceptíveis de se repetir e influenciar asprioridades, etcDeve notar-se que um Business Case para uma solução permanente paraalguns problemas pode não existir. Por exemplo, se um problema não provocarperturbações graves e existe uma solução e / ou o custar de resolver o problemasupera de longe os benefícios de uma solução permanente - então uma decisãopode ser tomada a tolerar a existência do problema. No entanto, será aindadesejável diagnosticar e implementar uma solução tão rapidamente quantopossível, que é onde o BDEC pode ser de ajuda.É essencial que os dados colocados na base de dados podem ser recuperadosrapidamente e com precisão. O Gerente de problema deve ser totalmentetreinado e familiarizado com os métodos de pesquisa / algoritmos usados pelobanco de dados selecionado e deve garantir que, quando cuidadosamente novoregistros são adicionados, os principais critérios relevantes da pesquisa sãocorretamente incluído.ITIL V3 - Operação de Serviço - Página: 128 de 423
  • 129. Cuidados devem ser tomados para evitar a duplicação de registros (ou seja, omesmo problema descrito em duas ou mais formas como registros separados).Para evitar isso, o Gerenciador de problema deve ser a única pessoa capaz deentrar em um novo recorde. Outro grupo de apoios deve ser permitida, e atéincentivado, para propor novos registros, mas estes devem ser controlados peloGerente problema antes de entrar no BDEC. Em grandes organizações, ondeGerenciamento de Problemas agentes existir em vários locais, mas um únicoBDEC é usado (recomendado!), um procedimento deve ser acordado entretodos os funcionários Gerenciamento de Problema para garantir que essaduplicação não pode ocorrer. Isso pode envolver a designação de apenas ummembro da equipe como Gerente BDEC central.A BDEC deve ser utilizado durante as fases de diagnóstico de incidentes eproblemas para tentar acelerar a resolução processo - E novos registos deve seradicionado tão rapidamente quanto possível quando um novo problema foiidentificado e diagnosticadas.Toda a equipe de suporte deve ser bem treinados e familiarizados com o valorque o BDEC pode oferecer e da forma como deve ser usado. Eles devem sercapazes prontamente para recuperar e utilizar os dados.Nota: Algumas ferramentas / implementações podem optar por delinear ErroConhecidos simplesmente pela alteração de um campo no original Graveproblema. Isto é aceitável, desde que o mesmo nível de funcionalidade estádisponível.A BDEC, como o CMS, faz parte de um grande Serviço do Sistema de Gestãodo Conhecimento (SKMS) ilustrado na Figura 4.6. Mais informação sobre osSKMS pode ser encontrada na Transição de Serviço publicação.ITIL V3 - Operação de Serviço - Página: 129 de 423
  • 130. Figura 4.6 Serviço do Sistema de Gestão do Conhecimento4.4.8 MétricasA seguir métricos devem ser usados para avaliar a eficácia e eficiência doGerenciamento de Problemas processo, Ou seu operação:• O número total de problemas registados no período (como uma medidade controlo)• O percentual de problemas resolvidos dentro SLA metas (ea porcentagemque não são!)• O número ea porcentagem de problemas que ultrapassou a sua metaresolução vezes• O acúmulo de problemas pendentes e da tendência (estática, reduzindoou aumentando?)• A média custar de tratamento de um problema• O número de grandes problemas (aberto e fechado e backlog)• A percentagem de grande problema Comentes realizados com sucesso• O número de Erro Conhecidos adicionados ao BDEC• A precisão da percentagem BDEC (a partir de auditars da base de dados)• O percentual de Comentários grande problema concluída com sucesso eno tempo.Todas as medidas devem ser discriminadas por categoria,impacto, Gravidade,urgência e prioridade e comparados com períodos anteriores.ITIL V3 - Operação de Serviço - Página: 130 de 423
  • 131. 4.4.9 Desafios, Fatores Críticos de Sucesso e riscosUm grande dependência para Gerenciamento de Problemas é oestabelecimento de um processo eficaz de Gestão de Incidentes e ferramentas.Isto irá assegurar que os problemas são identificados, logo que possível, e que àmedida que o trabalho é feito em grande parte pré-qualificação quanto possível.No entanto, é também crucial que os dois processos têm interfaces formais e detrabalho comum práticas. Isso significa o seguinte:• Ligando ferramentas de gerenciamento de incidentes e problemas• A capacidade de se relacionar e de Incidentes Grave problemas• O pessoal de segunda e terceira linha deve ter um bom trabalho relaçãocom a equipe na primeira linha• Certificar-se de que o negócio impacto é bem compreendida por todo opessoal que trabalha no problema resolução.Além disso, é importante que Gerenciamento de Problemas é capaz de usartodo o conhecimento e Gerenciamento de Configuração recursos disponível.Outra CSF é a formação contínua de pessoal técnico em ambos os aspectostécnicos do seu trabalho, bem como as implicações de negócios de serviços quesuportam e os processos que eles usamITIL V3 - Operação de Serviço - Página: 131 de 423
  • 132. 4,5 Gerenciamento de AcessoGerenciamento de Acesso é o processo de concessão de autorização usuárioodireito de usar um serviço, Enquanto impedindo o acesso a usuários não-autorizados. Também tem sido referido como Direitos Gestão ou Gestão deIdentidade em diferentes organizações.4.5.1 Finalidade objetivo / / objetivoGerenciamento de Acesso prevê o direito de que os usuários possam usar umserviço ou grupo de serviços. É, portanto, a execução de políticas e açõesdefinidas no Segurança e Gerenciamento de Disponibilidade.4.5.2 ÂmbitoGerenciamento de Acesso é efetivamente a execução de disponibilidade eGestão de Segurança da Informação, Na medida em que permite que oorganização para administrar o confidencialidade,disponibilidade e integridadede dados da organização e de propriedade intelectual.Gerenciamento de Acesso garante que os usuários têm o direito de usar umserviço, mas não garante que esse acesso está disponível em todos osmomentos acordados - esta é fornecida pelo Gerenciamento de Disponibilidade.Gerenciamento de Acesso é um processo que é executado por todos ostécnicos e Aplicação de Gestão de funçãos e não é geralmente uma funçãoseparada. No entanto, não é provável que seja um único controlar ponto decoordenação, geralmente em TI Gestão de Operações ou sobre o Service Desk.Gestão de acesso pode ser iniciada por um Solicitação de Serviço através doService Desk.4.5.3 Valor para os negóciosAccess Management fornece o seguinte valor:• Acesso controlado aos serviços garante que a organização é capaz demanter de forma mais eficaz o confidencialidade de suas informações• Os funcionários têm o nível de direito de acesso a executar as suastarefas de forma eficaz• Há menos probabilidade de erros feitos na entrada de dados ou nautilização de um serviço crítico por um utilizador inexperiente (porexemplo, produção controlar sistemas)• A capacidade de auditar utilização dos serviços e traçar o abuso deserviçosITIL V3 - Operação de Serviço - Página: 132 de 423
  • 133. • A capacidade mais facilmente para revogar o acesso direitos quandonecessário - uma importante segurança consideração• Pode ser necessária para regulamentar observância (Por exemplo, SOX,HIPAA, COBIT).4.5.4 Políticas / princípios / conceitos básicosGerenciamento de Acesso é o processo que permite usuários para utilizar osserviços que estão documentados no Catálogo de Serviços. É composto pelosseguintes conceitos básicos:• Acesso se refere ao nível e extensão da funcionalidade de um serviço oude dados que um usuário tem o direito de usar.• Identidade refere-se à informação sobre eles que os distingue como umindivíduo e que verifica a sua estado dentro do organização. Pordefinição, a identidade de um usuário é único para o usuário. (Isto éabordado com mais detalhe no ponto 4.5.7.1.)• Direitos (Também chamados de privilégios) referem-se às configuraçõesreais em que um usuário é fornecido acesso a um serviço ou grupo deserviços. Direitos típicos, ou níveis de acesso, incluem ler, escrever,executar, alterar, excluir.• Serviços ou grupos de serviços. A maioria dos usuários não usamapenas um serviço, E os usuários que executam um conjunto semelhantede atividades irá usar um conjunto semelhante de serviços. Em vez defornecer acesso a cada serviço para cada usuário separadamente, é maiseficiente para ser capaz de conceder a cada usuário - ou um grupo deusuários - o acesso a todo o conjunto de serviços que eles têm o direitode usar, ao mesmo tempo. (Isto é discutido em mais pormenor no ponto4.5.7.2.)• Serviços de Diretório refere-se a um tipo específico de ferramenta que éutilizada para gerenciar o acesso e direitos. Estes são discutidos naseção 5.8.4.5.5 as atividades de processo, métodos e técnicas4.5.5.1 Solicitação de acessoDe acesso (ou restrição) pode ser solicitado através de um qualquer número demecanismos, incluindo:• Um pedido padrão gerada pelo Recursos Humanos sistema. Issogeralmente é feito sempre que uma pessoa for contratado, promovido,transferido ou quando deixam a empresa• ARequisição de Mudança• ASolicitação de Serviço apresentadas através do Cumprimento deRequisição sistemaITIL V3 - Operação de Serviço - Página: 133 de 423
  • 134. • Ao executar um script pré-autorizado ou opção (por exemplo, o downloadde um aplicação a partir de uma preparação servidor como e quando elaé necessária).Regras para o pedido de acesso são normalmente documentados como parte doCatálogo de Serviços.4.5.5.2 VerificaçãoGestão de acesso precisa verificar cada pedido de acesso a uma De serviços deTI a partir de duas perspectivas:• Que o usuário solicitar o acesso é que eles dizem que são• Que eles têm um legítimo exigência para esse serviço.O primeiro categoria é geralmente obtida pelo usuário fornecendo o seu nomede usuário e senha. Dependendo da organização segurança políticas, o uso donome de usuário e senha são geralmente aceitos como prova de que a pessoa éum legítimo usuário. No entanto, para os serviços mais sensíveis identificaçãoadicional pode ser necessária (uso, biométricos de uma chave de acessoeletrônico ou dispositivo de criptografia, etc.)A segunda categoria vai exigir algum independente verificação, Que não seja opedido do utilizador. Por exemplo:• Notificação de Recursos Humanos que a pessoa é um funcionário novo erequer tanto um nome de usuário e acesso a um conjunto padrão deserviços• Notificação de Recursos Humanos que o usuário tenha sido promovido erequer acesso a adicional recursos• Autorização a partir de uma (adequada definida no processo) Gerente• Apresentação de um Solicitação de Serviço (Com provas), através daService Desk• Apresentação de um RFC (com provas) através de Change Management,ou a execução de um pré-definido Mudança Padrão• Apolítica afirmando que o usuário pode ter acesso a um serviço opcional,se eles precisarem.Para novos serviços, a Alteração do registro deve especificar quais usuários ougrupos de usuários terão acesso ao serviço. Gerenciamento de Acesso Emseguida, verifique se todos os usuários ainda são válidos e fornecerautomaticamente o acesso, conforme especificado no RFC.4.5.5.3 Prever direitosITIL V3 - Operação de Serviço - Página: 134 de 423
  • 135. Gerenciamento de Acesso não decide quem tem acesso a que De serviços deTIs. Em vez disso, Gestão de Acesso executa as políticas e regulamentosdefinidos durante Estratégia de Serviço e Design de Serviços. Gerenciamento deAcesso impõe decisões para restringir ou fornecer acesso, em vez de tomar adecisão.Assim que um usuário tenha sido verificada, Gestão de Acesso irá fornecer ousuário com direitos utilizar o requerido serviço. Na maioria dos casos, isso vairesultar em um pedido para cada equipe ou departamento envolvido no apoioque o serviço para tomar as medidas necessárias. Se possível, essas tarefasdevem ser automatizadas.Quanto mais papels e grupos que existem, o mais provável é que o conflito dopapel irá surgir. Conflito papel neste contexto se refere a uma situação em quedois papéis ou grupos específicos, se pertencer a um único usuário, vai criarproblemas com a separação de funções ou conflito de interesse. Exemplosincluem:• Um papel requer acesso detalhado, enquanto um outro papel que impedeo acesso• Dois papéis permitir que um usuário para executar duas tarefas que nãodevem ser combinados (por exemplo, um empreiteiro pode registrar suafolha de tempo para uma projeto e aprovar todos os pagamentos notrabalho para o mesmo projeto).Conflito papel pode ser evitada pela criação cuidadosa de funções e grupos,mas mais frequentemente são causadas por políticas e decisões tomadas forado Operação de Serviço - Seja pela empresa ou por diferentes equipes deprojeto de trabalho durante Design de Serviços. Em cada caso, o conflito deveser documentado e encaminhado para a das partes interessadass para resolver.Sempre funções e grupos são definidos, é possível que eles poderiam serdefinidas de forma demasiado ampla ou demasiado restritiva. Haverá sempre osusuários que precisam de algo um pouco diferente dos papéis pré-definidos.Nestes casos, é possível a utilização de papéis padrão e, em seguida, adicionarou subtrair direitos específicos, conforme necessário - semelhante ao conceitode linhas de base e Variantes em Gerenciamento da Configuração (VerTransição de Serviço publicação). No entanto, a decisão de fazer isso não estánas mãos do indivíduo operacional funcionários. Cada exceção deve sercoordenado pela Gerência de Acesso e aprovado através do processo deorigem.Gerenciamento de Acesso deve realizar um regular rever do papels e gruposque ele criou e gerenciar para garantir que eles são apropriados para osserviços que ele oferece e apóia - e obsoletos ou indesejados papéis / gruposdevem ser removidos.ITIL V3 - Operação de Serviço - Página: 135 de 423
  • 136. 4.5.5.4 status de identidade de MonitoramentoComo usuárioO trabalho na organização, Seus papéis mudam e assim tambémfazer as suas necessidades de acesso aos serviços. Exemplos de alteraçõesincluem:• Mudanças de emprego. Neste caso, o utilizador terá possivelmentenecessidade de acesso a serviços diferentes ou adicionais.• Promoções ou rebaixamentos. O usuário provavelmente vai usar omesmo conjunto de serviços, mas terá acesso a diferentes níveis defuncionalidade ou dados.• Transferências. Nesta situação, o utilizador pode ter acesso aexactamente o mesmo conjunto de serviços, mas de uma regiãodiferente, com trabalho diferente práticas e diferentes conjuntos de dados.• Demissão ou morte. De acesso precisa de ser completamente removidapara impedir que o nome de utilizador a ser utilizado como um segurançabrecha.• Aposentadoria. Em muitas organizações, um empregado que seaposenta ainda pode ter acesso a um conjunto limitado de serviços,incluindo benefícios sistemas ou sistemas que lhes permitem adquirir osprodutos da empresa a uma taxa reduzida.• Ação disciplinar. Em alguns casos, a organização exigirá uma restriçãotemporária para impedir o utilizador de aceder a alguns ou a todos osserviços que normalmente têm acesso. Deve haver um recurso noprocesso e ferramentas para fazer isso, ao invés de ter que excluir erestabelecer o acesso do usuário direitos.• Demissões. Se um trabalhador é demitido ou contratado, ou quando umaação legal seja tomada contra um cliente (Por exemplo, para falta depagamento para produtos comprados na internet), o acesso deve serrevogada imediatamente. Além disso, gerenciamento de acesso,trabalhando em conjunto com a Gestão de Segurança da Informação,deve tomar medidas activas para prevenir e detectar ações maliciosascontra a organização daquele usuário.Gerenciamento de Acesso deve entender e documentar o usuário típico Ciclo deVida para cada tipo de usuário e usá-lo para automatizar o processo. Asferramentas de gerenciamento de acesso deve fornecer recursos que permitemque um usuário para ser movida de um estado para outro, ou de um grupo paraoutro, de forma fácil e com um auditar trilha.4.5.5.5 acesso acompanhamento e rastreamentoGestão de acesso não só deve responder às solicitações. Também éresponsável por garantir que os direitos que eles têm prestado estão sendousados corretamente.ITIL V3 - Operação de Serviço - Página: 136 de 423
  • 137. A este respeito, monitorização e controlo de acesso devem ser incluídos nomonitoramento atividades de todos os técnicos e Aplicação de Gestão defunçãos e tudo Operação de Serviço processos.As exceções devem ser tratadas por Gerenciamento de Incidentes,Possivelmente usando Incident Modelos projetado especificamente para lidarcom o abuso de direitos de acesso. Deve notar-se que a visibilidade de taisacções deve ser restrito. Tornar esta informação disponível a todos os que têmacesso ao Gerenciamento de Incidentes sistema irá expor vulnerabilidades.Gestão de Segurança da Informação desempenha um papel vital papel paradetectar o acesso não autorizado e comparando-o com o direitos que foramfornecidos pela Gerenciamento de Acesso. Isso vai exigir o envolvimento degerenciamento de acesso na definição dos parâmetros para uso em ferramentasde detecção de intrusão.Gerenciamento de acesso também pode ser necessária para fornecer umregistro de acesso para serviços específicos durante as investigações forenses.Se um usuário é suspeito de violação de política, Uso inadequado de recursos,ou utilização fraudulenta de dados, gerenciamento de acesso pode ser obrigadoa fornecer provas de datas, horas e até mesmo conteúdo de acesso do usuárioaos serviços específicos. Isto é normalmente fornecido pelo Operacional pessoalde que serviço, Mas trabalhando como parte do Gerenciamento de Acessoprocesso.4.5.5.6 Remoção ou restritiva de direitosAssim como Access Management fornece direitos Para usar um serviço,também é responsável pela revogação de tais direitos. Novamente, isto não éuma decisão de que faz por si próprio. Em vez disso, ele irá executar asdecisões e políticas feitas durante Estratégia de Serviço e decisões de design etambém de gestores no organização.Removendo o acesso geralmente é feito nas seguintes circunstâncias:• Morte• Renúncia• Demissão• Quando o usuário mudou os papéis e não requer mais o acesso aoserviço• Transferência ou viajar para uma área onde o acesso regional diferentese aplica.Em outros casos, não é necessário para remover o acesso, mas apenas paraproporcionar restrições mais severas. Estas podem incluir a redução do nível deITIL V3 - Operação de Serviço - Página: 137 de 423
  • 138. tempo, ou a duração do acesso. Situações em que o acesso deve ser restritoincluem:• Quando o usuário mudou de função ou foi rebaixado e já não requer omesmo nível de acesso• Quando o usuário está sob investigação, mas ainda requer acesso aserviços básicos, tais como e-mail. Neste caso seu e-mail pode serobjecto de digitalização adicional (mas isso precisa ser tratado com muitocuidado e em total conformidade com a organização do política desegurança)• Quando um usuário está fora da organização em uma missão temporáriae não vai exigir o acesso a esse serviço por algum tempo.4.5.6 Triggers interfaces de entrada e saída / inter-processoGerenciamento de Acesso é desencadeada por um pedido de um ou maisusuários para acessar um serviço ou grupo de serviços. Isto poderia serprovenientes de qualquer dos seguintes:• Uma RFC. Este é mais freqüentemente usado para apresentações emgrande escala de serviços ou atualizações onde o direitos de um númerosignificativo de usuários precisam ser atualizados como parte do projeto.• ASolicitação de Serviço. Isso geralmente é iniciado através do ServiceDesk, Ou diretamente no Cumprimento de Requisição sistema, Eexecutado pelo técnico relevante ou Aplicação de Gestão de equipes.• A pedido dos humanos adequados pessoal Gestão de Recursos (quedeve ser canalizada através do Service Desk). Isto é normalmentegerada, como parte do processo para contratação, promoção, realocaçãoe rescisão ou aposentadoria.• O pedido do gerente de um departamento, que poderia ser a realizaçãode um RH papel, Ou que poderia ter tomado a decisão de começar a usarum serviço pela primeira vez.Gerenciamento de Acesso deve ser ligada aos processos de RecursosHumanos para verificar a usuárioS identificar, bem como para garantir que elestêm direito aos serviços que estão sendo solicitadas.Gestão de Segurança da Informação é uma tecla motorista para Gerenciamentode Acesso vez que irá proporcionar o segurança e as políticas de proteção dedados e ferramentas necessárias para executar Gerenciamento de Acesso.Gestão da Mudança desempenha um importante papel como meio paracontrolar os pedidos de acesso reais. Isto é porque qualquer pedido de acesso aum serviço é uma mudar, Embora seja geralmente processada como umMudança Padrão ou Solicitação de Serviço (Possivelmente usando uma modelo)Uma vez que os critérios de acesso foram acordados por SLM.ITIL V3 - Operação de Serviço - Página: 138 de 423
  • 139. SLM mantém a acordos para o acesso a cada serviço. Isso irá incluir os critériosde quem tem direito de acesso a cada serviço, o que o custar de que o acessoserá, se o nível adequado e que o acesso será concedido a diferentes tipos deusuário (por exemplo, gerentes ou funcionários).Há também uma forte relação entre a Gestão de Acesso e Gerenciamento daConfiguração. O CMS pode ser usado para armazenamento de dados einterrogados para determinar os detalhes de acesso atuais.4.5.7 Gestão da Informação4.5.7.1 IdentidadeO identidade de um usuário é a informação sobre eles que os distingue comoum indivíduo e que verifica seu status dentro da organização. Por definição, aidentidade de um usuário é único para o usuário. Uma vez que há casos em quedois usuários compartilham um pedaço comum de informação (por exemplo,eles têm o mesmo nome), a identidade é geralmente estabelecido usando maisdo que um pedaço de informação, por exemplo:• Nome• Endereço• Detalhes de contato, por exemplo, de telefone, endereço de e-mail, etc• Documentação física, por exemplo, carteira de motorista, passaporte,certidão de casamento, etc• Os números que se referem a um documento ou uma entrada numa basede dados, por exemplo, número de funcionários, número de contribuinte,número de identidade do governo, o número de carteira de motorista, etc• A informação biométrica, por exemplo, impressões digitais, imagens daretina, padrões de reconhecimento de voz, DNA, etc• Data de validade (se aplicável).A identidade do usuário é fornecida para qualquer pessoa com um legítimoexigência para acessar De serviços de TIs ou informação organizacional. Estaspodem incluir:• Funcionários• Empreiteiros• Vendedor pessoal (por exemplo, gerente de contass, pessoal de apoio,etc)• Clientes (especialmente na compra de produtos ou serviços através daInternet).A maioria das organizações vai verificar uma usuárioS identidade antes de sejuntar a organização solicitando um subconjunto da informação acima. O maisITIL V3 - Operação de Serviço - Página: 139 de 423
  • 140. seguro a organização, os tipos mais informações são necessárias e quanto maiscompletamente eles são verificados.Muitas organizações serão confrontados com a necessidade de acesso direitospara pessoal temporário ou ocasional ou contratantes /fornecedors. A gestão doacesso a esse pessoal muitas vezes se torna problemático - o acesso defechamento após o uso é muitas vezes tão difícil de gerir, ou mais, do queproporcionar acesso inicialmente. Bem definido procedimentos entre TI e RHdeve ser estabelecido que incluem prova de falhas cheques que garantemdireitos de acesso são removidos imediatamente que já não se justificam ourequerido.Quando um usuário tem acesso a um aplicação, Que já deveria ter sidoestabelecido pela organização (geralmente os Recursos Humanos ouSegurança Departamento) que o usuário é quem dizem que são.Neste ponto, todas as informações que está arquivado eo arquivo estáassociado a uma identidade corporativa, geralmente um número de empregadoou contratante e uma identidade que pode ser usado para acessar corporativorecursos e informações, geralmente uma identidade de usuário ou username euma senha de associado.4.5.7.2 Os usuários, grupos, funções e grupos de serviçoEnquanto cada usuário tem uma identidade individual, e cada De serviços de TIpode ser visto como uma entidade em seu próprio direito, muitas vezes é útilpara agrupá-los de modo que eles podem ser gerenciados mais facilmente. Àsvezes, os termos "perfil do usuário"Ou" modelo de usuário ou usuário papelSãousados para descrever este tipo de agrupamento.A maioria das organizações tem um conjunto padrão de serviços para todos osusuários individuais, independentemente da sua posição ou emprego (excluindoclientes - que não têm qualquer visibilidade aos serviços e processos internos).Estas incluem serviços como mensagens, automação de escritório, suporte adesktop, telefonia, etc Novos usuários são automaticamente fornecidos comdireitos de usar esses serviços.No entanto, a maioria dos usuários também têm algum papel especializado queeles desempenham. Por exemplo, para além dos serviços padrão, o utilizadortambém executa uma função de gestão de marketing, o que requer que eles têmacesso a alguns especializada de marketing e financeiros modelagemferramentas e dados.Alguns grupos podem ter única exigências - como campo ou trabalhadoresdomésticos que podem ter que discar ou usar Virtual Private Network (VPN),com implicações de segurança que podem ter de ser mais bem gerenciado.ITIL V3 - Operação de Serviço - Página: 140 de 423
  • 141. Para tornar mais fácil para Gerenciamento de Acesso para fornecer os direitosapropriados, ele usa um catálogo de todas as funções na organização e quais osserviços que suportam cada função. Este catálogo de funções deverá sercompilado e mantido pela Administração Acesso em conjunto com o RH e,muitas vezes, ser automatizado no Serviço de Diretórios ferramentas (versecção 5.8).Além de jogar diferentes papéis, os usuários também podem pertencer adiferentes grupos. Por exemplo, todos os contratantes são obrigados a registrarseus quadros de horários em um cartão de tempo dedicado Sistema, Que não éusado pelos funcionários. Gerenciamento de Acesso irá avaliar todas as funçõesque um usuário desempenha, bem como os grupos que eles pertencem egarantir que eles fornecem direitos de usar todos os serviços associados.Nota: Todos os dados sobre os usuários estarão sujeitos a legislação deprotecção de dados (isso existe na maioria das localizações geográficas de umaforma ou outra) por isso deve ser tratada e protegida como parte dosprocedimentos de segurança da organização.4.5.8 MétricasMétricos que podem ser usados para medir a eficiência e eficácia deGerenciamento de Acesso incluem:• Número de pedidos de acesso (Solicitação de Serviço, RFC, etc)• Instâncias de acesso concedido, por serviço,usuário, Departamento, etc• Instâncias de acesso concedida pelo departamento ou individuaisconcessão de direitos• Número de incidentes que requerem uma redefinição do acesso direitos• Número de incidentes causados por configurações de acesso incorretas.4.5.9 Desafios, Fatores Críticos de Sucesso e riscosCondições para sucesso Gerenciamento de Acesso incluem:• A capacidade de verificar a identidade de um usuário (que a pessoa é queeles dizem que são)• A capacidade de verificar a identidade da pessoa que aprova ouorganismo• A capacidade de verificar que um utilizador se qualifica para o acesso aum serviço específico• A capacidade de vincular os direitos de acesso múltiplo a um usuárioindividual• A capacidade para determinar o estado do utilizador em qualquer altura(por exemplo, para determinar se eles ainda são empregados doorganização quando fazer logon em um sistema)ITIL V3 - Operação de Serviço - Página: 141 de 423
  • 142. • A capacidade de gerenciar mudanças acesso de um usuário exigências• A capacidade de restringir direitos de acesso a usuários não autorizados• Um banco de dados de todos os usuários e os direitos que foramconcedidos.ITIL V3 - Operação de Serviço - Página: 142 de 423
  • 143. 4,6 As atividades operacionais de processos cobertos defases do ciclo de vida de outros4.6.1 Gestão da MudançaGestão da Mudança é primeiramente coberta no Transição de Serviçopublicação, mas há alguns aspectos da gestão da mudança que Operação deServiço funcionários estarão envolvidos em uma base dia-a-dia. Estes incluem:• Levantar e submeter RFCs como necessário para tratar de questõesoperação de serviço• Participação em reuniões ou CAB CAB / CE para garantir que a Operaçãode Serviço riscos, questões e opiniões são tidas em conta• Mudanças de execução, dirigidos pelo Gerenciamento de Mudanças,onde envolvem Operação de Serviço componente ou serviços• Fazendo as mudanças como dirigido por Gestão da Mudança onde elesenvolvem Operação de Serviço componente ou serviços• Ajudar a definir e manter alterar modelos relativas à Operação de Serviçocomponentes ou serviços• Receber alteração de horários e garantir que todo o pessoal Operação deServiço estão cientes e preparados para todas as alterações relevantes• Usando o Gerenciamento de Mudança processo por norma,operacionalTipo muda.4.6.2 Gerenciamento da ConfiguraçãoGerenciamento da Configuração é primeiramente coberta no Transição deServiço publicação, mas há alguns aspectos do Gerenciamento de Configuraçãoque o pessoal Operação de Serviço serão envolvidos em uma base dia-a-dia.Estes incluem:• Gerenciamento de Configuração informar de quaisquer discrepânciasencontradas entre qualquer CIs e do CMS• Fazendo as alterações necessárias para corrigir eventuais discrepâncias,sob a autoridade do Gerenciamento da Configuração, Onde se envolvequaisquer componentes do serviço de operação ou serviços.Responsabilidade pela actualização do CMS permanece com gerenciamento deconfiguração, mas em alguns casos equipe de operações pode ser solicitado,sob a direção de Gerenciamento de Configuração, para atualizar relaçãos, ouaté mesmo para adicionar novo CIS ou marca CIS como eliminados no CMS,se essas atualizações são relacionadas às atividades operacionais efetivamenterealizadas pela equipe de Operações.ITIL V3 - Operação de Serviço - Página: 143 de 423
  • 144. 4.6.3 Gerenciamento de Liberação e ImplantaçãoGerenciamento de Liberação e Implantação é principalmente coberta napublicação Transição de Serviço, mas há alguns aspectos deste processo que opessoal Operação de Serviço será envolvido em uma base dia-a-dia. Estespodem incluir:• Reais ações de implementação em relação ao desenvolvimento de novoliberars, sob a direção de Gerenciamento de Liberação e Implantação,onde eles se relacionam com os componentes de serviço de operação ouserviços• A participação no planejamento estágios de grandes lançamentos paraaconselhar sobre questões operação de serviço• A movimentação física de instituições de crédito de / para o DML comonecessário para cumprir seu operacional papels - ao aderir ao lançamentorelevante e Gestão de Implantação procedimentos, como garantir quetodos os itens são devidamente reservado e para trás dentro4.6.4 Gerenciamento da CapacidadeGerenciamento da Capacidade deveria operar em três níveis: Gerenciamento daCapacidade de negócios,Gerenciamento da Capacidade de serviço e RecursoGerenciamento da Capacidade.• Gerenciamento da Capacidade de negócios envolve o trabalho com aempresa para planejar e antecipar tanto de longo prazo estratégicoquestões e de curto prazo tático iniciativas que possam vir a ter umimpacto em TI capacidade.• Gerenciamento da Capacidade de serviço é sobre a compreensão dascaracterísticas de cada um dos De serviços de TIs, e, em seguida, aexigência de que os diferentes tipos de usuários ou transaçãos ter sobrea infra-estrutura subjacente - e como estes variam ao longo do tempo epode ser afetado pelo negócio mudar.• Recurso Gerenciamento da Capacidade envolve a compreensão daatuação características e capacidades e níveis de utilização de correntesde todos os aspectos técnicos componentes (IC) que compõem oInfraestrutura de TI, E prever a impacto de quaisquer alterações outendências.Muitas dessas atividades são de caráter estratégico ou de longo prazoplanejamento natureza e são abordados na Estratégia de Serviço, Design deServiços e Transição de Serviço publicações. No entanto, há um número deoperacional Capacidade de actividades de gestão que devem ser executadasem uma base regular e contínua, como parte de Operação de Serviço. Estesincluem os seguintes.ITIL V3 - Operação de Serviço - Página: 144 de 423
  • 145. 4.6.4.1 Capacidade e Performance MonitoringTodos componentes da Infraestrutura de TI deve ser continuamente monitorado(em conjunto com Gestão de Eventos) De modo que qualquer potencialproblemas ou tendências podem ser identificadas antes falhas ou atuaçãodegradação ocorre. Idealmente, tais monitoramento deve ser automatizada elimiars deve ser definido de modo que a exceção alertars são criados em tempode permitir adequada evitando ou recuperação ação a ser tomada antes doimpacto adverso ocorre.Os componentes e os elementos a serem monitorizadas irá variar dependendoda infra-estrutura a ser utilizado, mas será tipicamente incluem:• Utilização da CPU (global e discriminadas por sistema/serviço uso)• Utilização de memória• Taxas de ES (física e buffer) e utilização de dispositivo• Comprimento da fila (máxima e média)• Utilização arquivo de armazenamento (discos, partições segmentos)• Aplicaçãos (rendimento taxas, taxas de falha)• Bancos de dados (utilização, registro fechaduras, indexação, decontenção)• Rede transação taxas, erro e repetir as taxas de• Transação tempo de resposta• Duração perfis lote• Internet / intranet do site / página taxas de acerto• Internet tempos de resposta (externos e internos para firewalls)• Número de sistema / aplicação de log-ons e usuários simultâneos• Número de nós de rede em uso, e os níveis de utilização.Existem diferentes tipos de ferramentas de monitoramento necessários paracoletar e interpretar dados em cada nível. Por exemplo, algumas ferramentaspermitem o desempenho de transações de negócios a ser monitorado, enquantooutros vão monitorar CI comportamento.Gerenciamento da Capacidade deve configurar e calibrar alarme limiars (quandonecessário, em conjunto com Gestão de Eventos, Como é muitas vezesferramentas de monitorização de eventos que podem ser utilizados), de modoque a correcta alertar níveis são estabelecidos, e que qualquer filtragem éestabelecido como necessário de modo a que apenas significativo eventos sãolevantadas. Sem essa filtragem é possível que a "informação apenas alertaspodem obscurecer alertas mais significativos que exigem atenção imediata.Além disso, é possível que grave falhas para causar "alerta tempestades" devidoa volumes muito altos de alertas repetidos, que novamente deve ser filtrada paraque as mensagens mais significativas não são obscurecidos.ITIL V3 - Operação de Serviço - Página: 145 de 423
  • 146. Pode ser apropriado para uso externo, de terceiros, monitoramento capacidadespara alguns itens de configuração ou componentes da Infraestrutura de TI (Porexemplo, sites de Internet Key / páginas). Gestão de capacidade deve serenvolvido em ajudar especificar e selecionar qualquer capacidade deacompanhamento e na integração dos resultados ou eventuais alertas comacompanhamento outro e manipulação sistemas.Gerenciamento da Capacidade de trabalhar com todas as medidas adequadasgrupo de apoios para tomar decisões sobre onde os alarmes são encaminhadase em escalada caminhos e prazos. As indicações deverão ser registrados noService Desk bem como para o pessoal de apoio apropriado, de modo queadequado Grave incidentes pode ser levantado para uma permanente registrodo evento existe - e equipe de Service Desk ter uma visão de como o grupo deapoio(S) está lidando com a culpa e pode intervir se necessário.Fabricantes alegou atuação capacidades e concordou meta de nível de serviços,juntamente com o desempenho histórico real monitorados e os dados decapacidade, devem ser utilizados para definir níveis de alerta. Isto podenecessitar de ser um processo iterativo processo inicialmente, realizar algunsajustes de tentativa e erro, até que os níveis corretos sejam alcançados.Nota: Gerenciamento da Capacidade pode ter que se envolver no capacidadeexigências e capacidades de IT Service Management. Se o organização Aequipe tem bastante serviço para lidar com a taxa de incidentes; se a estruturaCAB pode lidar com o número de mudanças que está sendo solicitada a rever eaprovar, se ferramentas de suporte pode lidar com o volume de dados que estãosendo coletados são questões capacidade de gestão, que a equipe de Gestãode Capacidade podem ser feitas para ajudar a investigar e responder.4.6.4.2 capacidade ou manipulação desempenho incidentesrelacionadosSe um alerta é acionado, ou um incidente é gerado no Service Desk, causadapor uma capacidade de corrente ou em curso ou Gestão de Desempenhoproblema, Gerenciamento de Capacidade deve envolver-se para identificar acausa e encontrar uma resolução. Trabalhando em conjunto com a adequadasuporte técnico grupos, e ao lado Gerenciamento de Problemas, Todas asinvestigações necessárias devem ser realizados para detectar exatamente o quedeu errado eo que é necessário para corrigir a situação.Pode ser necessário mudar a monitorização mais detalhada durante a fase deinvestigação para determinar a causa exata. O monitoramento é geralmentedefinida em um "fundo" nível em circunstâncias normais devido à grandequantidade de dados que podem ser gerados e evitar colocar muito alto umfardo sobre a infra-estrutura de TI - mas quando as dificuldades específicasITIL V3 - Operação de Serviço - Página: 146 de 423
  • 147. estão sendo investigados monitoramento mais detalhado pode ser necessáriapara identificar a causa exata.Quando uma solução ou uma solução potencial, foi encontrado, as alteraçõesnecessárias para resolver o problema deve ser aprovada através formais Gestãoda Mudança antes da implementação. Se a falha está causando gravesperturbações e uma resolução de urgência é necessária, urgente mudarprocesso deve ser usado. É muito importante que não "afinação"Ocorre semsubmissão através do Gerenciamento de Mudança, pois mesmo aparentementepequenos ajustes muitas vezes pode ter grandes efeitos cumulativos - por vezesem toda a infraestrutura de TI inteira.4.6.4.3 Capacidade e tendências de desempenhoGerenciamento da Capacidade tem um papel a desempenhar na identificaçãode qualquer capacidade ou as tendências de desempenho como eles se tornamperceptíveis. Mais pormenores sobre as acções necessárias para resolver taistendências estão incluídos no Melhoria de Serviço Continuada publicação.4.6.4.4 Armazenamento de dados de gerenciamento de capacidadeGrandes quantidades de dados são usualmente gerados através capacidade eatuação monitoramento. Monitoramento de metros e tabelas de apenas algunspoucos kbytes cada um pode crescido rapidamente em arquivos enormes semuitos componentes estão a ser monitorizados em intervalos relativamentecurtos. Outro problema com o controlo muito curto prazo é de que não é possívela obtenção de uma informação significativa sem olhar ao longo de um períodomais longo. Por exemplo, um único instantâneo de um processador irá mostrar odispositivo a ser ou "ocupado" ou "inactivo" - mas um resumo sobre, porexemplo, um período de 5 minutos irá mostrar o nível médio de utilizaçãodurante o mesmo período, o que é um tanto medida mais significativa se odispositivo é capaz de trabalhar confortavelmente, ou se o desempenhopotencial problemas são prováveis de ocorrer.Em qualquer organização é provável que os instrumentos de controlo utilizadosirá variar muito - com uma combinação de sistemaFerramentas específicas,muitos deles parte do sistema operacional básico, e ferramentas especializadasde monitoramento a ser utilizados. A fim de coordenar os dados que estãosendo gerados e permitir a retenção de dados úteis para fins de análise etendências, alguma forma de repositório central de dados para a realizaçãodesta resumo é necessário: um Gerenciamento da Capacidade Sistema deInformação (CMIS).O formato, localização e projeto dessa base de dados deve ser planejado eimplementado com antecedência - ver o Design de Serviços publicação paraITIL V3 - Operação de Serviço - Página: 147 de 423
  • 148. mais detalhes - mas haverá algum operacional para lidar com aspectos, taiscomo limpeza de banco de dados e apoios.4.6.4.5 Gerenciamento da DemandaGerenciamento da Demanda é o nome dado a uma série de técnicas que podemser usadas para modificar a procura de um determinado recurso ou serviço.Algumas técnicas de gestão da procura pode ser planejado com antecedência, eestes são abordados com mais detalhes na publicação Service Design. Noentanto, há outros aspectos da gestão da procura, que são de natureza maisoperacional, exigindo mais curto prazo a ação.Se, por exemplo, o desempenho de um determinado serviço, está a causarpreocupação, a curto prazo e restrições simultaneidade de usuários sãonecessárias para permitir melhorias de desempenho para um pequeno gruporestrito, em seguida, Operação de Serviço funçãos terá que tomar medidas paraimplementar tais restrições - geralmente acompanhada de acções concorrentespara implementar o registro fora de usuários que estiveram inativos por umperíodo de tempo acordado para liberar recursos para outros.4.6.4.6 Workload ManagementPode haver ocasiões em que a otimização dos recursos de infra-estrutura énecessária para manter ou melhorar o desempenho ou rendimento. Isso muitasvezes pode ser feito através de Workload Gestão, que é um termo genérico paracobrir tais ações como:• Reprogramação de um determinado serviço ou carga de trabalho paraexecutar em um horário diferente do dia, ou do dia da semana, etc(geralmente longe do pico vezes para fora do pico janelas) - que, muitasvezes, significa ter que fazer ajustes para trabalho de agendamento desoftware.• Mover um serviço ou carga de trabalho de um local ou conjunto de CIspara outro - muitas vezes para equilibrar a utilização ou tráfego.• Virtualização técnica: criação e utilização de sistemas de virtualizaçãopara permitir o movimento de processamento em torno da infra-estruturapara dar um melhor desempenho /resiliência de um modo dinâmico.• Limitar ou mover demanda de recursos por meio de técnicas de gestão dademanda (ver acima e também a publicação de Desenho de Serviço).Só será possível gerenciar cargas de trabalho de forma eficaz se existe um bomentendimento de que as cargas de trabalho será executado em que momento equanto a utilização de recursos cada lugares de carga de trabalho sobre a infra-estrutura de TI. Diligente monitoramento e análise de carga de trabalhos énecessário, portanto, uma base operacional em andamento.ITIL V3 - Operação de Serviço - Página: 148 de 423
  • 149. 4.6.4.7 Modelação e aplicações de dimensionamentoModelagem e / ou dimensionamento de novos serviços e / ou aplicaçãos devem,se adequado, ser feito durante o planejamento fases e de transição - ver aDesign de Serviços e Transição de Serviço publicações. No entanto, o Operaçãode Serviço funçãos têm uma papel a desempenhar na avaliação da precisão dasprevisões e realimentando quaisquer problemas ou discrepâncias.4.6.4.8 Planejamento de CapacidadeDurante Design de Serviços e Transição de Serviço, o capacidade exigências deDe serviços de TIs são calculados. A prospectiva plano de capacidade deve sermantido e atualizado regularmente e Operação de Serviço terá um papel adesempenhar. Tal plano deve olhar para a frente até dois anos ou mais, masdeve ser revered regularmente a cada três a 12 meses, dependendo davolatilidade e dos recursos disponíveis.O plano deve ser ligada ao organizaçãoO ciclo de planejamento financeiro, demodo que qualquer despesa necessária para atualizações de infra-estrutura,melhorias ou adições podem ser incluídos no orçamento estimativas eaprovados com antecedência.O plano deve prever o futuro, mas também deve examinar e informar sobre asprevisões anteriores, particularmente para dar alguma confiança nas previsõesfuturas. Onde as discrepâncias foram encontradas, elas devem ser explicadas emedidas correctivas futuro descrito.O Plano de Capacidade pode geralmente cobrem:• Atuais detalhes de desempenho e utilização, com as recentes tendênciaspara todos os itens de configuração chave, incluindo• Redes de backbone• LANs• Mainframes (se ainda utilizado)• Chave servidors• Principais dispositivos de armazenamento de dados• Equipamentos selecionados desktop (representante) e laptop• Principais sites• Bases de dados-chave• Chave aplicaçãos• Operacional capacidade - eletricidade espaço, capacidade,ambientais (ar-condicionado), com peso de piso, a geração decalor e saída, a demanda elétrica e abastecimento de água e etc• Meios magnéticos.• Estimado atuação e utilização para todos os CIs tal durante o período deplanejamento (por exemplo, os próximos três meses)ITIL V3 - Operação de Serviço - Página: 149 de 423
  • 150. • Os dados comparativos com as estimativas anteriores - para permitir quea confiança nas estimativas futuras para ser julgado• Relatórios sobre qualquer específico capacidade dificuldades encontradasno período passado, com detalhes de recuperação e as açõespreventivas tomadas para o futuro• Pormenores de quaisquer atualizações necessárias ou dos contratosnecessários e previstos para o futuro, com indicativos custars e prazos.• Quaisquer riscos capacidade potencial que provavelmente - com sugeridocontramedidas caso venham a ocorrer.4.6.5 Gerenciamento de DisponibilidadeDurante Design de Serviços e Transição de Serviço,De serviços de TIs sãoconcebidos para disponibilidade e recuperação. Operação de Serviço éresponsável por realmente fazer o serviço de TI disponíveis para o especificadousuários no momento necessário e nos níveis acordados.Durante operação de serviço as equipes de TI e usuários estão na melhorposição para detectar se os serviços realmente cumprir o acordado exigências, ese o projeto destes serviços é eficaz.O que parece ser uma boa idéia durante a fase de projeto não pode realmenteser prático ou ótima. A experiência dos usuários e operacional funçãos faz umaentrada principal para a melhoria contínua dos serviços existentes e do design.No entanto, há um número de desafios com acesso a este conhecimento:• A maioria das experiências das equipes operacionais e os usuários sãoou informal, ou se espalhar através de múltiplas fontes.• O processo para recolha e tratamento destes dados precisa serformalizado.• Usuários e do pessoal operacional geralmente são totalmente ocupadocom suas atividades regulares e tarefas e é muito difícil para eles seenvolver em regular planejamento e atividades de design. Um argumentofreqüentemente feita aqui é que se o projeto é melhorada, as equipesoperacionais serão menos ocupado resolvendo problemas e, portanto,têm mais tempo para se envolver em atividades de projeto. No entanto,prática mostra que, assim como o pessoal são liberados, eles muitasvezes se tornam o alvo de exercícios de redução de efectivos.Dito isto, há três principais oportunidades para o pessoal operacional a serenvolvidos em Melhoria de disponibilidade, uma vez que estes são geralmentevistos como parte da sua responsabilidade em curso:• Comente das atividades de manutenção. Design de Serviços irá definiras programações de manutenção detalhada e actividades, que sãoITIL V3 - Operação de Serviço - Página: 150 de 423
  • 151. necessários para mantê-lo funcionando serviços no nível requerido deatuação e disponibilidade. Comparação regular de atividades reais demanutenção e horas com a planos vai destacar as áreas potenciais demelhoria. Uma das fontes dessas informações é uma revisão de seObjetivo de manutenção do serviços foram atendidas e, se não, por quenão.• Principais opiniões problema. Problemas podem ser o resultado dequalquer número de factores, um dos quais é má concepção. Opiniõesproblema, portanto, pode incluir oportunidades para identificar melhoriaspara o design de serviços de TI, que incluem disponibilidade e melhoriada capacidade.• Envolvimento em iniciativas específicas, utilizando técnicas como aAnálise de Falhas de Serviço (SFA), Componente Análise de Impactofalha (ACIA), ou Análise da Árvore de Falhas (FTA) ou como membros deObservation técnica (TO) atividades - como parte do acompanhamento àsprincipais problemas ou como parte de um processo contínuo serviçomelhoria programa, Em colaboração com a dedicada Gerenciamento deDisponibilidade pessoal. Estes Gerenciamento de Disponibilidadetécnicas são explicadas em mais detalhe no Design de Serviçospublicação.Pode haver ocasiões em que Operacional Equipe se precisa tempo deinatividade de um ou mais serviços para que possam realizar suas atividadesoperacionais ou de manutenção - que pode impacto sobre a disponibilidade senão for devidamente programado e controlado. Em tais casos, deve entrar emcontacto com SLM e equipe de gerenciamento de disponibilidade - que vainegociar com os usuários de negócios /, muitas vezes usando o Service Deskpara efectuar esta papel, Concordar e agendar tais atividades.4.6.6 Gestão do ConhecimentoÉ de vital importância que todos os dados e informações que podem ser úteispara o futuro Operação de Serviço atividades são devidamente recolhidos,armazenados e avaliados. Dados relevantes, métricos e informação deve serpassada em cima da cadeia de gestão e de outro Serviço Ciclo de Vida fasespara que possa alimentar as camadas de conhecimento e sabedoria doorganizaçãoS Serviço do Sistema de Gestão do Conhecimento, As estruturasde que têm de ser definidas em Estratégia de Serviço e Serviço de Design erefinado em Melhoria de Serviço Continuada (ver outro ITIL publicações nestasérie).Repositórios chave da operação de serviço, que foram citados em outroslugares, são a CMS ea BDEC, mas isso deve ser ampliado para incluir atotalidade do Serviço de Operação das equipes e departamentos"documentação, tais como operaçãos manuais, procedimentos manuais,instrução de trabalhos, etcITIL V3 - Operação de Serviço - Página: 151 de 423
  • 152. 4.6.7 Gerenciamento Financeiro para Serviços de TIOperação de Serviço equipe deve participar e apoiar o global de TIorçamentação e contabilidade sistema - E pode ser ativamente envolvidos emqualquer carregamento sistema que podem estar no local.Adequado planejamento é necessário para que despesas de capital (Capex) edespesas operacionais (Opex) orçamento estimativas podem ser preparadas econcordou em boa hora para atender os ciclos orçamentais.O Gerente de Operação de Serviço também deve ser envolvido em regular, pelomenos mensalmente, revers de despesas contra orçamentos - como parte doorçamento de TI em andamento e contabilidade processo. Qualquerirregularidade deve ser identificado e feito os ajustes necessários. Todas asdespesas comprometido deve passar pela organização de sistema de ordem decompra, de modo que os compromissos podem ser acumulados e verificaçõesadequadas devem ser feitas em todos os bens recebidos para que as faturas epagamentos podem ser corretamente autorizado - ou discrepâncias investigadase corrigidas.Deve notar-se que alguns propôs custar reduções por o negócio pode realmenteaumentar os custos de TI, ou pelo menos Custo unitários. Cuidados devem sertomados para garantir que a TI está envolvida na discussão de todas asmedidas de redução de custos e contribuir para as decisões globais. GestãoFinanceira é tratada em pormenor na publicação Estratégia de Serviço.4.6.8 Gestão da Continuidade de Serviço de TIFunções de operação de serviços são responsáveis pelo teste e execução desistema e serviço recuperação planos, tal como determinado no TI Plano deContinuidade do Serviços para a organização. Além disso, os gerentes de todasas funções de operação de serviço devem estar na equipe de Coordenação deNegócios Continuidade Central.Isto é discutido em detalhe na estratégia de serviço e design de serviço e nãoserão aqui repetidas, excepto para indicar que é importante que a operação deserviço funçãos devem estar envolvidos nas seguintes áreas:• Avaliação de risco, Usando seu conhecimento da infra-estrutura etécnicas como a ACIA e acesso à informação no CMS para identificarpontos únicos de falha ou outras de altarisco situações• Execução de qualquer Gestão de Risco medidas que estão acordados,por exemplo implementação de contramedidas, ou aumentada resiliênciapara componentes das infra-estruturas, etc• Assistência por escrito o real recuperação planos para sistemas eserviços sob sua controlarITIL V3 - Operação de Serviço - Página: 152 de 423
  • 153. • Participação nos testes dos planos (tais como envolvimento em off-site detestes etc simulações,) em uma base contínua, sob a direção do Gerentede Continuidade dos Serviços de TI (ITSCM)• Manutenção contínua dos planos sob o controle do GCSTI e Gestão daMudança• Participação em campanhas de formação e sensibilização para garantirque eles são capazes de executar os planos e compreender a sua papelsem um desastre• O Service Desk irá desempenhar um papel fundamental na comunicaçãocom a equipe, clientes e usuários durante um desastre realITIL V3 - Operação de Serviço - Página: 153 de 423
  • 154. 5 atividades operação comum ServiçoCapítulo 4 tratadas com os processos necessários para a eficaz Operação deServiço e no Capítulo 6, serão abordados os aspectos organizacionais. Estecapítulo se concentra em um número de operacional actividades que asseguremque a tecnologia está alinhado com o Serviço geral e Processo objetivos. Essasatividades são às vezes descritos como processos, mas na realidade sãoconjuntos de atividades técnicas especializadas todas destinadas a garantir quea tecnologia necessária para entregar e suportar serviços está a funcionar deforma eficaz e eficiente.Estas actividades serão geralmente de natureza técnica - embora a tecnologiaexacta irá variar de acordo com o tipo de serviço a ser entregues. Estapublicação incidirá sobre as atividades necessárias para gerenciar TI.Nota importante na gestão de tecnologiaÉ tentador separar o conceito de Serviço de Gestão de da gestão da infra-estrutura que é utilizada para prestar esses serviços.Na realidade, é impossível alcançar qualidade serviços sem alinhamento eengrenagens cada nível de tecnologia (e as pessoas que a gerenciam) para osserviços que estão sendo prestados. Serviço de Gestão envolve pessoas,processo e tecnologia.Em outras palavras, as atividades de operação comum de serviço não são sobreo gerenciamento da tecnologia para a questão de ter boa tecnologia atuação.Eles estão sobre a realização de desempenho que irá integrar a componente detecnologia com as pessoas e componentes de processo alcançar serviço eobjetivos de negócio. Veja a Figura 5.1 para exemplos de como a tecnologia égerido em organizações de maturação.ITIL V3 - Operação de Serviço - Página: 154 de 423
  • 155. Figura 5.1 atingir a maturidade em Gestão de TecnologiaFigura 5.1 ilustra as etapas envolvidas no amadurecimento de uma tecnologiacentrada organização a uma organização que utiliza a tecnologia como parte desua estratégia de negócios. Figura 5.1 ainda descreve o papel de Gestores deTecnologia em organizações de diferentes maturidade. O diagrama não éabrangente, mas fornece exemplos da forma em que a tecnologia é gerido emcada tipo de organização. Os títulos em negrito indicam o papel importantedesempenhado pela TI na gestão de tecnologia. O texto nas linhas descreve ascaracterísticas de um departamento de TI em cada nível.A finalidade deste diagrama neste capítulo é como se segue:• Este capítulo centra-se na Gestão Técnica actividades, mas não hánenhum modo simples de os representar. A organização menos maduratende a ver essas atividades como fins em si mesmos, e não um meiopara um fim. Uma organização mais madura tenderá a subordinar essasatividades para nível superior Serviço de Gestão de objetivos. Porexemplo, a Servidor Equipa de gestão vai passar de um departamentoisolado, focada exclusivamente no gerenciamento de servidores, paraITIL V3 - Operação de Serviço - Página: 155 de 423
  • 156. uma equipe que trabalha em conjunto com outros gerentes de tecnologiapara encontrar formas de aumentar o seu valor para o negócio.• Para fazer e reforçar o ponto de que não há nenhuma maneira "certa" deagrupar e organizar os departamentos que realizam esses serviços.Alguns leitores podem interpretar os títulos neste capítulo como os nomesdos departamentos, mas este não é o caso. O objetivo deste capítulo éidentificar as atividades típicas técnicos envolvidos na Operação deServiço. Aspectos organizacionais são discutidas no Capítulo 6.• As atividades de serviço de operação descritas no restante deste capítulonão são típicos de qualquer um dos níveis de maturidade. Em vez disso,as atividades são geralmente tudo presente de alguma forma em todos osníveis. Eles só estão organizadas e geridas de forma diferente em cadanível.Em alguns casos, um grupo dedicado pode lidar com todos de um processo ouatividade enquanto em outros casos de processos ou atividades podem sercompartilhadas ou dividir entre os grupos. No entanto, por meio de orientaçõesgerais, as seções a seguir listam as atividades necessárias sob os gruposfuncionais mais provável de ser envolvido em sua operação. Isso não significaque todas as organizações têm de usar essas divisões. Organizações menorestendem a atribuir grupos de essas atividades (se eles são necessários em todos)para os departamentos individuais, ou mesmo indivíduos.Finalmente, o objetivo deste capítulo não é fornecer uma análise detalhada detodas as atividades. Eles são especializados, e orientação detalhada estádisponível a partir dos fornecedores de plataformas e outros, mais técnicos,quadros, novas categorias serão adicionadas continuamente como a tecnologiaevolui. Este capítulo simplesmente tem como objetivo destacar a importância eanatureza da gestão de tecnologia para o gerenciamento de serviços de TI nocontexto.ITIL V3 - Operação de Serviço - Página: 156 de 423
  • 157. 5,1 Monitoramento e controleA medição e controlar de serviços é baseado em um ciclo contínuo demonitoramento, Relatórios e ações posteriores. Este ciclo é discutido emdetalhes nesta seção porque é fundamental para a prestação de suporte emelhoria dos serviços.É também importante notar que, embora o ciclo tem lugar durante a operação deserviço, que fornece a base para a fixação estratégia, Projeto e testes deserviços e alcançar a melhoria significativa. É também a base para a mediçãoSLM. Portanto, apesar de controlo é realizada por operação de serviço funçãos,que não deve ser visto como uma forma puramente operacional assunto. Todasas fases do Serviço Ciclo de Vida devem assegurar que as medidas e controlesestão claramente definidos e executados, e colocada em prática.5.1.1 DefiniçõesRefere-se a monitorização da atividade de observar uma situação para detectarmudanças que ocorrem ao longo do tempo.No contexto do Operação de Serviço, Isto implica o seguinte:• Usando ferramentas para monitorar o estado de CIs chave e principaisatividades operacionais• Assegurar condições especificadas forem satisfeitas (ou não atingida) e,se não, para levantar um alertar para o grupo apropriado (por exemplo, adisponibilidade de dispositivos de rede chave)• Assegurar que o atuação ou a utilização de um componente ou sistemaestá dentro de um intervalo especificado (espaço em disco, por exemplo,ou a utilização de memória)• Para detectar tipos anormais ou níveis de actividade na infra-estrutura(por exemplo, o potencial segurança ameaças)• Para detectar alterações não autorizadas (por exemplo, introdução desoftware)• Para garantir observância com a organizaçãoS políticas (por exemplo,uso inadequado de e-mail)• Para acompanhar as saídas para o negócio e garantir que eles seencontram qualidade e desempenho exigências• Para rastrear qualquer informação que é usado para medir KeyPerformance Indicators (KPIs).Relatórios refere-se à análise da produção e distribuição de saída domonitoramento atividade.No contexto do Operação de Serviço, Isto implica o seguinte:ITIL V3 - Operação de Serviço - Página: 157 de 423
  • 158. • Usando ferramentas para agrupar a saída de monitoramento ainformação que pode ser disseminada a vários grupos, funções ouprocessos• Interpretar o significado dessa informação• Determinar onde essa informação poderia ser melhor utilizados• A garantia de que os tomadores de decisão têm acesso às informaçõesque lhes permitam tomar decisões• Encaminhamento das informações transmitidas para o apropriadopessoa, grupo ou ferramenta.Controlar refere-se ao processo de administrar a utilização ou o comportamentode um dispositivo, sistema ou serviço. É importante notar, no entanto, quesimplesmente manipulando um dispositivo não é o mesmo que para a controlar.Controle exige três condições:• A ação deve assegurar que o comportamento está de acordo com umpadrão definido ou norma• As condições levando a ação deve ser definida, entendida e confirmada• A ação deve ser definido, aprovado e adequado para estas condições.No contexto do Operação de Serviço, Controle implica o seguinte:• Usando ferramentas para definir quais as condições que representamnormais operaçãos ou operações anormais• Regular o desempenho de dispositivos, sistemas ou serviços• Medir disponibilidade• Iniciar ações corretivas, o que pode ser automatizado (por exemplo,reiniciar um dispositivo remotamente ou executar um script) ou manual(por exemplo, notificar a equipe de operações do estado).5.1.2 Controle Loops monitorO mais comum modelo para a definição de controle é o Monitor de Controle deLoop. Apesar de ser um modelo simples, tem muitos complexos aplicaçãosdentro IT Service Management. Esta seção irá definir os conceitos básicos domodelo de malha de controle Monitor e seções irá mostrar o quão importanteesses conceitos são para o Serviço de Gestão de Ciclo de Vida.ITIL V3 - Operação de Serviço - Página: 158 de 423
  • 159. Figura 5.2 a malha de controle do monitorFigura 5.2 descreve os princípios básicos de controle. Uma única atividade e asua produção são medidos utilizando uma norma pré-definida, ou padrão, Paradeterminar se ela está dentro de um intervalo aceitável de atuação ou qualidade.Se não, são tomadas medidas para corrigir a situação ou para restaurardesempenho normal.Normalmente existem dois tipos de Malhas de Controle do Monitor:• Open Loop Sistemas destinam-se a efectuar uma específica atividadeindependentemente das condições ambientais. Por exemplo, um apoiopode ser iniciada em um determinado momento e frequência - e seráexecutado independentemente de outras condições.• Sistemas de circuito fechados monitorar uma ambiente e responder àsmudanças nesse ambiente. Por exemplo, no balanceamento de carga derede um monitor irá avaliar o tráfego em um circuito. Se o tráfego de redeexcede um determinado intervalo, o controlar sistema vai começar a rotade tráfego através de um circuito de backup. O monitor vai continuar afornecer feedback para o sistema de controlo que vai continuar a regularo fluxo de tráfego de rede entre os dois circuitos.ITIL V3 - Operação de Serviço - Página: 159 de 423
  • 160. Para ajudar a esclarecer a diferença, resolvendo Gerenciamento da Capacidadeatravés de excesso de provisionamento é de malha aberta, um balanceador decarga que detecta congestão /falha e capacidade de redirecionamentos é decircuito fechado.5.1.2.1 Controlo de Monitor Complexo LaçoO Monitor de Controle de Loop na Figura 5.2 é uma boa base para a definiçãode como Gestão de Operações obras, mas dentro do contexto de ITSM, asituação é muito mais complexa. A Figura 5.3 ilustra um processo composto portrês atividades principais. Cada um tem uma entrada e uma saída, e a saídatorna-se uma entrada para a actividade seguinte.Neste diagrama, cada atividade é controlada pelo seu próprio loop Monitor decontrole, usando um conjunto de normas para que a atividade específica. Oprocesso como um todo também tem a sua própria malha de controle Monitor,que abrange todas as atividades e garante que todas as normas sejamadequadas e estão sendo seguidas.Figura 5.3 Malha de Controle Complexo do MonitorNa Figura 5.3 há um ciclo de feedback de casal. Um ciclo se concentraexclusivamente na execução de um determinado padrão, E o segundo avalia oITIL V3 - Operação de Serviço - Página: 160 de 423
  • 161. atuação do processo, e também os padrões em que o processo é executado.Um exemplo disto seria se o primeiro conjunto de laços de realimentação, naparte inferior do diagrama representado estações individuais de uma linha demontagem e o circuito de nível superior representada Garantia de Qualidade.A malha de controle Complexo Monitor é uma boa ferramenta de aprendizagemorganizacional (como definido por Chris Argyris, (1976) Aumentar a eficácia daliderança. Nova Iorque: Wiley). O primeiro nível de feedback no nível deatividade indivíduo está preocupado com monitoramento e respondendo aosdados (fatos individuais, códigos ou peças de informação). O segundo nível estápreocupado com a monitorização e resposta à informação (uma coleção de umasérie de fatos sobre os quais uma conclusão pode ser desenhada). Consulte oTransição de Serviço publicação para um debate aprofundado sobre dados,informações, conhecimento e sabedoria.Tudo isso é teoria interessante, mas não explica como o Monitor conceito decontrole de loop pode ser usado para operar De serviços de TIs. Eespecialmente - que define a norma? Com base no que foi descrito até agora,Malhas de Controle do monitor pode ser usado para gerenciar:• O atuação de atividades em um processo ou procedimento. Cadaactividade ea sua saída relacionado pode potencialmente ser medidopara assegurar que problemas com o processo são identificados antes doprocesso como um todo é concluída. Por exemplo, em Gerenciamento deIncidentes, O Service Desk monitora se uma equipe técnica aceitou umincidente em um tempo especificado. Se não, o incidente é escalado. Istoé feito antes de o alvo bem resolução tempo para que o incidente porqueo objectivo de escalada que uma actividade é o de assegurar que oprocesso no seu conjunto é completado em tempo.• O eficácia de um processo ou procedimento como um todo. Neste caso,o atividadeCaixa representa todo o processo como uma única entidade.Por exemplo, a Gestão da Mudança irá medir o sucesso do processo,verificando se um mudar foi implementada em tempo, para especificaçãoe dentro orçamento.• O atuação de um dispositivo. Por exemplo, a caixa de "atividade"poderia representar o tempo de resposta de um servidor sob uma dadacarga de trabalho.• O desempenho de uma série de dispositivos. Por exemplo, aextremidade usuário tempo de resposta de um aplicação através da rede.Para definir como utilizar o conceito de Monitor de Controle de Loops em Serviçode Gestão de, As seguintes perguntas devem ser respondidas:• Como podemos definir o que precisa ser monitorado?• Quais são os adequados limiars para cada um deles?• Como será monitoramento ser realizada (manual ou automático)?ITIL V3 - Operação de Serviço - Página: 161 de 423
  • 162. • O que representa normais operação?• Quais são as dependências para o funcionamento normal?• O que acontece antes de se chegar a entrada?• Com que freqüência deve a medição ocorrer?• Será que precisamos para realizar medição ativa para verificar se o itemestá dentro da norma ou vamos esperar até que uma exceção é relatado(medição passiva)?• É Gestão de Operações a única função que realiza umacompanhamento?• Se não, como são as outras instâncias de monitoramento relacionados àGestão de Operações?• Se houver múltiplos loops, que são responsáveis por processos cadaloop?As seções seguintes irão expandir o conceito de Malhas de Controle do Monitore demonstrar como essas questões são respondidas.5.1.2.2 O ITSM Monitor de Controle LaçoEm ITSM, a malha de controle complexo Monitor pode ser representada comomostrado na figura 5.4.ITIL V3 - Operação de Serviço - Página: 162 de 423
  • 163. Figura 5.4 ITSM Monitor de Controle de LoopFigura 5.4 pode ser utilizado para ilustrar o controlar de um processo ou de ocomponenteé usado para entregar um serviço. Neste diagrama "atividade" apalavra implica que ele se refere a um processo. Para aplicá-lo a um serviço,uma "atividade" também poderia ser um "CI". Há um certo número decaracterísticas importantes na Figura 5.4:• Cada atividade num Serviço de Gestão de processo (ou de cadacomponente usado para fornecer um serviço) É monitorizada como partedo Operação de Serviço processos. O operacional equipe oudepartamento responsável por cada atividade ou componente irá aplicar amalha de controle do monitor, conforme definido no processo, E usandoas normas que foram definidos durante o Design de Serviços processos.O papel da monitorização operacional e controlo é o de assegurar que oprocesso ou o serviço funçãos exatamente como especificado, é por issoque eles estão principalmente preocupados com a manutenção do statusquo.ITIL V3 - Operação de Serviço - Página: 163 de 423
  • 164. • As normas e mecanismos de monitoramento e de controle são definidosem Design de Serviços, mas eles são baseados no padrãos earquiteturas definido durante Estratégia de Serviço. Quaisquer alteraçõesao organizaçãoEstratégia do Serviço, arquitetura, serviço carteiras ouExigência de Nível de Serviços vai precipitar mudanças para o que émonitorado e como ele é controlado.• O Monitor de Controle de Loops são colocados dentro do quadro dosistema. Isto implica que a Estratégia de Serviço serão principalmenteexecutado por executivos de TI com o apoio do fornecedor gerente decontass. Design de Serviços atua como ponte entre a Estratégia deServiço e Operação de Serviço e normalmente envolvem representantesde todos os grupos. As atividades e controles geralmente será executadopela equipe de TI (às vezes envolvendo usuários) e apoiada por gerentesde TI e os fornecedores. Melhoria de Serviço abrange todas as áreas,mas principalmente representa os interesses da empresa e seususuários.• Observe que o segundo nível de monitoramento neste loop complexoMonitor de controle é realizado por meio de processos de CSI Estratégiade Serviço e Design de Serviço. Estes relaçãos são representadas pelassetas numeradas na figura 5.4, como segue:• Seta 1. Neste caso CSI tem reconhecido que o serviço serámelhorada através de uma mudar à Estratégia de Serviço. Istopoderia ser o resultado da necessidade de uma mudança deactividade para o Portfólio de Serviços, Ou que a arquitetura nãoentregar o que era esperado.• Arrow 2. Neste caso, os requisitos de nível de serviço precisamser ajustados. Pode ser que o serviço é muito caro, ou que oconfiguração da infra-estrutura necessita de ser alterada paramelhorar atuação, Ou porque Gestão de Operações é incapaz demanter o serviço qualidade na arquitetura atual.• Seta 3. Neste caso, as normas especificadas em Design deServiços não estão a ser cumpridos. Isto poderia ser porque elesnão são apropriados ou executável, ou por causa de uma falta deeducação ou falta de comunicação. As normas ea falta deobservância precisam ser investigadas e as medidas tomadas paracorrigir a situação.Transição de Serviço oferece um grande conjunto de freios e contrapesosnestes processos. Fá-lo como se segue:• De novos serviços, Transição de Serviço irá garantir que as arquiteturastécnicas são adequadas e que os padrões operacionais de desempenhopode ser executado. Este, por sua vez, irá garantir que as equipes deserviço de operação ou departamentos são capazes de cumprir osrequisitos de nível de serviço.ITIL V3 - Operação de Serviço - Página: 164 de 423
  • 165. • Para os serviços existentes, Gestão da Mudança irá gerenciar qualqueruma das alterações que são necessárias, como parte de um controle (porexemplo, afinação), Assim como quaisquer alterações representadaspelas setas marcadas 1, 2 e 3. Apesar de Transição de Serviço nãodefine estratégia e projeto serviços, por si só, fornece coordenação egarantia de que os serviços estão funcionando e vai continuar a trabalhar,como planejado.Porque é que este circuito coberto Operação de Serviço?Figura 5.4 representa Monitoramento e Controle para o conjunto da IT ServiceManagement. Alguns leitores da publicação operação de serviço pode sentir queele deve ser mais adequadamente abordados na publicação Estratégia deServiço.No entanto, Monitoramento e Controle só pode ser efetivamente implantadoquando o serviço é operacional. Isto significa que o qualidade de todo o conjuntode processos de Gerenciamento de Serviço depende de como eles sãomonitorados e controlados de Operação de Serviço.As implicações disso são as seguintes:• Operação equipe de serviço não são as únicas pessoas com uminteresse no que é monitorado e como eles são controlados.• Enquanto Operação de Serviço é responsável por monitoramento econtrolar de serviços e componentes, eles estão agindo comoadministradores de uma parte muito importante do conjunto de laços deITSM Monitoramento e Controle• Se a equipe da Operação de Serviço definir e executar Monitoramento eControle procedimentos isoladamente, nenhum dos processos deGerenciamento de Serviço ou funçãos só será plenamente eficaz. Issoocorre porque as funções de operação de serviço não vai apoiar asprioridades e informações exigências de outros processos, por exemplo, atentativa de negociar um SLA quando os dados disponíveis apenas é apágina de swap as taxas em um servidor e a utilização da largura debanda de uma rede detalhada.5.1.2.3 definir o que precisa ser monitoradoA definição do que precisa ser monitorado é baseada no entendimento dodesejado resultado de um processo, dispositivo ou sistema. Deve concentrar-seno serviço e os seus impacto sobre o negócio, e não apenas os componentesindividuais de tecnologia. A primeira pergunta que precisa ser feita é "O queestamos tentando alcançar? .5.1.2.4 Monitoramento Interno e Externo e ControleITIL V3 - Operação de Serviço - Página: 165 de 423
  • 166. No início, torna-se claro que existem dois níveis de controlo:• Monitoramento e Controle Interno: A maioria das equipes oudepartamentos estão preocupados com a possibilidade de executar comeficácia e eficiência as tarefas que foram atribuídas a eles. Por isso, elesvão monitorar os itens e atividades que estão diretamente sob seucontrole. Este tipo de monitoramento e controle se concentra ematividades que são auto-contido que a equipe ou departamento. Porexemplo, a Service Desk Gerente vai monitorar o volume de chamadaspara determinar como muitos funcionários precisam estar disponíveispara atender o telefone.• Monitoramento e controle externo: Embora cada equipe oudepartamento é responsável por gerenciar sua própria área, eles nãoagem de forma independente. Cada tarefa que eles executam, oudispositivo que eles conseguem, tem um impacto sobre o sucesso daorganização como um todo. Cada equipe ou departamento também vaiestar controlando itens e atividades em nome de outros grupos,processos ou funçãos. Por exemplo, a Servidor Equipa de gestão vaimonitorar a CPU atuação em servidores principais e executar carga detrabalho equilibrar, de modo que um crítico aplicação é capaz depermanecer dentro de desempenho limiars definido pelo Aplicação deGestão de.A distinção entre o controlo interno e externo é um passo importante. SeOperação de Serviço incide apenas sobre monitoramento interno, que terá infra-estrutura muito bem gerida, mas não há maneira de entender ou influenciar oqualidade de serviços. Se ele se concentra apenas no monitoramento externo,ele vai entender o quão pobre a serviço qualidade é, mas não tem idéia do queestá causando isso ou como mudar isso.Na realidade, a maioria das organizações têm uma combinação de controlointerno e externo, mas em muitos casos estes não estão ligados. Por exemplo, aequipe de gerenciamento de servidor sabe exatamente o quão bem osservidores estão executando as tarefas eo Nível de Serviço Gerente sabeexatamente como os usuários percebem a qualidade do serviço prestado pelosservidores. No entanto, nenhum deles sabe como ligar esses métricos paradefinir qual o nível de desempenho do servidor representa a boa qualidadeserviço. Isso se torna ainda mais confuso quando o desempenho do servidorque é aceitável no meio do mês, não é aceitável no final do mês.5.1.2.5 Definir objectivos para monitoramento e controleMuitas organizações começar por perguntar a pergunta "O que estamos agestão? . Isso leva invariavelmente a um monitoramento interno forte Sistema,Com ligação muito pouco para o real resultado ou serviço que é exigido pelaempresa.ITIL V3 - Operação de Serviço - Página: 166 de 423
  • 167. A pergunta mais apropriada é "Qual é o resultado final das atividades eequipamentos que a minha equipa consegue? . Portanto, o melhor lugar paracomeçar, ao definir o que monitorar, é determinar o resultado necessário.A definição de Monitoramento e Controle objetivos devem, idealmente, começarcom a definição da Exigência de Nível de Serviçosdocumentos (ver Design deServiços publicação). Estes irão especificar como o clientes e usuários vai mediro desempenho do serviço, e são utilizados como entrada para os processos dedesign de serviço. Durante Design de Serviços, vários processos irá determinarcomo o serviço será entregue e gerenciado. Por exemplo, a Gerenciamento daCapacidade vai determinar a forma mais adequada e econômica para entregaros níveis de desempenho exigidos. Gerenciamento de Disponibilidade vaideterminar a forma como a infra-estrutura pode ser configurado paraproporcionar o menor número de pontos de falha.Se houver qualquer dúvida sobre a validade ou integridade de objectivos, aCOBIT framework fornece uma abrangente, conjunto de alto nível dos objectivoscomo uma lista de verificação. Mais informações sobre o COBIT é fornecido noApêndice A desta publicação.O Processo de Design de Serviços irá ajudar a identificar os seguintes conjuntosde insumos para a definição Operacional Monitoramento e Controle de normas emecanismos:• Eles vão trabalhar com clientes e usuários para determinar como a saídado serviço será medido. Isso irá incluir mecanismos de medição,freqüência e amostragem. Esta parte do Design de Serviços incidiráespecificamente sobre os requisitos funcionais.• Eles vão identificar CIs chave, como devem ser configurados e qual onível de desempenho e disponibilidade é necessária, a fim de cobrir aNível de Serviços.• Eles vão trabalhar com os desenvolvedores e fornecedores da CEI quecompõem cada serviço para identificar quaisquer restrições ou limitaçõesnaqueles componentes.• Todo apoio e equipes de entrega e departamentos terão de identificarquais informações irá ajudá-los a executar seu papel eficazmente. Partedo Design de Serviços e desenvolvimento será instrumento cada serviçopara que ele possa ser controlado para fornecer essas informações, oupara que possa gerar significativo eventos.Tudo isso significa que uma parte muito importante de definir o que Operação deServiço monitores e como ela exerce o controle é identificar a das partesinteressadass de cada serviço.As partes interessadas podem ser definidos como qualquer pessoa cominteresse na entrega e recepção de sucesso De serviços de TIs. Cada ator teráITIL V3 - Operação de Serviço - Página: 167 de 423
  • 168. uma perspectiva diferente do que vai demorar para entregar ou receber umserviço de TI. Operação de Serviço precisa entender cada uma dessasperspectivas, a fim de determinar exatamente o que precisa ser monitorado eoque fazer com a saída.Operação de Serviço, portanto, dependem de SLM para definir exatamentequem são essas partes interessadas e como elas contribuem ou usar o serviço.Isso é discutido com mais detalhes no design de serviço e publicações Melhoriade Serviço Continuada.Nota sobre Objetivos de monitoramento interno e externoO requerido resultado pode ser interno ou externo à Operação de Serviçofunçãos, embora deva ser sempre lembrado que uma ação interna, muitasvezes, ter um resultado externo. Por exemplo, a consolidação servidors paratorná-los mais fáceis de administrar pode resultar numa custar poupança, o queafetará a negociação e SLM rever ciclo, bem como o Gestão Financeiraprocessos.5.1.2.6 Tipos de monitoramentoExistem muitos tipos diferentes de monitoramento ferramenta e situaçõesdiferentes em que cada um deles será utilizado. Esta seção focaliza alguns dosdiferentes tipos de controlo que podem ser realizadas e quando seria adequado.Monitoramento ativa versus passiva• Monitoramento ativo refere-se à "interrogação" contínuo de um dispositivoou sistema para determinar a sua estado. Esse tipo de monitoramentopode ser recurso intensivo e é geralmente reservado para monitorarproativamente o disponibilidade de dispositivos ou sistemas críticos, oucomo um passo de diagnóstico quando se tenta resolver um incidente oudiagnosticar um problema.• Monitoramento passivo é mais comum e refere-se a geração etransmissão de eventos de um "dispositivo de escuta", ou agente demonitoramento. Monitoramento passivo depende de definição bemsucedida de eventos e instrumentação do sistema a ser monitorizados(ver secção 4.1).Reativa contra Proactive• Acompanhamento reactivo é projetado para solicitar ou desencadear umaacção na sequência de um certo tipo de evento ou falha. Por exemplo,servidor, atuação degradação pode desencadear um reboot, ou uma falhado sistema irá gerar uma incidente. Monitoramento reativo não é usadosomente para exceções. Ele também pode ser usado como parte daITIL V3 - Operação de Serviço - Página: 168 de 423
  • 169. operação normal procedimentos, por exemplo, um trabalho em lotes éconcluída com êxito, o que leva o sistema de agendamento para enviar otrabalho próximo lote.• Monitoramento proativo é usado para detectar os padrões de eventos,que indicam que um sistema ou serviço pode estar prestes a falhar.Proactive monitoramento é geralmente usado em mais maduraambientes, onde estes padrões têm sido detectados anteriormente,muitas vezes, por várias vezes. Ferramentas de monitoramento pró-ativosão, portanto, um meio de automatizar a experiência da equipe de TIexperiente e muitas vezes são criadas através do Gerenciamento deProblemas pró-ativa processo (Ver publicação Melhoria de ServiçoContinuada).Por favor, note que o monitoramento reativo e proativo pode ser ativo oupassivo, conforme a Tabela 5.1:Ativo PassivaReativo Usado para diagnosticar qualdispositivo está causando o falha e emque condições ("ping" por exemplo, umdispositivo, ou executar e acompanharuma amostra transação através deuma série de dispositivos)Requer conhecimento da infra-estrutura e topografia do mapeamentodos serviços a instituições de créditoDetecta e correlaciona evento registrospara determinar o sentido da eventos eaação apropriada (por exemplo, um usuáriofaz em três vezes com a senha incorreta, oque gera representa um segurançaexceção e é escalado por Gestão deSegurança da Informação procedimentos)Requer conhecimento detalhado do normaloperação da infra-estrutura e serviçosProactive Utilizado para determinar o tempo realestado de um dispositivo, sistema ouserviço - geralmente por críticacomponentes ou após a recuperaçãode um dispositivo falhou para garantirque ele está totalmente recuperado(isto é, não vai causar novosincidentes)Os registros de eventos sãocorrelacionados ao longo do tempo paraconstruir tendências para Gerenciamentode Problemas pró-ativa.Padrões de eventos são definidos eprogramados em ferramentas decorrelação para futuro reconhecimentoReativa Tabela 5.1 Ativo e Passivo e monitoramento proativoMedição contínua versus exceção baseada em Medição• Medição Contínua é focado em monitoramento um sistema em temporeal para assegurar que ele está em conformidade com a atuação norma(por exemplo, um aplicação servidor está disponível para 99,9% doacordado horas de serviço). A diferença entre a medição e monitorizaçãocontínua e ativa é que o monitoramento ativo não tem que ser contínuo.No entanto, como com a monitorização activa, isto é recurso intensivo e égeralmente reservado para componentes críticos ou serviços. Na maioriados casos, o custar da largura de banda e poder de processamentoITIL V3 - Operação de Serviço - Página: 169 de 423
  • 170. superior ao benefício de medição contínua. Nestes casos, um controloserá normalmente por amostragem e análise estatística (por exemplo, odesempenho do sistema é relatada a cada 30 segundos e extrapoladospara representar o desempenho global). Nestes casos, o método demedição deverá ser documentado e acordado nos OLAs para garantir queela é adequada para suportar os requisitos de informação de serviço (verMelhoria de Serviço Continuada publicação).• Exceção Baseado Medição não mede o desempenho em tempo real deum serviço ou sistema, mas detecta e relatórios com exceções. Porexemplo, um evento é gerado se a transação não for concluída, ou se umdesempenho limiar é atingido. Este é mais rentável e mais fácil de medir,mas pode resultar em mais serviço interrupções. Medição exceçãoBaseado é usado para sistemas menos críticos ou em sistemas ondecustar é uma questão importante. Também é utilizado em instrumentos deTI não são capazes de determinar o estado ou qualidade de um serviço(Por exemplo, se a qualidade de impressão faz parte da serviçoespecificação, A única maneira de medir esta é a inspecção física -muitas vezes realizada pelo usuário em vez de a equipe de TI). OndeMedição Excepção-Based é usado, é importante que tanto o OLA ea SLApara esse serviço refletir isso, como interrupções de serviço são maisprováveis de ocorrer, e os usuários são muitas vezes obrigados acomunicar a exceção.Desempenho versus saídaHá uma distinção importante entre o relatório usado para rastrear a atuação decomponentes ou equipes ou departamento usado para fornecer um serviço e osrelatórios usados para demonstrar a realização do serviço qualidade objetivos.Os gerentes de TI muitas vezes confundem estes relatando ao negócio sobre odesempenho de suas equipes ou departamentos (por exemplo, número dechamadas atendidas por Service Desk Analista), como se isso fosse a mesmacoisa que qualidade de serviço (por exemplo, incidentes resolvidos no prazoacordado).Monitoramento de Desempenho e métricos deve ser usado internamente peloServiço de Gestão de para determinar se as pessoas, processo e tecnologiaestão funcionando corretamente e com o padrão.Usuários e clientes preferiria ver relatórios relacionados com a qualidade edesempenho do serviço.Embora Operação de Serviço está preocupado com os dois tipos decomunicação, a principal preocupação desta publicação é de monitoramento dedesempenho, enquanto monitoramento de Qualidade de Serviço (ou com baseITIL V3 - Operação de Serviço - Página: 170 de 423
  • 171. em resultados de Monitoramento) será discutido em detalhe no Melhoria deServiço Continuada publicação.5.1.2.7 Monitoramento em ambientes de testeTal como acontece com qualquer Infraestrutura de TI, Um Ambiente de Testeterá de definir como vai utilizar a monitorização e controlar. Estes controlos sãomais completamente discutidos na Transição de Serviço publicação.• Monitorar o ambiente de teste em si: Um ambiente de teste consiste deinfra-estrutura, aplicaçãos e processos que têm de ser geridos econtrolados como qualquer outro ambiente. É tentador pensar que oambiente de teste não precisa de rigoroso monitoramento e controle,porque não é um viver ambiente. No entanto, este argumento não éválido. Se um ambiente de teste não está devidamente monitorizado econtrolado, existe o perigo de executar os testes no equipamento que sedesvia da padrãos definidos no Design de Serviços.• Itens de monitoramento que está sendo testado: Os resultados dostestes têm de ser rigorosamente controladas e verificadas. Também éimportante que as ferramentas de monitoramento que foram construídasem serviços novos ou modificados têm de ser testados também.5.1.2.8 Relatórios e ação"Um relatório sozinho cria a consciência, um relatório com um plano de açãoalcança resultados.Relatórios e disfunçãofunçãoA experiência prática tem mostrado que há mais informação nas organizaçõesdisfuncionais do que em organizações eficazes. Isto é porque os relatórios nãoestão sendo usados para iniciar pré-definida de ação planos, mas sim:• transferir a culpa para um incidente• para tentar descobrir quem é o responsável por tomar uma decisão• como entrada para a criação de planos de ação para futuras ocorrências.Nas organizações disfuncionais uma série de relatórios que são produzidosninguém tem tempo para olhar ou consulta.Monitoramento sem controlar é irrelevante e ineficaz. O monitoramento deve sersempre, para evitar que serviço e operacional objetivos estão sendo atendidas.Isso significa que, a menos que haja um objetivo claro para monitoramento umsistema ou serviços, que não devem ser monitorizados.ITIL V3 - Operação de Serviço - Página: 171 de 423
  • 172. Isso também significa que quando a vigilância é definida, também devequaisquer ações necessárias. Por exemplo, ser capaz de detectar que umagrande aplicação falhou não é suficiente. A equipe de gestão competenteaplicativo também deve ter definido as etapas exatas que vai levar quando oaplicativo falha.Além disso, deve também ser reconhecido que essa acção pode ter de sertomada por pessoas diferentes, por exemplo, um único evento (tal como umaaplicação falha) Pode desencadear a acção da Aplicação de Gestão de equipa(para restaurar serviço), os usuários (para iniciar o processamento manual) e degestão (para determinar como esta evento pode ser evitado no futuro).As implicações disto princípio são descritos em mais pormenor em relação àsGestão de Eventos (Ver secção 4.1).5.1.2.9 auditorias Operação de ServiçoRegular auditars devem ser realizados com o Operação de Serviço processos eatividades para garantir:• Estão a ser realizados como pretendido• Não há evasão• Eles ainda são apto para o efeito, Ou para identificar eventuais alteraçõesou melhorias.Gerentes de operação de serviço pode optar por realizar auditorias si, mas oideal é alguma forma de elemento independente das auditorias é preferível.O organizaçãoS interno de TI equipe de auditoria ou departamento pode sersolicitado a se envolver ou algumas organizações podem optar por participar deterceiros consultoria / auditoria /avaliação empresas de modo que um perito vistatotalmente independente é obtido.Auditorias operação de serviço fazem parte da avaliação contínua que ocorrecomo parte de Melhoria de Serviço Continuada e são discutidos em maisdetalhes na publicação.5.1.2.10 Medição, métricas e KPIsEsta seção tem como foco principal o monitoramento e controle como base paraa operação de serviço. Outras seções da publicação ter coberto alguns básicosmétricos que podem ser usados para medir a eficácia e eficiência de umprocesso.Embora esta publicação não é principalmente sobre medição e métricas, éimportante que as organizações que utilizam estes diretrizs têm técnicas deITIL V3 - Operação de Serviço - Página: 172 de 423
  • 173. medição robustos e métricas que suportam o objetivos dos seus organização.Esta seção é um resumo desses conceitos.MediçãoRefere-se a medição de qualquer técnica que é utilizada para avaliar a extensãoou dimensão capacidade de um artigo, em relação a um padrão ou a unidade.• Refere-se a medida do grau de observância ou conclusão (por exemplo,são todas as alterações formalmente autorizados pela autoridadecompetente)• Dimensão refere-se ao tamanho de um artigo, por exemplo, o número deincidentes resolvidos pela Service Desk• Refere-se a capacidade total capacidade de um artigo, por exemplo,número máximo de padrão transaçãos que podem ser processados porum servidor por minuto.Medição só se torna significativa quando é possível medir a saída real oudimensões de um sistema,função ou processo contra um nível padrão oudesejado, por exemplo, o servidor deve ser capaz de processar um mínimo de100 operações padrão por minuto. Isso precisa ser definido em Design deServiço, e aperfeiçoado ao longo do tempo através Melhoria de ServiçoContinuada, Mas a medida em si acontece durante Operação de Serviço.MétricaMétricos referem-se ao quantitativo, periódica avaliação de um processo,Sistema ou função, juntamente com a procedimentos e ferramentas que serãousadas para fazer essas avaliações e os procedimentos para interpretá-los.Esta definição é importante, porque não só especifica o que deve ser medido,mas também a forma de medi-la, o que a faixa aceitável de desempenho será equais as medidas terão de ser tomadas como resultado do normal atuação ouum. exceção A partir disto, é evidente que qualquer métrica dada na secçãoprecedente desta publicação é muito básica e terá de ser aplicado e expandidodentro do contexto de cada organização antes que possa ser eficaz.Indicadores Chave de DesempenhoUm KPI refere-se a um nível específico, acordado atuação que irão ser utilizadospara medir o eficácia de um organização ou processo.KPIs são únicos para cada organização e têm de estar relacionadas adeterminadas entradas, saídas e atividades. Elas não são de natureza genéricaou universal e, portanto, não foram incluídos nesta publicação.ITIL V3 - Operação de Serviço - Página: 173 de 423
  • 174. Uma outra razão para não incluir a eles é o fato de que semelhante métricospode ser usada para atingir KPIs muito diferentes. Por exemplo, umaorganização utilizada a percentagem métrica de Incidentes resolvidos pelaService Desk"Para avaliar o desempenho do Service Desk. Isso funcionouefetivamente por cerca de dois anos, após o qual o gerente de TI começaram aperceber que este KPI estava sendo usado para prevenir eficaz Gerenciamentode Problemas, Ou seja, se, depois de dois anos, 80% de todos os incidentes sãofáceis o suficiente para ser resolvido em 10 minutos no primeiro chamar, Por quenão podemos chegar a uma solução para eles? Com efeito, o KPI agora tornou-se uma medida de como ineficazes as equipes de Gerenciamento de Problemasforam.5.1.2.11 Interfaces para práticas de outros serviços do Ciclo de VidaMonitoramento Operacional e Melhoria de Serviço ContinuadaEsta secção tem incidido sobre Operacional Vigilância e informação, masmonitoramento também constitui o ponto de partida para o Melhoria de ServiçoContinuada. Isso é abordado na publicação Melhoria de Serviço Continuada,mas as principais diferenças são descritos aqui.Qualidade é a chave objetivo de monitoramento para a Melhoria de ServiçoContinuada (MSC). O acompanhamento será, portanto, incidir sobre a eficáciade um serviço, Processo, ferramenta de organização, ou CI. A ênfase não estána garantia de desempenho em tempo real de serviços, mas sim que está emidentificar onde as melhorias podem ser feitas para o actual nível de serviço, ouo desempenho de TI.Monitoramento de CSI, portanto, tendem a se concentrar na detecção deexceções e resoluçãos. Por exemplo, a CSI não é tão interessado em saber seum incidente foi resolvido, mas se ele foi resolvido dentro do prazo acordado ese incidentes futuros podem ser evitados.CSI não é apenas interessado em exceções. Se um SLA é consistentementeconheceu ao longo do tempo, CSI também estará interessado em determinar seo nível de desempenho pode ser sustentado a um menor custar ou se eleprecisa ser atualizado para um nível ainda maior de desempenho. CSI pode,portanto, também precisam ter acesso a relatórios de desempenho regulares.No entanto, como CSI é improvável que precisa, ou ser capaz de lidar com asenormes quantidades de dados que são produzidos por todo oacompanhamento atividade, Eles vão se concentrar mais provável em umsubconjunto específico de monitoramento a qualquer momento. Isto pode serdeterminado através de uma entrada a partir da empresa ou melhorias àtecnologia.ITIL V3 - Operação de Serviço - Página: 174 de 423
  • 175. Isso tem duas implicações principais:• Monitoramento de CSI vai mudar ao longo do tempo. Eles podem estarinteressados no acompanhamento do serviço de correio electrónicoquarto e depois passar a olhar para RH sistemas no próximo trimestre.• Isto significa que, Operação de Serviço e CSI precisa construir umprocesso que irá ajudá-los a chegar a acordo sobre que áreas precisamser monitoradas e para que finalidade.ITIL V3 - Operação de Serviço - Página: 175 de 423
  • 176. 5,2 Operações de TI5.2.1 Management Console / Ponte de OperaçõesEstes fornecem um ponto de coordenação central para gerenciar várias classesde eventos, a detecção de incidentes de rotina, gestão operacional atividades eelaboração de relatórios sobre o estado ou atuação de tecnologia componentes.Observação e monitoramento do Infraestrutura de TI pode ocorrer a partir de umconsole centralizado - para o qual todos sistema eventos são roteados.Historicamente, isto envolveu o acompanhamento do mestre operaçãos consolade um ou mais computadores centrais -, mas hoje em dia é mais provável queenvolve um controlo de um servidor farm (s), dispositivos de armazenamento,componentes de rede aplicaçãos, bases de dados ou qualquer outro CIs,incluindo qualquer estrutura principal restante (s), a partir de um único local,conhecido como o Operações Ponte.Existem duas teorias sobre como o Operações Ponte foi assim chamado. Umadelas é que ele se assemelha a ponte de um navio grande, automatizada (comonaves espaciais comumente visto em filmes de ficção científica). Outra teoria éque a Operações Ponte representa uma ligação entre o Operações de TIequipes e as tradicionais Help Desk. Em alguns organismos, isto significa que ofunçãos de Controle Operacional e do Help Desk foram incorporadas pelaService Desk, Que realizou os dois conjuntos de funções em um único localfísico.Independentemente da forma como foi nomeado, um Operações Ponte reunirátodos os pontos de observação críticos na infra-estrutura de TI, para quepossam ser monitorados e gerenciados a partir de um local centralizado, com omínimo de esforço. Os dispositivos a ser monitorizado são susceptíveis de serfisicamente dispersos e podem estar localizados em instalações centralizadasdo computador ou dispersos no interior da usuário comunidade, ou ambos.O Operações Ponte vai combinar muitas atividades, que podem incluirManagement Console, manipulação de eventos, de primeira linha degerenciamento de rede, Job Scheduling e suporte out-of-hora (cobertura para oService Desk e / ou segunda linha de apoio grupos se eles não trabalham 24/7).Em algumas organizações, o Service Desk é parte do Operações Ponte.A localização física e layout de Ponte da operação deve ser cuidadosamenteprojetado para oferecer a acessibilidade correta e visibilidade de todas as telas edispositivos pertinentes ao pessoal autorizado. No entanto, isso vai se tornaruma área muito sensível, onde o acesso controlado e apertado segurança seráessencial.ITIL V3 - Operação de Serviço - Página: 176 de 423
  • 177. Organizações menores não pode ter um físico Operações Ponte, Mas haverácertamente ainda a necessidade de Management Console, geralmentecombinado com outras técnicas papels. Por exemplo, uma única equipe detécnicos irá gerenciar a rede, servidores e aplicativos. Parte do seu papel será ode monitorar os consoles para esses sistemas - muitas vezes usando consolesvirtuais, para que possam realizar o atividade a partir de qualquer localização.No entanto, deve notar-se que estas consolas virtuais são ferramentaspoderosas e, se for usado em locais inseguros ou mais conexões a descoberto,pode representar uma segurança significativa ameaça.5.2.2 Job SchedulingOperações de TI irá executar rotinas, consultas ou relatórios que lhe foremdelegadas, como parte dos serviços de entrega, ou como parte da rotina delimpeza delegada pelo técnico e Aplicação de Gestão de equipes.Job Scheduling envolve a definição e início de pacotes de software deagendamento de tarefas para executar em lote e em tempo real de trabalho. Istonormalmente envolvem diária, semanal, mensal, anual e horários ad hoc paraatender às necessidades de negócio.Além da primeira projetoOu redesenho periódica, dos horários, não sãosusceptíveis de ser frequentes alterações ou ajustes para fazer, durante o qualas dependências de trabalho têm de ser identificados e acomodados. Haverátambém um papel a desempenhar na definição alertars e Relatório de Exceçãospara ser usado para monitoramento/ Verificar horários de trabalho. Gestão daMudança desempenha um papel importante na avaliação e validação degrandes mudanças de horários, bem como a criação de Mudança Padrãoprocedimentos para mais mudanças de rotina.Tempo de execução parâmetros e / ou arquivos têm que ser recebidos (ouacelerada se atrasado) e de entrada - e todos os logs em tempo de execuçãotem que ser verificado e qualquer falhas identificadas.Se as falhas ocorrem, em seguida, re-runs terá que ser iniciado, sob aorientação da apropriadas unidade de negócioss, muitas vezes com diferentesparâmetros ou dados alterados / arquivo versãos. Isso vai exigir comunicaçõescuidadosos para garantir parâmetros corretos e arquivos são usados.Muitas organizações se deparam com crescentes horários lote durante a noiteque pode, se superado o slot lote durante a noite, negativamente impacto sobreos serviços on-line dia - assim estão buscando maneiras de utilizar máximadurante a noite capacidade e atuação, Em conjunto com Gerenciamento daCapacidade. Isto é onde Workload Técnicas de gestão podem ser úteis, taiscomo:ITIL V3 - Operação de Serviço - Página: 177 de 423
  • 178. • Re-agendamento de trabalho para evitar a disputa em dispositivosespecíficos ou em momentos específicos e melhorar global rendimento• Migração de cargas de trabalho para plataformas alternativas /ambientespara ganhar um melhor desempenho e / ou produtividade (capacidadesde virtualização de fazer isso muito mais viável, permitindo a migração,dinâmico automatizado)• Sincronismo cuidadoso e "intercalação" de postos de trabalho paraganhar o máximo aproveitamento dos disponíveis recursos.AnedotaUm grande organização, Que foi confrontado com superação lote / utilizaçãoproblemas, identificou que, devido à natureza humana onde as pessoas estavamprocurando ser arrumado, todos os trabalhos estavam sendo iniciado na horaou menos 15 minutos de intervalo durante a hora (ou seja, n horas, 15 minutospassado, passado meia, de 15 minutos a, etc.)Ao re-agendamento de trabalho para que ele começou logo outro trabalhoterminado, e cambaleando os tempos de início de outro trabalho, ele foi capazde obter reduções significativas na disputa e conseguir o processamento muitomais rápido em geral, que se resolveu a sua problemas, sem a necessidade deatualizações.Job Scheduling tornou-se um sofisticado atividade, Incluindo qualquer númerode variáveis - tais como tempo-sensibilidade, dependências críticas e nãocríticas, balanceamento de carga de trabalho, falha e encaminhar, etc Comoresultado, a maioria operaçãos contar com ferramentas que permitem JobScheduling Operações de TI para agendar trabalhos para o melhor uso datecnologia para alcançar Nível de Serviço Objetivos.A mais recente geração de ferramentas de programação permite um únicoconjunto de ferramentas para agendar e automatizar as atividades técnicas eServiço de Gestão de processo atividades (como o agendamento de mudança).Embora esta seja uma boa oportunidade para melhorar eficiência, Representatambém um maior ponto único de falha. As organizações que utilizam esse tipode ferramenta, portanto, ainda usam soluções pontuais como agentes e tambémcomo um apoio no caso de o conjunto de ferramentas principal falhar.5.2.3 Backup e RestauraçãoFaça backup e Restaurar É, essencialmente, um componente do bem Deserviços de TI Planejamento da Continuidade. Como tal, Design de Serviçosdeve assegurar que existem sólidas estratégias de backup para cada serviço eTransição de Serviço deve garantir que estas sejam devidamente testados.ITIL V3 - Operação de Serviço - Página: 178 de 423
  • 179. Além disso, o regulador exigências especificar que certos tipos de organização(Tais como serviços financeiros ou empresas cotadas) deve ter um backupformal e Restaurar estratégia no lugar e que esta estratégia é executado eauditados. Os requisitos exatos variam de país para país e por setor daindústria. Isso deve ser determinado durante Design de Serviços e construído nafuncionalidade do serviço e documentação.O único ponto de fazer backups é que eles podem precisar de ser restaurado emalgum ponto. Por esta razão, não é tão importante para definir como fazer umasistema -se como é para definir quais componentes estão em risco e comoefetivamente mitigar esse risco.Há um sem número de ferramentas disponíveis para backup e restauração, masé importante notar que as características de tecnologias de armazenamentousados para dados corporativos estão sendo utilizados para backup / restore(instantâneos, por exemplo). Há, portanto, um aumento do grau de integraçãoentre as atividades de backup e restauração e as de armazenamento earquivamento (ver secção 5.6).5.2.3.1 backupDados da organização tem que ser protegido e isso vai incluir backup (cópia) earmazenamento de dados em locais remotos, onde pode ser protegidos - eusado deveria precisam ser restaurados, devido à corrupção, perda ouimplementação de TI Plano de Continuidade do Serviços.Uma estratégia de backup global deve ser acordado com o negócio,abrangendo:• Que dados tem de ser apoiada ea freqüência e periodicidade a ser usado.• Quantas gerações de dados têm de ser conservados - isto pode variar deacordo com o tipo de dados que está sendo feito o backup, ou que tipo dearquivo (por exemplo, arquivo de dados ou aplicação executável).• O tipo de backup (completo, parcial, progressiva) e pontos de controlo aserem utilizados.• Os locais a serem utilizadas para o armazenamento (que podem incluirdesastre recuperação locais) e horários de rotação.• Métodos de transporte (por exemplo, a transferência de arquivos atravésda rede, transporte físico em mídia magnética).• Testes / verificações a serem realizadas, como teste-lê, testerestaurações, verificar-somas etc• Objetivo do ponto de recuperação. Isto descreve o ponto para o qual osdados serão restaurados após a recuperação de uma De serviços de TI.Isto pode envolver a perda de dados. Por exemplo, um Objetivo do pontode recuperação de um dia pode ser suportado por apoios diários, e até 24horas de dados podem ser perdidos. Objetivos do ponto de recuperaçãoITIL V3 - Operação de Serviço - Página: 179 de 423
  • 180. para cada serviço de TI deve ser negociado, acordado e documentadoem Olas, SLAs e UCs.• Objetivo Tempo de recuperação. Isso descreve o tempo máximopermitido para a recuperação de um serviço de TI após uma interrupção.O Nível de Serviço a ser fornecida pode ser menor do que o normal Alvode Nível de Serviços. Objetivos de tempo de recuperação para cadaserviço de TI deve ser negociado, acordado e documentado em Olas,SLAs e UCs.• Como verificar se o apoios vai funcionar se eles precisam ser restaurard.Mesmo se não houver erro códigos gerados, pode haver vários motivospara o backup não podem ser restaurados. Um bom backup estratégia eoperaçãosprocedimentos irá minimizar o risco de que isso aconteça. Façabackup procedimentos devem incluir uma verificação passo para garantirque os backups estão completos e que vai funcionar se uma restauraçãoé necessária. Onde qualquer backup falhas são detectados, recuperaçãoações devem ser iniciadas.Há também uma necessidade de adquirir e gerir os meios necessários (discos,fitas, CDs, etc) que serão utilizadas para backups, de modo que não háescassez de oferta.No caso de dispositivos automatizados estão a ser utilizados, de pré-carregamento dos meios de comunicação necessários irá ser necessáriapreviamente. Ao carregar e limpar mídia retornados de fora do local dearmazenamento, é importante que haja um procedimento para verificar se estessão os corretos. Isso impedirá que o backup mais recente é escrito com dadosdefeituosos, e depois de não ter dados válidos para restaurar. Depois debackups bem-sucedidos foram tomadas, a mídia deve ser removido para oarmazenamento.O início real dos backups podem ser automatizados, ou realizada a partir daOperações Ponte.Algumas organizações podem utilizar equipe de operações para realizar otransporte físico e trasfega de cópias de backup de / para locais remotos, onde,em outros casos, esta pode ser entregues a outros grupos, como internasegurança funcionários ou prestadores de serviços externos.Se os backups estão sendo automatizados ou executadas remotamente, emseguida, recursos de monitoramento de eventos devem ser considerados paraque eventuais falhas podem ser detectadas precocemente e corrigidos antesque eles causem problemas. Em tais casos Operações de TI tem um papel adesempenhar na definição alertars e escalada caminhos.Em todos os casos, a equipe de TI Operações devem ser treinados em backup(e restauração) procedimentos - que deve ser bem documentado naITIL V3 - Operação de Serviço - Página: 180 de 423
  • 181. organizaçãoS operações de TI Manual de Procedimentos. Qualquer específicaexigências ou metas deve ser referenciado em UCs OLAs ou se for o caso,enquanto qualquer usuário ou cliente exigências ou atividade deve serespecificado no apropriado SLA.5.2.3.2 RestaurarA restauração pode ser iniciada a partir de um número de fontes, que vão desdeum evento que indica a corrupção de dados, através de um Solicitação deServiço de um usuário ou cliente logado no Service Desk. A restauração poderáser necessária no caso de:• Dados corrompidos• Dados perdidos• A recuperação de desastres /De serviços de TI Situação de continuidade• Dados históricos requerido para a investigação forense.As medidas a serem tomadas irão incluir:• Localização dos dados apropriados / mídia• Transporte ou transferência de volta para o físico recuperação localização• Acordo no ponto de recuperação checkpoint e no local específico para osdados recuperados (disco, diretório, etc pasta)• Restauração real do arquivo / dados (cópia de segurança e qualquer roll-back/roll-forward necessário para chegar ao posto de controle concordou• Verificação para garantir a conclusão do restaurar - Com maisrecuperação ação se necessário até que o sucesso foi alcançado.• Usuário /cliente sign-off.5.2.4 impressão e de saídaMuitos serviços consistem em gerar e fornecer as informações em formaimpressa ou eletrônica. Garantir a informação certa chegue às pessoas certas,com total integridade, Requer formais controlar e gestão.Impressão (física) e de saída (eletrônica) instalações e serviços precisam serformalmente conseguiu porque:• Eles muitas vezes representam a saída tangível de uma serviço. Acapacidade de medir que esta saída atingiu o destino adequado, é muitoimportante (por exemplo, se a verificação de arquivos com financeiratransação dados realmente chegaram a um banco através de um serviçoFTP)• Produção física e eletrônica, muitas vezes contém informações sensíveisou confidenciais. É vital que os níveis adequados de segurança sãoaplicados tanto a geração como o fornecimento deste produto.ITIL V3 - Operação de Serviço - Página: 181 de 423
  • 182. Muitas organizações terão impressão em massa centralizada exigências queOperações de TI deve lidar.Além da carga física e re-carregamento de papel ea operação e cuidados dasimpressoras, outras actividades podem ser necessários, tais como:• Acordo e definição de pré-notificação de impressão grande roda e alertarspara evitar a impressão excessiva de trabalhos de impressão desonestos• Controle físico de alto valor papelaria, como cheques de empresas oucertificados, etc• Gestão do armazenamento físico e electrónico necessário para gerar asaída. Em muitos casos, vai ser obrigado a fornecer arquivos para osmateriais impressos e eletrônicos• Controle de todo o material impresso, de modo a aderir a legislação deprotecção de dados e, por exemplo regulação HIPAA (Health InsurancePortability e Accountability Act) no EUA, Ou FSA (Financial ServicesAuthority) na Reino Unido.Quando os serviços de impressão e de saída são entregues diretamente para ousuários, é importante que a responsabilidade pela manutenção dasimpressoras ou dispositivos de armazenamento é claramente definida. Porexemplo, a maioria dos usuários assumem que a limpeza e manutenção deimpressoras deve ser realizada por TI. Se este não é o caso, isso deve serclaramente indicado no SLA.ITIL V3 - Operação de Serviço - Página: 182 de 423
  • 183. 5.3 Gestão MainframeMainframes ainda são amplamente utilizados e ter bem estabelecido e maduropráticas. Mainframes formar o centro componente de muitos serviços e seusatuação , portanto, definir um linha de base para as expectativas dedesempenho do serviço e do usuário ou cliente, embora nunca pode saber queeles estão usando o mainframe.As formas em que as equipes de gestão de mainframe são organizadas sãobastante diversificadas. Em alguns Gestão Mainframe organizações é umaequipe única, altamente especializada, que gerencia todos os aspectos dasoperações diárias através de sistema engenharia. Em outras organizações, asatividades são realizadas por várias equipes ou departamentos, com engenhariae terceiro nível de apoio a ser prestado por uma equipe e por dia operaçãos aser combinado com o resto da Operações de TI (E muito provavelmente geridaatravés do Operações Ponte).Normalmente, as seguintes atividades deverão ser realizadas:• Operacional de mainframe sistema manutenção e suporte• Terceiro nível de suporte para todos os incidentes relacionados /mainframeproblemas• Escrevendo roteiros de trabalho• A programação do sistema• Interface com suporte de hardware (H / W); arranjar manutenção,concordando slots, identificando H / W falha, Ligação com H / Wengenharia.• Prestação de informações e assistência aos Gerenciamento daCapacidade para ajudar a alcançar o melhor rendimento, Utilização eatuação do mainframe.ITIL V3 - Operação de Serviço - Página: 183 de 423
  • 184. 5,4 Management Server e suporteServidors são usados na maioria das organizações de prestação de serviçosflexíveis e acessíveis de hospedagem aplicaçãos ou bancos de dados,executando cliente/ Servidor de serviços, armazenamento de impressão egerenciamento de arquivos. Gestão bem-sucedida de servidores é, portanto,essencial para o sucesso Operação de Serviço.O procedimentos e as atividades que devem ser realizadas pela Equipe Server(s) ou serviço (s) - equipes separadas podem ser necessárias nos casos emservidor diferente tipos são usados (UNIX, Wintel etc) - incluem:• Suporte de sistema operacional: De suporte e de manutenção dosistema operacional apropriado (s) e, relativamente utilidade software(software de failover, por exemplo), incluindo gerenciamento de patches eenvolvimento na definição apoio e restaurar políticas.• Gerenciamento de licença para todos os itens de configuração doservidor, não especialmente sistemas operacionais, utilitários e softwareaplicativo gerenciado pelas equipes de gerenciamento de aplicativos.• Terceiro nível de suporte: Terceiro nível de suporte para todos osservidores e / ou servidor do sistema de operação relacionadas comincidentes, incluindo diagnóstico e recuperação actividades. Isso tambémirá incluir a ligação com terceiros contratados para suporte a hardware e /ou fabricantes como necessário para escalar hardware incidentesrelacionados.• Conselho aquisições: Aconselhamento e orientação para o negócio daseleção, dimensionamento, aquisição e uso de servidores e softwareutilitário relacionado para atender às necessidades de negócio.• Sistema segurança: Controle e manutenção dos controles de acesso epermissões dentro do servidor relevante ambiente(S), bem como sistemaadequado e de medidas de segurança física. Que incluem a identificaçãoe aplicação de patches de segurança, Gerenciamento de Acesso (Versecção 4.5) e intrusão detecção.• Definição e gestão de servidores virtuais. Isto implica que qualquerservidor que tenha sido projetada e construída em torno de um comumpadrão pode ser usado para processo carga de trabalhos de uma gamade aplicações ou usuários. Management Server será necessário paradefinir esses padrões e, em seguida, garantir que as cargas de trabalhosão devidamente equilibrado e distribuído. Eles também são responsáveispor ser capaz de controlar a carga de trabalho que está sendoprocessado por que servidor de modo que eles são capazes de lidar comincidentes de forma eficaz.• Capacidade e desempenho: Fornecer informações e assistência aosGerenciamento da Capacidade para ajudar a alcançar o melhorrendimento, Utilização e atuação dos servidores disponíveis. Isto édiscutido em mais detalhe na Design de Serviços, Mas inclui oITIL V3 - Operação de Serviço - Página: 184 de 423
  • 185. fornecimento de orientações sobre, e instalação e operação de, osoftware de virtualização de modo a alcançar valor para o dinheiroobtendo os mais altos níveis de desempenho e de utilização de umnúmero mínimo de servidores.• Outro atividades de rotina incluem:o Definição de padrão construirs para os servidores como parte doprovisionamento processo. Isso é abordado com mais detalhes emDesign de Serviços e Transição de Serviçoo Construção e instalação de novos servidores como parte demanutenção contínua ou para a prestação de novos serviços. Istoé discutido em mais detalhe na Transição de Serviçoo Clusters de criação e gestão, que visam a construção deredundância, Melhorando o desempenho do serviço e fazer a infra-estrutura mais fácil de gerenciar.• Manutenção contínua. Isso normalmente consiste na substituição deservidores ou "lâminas" em uma programação de rolamento para garantirque o equipamento é substituído antes de falhar ou se torna obsoleto.Isso resulta em servidores que não são apenas totalmente funcional, mastambém capaz de suportar serviços em evolução• Desmantelamento e eliminação de equipamento servidor antigo. Issogeralmente é feito em conjunto com o organizaçãoPolíticas ambientais "spara eliminação.ITIL V3 - Operação de Serviço - Página: 185 de 423
  • 186. 5,5 Gerenciamento de RedeComo a maioria De serviços de TIs são dependentes de conectividade,gerenciamento de rede será essencial para oferecer serviços e também parapermitir Operação de Serviço pessoal para acessar e gerenciar serviço chavecomponentes.Gerenciamento de rede terá a responsabilidade global para toda a organizaçãopróprias redes locais (LANs), Metropolitan Area Networks (MANs) e redes deárea ampla (WAN) - e também será responsável pelos contactos com terceirosrede fornecedors.Seu papel irá incluir as seguintes atividades:• Inicial planejamento e instalação de novas redes / componentes de rede,manutenção e upgrades para a infra-estrutura de rede física. Isto é feitoatravés do Design de Serviços e Transição de Serviço.• Terceiro nível de suporte para todas as atividades relacionadas à rede,incluindo a investigação de problemas de rede (por exemplo, ping ourastreamento de rota e / ou utilização de ferramentas de software degerenciamento de rede - embora deva ser notado que o ping de umservidor não significa necessariamente que o serviço está disponível! ) deligação e com terceiros, se necessário. Isto também inclui a instalação eutilização de "ferramentas" farejadores, que analisam o tráfego de rede,para ajudar na incidente e problema resolução.• Manutenção e suporte operacional de rede sistema e middlewareincluindo software de gerenciamento de patches, upgrades, etc• Monitoramento de tráfego de rede para identificar falhas ou de detectarpotencial atuação ou questões gargalo.• Reconfigurar ou desvios de tráfego para alcançar melhor rendimento ousaldo massa - definição de regras para o balanceamento dinâmico /roteamento.• Rede segurança (Em articulação com o organizaçãoS Gestão deSegurança da Informação), incluindo acesso de firewall, gestão direitos,Proteção de senha etc• Atribuição e gerenciamento de endereços IP, sistemas de nome dedomínio (DNSs - que convertem o nome de um serviço para seuendereço IP associado) e Dynamic Host Configuration Protocol (DHCP)de sistemas, que permitem o acesso e uso dos DNS.• Gerenciando Provedor de Serviços de Internets (ISPs).• Execução, monitoramento e manutenção de Sistemas de Detecção deIntrusão em nome de Gestão de Segurança da Informação. Eles tambémserão responsáveis por assegurar que não há negação de serviço paralegitimar usuários da rede.• Atualizando Gerenciamento da Configuração se necessário,documentando CIs, estado,relaçãos, etcITIL V3 - Operação de Serviço - Página: 186 de 423
  • 187. Gerenciamento de rede também é muitas vezes responsável, muitas vezes emconjunto com o suporte de desktop, por questões de conectividade remota, taiscomo discagem, dial-back e instalações VPN prestados a casa de trabalho, ostrabalhadores remotos ou fornecedors.Algumas equipes de gerenciamento de rede ou departamentos também terá aresponsabilidade de voz / telefonia, incluindo o fornecimento e apoio aointercâmbio, linhas, ACD, pacotes de software estatísticos etc, e para Voice overInternet Protocol (VoIP) e de monitoramento remoto (RMON) sistemas.Ao mesmo tempo, muitas organizações ver VoIP e telefonia como áreasespecializadas e têm equipes dedicadas ao gerenciamento desta tecnologia. Assuas actividades serão semelhantes aos descritos acima.Nota sobre o gerenciamento de VoIP como serviçoMuitas organizações têm experimentado atuação e disponibilidade problemascom a sua VoIP soluções, apesar do facto de que não parece ser mais do que alargura de banda disponível suficiente. Isso resulta em queda de chamadas esom pobres qualidade. Isso geralmente é devido a variações na utilização dalargura de banda durante o chamar, O que é frequentemente o resultado dautilização da rede por outros utilizadores, aplicaçãos ou outro web atividade. Istolevou à diferenciação entre a medição da largura de banda disponível parainiciar uma chamada (serviço de acesso de banda - ou SAB) e a quantidade delargura de banda que deve ser continuamente disponível durante a chamada(serviço de banda Utilization - ou SUB). Cuidados devem ser tomados nadiferenciação entre estes quando projetar, gerenciar e medir os serviços deVoIP.ITIL V3 - Operação de Serviço - Página: 187 de 423
  • 188. 5,6 Armazenamento e ArquivoMuitos serviços exigem o armazenamento de dados por um tempo específico etambém para que os dados estejam disponíveis off-line por um determinadoperíodo após ele não é mais usado. Este é muitas vezes devido a regulamentarou legislativo exigências, mas também porque a história e auditar dados sãovaliosos para uma variedade de finalidades, incluindo o produto de marketing,desenvolvimento, Investigações forenses, etcA equipe separada ou departamento pode ser necessária para gerir aorganizaçãoA tecnologia de armazenamento de dados, tais como:• Dispositivos de armazenamento, como discos, controladores, fitas, etc• Network Attached Storage (NAS), que é de armazenamento conectado auma rede e acessível por vários clientes• Armazenamento Area Networks (SAN) destinados a conectar dispositivosde armazenamento de computador, tais como controladores de matriz dedisco e bibliotecas de fitas. Para além de dispositivos de armazenamento,uma SAN vai exigir também a gestão de rede diversos componentes,como hubs, cabos, etc• Direct Attached Storage (DAS), o qual é um dispositivo dearmazenamento ligado directamente a um servidor• Armazenamento de conteúdo endereçável (CAS), que é oarmazenamento que é baseado em recuperação de informação com baseno seu teor em vez de localização. O foco neste tipo de sistema é nacompreensão da natureza dos dados e informações armazenados, emvez do que em proporcionar locais de armazenamento específicos.Independentemente do tipo de sistemas de armazenamento estão sendoutilizados, armazenamento e arquivamento vai exigir o gerenciamento doscomponentes da infra-estrutura, bem como as políticas relacionadas ao localonde os dados são armazenados, por quanto tempo, de que forma e quem podeacessá-lo. Responsabilidades específicas incluirão:• Definição de políticas de armazenamento de dados e procedimentos• Convenções de armazenamento de arquivos de nomenclatura, hierarquiae as decisões de colocação• Projeto, dimensionamento, seleção, aquisição, configuração e operaçãode toda a infra-estrutura de armazenamento de dados• Manutenção e suporte para todos utilidade e middleware dearmazenamento de dados de software• Ligação com Informação Ciclo de Vida Gestão de equipe (s) ou Governoequipes para garantir observância com a liberdade de informação deprotecção de dados, governança de TI e regulamentações• Envolvimento com definição e acordo de arquivamento políticaITIL V3 - Operação de Serviço - Página: 188 de 423
  • 189. • Limpeza de todas as instalações de armazenamento de dados• Arquivamento de dados de acordo com regras e horários definidosdurante Design de Serviços. As equipes de armazenamento oudepartamentos irá igualmente contribuir para a definição dessas regras eirá fornecer relatórios sobre a sua eficácia como entrada para futuroprojeto• Recuperação de dados arquivados que for necessário (por exemplo, parafins de auditoria, a evidência forense, ou para atender a todos osrequisitos de outras empresas)• Terceira linha de apoio para armazenamento e arquivamento deincidentes relacionados.ITIL V3 - Operação de Serviço - Página: 189 de 423
  • 190. 5,7 Database AdministrationAdministração de banco de dados deve trabalhar em estreita colaboração com achave Aplicação de Gestão de equipes ou departamentos e em algumasorganizações a funçãos podem ser combinados ou ligados em uma únicaestrutura de gestão. Opções organizacionais incluem:• Administração de banco de dados que está sendo realizada por cadaequipe de Gerenciamento de Aplicativos para todos os aplicaçãos sobseu controle• Um departamento dedicado, que gerencia todas as bases de dados,independentemente do tipo ou aplicação• Vários departamentos, cada um gerenciando um tipo de banco de dados,independentemente de qual aplicativo eles fazem parte.Administração de banco de dados trabalha para garantir o melhoratuação,segurança e funcionalidade de bancos de dados que gerenciam.Administradores de banco de dados normalmente têm as seguintesresponsabilidades:• Criação e manutenção de banco de dados padrãoe as políticas• Banco de dados inicial projeto, Criação de testes,• Gestão da base de dados disponibilidade e desempenho; resiliência,Dimensionamento capacidade volumetria etc• Resiliência pode exigir a replicação de banco de dados, que seria deresponsabilidade da Administração do Banco de Dados• Administração contínua de objetos de banco de dados: tabelas, índices,visões, restrições, seqüências de instantâneos e armazenadosprocedimentos; bloqueios de página - para alcançar melhor utilização• A definição de gatilhos que irão gerar eventos, que por sua vez irá alertaradministradores de banco de dados de desempenho ou potencialintegridade problemas com o banco de dados• Execução de limpeza de banco de dados - as tarefas de rotina queassegurem que os bancos de dados estão funcionando de formaotimizada e segura, por exemplo, afinação, Indexação, etc• Monitoramento de uso; transação volumes, tempo de respostas,simultaneidade níveis, etc• Geração de relatórios. Estes poderiam ser os relatórios com base nosdados no banco de dados ou relatórios relacionados com o desempenhoea integridade do banco de dados• Relatórios de identificação e gestão de questões de segurança de bancode dados; auditar trilhas e forenses• Assistência na elaboração de banco de dados apoio, Arquivamento earmazenamento estratégia• Assistência na alertas dados concepção e gestão de eventosITIL V3 - Operação de Serviço - Página: 190 de 423
  • 191. • Prestação de terceiro nível de suporte de banco de dados para todos osincidentes relacionados.ITIL V3 - Operação de Serviço - Página: 191 de 423
  • 192. 5,8 Diretório de Gestão de ServiçosAServiço de Diretório é um software especializado que gerencia informaçõessobre o recursoEstá disponível em uma rede e quais os usuários têm acesso. Éa base para fornecer acesso a esses recursos e para garantir que o acesso nãoautorizado é detectado e impedido (ver secção 4.5 para informações detalhadassobre Gerenciamento de Acesso).Directory Services vê cada recurso como um objeto do Diretório Servidor eatribui-lhe um nome. Cada nome está ligado ao endereço do recurso de rede, demodo que usuários não tem que memorizar endereços confusos e complexos.Directory Services é baseado em X.500 da OSI padrãos e comumente utilizaprotocolos como o Directory Access Protocol (DAP) ou Lightweight DirectoryAccess Protocol (LDAP). LDAP é utilizado para apoiar as credenciais do usuáriopara aplicação login e muitas vezes inclui usuário interno e externo /clientedados que é especialmente bom para extranet chamar registro. Desde LDAP éum crítico operacional ferramenta, e geralmente mantido até à data, também éuma boa fonte de dados e verificação para o CMS.Gestão de Serviços de Diretório refere-se ao processo que é usado paragerenciar Directory Services. Suas atividades incluem:• Trabalhando como parte de Design de Serviços e Transição de Serviçopara garantir que os novos serviços são acessíveis e controlados quandoeles são implantados• Localização de recursos em uma rede (se não já foram definidos duranteService Design)• O acompanhamento do estado desses recursos e fornecendo acapacidade de gerir esses recursos remotamente• Gerenciando o direitos de específica usuários ou grupos de usuários paraacessar recursos em uma rede• Definir e manter as convenções de nomenclatura para serem utilizadospara os recursos numa rede• Assegurar a coerência de nomeação e acesso controlar em diferentesredes do organização• Ligando diferente Serviço de Diretórios em toda a organização paraformar um serviço de diretório distribuído, ou seja, os usuários só vai verum conjunto lógico de recursos de rede. Isso é chamado de Distribuiçãode Serviços de Diretório• Monitorando eventos sobre os Serviços de Diretório, como tentativas paraacessar um recurso, e tendo a ação apropriada quando necessário• Manutenção e atualização das ferramentas utilizadas para gerenciarDirectory Services.ITIL V3 - Operação de Serviço - Página: 192 de 423
  • 193. 5,9 Desktop SupportComo a maioria o acesso de usuários De serviços de TIs usando computadoresdesktop ou laptop, é fundamental que estes são suportados para garantir osníveis acordados de disponibilidade e atuação de serviços.Suporte de mesa terá a responsabilidade global para toda a área de trabalho daorganização e hardware de computador portátil, software e periféricos.Responsabilidades específicas incluirão:• Políticas de desktop e procedimentos, por exemplo, as políticas delicenciamento, uso de laptops ou desktops para fins pessoais, USBbloqueio, etc• Projetando e concordando imagens de desktop padrão• Área de trabalho de manutenção do serviço, incluindo desenvolvimentode liberars, upgrades, patches e correções (hot-em conjunto comGerenciamento de Liberação (Ver publicação Transição de Serviço paramais detalhes)• Concepção e implementação de área de trabalho de arquivamento /reconstruir política (Incluindo a política relativa aos cookies, favoritos,modelos, dados pessoais, etc)• Terceiro nível de suporte do ambiente de trabalho relacionados comincidentes, incluindo mesa as visitas sempre que necessário• Suporte para problemas de conectividade (em conjunto com ogerenciamento de rede) para a casa de trabalho, o pessoal móvel, etc• Controle de configuração e auditar de todos os equipamentos de área detrabalho (em conjunto com Gerenciamento da Configuração e Auditoriade TI).ITIL V3 - Operação de Serviço - Página: 193 de 423
  • 194. 5,10 Middleware GestãoMiddleware é um software que conecta ou integra software componentes emtodo distribuída ou díspar aplicaçãos e sistemas. Middleware permite a efetivatransferência de dados entre aplicações, e é, portanto, fundamental paraserviços que dependem de vários aplicativos ou fontes de dados.Uma variedade de tecnologias são atualmente usados para apoiar o programapara programa de comunicação, como corretores de solicitação de objetos,middleware orientado a mensagem, controle remoto procedimento chamadas eserviços ponto-a-ponto web. Mais recentes tecnologias estão surgindo o tempotodo, por exemplo Enterprise Service Bus (ESB), que permite que os programas,sistemas e serviços para se comunicar uns com os outros, independentementeda arquitetura e origem das aplicações. Isto é especialmente utilizado nocontexto da implantação Service Oriented Architectures (SOA).Middleware Management pode ser realizada como parte de um Aplicação deGestão de função (Em que é dedicado a uma aplicação específica), ou comoparte de um Gestão Técnica função (onde ele é visto como uma extensão para osistema operacional de uma plataforma específica).Funcionalidade fornecida pelo middleware inclui:• Fornecer mecanismos de transferência de dados de várias aplicações oufontes de dados• O envio de trabalho para outra aplicação ou procedimento para oprocessamento• Transmissão de dados ou informações para outros sistemas, tais comodados de sourcing para publicação em sites (por exemplo, publicação deIncidentes estado informação)• Liberando atualizados módulos de software em todo distribuído ambientes• Agrupamento e distribuição de mensagens do sistema e instruções, porexemplo, eventos ou operacional scripts que precisam ser executados emdispositivos remotos• Configuração de multicast com redes. Multicast é a entrega deinformações a um grupo de destinos em simultâneo através da rota deentrega mais eficiente• Gerenciando tamanhos de fila.Middleware Management é o conjunto de atividades que são usados paragerenciar middleware. Estes incluem:• Trabalhando como parte de Design de Serviços e Transição para garantirque o apropriado middleware As soluções são escolhidas e que elespossam desempenhar optimamente quando eles são implantadosITIL V3 - Operação de Serviço - Página: 194 de 423
  • 195. • Garantir a correta operação de middleware através de monitoramento econtrolar• Detecção e resolução de incidentes relacionados com middleware• Manutenção e atualização de middleware, incluindo o licenciamento einstalação de novo versãos• Definir e manter informações sobre como aplicaçãos estão ligadosatravés de Middleware. Isso deve ser parte da CMS (ver Transição deServiço publicação).ITIL V3 - Operação de Serviço - Página: 195 de 423
  • 196. 5,11 Gestor da Internet / WebMuitas organizações conduzir muito de seu negócio através da Internet e são,portanto, fortemente dependente do disponibilidade e atuação de seus sites.Nesses casos, uma equipe de suporte em separado Internet / Web oudepartamento será desejável e justificado.As responsabilidades de uma equipe ou departamento de incorporar tantoIntranet e Internet e é provável que incluem:• Definindo arquiteturas para serviços de Internet e web• O especificação de padrãos para desenvolvimento e gestão de aplicaçõesbaseadas na web, conteúdo, sites e páginas da web. Este serátipicamente feito durante Design de Serviços• Design, testes, implementação e manutenção de websites. Isso irá incluira arquitetura de sites eo mapeamento de conteúdo a ser disponibilizado• Em muitas organizações, o gerenciamento web irá incluir a edição doconteúdo a ser postado na web• Manutenção de todo o desenvolvimento web e gerenciamento deaplicativos• Ligação e conselhos para web-conteúdo equipes dentro da empresa. Oconteúdo pode residir em aplicativos ou dispositivos de armazenamento,o que implica uma estreita ligação com Aplicação de Gestão de e outrosGestão Técnica equipes• Ligação e gestão de fornecedores dos ISPs, os anfitriões, omonitoramento de terceiros ou de organizações de virtualização etc Emmuitas organizações os ISPs são gerenciados como parte deGerenciamento de Rede• Terceiro nível de suporte para incidentes Internet-/web-related• Suporte para interfaces com back-end e legado sistemas. Isso muitasvezes significa trabalhar com os membros do Desenvolvimento deAplicações e equipas de gestão para garantir acesso seguro econsistência de funcionalidade• Monitoramento e gerenciamento de desempenho do site e incluindo:testes de batimentos cardíacos, usuário simulação experiência, aferição,On-demand de balanceamento de carga de virtualização,• Site disponibilidade,resiliência e segurança. Isto fará parte do conjuntoGestão de Segurança da Informação do organizaçãoITIL V3 - Operação de Serviço - Página: 196 de 423
  • 197. 5,12 Instalações e Data Management CentreGestão de Instalações refere-se à gestão da física ambiente de Operações deTI, Geralmente localizados nos centros de dados ou salas de informática. Esta éuma área vasta e complexa e esta publicação irá fornecer uma visão geral desua chave papel e atividades. Uma visão mais detalhada está contida no AnexoE.Em muitos aspectos, Gestão de Instalações poderia ser visto como um funçãoem seu próprio direito. No entanto, por causa desta publicação está focada emque as operações de TI estão alojados, cobrirá Facilities Managementespecificamente no que se refere à gestão dos centros de dados e, como umsubconjunto da TI Gestão de Operações função.O principal componentes de Gestão de Instalações são as seguintes:• Gestão de Edifícios, Que refere-se à manutenção e conservação dosprédios que abrigam o Centro de TI pessoal e de dados. As atividadestípicas incluem limpeza, eliminação de resíduos, gestão doestacionamento e acesso controlar• Equipamentos de hospedagem, O que garante que todo especialexigências são fornecidos para a habitação física de equipamentos e asequipes que os suportam• Gerenciamento de energia, A qual refere-se a gerir o fornecimento eutilização de fontes de energia que são utilizados para manter a unidadefuncional. Esta definição de gerenciamento de energia tem uma série deimplicações, que são discutidos no Apêndice E. Nota que as informaçõessobre utilização de energia é importante para a planejamento ocapacidade de ambos os novos serviços e novas construções• Condicionamento ambiental e Alertar Sistemas, Os quais incluem oespecificaçãoE manutenção monitoramento de sistemas como a detecçãode fumaça e combate a incêndios, de água, sistemas de aquecimento erefrigeração, etc• Segurança refere-se observância a toda a legislação, padrãos e políticasem relação à segurança dos empregados• Controle de Acesso Físico refere-se a assegurar que a instalação só éacessado por pessoal autorizado e que qualquer acesso não autorizado édetectado e gerenciado. Isto é discutido em mais detalhe no Apêndice F• Envio e recebimento refere-se à gestão de todos os equipamentos,móveis, correio, etc, que sai ou entra no edifício. Ele garante que somenteitens apropriados estão entrando ou saindo do prédio e que eles sãoencaminhados para a festa correta• Envolvimento em Gestão de Contratos dos vários fornecedors e provedorde serviçoss envolvidas na instalaçãoITIL V3 - Operação de Serviço - Página: 197 de 423
  • 198. • Manutenção refere-se a manutenção, regulares programadas dainstalação, bem como a detecção e resolução de problemas com afacilidade.Nota importante sobre os Centros de DadosCentros de dados são geralmente unidades especializadas e, enquanto elesusam e se beneficiar de genéricos disciplinas Facilities Management, elesprecisam se adaptar estes. Por exemplo aquecimento layout, e podercondicionado, planejamento e muitos outros aspectos são geridosexclusivamente em Centros de Dados.Isto significa que, apesar de centros de dados pode ser detida por uminstalações organização, Eles são melhor geridas sob a autoridade doOperações de TI, Embora possa haver uma linha de comunicação funcionalentre a TI eo departamento que gerencia outras facilidades para a organização.5.12.1 Dados estratégias CentroGerenciando um Centro de Dados é muito mais do que hospedar um espaçoaberto onde grupos técnicos instalar e gerenciar equipamentos, utilizando assuas próprias abordagens e procedimentos. Ela exige um conjunto integrado deprocessos e procedimentos envolvendo todos os grupos de TI em todas as fasesdo ITSM Ciclo de Vida. Centro de Dados operaçãos são regidas pela estratégicoe projeto decisões para o manejo e controlar e são executadas pelosoperadores. Isso exige uma série de fatores-chave a serem postas em prática:• Dados Automação Centro. Automação especializado sistemas, quereduzem a necessidade de operadores manual e que monitorar eacompanhar o estado da instalação e todos Operações de TI sempre• PolíticaGestão baseada em onde as regras de automação e recursoalocação são geridos pela política, ao invés de ter que passar porcomplexo mudar procedimentos de processamento a cada momento émovido de um recurso para outro• Serviços de tempo real 24 horas por dia, 7 dias por semana• Normalização do equipamento. Isso proporciona maior facilidade degerenciamento, os níveis mais consistentes de atuação e um meio defornecimento de serviços múltiplos através de tecnologia semelhante.Padronização também reduz a variedade de conhecimentos técnicosnecessários para gerir equipamentos no Centro de Dados e para fornecerserviços• SOAs, Onde o serviço componentes pode ser reutilizado, trocadas esubstituído muito rapidamente e sem impacto sobre o negócio. Istotornará possível para o Centro de Dados para ser altamente responsivoem atender às demandas empresariais em constante mudança, sem terde passar pelo demorado e complicado re-engenharia e rearquiteturaITIL V3 - Operação de Serviço - Página: 198 de 423
  • 199. • Virtualização. Isto significa que, De serviços de TIs são entreguesatravés de um conjunto em constante mudança de equipamentos,voltados para atender a demanda atual. Por exemplo, um aplicativo podeser executado em um dispositivo dedicado juntamente com o seu bancode dados durante a alta demanda vezes, mas mudou para um dispositivocompartilhado com seu banco de dados em um dispositivo remoto nãodurante horários de pico - tudo automatizado e automático. Isto significauma economia ainda maior de custars como qualquer equipamento podeser usado a qualquer momento, sem qualquer intervenção humana,exceto para realizar a manutenção e substituição de equipamentosfalhou. O Infraestrutura de TI é mais resiliente porque qualquercomponente é apoiada por qualquer número de componentessemelhantes, qualquer um dos quais pode ter mais de um componentefalha carga de trabalho automaticamente.Remoto monitoramento,controlar e equipamentos de sistemas de gestãoe será essencial para gerenciar uma virtualizado ambiente, Como muitosserviços não será ligada a qualquer uma peça específica do equipamento.• Unificado sistema de gestãos tornaram-se mais importante como osserviços são executados em vários locais e tecnologias. Hoje, éimportante definir que ações devem ser tomadas e que sistemas vaiexecutar essa ação. Isso significa investir em soluções que permitam aosgerentes de infra-estrutura simplesmente especificar o que resultado énecessário, e permitindo que o sistema de gestão para calcular a melhorcombinação de instrumentos por forma a atingir o resultado.ITIL V3 - Operação de Serviço - Página: 199 de 423
  • 200. 5,13 Gestão de Segurança da Informação e Operação deServiçoGestão de Segurança da Informação como processo é abordado no ITIL Designde Serviços publicação. Gestão de Segurança da Informação tem aresponsabilidade global para definição de políticas, padrãos e procedimentospara assegurar a protecção da organizaçãoS ativoss, dados, informações e Deserviços de TIs. Operação de Serviço equipes jogam um papel na execuçãodessas políticas, normas e procedimentos e trabalhará em estreita colaboraçãocom as equipes ou departamentos responsáveis de Gestão de Segurança daInformação.Equipes de operação de serviço não pode tomar posse de Gestão de Segurançada Informação, isso representaria um conflito. É preciso haver segregação defunções entre os grupos de definir e gerir o processo e os grupos que executamatividades específicas como parte do curso operação. Isso vai ajudar a protegercontra violações de segurança medidas, como nenhum indivíduo deve tercontrolar ao longo de dois ou mais fases de um transação ou operação. Gestãode Segurança da Informação deve atribuir responsabilidades para garantir umaverificação cruzada de funções.O papel das equipes de operação de serviço é descrito a seguir.5.13.1 Policiamento e relatóriosIsso vai envolver a equipe Operação realizar atividades específicas depoliciamento, tais como a verificação de revistas, logs de sistema,evento/monitoramento alertars etc, intrusão detecção e / ou relatórios deviolações de segurança reais ou potenciais. Isso é feito em conjunto com aGestão de Segurança da Informação para fornecer um sistema de verificação eequilíbrio para garantir a detecção e gestão eficaz dos problemas de segurança.Pessoal Operação de Serviço são muitas vezes primeiro a detectar eventos desegurança e estão em melhor posição para ser capaz de desligar e / ou removero acesso a sistemas comprometidos.Particular atenção será necessária no caso de organizações de terceiros querequerem acesso físico à organização. Pessoal Operação de Serviço pode serobrigado a escoltar visitantes em áreas sensíveis e / ou controlar o seu acesso.Eles também podem ter um papel a desempenhar no controle de acesso de redea terceiros, como mantenedores de hardware discando para fins de diagnóstico,etcITIL V3 - Operação de Serviço - Página: 200 de 423
  • 201. 5.13.2 Assistência técnicaAlguns suporte técnico pode precisar de ser fornecida para a equipe de TI deSegurança para ajudar na investigação de incidentes de segurança e auxiliar naprodução de relatórios ou na coleta de provas forenses para uso em açãodisciplinar ou processos criminais.Consultoria e assistência técnica também pode ser necessária em relação amelhorias de segurança em potencial (por exemplo, a criação de firewallsapropriadas ou acesso / senha controles).O uso de evento, incidente,problema e gerenciamento de configuraçãoinformação pode ser invocado para fornecer cronologias precisas de segurançarelacionados com as investigações.5.13.3 controle de segurança operacionalPara operacional razões, o pessoal técnico, muitas vezes, precisa ter acessoprivilegiado às principais áreas técnicas (por exemplo, raiz sistema senhas, oacesso físico aos dados Centros ou etc comunicações quartos). É, portanto,essencial que controles adequados e auditar trilhas são mantidos de todasessas atividades privilegiadas, de modo a prevenir e detectar qualquersegurança eventos.Controles físicos precisam estar no local para todas as áreas seguras com ologin-out de todos os funcionários. Onde terceiro funcionários ou visitantesprecisam de acesso, pode ser Operação de Serviço funcionários que sãoresponsáveis pela escolta e gerir o movimento desse pessoal.No caso de sistemas de acesso privilegiado, isso precisa ser restrito a apenasaquelas pessoas cuja necessidade de acessar o sistema foi verificado - eretirado imediatamente quando essa necessidade não existe mais. Uma trilha deauditoria deve ser mantida de quem tem acesso e quando teve, e de todas asatividades realizadas com os níveis de acesso.5.13.4 Seleção e habilitaçãoTodo o pessoal Operação de Serviço deverão ser avaliados e controlados a umnível de segurança adequado ao organização em questão.Fornecedors e de terceiros contratados também devem ser avaliados econtrolados - ambas as organizações e os específicos de pessoal envolvido.Muitas organizações começaram a usar a polícia ou do governo deantecedentes da agência, especialmente onde os contratantes estarãotrabalhando com sistemas de classificados. Sempre que necessário, asorganizações não-revelação e confidencialidade acordos deve ser acordado.ITIL V3 - Operação de Serviço - Página: 201 de 423
  • 202. 5.13.5 Treinamento e conscientizaçãoTodo o pessoal Operação de Serviço deve ser dada formação regular e contínuae consciência da organização do política de segurança e procedimentos. Estedeve incluir detalhes de medidas disciplinares no lugar. Além disso, a segurançade qualquer exigências deve ser especificado no do empregado contrato deemprego.5.13.6 políticas e procedimentos documentadosProcedimentos de serviço de operação documentados deve incluir todas asinformações pertinentes relativas a questões de segurança - extraído da políticade segurança da organização geral documentos. Deve-se considerar a utilizaçãode manuais para auxiliar na obtenção das mensagens de segurança para todo opessoal relevante.ITIL V3 - Operação de Serviço - Página: 202 de 423
  • 203. 5,14 Melhoria das actividades operacionaisTodo o pessoal Operação de Serviço deve ser constantemente à procura deáreas em que processo melhorias podem ser feitas para dar maior De serviçosde TI qualidade e / ou executados de forma mais rentável. Isto pode incluiralgumas das seguintes atividades.5.14.1 automação de tarefas manuaisQuaisquer tarefas que têm de ser realizadas manualmente, particularmenteaqueles que têm de ser regularmente repetido, são susceptíveis de ser maisdemorada, dispendiosa e erro propensos do que os que podem sersistematizado e automatizado. Todas as tarefas devem ser examinados paraautomação potencial para reduzir o esforço e custars e para minimizar os errospotenciais.A decisão deve ser feita na custars da automação e os prováveis benefícios queirão ocorrer.5.14.2 Rever atividades improvisadas ou procedimentosDevido à natureza pragmática de Operação de Serviço, Que por vezes podesurgir de que as atividades improvisadas ou processos são introduzidos pararesolver a curto prazo operacional expedientes. Existe o perigo de que talpráticas pode ser continuado e tornar-se a "norma" - levando a ineficiências emcurso. Onde quaisquer atividades ou improvisados procedimentos tem de serintroduzida, é importante que estas sejam revered, logo que a oportunidadeimediata é superar - e, ou suprimida ou substituída por processos eficientesacordados para o prazo mais longo.5.14.3 Auditorias OperacionaisRegular auditars deve ser conduzida de todos os processos de operação deserviço para garantir que eles estão trabalhando de forma satisfatória.5.14.4 Usando o Gerenciamento de Incidentes e de ProblemasProblema e Gerenciamento de Incidentes proporcionar uma fonte rica deoperacional oportunidades de melhoria. Esses processos são discutidos emdetalhe no capítulo 4 desta publicação.5.14.5 ComunicaçãoDeve ir sem dizer que a boa comunicação sobre a mudança exigências, atecnologia e os processos resultará em melhoria na operação do serviço. NoITIL V3 - Operação de Serviço - Página: 203 de 423
  • 204. entanto, a comunicação é muitas vezes negligenciada. Melhoria Operaçãoserviço é dependente da comunicação formal e regular entre as equipesresponsáveis pela projeto, Suporte e operação de serviços.5.14.6 A educação ea formaçãoEquipes de operação de serviço deve compreender a importância do que fazemem uma base diária. Educação é necessária para garantir que o pessoalentender o que o negócio funçãos ou serviços são suportados por suasatividades. Isso irá incentivar um maior cuidado e atenção aos detalhes etambém vai ajudar as equipes de operação do serviço, para melhor identificar asprioridades de negócios.Treinamento programas deve assegurar que todos os funcionários têm ashabilidades necessárias para a tecnologia ou aplicaçãos que eles estãoconseguindo. A formação deve ser sempre fornecida quando uma novatecnologia é introduzida, ou quando a tecnologia existente é alterado.ITIL V3 - Operação de Serviço - Página: 204 de 423
  • 205. 6 Organizador para Operação de Serviço6.1 FunçõesAfunção é um conceito lógico que se refere ao povo e medidas automatizadasque executam um definido processo, Um atividade ou uma combinação deprocessos ou atividades. Em organizações maiores uma função pode serdividida e executada por vários departamentos, equipes e grupos, ou pode serincorporado dentro de uma única unidade organizacional.Figura 6.1 Funções de operação de serviçoITIL V3 - Operação de Serviço - Página: 205 de 423
  • 206. A Operação de Serviço funçãos dado na Figura 6.1 são necessários para gerir o"estado estável" operacional TI ambiente. Estas são funções lógicas e nãonecessariamente tem que ser feita por uma estrutura equivalente organizacional.Isto significa que a técnica e Aplicação de Gestão de podem ser organizados emqualquer combinação e em qualquer número de departamentos. Osagrupamentos de segundo nível na Figura 6.1 são exemplos de grupos típicosde atividades realizadas por Gestão Técnica (Ver Capítulo 5) e não são umasugestão organização estrutura.A seguir, um resumo das principais funções de Serviço de Operação na Figura6.1:• O Service Desk é o principal ponto de contato para usuários quando háuma serviço interrupção, por solicitação de serviços ou até mesmo paraalgumas categorias de Requisição de Mudança. O Service Desk forneceum ponto de comunicação com os usuários e um ponto de coordenaçãopara vários grupos de TI e processos. Para habilitá-los para realizar essasações efetivamente o Posto de Serviço é normalmente separado dosoutros Funções de operação de serviço. Em alguns casos, por exemplo,onde detalhada suporte técnico é oferecida aos usuários no primeirochamar, Pode ser necessário para a técnica ou Aplicação de Gestão deequipe para estar no Service Desk. Isso não significa que o Service Deskse torna parte de theTechnical função de Gestão. De fato, enquanto elesestão no Service Desk, eles deixam de ser uma parte da gestão técnicaou funções de gerenciamento de aplicativos e tornar-se parte do ServiceDesk, mesmo que apenas temporariamente.• Gestão Técnica fornece detalhadas habilidades técnicas e recursosnecessários para suportar o curso operação do Infraestrutura de TI.Gestão Técnica também desempenha um importante papel no projeto,Testes, liberar e melhoria das De serviços de TIs. Em pequenasempresas, é possível gerenciar essa experiência em um únicodepartamento, mas as grandes organizações são normalmente divididaem vários departamentos especializados tecnicamente (ver mais adianteneste capítulo). Em muitas organizações, os departamentos de Gestãotécnicos são também responsáveis pela operação diária de umsubconjunto da infra-estrutura de TI. A Figura 6.1 mostra que, emborasejam parte de um departamento de gestão técnica, funcionários querealizam essas atividades são logicamente parte da função deGerenciamento de Operações de TI.• TI Gestão de Operações é a função de responsável pela diáriaoperacional atividades necessárias para gerenciar a infra-estrutura de TI.Isso é feito de acordo com o desempenho Padrãos definido duranteDesign de Serviços. Em algumas organizações este é um departamentoúnico e centralizado, enquanto em outros algumas atividades efuncionários são centralizados e alguns são fornecidos por departamentosdistribuídos ou especializada. Isto é ilustrado na Figura 6.1 pelaITIL V3 - Operação de Serviço - Página: 206 de 423
  • 207. sobreposição de funções de gestão técnica e de aplicativos. Gestão deOperações de TI tem duas funções que são únicas e que são geralmenteformais estruturas organizacionais. Estes são os seguintes:• Operações de TI Controle, O qual é geralmente composta pordeslocars de operadores e que assegura que as tarefas rotineirasoperacionais são realizadas. Controle de Operações de TI tambémirá fornecer centralizado monitoramento e controlar actividades,geralmente usando uma Operações Ponte ou Centro deOperações de Rede.• Gestão de Instalações refere-se à gestão da TI física ambiente,Geralmente centros de dados ou salas de informática. Em muitasorganizações Técnica e Gerenciamento de Aplicativos são co-localizado com Operações de TI nos Centros de dados grandes.Em algumas organizações muitas física componentes daInfraestrutura de TI foram terceirizados e gestão de instalaçõespodem incluir a gestão do terceirização contratos.• Aplicação de Gestão de é responsável pela gestão aplicaçãos ao longoda sua ciclo de vida. O Gerenciamento de Aplicativos função suporta emantém operacional aplicações e também desempenha um importantepapel no projeto, Teste e aperfeiçoamento de aplicações que fazem partedo De serviços de TIs. Gerenciamento de Aplicativos é geralmentedividida em departamentos com base no portfólio de aplicativos doorganização (Veja os exemplos na figura 6.1), permitindo assim mais fácilde especialização e de mais apoio focado. Em muitas organizaçõesdepartamentos de gestão de aplicativos têm funcionários que realizamdiariamente operaçãos para esses aplicativos. Tal como acontece comGestão Técnica, Esse pessoal logicamente parte do TI Gestão deOperações função.Nota especial sobre Gestão de Segurança da InformaçãoEmbora a maioria concorda que a Gestão de Segurança da Informação é umfunção, É altamente especializada e abrange diversas fases do ciclo de vida.Também é responsável pela supervisão de muitas atividades dentro de tudoOperação de Serviço funções. Para uma descrição mais aprofundada de Gestãode Segurança da Informação, por favor consulte o Design de Serviçospublicação e de seção 5.13 desta publicação.6.1.1 Funções e atividadesCapítulo 5 desta publicação introduziu uma série de atividades de operaçãocomum de serviço. Devido à natureza técnica e especialização dessasatividades, as equipes, grupos ou departamentos que os executam são muitasvezes recebem nomes que correspondem às atividades particulares. Porexemplo, Gerenciamento de Rede pode ser realizado por um Departamento deGestão de Rede ". Isto, no entanto, é de modo nenhum uma regra. Há umITIL V3 - Operação de Serviço - Página: 207 de 423
  • 208. número de opções disponíveis no mapeamento atividades para uma equipe oudepartamento, por exemplo:• Um atividade poderia ser realizada por várias equipes ou departamentos,por exemplo, se uma organização tem cinco departamentos principaisaplicativos de apoio, cada um apoiando um conjunto diferente deaplicativos, cada um destes departamentos pode executar aAdministração de banco de dados para aplicações de suas• Um departamento pode realizar várias actividades, como por exemplo doDepartamento de Gestão de Rede pode ser responsável pela gestão darede, Serviço de Diretórios Gestão e Servidor Gestão• Uma actividade pode ser realizada, por exemplo, por gruposAdministração de Segurança pode ser realizada por qualquer pessoa coma responsabilidade de gerir uma aplicação de servidor, middleware oudesktop.Estas decisões organizacionais são influenciadas por uma série de factores, taiscomo:• A dimensão e localização da organização. Menores, as organizaçõesmenos distribuídos tendem a combinar essas funções, enquanto queempresas grandes e descentralizadas pode ter várias equipes oudepartamentos realizando o mesmo atividade (Por exemplo, por região).• A complexidade da tecnologia utilizada no organização. Quanto maior onúmero de diferentes tecnologias utilizadas, o mais provável, há de servárias equipes diferentes, cada um fazendo algo semelhante, mas em umcontexto diferente (por exemplo, UNIX Servidor Gestão e degerenciamento do Windows Server).• O disponibilidade de competências. Onde as habilidades técnicas sãoescassos, é comum que as organizações usem generalistas paraexecutar vários grupos de atividades - embora, em alguns casos,segurança considerações tornam isso muito difícil. Por exemplo, umaorganização que trabalha em classificados ou segredo projetos pode terque contratar caro, especializado recursos, mesmo quando isso significaque realocá-los ou contratação através de segurança-Limpoufornecedores.• O cultura da organização. Algumas organizações preferem trabalhar emaltamente especializada ambientes, enquanto outros tendem a preferir aflexibilidade da equipe generalista.• A situação financeira da organização vai determinar quantas pessoas,com que tipo de habilidade, pode ser empregada e como eles serãoorganizados.Como resultado desses fatores, é impossível para esta publicação paraprescrever uma estrutura organizacional adequada que vai caber a cadasituação, no entanto, as seções a seguir listam as atividades necessárias sob osITIL V3 - Operação de Serviço - Página: 208 de 423
  • 209. grupos funcionais mais propensos a se envolver em seu operação. Por favor,note que isso não significa que todas as organizações têm de usar essasdivisões. Organizações menores tendem a combinar essas atividades emdepartamentos individuais, ou mesmo indivíduos - se eles são mesmonecessários em tudo.Nota especial sobre terceirizaçãoEstas considerações organizacionais tendem a ser mais relevante para asorganizações de TI internos. A situação se torna ainda mais complexa quandoparte ou a totalidade de uma determinada atividade ou função são terceirizados.Excelentes oportunidades para a terceirização tem sido o Service Desk eOperações de Rede. Isto será explicado em mais pormenor na ITIL Orientaçãocomplementar, mas alguns dos pontos-chave para se lembrar são:• Independentemente de quem está realizando o atividade, A empresa quecontrata o contratante ainda é responsável por garantir que ele érealizado para uma padrão que irá apoiar a prestação de serviços aosseus clientes e usuários.• Terceirização para resolver de uma organização problemas ou como umaalternativa ao bom Serviço de Gestão de processos raramente funciona.Os melhores resultados são obtidos quando estes estão em vigor antesda terceirização.• Terceirização funciona melhor quando há o envolvimento ativo de ambasas organizações. Se a equipe e gerentes da organização do clientedesengatar, o contratante é improvável que seja bem sucedido,simplesmente porque ninguém entende a organização melhor do que aspessoas que trabalham lá.• O contratante não deve determinar suas saídas ou como eles sãomedidos. Estas são determinadas através da compreensão da empresaexigências de usuários e clientes e garantir que eles possam seratendidas pelos recursos de que o contratante do.• Embora os serviços que o contratante se tornam parte integrante doorganização, Eles ainda são uma organização de terceiros, com umconjunto diferente de objetivo de negócios, políticas e práticas. Segurançapadrãos deve ser acolhida e ambas as partes devem entender claramenteseus respectivos papels e contribuições.ITIL V3 - Operação de Serviço - Página: 209 de 423
  • 210. 6,2 Service DeskAService Desk é uma unidade funcional formada por um número específico depessoal responsável pelo tratamento de uma variedade de serviços eventos,muitas vezes feita através de chamadas telefónicas, interface web, ou eventosde infra-estrutura automaticamente notificados.O Service Desk é uma parte vital do Departamento de TI de uma organização edeve ser o único ponto de contato para TI usuários em uma base dia-a-dia - e irálidar com todos os incidentes e solicitação de serviços, geralmente usandoferramentas de software especializados para registrar e gerenciar todos esseseventos.O valor de um Service Desk eficaz não deve ser subestimado - um Service Deskbom muitas vezes pode compensar deficiências em outras partes daorganização de TI, mas um Service Desk pobres (ou a falta de um Posto deServiço) pode dar uma má impressão de uma outra maneira muito organizaçãode TI eficaz!Por isso, é muito importante que o calibre correto de pessoal utilizado no ServiceDesk e que Gerentes de TI fazer o seu melhor para fazer a mesa de um lugaratrativo para trabalhar para melhorar a retenção de pessoal.A natureza exata, tipo, tamanho e localização de um Service Desk pode variar,dependendo do tipo de negócio, número de usuários, a geografia, acomplexidade das chamadas, escopo de serviços e de muitos outros fatores.Em alinhamento com cliente e de negócios exigências, os gerentes seniores daorganização de TI, deve decidir a natureza exata de seu Service Desknecessária (e se deve ser interna ou terceirizada para uma terceiro) Como partede sua ITSM geral estratégia (Ver Estratégia de Serviço publicação) - e posteriorplanejamento deve ser feito para preparar e implementar o Service Deskapropriado função (Seja na implementação de uma nova função, ou, maisprovavelmente nos dias de hoje ao fazer alterações necessárias para umafunção existente - veja Design de Serviços e Transição de Serviço publicações).6.2.1 Justificação e do papel do Service DeskMuito pouca justificação é necessário hoje para um Service Desk, como muitasorganizações têm se convencido de que esta é de longe a melhor abordagempara lidar com questões de primeira linha de suporte de TI. Basta fazer apergunta "Qual é a alternativa?" Para fazer um caso convincente para o conceitode Service Desk. Onde justificação adicional é necessária, os seguintesbenefícios devem ser considerados:ITIL V3 - Operação de Serviço - Página: 210 de 423
  • 211. • Melhor serviço ao cliente, percepção e satisfação• Acessibilidade aumentada através de um único ponto de contacto decomunicação e informação• Melhorqualidade e de resposta mais rápido de pedidos do cliente ouusuário• Melhor trabalho em equipe e comunicação• Maior concentração e uma abordagem pró-ativa para a prestação deserviços• Um negócio reduzida negativo impacto• Melhor infra-estrutura e de gestão controlar• Melhor utilização de Suporte de TI recursos e aumento da produtividadedo pessoal de negócios• Mais significativo gestão da informação de apoio à decisão• É comum prática que o Service Desk posições fornece "nível de entrada"para o pessoal de ITSM. Trabalho sobre o Service Desk é uma terraexcelente para quem deseja seguir a carreira de Serviço de Gestão de.No entanto, isso também pode apresentar desafios com pessoas que nãoentendem do negócio ou da tecnologia. Usuáriochamando o Service Deskdeve ser capaz de falar com alguém que é capaz de atender às suasnecessidades, e os analistas do Service Desk não deve ser queimado emmenos de um ano por causa de estresse. Cuidados devem ser tomadospara selecionar adequadamente os indivíduos qualificados com um bomentendimento do negócio e fornecer treinamento adequado - reduçãoimpedindo assim em níveis de apoio, devido à falta de conhecimento naprimeira linha.6.2.2 Posto de objectivos de serviçoO objetivo principal do Service Desk é restaurar normal serviçoAos usuários omais rápido possível. Neste "contextorestauração do serviçoSignifica, no sentidomais amplo possível. Enquanto isto pode envolver a fixação de um técnicoculpa, Pode igualmente envolver o cumprimento de uma solicitação de serviçoou respondendo a uma consulta - tudo o que é necessário para permitir que osusuários de voltar a trabalhar de forma satisfatória.Responsabilidades específicas incluirão:• Registrando todas as informações relevantes incidente/ Serviço detalhesda solicitação, a categorização alocação e códigos de priorização• Fornecer primeira linha de investigação e diagnóstico• Resolver os incidentes / requisições de serviços que eles são capazes• A escalada de incidentes / requisições de serviços que não podem serresolvidos dentro de prazos acordados• Manter os usuários informados sobre o progresso• Fechar todos os incidentes resolvidos, pedidos e outras chamadasITIL V3 - Operação de Serviço - Página: 211 de 423
  • 212. • Condutor cliente/ Satisfação do usuário call-backs/surveys conformeacordado• Comunicação com os usuários - mantendo-os informados de incidenteprogresso, interrupções notificando-os de mudanças iminentes ouacordado, etc• Atualizando o CMS sob a direção e aprovação de Gerenciamento daConfiguração se assim for acordado.Nota: essas atividades são explicados e definir em contexto com a maiscompleta Gerenciamento de Incidentes e Cumprimento de Requisição processonas seções 4.2 e 4.3, respectivamente.6.2.3 estrutura organizacional Service DeskHá muitas maneiras de estruturar Mesas de Serviço e localizá-las - ea soluçãocorreta irá variar para diferentes organizações. As principais opções sãodetalhadas a seguir, mas, na realidade, uma organização pode precisarimplementar uma estrutura que combina um número dessas opções, a fim deatender plenamente as necessidades de negócios:6.2.3.1 Posto de Serviço LocalEste é o lugar onde uma mesa é co-localizados dentro ou fisicamente perto dousuário comunidade que serve. Essa comunicação muitas vezes ajudas e dáuma presença bem visível, o que alguns usuários gostam, mas muitas vezespode ser ineficiente e caro recurso como pessoal são amarrados à espera delidar com incidentes quando a taxa de volume e chegada de chamadas nãopode justificar isso.Pode, no entanto, haver algumas razões válidas para a manutenção de umbalcão de local, mesmo quando chamar volumes por si só não justificam.Razões podem incluir:• Língua e as diferenças culturais ou políticos• Diferentes fusos horários• Grupos especializados de usuários• A existência de serviços personalizados ou especializadas que exigemconhecimento especializado• VIP criticidade / estado de usuários.ITIL V3 - Operação de Serviço - Página: 212 de 423
  • 213. Figura 6.2 Service Desk local6.2.3.2 Service Desk centralizadoÉ possível reduzir o número de Service Desks, fundindo-os em um único local(ou em um número menor de locais), chamando a equipe em uma ou maisestruturas centralizadas Posto de Serviço. Isso pode ser mais eficiente e debaixo custo, permitindo menos pessoal global para lidar com um volume maiorde chamadas, e também pode levar a níveis mais altos através de familiarizaçãogrande através de ocorrência mais freqüente de eventos. Pode ainda sernecessário manter alguma forma de "presença local" para lidar com suportefísico exigências, mas esse pessoal pode ser controlada e implantado a partir dobalcão central.ITIL V3 - Operação de Serviço - Página: 213 de 423
  • 214. Figura 6.3 Service Desk centralizado6.2.3.3 Service Desk VirtualAtravés da utilização de tecnologia, em particular a Internet, bem como autilização de ferramentas de suporte corporativos, é possível dar a impressão deuma única central de serviços, centralizado, quando, de facto, o pessoal podeser espalhada ou localizado em qualquer número ou tipo de geográfica ou locaisestruturais. Isso traz a opção de trabalho em casa, secundário grupo de apoio,Off-shore, ou terceirização - Ou qualquer combinação necessária para atenderusuário demanda. É importante notar, contudo, que as salvaguardas sãonecessários em todas estas circunstâncias para assegurar a consistência euniformidade de serviço qualidade e termos culturais.ITIL V3 - Operação de Serviço - Página: 214 de 423
  • 215. Figura 6.4 Service Desk Virtual6.2.3.4 Siga o SolAlgumas organizações globais ou internacionais pode desejar combinar duas oumais de sua geograficamente dispersos Service Desks para fornecer 24 horasde acompanhamento do sol serviço. Por exemplo, um Service Desk na Ásia-Pacífico pode lidar com chamadas durante seu horário de expediente normal eno final deste período, pode entregar a responsabilidade por quaisquerincidentes abertas para uma mesa de base europeia. Essa mesa vai lidar comessas chamadas, juntamente com os seus próprios incidentes durante o seu dia-padrão e, em seguida, entregar a uma secretária EUA-baseado - que,finalmente, as mãos de volta a responsabilidade para a mesa da Ásia-Pacíficopara completar o ciclo.Isso pode dar cobertura de 24 horas na relativamente baixa custar, Comonenhuma mesa tem que trabalhar mais do que um único deslocar. No entanto,as mesmas garantias de processos comuns, ferramentas, banco de dadoscompartilhado de informações e cultura devem ser abordadas para estaabordagem para prosseguir - e bem controlados escalada e processos detransferência são necessários.ITIL V3 - Operação de Serviço - Página: 215 de 423
  • 216. 6.2.3.5 grupos Posto de serviço especializadoPara algumas organizações que poderia ser benéfico para criar "grupos deespecialistas" dentro da estrutura geral de Service Desk, para que incidentesrelacionados a um determinado De serviços de TI podem ser encaminhadasdiretamente (normalmente através da seleção de telefonia ou de uma interfaceweb-based) para o grupo de especialistas. Isso pode permitir que maisrapidamente resolução desses incidentes, através de uma maior familiaridade eformação especializada.A seleção será feita através de um script ao longo das linhas de Se o seuchamar é sobre o serviço X, por favor, pressione 1 agora, caso contrário, porfavor, segure para um analista de Service Desk ".É necessário cuidado para não complicar mais a seleção, então grupos deespecialistas deve ser considerada apenas para um número muito pequeno deserviços essenciais, caso existam, e onde chamam taxas sobre isso serviçojustificar um grupo especializado em separado.6.2.3.6 AmbienteO ambiente onde o Service Desk deve ser localizado deve ser cuidadosamenteescolhido. Sempre que possível, as seguintes instalações devem ser fornecidos:• Um local onde toda a função pode ser posicionado com luz naturalsuficiente e espaço total - para permitir mesa adequada e espaço dearmazenamento, e espaço para se movimentar, se necessárioAnedotaUma empresa descobriu que havia um nós e eles cultura existente entre oService Desk e as equipes de apoio. As equipes de terceira linha muitas vezesacredita-se ser melhor do que o Service Desk. Escondendo o Service Desk dedistância em uma sala isolada ajudou a reforçar essa cultura. A empresaconstatou que a criação de um escritório de plano aberto com o Service Desk nomeio de trabalho mais próxima incentivou e ajudou a quebrar essas barreiras• Um ambiente tranquilo, com acústica adequada controlar de modo queuma conversação telefónica não é perturbada por uma outra• Ambiente agradável e mobiliário confortável, de modo a aliviar o clima (oService Desk pode ser um lugar muito estressante para trabalhar, entãocada pequena ajuda!)• Uma área de sala de descanso e refresco separado nas proximidades,para que a equipe possa fazer pausas curtas como apropriado, quandonecessário, sem estar longe por muito tempo.ITIL V3 - Operação de Serviço - Página: 216 de 423
  • 217. 6.2.3.7 Nota sobre a construção de um único ponto de contatoIndependentemente de a combinação das opções escolhido para cumprir umaorganizaçãoEstrutura do Posto de Serviço geral individual, usuários deve estarem dúvida sobre quem contactar se eles precisam de ajuda. Um único númerode telefone (ou um número único para cada grupo se mesas separadas sãoescolhidas) devem ser fornecidos e bem divulgado -, bem como um endereço dee-mail único e uma página de contato Internet Service Desk.Idéias que podem ser usadas com sucesso para ajudar a divulgar o número detelefone de Serviço de Recepção e e-mail, e disponibilizá-lo à mão quando osusuários estão propensos a precisar deles, são:• Incluindo o número de telefone de Service Desk em rótulos de hardwareIC, anexa ao componentes o usuário é susceptível de ser chamadassobre• Impressão de Service Desk detalhes de contato nos telefones• Para PCs e laptops, usando um fundo personalizado ou área de trabalhocom o Serviço detalhes de contato Posto, juntamente com informações lera partir do sistema que será necessário ao chamar (como endereço IP,sistema operacional construir número, etc), num canto• Imprimir o número de Service Desk em brindes (canetas, lápis, canecas,mouse-esteiras, etc)• Proeminente colocar esses detalhes em Service Desk Internet / intranetlocais• Incluí-los em quaisquer cartões telefônicos ou cartões de pesquisa desatisfação com os usuários deixados quando uma visita mesa foinecessário• Repetindo os detalhes sobre toda a correspondência enviada aosusuários (juntamente com chamar números de referência)• Colocar os detalhes sobre a afixação ou locais físicos que os usuáriostendem a visitar regularmente (entradas, refeitórios, áreas dearrefecimento, etc.)6.2.4 pessoal Service DeskAs questões envolvidas na, e os critérios para estabelecer, o pessoal adequadomodelo e os níveis são discutidos nesta seção. Detalhes sobre Service Desktípico papels e responsabilidades podem ser encontradas no parágrafo 6.6.1abaixo. Eles incluem o Service Desk Manager, Supervisor, analistas e, emalgumas organizações, esses papéis são complementados por usuários denegócios (Super Users ), que fornecem suporte de primeira linha.6.2.4.1 Os níveis de pessoalITIL V3 - Operação de Serviço - Página: 217 de 423
  • 218. Uma organização deve assegurar que o número correto de funcionários estãodisponíveis a qualquer momento para atender a demanda que está sendocolocado sobre a mesa pela empresa. Taxas de chamadas podem ser muitovoláteis e muitas vezes no mesmo dia, a taxa de chegada pode ir de muito alta amuito baixa e de volta. Uma organização planejamento uma nova mesa devetentar prever a taxa de chegada de chamadas e perfil - e ao pessoal emconformidade. A análise estatística dos chamar taxas de chegada em regime desuporte atuais devem ser realizados e, em seguida, acompanhado de perto eajustada, se necessário.Muitas organizações vai descobrir que as taxas de chamadas de pico durante oinício do dia escritório e depois cair rapidamente, talvez com outra explosão noinício da tarde - isso, obviamente, varia de acordo com o organizaçãoNegócio s,mas é um padrão, muitas vezes ocorrendo para muitas organizações. Em taiscircunstâncias, pode ser possível utilizar parte-time, home-trabalhadores,segunda linha de apoio pessoal ou de terceiros para cobrir os picos.Os seguintes fatores devem ser considerados ao decidir os níveis de pessoal:• Cliente expectativas de serviço• Negócio exigências, tais como orçamento, Chamada tempo de respostas,etc• Tamanho, idade relativa projeto e complexidade do Infraestrutura de TI eCatálogo de Serviços - por exemplo, o número eo tipo de incidentes, aextensão do padrão personalizado contra software off-the-shelfimplantado, etc• O número de clientes e usuários para apoiar, e fatores associados, taiscomo:• Número de clientes e usuários falando uma língua diferente• Nível de habilidade• Incidente e Solicitação de Serviço tipos (e tipos de RFC, se for o caso):• Duração do tempo requerido para tipo de chamadas (por exemplo,consultas simples, especialista aplicação consultas, hardware, etc)• Experiência local ou externo necessário• O volume e os tipos de incidentes e solicitações de serviço• O período de cobertura apoio necessário, com base em:• Horas coberta• Fora-de-horas de apoio exigências• Fusos horários a serem cobertas• Locais a serem suportados (especialmente se Service Deskfuncionários também realizam mesa do lado de suporte)• O tempo de viagem entre os locais• Workload padrão de pedidos (por exemplo, diariamente, fim demês, etc)• O meta de nível de serviços em vigor (níveis de resposta, etc)• O tipo de resposta exigida:ITIL V3 - Operação de Serviço - Página: 218 de 423
  • 219. • Telefone• E-mail/fax/voice mail / vídeo• Presença física• Acesso on-line /controlar• O nível de formação exigido• As tecnologias de apoio disponíveis (por exemplo, telefone sistemas,ferramentas de suporte remoto, etc)• Os actuais níveis de competência do pessoal• Os processos e procedimentos em uso.Todos esses itens devem ser cuidadosamente considerados antes de tomarqualquer decisão sobre os níveis de pessoal. Isso também deve ser refletido nosníveis de documentação necessária. Lembre-se que o melhor a serviço, Mais onegócio vai usá-lo.Uma série de ferramentas estão disponíveis para ajudar a determinar o númeroadequado de funcionários para o Service Desk. Estes carga de trabalhomodelagem ferramentas são dependentes de "conhecimento local" detalhada doorganização tal como chamar volumes e padrões, serviços e perfil do usuários,etc6.2.4.2 Os níveis de especializaçãoUma organização deve decidir sobre o nível e variedade de habilidades queexige de sua equipe de Service Desk - e, em seguida, garantir que essashabilidades estão disponíveis nos momentos apropriados.Uma gama de opções de habilidade é possível, a partir de um call-logging "serviço apenas - onde a equipe só precisa de muito conhecimentos técnicosbásicos - direito até a um "técnico" Service Desk onde a equipe tecnicamentemais qualificada da organização são usados. No caso do primeiro, não haveráum manuseamento elevada, mas baixa resolução taxa, enquanto no último caso,esta será invertida.A decisão sobre o nível de competências necessárias, muitas vezes, serconduzido por vezes alvo de resolução (concordou com o negócio e capturadoem meta de nível de serviços), a complexidade dos sistemas de apoio e o que aempresa está disposta a pagar ".Há uma forte correlação entre a resposta e as metas de resolução e custars - deum modo geral, o menor dos tempos alvo, maior o custo, porque mais recursossão necessárias.Embora possa haver casos em negócios dependência criticidade ou fazer umamesa altamente qualificados tecnicamente um imperativo, a abordagem ideal emelhor custo-benefício é geralmente a primeira linha tem uma "chamada-ITIL V3 - Operação de Serviço - Página: 219 de 423
  • 220. logging" de apoio através do Service Desk, com rápido e eficaz escaladas paramais qualificados grupos de resolução de segunda linha e terceira linha, ondepessoal qualificado pode ser concentrada e mais eficazmente utilizados (verGerenciamento de Incidentes, Secção 4.2, para mais informações e orientaçõessobre estruturas de ponta a ponta-de apoio). No entanto, este ponto de partidabásico pode ser melhorada ao longo do tempo, proporcionando ao pessoal deprimeira linha com um eficaz da base de conhecimento, script de diagnósticos eferramentas de apoio integrados (incluindo um CMS), bem como a formaçãocontínua ea consciência, de modo que as taxas de resolução de primeira linhapode ser gradualmente aumentada.Isso também pode ser alcançado através da localização de segundo nívelpessoal no Service Desk, efetivamente criando uma estrutura de dois níveis. Istotem vantagens de fazer segundo nível pessoal disponível para ajudar a lidar comperíodos de pico de chamadas e para treinar o pessoal mais júnior, e, muitasvezes, aumentar a taxa de resolução na primeira chamada. No entanto, segundopessoal da linha, muitas vezes têm deveres fora do Service Desk - resultandoem listas que têm de ser geridos ou posições de segunda linha pessoal que estásendo duplicado. Além disso, ter que lidar com chamadas de rotina pode serdesmotivador para o pessoal mais experiente. Uma outra desvantagem potencialé que o Service Desk torna-se muito bom em resolver as chamadas, enquanto asegunda linha pessoal deve ser focada na remoção do causa raiz em vez disso.Outro fator a considerar quando se decidir sobre as habilidades exigências parao Serviço de Pessoal da recepção é o nível de personalização e especializaçãodos serviços suportados. Serviços padronizados requerem menos conhecimentoespecífico para fornecer qualidade cliente apoiar. Quanto mais especializado oserviço, o conhecimento especializado mais provável será exigida na primeirachamada.Note-se que em primeira linha resolução as taxas podem ser reduzidos poreficácia Gerenciamento de Problemas, O que vai reduzir a quantidade dos maissimples, incidentes repetitivos. Em tais casos, embora os índices de resoluçãoparecem estar a correr para baixo, o conjunto serviço qualidade terá melhoradoatravés da remoção completa dos muitos incidentes. Enquanto isso é bom, se aequipe de Service Desk são pagos incentivos ou bônus de resolução na primeirachamada, pode ser desastrosa para a moral e processo eficácia, A menos que obônus limiar é revered.Melhorias no tempo de resolução / taxas não deve ser deixado ao acaso, masdeverão ser parte de uma Melhoria de Serviço em curso Programa (Veja aMelhoria de Serviço Continuada publicação para maiores detalhes).Uma vez que o nível de conhecimentos necessários foram identificados, existeuma tarefa permanente de garantir que o Service Desk é operado de tal formaque o pessoal necessário obter e manter as habilidades necessárias - e que oITIL V3 - Operação de Serviço - Página: 220 de 423
  • 221. pessoal com o equilíbrio correto de habilidades estão de plantão em momentosapropriados para que a consistência é mantida.Isso envolverá uma formação contínua e programa de conscientização que deveabranger:• Habilidades interpessoais, tais como habilidades de telefonia, habilidadesde comunicação, escuta ativa e clienteDe cuidados de treinamento.• Consciência negócio: conhecimento específico do organizaçãoS áreas denegócio, motoristaA estrutura, prioridades, etc• A consciência de serviço de toda a chave da organização De serviços deTIs para a qual o suporte está a ser fornecido• Consciência técnica (e mais profunda formação técnica para o níveladequado, dependendo da taxa de resolução procurado)• Dependendo do nível de suporte fornecido, alguns diagnósticohabilidades (por exemplo, Kepner e Tregoe)• Ferramentas de apoio e técnicas• Treinamento de conscientização e tutoriais em novo sistemas etecnologias, antes da sua introdução• Processos e procedimentos (mais incidente particularmente Alterar eGerenciamento da Configuração - Mas uma visão geral de todos osprocessos de ITSM e procedimentos)• Digitando habilidades para garantir a entrada rápida e precisa deincidente ou solicite mais detalhes do serviço.Para tal programa seja eficaz habilidade, exigências e os níveis devem seravaliados periodicamente e treinamento registros mantidas.Formulação cuidadosa de rotações de pessoal ou horários deve ser mantidopara que um equilíbrio consistente de experiência pessoal e os níveis dehabilidade apropriadas estão presentes durante toda a crítica operacionalperíodos. Não é suficiente ter apenas o número certo de funcionários de plantão- a mistura correta de habilidades também deve estar disponível.6.2.4.3 FormaçãoÉ fundamental que toda a equipe de Service Desk são adequadamentetreinados antes de serem chamados para o pessoal do Service Desk. Umprograma de indução formal deve ser realizada por todos os novos funcionários,o conteúdo exato do que irá variar de acordo com os níveis de habilidade eexperiência existentes do novo recruta, mas é provável que incluem muitas dashabilidades necessárias, como descrito acima.Sempre que possível, a consciência de um negócio programa, Incluindo curtosperíodos de destacamento em áreas chave do negócio, deve ser fornecida parao pessoal novo que ainda não tem este nível de consciência negócio.ITIL V3 - Operação de Serviço - Página: 221 de 423
  • 222. Ao iniciar no Service Desk, Nova equipe deverá inicialmente equipe experientesombra - sentar com eles e ouvir em chamadas - antes de começar a tomarchama-se com um mentor ouvindo e capaz de intervir e fornecer suporte quandonecessário. O mentor deverá inicialmente rever cada chamar com o estagiário,após concluir a aprender quaisquer lições. A frequência dessas análises deveráser gradualmente reduzida, experiência e confiança cresce, mas o mentor aindadeve estar disponível para fornecer suporte contínuo, mesmo quando ocandidato tenha alcançado o estágio de carreira solo.Mentores podem precisar de ser treinados sobre como mentor. ExperiênciaService Desk e habilidades técnicas não são o único exigências para orientação.Eficazes de transferência de conhecimentos e habilidades a capacidade deensinar sem ser condescendente ou ameaçando são igualmente importantes.Aprograma será necessário para manter o conhecimento pessoal do Serviço deRecepção de até à data - e torná-los conscientes de novo desenvolvimentos,serviços e tecnologias. O momento de tal eventos é crítica de forma a nãoimpacto sobre as funções normais. Mesas Serviço Muitos acham que é melhorpara organizar curta "tutoriais" durante períodos tranquilos quando osfuncionários têm menos probabilidade de ser necessário para atendimento dechamadas.Nota: Investimento também deve ser feito no desenvolvimento profissional dopessoal de Service Desk. Interno de orientação e de sombreamento pessoal deapoio de segundo e terceiro nível é um bom começo, mas Mesas best-of-breedServiço beneficiar de um programa formal de desenvolvimento de pessoal.Comprometimento organizacional para o desenvolvimento profissional ajuda aincutir um senso de realização e oportunidade para o pessoal. Isso muitas vezesleva à inovação em Service Desk operação (Tais como serviços especializados),que por sua vez, na unidade operacional eficiências em todos os níveis dacamada de apoio. Ela ajuda a construir habilidades que podem ser utilizados nasua actual papel assim como ele saltar inicia o treinamento para um novo papel.Embora seja importante para desenvolver suas competências essenciais em suafunção atual, ter um plano de carreira claro e reconhecendo exigência futuro eas necessidades de desenvolvimento também é importante.6.2.4.4 retenção de pessoalÉ muito importante que todos os gestores de TI reconhecem a importância doService Desk e do pessoal que trabalha nele, e dar essa atenção especial.Qualquer perda significativa de pessoal pode ser perturbador e levar ainconsistência de serviço - Por isso os esforços devem ser feitos para que oService Desk um lugar atraente para o trabalho.Maneiras em que isto pode ser feito incluem o reconhecimento apropriado dopapel com pacotes de recompensa Reconhecendo isso, equipe de construçãoITIL V3 - Operação de Serviço - Página: 222 de 423
  • 223. de exercícios, rotação de pessoal para outras atividades (projetos, o suporte desegunda linha, etc.)O Service Desk muitas vezes pode ser usado como um trampolim para outrasfunções mais técnicas ou de supervisão / gerencial. Se isso for feito, o cuidado énecessário para garantir que a sucessão adequada planejamento ocorre paraque a mesa não perder todo o seu conhecimento fundamental em qualquer áreade uma vez. Além disso, boa documentação e cross-training pode reduzir esserisco.6.2.4.5 SuperusuáriosMuitas organizações achar que é útil para nomear ou designar um número deSuper Users "ao longo da usuário comunidade, para atuar como pontos deligação com TI em geral e do Service Desk, em particular.Superusuários pode ser dada alguma formação adicional e de sensibilização eusado como um canal de comunicações de fluxo em ambas as direcções. Elaspodem ser feitas para filtrar os pedidos e as questões levantadas pelacomunidade de usuários (em alguns casos, até mesmo indo tão longe a pontode ter incidentes ou solicitações levantadas pelo Super Usuário) - pode ajudar aprevenir incidente tempestades "quando um serviço chave ou componentefalha, que afeta muitos usuários.Eles também podem ser utilizados para informação de cascata para o exteriorao longo do seu Service Desk comunidade local de utilizadores, que podem sermuito úteis na divulgação detalhes do serviço para todos os utilizadores muitorapidamente.É importante notar que, Super Users deve registrar todas as chamadas quelidam com, e não apenas aqueles que eles passam para TI. Isto significa acessoe treinamento sobre como usar as ferramentas, registrando incidentes. Isso vaiajudar a medir a atividade do Super Usuário e também para assegurar que a suaposição não é abusado. Além disso, ele vai garantir que a história valiosas sobreincidentes e serviços qualidade não são perdidos.Também pode ser possível para Superusuários a ser envolvida em:• Formação de pessoal para usuários na sua área• Fornecendo suporte para incidentes menores ou simples pedidocumprimento• Envolvimento com o novo liberars e lançamentos.Superusuários não necessariamente fornecer suporte para toda a TI. Em muitoscasos, um Super Usuário só irá fornecer suporte para uma específicaaplicaçãoOu módulo unidade de negócios área. Como um usuário de negóciosITIL V3 - Operação de Serviço - Página: 223 de 423
  • 224. do Usuário Super muitas vezes tem um conhecimento profundo de como chaveprocesso de negócioes executar e como trabalhar em serviços prática. Este éum conhecimento muito útil para compartilhar com o Service Desk, De modo quepossa proporcionar maior qualidade de serviços no futuro.Note-se que um compromisso firme é necessário que potenciais usuários Supere, especificamente, a sua gestão, que terá o tempo e interesse para realizaresse papel antes da seleção e treinamento começa.A Super User, enquanto uma interface valiosa para o negócio e Service Desk,deve ser dada formação adequada, responsabilidade e expectativa.Superusuários podem ser vulneráveis ao mau uso, se o seu papel, asresponsabilidades e os processo regem estes não são claramente comunicadaaos usuários. É imperativo que um Super Usuário não é visto como umsubstituto, ou um meio de contornar, o Service Desk.6.2.5 Posto de métricas de serviçoMétricos deve ser estabelecida de modo que atuação do Service Desk pode seravaliada em intervalos regulares. Isto é importante para avaliar a saúde,maturidade,eficiência,eficácia e todas as oportunidades para melhorar asoperações do Service Desk.Métricas de desempenho Service Desk devem ser realistas e cuidadosamenteescolhido. É comum para selecionar essas métricas que são facilmentedisponíveis e que pode parecer ser uma possível indicação de desempenho, noentanto, isso pode ser enganador. Por exemplo, o número total de chamadasrecebidas pela Central de Serviços não é em si uma indicação de qualquer bomou mau desempenho e pode de fato ser causada por eventos completamentefora do controlar do Service Desk - por exemplo, um período particularmentemovimentado para o organização, Ou o liberar de um novo versão de uma dasgrandes empresas sistema.Um aumento no número de chamadas para a Central de Serviço pode indicarserviços menos confiáveis durante esse período de tempo - mas também podeindicar a confiança do usuário em um aumento de Service Desk que estáamadurecendo, resultando em uma maior probabilidade de que os usuários vãoprocurar assistência em vez de tentar para lidar sozinho. Para este tipo demétrica para ser confiável para alcançar ou conclusão de comparação, aindamais em períodos anteriores por quaisquer melhorias Service Deskimplementadas desde a última medição linha de baseOu serviço confiançaalterações, problemas, etc, para isolar a verdadeira causa para o aumento énecessário.Uma análise adicional e mais métricas detalhadas são, portanto, necessário, edeve ser examinada durante um período de tempo. Estas incluem as estatísticasITIL V3 - Operação de Serviço - Página: 224 de 423
  • 225. de processamento de chamadas anteriormente mencionados em telefonia, e,adicionalmente:• A primeira linha resolução taxa de: a percentagem de chamadasresolvidas em primeira linha, sem a necessidade de escalada a outragrupo de apoios. Esta é a figura freqüentemente citado por organizaçõescomo a principal medida do desempenho Mesas serviço - e utilizado parafins de comparação com o desempenho de outras mesas - mas é precisocuidado ao fazer qualquer comparação. Para maior precisão e maiscomparações válidas isto pode ser subdivididos como segue:• A percentagem de chamadas resolvidas no primeiro contato com oService Desk, Isto é, enquanto o usuário ainda está no telefonepara informar o chamar• A percentagem de chamadas resolvido pela equipe de ServiceDesk-se sem ter que procurar mais profundo apoio de outrosgrupos. Nota: algumas mesas vai escolher para co-localizar ouincorporar mais tecnicamente capacitada equipe de segunda linhacom o Service Desk (ver Gerenciamento de Incidentes para maisdetalhes). Em tais casos, é importante ao fazer comparações coma também separar (i) A percentagem resolvido pela equipe deService Desk sozinho, e (ii) A percentagem resolvido pela equipede primeira linha Posto de Serviço e segunda linha de apoio equipecombinados.• O tempo médio para resolver uma incidente (Quando resolvidas emprimeira linha)• O tempo médio para escalar um incidente (onde de primeira linharesolução não é possível)• Service Desk média custar de lidar com um incidente. Dois métricosdevem ser considerados aqui:• O custo total do Service Desk dividido pelo número de chamadas.Isto irá proporcionar um valor médio que é útil como um índice epara planejamento propósitos, mas não representar com precisãoos custos relativos dos diferentes tipos de chamadas• Ao calcular a percentagem de tempo de duração da chamada namesa geral e elaborar um custo por minuto (custos totais para operíodo, dividido pelo total de minutos de duração de chamada ")isto pode ser usado para calcular o custo das chamadas individuaise dar um valor mais exacto .Ao avaliar os tipos de incidentes com duração de chamada, uma imagemmais refinada de custo por chamada por tipos surge e dá indicação dequais tipos de incidentes tendem a custar mais para resolver e possíveisalvos para melhorias.• Percentual de cliente ou actualizações do utilizador conduzido dentro detempos-alvo, como definido na SLA alvosITIL V3 - Operação de Serviço - Página: 225 de 423
  • 226. • Tempo médio para rever e fechar uma chamada resolvido• O número de chamadas discriminadas por hora do dia e dia da semana,combinada com a média de tempo de chamada métrica, é fundamentalpara determinar o número de pessoal necessário.Outros detalhes gerais sobre métricas e como eles devem ser usados paraimpulsionar serviço qualidade está incluído no Melhoria de Serviço Continuadapublicação.6.2.5.1 cliente / usuário pesquisas de satisfaçãoBem como acompanhamento das medidas "duras" do Service Desk da atuação(Através dos indicadores descritos acima), também é importante avaliar softmedidas - tais como o quão bem os clientes e usuários sentem que suaschamadas foram atendidas, se eles se sentem o operador Service Desk foicortês e profissional, se reforçou a confiança no utilizador.Este tipo de medida é o melhor obtido a partir dos próprios usuários. Isso podeser feito como parte de um amplo cliente/usuário pesquisa de satisfação quecobre tudo ou pode ser especificamente orientadas para as questões ServiceDesk sozinho.Uma maneira eficaz de alcançar o último é através de um inquérito telefónico decall-back, onde uma organização independente Service Desk Operador ouSupervisor anéis de volta uma pequena porcentagem de usuários logo após seuincidente foi resolvido, para fazer as perguntas específicas necessárias.Cuidados devem ser tomados para manter o número de perguntas a um mínimo(5-6 no máximo) para que os usuários terão tempo para cooperar. Tambémperguntas da pesquisa deve ser projetado de forma que o usuário ou o clientesabe o que perguntas de área ou tema são cerca e que incidente ou serviço elesestão se referindo. O Service Desk deve atuar em baixos níveis de satisfação equalquer feedback recebido.Para permitir comparações adequadas, o mesmo percentual de chamadasdevem ser selecionados em cada período e devem ser rigorosamente realizadasapesar das pressões do tempo outros.As pesquisas são uma área complexa e especializada, exigindo um bomentendimento de estatísticas e técnicas de pesquisa. Esta publicação não podeITIL V3 - Operação de Serviço - Página: 226 de 423
  • 227. tentar fornecer uma visão geral de todas elas, mas um resumo de algumas dastécnicas mais amplamente utilizadas e ferramentas está listada na Tabela 6.1.Técnica / Ferramenta Vantagens DesvantagensDepois de call-pesquisaChamadores sãoconvidados a permanecerno telefone após a chamare então solicitados aclassificar o serviço foramfornecidos• Alta taxa de respostadesde o chamador é jáno telefone• Chamador sejaexaminadoimediatamente após achamada assim que suaexperiência é recente• As pessoas podemse sentirpressionados a tomara pesquisa,resultando em umaexperiência deserviço negativa• O inspector é vistocomo parte doService Desk emestudo, o que podedesencorajarrespostas abertasPesquisa telefônica desaídaOs clientes e usuários quejá usaram o Service Desksão contactados algumtempo após a suaexperiência com o ServiceDesk• Maior taxa de respostadesde o chamador éentrevistado diretamente• Categorias específicasde usuário ou clientepode ser alvo defeedback (por exemplo,pessoas que solicitaramum serviço específico, oupessoas experimentouuma quebra para umserviço particular)• Este método poderiaser visto comointrusivo, seinterrompe achamada doutilizador ou clientedo seu trabalho• A pesquisa érealizada algumtempo depois que ousuário ou clienteusou o Service Desk,pelo que a suapercepção pode termudadoEntrevistas pessoaisOs clientes e usuários sãoentrevistadospessoalmente pela pessoaque faz a pesquisa. Isto éespecialmente eficaz paraclientes ou usuários queusam o Service Deskextensivamente ou quetiveram uma experiênciamuito negativa• O entrevistador é capazde observar sinais não-verbais, bem como ouviro que o usuário ou ocliente está dizendo• Usuários e clientessentem um maior grau deatenção pessoal e umasensação de que suasrespostas estão sendolevados a sério ·• Entrevistas sãodemorados, tantopara o entrevistadoreo entrevistado• Usuários e clientespode transformar asentrevistas emsessões dereclamações ·Entrevistas de grupoOs clientes e usuários sãoentrevistados em pequenos• Um número maior deusuários e clientespodem ser entrevistado• As perguntas são mais• As pessoas nãopodem se expressarlivremente na frentede seus colegas ouITIL V3 - Operação de Serviço - Página: 227 de 423
  • 228. grupos. Isto é bom para arecolha de impressõesgerais e para determinar seexiste uma necessidade dealterar certos aspectos daService Desk, E.g. horas deserviço ou localizaçãogenéricos e, portanto,mais consistente entreentrevistas ·gerentes• As opiniões daspessoas pode serfacilmente alteradopor outros membrosdo grupo durante aentrevista ·Postais / e-mailpesquisasQuestionários são enviadospara um conjunto alvo declientes e usuários. Elessão convidados a retornarsuas respostas por e / mail• Clientes específicos outodos ou os usuáriospodem ser orientados• Pesquisas postais podemser anônimas, permitindoque as pessoas seexpressem maislivremente• E-mail pesquisas não sãoanônimas, mas podemser criados usandoformuláriosautomatizados quetornam conveniente efácil para o usuário aresponder e aumentar aprobabilidade de queserá completada ·• Pesquisas postaissão intensivos detrabalho paraprocesso• O percentual depessoas queresponderam ainquéritos postaistende a ser pequeno• Má interpretação deuma perguntapoderia afetar oresultado ·Pesquisas on-lineOs questionários sãopostados em um site eusuários e clientesincentivada através de e-mail ou links de um sitepopular para participar dapesquisa• O público potencialdessas pesquisas ébastante grande• Os entrevistados podempreencher o questionárioem seu próprio tempo• Os links em sitespopulares sãolembranças boas, semser intrusivoA percentagem de inquiridosnão pode ser previstaTabela 6.1 técnicas e ferramentas de pesquisa6.2.6 A terceirização do Service DeskA decisão de terceirizar é uma estratégico emitir para gerentes seniores - e éabordado em detalhes na Estratégia de Serviço e Design de Serviçospublicações. Muitos dos diretrizs nesta seção não são exclusivos do ServiceDesk e pode ser aplicado a qualquer função, A área de suporte ou serviço sendoterceirizado (ou fora-tarefa).Independentemente das razões, ou a extensão de, a terceirização contrato, Évital que o organização mantém a responsabilidade para as atividades eITIL V3 - Operação de Serviço - Página: 228 de 423
  • 229. serviços prestados pelo Service Desk. A organização é responsável pelaresultados da decisão e, portanto, deve determinar que tipo de serviço ocontratante fornece, e não o contrário.Se a rota é escolhida de terceirização, há algumas salvaguardas que sãonecessárias para assegurar que o Service Desk terceirizado funciona de formaeficaz e eficiente, com a organização de TI outras equipes e departamentos eesse fim-de-final Serviço de Gestão de controlar é mantida (isto éparticularmente importante para as organizações que procuram ISO / IEC 20000certificado como controle de gestão global tem de ser demonstrada). Algumasdessas garantias são definidas a seguir.6.2.6.1 As ferramentas comuns e processosO Service Desk não tem a responsabilidade de todos os processos eprocedimentos que inicia. Por exemplo, um Solicitação de Serviço é recebidopelo Service Desk, mas a solicitação é atendida pelo interno de TI Operacionalequipe.Se o Service Desk é terceirizado, os cuidados devem ser tomados para que asferramentas são consistentes com aqueles que ainda estão sendo usados naorganização do cliente. Terceirização é muitas vezes visto como umaoportunidade para substituir os instrumentos desatualizados ou inadequada,apenas para descobrir que há integração grave problemas entre a novaferramenta e as ferramentas herdadas e processos.Por esta razão, é importante para assegurar que estas questões sãodevidamente estudadas e do cliente exigências são devidamente delimitado eespecificado antes do contrato de terceirização. Ferramentas de Service Deskdeve não só apoiar a Central de serviços terceirizados, mas devem apoiar osprocessos da organização do cliente e requisitos de negócio também.Idealmente, a secretária terceirizada deve usar as mesmas ferramentas eprocessos (ou, no mínimo, as ferramentas de interface e processos) parapermitir suave processo fluxo entre o Service Desk e de segunda e terceira linhagrupo de apoios.Além disso, o Service Desk terceirizado deve ter acesso a:• Todos registro de incidentes e informações• Grave problemas e informações• Erro Conhecido Dados• Alterar agendamento• Fontes de conhecimento interno (especialmente técnico ou aplicaçãoespecialistas)• SKMSITIL V3 - Operação de Serviço - Página: 229 de 423
  • 230. • CMS• Alertars a partir de monitoramento ferramentas.Muitas vezes, é um desafio processos integradores e ferramentas em um menosmaduro organização com os de uma organização mais madura. Uma suposiçãocomum, mas incorreta é que o maturidade de uma organização, de algumaforma como consequência uma maior maturidade na outra. O envolvimento ativopara garantir o alinhamento de processos e ferramentas é essencial para umatransição suave e gerenciamento contínuo de serviços entre organizaçõesinternas e externas. Na verdade, se este não está directamente dirigida, issopode resultar na falha do contrato.É também muitas vezes erradamente do princípio de que a prova de Serviço deGestão de qualidade e vencimento em um parceiro terceirizar externo pode sergarantido por afirmar exigências, na aquisição processo para ITIL conformidadee / ouISO / IEC 20000 certificado. Estas declarações podem indicar que umpotencial fornecedor usa o modelo ITIL em sua entrega de serviços aos clientes,ou que eles têm alcançado padrãos certificação para sua interna práticas, mas éigualmente importante ter a tecnologia que permite no lugar e sendo utilizado umque demonstra provedor de serviçosS capacidade para gerenciar serviços einterface com as práticas internas harmoniosamente. Não existe um padrão deobservância que garante esforços de aquisição deste e por isso deve incluirconsultas específicas para satisfazer esta exigência. Mais informações sobre ofornecedor terceirizar aquisição pode ser encontrada na Design de Serviçospublicação.6.2.6.2 SLA alvosAs metas de SLA para geral incidente manipulação e resolução vezes precisamser acordado com o clientes, e entre todas as equipes e departamentos - e OLA/ UC metas precisam ser coordenadas e concordou com o indivíduo grupo deapoios para que apoiar e apoiar o SLA alvos.Exemplos destes podem ser vistos na secção métricos acima (ver secção 6.2.5).6.2.6.3 A boa comunicaçãoAs linhas de comunicação entre a Central de Serviço terceirizado e os outrosgrupos de apoio precisam trabalhar de forma muito eficaz. Isto pode ser ajudadopor alguns ou todos os seguintes passos:• Feche a partilha física• Ligação regular /rever reuniões• Cross-training tutoriais entre as equipes e departamentos• Parceria"Arranjos quando o pessoal de ambas as organizações sãousados em conjunto com o pessoal da mesaITIL V3 - Operação de Serviço - Página: 230 de 423
  • 231. • Planos de comunicação e atuação alvos são documentados de formaconsistente em Olas e UCs.Nos casos em que o Service Desk está localizado off-shore, Nem todas essasmedidas será possível. No entanto, a necessidade de formação e comunicaçãoda equipe de Service Desk ainda é crítica, ainda mais em casos em que existamdiferenças linguísticas e culturais.Isso será abordado mais detalhadamente em publicações ITIL complementares,mas, como regra, as empresas de outsourcing que oferecem soluções off-shorede Service Desk deve levar em conta o seguinte:• Treinamento programas focada na compreensão cultural do clientemercado• Habilidades de linguagem - especialmente a compreensão da utilizaçãoidiomática da língua no mercado do cliente. Isto não é assim que oserviço de som A equipe como os nativos do país do cliente (que tipo deinsinceridade é rapidamente detectado por clientes), mas para facilitar acompreensão do cliente e para melhor apreciar as suas prioridades• Visitas regulares de representantes do cliente organização para fornecertreinamento e feedback apropriado diretamente para a gestão de ServiceDesk e pessoal• Treinamento no uso de organizações dos clientes ferramentas e métodosde trabalho. Isto é especialmente eficaz se os materiais de formaçãosemelhantes são apresentados pelos instrutores idênticos aos utilizadospela organização do cliente.6.2.6.4 Propriedade dos dadosDomínio claro dos dados coletados pelo Service Desk terceirizado deve serestabelecida. Posse de todos os dados relativos aos usuários, clientes, CISafetada, serviços, incidentes Solicitação de Serviços, mudanças, etc devempermanecer com a organização que é terceirização o atividade -, Mas ambas asorganizações precisam de acesso a ele.Dados que estão relacionados especificamente para atuação de funcionários daempresa de terceirização continuará a ser propriedade daquela empresa, quemuitas vezes é legalmente impedido de compartilhar os dados com aorganização do cliente. Isso também pode ser verdade para outros dados quesão utilizados exclusivamente para a gestão interna do Service Desk, comocontagem de cabeça, otimização de atividades, Service Desk custarinformações, etcTodos os relatórios exigências e as questões em torno da propriedade dosdados deve ser especificado no subjacente contrato com a empresa que prestao serviço de outsourcing.ITIL V3 - Operação de Serviço - Página: 231 de 423
  • 232. 6.3 Gestão TécnicaGestão Técnica refere-se aos grupos, departamentos ou equipes que fornecemconhecimento técnico e de gestão global da Infraestrutura de TI.6.3.1 papel de Gestão TécnicaGestão Técnica desempenha um duplo papel:• Ele é o guardião do conhecimento técnico e experiência relacionada àgestão da infra-estrutura de TI. Neste papel, Gestão Técnica garante queo conhecimento necessário para projeto,teste, Gerir e melhorar Deserviços de TIs é identificado, desenvolvido e aperfeiçoado.• Ele oferece a real recursos para suportar o ITSM Ciclo de Vida. Nestepapel de Gestão Técnica garante que os recursos sejam efetivamentetreinados e distribuídos para projeto,construir, Transição, operar emelhorar a tecnologia necessária para dar suporte De serviços de TIs.Ao realizar estes dois papels, Gestão Técnica é capaz de assegurar que oorganização tem acesso ao tipo certo nível e de humano recursos paraadministrar de tecnologia e, portanto, para satisfazer negócios objetivos.Definindo o exigências para estes papéis começa na Estratégia de Serviço e éexpandido em Design de Serviços, Validado em Transição de Serviço e refinadoem Melhoria de Serviço Continuada (Ver outro ITIL publicações nesta série).Parte deste papel é também para assegurar um equilíbrio entre o nível dehabilidade de utilização, e a custar desses recursos. Por exemplo, a contrataçãode um recurso de nível superior no ponto mais alto da escala salarial e só entãousar essa habilidade para 10% do tempo não é eficaz. A melhor de GestãoTécnica estratégia seria identificar os momentos em que a habilidade énecessário e, em seguida, contratar um empreiteiro para apenas as tarefas.Outra estratégia em organizações maiores é a equipe de alavancagemespecialista de "central" de grupos para que especialistas possam ser bemutilizados e proporcionar uma economia de escala para a organização eminimizar a necessidade de contratar em empreiteiros. Habilidadesespecializadas devem ser identificados entre os recursos na organização de TI,então aproveitados para necessidades específicas que possam surgir, análogasa uma unidade especial tático, cujos membros também desempenhar funçõesregulares, mas que são designados para tarefas que necessitam de suashabilidades especiais. Este tipo de utilização de recursos é particularmente útiltanto para projeto equipes e problema resolução.Um papel adicional, mas muito importante desempenhado pela Gestão Técnicaé fornecer orientações para Operações de TI sobre a melhor forma de levar acabo o curso operacional gerenciamento da tecnologia. Este papel éITIL V3 - Operação de Serviço - Página: 232 de 423
  • 233. parcialmente realizado durante o Design de Serviços processo, Mas é tambémuma parte da comunicação diária com TI Gestão de Operações , que procuramalcançar a estabilidade e ótima atuação.Os objetivos, atividades e estruturas que permitem Gestão Técnica paraexecutar essas funções de forma eficaz são discutidas abaixo.6.3.2 Técnicas objectivos de gestãoOs objetivos da Gestão Técnica são para ajudar a planejar, implementar emanter uma infra-estrutura estável técnica para apoiar a organização doprocesso de negócioes por meio de:• Bem desenhado e altamente resistente, topologia de custo-benefíciotécnico• O uso de habilidades técnicas adequadas para manter a infra-estruturatécnica em óptimo estado• Swift uso de habilidades técnicas para diagnosticar e resolverrapidamente qualquer técnica falhas que ocorrem.6.3.3 genéricos técnicos actividades de gestãoGestão Técnica está envolvido em dois tipos de atividade:• Atividades que são genéricas para a Gestão Técnica função como umtodo são discutidos nesta seção como eles permitem Gestão Técnicacomo uma função para executar o seu papel.• Um conjunto de atividades distintas e processos que são executadas portodas as três funções de Aplicação, Técnico de TI e Gestão deOperações são abordados no Capítulo 5.As actividades de gestão genéricos técnicos se destacam as seguintes:• Identificar o conhecimento ea experiência necessários para gerenciar eoperar o Infraestrutura de TI e para fornecer De serviços de TIs. Esteprocesso começa durante a Estratégia de Serviço fase, é expandido emdetalhe em Design de Serviços e é realizado em Operação de Serviço.Contínuo avaliação e atualização dessas habilidades é feito duranteMelhoria de Serviço Continuada.• Documentação das habilidades que existem no organização, Bem comoas capacidades que precisam de ser desenvolvido. Isso incluirá adesenvolvimento Habilidades de Inventários e as atuação Análise dasNecessidades de Formação.• Iniciando treinamento programas para desenvolver e refinar ashabilidades da técnica adequada recursos e treinamento manter registrospara todos os recursos técnicos.ITIL V3 - Operação de Serviço - Página: 233 de 423
  • 234. • Concepção e execução de treinamento para usuários, o Service Desk eoutros grupos. Embora o treinamento exigências deve ser definido emDesign de Serviços, são executadas de Operação de Serviço. OndeGestão Técnica não entrega de formação, é responsável por identificar asorganizações que podem fornecer isso.• Recrutamento ou contratação de recursos com as competências que nãopodem ser desenvolvidas internamente, ou onde há pessoas suficientespara realizar as atividades exigidas gestão técnica.• Aquisição de habilidades para atividades específicas, onde as habilidadesnecessárias não estão disponíveis internamente ou no mercado aberto,ou onde ela é mais custo-eficiente para fazer isso.• Definição de padrãos utilizados no projeto de novo arquiteturas eparticipação na definição de arquiteturas de tecnologia durante aEstratégia de Serviço e as fases do projeto.• Pesquisa e desenvolvimento de soluções que podem ajudar a expandir aCarteira de serviço, ou que podem ser usados para simplificar ouautomatizar Operações de TI, Reduzir custars ou aumentar os níveis deserviço de TI.• Participação na concepção e construção de novos serviços. GestãoTécnica irá contribuir para a concepção das normas técnicas Arquitetura edesempenho para serviços de TI. Além disso, será também responsávelpor especificar o operacional atividades necessárias para gerenciar aInfraestrutura de TI em uma base contínua.• Envolvimento em projetos, não apenas durante o Design de Serviços eTransição de Serviço, mas também para Melhoria de Serviço Continuadaou projectos operacionais, tais como atualizações do sistema operacional,servidor projetos de consolidação ou movimentos físicos.• Disponibilidade e Gerenciamento da Capacidade são dependentes deGestão Técnica de Engenharia de serviços de TI para atender os níveisde serviço exigidas pela empresa. Isto significa que, modelagem e cargade trabalho previsão são muitas vezes feito com recursos gestão técnica.• Assistência na avaliação risco, Identificando o serviço e críticas sistemadependências e definição e implementação de contramedidas.• Concepção e realização de testes para a funcionalidade, desempenho ecapacidade de gerenciamento de serviços de TI.• Gestão de fornecedores. Muitos departamentos de Gestão Técnica ougrupos são os únicos que sabem exatamente o que é exigido de umfornecedor e como medir e gerenciá-los. Por esta razão, muitasorganizações dependem de Gestão Técnica departamentos para gerircontratos com fornecedores de itens de configuração específica. Se estefor o caso, é importante para assegurar que estes relaçãos sãogerenciados como parte do SLM processo.• Definição e gestão dos Gestão de Eventos padrãos e ferramentas.Gestão Técnica também vai monitorar e responder a muitas categorias deeventos.ITIL V3 - Operação de Serviço - Página: 234 de 423
  • 235. • Departamentos de gestão técnica ou grupos são essenciais para oatuação de Gerenciamento de Incidentes. Eles recebem através deincidentes Escalada funcional e fornecer suporte de segundo e de nívelsuperior. Eles também estão envolvidos na manutenção de categorias eque define o escalada procedimentos que são executados emGerenciamento de Incidentes.• Gestão Técnica em função fornece o recursos que executam oGerenciamento de Problemas processo. É a sua competência técnica econhecimento que é usado para diagnosticar e resolver problemas. Étambém sua relação com os vendedores que são usados para escalar eacompanhamento com as equipes de suporte do fornecedor.• Gestão de recursos técnicos estarão envolvidos na definição decodificação sistemas que são usados em Gestão de Incidentes eProblemas (Categorias por exemplo incidente).• Gestão de recursos técnicos são utilizados para apoiar a Gestão deProblemas na validação e manutenção da BDEC.• Gestão da Mudança depende do conhecimento técnico e experiênciapara avaliar as mudanças, e muitas mudanças será construído pelaDireção Técnica.• Soltes são freqüentemente implementados com recursos gestão técnica.• Gestão Técnica irá fornecer informações para, e operacionalmentemanter, o Sistema de gerenciamento de configuração e os seus dados.Isto será feito em cooperação com Aplicação de Gestão de para garantirque o CI correto atributos e os relacionamentos são criados a partir dadesenvolvimento de serviços e da manutenção contínua ao longo da vidade CIs.• Gestão Técnica está envolvido na Melhoria de Serviço Continuadaprocessos, especialmente na identificação de oportunidades de melhoriae, em seguida, para ajudar a avaliar as soluções alternativas.• Como um guardião do conhecimento técnico e experiência, GestãoTécnica garante que todo o sistema operacional e documentação estáatualizada e devidamente utilizado. Isto inclui assegurar que toda agestão, administração e usuário manuais estão em dia e concluir e que aequipe técnica está familiarizado com seu conteúdo.• Atualização e manutenção de dados utilizados para elaboração derelatórios sobre as capacidades técnicas e de serviço, por exemplo,Capacidade e Gestão de Desempenho, Gerenciamento deDisponibilidade, Gerenciamento de Problemas, etc• Auxiliar de TI Gestão Financeira para identificar o custar de TI e recursoshumanos utilizados para gerenciar De serviços de TIs.• Envolvimento na definição do operacional atividades realizadas comoparte de TI Gestão de Operações. Muitos departamentos de gestãotécnica, grupos ou equipes também executam as atividades operacionais,como parte de um organizaçãoS TI Gestão de Operações função.ITIL V3 - Operação de Serviço - Página: 235 de 423
  • 236. 6.3.4 organização Gestão TécnicaGestão Técnica normalmente não é fornecido por um único departamento ougrupo. Um ou mais Suporte técnico equipes ou departamentos serãonecessários para fornecer gerenciamento e apoio técnico para a Infraestruturade TI. Ao todo, mas as menores organizações, onde uma equipe única,combinada ou departamento pode ser suficiente, as equipes ou departamentosseparados serão necessários para cada tipo de infra-estrutura utilizada.TI Gestão de Operações consiste de um certo número de áreas tecnológicas.Cada uma delas requer um conjunto específico de habilidades para gerenciar eoperar lo. Alguns conjuntos de competências são relacionado e pode serrealizada por generalistas, enquanto outros são específicos de umcomponente,sistema ou plataforma.O principal critério de estrutura organizacional de Gestão Técnica é a deespecialização ou divisão do trabalho. O princípio é que as pessoas sãoagrupadas de acordo com suas habilidades técnicas, e que estes conjuntos dehabilidades são determinadas pela tecnologia que precisa ser gerenciado.Seções 6.6 e 6.7 abrangem os aspectos organizativos de Gestão Técnica emdetalhes, mas esta lista apresenta alguns exemplos típicos de equipas de gestãotécnicos ou departamentos:• Mainframe equipe ou departamento - se um ou mais tipos de mainframeainda estão sendo usados pelo organização• Servidor equipe ou departamento - muitas vezes dividir novamente portipos de tecnologia (por exemplo, Unix servidor, Wintel servidor)• Equipe de armazenamento ou departamento, responsável pela gestão detodos os dispositivos de armazenamento de dados e mídia• Equipe de suporte de rede ou departamento, cuidando de WANs internosda organização / LANs e gestão de qualquer rede externa fornecedors• Área de trabalho da equipe ou departamento, responsável por todos osequipamentos desktop instalado• Equipe de banco de dados ou departamento, responsável pela criação,manutenção e suporte de bases de dados da organização• Middleware equipe ou departamento, responsável pela integração, teste emanutenção de todas as middleware em uso na organização• Serviço de DiretórioA equipe ou departamento, responsável por manter oacesso e direitos de elementos de serviço na infra-estrutura• Internet ou Web equipe ou departamento, responsável pela gestão dodisponibilidade e segurança de acesso aos servidores e conteúdo porcliente externos, usuários e parceiros• Mensagens equipe ou departamento, responsável por serviços de correioelectrónico• Baseada em IP Telephony equipe ou departamento (por exemplo, VoIP).ITIL V3 - Operação de Serviço - Página: 236 de 423
  • 237. 6.3.5 Manutenção Design e Técnico de Apoio Técnico eGestão Técnica consiste de arquitetos especializados técnicos e designers (queestão principalmente envolvidos durante Design de Serviços) E pessoalespecializado de manutenção e suporte (que são principalmente envolvidosdurante Operação de Serviço).Nesta publicação, eles são vistos como sendo parte da mesma função, Masmuitas organizações vê-los como duas equipes distintas ou mesmodepartamentos. O problema com esta abordagem é que boa projeto precisa deentrada das pessoas que são necessários para gerenciar a solução - e bomoperação requer o envolvimento das pessoas que projetaram a solução.O problemas que precisam ser superados são semelhantes aos enfrentados nagestão da Aplicação Ciclo de Vida (Ver secção 6.5 para uma discussão maisdetalhada). A solução irá incluir os seguintes elementos:• Pessoal de apoio devem ser envolvidos durante o projeto ou arquiteturade uma solução. Equipe de projeto deve ser envolvido na criação demanutenção objetivos e resolver problemas de suporte.• A mudança na forma como o projeto ea equipe de suporte são medidos.Designers deve ser realizada, em parte, responsáveis por falhas deprojeto que criam operacional interrupções. Equipe de apoio deverá serrealizada, em parte, responsável pela contribuição para a arquiteturatécnica.6.3.6 Técnicas de Gestão de métricasMétricas para Gestão Técnica dependerá em grande parte da tecnologia queestá a ser gerido, mas alguns genéricos métricos incluem:• Medição de resultados acordados. Estas podem incluir:• Contribuição para a realização dos serviços para o negócio.Apesar de muitas das equipas de gestão técnicos não estarão emcontato direto com a empresa, a tecnologia que gerem impacto nonegócio. Métricas devem refletir tanto (incidentes traçadas para asua equipe) negativos e positivos (sistema atuação edisponibilidadeContribuições)• Transação taxas e disponibilidade para operações críticas denegócios• Service Desk treinamento• Gravação problema resoluçãos para o BDEC• Usuário medidas do qualidade de saídas, tal como definidos noSLA• Instalação e configuração de componentes sob seu controlar.ITIL V3 - Operação de Serviço - Página: 237 de 423
  • 238. • Métricas de processo. As equipas de gestão técnica executarGerenciamento de Serviços de muitos processo actividades. A suacapacidade de fazê-lo será medido como parte das métricas de processose for o caso (ver secção sobre cada processo para mais detalhes). Osexemplos incluem:• O tempo de resposta para eventos e as taxas de conclusão doevento• Incidente resolução vezes por segundo e terceira linha de apoio• Resolução de problemas estatísticas• Número de escaladas e razão para as escalações• Número de mudanças implementadas e saiu• Número de alterações não autorizadas detectado• Número de liberars implantado, com sucesso total e• Questões de segurança detectados e resolvidos• Real sistema utilização contra Plano de capacidade previsões(onde a equipe tem contribuído para a desenvolvimento do plano)• Rastreamento contra PIS• Despesas contra orçamento.• Tecnologia atuação. Estes métricos são baseados Design de Serviçosespecificaçãos e desempenho técnico padrãos definir por vendedores, eserão normalmente contido em OLAs ou Procedimentos OperacionaisPadrão. Métricas reais variam de acordo com a tecnologia, mas éprovável que incluem:• Taxas de utilização (por exemplo, memória ou processador paraservidor, Largura de banda para redes, etc)• Disponibilidade (De sistemas, de rede, dispositivos, etc), que é útilpara a medição da equipa ou o desempenho do sistema, mas nãodeve ser confundida com a disponibilidade de serviço - o querequer a capacidade para medir a disponibilidade geral do serviçoe pode usar os números de disponibilidade para um certo númerode sistemas individuais ou componentes• Performance (e.g. tempo de respostas, filas taxas, etc.)• Tempo médio entre falhas dos equipamentos especificados. Estamétrica é utilizado para assegurar que as decisões de compra boas eestão a ser feitos, quando comparado com os programas de manutenção,se o equipamento está a ser correctamente mantido• A medição da atividade de manutenção, Incluindo:• Manutenção realizada por horário• Número de janelas de manutenção ultrapassado• Manutenção objetivos alcançado (número e porcentagem).• Formação e competências desenvolvimento. Essas métricas garantirque a equipe tem as habilidades e treinamento para gerenciar atecnologia que está sob a sua controlar, E também identificar as áreas emque a formação ainda é necessária.ITIL V3 - Operação de Serviço - Página: 238 de 423
  • 239. 6.3.7 documentação Gestão TécnicaGestão Técnica está envolvido na elaboração e manutenção de váriasdocumentos como parte de outros processos (por exemplo, Planejamento deCapacidade,Gestão da Mudança,Gerenciamento de Problemas, Etc.) Estesdocumentos são discutidos com algum detalhe no relevante processodescrições.No entanto, existem alguns documentos que são específicos para os grupostécnicos de gestão ou as equipes que irão documentar gestão e controle dedocumentos relativos à tecnologia sob seu controle. Documentação GestãoTécnica inclui o seguinte.6.3.7.1 A documentação técnicaO fornecimento e manutenção de documentação técnica para todos os itens deconfiguração é de responsabilidade do gerenciamento técnico. Estes incluem:• Manuais Técnicos• Manuais de gestão e administração• Usuário manuais para CEI. Estes serão geralmente excluem aplicaçãomanuais do usuário, que são mantidos por Aplicação de Gestão de.6.3.7.2 programações de manutençãoEstes esquemas são elaborados e acordados durante a Design de Serviços faserelacionada com a disponibilidade e Gerenciamento da Capacidade, Mas sãoessencialmente as propriedades dos vários Gestão Técnica departamentos,grupos ou equipes. Isso é porque eles tem o conhecimento técnico paratecnologias específicas e são mais susceptíveis de saber o que é necessáriopara mantê-los em funcionamento.Para mais detalhes sobre a definição de programas de manutenção e Objetivode manutenção do serviços, referem-se a ITIL Design de Serviços publicação.6.3.7.3 Inventário de HabilidadesUm Inventário de Habilidades é um sistema ou ferramenta que identifica ascompetências necessárias para dar suporte De serviços de TIs e também osindivíduos que possuem essas habilidades. Estoques habilidades são maiseficazes se elas estão alinhadas com os processos, arquiteturas e atuaçãopadrãos.Além disso, estoques habilidades devem identificar o treinamento disponívelpara cultivar cada habilidade deve deixar o pessoal existente organização.ITIL V3 - Operação de Serviço - Página: 239 de 423
  • 240. Estoques habilidades também podem ser usados como parte do Portfólio deServiços para avaliar se um novo serviço pode ser entregue com o pessoalexistente e conjuntos de habilidades, ou se um investimento tem de ser feito emequipe nova ou treinamento. Estoques habilidades pode, portanto, contribuirsignificativamente para a Planejamento de Capacidade.A definição e manutenção de estoques Habilidades requer uma boa interfacecom processos de Recursos Humanos e ferramentas na organização.ITIL V3 - Operação de Serviço - Página: 240 de 423
  • 241. 6,4 TI Gestão de OperaçõesNos negócios, o termo Gestão de Operações"É usada para significar odepartamento, grupo ou equipe de pessoas responsáveis por executar aorganização do dia-a-dia operacional - actividades como correr da linha deprodução de uma fabricação ambiente ou a gestão dos centros de distribuição eos movimentos da frota dentro de uma organização logística.Gestão de Operações geralmente tem as seguintes características:• Há trabalho para assegurar que um dispositivo, sistema ou processo é, naverdade, correr ou de trabalho (em oposição a estratégia ouplanejamento)• Isto é onde planos são transformados em ações• O foco é sobre as actividades diárias ou a curto prazo, mas deve notar-seque estas actividades serão geralmente realizada e repetida ao longo deum período relativamente longo (em oposição a one-off projeto atividadesdo tipo)• Essas atividades são executadas por pessoal técnico especializado, quemuitas vezes têm de receber formação técnica para aprender a executarcada atividade• Há um foco na construção de ações consistentes repetíveis, que - serepetido com freqüência suficiente no nível certo de qualidade - Seassegurar o sucesso do operação• Isto é, onde o valor real da organização é entregue e medido• Existe uma dependência sobre o investimento em equipamentos ourecursos humanos ou de ambos• O valor gerado, deve exceder o custar do investimento e todos os outrosorganizacional despesas geraiss (tais como gestão e custos demarketing) se o negócio é de sucesso.De um modo semelhante, TI Gestão de Operações pode ser definida como afunção de responsável pela gestão e manutenção constantes de umaorganização de Infraestrutura de TI para garantir a entrega do nível acordado deDe serviços de TIs para o negócio.Operações de TI pode ser definido como o conjunto de actividades envolvidasno funcionamento do dia-a-dia da Infraestrutura de TI com o objetivo de entregarserviços de TI em níveis acordados para atender negócios declarado objetivos.6.4.1 Funções de Gerenciamento de Operações de TIO papel de Gestão de Operações é executar as actividades em curso eprocedimentos necessárias para gerenciar e manter a infra-estrutura de TI, demodo a entregar e suportar serviços de TI nos níveis acordados. Estes já foramdescritos na seção 5, mas são resumidas aqui para ser completo:ITIL V3 - Operação de Serviço - Página: 241 de 423
  • 242. • Operações de controle, Que supervisiona a execução e monitoramentodo operacional actividades e eventos na Infra-estrutura de TI. Isto podeser feito com o auxílio de um Operações Ponte ou Centro de Operaçõesde Rede. Além de executar as tarefas de rotina de todas as áreastécnicas, Controle de Operações também executa as seguintes tarefasespecíficas:• Console de Gerenciamento de, Que se refere à definição deobservação central e monitoramento capacidade e em seguida,usando os consoles para exercer o acompanhamento e controlaratividades• Job Scheduling, Ou a gestão de trabalhos em lote de rotina ouscripts• Faça backup e Restaurar em nome de todos os técnicos e equipesde gerenciamento de aplicativos e serviços e, muitas vezes, emnome da usuários• De impressão e de saída de gestão para a recolha e distribuiçãode toda a impressão centralizada ou saída eletrônica• Desempenho das atividades de manutenção em nome técnico ouAplicação de Gestão de equipes ou departamentos.• Gestão de Instalações, Que se refere à gestão da TI física ambiente,Normalmente um Centro de Dados ou salas de informática e recuperaçãolocais, juntamente com toda a potência e equipamentos de refrigeração.Facilities Management também inclui a coordenação de grande escala deconsolidação projetos, por exemplo, Consolidação de dados ou Centroservidor projetos de consolidação. Em alguns casos, a gestão de um datacenter é terceirizado, no qual Facilities Management caso refere-se àgestão do terceirização contrato.Tal como acontece com muitos IT Service Management processos e funções, TIGestão de Operações desempenha um duplo papel.• Gerenciamento de Operações é responsável pela execução dasatividades e atuação padrãos definido durante Design de Serviços etestado durante a Transição de Serviço. Neste sentido, o papel deoperações de TI "é, principalmente, manter o status quo. A estabilidadedo Infraestrutura de TI e consistência de De serviços de TIs é umapreocupação primordial de Operações de TI. Mesmo operacionalmelhorias visam encontrar formas mais simples e melhor de se fazer amesma coisa.• Ao mesmo tempo, as operações de TI é parte do processo de agregaçãode valor para os diferentes linhas de negócios e apoiar a rede de valor(Veja o ITIL Estratégia de Serviço publicação). A capacidade da empresapara cumprir o seu objetivos e para manter a competitividade depende dasaída e confiança do dia-a-dia operação de TI. Como tal, TI Gestão deOperações deve ser capaz de se adaptar continuamente a actividadeexigências e procura. O negócio não se importa que operações de TIITIL V3 - Operação de Serviço - Página: 242 de 423
  • 243. cumprido um padrão procedimento ou que um servidor realizada de formaotimizada. Como a demanda de negócios e mudança de requisitos,Gerenciamento de Operações deve ser capaz de manter o ritmo comeles, muitas vezes desafiando o status quo.Operações de TI deve alcançar um equilíbrio entre essas funções, o que exigiráo seguinte:• A compreensão de como a tecnologia é usada para fornecer serviços deTI• A compreensão da importância relativa e impacto desses serviços sobre onegócio• Procedimentos e manuais que delineiam o papel das operações de TI,tanto na gestão da tecnologia e da entrega de De serviços de TIs• Um conjunto claramente diferenciada de métricos de informar a empresasobre a realização dos objectivos de serviço, e de informar os gestores deTI na eficiência e eficácia de Operações de TI• Todos a equipe de TI Operações entender exatamente como o atuaçãoda tecnologia afeta serviços da entrega de TI• Acustar estratégia destinado a equilibrar as exigências de diferentesunidade de negócioss com a redução de custos através da otimizaçãodisponíveis da tecnologia existente ou o investimento em novastecnologias• Um valor, em vez de custo, retorno com base na estratégia deinvestimento.6.4.2 Operações de TI objectivos de gestãoOs objetivos do Gerenciamento de Operações incluem:• Manutenção do status quo para alcançar a estabilidade doorganizaçãoDia-a-dia s processos e atividades• Escrutínio regular e melhorias para alcançar um melhor serviço a custosreduzidos, mantendo a estabilidade• Rápido aplicação de habilidades operacionais para diagnosticar e resolverquaisquer operações de TI falhas que ocorrem.6.4.3 Operações de TI Gestão de organizaçãoFigura 6.1 na introdução do Capítulo 6 ilustra que a TI Gestão de Operações évisto como um função em seu próprio direito, mas que, em muitos casos equipe,do técnico e Aplicação de Gestão de grupos formam parte desta função.Isso significa que alguns departamentos de Gestão Técnica e Aplicação ougrupos vão gerenciar e executar os seus próprios operacional actividades.ITIL V3 - Operação de Serviço - Página: 243 de 423
  • 244. Outros vão delegar essas atividades a um dedicado Operações de TIdepartamento.Não existe um método único para a atribuição de actividade, uma vez quedepende da maturidade e estabilidade da infra-estrutura que está sendogerenciado. Por exemplo, Técnico e áreas de aplicação de gerenciamento quesão relativamente novo e instável tendem a gerenciar suas próprias operações.Grupos onde a tecnologia ou aplicação é estável, maduro e bem compreendidotendem a ter suas operações mais padronizadas e, portanto, se sentem maisconfortáveis delegar essas atividades.Algumas opções de como estruturar operações de TI são discutidos em detalhesna seção 6.7 desta publicação.6.4.4 Operações de TI métricas de gestãoTI Gestão de Operações é medida em termos da sua execução eficaz dasatividades especificadas e procedimentos, bem como a sua execução processoactividades. Exemplos destes são os seguintes:• A conclusão bem sucedida de trabalhos agendados• Número de exceções para as atividades programadas e empregos• Número de dados ou sistema restaurars exigido• Equipamentos estatísticas de instalação, incluindo o número de itensinstalados por tipo, instalações bem-sucedidas, etc• Processo métricos. Gestão de Operações de TI Service Managementexecuta muitos processo actividades. A sua capacidade de fazê-lo serámedido como parte das métricas de processo se for o caso (ver secçãosobre cada processo para mais detalhes). Os exemplos incluem:• O tempo de resposta para eventos• Incidente resolução vezes por incidentes• Número de segurançaIncidentes relacionados• Número de escaladas e razão para as escalações• Número de mudanças implementadas e saiu• Número de alterações não autorizadas detectado• Número de liberars implantado, com sucesso total e• Rastreamento contra PIS• Despesas contra orçamento.• Se as atividades de manutenção ter sido delegada, então métricasrelacionadas a essas atividades também será apropriado:• Manutenção realizada por horário• Número de janelas de manutenção ultrapassado• Manutenção objetivos alcançado (número e porcentagem).• Métricas relacionadas a Gestão de Instalações são extensas, masgeralmente incluem:ITIL V3 - Operação de Serviço - Página: 244 de 423
  • 245. • Custos versus orçamento relacionados com a construção,manutenção, segurança, Transporte, etc• Incidentes relacionados com a construção, por exemplo, reparosnecessários para a instalação de• Relatórios sobre acesso à facilidade• Número de segurança eventos e incidentes e suas resolução• Estatísticas de utilização de energia, além de aspectosrelacionados a mudanças no layout e estratégias decondicionamento ambiental• Eventos ou incidentes relacionados com o transporte e distribuição.6.4.5 Operações de TI Gestão de documentaçãoUm certo número de documentos são produzidos e utilizados durante TI Gestãode Operações. Esta lista é um resumo de alguns dos mais importantes e nãoinclui relatórios que são produzidos pela TI Gestão de Operações em nome deoutros processos ou funçãos.6.4.5.1 Procedimentos Operacionais PadrãoOs POPs são um conjunto de documentos que contêm instruções detalhadas eatividade horários para cada equipe de Gerenciamento de Operações de TI,departamento ou grupo.Esses documentos representam a rotina de trabalho que precisa ser feito paracada dispositivo, sistema ou procedimento. Eles também descrevem osprocedimentos a serem seguidos se uma exceção é detectada ou se um mudaré necessária.Documentos SOP também pode ser utilizado para definir níveis padrão deatuação para dispositivos ou procedimentos. Em alguns organismos osdocumentos SOP são referidos no OLA. Em vez de listar medidas dedesempenho detalhadas no OLA, uma cláusula é inserida para se referir aodesempenho padrãos no POP e como estes serão medidos e relatados.6.4.5.2 Operações LogsQualquer atividade que é realizada como parte de Operações de TI devem serregistados para uma série de razões, incluindo:• Elas podem ser usadas para confirmar a conclusão bem sucedida detrabalhos ou actividades específicas• Elas podem ser usadas para confirmar que um De serviços de TI foientregue conforme acordado• Eles podem ser utilizados por Gerenciamento de Problemas parapesquisar o causa raiz de incidentesITIL V3 - Operação de Serviço - Página: 245 de 423
  • 246. • Eles são a base para relatórios sobre o desempenho das equipes de TIde Gestão de Operações e departamentos.O formato destes registros é tão variada quanto o número de sistemas e Gestãode Operações equipes ou departamentos. Exemplos de Logs operações incluemo seguinte:• Sistema operacional registra armazenados em cada dispositivo• Aplicação registros de atividades armazenados em um arquivo noaplicação servidor• Evento Troncos armazenados no monitoramento servidor ferramenta• Logs de utilização de dispositivos-chave• Gravação de logs de acesso físico que acessou edifícios mais seguros equando• Registros manuscritos das ações realizadas pelos operadores. Este deveser em um diário de bordo formal ou fichário, numeradas e armazenadasde forma segura ambiente. Os cheques devem assegurar que as páginasnão são removidos.Apolítica precisa ser estabelecido como parte dos POPs, para afirmar como oslogs de longas precisam ser mantidos, como são arquivados e quando elespodem ser excluídos. Essas políticas levarão em conta estatutária e observânciaexigências. Políticas também devem especificar os parâmetros para oarmazenamento adequado e apoio estratégias para armazenar e recuperararquivos de log.6.4.5.3 Shift Schedules e RelatóriosHorários de turnos são documentos que delineiam as atividades exatas queprecisam ser realizadas durante o deslocar. Eles também irá listar todas asdependências e atividade seqüências. Haverá provavelmente mais do que umprograma de mudanças, onde cada equipe terá um versão por sua própriasistemas. É importante que todos os horários são coordenados, antes do inícioda passagem. Isso geralmente é feito por uma pessoa que é especializada emturno programação, com a ajuda de ferramentas de programação.A Programação deslocamento pode consistir de um número de itens de rotinaque estão incluídos no POP. Neste caso, os artigos podem simplesmente serlistados sucintamente com uma referência para a secção ou da página na SOP.Horários mais turnos assumir a forma de uma lista onde os operadores podemmarcar o item como ela for concluída, juntamente com o tempo de conclusão.Isto torna mais fácil para ver o andamento das atividades e também ajuda aidentificar possíveis problemas onde os trabalhos estão demorando muito.ITIL V3 - Operação de Serviço - Página: 246 de 423
  • 247. Relatórios de turnos são uma forma de registrar as operações, mas têm oadicional funçãos como se segue:• Para gravar grande eventos e ações que ocorreram durante o turno• Para fazer parte da transferência de soberania entre os líderes demudança• Para denunciar qualquer exceção à Objetivo de manutenção do serviços• Para identificar qualquer incompleto atividade que podem resultar emdegradação atuação em qualquer serviço durante a próxima horas deserviço.6.4.5.4 Horário de OperaçõesAs listas de Operações são semelhantes a mudar programações mas cobremtodos os aspectos da Operações de TI a um nível elevado. Essa programaçãovai incluir uma visão geral de todas as alterações planejadas, manutenção,trabalhos de rotina e trabalho adicional, juntamente com informações sobre onegócio ou eventos de fornecedores. O Cronograma de Operações é usadocomo base para a Reunião de operações diárias e é a referência principal paratodos os gerentes de operações de TI para acompanhar o progresso e detectarexceções.6,5 Gerenciamento de AplicativosAplicação de Gestão de é responsável pela gestão aplicaçãos ao longo da suaciclo de vida. A função de gerenciamento de aplicativos é realizada por qualquerdepartamento, grupo ou equipe envolvida na gestão e suporte operacionalaplicações. Gerenciamento de Aplicativos também desempenha um importantepapel no projeto, Teste e aperfeiçoamento de aplicações que fazem parte do Deserviços de TIs. Como tal, ele pode estar envolvido em desenvolvimentoprojetos, mas normalmente não é o mesmo que as equipas de desenvolvimentode aplicações.6.5.1 papel Gerenciamento de AplicativosGerenciamento de Aplicativos é a aplicações que Gestão Técnica é oInfraestrutura de TI. Aplicação de Gestão desempenha um papel em todas asaplicações, se comprados ou desenvolvidos in-house. Uma das principaisdecisões que contribuam para a decisão de se comprar um aplicativo ouconstruir -o (isto é discutido em detalhe no Design de Serviços publicação). Umavez que a decisão é tomada, Gerenciamento de Aplicativos irá desempenhar umduplo papel:• Ele é o guardião do conhecimento técnico e experiência relacionada comaplicações de gestão. Neste Aplicação de Gestão de papel, trabalhandoem conjunto com a Gestão Técnica, garante que o conhecimentoITIL V3 - Operação de Serviço - Página: 247 de 423
  • 248. necessário para projetar, teste, Gerir e melhorar os serviços de TI éidentificado, desenvolvido e aperfeiçoado.• Ele oferece a real recursos para suportar o ITSM Ciclo de Vida. Nestepapel, Gerenciamento de Aplicativos garante que os recursos sejamefetivamente treinados e distribuídos para projetar, construir, Transição,operar e melhorar a tecnologia necessária para entregar e suportar osserviços de TI.Ao realizar essas duas funções, gerenciamento de aplicativos é capaz degarantir que o organização tem acesso ao tipo certo e nível de recursoshumanos para gerenciar aplicações e, portanto, para atender empresasobjetivos. Esta começa em Estratégia de Serviço e é expandido em Design deServiço, testado em Transição de Serviço e refinado em Melhoria de ServiçoContinuada (Ver outro ITIL publicações nesta série).Parte desse papel é garantir um equilíbrio entre o nível de habilidade e do custardesses recursos.Para além destes dois papéis de alto nível, Application Management tambémexecuta as seguintes funções específicas:• Fornecer orientação para Operações de TI sobre a melhor forma deproceder à gestão em curso operacional de aplicações. Este papel éparcialmente realizado durante o Design de Serviços processo, Mas étambém uma parte da comunicação diária com TI Gestão de Operações ,que procuram alcançar a estabilidade e ótima atuação.• A integração do Ciclo de Vida do Gerenciamento de Aplicativos para oCiclo de Vida de ITSM. Isto é discutido abaixo.Os objetivos, atividades e estruturas que permitem Gerenciamento deAplicativos para jogar esses papéis efetivamente são discutidas abaixo.6.5.2 Aplicação objectivos de gestãoOs objetivos do gerenciamento de aplicativos são apoiar a organização doprocesso de negócioes, ajudando a identificar funcional e capacidade degerenciamento exigências para o software de aplicação e, em seguida, paraauxiliar na concepção e desenvolvimento dessas aplicações e suporte contínuoe melhoria dessas aplicações.Estes objectivos são alcançados através de:• Os aplicativos que são bem desenhados, resistente e de baixo custo• Garantir que a funcionalidade está disponível para realizar o negócioexigido resultadoITIL V3 - Operação de Serviço - Página: 248 de 423
  • 249. • O organização de competências técnicas adequadas para manteroperacional aplicaçãos em condição ideal• Swift uso de habilidades técnicas para diagnosticar e resolverrapidamente qualquer técnica falhas que ocorrem.6.5.3 Gestão de princípios de aplicação6.5.3.1 Construir ou comprar?Uma das principais decisões em Aplicação de Gestão de é se comprar umaaplicação que suporta a funcionalidade necessária, ou se a construir a aplicaçãoespecífica para a organização do exigências. Estas decisões são muitas vezesfeitas por um Diretor Técnico (CTO) ou Comitê Gestor, mas são dependentes dainformação a partir de um número de fontes. Estes são discutidos em detalhe naDesign de Serviços, Mas estão aqui resumidas a partir de uma Aplicação deGestão função perspectiva.Gerenciamento de Aplicativos irá ajudar nesta decisão durante Design deServiços como se segue:• Aplicação dimensionamento e carga de trabalho previsões (ver secção4.6.4)• Especificação de gerenciamento exigências• Identificação de curso custo operacionals• Dados os requisitos de acesso para o relatório ou a integração de outrasaplicações• Investigar até que ponto a funcionalidade necessária pode ser atendidapelas ferramentas existentes - e quanto personalização será necessáriopara alcançar este• Estimar o custo de personalização• Identificar quais habilidades serão necessárias para apoiar a solução (porexemplo, se um aplicativo é comprado, vai exigir um novo conjunto deempregados, ou empregados existentes podem ser treinados para apoiá-lo?)• Requisitos de administração• Requisitos de segurança.Se a decisão é construir a aplicação, uma decisão ainda precisa ser feita se odesenvolvimento será terceirizada ou construído usando funcionários. Isto édetalhado no Estratégia de Serviço e Serviço de publicações de design, mas háalgumas considerações importantes que afetam a operação de serviço, porexemplo:• Como os requisitos de gerenciamento ser especificadas e acordadas (porexemplo, aplicação de concepção e transação monitoramento)? EstasITIL V3 - Operação de Serviço - Página: 249 de 423
  • 250. são algumas vezes esquecida quando operacional equipes oudepartamentos não estão representados no projeto• Quais são os Aceitação Critérios para operacional atuação, Como e ondevai ser a solução testada e que irá realizar os testes?• Quem será o proprietário e gerir a Biblioteca definitivo para essaaplicação?• Quem vai projeto e manter o operacional gestão e administração scriptspara estas aplicações?• Quem é responsável pelo ambiente de set-up e possuir e manter a infra-estrutura diferente componentes?• Como vai ser a solução instrumentada de forma que ele é capaz de geraro requerido eventos?6.5.3.2 Modelos OperacionaisUm Operacional Modelo é o especificação do operacional ambiente em que oaplicação acabará por correr quando ele vai viver. Isto irá ser utilizado durante afase de ensaio e de transição para simular e avaliar o viver ambiente. Esta éuma forma de garantir que o aplicativo pode ser dimensionados corretamente eas condições ambientais necessárias podem ser documentados ecompreendidos por todos. A Operacional Modelo devem ser definidas eutilizadas em testes, durante o Design de Serviços e Transição de Serviço fases,respectivamente (ver Design de Serviços e publicações Transição de Serviço).6.5.4 Aplicação de Gestão do Ciclo de VidaO ciclo de vida seguido para desenvolver e gerenciar aplicações tem sidoreferido por muitos nomes, incluindo o software Ciclo de Vida (SLC) e SoftwareDevelopment Lifecycle (SDLC). Estes são geralmente utilizados pelas equipesde desenvolvimento de aplicações e sua Projeto Gestores para definir o seuenvolvimento na concepção, construção, testes, implantação e suporte deaplicações. Exemplos dessas abordagens são Análise de Sistemas Estruturadoe Metodologia Design (SSADM), Dynamic Método de Desenvolvimento deSistemas (DSDM), Rapid Application Development (RAD), etcITIL está interessado principalmente na gestão global de aplicativos como partede De serviços de TIs, sejam eles desenvolvidos internamente ou comprado deum terceiro. Por esta razão, o termo Aplicação de Gestão de Ciclo de vida temsido utilizada, uma vez que implica uma visão mais holística.Isso não deve substituir o SDLC, que ainda é uma abordagem válida usado pordesenvolvedores, especialmente por empresas de software de terceiros. Noentanto, isso não significa que deve haver um maior alinhamento entre odesenvolvimento ver de aplicaçãos e da gestão "ao vivo" dessas aplicações.ITIL V3 - Operação de Serviço - Página: 250 de 423
  • 251. Isso é mais difícil em grandes aplicativos adquiridos, tais como e-mail, já que osdesenvolvedores não costumam interagir individualmente com seu aplicativousuários. No entanto, o ciclo de vida básico ainda é válido na medida em que aaplicação precisa exigências, projeto, Customização, operação edesenvolvimento. A otimização é obtida através de uma melhor gestão,melhorias para a personalização e upgrades.O Ciclo de Vida do Gerenciamento de Aplicativos é ilustrado da seguinte forma:Figura 6.5 Aplicação de Gestão do Ciclo de VidaProcessos de ITSM e processos de desenvolvimento de aplicações têm de seralinhadas como parte do total estratégia de entrega de serviços de TI em apoioao negócio.Aplicações Desenvolvimento e Operações fazem parte do ciclo de vida domesmo conjunto e ambas devem ser envolvidas em todas as fases, embora oseu nível de envolvimento pode variar, dependendo da fase do ciclo de vida.ITIL V3 - Operação de Serviço - Página: 251 de 423
  • 252. Relação entre o gerenciamento de aplicativos e Serviço de Gestão de Ciclode VidasO Aplicação de Gestão de Ciclo de Vida não deve ser visto como umaalternativa para o Lifecycle Management Service. As aplicações são parte dosserviços e têm de ser gerenciados como tal. No entanto, aplicaçãos são umamistura única de tecnologia e funcionalidade e isso requer um foco especializadoem cada fase do ciclo de vida de Gerenciamento de Serviços.Cada etapa do ciclo de vida de gerenciamento de aplicativos tem seu próprioconjunto específico de objetivos, atividades entregas e equipes dedicadas. Cadaestágio tem também uma responsabilidade clara para garantir que suas saídasigualar-se aos objetivos específicos do Lifecycle Management Service.Diferentes aspectos do gerenciamento de aplicativos são abordados emdetalhes em cada uma das publicações da ITIL, como segue:• Estratégia de Serviço: Define o total arquitetura de aplicações e infra-estrutura. Isso irá incluir a definição dos critérios para o desenvolvimentoin-house, terceirização desenvolvimento, Ou a compra e personalizaçãode aplicativos. Estratégia de Serviço também vai ajudar a definir oPortfólio de Serviços (Incluindo as aplicações), que também incluiinformações sobre o retorno do investimento de aplicações e os serviçosque eles suportam. Assim, de alto nível exigências são definidos duranteesta fase.• Design de Serviços: Ajuda a estabelecer requisitos para a funcionalidadee capacidade de gerenciamento de aplicações e trabalha com equipes dedesenvolvimento para que possam cumprir com esses objetivos. Designde Serviços cobre a maior parte da fase de Requisitos e está envolvidodurante a Construir fase do Ciclo de Vida do Gerenciamento deAplicativos.• Transição de Serviço: Equipes de desenvolvimento de aplicativos eGestão estão envolvidos em testar e validar o que foi construído eimplantá-lo operacionalmente.• Operação de Serviço:Este abrange a fase Operate do LifecycleManagement Application. Esses processos e estruturas são discutidas empormenor nesta publicação.• Melhoria de Serviço Continuada: Cobre o Otimizar fase do Ciclo de Vidado Gerenciamento de Aplicativos. Melhoria de Serviço Continuada medea qualidade e relevância de aplicações em operação e fornecerecomendações sobre como melhorar as aplicações se há um retornoclaro sobre o investimento para o fazer.6.5.4.1 RequisitosEsta é a fase durante a qual o exigências para uma nova aplicação estãoreunidos, com base nas necessidades comerciais do organização. Esta fase éITIL V3 - Operação de Serviço - Página: 252 de 423
  • 253. ativa principalmente durante a fase de Design de Serviços do Ciclo de Vida deITSM.Existem seis tipos de requisitos para qualquer aplicação, seja sendodesenvolvido in-house, terceirizado ou adquirido:• Os requisitos funcionais são aqueles especificamente necessária parasuportar um negócio particular função• Gerenciabilidade exigências, olhou de um Serviço de Gestão deperspectiva, abordar a necessidade de um serviço ágil, seguro edisponível, e lidar com questões como a desenvolvimento, Operaçõessistema de gestão e segurança• Usabilidade requisitos são aqueles que abordar as necessidades daextremidade usuário, E em consequência as características do sistemaque facilitam a sua facilidade de uso• Requisitos arquitetônicos, especialmente se este exige uma mudar aexistente arquitetura padrãos• Requisitos de interface, onde existem dependências entre existentesaplicaçãos ou ferramentas e da nova aplicação• Exigência de Nível de Serviços, que especificam como o serviço deverealizar, a qualidade de sua produção e outros aspectos qualitativosmedidos pelo usuário ou cliente.6.5.4.2 DesenhoEsta é a fase durante a qual são traduzidos em requisitos especificaçãos.Projeto inclui a projeto da aplicação em si, eo design do ambiente, ouoperacional modelo que a aplicação tem que correr. Considerações dearquitectura é o aspecto mais importante desta fase, uma vez que eles podemimpacto sobre a estrutura eo conteúdo de ambos aplicação e modelooperacional. Considerações de arquitetura para a aplicação (projeto daarquitetura do aplicativo) e considerações arquitetônicas para o operaçãomodelo (projeto da arquitetura do sistema) estão fortemente relacionados eprecisam ser alinhados.No caso de aquisição de software, a maioria das organizações não serápermitida a entrada direta para o design do software (o qual já tenha sidoconstruído). No entanto, é importante que o Gerenciamento de aplicativo écapaz de fornecer feedback para o fornecedor de software sobre afuncionalidade de gerenciamento e atuação do software. Isto irá, por sua vez,ser assumida pelo fornecedor do software, como parte de um aperfeiçoamentodo software.Parte da avaliação processo para o software adquirido deve incluir umaavaliação de se o vendedor é sensível a tais comentários. Ao mesmo tempo,devem assegurar que existe um equilíbrio entre ser sensível e mudando o seuITIL V3 - Operação de Serviço - Página: 253 de 423
  • 254. software de tal forma que é perturbador ou que muda algumas funcionalidadesbásicas.Design para software adquirido também irá incluir o projeto de qualquerpersonalização que é necessário. De especial importância aqui é avaliar se ofuturo versão do software irá apoiar a personalização.6.5.4.3 ConstruçãoNo Construir fase, tanto a aplicação e do modelo operacional estão prontas paraimplantação. Aplicação componentes são codificados ou adquirida, integrado etestado.Por favor note que Teste não é uma fase separada no ciclo de vida, Ainda queseja um discreto atividade, E mesmo que os testes são realizados de formaindependente de ambos os desenvolvimento e atividades operacionais. Sem acriar e implantar as fases, não haveria nada de testar e, sem testes, não haveriacontrole sobre o que é desenvolvido e implantado.O teste é um componente integral de ambos os criar e implantar as fases, comoum validação do atividade e saída das referidas fases - mesmo que utilizadiferentes ambientes e pessoal. Teste em fase de desenvolvimento concentra-seem saber se o pedido preenche sua funcionalidade e especificações degerenciamento. Muitas vezes, a distinção entre uma e desenvolvimentoambiente de teste. O ambiente de teste permite testar a combinação daaplicação e do modelo operacional. O teste é coberto na publicação Transiçãode Serviço ITIL.Para o software comprado, isso vai envolver a compra real da aplicação,qualquer exigido middleware eo relacionado ao hardware e equipamentos derede. Qualquer personalização que é necessária terá de ser feita aqui, como severá a criação de tabelas, categorias, etc, que irá ser utilizado. Isto é feito muitasvezes como um piloto implementação pelo relevante Aplicação de Gestão deequipe ou departamento.6.5.4.4 ImplantarNesta fase, tanto a operacional modelo e a aplicação são implantados. Omodelo operativo é incorporado no ambiente de TI existente e a aplicação éinstalada na parte superior do modelo de operação, utilizando o Gerenciamentode Liberação e Implantação processo descrito na ITIL Transição de Serviçopublicação.Teste também acontece durante esta fase, embora aqui a ênfase está emgarantir que o processo de implantação e os mecanismos de trabalhar de formaeficaz, por exemplo, testar se o aplicativo ainda funçãos para especificaçãoITIL V3 - Operação de Serviço - Página: 254 de 423
  • 255. depois de ter sido baixado e instalado. Isto é conhecido como Life Support cedoe cobre um período de garantia pré-definido que a validação, testes emonitoramento de uma nova aplicação ou serviço durante esse período, ocorre.Suporte início da vida é abordada em detalhes na publicação Transição deServiço.6.5.4.5 OperarNa fase de operar, o De serviços de TIsorganização opera o aplicativo comoparte da prestação de um serviço exigido pela empresa. O atuação de aplicaçãoem relação ao serviço total é medido continuamente contra o Nível de Serviços ede negócios-chave motoristas. É importante distinguir que os aplicativos em sinão equivale a um serviço. É comum em muitas organizações, para se referir aaplicações como serviços, no entanto, as aplicações são apenas umcomponente muitos dos necessários para fornecer uma serviço de negócio.A fase Operate não é exclusiva de aplicações e é discutido ao longo destapublicação, com uma lista mais detalhada das atividades mencionadas na seção6.5.5 abaixo.6.5.4.6 OtimizarNo Otimizar fase, os resultados do nível de serviço atuação medições sãomedidos, analisados e tratados. Possíveis melhorias são discutidas edesenvolvimentos iniciado, se necessário. As duas estratégias principais nestafase são para manter e / ou melhorar a Nível de Serviços e para baixar custar.Isso poderia levar a iteração no ciclo de vida ou à aposentadoria justificada deum aplicativo.Uma coisa importante a lembrar sobre o Aplicação de Gestão de Ciclo de Vida éque, uma vez que é circular, a mesma aplicação pode residir em diferentes fasesdo ciclo de vida, ao mesmo tempo. Por exemplo, quando o próximo versão deum aplicativo está sendo projetado, ea versão atual está sendo implantado, aversão anterior ainda pode ser em operação em partes de uma organização.Isto, obviamente, requer a versão forte, configuração e liberar controlar.Determinadas fases pode demorar mais ou parecem mais significativos do queoutros, mas todos eles são cruciais. Cada aplicação tem de passar por todoseles, pelo menos, uma vez e, por causa da natureza circular do ciclo de vida, vaipassar por um pouco mais do que uma vez.Esta abordagem também suporta iterativo abordagens de desenvolvimento,onde o software está sendo continuamente desenvolvidas em passosincrementais. Cada passo segue o ciclo de vida e que o aplicativo é construídoem incrementos, com as prioridades de negócios como motorista.ITIL V3 - Operação de Serviço - Página: 255 de 423
  • 256. Uma boa comunicação é a chave como um aplicativo funciona seu caminhoatravés das fases do ciclo de vida. É crítico que a altaqualidade informação érepassada por aqueles lidar com a aplicação em uma fase da sua existênciapara aqueles que manipulam-lo na próxima fase. Também é importante que aorganização monitora a qualidade do Lifecycle Management Application.Alterações no ciclo de vida, por exemplo, na forma de uma organizaçãotransfere as informações entre as diferentes fases, irá afectar a sua qualidade.Compreender as características de cada fase do ciclo de vida de gerenciamentode aplicativos é crucial para a melhoria da qualidade da totalidade. Métodos eferramentas utilizadas em uma fase pode ter um impacto em outros, enquanto aoptimização de uma fase pode sub-otimizar o todo.6.5.5 Aplicação de Gestão de actividades de carácter genéricoEnquanto a maioria Aplicação de Gestão de equipes ou departamentos sãodedicados a específica aplicaçãos ou conjuntos de aplicativos, há uma série deactividades que têm em comum. Estes incluem:• Identificar o conhecimento ea experiência necessários para gerenciar eoperar aplicações na entrega de De serviços de TIs. Este processocomeça durante a Estratégia de Serviço fase, é expandido em detalhe emDesign de Serviços e é realizado em Operação de Serviço. Contínuoavaliação e atualização destas competências são feitas durante Melhoriade Serviço Continuada.• Iniciando treinamento programas para desenvolver e refinar ashabilidades no gerenciamento de aplicativos apropriado recursos etreinamento manter registros para estes recursos.• O recrutamento ou contratação recursos com habilidades que não podemser desenvolvidas internamente, ou onde há pessoas suficientes pararealizar as atividades de gestão necessárias Aplicação.• Concepção e execução de fim-usuário treinamento. O treinamento podeser desenvolvido e entregue tanto pelo desenvolvimento de aplicativos ougrupos de gerenciamento de aplicativos, ou por um terceiro, MasAplicação de Gestão de é responsável por assegurar que o treinamento érealizado conforme o caso.• Insourcing para atividades específicas, onde as habilidades necessáriasnão estão disponíveis internamente ou no mercado aberto, ou onde ela émais custo-eficiente para fazer isso.• Definição de padrãos utilizados no projeto de novas arquiteturas eparticipação na definição de aplicação arquiteturas durante os processosde estratégia de serviço.• Pesquisa e Desenvolvimento de soluções que podem ajudar a expandir oportfólio de serviços, ou que pode ser usado para simplificar ouautomatizar Operações de TI, Reduzir custars ou aumentar os níveis deserviço de TI.ITIL V3 - Operação de Serviço - Página: 256 de 423
  • 257. • Participação na concepção e construção de novos serviços. Todas asequipes ou departamentos Application Management irá contribuir para aconcepção das normas técnicas Arquitetura e desempenho para serviçosde TI. Além disso, eles também será responsável por especificar aoperacional atividades necessárias para gerenciar as aplicações em umabase contínua.• Envolvimento em projetos, não só durante o projeto do Serviço deprocesso, Mas também para Melhoria de Serviço Continuada ou projetosoperacionais, tais como atualizações do sistema operacional, servidorprojetos de consolidação ou movimentos físicos.• Concepção e realização de testes para a funcionalidade, atuação egerenciamento de serviços de TI (tendo em conta que o teste deve sercontrolada e realizada por um laboratório independente - veja Transiçãode Serviço publicação).• Disponibilidade e Gerenciamento da Capacidade são dependentes deGerenciamento de Aplicativos para contribuir para a concepção deaplicações para atender os níveis de serviço exigidas pela empresa. Istosignifica que, modelagem e carga de trabalho previsão são muitas vezesfeito em conjunto com técnicas e de gestão de aplicativos.• Assistência na avaliação risco, Identificando o serviço e críticas sistemadependências e definição e implementação de contramedidas.• Gestão de fornecedores. Muitos Aplicação de Gestão de departamentosou grupos são os únicos que sabem exatamente o que é exigido de umfornecedor e como medir e gerenciá-los. Por esta razão, muitasorganizações dependem de Gerenciamento de Aplicativos para gerenciarcontratos com fornecedores de específico aplicaçãos. Se este for o caso,é importante para assegurar que estes relaçãos são gerenciados comoparte do SLM processo.• Envolvimento na definição de Gestão de Eventos padrãos e,especialmente, na instrumentação de aplicações para a geração designificativa eventos.• Gerenciamento de Aplicativos como um função fornece o recursos queexecutam o Gerenciamento de Problemas processo. É a sua competênciatécnica e conhecimento que é usado para diagnosticar e resolverproblemas. É também a sua relação com os vendedores que são usadospara escalar e acompanhamento com as equipes de apoio defornecedores ou departamentos.• Recursos de gerenciamento de aplicativos estarão envolvidos nadefinição de sistemas de codificação que são usados em Gestão deIncidentes e Problemas (Categorias por exemplo incidente).• Recursos de gerenciamento de aplicativos são utilizados para apoiarGerenciamento de Problemas na validação e manutenção da BDECconjunto com as equipes de desenvolvimento de aplicativos.• Gestão da Mudança depende do conhecimento técnico e experiênciapara avaliar as mudanças e muitas mudanças serão construídos porequipes de gerenciamento de aplicativos.ITIL V3 - Operação de Serviço - Página: 257 de 423
  • 258. • Bem sucedido Gerenciamento de Liberação depende de envolvimento daequipe de gerenciamento de aplicativos. Na verdade, eles sãofreqüentemente a motoristas da Gerenciamento de Liberação processopara suas aplicações.• Aplicação de Gestão vai definir, gerir e manter atributos e osrelacionamentos de IC aplicação no CMS.• Aplicação de Gestão está envolvido na Melhoria de Serviço Continuadaprocessos, especialmente na identificação de oportunidades de melhoriae, em seguida, para ajudar a avaliar as soluções alternativas.• Aplicação de Gestão assegura que todo o sistema operacional edocumentação está atualizada e devidamente utilizado. Isto incluiassegurar que todos os projeto, Gestão e usuário manuais estão em dia econcluir e que a equipe de gerenciamento de aplicativos e usuários estãofamiliarizados com seu conteúdo.• Colaboração com Gestão Técnica sobre a realização de Análise denecessidades de formação e manutenção de estoques de Habilidades.• Auxiliar de TI Gestão Financeira para identificar o custar dogerenciamento contínuo de aplicações.• Envolvimento na definição do operacional atividades realizadas comoparte de TI Gestão de Operações. Muitos departamentos de aplicativosde gestão, grupos ou equipes também executam as atividadesoperacionais, como parte de um organizaçãoS TI Gestão de Operaçõesfunção.• Introduzidos e manutenção de, software configuração políticas.• Juntamente com as equipes de desenvolvimento de software, a definiçãoe manutenção de documentação relacionada com as aplicações. Estesincluirão usuário manuais de administração e gestão de manuais, bemcomo quaisquer POPs necessários para gerenciar operacional aspectosda aplicação.Aplicação de Gestão de equipes ou departamentos serão necessários paratodas as aplicações-chave. A natureza exata do papel irá variar, dependendodas aplicações sendo suportados, mas as responsabilidades genéricas sãosusceptíveis de incluir:• Terceiro nível de suporte de incidentes relacionados com a aplicação (s)coberto por essa equipe ou departamento• Envolvimento em operação teste planos e desenvolvimento questões• Rastreamento de bugs e aplicação de gerenciamento de patches(correções para codificação em casa código, transportes / patches paracódigo de terceiros)• Envolvimento na operacionalidade aplicação e problemas de suporte, taiscomo erro projeto do código, erro de mensagens, gestão de eventosganchosITIL V3 - Operação de Serviço - Página: 258 de 423
  • 259. • Aplicação dimensionamento e atuação, Volume métricos e etc testes decarga Este é em apoio de Capacidade e Gerenciamento deDisponibilidade processos• Envolvimento no desenvolvimento Solte Políticas• Identificação de melhorias para o software existente, tanto a partir de umaperspectiva de funcionalidade e capacidade de gerenciamento.6.5.6 Aplicação de Gestão de organizaçãoApesar de todos os departamentos Application Management, grupos ou equipesde atividades similares, cada aplicação ou conjunto de aplicações tem umconjunto diferente de gestão e operacionais exigências. Os exemplos de taisdiferenças incluem:• A finalidade da aplicação. Cada aplicativo foi desenvolvido para atenderum conjunto específico de objetivos, normalmente objetivo de negócios.Para apoio efetivo e melhoria, o grupo que gerencia esse aplicativoprecisa ter uma compreensão abrangente do contexto dos negócios ecomo o aplicativo é utilizado para atender seus objetivos. Isso é muitasvezes conseguida por analistas de negócios que estão perto de o negócioe responsável por garantir que o negócio exigências se traduzirem emaplicação especificaçãos. Analistas de Negócios deveriam reconhecerque o negócio exigências deve ser traduzida em funcional e capacidadede gerenciamento especificaçãos.• A funcionalidade da aplicação. Cada aplicativo foi projetado paratrabalhar de uma forma diferente e para executar diferentes funçãos emmomentos diferentes.• A plataforma em que o aplicativo é executado. Apesar de a plataformaser geralmente administrado por uma Gestão Técnica equipe oudepartamento, cada um deles afeta a maneira em que um aplicativoprecisa ser administrada e explorada.• O tipo ou marca de tecnologia utilizada. Mesmo aplicações que têmfuncionalidade semelhante operar de forma diferente em diferentesbancos de dados ou plataformas. Estas diferenças têm que serentendidas no sentido de gerir a aplicação eficaz.Mesmo que as atividades para gerenciar esses aplicativos são genéricas, ocronograma específico de atividades ea forma como eles são realizados serádiferente. Por esta razão, as equipes de Application Management edepartamentos tendem a ser organizado de acordo com as categorias deaplicaçãos que suportam. Exemplos típicos de organizações de gestão deaplicações incluem:• Aplicações financeiras. Em organizações maiores onde um número deaplicações diferentes são usados para diferentes aspectos da GestãoFinanceira, Pode haver vários departamentos, grupos ou equipas deITIL V3 - Operação de Serviço - Página: 259 de 423
  • 260. gestão dessas aplicações, por exemplo, Devedores e Credores e análiseda idade, General Ledger, etc• Aplicativos de mensagens e colaboração• Aplicações de RH• Fabricação aplicações de suporte• Automação da força de vendas• Vendas de processamento de aplicações de ordem• Call center e aplicações de marketing• Empresas aplicativos específicos (por exemplo, cuidados de saúde,seguros, banca, etc)• Aplicações de TI, tais como Service Desk, Enterprise Sistema de Gestãode, Etc• Portais web• Compras on-line.ITIL V3 - Operação de Serviço - Página: 260 de 423
  • 261. 6.5.6.1 papéis organizacionaisTradicionalmente, as equipes de desenvolvimento de aplicativos e Gestão edepartamentos foram unidades autônomas. Cada um gere a sua própriaambiente à sua maneira e cada um tem uma interface separada para o negócio.Isto está ilustrado na Tabela 6.2.Desenvolvimento de Aplicações Aplicação de Gestão deFocoprincipalFuncionalidade de construção para a suacliente. O que o aplicativo faz é maisimportante para eles do que como ele éoperadoConcentre-se no que a funcionalidadeé bem como a forma de entregá-lo.Aspectos de gerenciamento daaplicação, ou seja, como garantir aestabilidade e atuação da aplicaçãoModo degestãoA maioria desenvolvimento o trabalho éfeito em projetos, onde o foco está emfornecer unidades específicas de trabalhopara especificação, No prazo e dentroorçamento.Isto significa que muitas vezes é difícil paraos desenvolvedores a entender e construirpara as operações em curso,especialmente porque eles não estãodisponíveis para apoio do pedido, uma vezque se mudaram para o próximo projetoMaioria do trabalho é feito como partede repetíveis e processos emandamento. Um número relativamentepequeno de pessoas trabalham emprojetos.Isto significa que é muito difícil paraoperacional pessoal para se envolverem projetos de desenvolvimento,como que os leva longe de seus"empregos reais"Medição Funcionários são recompensados para acriatividade e para concluir um projeto paraque eles possam passar para a próximaprojetoFuncionários são recompensados decoerência e de prevenção inesperadoeventos e funcionalidade nãoautorizada ("sinos e assobios", porexemplo adicionado pordesenvolvedores)Custar Projetos de desenvolvimento sãorelativamente fáceis de quantificar uma vezque o recursos são conhecidos e é fácil devincular suas despesas para umdeterminado aplicação ou De serviços deTIGerenciamento contínuo custars sãomuitas vezes misturados com oscustos de outros serviços de TI desderecursos são muitas vezescompartilhados entre vários serviçosde TI e aplicaçõesCiclo deVidasFoco de desenvolvimento pessoal emciclos de vida de desenvolvimento desoftware, que destacam as dependênciaspara sucesso operação, Mas não atribuir aresponsabilidade por estesPessoal envolvido na gestão em cursonormalmente só controlar uma ouduas fases destes ciclo de vidas -Operação e MelhoriaTabela 6.2 papéis organizacionaisAo longo dos últimos anos, estes dois mundos estão sendo reunidos pormovimentos recentes para Object Oriented abordagens e SOA, juntamente coma pressão crescente do negócio a ser mais ágil e fácil de trabalhar.ITIL V3 - Operação de Serviço - Página: 261 de 423
  • 262. Isto significa que o desenvolvimento de aplicativos terá uma maiorresponsabilidade para o bom funcionamento de aplicativos que projeto,Enquanto Aplicação de Gestão de terá um maior envolvimento nadesenvolvimento de aplicações.Isto não muda a fundamental papel de cada grupo, mas requer uma abordagemmais integrada do SLC. Isso também significa que a saída de Desenvolvimentode Aplicativos será mais comoditizado e que Gerenciamento de Aplicativos serámais envolvidos em projetos de desenvolvimento.Isso exigirá as seguintes alterações:• Uma única interface para o negócio para todas as fases do ciclo de vida euma comum exigências e especificação-Definição processo.• A mudança na forma como ambos Desenvolvimento e Gestão de pessoalsão medidos. As equipes de desenvolvimento deve ser realizada, emparte, responsáveis por falhas de projeto que criam operacionalinterrupções. Equipe de gestão deve ser realizada, em parte, responsávelpela contribuição para o técnico arquitetura eo projeto de gerenciamentode aplicações.• Uma única Gestão da Mudança processo para ambos os grupos, comcontrole de mudanças em cada grupo sendo subordinado à autoridadegeral de Gestão de Mudança (veja Transição de Serviço publicação).• Um mapeamento claro de Desenvolvimento e Gestão de atividades dociclo de vida, que é ilustrado em um alto nível na Figura 6.5. As atividadesexatas e como eles interagem deve ser definido em cada organização,Embora alguns genérico diretrizs são dadas em cada um dos ITILpublicações.• Maior foco na integração de funcionalidade e capacidade degerenciamento exigências no início do projeto.ITIL V3 - Operação de Serviço - Página: 262 de 423
  • 263. Figura 6.6 Papel das equipes na aplicação de gestão do ciclo de vidaA Figura 6.6 mostra uma comum Aplicação de Gestão de Ciclo de Vida com aparticipação de ambos os grupos. Neste diagrama, é evidente que AplicaçãoDesenvolvimento estará dirigindo algumas fases com a entrada deGerenciamento de Aplicativos. Em outros casos, Gerenciamento de Aplicativosserá a condução da fase com a entrada e apoio de desenvolvimento deaplicativos. Ambos os grupos são subordinados ao TI Estratégia de Serviço doorganização e seus esforços são coordenados através Transição de Serviçomecanismos e processos.6.5.7 Aplicação funções de gerenciamento e responsabilidades6.5.7.1 Aplicações Gerentes / ou chefes de equipaUm Applications Manager ou líder de equipe (dependendo do tamanho e / ouimportância da equipe ou departamento e da aplicação que suportam, eITIL V3 - Operação de Serviço - Página: 263 de 423
  • 264. estrutura da organização e cultura) Serão necessários para cada uma dasequipas aplicações ou departamentos. O papel irá:• Assumir a responsabilidade total para a liderança, controlar e tomada dedecisão para a equipe de aplicações ou departamento• Fornecer conhecimento técnico e liderança nas atividades específicas deaplicações de apoio abrangidos pela equipe ou departamento• Garantir níveis técnicos necessários sensibilização, formação eexperiência são mantidos dentro da equipe ou departamento relevantepara os aplicativos que estão sendo apoiados e processos que estãosendo usados• Envolvem a comunicação permanente com usuários e clientes em relaçãoà aplicação atuação e em evolução exigências do negócio• Relatar à alta administração sobre todas as questões relevantes para osaplicativos que estão sendo apoiados• Executar linha de gestão para toda a equipe ou membros dodepartamento.6.5.7.2 Aplicações Analista / ArquitetoAnalistas aplicativos e arquitetos são responsáveis por correspondênciarequisitos para aplicação especificaçãos. Atividades específicas incluem:• Trabalhando com usuários, patrocinadores e todos os outros das partesinteressadass para determinar suas necessidades em evolução• Trabalhando com Gestão Técnica para determinar o nível máximo desistema requisitos necessários para cumprir os requisitos de negóciosdentro orçamento e limitações tecnológicas• Execução de análises custo-benefício para determinar os meios maisadequados para atender a exigência declarada• Em desenvolvimento Operacional Modelos que vai garantir uma utilizaçãoóptima dos recursos e o nível apropriado de desempenho• Garantindo que os aplicativos são projetados para ser gerido de formaeficaz dada a tecnologia da organização arquitetura, Habilidades eferramentas disponíveis• Desenvolvimento e manutenção de padrãos para aplicaçãodimensionamento,atuação modelagem, Etc• Gerando um conjunto de aceitação teste exigências, em conjunto com osdesigners, engenheiros de teste e os usuário, Que determinam que todosos requisitos de alto nível foram cumpridos relativamente à funcional ecapacidade de gerenciamento• Entrada para o projeto de configuração dados necessários para gerenciare rastrear o aplicação eficazmente.ITIL V3 - Operação de Serviço - Página: 264 de 423
  • 265. Um número apropriado de analistas de aplicação serão necessários para cadauma das equipes Application Management ou departamento para realizar asatividades genéricas descritas no parágrafo 6.5.5.As formas em que Aplicação de Gestão de grupos podem ser organizados, e asopções disponíveis, são discutidos em detalhe na seção 6.7 abaixo.6.5.8 Gestão de métricas de aplicaçãoMétricos para Gerenciamento de Aplicativos dependerá em grande parte osaplicativos que estão sendo gerenciados, mas algumas métricas genéricasincluem:• Medição de resultados acordados. Estas podem incluir:• Capacidade dos usuários de acessar o aplicativo e suafuncionalidade• Relatórios e arquivos são transmitidos para os usuários• Transação taxas e disponibilidade para operações críticas denegócios• Service Desk treinamento• Gravação problema resoluçãos para o BDEC• Medidas de usuário do qualidade de saídas, tal como definidos noSLA.• Métricas de processo. Gestão Técnica equipes de executar Serviço deGerenciamento de muitos processo actividades. A sua capacidade defazê-lo será medida como parte do processo métricas se for o caso (versecção sobre cada processo para mais detalhes). Os exemplos incluem:• O tempo de resposta para eventos e as taxas de conclusão doevento• Incidente resolução vezes por segundo e terceira linha de apoio• Resolução de problemas estatísticas• Número de escaladas e razão para as escalações• Número de mudanças implementadas e saiu• Número de alterações não autorizadas detectado• Número de liberars implantado, total e bem sucedida, incluindo agarantia de adesão às Políticas lançamento do organização• Questões de segurança detectados e resolvidos• Real sistema utilização contra Plano de capacidade previsões(onde a equipe tem contribuído para a desenvolvimento do plano)• Rastreamento contra PIS• Despesas contra orçamento.• Aplicação atuação. Estes métricos são baseados Design de Serviçosespecificaçãos e desempenho técnico padrãos definir por fornecedores enormalmente será contida OLAs ou SOPs. Métricas reais variam deacordo com a aplicação, mas é provável que incluem:• O tempo de respostasITIL V3 - Operação de Serviço - Página: 265 de 423
  • 266. • Aplicação disponibilidade, Que é útil para medir a equipe ouaplicação desempenho, mas não deve ser confundido comdisponibilidade de serviço - o que requer a capacidade para medira disponibilidade geral do serviço, e pode utilizar os dados dedisponibilidade para um número de indivíduos sistemas oucomponentes• Integridade de dados e relatórios.• Medição de manutenção atividade, Incluindo:• Manutenção realizada por horário• Número de janelas de manutenção ultrapassado• Manutenção objetivos alcançado (número e porcentagem).• Aplicação de Gestão de equipes são propensos a trabalhar em estreitacolaboração com as equipes de desenvolvimento de aplicativos emprojetos, E as métricas apropriadas devem ser usados para medir esta,incluindo:• Tempo gasto em projetos• Cliente e usuário satisfação com a saída do projecto• Custo de participação no projeto.• Treinamento e desenvolvimento de competências. Essas métricasgarantir que a equipe tem as habilidades e treinamento para gerenciar atecnologia que está sob a sua controlar, E também identificar as áreas emque a formação ainda é necessária.6.5.9 documentação Gerenciamento de AplicativosUm certo número de documentos são produzidos e utilizados duranteGerenciamento de Aplicativos. Esta lista é um resumo de alguns dos maisimportantes e não inclui relatórios ou documentos que são produzidos porGerenciamento de Aplicativos em nome de outro processo ou funçãos (porexemplo, RFC, Erro Conhecido documentação, Registro de Lançamentos, etc.)Note que os documentos devem ser controladas como IC e relacionado com asaplicações relevantes ou equipes de gerenciamento de aplicativos.6.5.9.1 Application PortfolioO Application Portfolio é usado primariamente como parte de Estratégia deServiço, Mas é referenciado aqui para ser completo. O portfólio de aplicativos éuma lista (mais precisamente um sistema ou banco de dados) de todos osaplicativos em uso dentro do organização, Em conjunto com as seguintesinformações:Chave atributos da aplicação• Clientes e os utilizadores• Finalidade comercial• Nível de importância do negócioITIL V3 - Operação de Serviço - Página: 266 de 423
  • 267. • Arquitetura (Incluído o Infraestrutura de TI dependências)• Desenvolvedores, grupo de apoios, fornecedors ou fornecedores• O investimento feito no aplicação até o momento. A este respeito, acarteira de aplicações pode ser utilizada como um ativos registo para asaplicações,O objetivo do portfólio de aplicativos é analisar a necessidade eo uso deaplicações no organização. Ele pode ser usado para ligar a funcionalidade e deinvestimento para negócios atividade e é, portanto, uma parte importante docurso de TI planejamento e controlar. Outro benefício da Carteira de aplicação éque ele pode ser usado para identificar a duplicação e licenciamento excessivode aplicações.A Carteira de Aplicação faz parte do total De serviços de TI Carteira, que édiscutida em detalhe na Estratégia de Serviço publicação.O portfólio de aplicativos e do Catálogo de ServiçosA Carteira do aplicativo não deve ser confundido com o Catálogo de Serviço enão deve ser anunciado como uma lista de serviços para clientes ou usuários.Os aplicativos são um dos componentes usado para fornecer serviços de TI,geralmente não os serviço si.O portfólio de aplicativos deve, portanto, ser usado como um documento deplanejamento apenas pelos gerentes e funcionários que estão envolvidos com odesenvolvimento e gestão da estratégia de TI da organização, bem como aequipe de TI, que têm a tarefa de gerir as aplicações ou as plataformas em queos aplicativos são executados.O Catálogo de Serviços deve se concentrar em listar os serviços que estãodisponíveis, em vez de simplesmente listar aplicações e assumindo que osusuários e clientes podem fazer a ligação. Dito isto, há momentos em que aaplicação é sinônimo de serviço, por exemplo de processamento de aplicativossão normalmente conhecido por seu nome, um pedido de serviço dehospedagem irá mencionar os nomes dos hospedado aplicação, etc6.5.9.2 Requisitos da AplicaçãoHá dois conjuntos de documentos que contêm exigências para aplicações:• Requisitos de Negócio delinear o Business Case para a aplicaçãodesejada, em outras palavras, o que a empresa vai fazer com aaplicação. Isso irá incluir o retorno sobre o investimento para a aplicação,bem como todas as melhorias relacionadas ao negócio. Requisitos denegócios também incluem a Exigência de Nível de Serviços, tal comodefinido pelos clientes e utilizadores de serviços.ITIL V3 - Operação de Serviço - Página: 267 de 423
  • 268. • Requisitos da Aplicação documentos baseiam-se nos requisitos denegócio e especificar exatamente como a aplicação irá atender a essesrequisitos. Em resumo, os documentos de requisitos de aplicação reunirinformações que serão utilizadas para nova comissão aplicaçãos oualterações nos aplicativos existentes, por exemplo:• Para projeto o arquitetura da aplicação (especificação dosdiferentes componentes da sistema, Como eles se relacionamentre si e como eles serão geridos)• Para especificar uma Request for Proposal (RFP) para umComercial Off the Shelf (COTS) aplicação• Para iniciar o projeto e construção de uma aplicação em casa.Requisitos documentos são normalmente de propriedade de um projeto líder, oude um desenvolvimento equipe do projeto, ou para uma equipe de elaboraçãodas especificações para uma RFP. Exigênciadocumentos s estão sujeitos adocumento controlar para o projeto, que faze