Você está na página 1de 36

ITIL Fundamentos de Gerenciamento

de Servios de TI

Last Update 0.9 | 2006/07/18

Objetivo do Treinamento e Programa


Oferecer compreenso bsica (teoria e conceitos) dos componentes de Suporte a Servios e entrega de Servios de
ITIL
Preparar os participantes para uma avaliao (exame) de mltipla escolha, com 40 questes e 1 hora de durao (se
aplicvel), para obteno da Certificao em Fundamentos do ITIL.
Programa:
- Introduo ao ITIL
- Suporte a Servios (Processos Operacionais)
- Entrega de Servios (Processos Tticos)
- Reviso Geral e Avaliao (Se Aplicvel)
Introduo ao ITIL
ITIL & Gerenciamento de Servios em TI
ITIL: Information Technology Infrastructure Library
- Fornece um conjunto amplo, consistente e coerente de melhores prticas focadas no Gerenciamento de Servios de
TI.
- Promove uma abordagem de qualidade para alcanar efetividade de negcio na utilizao de sistemas de
informao.
Gerenciamento de Servios de TI
- Focado na entrega e suporte de servios em TI que sejam adequados aos requisitos de negcio da organizao.
Coleo de Livros ITIL
Planejamento para Implementar Gerenciamento de Servios
A Perspectiva de Negcio
Gerenciamento de Aplicaes
Gerenciamento de Servios
Entrega de Servios
Suporte a Servios
Gerenciamento de Segurana
Gerenciamento de Infra-Estrutura
Partes Envolvidas
- Office Of Government Commerce (OGC)
* Dono do ITIL, pode vend-lo.
- ISEB, EXIN and Loyalist College
* Podem Certificar * Empresas Paulistas so representantes de ISEB e EXIN
- Information Technology Service Management Forum, itSMF
* Grupos de Usurios, Prticas de Sistemas e Discusso sobre prticas.
* Seminrios, Fruns e Conferncias.
- Pink Elephant
- Organizaes de Prtica
Principais Termos e Conceitos
- Um servio de TI
- Gerenciamento de Sistemas ou Gerenciamento de Servios ?
- Polticas, Processos e Procedimentos.
- Estratgico, Ttico e Operacional (Diretor,Gerente,Tcnico).

- Modelo Genrico de Processo


- Componentes de Processo: Controles, Atividades, Facilitadores & Gerente de Processo. (Boneco)
- O Ciclo de Deming e a Garantia de Qualidade e o Controle de Qualidade. (Just do It | Nike)
- Plan, Do, Check, Act (Planejar, Fazer, Verificar, Agir) 5W2H
- Modelo de Melhoria de Processos
- As Quatro Questes
*O que ta ruim?
*Onde estou?
*Onde quero chegar?
*Como fazer? (Passos, Recursos). Plano
Cheguei ?
Desenho do Boneco deve ser colocado aqui !!!
Formato
- Seo 1: Modulo de Treinamento
- Objetivo do Processo
- Definies do Processo
- Atividades do Processo
- Seo 2: Exerccios
- Por processo
- Respostas chaves
- Seo 3: Referncias
- Viso Geral por Processo
- Benefcios e Desafios por Processo
- Glossrio dos Termos do ITIL
- Seo 4: Mdulo de Exame
- Requerimento para o Exame
- Simulado
Suporte a Servios
O Modelo de Suporte a Servios
Desenho deve existir aqui !!!
- Usado apenas como representao e no regra.
Gerenciamento de Configurao
- Objetivo
- Gerenciamento da Configurao prov um modelo lgico da infra-estrutura ou de um servio, identificando,
controlando, mantendo e verificando as verses dos itens de Configurao (ICs) existentes.
* Controle de Mudanas
* Conhecer todos os conponentes
* Auditoria
1. Objetivo
O Gerenciamento da configurao deve:
- Responsabilizar-se por todos os ativos e configuraes de TI dentro da organizao e seus servios
- Fornecer informaes exatas sobre configuraes e documentao correspondente para apoiar todos os outros
processos de Gerenciamento de Servios
- Fornecer uma base adequada para Gerenciamento de Incidentes, Gerenciamento de Problemas, Gerenciamento de
Mudanas e Gerenciamento de Verses.
- Comparar os registros de configurao com a infra-estrutura e corrigir quaisquer excees.

Definies
- Infra-Estrutura
- Item de Configurao (IC)
- Atributos
- Ativos
- Gerenciamento de Ativos
- Relacionamentos
- Banco de Dados do Gerenciamento da Configurao (BDGC)
- Escopo
- Nvel de IC
- Modelo de Referencia (Baseline)
2. Definies
2.1 Infra-Estrutura
A infra-estrutura inclui hardware, software e documentao relacionada.
2.2 Item de Configurao (IC)
Um item de configurao, IC, um componente de uma infra-estrutura que est (ou deve estar) sob o controle do
Gerenciamento da Configurao. Os ICs podem variar grandemente em complexidade, tamanho e tipo desde um sistema
inteiro at um mdulo nico ou um componente pequeno de hardware.
2.3 Atributos
Detalhes que identificam de forma nica os ICs (localizao, nmero de srie, nmero de verso, proprietrio, etc.)
2.4 Ativos
Recursos de negcios.
* Ex.: Mais de R$ 1.000,00 ativo
* Cadeira no ativo, mas a mesa sim.
2.5 Gesto de Ativos
Um processo Contbil para monitorar a depreciao de ativos cujo preo de compra ultrapassa um limite definido.
2.6 Relacionamentos
Descrio das interfaces que existem entre os ICs na infra-estrutura, parentesco ou conectividade direta.
2.7 Banco de Dados do Gerenciamento de Configurao (BDGC)
Um banco de dados que guarda um registro completo de todos os Itens de Configurao (ICs) associados infra-estrutura
de TI, isto : verses, localizao, documentao, componentes e os relacionamentos entre eles.
2.8 Escopo
Escopo a abrangncia de responsabilidade coberta pelo Gerenciamento da Configurao e a amplitude do BDGC.
dinmico.
2.9 Nvel de IC
O grau de detalhe selecionado para descrever cada IC.
2.10 Modelo de Referncia (Baseline)
Um produto ou sistema estabelecido em um ponto especifico do tempo, que captura tanto a estrutura como os detalhes
daquele produto ou sistema e permite que aquele produto ou sistema seja reconstrudo em uma data posterior.
Exemplos de ICs de Hardware
Desenho deve existir aqui !!!
Atividades

- Planejamento para Gerenciamento de Configurao


- Contexto
- Identificao
- Escopo, Nvel de IC (largura x profundidade/piscina).
- Coleta de Dados e Registro
- Relaes
- Controle
- Registro/Arquivamento e Atualizao
- Informao de Status
- Histrico e Roteiro de Auditoria (Trava qdo coloca memria).
- Verificao e Auditoria
- Desvios (Ter wireless sem saber)
3. Atividades
3.1 Planejamento para Gerenciamento da Configurao
Planejamento e definio do escopo, objetivos, polticas, procedimentos, contexto tcnico e organizacional para o
Gerenciamento da Configurao.
3.2 Identificao
Seleo e identificao das estruturas de configurao para todos os Itens de Configurao da infra-estrutura, seus
proprietrios, seus inter-relacionamentos e documentao de configurao, Incluem a alocao de identificadores para os
Itens de Configurao, suas verses e documentao.
3.3 Controle
Garantia de que somente ICs autorizadas e identificveis sero aceitas e registradas desde o recebimento at o descarte.
3.4 Informao de Status
Relatrio de todos os dados atuais e histricos relacionados a cada IC durante todo seu ciclo de vida. Permite que mudanas
nos Itens de Configurao e seus registros sejam rastreados, isto : rastrear o status de um IC de um status a outro
desenvolvimento, teste, produo, retirada.
3.5 Verificao e Auditoria
Qualidade da configurao controlada por meio de uma srie de revises e auditoria que verificam a existncia fsica dos
Itens de Configurao e se esto registrados corretamente no sistema de Gerenciamento da Configurao.
Informao do Status
Desenho deve existir aqui !!!
A Central de Servios (Service Desk)
Objetivo
- A Central de Servios (Service Desk) moderna simultaneamente voltada ao cliente e focada em seus objetivos principais,
que devem orientar e melhorar o servio para e em favor do negcio.
- Em nvel operacional, seu objetivo fornecer um ponto nico de contato para oferecer orientao, diretrizes e rpida
restaurao dos servios normais para seus clientes e usurios.
1. Objetivo
A Central de Servios (Service Desk) uma funo fundamental para todo o conceito de Gerenciamento de Servio. o
ponto de contato entre o cliente e o servio. responsvel pela abertura e fechamento de chamados originados pelo cliente,
utilizando o Gerenciamento de Incidentes (apresentado em um captulo mais frente). A Central de Servios (Service Desk)
focada e formada por pessoas com expertise tcnica, conscincia do negcio e habilidades interpessoais.
Definies
- Central de Atendimento (Call Center)

- Centro de Suporte (Help Desk)


- Central de Servios (Service Desk) (Assume o proc. e resolve com outras reas)
- Ponto nico de Contato (*)
- Central de Servios no habilitada
- Central de Servios habilitada
- Central de Servios Especializada
(* SPOC Single Point Of Contact)
2. Definies
2.1 Central de Atendimento
O foco principal de uma Central de Atendimento atender grandes volumes de ligaes telefnicas de maneira profissional,
realizando transaes por telefone para servios de televendas de commodities (por exemplo: bancos, seguros).
2.2 Centro de Suporte
O objetivo principal gerenciar, coordenar e resolver Incidentes o mais breve possvel, bem como garantir que nenhuma
solicitao se perca, seja esquecida ou ignorada. Links com o Gerenciamento de Configurao e ferramentas de
conhecimento so normalmente usadas como tecnologias de suporte.
2.3 Central de Servios (Service Desk)
A Central de Servios (Service Desk) amplia a gama de servios e oferece uma abordagem com foco mais global,
possibilitando que os processos de negcio sejam integrados infra-estrutura de Gerenciamento de Servio. No lida
apenas com Incidentes, Problemas e questes, mas tambm fornece uma interface para as outras atividades, como
solicitaes de Mudanas de clientes, contratos de manuteno, licenas de software, Gerenciamento de Nvel de Servio,
Gerenciamento de Configurao, Gerenciamento de Disponibilidade, Gerenciamento Financeiro para Servios de TI e
Gerenciamento de Continuidade de Servios de TI.
2.4 Ponto nico de Contato (Single Point Of Contact - SPOC)
A Central de Servios (Service Desk) fornce orientao, direo e rpida restaurao da proviso normal do servio.
Tipicamente , a funo da Central de Servios (Service Desk) era usada mais como barreira que como capacitadora, mas
atualmente normalmente se dedica com o atendimento do cliente.
2.5 Central de Servios No-Habilitada (Regina)
As ligaes so registradas, descritas em termos gerais e imediatamente encaminhadas.
2.6 Central de Servios Habilitada
Utilizando solues documentadas, esta Central de Servios (Service Desk) pode resolver muitas situaes de
indisponibilidade, ao mesmo tempo em que relatrios de indisponibilidade so encaminhados para equipes de suporte.
2.7 Service Desk Especialista
Esta Central de Servios (Service Desk) tem conhecimento especializado de toda a infra-estrutura de TI e know-how para
resolver a maioria dos incidentes de maneira autnoma.
Modelos de Centrais de Servio (Service Desk)
- Central de Servios Local Tipicamente as organizaes criaram suporte local para atender necessidades de negcios
locais, atendendo chamados de usurios de unidade local.
- Central de Servios Centralizada Uma unidade fsica central que recebe chamados de usurios de vrias localidades.
- Central de Servios Virtual Pode estar localizada e ser acessada em qualquer ponto do mundo.
Central de Servios Local
Desenho deve existir aqui!!!
Central de Servios Centralizada

Desenho deve existir aqui!!!


Central de Servios Virtual
Desenho deve existir aqui!!!

Atividades da Central de Servios (Service Desk)


- Receber ligaes e contatos dos clientes em primeiro nvel
- Registrar e acompanhar Incidentes e Solicitaes de Servio
- Avaliao inicial, procurando resolver ou encaminhar para algum que possa faz-lo, baseado nos nveis de servio
acordados
- Monitorar procedimentos de escalao
- Gerenciar o ciclo de vida da solicitao, incluindo seu fechamento
- Comunicao
- Prover recomendaes para melhoria dos servios
- Alertar clientes sobre necessidade de treinamentos
- Contribuir na identificao de incidentes e solicitaes recorrentes
Gerenciamento de Incidentes
Objetivo
- Restaurar a operao normal do servio o mais breve possvel e minimizar o impacto contrrio nas operaes de negcio.
1 Objetivo
O Objetivo do Gerenciamento de Incidentes assegurar que nveis de servio de alta qualidade sejam mantidos e que a
disponibilidade do servio atenda aos requisitos do cliente.
Operao normal de servio definida como a operao de servio efetiva e eficiente dentro dos limites de Acordo de Nvel
de Servios (ANS) ou das expectativas do usurio.
Definio
- Incidente
- Qualquer evento que no faa parte da operao padro de um servio e que causa, ou possa causar, uma interrupo, ou
reduo, na qualidade daquele servio.
- Requisio de Servio
- Uma categoria de incidente que inclui, por exemplo, um pedido de informao e/ou um aconselhamento e/ou uma
documentao.
- Posio no fluxo de trabalho
- O status de um incidente, refletindo sua situao no ciclo de vida.
- Carga de Trabalho
- O tempo e o esforo despendidos em qualquer parte da resoluo de um incidente.
2. Definies
2.1 Incidente
Dentro da funo de Gerenciamento de sistemas com foco mais tcnico, um evento registrado automaticamente (por
exemplo, exceder a capacidade de uso de disco) normalmente considerado como parte da operao normal. Esses
eventos so includos na definio de incidentes, embora os servios de entrega clientes/usurios no sejam afetados. So
simplesmente considerados como sinais de que, a longo prazo, o disco necessitar ser substitudo por um item de maior
capacidade. Naturalmente, com o tempo, o processo de substituir o disco causaria mudanas necessrias ao BDGC.
2.2 Requisio de Servio

A interao com o cliente no se restringe mais ao telefone e ao contato pessoal. O servio pode ser grandemente
aumentado e ampliado para o cliente, usurios e equipe de suporte por meio da expanso dos mtodos de registro,
atualizao e solicitao de consulta. Isso pode ser alcanado basicamente por meio de e-mail e internet/intranet para
escritrios remotos, embora o fax tambm possa ser uma ferramenta til. Esses mtodos so melhores explorados em
atividades que no so crticas para o negcio, incluindo solicitaes ou contatos no-urgentes, como:
- Informao relacionada compra de produtos.
- Consultas sobre aplicativos.
- Solicitaes de documentao.
- Solicitaes de materiais de consumo.
2.3 Posio no Fluxo de Trabalho
Todos deveriam estar conscientes de cada situao (posio no fluxo de trabalho) e seu significado. Alguns exemplos de
categoria de status (situao) incluem:
- Novo
- Aceito
- Programado
- Atribudo/Encaminhado ao especialista
- Trabalho em andamento (Work in Progress - WIP)
- Em espera
- Resolvido
- Encerrado
2.4 Carga de Trabalho
Anlises exatas da carga de trabalho da equipe de suporte e de terceiros necessitam levar em consideraes o ciclo de vida
completo da solicitao e o tempo despendido em cada fase. Para uma anlise detalhada, a equipe de suporte deve registrar
o tempo que gastou trabalhando em uma solicitao ou em qualquer parte dela. Por exemplo, uma solicitao pode ser
aberta e fechada pela Central de Servios (Service Desk). No entanto, durando seu ciclo de vida, pessoas de outras equipes
de suporte podem ter passado tempo trabalhando na solicitao. Portanto, o tempo decorrido de cada pessoa e o tempo real
gasto necessitam ser contabilizados e colocados no relatrio.
Prioridade
Desenho deve existir aqui!!!
Escalao
Desenho deve existir aqui!!!
3. Definies
3.1 Prioridade
Prioridade definida como a seqncia em que um incidente, problema, ou mudana necessita ser resolvido, baseado no
impacto sobre o negcio e a urgncia.
3.2 Impacto
O grau em que a proviso de servios interrompida dentro da organizao; pode ser indicado pelo nmero de ICs afetados
e/ou a quantidade de interrupo aos principais processos de negcio.
3.3 Urgncia
A velocidade com que os incidentes devem ser resolvidos.
3.4 Esforo Esperado
A quantidade antecipada de recurso, tempo e custo necessrio para restaurar o servio depois da ocorrncia de um
Incidente.
4. Escalada
Escalada o mecanismo que oferece a resoluo adequada de um incidente. Pode ocorrer durante qualquer atividade
durante o processo de resoluo.
4.1 Funcional
Transferir um incidente do grupo de suporte de primeiro nvel para o de segundo nvel ou mais adiante, chamado de
escalada funcional. A escalada funcional basicamente ocorre por falta de conhecimento ou expertise. A escalada funcional

tambm pode ocorrer quando expiram os intervalos de tempo acordados. A escalada funcional automtica, baseada em
intervalos de tempo, deve ser planejada cuidadosamente e no deve exceder os tempos de resoluo acordados no ANS.
Inclui todos os nveis (ou faixas) de servio 1, 2, 3,..., N., incluindo fornecedores terceirizados.
4.2 Hierrquico
Escalada hierrquica pode ocorrer em qualquer momento durante o processo de resoluo quando h a probabilidade de
que o incidente no seja resolvido dentro do prazo ou satisfatoriamente. Escalada hierrquica automtica pode ser
considerada depois de um determinado intervalo critico de tempo, quando provvel que uma resoluo adequada v falhar.
Isso deve ocorrer antes que seja excedido o tempo do ANS para que aes corretivas possam ser tomadas sem o
descumprimento do ANS.
Atividades
Desenho deve existir aqui!!!
5. Atividades
5.1 Deteco de Incidentes e Registro
- Registrar detalhes bsicos do incidente
- Alertar grupos especialistas de suporte conforme a necessidade
5.2 Classificao e Suporte Inicial
- Classificar incidentes e comparar com erros conhecidos e problemas
- Priorizar incidentes
- Informar o Gerenciamento de Problemas sobre novos problemas ou incidentes mltiplos e que no tenham referencia de
comparao.
- Fornecer suporte inicial (resoluo rpida).
- Fechar ou encaminhar o incidente para um grupo especialista e informar clientes/usurios.
5.3 Investigao e Diagnstico
- Avaliar detalhes do incidente
- Reunir e analisar informao/resoluo relacionada com a soluo de contorno ou escalada.
5.4 Resoluo e Recuperao
- Resolver o incidente e elaborar uma Requisio de Mudana (RM) e tomar aes corretivas.
5.5 Fechamento do Incidente
- Confirmar resoluo para o cliente ou originador e atualizar o status para fechado.
5.6 Propriedade, Monitorao, Acompanhamento e Comunicao.
Propriedade
O Suporte tem a propriedade do incidente e gerencia at que seja resolvido de acordo com a satisfao do cliente.
Monitorao e Acompanhamento
O Suporte monitora regularmente o status e o andamento em direo soluo e em comparao com os nveis de servio
de todos os incidentes abertos.
Comunicao
responsabilidade do Suporte, operando dentro do processo de Gerenciamento de Incidente, realizar toda a comunicao
referente aos incidentes entre a rea de TI e o cliente.
Integrao do Processo de Gerenciamento de Incidentes
Desenho deve existir aqui!!!
6. Integrao do Processo de Gerenciamento de Incidentes

Os incidentes entram nos processos vindos de muitas reas, como Gerenciamento de Rede, a partir de usurios via Suporte
e/ou das Operaes de Computador.
Deve haver uma interface prxima entre os processos de Gerenciamento de Incidentes, Gerenciamento de Problemas e
Gerenciamento de Mudanas bem como a funo de Suporte.
Se no so controladas adequadamente, as mudanas podem trazer novos incidentes. Necessita-se de um meio de
rastreamento. Portanto, recomenda-se que os registros de incidente permaneam no mesmo Banco de Dados do
Gerenciamento de Configurao (BDGC) dos problemas, erros conhecidos e registros de mudana, ou a menos com uma
ligao para no precisar se autenticar novamente a fim de melhorar as interfaces e facilitar consultas e relatrios.
Suporte de Primeiro, Segundo e Terceiro Nveis
Desenho deve existir aqui!!!
7. Suporte de Primeiro, Segundo e Terceiro Nveis
As responsabilidades do suporte de primeiro nvel (Suporte) incluem:
- Registro do Incidente
- Encaminhamento da solicitao de servio aos grupos de suporte nos casos em que Incidentes no so fechados
- Suporte inicial e classificao
- Propriedade, Configurao, Acompanhamento e Monitorao.
- Resoluo e Recuperao de Incidentes no atribudos ao suporte de segundo nvel
- Fechamento de Incidentes
Suporte de segundo nvel (grupos especialistas que podem fazer parte do Suporte) estar envolvido em tarefas como:
- Lidar com solicitaes de servio.
- Monitorar detalhes do Incidente, incluindo os Itens de Configurao (IC) afetados.
- Pesquisa e diagnostico do Incidente (incluindo resoluo quando possvel).
- Deteco de possveis Problemas e respectivo encaminhamento para a equipe de Gerenciamento de Problemas para que
eles faam o registro do Problema.
- Resoluo e recuperao dos Incidentes que lhes foram encaminhados.
Suporte de terceiro nvel (grupos de especialistas que podem apoiar o suporte de segundo nvel) estar envolvido em tarefas
como:
- Pesquisa e diagnostico de Incidentes (incluindo resoluo quando possvel).
- Deteco de possveis Problemas e respectivo encaminhamento para a equipe de Gerenciamento de Problemas para que
eles faam o registro do Problema.
- Resoluo e recuperao dos Incidentes que lhes foram encaminhados.
Gerenciamento de Problemas
Objetivo
- O Objetivo do Gerenciamento de Problemas minimizar o impacto de Incidentes e problemas ao negcio, causados por
erros dentro da infra-estrutura de TI e prevenir a repetio de Incidentes relacionados a esses erros.
1. Objetivo
O processo de Gerenciamento de Problemas tanto reativo como pr-ativo. O aspecto reativo est relacionado com a
resoluo de problemas em resposta a um ou mais incidentes. O Gerenciamento de Problemas pr-ativo tem a ver com a
identificao e soluo de problemas e erros conhecidos antes que os incidentes ocorram.
Definies
- Problemas
- Uma condio identificada a partir de mltiplos Incidentes que demonstram sintomas comuns, ou a partir de um
nico Incidente importante, indicativo de um erro especfico, cuja causa desconhecida.
- Erro Conhecido
- Uma condio identificada por meio de um diagnstico bem sucedido da causa raiz de um Problema, em que se
confirma que um IC est falhando e uma soluo provisria tem sido identificada.

10

- Soluo de Contorno
- Mtodo de evitar um Incidente ou Problema, seja a partir de um reparo temporrio ou de uma tcnica. Significa que
o cliente no depende de um aspecto particular do servio que, sabe-se, apresenta um problema.
2. Definies
Um novo problema identificado e registrado para cada incidente sem soluo de rotina disponvel ou sem comparao com
um problema existente ou erro conhecido. O processo de localizar solues de rotina e/ou compar-los com problemas/erros
conhecidos chamado Comparao de Incidentes. O Gerenciamento de Incidentes, na procura de resolver os incidentes o
mais breve possvel, realiza esse processo. Se no se encontra combinao para os incidentes, ento envia um alerta para
Gerenciamento de Problemas sobre o novo incidente. Isso garante que o Gerenciamento de Problemas esteja sempre atento
a novos incidentes e, dependendo do impacto e/ou severidade desses incidentes, possa identific-los como um novo
problema, abrindo um novo registro de problema para remov-lo permanentemente da infra-estrutura.
Processo de Gerenciamento Reativo de Problemas
Desenho deve existir aqui!!!
3. Atividades
3.1 Atividades do Gerenciamento Reativo de Problemas
3.1.1 Controle do Problema
O Controle do Problema identifica as causas fundamentais dos incidentes para prevenir repeties futuras.
3.1.2 Controle de Erro
O Controle de Erro abrange os processos envolvidos em lidar com os erros conhecidos at que estes sejam eliminados pela
implementao bem sucedida de uma mudana sob controle do processo de Gerenciamento de Mudanas. O Objetivo
estar atento aos erros, monitor-los e elimin-los quando seja vivel e justifique os custos.
3.2 Gerenciamento Pr-Ativo de Problemas
- Anlise de tendncias.
- Foco em ao preventiva
- Importantes revises de problemas.
De Incidente Para Problema
Para Erro Para Mudana
Desenho deve existir aqui!!!
4. Relao entre Incidente, Problema e Gerenciamento de Mudanas.
Deve haver uma interface prxima entre os processos de Gerenciamento de Incidentes, Gerenciamento de Problemas e
Gerenciamento de Mudanas bem como a funo de Suporte. Se no so controladas adequadamente, as mudanas podem
trazer novos incidentes. Os registros de incidente devem permanecer no mesmo BDGC dos problemas, erros conhecidos e
registro de mudana. Ou a menos com uma ligao para no precisar se autenticar novamente. O Gerenciamento de
problemas exige o registro exato e detalhado dos incidentes para identificar, efetiva e eficientemente, a causa dos incidentes
e as tendncias.
Cada incidente resultado de um erro na infra-estrutura de TI. Para descobrir um erro, um problema definido, pesquisado e
diagnosticado. Assim que se encontra o IC que causou o erro, o problema se torna um erro conhecido. Um erro conhecido
removido por meio de uma mudana e o Gerenciamento de Problemas assegura-se de que uma RM seja enviada ao
Gerenciamento de Mudanas.
Gerenciamento de Mudanas
Objetivo
- Garantir que mtodos e procedimentos padronizados sejam usados para lidar com rodas as mudanas de maneira eficiente
e rpida a fim de minimizar o impacto de incidentes relacionados a mudanas e melhorar as operaes do dia-a-dia.
(Gerenciamento de Mudana no faz a mudana, mas avalia).

11

1. Objetivo
Um nmero alto de mudanas no indica necessariamente algum tipo de problema com o sistema de Gerenciamento de
Mudanas. Pode simplesmente refletir um sistema voltil e qualquer tentativa de reduzir o nmero de Requisies de
Mudanas (RM) pode sufocar a inovao. No entanto, um Gerenciamento de Mudanas eficiente e efetivo deve mostrar
claramente que h menos incidentes relacionados a mudanas que antes da implementao do processo.
A qualidade do servio em geral ser melhorada como resultado da reduo de incidentes relacionados a mudanas.
de fundamental importncia que os processos de Gerenciamento de Mudanas tenham grande visibilidade e canais de
comunicao para promover transies tranqilas no momento em que as mudanas ocorrem.
Definies
- Mudana
- Requisito de Mudana (RM)
- Gerente de Mudana e Mudanas Menores
- Comit de Controle de Mudanas (CCM) e Mudanas Significativas
- Gerncia Executiva e Mudanas Maiores
- Comit de Emergncia do Comit de Controle de Mudanas (CE/CCM) e Mudanas Urgentes
- Mudana Normal
- Programao Futura de Mudanas (PFM)
- Disponibilidade Projetada de Servio (DPS)
2. Definies
2.1 Mudana
Uma ao que resulta em um novo status para um ou mais ICs da infra-estrutura de TI.
2.2 Requisio de Mudana (RM)
Utilizado para registrar detalhes de uma mudana em qualquer IC.
2.3 Gerente de Mudanas e Mudanas Menores
O Gerente de Mudanas aprova Mudanas Menores que so caracterizadas por causar pequeno impacto. Necessitam-se
poucos recursos de Desenvolvimento ou runtime adicional.
2.4 Comit de Controle de Mudana (CCM) e Mudanas Significativas
O CCM um grupo escolhido de pessoas (incluindo representantes de TI e do Negcio) com autoridade de deciso para
Mudanas Significativas. As Mudanas Significativas so caracterizadas como tendo impacto considervel ou complexo e/ou
necessidades de recursos de desenvolvimento ou runtime.
2.5 Gerncia Executiva e Mudanas Maiores
A Gerncia Executiva o grupo responsvel pela aprovao de Mudanas Maiores. Uma vez aprovada, a Requisio de
Mudana (RM) deve ser devolvida, talvez via Comit de Controle de Mudanas, para agendamento e implementao. As
Mudanas Maiores so caracterizadas como tendo enorme impacto e/ou necessidades de grandes quantidades de recursos
de desenvolvimento ou runtime.
2.6 Comit de Emergncia do Comit de Controle de Mudanas (CE/CCM)
A CE/CCM um subgrupo do Comit de Controle de Mudanas e trata as Mudanas Urgentes. Mudanas Urgentes devem
ser minimizadas por causa da interrupo na infra-estrutura e alta incidncia de falhas.
2.7 Mudana Normal
uma mudana, na infra-estrutura, que segue um roteiro definido. Bastante comum a soluo aceita para um requisito
especifico ou um conjunto de requisitos.

12

2.8 Programao Futura de Mudanas (PFM)


Um cronograma com detalhes de todas as mudanas aprovadas para implementao e suas datas propostas de
implementao.
2.9 Disponibilidade Projetada de Servios (DPS)
Documento que contm detalhes das mudanas nos ANSs aprovados e disponibilidade de servio em virtude do cronograma
atual de mudanas (PFM).
Atividades
- Registro de Mudana e Filtragem
- Alocao de Prioridade
- Categorizao de Mudana
- Averiguao de Impactos e Recursos
- Aprovao de Mudana
- Agendamento da Mudana
- Coordenao da construo, teste e implementao.
- Reviso da Mudana / Reviso Ps-implementao
3. Atividades
3.1 Registro de Mudanas e Filtragem
O Gerente de Mudanas aceita ou rejeita um RM dependendo se h informao suficiente nos formulrios de solicitao para
realizar uma avaliao adequada e/ou se as mudanas esto alinhadas aos objetivos da organizao. As RMs rejeitadas so
devolvidas ao originador com explicaes sobre a rejeio.
3.2 Alocao de Prioridade
O Gerente de Mudanas deve ser responsvel em alocar prioridades. A prioridade da RM deve ser decidida em colaborao
com o solicitante e, se necessrio, com o Comit de Controle de Mudanas (CCM). Contudo, no deve ser deixada
unicamente ao solicitante, pois pode ocorrer uma prioridade mais alta que a justificvel. A avaliao de risco de
fundamental importncia nesta fase.
3.3 Categorizao de Mudana
A questo do risco para o negcio de qualquer mudana deve ser levada em conta antes da aprovao de qualquer
mudana. O Gerenciamento de Mudanas deve analisar casa RM e decidir como proceder conforme a categoria (prdefinida) em que se encaixa a RM.
3.4 Averiguao de Impactos e Recursos
Baseado nessas avaliaes e nos benefcios potenciais da mudana, cada avaliador deve indicar se apia a mudana e qual
a prioridade atribuda.
3.5 Aprovao de Mudana
Dependendo da categoria, a solicitao ser apresentada ao Gerente de Mudanas, Comit de Controle de Mudanas ou a
Gerencia Executiva. Uma avaliao de impacto e recurso dever ser apresentada antes que seja concedida a aprovao
para a mudana. A mudana colocada no cronograma e acrescentada Programao Futura de Mudanas (PFM).
3.6 Agendamento da Mudana
Sempre que possvel, O Gerente de Mudanas deve programar mudanas aprovadas em liberaes alvo (target) e
recomendar a alocao apropriada de recursos.
3.7 Coordenao da construo, teste e implementao.

13

Mudanas so desenvolvidas e procedimentos de restaurao so preparados e documentados com antecedncia para que,
em caso de erros depois da implementao, esses procedimentos possam ser ativados rapidamente. As mudanas ento
so testadas com antecedncia (incluindo procedimentos de recuperao quando possvel) e implementadas.
3.8 Reviso da Mudana / Reviso Ps-implementao
O Gerenciamento de Mudanas deve revisar rodas as Mudanas implementadas depois de um perodo pr-definido.
Normalmente chamada de Reviso de Ps-Implementao.
Relaes
Desenho deve existir aqui!!!
Gerenciamento de Liberaes
Objetivo
- O Gerenciamento de Liberaes assume uma viso holstica (um todo) da mudana em um servio de TI e deve garantir
que todos os aspectos de uma liberao, tanto tcnicos como no tcnicos, sejam considerados m conjunto.
1. Objetivo
O Gerenciamento de Liberaes se preocupa com as mudanas em servios definidos de TI. O Gerenciamento de
Liberaes trabalha em conjunto com os Gerenciamento de Mudanas e da Configurao para garantir que o BDGC esteja
atualizado, as mudanas adequadamente gerenciadas e todas as novas verses de software estejam armazenadas na
Biblioteca de Software Definitivo (BSD). Muitos provedores de servios e fornecedores podem estar envolvidos em liberar
verses de hardware e software dentro de um ambiente distribudo.
Definies
- Liberao (Release)
- Usado para descrever uma coleo de mudanas autorizadas para um servio de TI. Uma liberao (release)
definida pela RM (Requisio de Mudana) que a implementa.
- Biblioteca de Software Definitivo (BSD)
- Uma rea fsica e segura onde as verses autorizadas e definitivas de todos os ICs de software so armazenadas e
protegidas.
- Depsito de Hardware Definitivo (DHD)
- Componentes de reserva e montagens que so mantidos no mesmo nvel em que os sistemas do ambiente real.
- Verso
- Uma instncia identificada de um IC para fins de rastreamento de auditoria do histrico de mudanas.
2. Definies
2.1 Liberao (Release)
Uma liberao uma coleo de mudanas autorizadas em um servio de TI e definida pela RM que ela implementa.
Normalmente uma liberao consiste em correes de problemas e melhorias de servio.
2.2 Biblioteca de Software Definitivo (BSD)
A BSD inclui cpias definitivas de software adquirido (junto com os documentos de licena ou informao), software
desenvolvido no site e cpias eletrnicas mster da documentao.
2.3 Depsito de Hardware Definitivo (DHD)
Uma rea separada para o armazenamento seguro de peas de reserva definitivas. Detalhes desses componentes e seus
respectivos desenvolvimentos e contedos devem ser detalhadamente registrados no BDGC.
2.4 Verso

14

Uma situao identificada de um Item de Configurao dentro de uma estrutura detalhada de produto ou estrutura de
configurao com o objetivo de acompanhar e auditar o histrico da mudana. Tambm utilizado para Itens de Configurao
de software para definir uma identificao especfica liberada em desenvolvimento para esboo (drafting), reviso ou
modificao, teste ou produo.
Definies
- Poltica de Liberao
- Unidade de Liberao
- Tipos de Liberao
- Liberao Delta
- Liberao Completa
- Liberao em Pacote
- Liberao de Emergncia
Cont.
2. Definies
2.5 Poltica de Liberao
um documento que define os papeis e as responsabilidades para o Gerenciamento de Liberao. Esse documento
especifica as diretrizes e os detalhes para cada sistema com suporte ou servio de TI. Em resumo, faz parte do plano geral
de Gerenciamento de Mudanas.
2.6 Unidade de Liberao
O principal objetivo de uma Unidade de Liberao decidir o nvel de unidade de release mais apropriado para cada item de
software ou tipo de software.
2.7 Tipos de Liberaes
2.7.1 Liberao Delta
Inclui somente aqueles ICs dentro da unidade de liberao que foram modificados ou so novos desde a ltima liberao
completa ou delta. utilizada quando no se justifica uma liberao completa.
2.7.2 Liberao Completa
Todos os componentes da unidade de liberao so desenvolvidos, testados, distribudos e implementados em conjunto. O
teste de regresso com parte do processo de implementao de uma liberao completa que permite um grande nmero de
componentes seja re-testado para garantir que no h degradao na funo ou comportamento do sistema.
2.7.3 Liberao em Pacote
Inclui pelo menos duas verses completa, delta ou ambas agrupadas em conjunto. O objetivo oferecer perodos mais
longos de estabilidade por meio da reduo da freqncia de verses introduzidas no ambiente real.
2.7.4 Liberao de Emergncia
Normalmente contm as correes para um nmero pequeno de Problemas Conhecidos.
Atividades de Gerenciamento de Liberaes
Desenho deve existir aqui!!!
3. Atividades
3.1 Poltica de Verso
Garante que cada verso seja conduzida de acordo com as Diretrizes de Liberaes que tenha um identificador nico para
objetivos de rastreamento que lhe sejam atribudos.
3.2 Planejamento de Verso

15

Isso envolve acordo sobre polticas e procedimentos a serem utilizados, determinao de funes e responsabilidades,
planejamento dos nveis de recursos, etc.
3.3 Desenhar, Desenvolver e/ou Comprar Software.
Os procedimentos devem ser planejados e documentados para desenvolver liberaes de software, reutilizando
procedimentos-padro sempre que possvel.
3.4 Desenvolvimento e Configurao de Software
Isso envolve procedimentos de planejamento e documentao para desenvolvimento de verses, compilao de mdulos de
aplicativos, descrio de rotinas de instalao automatizadas, levando em conta requisitos de segurana ao liberar
equipamentos novos/modificados, carga de banco de dados de testes com dados de teste, etc.
3.5 Teste de Adequao
Deve incluir teste funcional, teste operacional, teste de desempenho e teste de integrao. A falta de teste a causa principal
de falhas em todas as Mudanas e Liberaes.
3.6 Aceite de Verso
Isso envolve verses de teste e inclui procedimentos de reserva. O teste de integrao realizado pelo pessoal de negcio e
envolver a equipe de TI para verificar qualquer procedimento de suporte modificado.
3.7 Planejamento de Implementao
Isso envolve a criao de um cronograma detalhado de eventos, incluindo responsabilidades e tarefas, a documentao de
planos de ao por site, desenvolvendo planos de compra e adquirindo software hardware/software.
3.8 Comunicao, Preparao e Treinamento.
Comunicar aos clientes e equipe de suporte importante. Identifique o que est planejado e como isso pode afet-los.
Revise os planos por meio da realizao de reunies de planejamento de implementao e sesses de treinamento.
3.9 Distribuio e Instalao
Isso envolve a distribuio de verses de software, e, se for o caso, as respectivas mudanas de hardware, desde o
ambiente de desenvolvimento para o de teste e para o ambiente real. Tambm garante que o equipamento seja entregue
com segurana a seu destino e nas condies esperadas, que as reas de armazenamento sejam seguras, que a integridade
do software seja mantida durante o manuseio, embalagem e entrega, que os procedimentos sejam seguidos e verificaes
automatizadas realizadas para garantir que os pr-requisitos de software e hardware sejam atendidos, etc.
O Modelo de Suporte a Servios
Desenho deve existir aqui !!!
Entrega de Servios
O Modelo de Entrega de Servios
Desenho deve existir aqui !!!
Gerenciamento do Nvel de Servio
Objetivo
- Manter e melhorar a qualidade do servio de TI por meio de um ciclo constante de acordo, monitorao e relatrio para
atender aos objetivos e negcio do cliente.
1. Objetivo
O processo de Gerenciamento do Nvel de Servio envolve tanto o cliente quanto o provedor de servios de TI. Juntos, eles
definem, negociam, aprovam e monitoram nveis de servio. Essa comunicao contnua proporciona um relacionamento
mais slido entre o Gerenciamento de servio de TI e seus clientes. A comunicao do Gerenciamento do Nvel de Servio
tem o foco na busca do acordo no em manter uma das partes como refm,

16

Gerenciamento d o Nvel de Servio o nome dado aos processos de planejamento, coordenao, elaborao de minuta,
acordo, monitorao e relatrio em relao aos Acordos de Nvel de Servio; tambm reviso permanente dos resultados
do servio para garantir que a qualidade, necessria e de custo justificvel, seja mantida e gradativamente melhorada.
Definies
- Catlogo de Servio
- Requisitos de Nvel de Servio (RNS)
- Acordo de Nvel Operacional (ANO)
- Contrato de Apoio (CA)
- Acordo de Nvel de Servio (ANS)
- Programa de Melhoria de Servio (PMS)
1. Definies
1.1 Catlogo de Servios
O Catlogo de Servio define os servios fornecidos por default com as opes e nveis por default. O Catlogo de Servios
pode ser usado para das organizao um perfil do provedor de servios de TI e aos usurios uma viso geral de todos os
servios fornecidos, informao adicional sobre o contedo do Catlogo de Servios pode ser encontrada na seo
subseqente de observaes.
1.2 Requisitos de Nvel de Servio (RNS)
Requisitos de Nvel de Servio formam uma lista dos requisitos de servio dos clientes. As RNSs devem ser parte integral de
critrios de design do servio, dos quais a especificao funcional uma parte.
1.3 Acordo de Nvel Operacional (ANO)
Um Acordo de Nvel Operacional um acordo feito entre um departamento interno de TI (por exemplo, Gerenciamento de
Rede) e o Gerenciamento do Nvel de Servio.
1.4 Contrato de Apoio (CA)
Um contrato com um fornecedor externo, que abrange servios necessrios para suportar Ti na entrega de servios.
1.5 Acordo de Nvel de Servio (ANS)
Um ANS um acordo escrito entre um fornecedor de servios de TI e o(s) cliente(s) de TI, definindo as principais metas de
servio e as responsabilidades de ambas as partes. importante observar que essas metas devem ser bem entendidas e
aprovadas por ambas as partes a fim de evitar disputas e mal-entendidos.
1.6 Programa de Melhoria do Servio (PMS)
Um projeto formal, realizado dentro do Gerenciamento do Nvel de Servio, focado na satisfao do Cliente e/ou nos
funcionrios.
O Catlogo de Servio
Desenho deve existir aqui !!!
2. Contedo do Catlogo de Servios
O Catlogo de Servios contm, entre outras coisas, a seguinte informao:
- Nmero de verso, data de criao, data de modificao.
- ndice
- Prefcio do Diretor de TI
- Perfil do provedor de servio de TI
- Horrio de servios e acessibilidade do provedor de servios de TI
- Viso geral de servios e produtos
- Servios focados ao cliente ou descrio do produto.
- Especificaes
- Entregveis

17

- Horrios de servios
- Horrios de manuteno
- Horrios de suporte
- Horrios de entrega
- Metas de qualidade (disponibilidade, confiabilidade, usabilidade, prioridade).
- Requisitos
- Procedimento de solicitao de mudana.
- Poltica de contingncia.
- Preo e cobrana.
- ndice e definies.
Esse catlogo deve listar todos os servios fornecidos, um resumo de suas caractersticas e detalhes dos clientes e
mantenedores de cada servio. Pode ser necessrio certo trabalho de investigao para compilar a lista e aprov-la junto
com os clientes. Um Banco de Dados do Gerenciamento da Configurao (BDGC), ou um banco de ativos, pode ser uma
forte valiosa de informao.
ANSs, ANOs, CAs
Desenho deve existir aqui !!!
Estruturas de ANS
Desenho deve existir aqui !!!
4. Definies Estrutura do Gerenciamento do Nvel de Servio
ANSs/ANOs/CAs
A maior parte dos provedores de servios de TI dependente, de alguma maneira, dos seus prprios fornecedores (interno
e/ou externo). Eles no podem se comprometer a atender as metas do ANS a no ser que o prprio desempenho de seus
fornecedores suportem essa metas. Contratos com fornecedores externos uma obrigatoriedade, mas muitas organizaes
tambm tem identificado os benefcios de ter simples acordos com grupos internos de suporte, normalmente citados como
ANOs (Acordos de Nvel Operacional).
5. Estruturas de ANS
5.1 Baseado no Cliente
Um acordo com um grupo individual de Clientes, cobrindo todos os servios que eles utilizam. Por exemplo, podem ser feitos
acordos com o Departamento Financeiro de uma organizao, cobrindo por exemplo o Sistema Financeiro, o Sistema de
Contabilidade, o Sistema de Folha de Pagamento, o Sistema de Cobrana, o Sistema de Procurement(obteno) e qualquer
outro sistema de TI que eles utilizem.
5.2 Baseado em Servio
o caso em que um ANS cobre um servio para todos os Clientes daquele servio. Por exemplo, pode ser estabelecido um
ANS para o servio e e-mail da organizao, cobrindo todos os Clientes daquele servio.
5.3 ANSs Multi-Nvel
H organizaes que escolheram adotar uma estrutura multi-nvel de ANS. Por exemplo, uma estrutura de trs camadas,
como segue:
1)
Nvel Corporativo: cobre todas as questes genricas de GNS, adequadas para todos os Clientes em toda a
organizao. Essas questes tendem a ser menos volteis, consequentemente necessitam-se de menos atualizaes.
2)
Nvel Cliente: cobre todas as questes de GNS que so relevantes para um grupo especfico de Clientes,
independentemente do servio utilizado.
3)
Nvel Servio: cobre todas as questes de GNS que so relevantes para um servio especifico, em relao a
esse grupo especfico de Clientes (um para cada servio coberto pelo ANS).
Atividades
Desenho deve existir aqui !!!
6. Activies

18

6.1 Funo Estabelecida


6.1.1 Planejamento
Atividades iniciais de planejamento incluem a nomeao de um Gestor de Nvel de Servio, a definio de papis e
responsabilidades, o planejamneto de monitorao de habilidades e identificao de ferramentas de suporte. realizada a
definio inicial de percepo de servios bem como a reviso dos atuais ANOs e USs.
6.1.2 Implementao
Antes de continuar com o GNS, as atividades so quantificadas e os recursos, fundos e critrios de qualidade so definidos.
Deve ocorrer a identificao de risco bem como o planejamento para as estruturas de ANS e Catlogo de Servios.
Desenvolve0se um formato piloto de ANS.
6.2 Implementar ANS
6.2.1 Catalogar Servios
O Catlogo de Servios produzido. A gesto contnua de expectativas importante.
6.2.2 Draft
A estrutura do ANS e a redao so finalizadas e os RNS so reunidos.Monta-se um esboo de ANS.
6.2.3 Negociar
Comea-se a buscar um acordo para os ANSs e a estabelecer as capacidades de monitoramento.
6.2.4 Revisar CAs e ANOs
Revisar CAs e ANOs para verificar a compatibilidade com os ANSs e definir os procedimentos de relatrio e reviso.
6.2.5 Acordar ANSs
Ocorre a aprovao de ANSs e esses ANSs so divulgados.
6.3 Gerenciar Processo
6.3.1 Monitorar
Estimular monitorao e produzir relatrios de realizao de servios e relatrios operacionais.
6.3.2 Reportar
Relatrios peridicos com detalhes de desempenho comparados aos ANSs devem incluir tendncias, etc.
6.3.3 Revisar
Relatrios peridicos devem ser produzidos e devem circular alguns dias antes das revises de ANSs. Quaisquer perguntas
ou divergncias devem ser resolvidas antes da reunio de reviso.
6.4 Revises Peridicas
6.4.1 Revisar ANSs, ANOs e CAs
Reunies de Reviso de Servios devem ocorrer regularmente com os clientes para revisar a realizao dos servios no
ltimo perodo e prever quaisquer questes para o prodo seguinte. Realize essas reunies mensalmente, trimestralmente
pois podem ocasionar PMS.
6.4.2 Revisar Processo GNS
ANSs, CAs e ANOs devem estar atualizados.
Contedo Sugerido para ANS
- Introduo

19

- Horrio do Servio
- Disponibilidade
- Confiabilidade
- Suporte
- Capacidade de Processamento (throughput)
- Tempos de resposta de transao
- Tempos de processamento batch
- Mudanas
- Segurana e Continuidade de Servio em TI
- Cobrana
- Relatrio e reviso de servio
- Segurana
- Sustentabilidade e capacidade de servio.
7. Contedo do Acordo do Nvel de Servio
7.1 Introduo
A introduo deve conter o seguinte:
- Partes do acordo e signatrios
- Ttulo e breve descrio do acordo
- Responsablidades TI e Cliente

- Datas: comeo, fim, reviso


- Escopo do acordo
- Descrio de servios includos

7.2 Horas de Servio


Horas de servio devem incluir as horas em que normalmente se necessita cada servio;
Proviso para solicitar extenses de servio, incluindo perodo necessrio mediante aviso;
Horrios especiais como feriados pblicos e um calendrio de servio.
7.3 Disponibilidade
Metas de disponibilidade dentro do horrio acordado so normalmente expressas como porcentagens e devem ser includas
no ANS bem como o perodo de medio e o mtodo.
7.4 Confiabilidade
Normalmente expressada como o numero de interrupes no servio, Tempo Mdio entre Defeitos (TMED) ou Tempo Mdio
entre Incidentes de Sistema (TMEIS).
7.5 Suporte
Horrio de suporte deve ser identificado, especialmente se no for o mesmo do horrio de servio. Meta de tempo para
resposta seja fisicamente ou por outro mtodo.
7.6 Capacidade de Processamento (throughput)
Indicao do volume de trfego provvel e capacidade de processamento (throughput).
7.7 Tempos de Resposta de Transao
Inclui-se a meta de tempo para tempo de resposta mdio ou mximo da workstation. Normalmente se expressa em
porcentagem.
7.8 Tempo de Processamento de Batch
Tempo para entrega de input e output, bem como o local.
7.9 Mudana
Metas para aprovao, encaminhamento e implementao de RM, normalmente baseado na categoria ou
urgncia/prioridade da mudana.
7.10 Segurana e Continuidade dos Servios em TI

20

Citao de quaisquer planos de continuidade de TI e como acion-los, incluindo cobertura de quaisquer questes de
segurana, em especial quaisquer responsabilidades do cliente. Detalhes de qualquer diminuio ou modificao de meta de
servio em caso de ocorrncia de situaes de desastre.
7.11 Cobrana
Detalhes da frmula de cobrana e perodos. Se o ANS cobre o relacionamento com terceiro, as taxas devem ser detalhadas
no apndice.
7.12 Relatrio e Reviso de Servio
Contedo, freqncia e distribuio de relatrios de servio; freqncia da reunio de reviso de servios.
7.13 Segurana
Meno sucinta e/ou referncia poltica de segurana da organizao. Detalhes de quaisquer responsabilidades
especficas de ambas as partes.
7.14 Sustentabilidade e Servio
A sustentabilidade define o perodo de tempo aceitvel que um cliente pode esperar para que determinado componente ou
servio esteja fora do ar ou restaurado. A sustentabilidade tambm se refere ao tempo necessrio para realizar a
manuteno preventiva. Um cronograma do tempo planejado para estar fora do ar tambm deve ser mencionado no ANS.
A funcionalidade do servio se refere a contratos de servio celebrados com fornecedores terceirizados de TI.
Gerenciamento Financeiro para Servios em TI
Objetivo
- Fornecer administrao rentvel dos ativos de TI e recursos utilizados para fornecer os servios de TI
1. Objetivo
O alvo a qualquer organizao de servios de TI deve incluir:
- capacidade de prestar contas de todas as despesas com servios de TI e atribuir esses custos aos servios entregues aos
clientes da organizao.
- Dar assistncia s decises executivas sobre investimentos em TI, fornecendo business cases detalhados para mudanas
em servios de TI.
Definies
- Modelo de Custo
- Uma estrutura usada para registrar e alocar custos
- Tipos de Custos
- Usado para categorizar os curso dentro de uma estrutura de Modelo de Custos
- Elementos de Custos
- Usado para auxiliar a diviso dos tipos de custos
- Categoria de Custos
- Capital ou Operacional (Classificao mnima dos Elementos de Custos)
- Custos Direto ou Indireto
- Custos Fixo ou Varivel
2. Definies
2.1 Modelo de Custo

21

Modelo de custo baseado no clculo do custo por cada Cliente. Outros modelos podem ser desenvolvidos para mostrar o
custo por cada servio ou os custos por cada localidade. Modelos de custos que permitem o clculo de custos por Cliente
so o ponto de partida caso seja introduzido um Sistema de Cobrana.
2.2 Tipos de Custo
Exemplos de Tipos de Custo incluem: Hardware, Software, Pessoas, Acomodaes, Servios Externos e custos de
transferncia.
2.3 Elementos de Custo
Caso seja necessrio maior detalhamento no calculo de custo, os principais Tipos de Custo selecionados hardware,
software, pessoas, acomodaes e transferncia podem ser divididos ainda mais. Por exemplo, hardware pode ser dividido
em Escritrio, Rede e Servidores Centrais. O objetivo garantir que cada custo identificado na organizao de TI possa ser
colocado dentro de uma tabela de custos, por tipo. Isso possibilita que a analise seja realizada por tipo, por exemplo, todos
os custos de Rede.
2.4 Categoria de Custo
2.4.1 Capital ou Operacional
Custos de Capital so aqueles custos que tipicamente se aplicam aos ativos fsicos (substanciais) da organizao. Custos
Operacionais so os que resultam da operao diria da seo de Servios de TI, por exemplo, custos de pessoal,
manuteno de hardware e eletricidade e relacionados a pagamentos repetitivos cujos efeitos podem ser medidos dentro de
um perodo de tempo curto, normalmente menos que o ano financeiro de 12 meses.
2.4.2 Diretos ou Indiretos
Custos direto so claramente atribuveis a um nico cliente, por exemplo: sistemas industriais que so utilizados somente
pela diviso industrial. Custos indiretos so aqueles realizados por todos, ou por um nmero de clientes ou servios, por
exemplo: a rede ou o departamento de suporte tcnico, que tem que ser dividido com todos, ou com um nmero de clientes
de maneira justa.
Observao: A cobrana pelos custos indiretos pode ser feita por meio do Custo Baseado em Atividade (ABC Activity
Based Costing). O mtodo ABC comea totalizando todos os custos administrativos em uma organizao e, em seguida,
alocando os custos das atividades aos produtos e servios que necessitaram dessas atividades. Em vez de alocar custos
indiretos arbitrariamente, o ABC aloca esses custos baseado nas atividades realizadas para produtos e servios.
2.4.3 Fixos ou Variveis
Custos fixos se mantm constantes; custos variveis variam com algum fator, como utilizao ou tempo. Custos variveis
tendem a ser usados como elementos de custo que no podem ser facilmente previsveis.
Definies Modelo de Custo
- Poltica de Cobrana
- Notaes de Cobrana
- Comunicao de Informaes
- Flexibilidade de Preo
- Poltica/Mtodo de Preo
- Custo Plus
- Taxa Contratada
- Taxa de Mercado
- Retorno Alvo
- Preo de Contrato Negociado
2.5 Poltica de Cobrana
O mtodo apropriado pode ser escolhido conforme os objetivos do processo.
2.5.1 Notaes de Cobrana
Os custos so faturados, mas no necessitam ser pagos.

22

2.5.2 Comunicao de Informao


Os clientes so informados sobre as cobranas para que estejam conscientes dos custos da utilizao dos servios de TI
pelo seu departamento.
2.5.3 Flexibilidade de Preos
Tarifas so determinadas e cobradas anualmente.
2.6 Poltica de Preos
2.6.1 Custo Plus
Baseado na cobrana dos custos realizados mais margem de lucro.
2.6.2 Taxa Contratada
Para servios em que j esto estabelecidos acordos de preos.
2.6.3 Taxa de Mercado
Preos que se igualam aos cobrados por fornecedores externos.
2.6.4 Retorno Alvo
Servios cujo preo foi determinado antecipadamente.
2.6.5 Preo de Contrato Negociado
Esses preos so discutidos com o cliente. Caso o cliente solicite um novo servio, ento se negocia se ele tem que absorver
todos os custos de investimento ou somente uma proporo.
Modelo de Custo - por Servio
Desenho deve existir aqui !!!
Modelo de Custo - por Cliente
Desenho deve existir aqui !!!
Atividades
- O oramento capacita uma organizao a:
- Prever o dinheiro necessrio para operar os servios de TI durante um determinado perodo.
- Garantir que as despesas reais possam ser comparadas com as previstas em qualquer ponto.
- Reduzir o risco de gastar demais.
- Garantir que receitas esto disponveis para cobrir as despesas previstas.
- A Contabilidade de TI capacita uma organizao a:
- Prestar contas do dinheiro gasto no fornecimento de servios de TI.
- Calcular o custo total de propriedade do fornecimento de servios de TI
- Realizar anlises de custo-benefcio ou retorno sobre investimento.
- Identificar o custo de mudanas.
- A Cobrana capacita uma organizao a:
- Recuperar os custos dos servios de TI dos clientes.
- Operar a organizao de TI como unidade de negcio, se necessrio.
- Influenciar o comportamento de usurio e clientes.
3. Atividades
3.1 Oramento

23

Oramento o processo de prever e controlar o gasto do dinheiro dentro da empresa. Consiste em um ciclo de negociao
peridica para determinar os oramentos (normalmente anual) e a monitorao dia-a-dia dos oramentos atuais.
3.2 Contabilidade de TI
o conjunto de processos que capacita a organizao de TI a prestar contas de maneira plena do modo como se gasta o
dinheiro (em especial a habilidade de identificar custos por cliente, por servio, por atividade). Normalmente envolve livros
fiscais e supervisionado por algum treinado em prticas-padro de contabilidade.
3.3 Cobrana
Cobrana o conjunto de processos necessrios para cobrar os clientes pelos servios a eles prestados. Para alcanar isso,
necessrio uma boa contabilidade, que alcance um nvel de detalhe determinado pelos requisitos dos processo de anlise,
cobrana e relatrios.
Ciclo Financeiro em TI
Desenho deve existir aqui !!!
Oramento, Contabilidade de TI & Ciclos de Cobrana.
Desenho deve existir aqui !!!
4. Ciclo Financeiro de TI
O Gerenciamento Financeiro apia a empresa no planejamento e execuo de seus objetivos de negcio e exige aplicao
em toda a empresa para alcana o mximo de eficincia e o mnimo de conflito. H dois ciclos distintos: um ciclo de
planejamento anual em que projees de custo e previso de carga de trabalho formam a base para clculo de custo e
determinao de preo e um ciclo operacional (mensal ou trimestral) em que os custos so monitorados e comparados com
os oramentos, cobranas so emitidas e receitas so cobradas. Mudanas no sistema de contabilidade de TI devem
coincidir com as revises de ANS e qualquer mudana deve ser includa.
5. Oramento, Contabilidade de TI e Ciclos de Cobrana.
Um ciclo de planejamento (anual) em que projees de custo e previso de carga de trabalho formam a base para clculo de
custo e determinao de preo. Um ciclo operacional (mensal ou trimestral) em que os custos so monitorados e
comparados com os oramentos, cobranas so emitidas e receitas so cobradas.
Gerenciamento de Disponibilidade
Objetivo
- Otimizar a capacidade de infra-estrutura de Ti e servios e apoiar a organizao na entrega de um nvel de disponibilidade
rentvel e sustentvel que capacite o negcio a atingir seus objetivos.
1. Objetivo
O escopo do Gerenciamento de Disponibilidade abrange design, implementao, mensurao e Gerenciamento da
Disponibilidade da infra-estrutura de TI. O Gerenciamento da Disponibilidade comea to logo os requisitos de
disponibilidade para um servio de TI so claros o suficiente para serem articulados. um processo contnuo, terminando
somente quando o servio de TI desligado.
Definies
- Disponibilidade
- Confiabilidade
- Sustentabilidade (interno)
- Funcionalidade do Servio (externo)
- Resilincia (Resistncia)
- Funo Crtica de Negcio (FCN)
- Segurana (confidencialidade, integridade, disponibilidade).
- Banco de Dados de Gerenciamento da Disponibilidade (BDD)
- Janela de Servio

24

2. Definies
2.1 Disponibilidade
Disponibilidade a habilidade de um servio ou componente de Ti para desempenhar a funo requerida em um
determinado instante ou durante um perodo de tempo determinado.
2.2 confiabilidade
Livre de defeitos operacionais. A confiabilidade de um servio inteiro de TI determinada pela confiabilidade de cada
componente dentro da infra-estrutura de TI que entrega o servio de TI.
2.3 Sustentabilidade (Interno)
A habilidade de um componente da infra-estrutura de TI em ser mantido em seu estado operacional, ou restaurado a esse
estado.
2.4 Funcionalidade do servio (Externo)
A funcionalidade do servio descreve as provises contratuais feitas com fornecedores terceirizados de servios de TI para
garantir a disponibilidade, confiabilidade e sustentabilidade dos servios de TI e dos componentes sob sua responsabilidade.
2.5 Resilincia (Resistncia)
A capacidade de um servio de TI em permitir a operao contnua de TI apesar do funcionamento incorreto de um ou mais
de seus subsistemas.
2.6 Funo Crtica de Negcio (FCN)
A Funo Crtica de Negcio o elemento de um processo de negcio considerado crtico para o negcio. Em qualquer
servio de TI, h um nmero de funes de negcio que podem ser suportadas e algumas so mais vitais que outras.
2.7 Segurana
Lida com confidencialidade, integridade e disponibilidade e dados associados.
2.8 Banco de Dados do Gerenciamento da Disponibilidade (BDD)
O banco de dados do Gerenciamento da Disponibilidade usado para registrar e armazenar informao necessria para o
suporte de atividades fundamentais, como produo de relatrios, anlise estatstica e previso de disponibilidade.
2.9 Janela de Servio
Usualmente se refere a um ponto de tempo especfico no qual o servio est disponvel, ou, de outra forma, o tempo possvel
para que uma manuteno seja realizada.
Atividade
- Determinar os requisitos de disponibilidade
- Desenhar atividade
- Guias para disponibilidade
- Guias para recuperao
- Consideraes de Segurana
- Gerenciamento de Manuteno
- Desenvolver planos de disponibilidade (5W2H)
- Medio e Reporte
3. Atividades
3.1 Determinar os Requisitos de Disponibilidade

25

A determinao dos requisitos de disponibilidade um processo interativo pois h a necessidade de equilibrar os requisitos
de Disponibilidade de negcio com os outros associados. Os passos necessrios so:
- Determinar o impacto de negcio causado pela perda de servio.
- A partir dos requisitos de negcio, especificar os requisitos para os componentes de TI, controlados por TI.
- Para componentes e Servios externos de TI, identificar os requisitos de fornecimento de servio.
- Estimar os custos envolvidos em atender requisitos.
- Determinar com o negcio se os custos envolvidos em atender os requisitos so justificveis.
- Determinar a partir do negcio os custos derivados de perda ou degradao do servio.
- Quando so vistos como custos justificveis, definir os requisitos em acordos/contratos.
3.2 Desenhar Atividades
3.2.1 Guias para Disponibilidade
Isso se refere ao design tcnico da Infra-estrutura de Ti e ao alinhamento necessrio de fornecedores internos e externos
para atender os requisitos de Disponibilidade para um Servio de TI.
3.2.2 Guias de Recuperao
Isso se refere aos pontos de design necessrios para garantir que, em caso de falha no Servio de TI, o servio possa ser
restaurado para possibilitar que a operao normal de negcios possa ser retomada o mais breve possvel.
3.3 Consideraes de Segurana
Durante o agrupamento dos requisitos de Disponibilidade para os novos Servios de TI, importante que os requisitos que
abrangem a segurana de TI sejam definidos. Esse requisitos necessitam ser aplicados durante a fase de design para a
Infra-estrutura de suporte de TI.
3.4 Gerenciamento de Manuteno
Todos os componentes de TI devem estar sujeitos a uma estratgia planejada de manuteno. A freqncia e nveis de
manuteno necessrios variam de componente para componente, conforme as tecnologias envolvidas, nvel crtico e
benefcios potenciais de negcio.
3.5 Desenvolver Planos de Disponibilidade
O Plano de Disponibilidade um dos principais produtos do Gerenciamento de Disponibilidade. um plano de longo prazo
que trata da disponibilidade durante os prximos anos. Em primeiro lugar, deve descrever a situao atual e, em estgio
posterior, pode ser ampliado para incluir atividade de melhoria para servios existentes e diretrizes bem como planos para
novos servios e diretrizes para manuteno.
3.6 Medio e Relatrios
Mensurao e relatrios so atividades importantes no Gerenciamento da Disponibilidade, pois fornecem a base para
verificar acordos de servio, resolver problemas e definir propostas de melhoria.
Entradas & Sadas
Desenho deve existir aqui !!!
Ciclo de Vida Expandido do Incidente
Desenho deve existir aqui !!!
Mtodos/Tcnicas e Clculo
- Anlise de Impacto em Falha de Componente (AIFC)
- Anlise de rvore de Falha (AAF)
- Anlise de Indisponibilidade de Sistema (AIS)
- Clculo de Disponibilidade
% Disponibilidade = Tempo no Ar / Tempo Acordado x 100%
4. Mtodos/Tcnicas e Clculos

26

4.1 Anlise de Impacto em Falha de Componente (AIFC)


Determine o ativos de configurao da Infra-estrutura de TI, crie uma grade (ICs em um eixo e Servios de TI que tm
Dependncia de um IC em outro eixo). Faa o seguinte em cada ponto de interseco:
- Deixe em branco quando a falha do IC no impacta o servio.
- Coloque um X quando a falha do IC deixa o servio sem funcionar.
- Coloque um A quando existe um IC alternativo para fornecer o servio.
- Coloque um B quando existe um IC alternativo, mas o servio deve ser recuperado primeiramente.
ICs que tm uma grande quantidade de Xs so crticos para muitos servios e podem causar grande impacto em caso de
falha do IC. Servios de TI que tm grande nmero de Xs so complexos e vulnerveis a falhas.
4.2 Anlise de rvore de Falha (AAF)
A Anlise de rvore de Falha (AAF) uma tcnica que pode ser usada para determinar a seqncia de eventos que causou
uma interrupo nos servios de TI. A AAF distingue os seguintes eventos:
- Eventos bsicos pontos terminais para a arvore de erros, por exemplo, falta de energia, erro do operador. Caso eventos
bsicos sejam analisados em profundidade, eles se tornam automaticamente eventos resultantes.
- Eventos resultantes ndulos intermedirios da rvore de erros, que resultam da combinao de eventos. O ponto principal
normalmente uma falha do Servio de TI.
- Eventos condicionais eventos que ocorrem somente sob determinadas condies, por exemplo, a falha de um
equipamento de ar condicionado.
- Eventos causadores eventos que disparam outros eventos, com, por exemplo, equipamento de deteco de falta d
energia, que pode disparar o desligamento automtico do Servio de TI.
4.3 Anlise de Indisponibilidade de Sistemas (AIS)
AIS uma tcnica desenhada para fornecer uma abordagem estruturada para identificar oportunidades de melhoria d
Disponibilidade, de ponta-a-ponta , que resultem em benefcios para o Usurio. Segue a abordagem estruturada para uma
atividade de (AIS):
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

Escolha a oportunidade
Delimite a atividade
Planeje a atividade
Desenvolva a hiptese
Analise de dados
Entreviste principais funcionrios
Descobertas e concluses
Recomendaes
Relatrios
Validao

4.4 Clculo de Disponibilidade


O Clculo Bsico de Disponibilidade foi demonstrado anteriormente, no entanto h dois clculos alternativos:
4.4.1 Configurao Simples de Infra-estrutura de TI (Simple IT Infrastructure Configuration).
Desenho deve existir aqui !!!
Disponibilidade vista a partir da estao de trabalho do Usurio calculada assim:
Disponibilidade = Host * Rede * Servidor * Estao de Trabalho
Clculo = 0.98 * 0.98 * 0.975 * 096 = 0.8989
Disponibilidade Total da Infra-estrutura = 89.89%

27

4.4.2 Configurao somples de TI com Componente de Resistncia.


Desenho deve existir aqui !!!
O componente de host tem um componente de backup para fornecer maior resistncia. A porcentagem da Disponibilidade do
componente de host agora recalculada assim:
Disponibilidade = 1 ((1-0.98)*(1-0.98)) = 0.9996
Disponibilidade do Host = 99,96%
Relaes com Gerenciamento da Disponibilidade
Desenho deve existir aqui !!!
Gerenciamento de Segurana
Objetivo
- Atender aos requerimentos de segurana do ANSs e outros requerimentos externos adicionais para contratos, legislao e
obrigaes.
- Prover um nvel bsico de segurana, independente de requerimentos externos.
1. Objetivo
O objetivo geral da segurana de TI obter uma segurana equilibrada em conformidade com controle justificveis
implementados para garantir a continuidade de servio de TI dentro de parmetros seguros.
H potencial para confuso entre os proprietrios de processo para o Gerenciamento de Segurana e Gerenciamento da
Disponibilidade em relao aos requisitos de segurana para novos servios de TI.
O Gerenciamento de Segurana pode ser visto como responsvel por garantir que haja conformidade com a poltica de
segurana na implementao de novos servios de TI. O Gerenciamento da Disponibilidade responsvel por garantir que
os requisitos de segurana sejam definidos e incorporados dentro do design geral de disponibilidade.
Definies
- Segurana
- Conscientizao de Segurana
- incidentes de Segurana
- Nvel de Segurana

- Seo de Segurana
- Confidencialidade
- Integridade
- Disponibilidade

2. Definies
2.1 Segurana
Proteger o valor da informao
2.2 Conscientizao de Segurana
Garantir que a organizao esteja consciente dos requisitos de segurana, atividade, impactos, etc. Normalmente se realiza
um projeto formal para aumentar a Conscincia de Segurana em pocas especficas do ano.
2.3 Incidentes de Segurana
Eventos que podem causar dano Confidencialidade, Integridade ou Disponibilidade da informao. Materializado como
acidentes ou atos propositais.
2.4 Nvel de Segurana
O grau de segurana aprovado dentro de um Acordo de Nvel de Servio, ou ordenado dentro de um Acordo de Nvel
Operacional ou Contrato de Apoio.

28

2.5 Seo de Segurana


Refere-se a uma seo de acordos e contratos em que requisitos especficos e detalhados de Segurana so includos.
2.6 Confidencialidade
Proteger informao contra acesso e uso no-autorizado.
2.7 Integridade
Proteger a exatido, integridade e a adequao da informao.
2.8 Disponibilidade
A informao acessvel em qualquer horrio acordado.
Atividades
Desenho deve existir aqui !!!
3. Atividades
3.1 Atividades
3.1 Controlar poltica de Segurana da Informao e Organizao
A atividade de Controle o primeiro subprocesso do Gerenciamento de Segurana e se relaciona organizao e gesto do
processo. Essa atividade define os subprocessos, funes de segurana, papis e responsabilidades. Tambm descreve a
estrutura organizacional, providncias de relatrios e linha de controle.
3.2 Planejar
Inclui a definicao da seo de segurana do ANS em consulta com o GNS e as atividade nos UCs relacionadas
segurana. Esse subprocesso no apenas recebe dados do ANS, mas tambm dos princpios de poltica do provedor de
servios.
3.3 implementar
Tem o objetivo de implementar todas as medidas especificadas nos planos. rea que devem ser consideradas durante esse
subprocesso:
1.
2.
3.
4.

Classificao e Gerenciamento dos recursos de TI.


Segurana de funcionrios.
Segurana de Gerenciamento.
Controle de acesso.

3.4 Avaliar
A avaliao independentemente da implementao de medidas planejadas fundamental.
- Auto-avaliaes: principalmente implementadas por grupos operacionais de segurana.
- Auditorias internas: realizadas por auditores internos de TI.
- Auditorias externas: realizadas por auditores externos de TI.
Avaliaes tambm so realizadas em resposta a incidentes de segurana:
- Verificar conformidade com a poltica de segurana.
- Realizar auditorias de segurana nos sistema de TI.
- Identificar e responder ao uso no-adequado dos recursos de TI.
- Adotar aspectos de segurana de outras auditorias.
3.5 Manter

29

A manuteno realizada com base nos resultados do subprocesso de Avaliao e na avaliao de mudanas nos riscos. As
propostas podem ser introduzidas tanto no subprocesso de Planejamento como includas na manuteno do ANS como um
todo. As propostas podem resultar na incluso de atividades no plano anual de segurana.
3.6 Reportar
Relatar no um subprocesso, mas o resultado dos outros subprocessos. Os relatrios so produzidos para fornecer
informao sobre o desempenho de segurana alcanado e para informar os clientes sobre questes de segurana. Esses
relatrios normalmente so solicitados sob acordo com o cliente.
Consideraes de Segurana
- Depois da Falha: garantir que no houve comprometimento da confidencialidade e integridade nem comprometimento
posterior da disponibilidade de servio.
- Acesso Fsico ao computador e rede deve ser restrito somente ao pessoal autorizado.
- ANOs e CAs devem demonstrar adeso aos controle de segurana exigidos pela organizao de suporte de TI.
Gerenciamento de Capacidade
Objetivo
- Garantir que todos os aspectos de capacidade e de desempenho, atuais e futuros, dos requisitos de negcio sejam
atendidos de maneira rentvel.
1. Objetivo
Custo versus Capacidade
Assegurar que a capacidade de processamento adquirida no justificada somente em termos de necessidade de negcio,
mas tambm do mais eficiente uso desses recursos.
Oferta versus Demanda
Assegurar que a oferta disponvel de poder de processamento combina com a demanda solicitada pelo negcio, tanto agora
como no futuro. Pode ser necessrio tambm gerenciar ou influenciar a procura por um recurso especfico.
O Gerenciamento de Capacidade necessita compreender os requisitos de negcio (a entrega de servio requerida), a
operao da organizao (a entrega de servio atual) e a infra-estrutura de TI (os meios de entrega de servio). Utilizar essa
informao de maneira efetiva garante que todos os aspectos de capacidade e de desempenho dos requisitos e negcio,
atuais e futuros, sejam atendidos de maneira rentvel.
O Gerenciamento da Capacidade significa tambm compreender o potencial para a entrega de servio. A nova tecnologia
necessita ser compreendida e, se for adequada, utilizada para entregar os servios solicitados pelo negcio. O
Gerenciamento da Capacidade necessita reconhecer que a velocidade da mudana tecnolgica tende a continuar em seu
ritmo atual, ou at mais rpida.
Definies
Gerenciamento da Capacidade do Negcio
- Responsvel em garantir que as necessidade futuras de negcio para servios de TI sejam consideradas, planejadas e
implementadas de maneira oportuna.
Gerenciamento da Capacidade de Servio
- O gerenciamento do desempenho dos servios de TI no ar e operacionais usados pelos clientes.
Gerenciamento da Capacidade dos Recursos
- O gerenciamento dos componentes individuais da infra-estrutura de TI.

30

2. Definies
2.1 Gerenciamento da Capacidade do Negcio
Um objetivo fundamental deste subprocesso garantir que as futuras necessidades quanto a servios de TI sejam levadas
em conta e compreendidas, e que suficiente capacidade para suportar os servios seja planejada e implementada em uma
escalada de tempo apropriada. Embora o processo de Gerenciamento da Capacidade deva atender aos requisitos que
constantemente mudam para a capacidade de processamento, ele deve ser pr-ativo/preditivo ao invs de reativo.
Novos requisitos podem ser apresentados ao Gerenciamento da Capacidade vindos e muitas fontes diferentes e por muitas
razes diferentes. Eles podem ser produzidos pelo negcio ou podem se originar do prprio processo de Gerenciamento da
Capacidade. Como exemplo, pode ser a recomendao de fazer um upgrade para aproveitar a nova tecnologia, ou a
implementao de uma atividade de sintonia fina para resolver um problema de desempenho.
O Gerenciamento da Capacidade no deve ser um X de ltima hora no quadrinho antes da aceitao de operaes e da
aceitao do cliente.
2.2 Gerenciamento de Capacidade do Servio
Um objetivo fundamental do subprocesso do Gerenciamento da Capacidade do Servio identificar e entender os servios
de TI, a utilizao de seus recursos, padres de trabalho, picos e ociosidades, e garantir que os servios possam e cumpram
as metas do ANS. Portanto, o foco em gerenciar o desempenho de servio, conforme determinado pelas metas contidas
nos ANSs.
Quanto as necessidades de negcio para um servio passaram pelo subprocesso de Gerenciamento da Capacidade de
Negcio e o servio se tornou operacional, ento o subprocesso de Gerenciamento da Disponibilidade do Servio se torna
responsvel em assegurar que o servio atende as metas aprovadas de servio. O servio monitorado fornece dados que
podem identificar tendncias, a partir das quais se estabelecem os nveis normais de exceo podem ser definidas,
identificadas e colocadas em relatrios. Assim, o Gerenciamento da Capacidade informa o Gerenciamento do Nvel de
Servio (GNS) qualquer brecha no servio ou um quase erro.
2.3 Gerenciamento da Capacidade dos Recursos
Um objetivo fundamental deste subprocesso identificar e entender a capacidade e a utilizao das partes de cada
componente da infra-estrutura de TI. Isso garante o uso ideal dos recursos atuais de hardware e de software a fim de atingir
e manter os nveis de servio aprovados. Esse subprocesso tambm se mantm atento a novas tecnologias.
Atividades
Desenho deve existir aqui !!!
3. Atividades
Contnuas:
Atividade Repetitivas, Gerenciamento de demanda e Armazenamento de dados no BDC.
Circunstanciais:
Modelagem e Dimensionamento de Aplicao.
Regularmente: Produo do Plano de Capacidade.
Atividades Repetitivas
Atividades Repetitivas so conduzidas ao se realizar qualque um dos
subprocessos de Gerenciamento da Capacidade. As Atividades Repetitivas
consistem em:
- Monitorao: utilizao de cada recurso e servio.
- Anlise: identificar tendncias, etc.
- Sintonia: tcnicas incluem equilbrio de carga de trabalho e/ou trfego de disco.
- Implementao: introduo de quaisquer mudanas identificadas por Monitorao, Anlise e sintonia.
3.2 Gerenciamento da Demanda

31

O objetivo do Gerenciamento da Demanda influenciar a demanda e o uso de um recurso de informtica. Normalmente se


realiza em curto prazo porque h capacidade insuficiente, mas pode ser utilizado em longo prazo, quando difcil justificar
um upgrade caro.
3.3 Modelagem
O propsito da modelagem prever o comportamento dos servios de TI, sob determinado volume e variedade de trabalho.
Os diferentes tipos de modelagem vo desde a preparao de oramentos baseados na experincia at benchmarking de
escala completa. O primeiro barato, embora no seja to exato, ao passo que o ultimo caro e mais exato pode ser
aconselhvel para um projeto novo e grande.
3.4 Dimensionamento da Aplicao
O objetivo inicial estimar os requerimentos de recursos necessrios para suportar uma proposta de mudana de aplicativo,
e garantir que isso atenda aos nveis de servio exigido. A dimenso de aplicativo tem um perodo de vida finito. Comea no
estgio de iniciao para um novo aplicativo ou quando h uma grande mudana de um aplicativo existente e se completa
quando o aplicativo aceito dentro do ambiente operacional.
3.5 Armazenamento dos Dados de Gerenciamento da Capacidade
O Banco de dados do Gerenciamento da Capacidade (BGC) fundamental para o sucesso do processo de Gerenciamento
da Capacidade. Deve ser tido com um repositrio de todos os dados utilizados produzidos e utilizados por todos os
subprocessos do processo de Gerenciamento da Capacidade.
3.6 Produo do Plano de Capacidade
O plano de capacidade documenta os nveis atuais de utilizao de recursos e desempenho de servio. Depois de considerar
os planos e a estratgia de negocio, tambm prev os futuros requisitos de recursos para suportar os Servios de TI que
suportam as atividades de negcio. O plano deve indicar claramente qualquer pressuposio feita. Tambm deve incluir
recomendaes quantificadas em termos de recurso solicitado, custo, benefcios, impacto, etc.
Entradas & Sadas
Desenho deve existir aqui !!!
Relaes com Gerenciamento da Capacidade
Desenho deve existir aqui !!!
Gerenciamento da Continuidade dos Servios de TI
Objetivo
- Suportar o processo global de Gerenciamento da Continuidade de Negcios, garantindo que os servios e facilidades de Ti
podem ser recuperados dentro das janelas de tempo requeridas e acordadas com o negcio.
1. Objetivo
Apoiar o processo geral do Gerenciamento da Continuidade do Negcio por meio da garantia de que as condies de servio
e as condies tcnicas de TI necessrias (incluindo sistemas de computadores, redes, aplicativos, telecomunicaes,
suporte tcnico e servio) sejam recuperadas dentro das escalas de tempo de negcio solicitadas e aprovadas.
GCN & GCSTI
- O Gerenciamento da Continuidade do Negcio (GCN) se preocupa com o Gerenciamento da Continuidade de Negcio que
incorpora todos os servios dos quais o negcio depende, entre eles TI.
- O Gerenciamento da Continuidade dos Servios em TI (GCSTI) est focado na continuidade dos servios de TI para o
negcio.
- As organizaes exigem que o GCSTI se torne parte integral do gerenciamento corporativo para que objetivos de negcio e
metas sejam alcanados e mantidos.

32

2. Definies GCN & GCSTI


2.1 Gerenciamento da Continuidade do Negcio (GCN)
O Gerenciamento da Continuidade do Negcio (GCN) se preocupa com a gesto de riscos para garantir que a organizao
possa continuar operando em um nvel mnimo, pr-determinado. O Processo GCN envolve a reduo do risco a um nvel
aceitvel e o planejamento da recuperao dos processos de negcio em caso de materializao de risco e interrupo do
negcio.
2.3 Gerenciamento da Continuidade dos Servios em TI (GCSTI)
O Gerenciamento da Continuidade dos Servios em TI (GCSTI) parte do processo geral do Gerenciamento da
Continuidade do Negcio (GCN) e depende de informao derivada desse processo.
O Gerenciamento da Continuidade dos Servios em TI (GCSTI) deve ser parte do processo geral do Gerenciamento da
Continuidade do Negcio (GCN) e depende de informao derivada desse processo. O GCSTI est focado na Continuidade
dos servios de TI para o negcio. O GCN se preocupa com o Gerenciamento da Continuidade do Negcio que incorpora
todos os servios dos quais o negcio depende, um dos quais TI.
H a necessidade de que requisitos mnimos de negcio sejam determinados em certo nvel de detalhamento e aprovados
entre o negcio e os provedores de Servio de TI (interno ou externo) antes que o escopo do GCSTI seja definido. Esses
requisitos podem definir a necessidade de estabelecer uma transferncia imediata do servio para um site alternativo ou um
requisito de recuperar elementos do servio durante um perodo de tempo mais longo (por exemplo, uma semana).
fundamental que esse pr-requisitos sejam plenamente compreendidos, definidos e aprovados pelo negcio como parte do
processo GCN para garantir que o GCSTI seja especificamente usado da maneira mais efetiva e eficiente para cumprir a
parte de TI desses requisitos.
Definies
- Desastre
- gerenciamento de Crise
- Planejamento de Recuperao de Desastres
- Anlise de Risco e Mtodo de Gerenciamento do CCTA(*)
- Opes de Recuperao
(*) CCTA Risk Analysis ans Management Method (CRAMM)
3. Definies Contra-Medidas
3.1 Desastre (Disaster)
Um evento que afeta um servio ou sistema de tal maneira que exige esforo significativo para restaur-lo ao nvel original de
desempenho.
3.2 Gerenciamento de Crise
O processo pelo qual uma organizao gerencia o impacto maior de um desastre, como a cobertura negativa da imprensa.
3.3 Planejamento de Recuperao de Desastres
Uma srie de processos focados unicamente nos processos de recuperao, especialmente em resposta a desastres fsicos
que esto contidos dentro do GCN.
3.4 Anlise de Risco de Gerenciamento do CCTA (*)
CRAMM descreve um meio de identificar contramedidas justificveis para proteger a Confidencialidade, Integridade e
Disponibilidade da Infra-estrutura de TI. Os conceitos gerais so representados por um simples diagrama que mostra a
Anlise de Risco e a Gesto de Risco como duas atividades relacionadas, porm separadas.
(*) CCTA Risk Analisys & Management Method - CRAMM
Desenho deve existir aqui !!!

33

A Anlise de Risco envolve a identificao e avaliao do nvel (medida) dos riscos calculados a partir dos valores avaliados
dos ativos e dos nveis avaliados de ameaas a esses ativos e vulnerabilidade desses ativos. A Gesto de Risco envolve a
identificao, seleo e adoo de contramedidas justificadas pelos riscos identificados aos ativos em termos de impacto
potencial sobre servios caso ocorra uma falha e a reduo desses riscos a um nvel aceitvel.
3.5 Opes de Recuperao
- No faa nada. (Do nothing)
- Soluo Provisria Manual
- Providncias Recprocas

- Recuperao Gradual (Cold Standby)


- Recuperao Intermediria (Warm Standby)
- Recuperao Imediata (Hot Standby)

Atividades
Desenho deve existir aqui !!!
4. Atividades
Estgio 1: Iniciao
4.1 Iniciar o Gerenciamento da Continuidade do Negcio (GCN)
A iniciao cobre a organizao como um todo e consiste em cada um dos itens a seguir:
- Determinar a Poltica
- Determinar os Termos de Referncia e o Escopo
- Alocao de Recursos
- Definir Estrutura de Organizao e Controle do Projeto
- Aprovar o Projeto e os Planos de Qualidade
Estgio 2: Requisitos e Estratgia
4.2 Requisitos e Estratgia
Esse estgio fornece a base para o GCSTI e crtica para determinar quo bem uma organizao sobreviver uma
interrupo de negcio ou desastre e os custos que podem existir.
4.2.1 Anlise de Impacto no Negcio
Um fator fundamental para definir os requisitos de GCSTI saber quanto organizao tem a perder como resultado de um
desastre ou outra interrupo no servio e a velocidade da escalada dessas perdas. O propsito de uma anlise de impacto
no negcio (AIN) fazer essa avaliao por meio da:
- Identificao de processos crticos de negcio, o dano ou a perda potencial que pode ser causada a organizao como
resultado de uma interrupo dos processos crticos de negcio.
- O impacto medido em comparao a vrios cenrios e normalmente cai em uma ou mais das seguintes categorias
defeito em alcanar os nveis de servio aprovados internamente, perdas financeiras, custos adicionais, perda imediata e de
longo prazo do market share, etc.
4.2.2 Avaliao de Risco
O segundo fator para determinar os requisitos de GCSTI a probabilidade de que um desastre ou uma interrupo grave de
servio vai ocorrer. Isso significa uma avaliao do nvel de ameaa e at que ponto uma organizao est vulnervel a essa
ameaa.
4.2.3 Estratgia da Continuidade do Negcio
A informao extrada da anlise de impacto e da avaliao de risco, alm dos mecanismos de GCSTI associados, oferece
uma estratgia adequada para que a organizao se desenvolva com um equilbrio ideal de reduo de risco e recuperao
ou opes de Continuidade. Isso inclui a considerao das prioridades relativas de recuperao de servio e as mudanas
na prioridade relativa de servio para o horrio do dia, dia da semana e variaes mensais e anuais.
Estgio 3: Implementao

34

4.3 Implementao
4.3.1 Organizao e Planejamento da Implementao
O planejamento da implementao critico para o processo de implementao e sem planos factveis, o processo falhar.
4.3.2 Implementao de Acordos em Reserva (Standby)
importante lembrar que a recuperao baseada ao redor de uma sria de acordos em reserva (standby), incluindo
acomodao bem como sistemas e telecomunicaes. Determinadas aes so necessrias para implementar os acordos
em reserva, como:
- Contratar instalaes de recuperao terceirizadas
- Preparar e equipar acomodaes de reserva
- Comprar e instalar sistemas reserva de computadores
- Negociar com fornecedores externos de servio sobre seus planos de GCSTI
4.3.3 Desenvolvimento de Planos de Recuperao
Os planos de GCSTI necessitam ser desenvolvidos para fornecer a informao necessria a fim de que sistemas crticos,
servios e instalaes continuem a ser fornecidos ou sejam restaurados dentro de um perodo aceitvel para o negcio.
4.3.4 Implementao de Medidas de Reduo de Risco
Arquivamento e armazenamento offsite; estrutura de dados RAID e espelhamento de disco para servidores de LAN para
prevenir perda de dados e garantir disponibilidade contnua de dados; sistemas tolerantes de defeito devem ser
implementados para aplicaes crticas em que mesmo um tempo mnimo fora do ar inaceitvel.
4.3.5 Desenvolvimento de Procedimentos
Necessitam ser desenvolvidos procedimentos que incluam:
- Instalao e teste de redes e hardware de reposio
- Restaurao de software e dados para um ponto de referncia consistente e comum.
- Fusos horrios diferentes em uma organizao multinacional e pontos de corte de negcio.
4.3.6 Teste Inicial
Um teste completo precisa replicar a invocao de todos os preparativos de reserva, incluindo a recuperao de processos
de negcio e o envolvimento de grupos externos. Isso testa a integridade dos planos e confirma os objetivos de prazo, a
resposta, estado de alerta a preparao da equipe.
Estgio 4: Gerenciamento Operacional
4.3 Gerenciamento Operacional
4.4.1 Educao e Conscientizao
Deve abranger a organizao e, em particular, a organizao de TI, para itens especficos de continuidade de servio. Isso
garante que todo o pessoal esteja consciente das implicaes da continuidade de negcio e da continuidade de servio e as
considerem como parte de sua rotina normal de trabalho e de seu oramento.
4.4.2 Reviso e Auditoria
Necessita ser realizada a reviso regular de todos os entregveis do processo de GCSTI para garantir que eles permaneam
atualizados. Em relao a TI, isso necessrio sempre que houver uma grande mudana na infra-estrutura de TI, ativos ou
dependncias, tais como novos sistemas ou redes ou uma mudana nos provedores de servio. Isso inclui os casos em que
h mudanas no rumo do negcio, na estratgia do negcio ou na estratgia de TI. Como as organizaes normalmente
mudam rapidamente, necessrio investir em um programa de reviso contnua e incorporar o GCSTI aos processos
organizacionais de justificativa de negcio. Novos requisitos sero implementados em conformidade com o processo de
controle de mudanas.

35

4.4.3 Teste
Depois do teste inicial, necessrio estabelecer um programa de testes regulares para garantir que os componentes crticos
da estratgia so testados pelo menos anualmente ou conforme orientao da Gerencia Executiva ou da auditoria.
importante que quaisquer mudanas na infra-estrutura de TI sejam includas na estratgia, implementadas de modo
adequado e testadas para garantir o funcionamento correto dentro da proviso geral dos servios de TI.
4.4.4 Gerenciamento de Mudanas
O GCSTI deve ser includo como parte do processo de gerenciamento de mudanas para garantir que quaisquer mudanas
na infra-estrutura sejam refletidas nos panos de contingncia fornecidos por TI ou por terceiros. Planos inadequados e
capacidades de recuperao inadequadas podem resultar no defeito da GCSTI.
4.4.5 Treinamento
A TI pode estar desenvolvida em treinar os integrantes da equipe de recuperao de negcio que no sejam da rea de TI
para garantir que eles tenham o nvel necessrio de competncia para facilitar a recuperao.
4.4.6 Garantia
Obter a garantia de que a qualidade dos entregveis da GCSTI aceitvel Gerncia Executiva de negcio e que os
processos de gerenciamento operacional esto funcionando satisfatoriamente.
Invocao do Plano de Contingncia
A deciso de invocar necessita levar em conta um nmero de fatores:
- A extenso do dano e o escopo da interrupo.
- A extenso provvel da interrupo e a indisponibilidade de instalaes e/ou servios.
- O horrio do dia/ms/ano e o impacto potencial no negcio. No final do ano, a necessidade de invocar pode ser maior para
garantir que o processamento de fim de ano seja completado dentro do prazo.
- Requisitos especficos do negcio dependendo do trabalho que est sendo realizado no momento.
5. Invocao
Esta deciso normalmente feita por uma equipe de gerenciamento de crise formada por executivos do negcio e
departamentos de suporte (incluindo TI), utilizando informao vinda da avaliao de dano e de outras fontes.
O plano de GCSTI deve incluir detalhes das atividades que necessitam ser realizadas, incluindo:
- Recuperao de fitas de backup ou uso de cofre de dados para recuperar dados.
- Recuperao de documentao essencial, procedimentos, imagens de workstation, etc, armazenadas off-site.
- Mobilizao de pessoal tcnico apropriado.
- Entrar em contato e deixar em alerta fornecedores de telecomunicaes, servios de suporte, distribuidores de aplicativos,
etc.
Ao longo da recuperao inicial, importante que todas as atividades sejam registradas. fundamental para garantir que a
segurana da informao e os mecanismos e controles de proteo de dados so mantidos e executados durante a
invocao, recuperao e retorno aos estgios normais da Continuidade de Servio.
Uma vez que a recuperao tenha sido concluda, o negcio deve ter condies de operar a partir do site de recuperao no
nvel determinado e aprovado na estratgia de Continuidade de Negcio. No entanto, o objetivo conduzir o negcio aos
nveis normais e desocupar o site de recuperao o mais breve possvel. importante que isso seja bem gerenciado e que
todo o pessoal envolvido esteja consciente de suas responsabilidades para garantir uma transio tranqila.
O Modelo de Entrega de Servios
Desenho deve existir aqui !!!

36