fundamentos itil portugues brasil br completo

8/6/2019 Fundamentos ITIL Portugues Brasil BR Completo

1/54


2/54

Last Update 0.9 | 2006/07/18Objetivo do Treinamento e Programa

Oferecer compreenso bsica (teoria e conceitos) dos componentes de

Suporte a Servios e entrega de Servios de ITILPreparar os participantes para uma avaliao (exame) de mltipla escolha, com40 questes e 1 hora de durao (se aplicvel), para obteno da Certificaoem 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 prticasfocadas no Gerenciamento de Servios de TI.- Promove uma abordagem de qualidade para alcanar efetividade de negciona utilizao de sistemas de informao.

Gerenciamento de Servios de TI- Focado na entrega e suporte de servios em TI que sejam adequados aosrequisitos de negcio da organizao.

Coleo de Livros ITILPlanejamento para Implementar Gerenciamento de ServiosA Perspectiva de NegcioGerenciamento de AplicaesGerenciamento de ServiosEntrega de Servios

Suporte a ServiosGerenciamento de SeguranaGerenciamento 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.

2


3/54

* 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

3


4/54


5/54

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. OsICs 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 desrie, nmero de verso, proprietrio, etc.)

2.4 AtivosRecursos de negcios.* Ex.: Mais de R$ 1.000,00 ativo* Cadeira no ativo, mas a mesa sim.

2.5 Gesto de AtivosUm processo Contbil para monitorar a depreciao de ativos cujo preo

de compra ultrapassa um limite definido.

2.6 RelacionamentosDescrio 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 deConfigurao (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 daConfigurao 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, quecaptura tanto a estrutura como os detalhes daquele produto ou sistema epermite que aquele produto ou sistema seja reconstrudo em uma dataposterior.

Exemplos de ICs de Hardware

Desenho deve existir aqui !!!

5


6/54

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 deConfigurao da infra-estrutura, seus proprietrios, seus inter-relacionamentose documentao de configurao, Incluem a alocao de identificadores paraos Itens de Configurao, suas verses e documentao.

3.3 Controle

Garantia de que somente ICs autorizadas e identificveis sero aceitas eregistradas desde o recebimento at o descarte.

3.4 Informao de StatusRelatrio de todos os dados atuais e histricos relacionados a cada IC durantetodo seu ciclo de vida. Permite que mudanas nos Itens de Configurao eseus registros sejam rastreados, isto : rastrear o status de um IC de um statusa outro desenvolvimento, teste, produo, retirada.

3.5 Verificao e Auditoria

Qualidade da configurao controlada por meio de uma srie de revises eauditoria que verificam a existncia fsica dos Itens de Configurao e se esto

registrados corretamente no sistema de Gerenciamento da Configurao.

6


7/54


8/54

O objetivo principal gerenciar, coordenar e resolver Incidentes o mais brevepossvel, bem como garantir que nenhuma solicitao se perca, seja esquecidaou ignorada. Links com o Gerenciamento de Configurao e ferramentas deconhecimento 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 umaabordagem com foco mais global, possibilitando que os processos de negciosejam integrados infra-estrutura de Gerenciamento de Servio. No lidaapenas com Incidentes, Problemas e questes, mas tambm fornece umainterface para as outras atividades, como solicitaes de Mudanas de clientes,contratos de manuteno, licenas de software, Gerenciamento de Nvel deServio, Gerenciamento de Configurao, Gerenciamento de Disponibilidade,Gerenciamento Financeiro para Servios de TI e Gerenciamento deContinuidade 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 rpidarestaurao da proviso normal do servio. Tipicamente , a funo da Centralde Servios (Service Desk) era usada mais como barreira que comocapacitadora, mas atualmente normalmente se dedica com o atendimento docliente.

2.5 Central de Servios No-Habilitada (Regina)

As ligaes so registradas, descritas em termos gerais e imediatamenteencaminhadas.

2.6 Central de Servios HabilitadaUtilizando solues documentadas, esta Central de Servios (Service Desk)pode resolver muitas situaes de indisponibilidade, ao mesmo tempo em querelatrios de indisponibilidade so encaminhados para equipes de suporte.

2.7 Service Desk Especialista

Esta Central de Servios (Service Desk) tem conhecimento especializado detoda a infra-estrutura de TI e know-how para resolver a maioria dos incidentesde maneira autnoma.

Modelos de Centrais de Servio (Service Desk)

- Central de Servios Local Tipicamente as organizaes criaram suportelocal para atender necessidades de negcios locais, atendendo chamados deusurios de unidade local.

8


9/54

- Central de Servios Centralizada Uma unidade fsica central que recebechamados de usurios de vrias localidades.

- Central de Servios Virtual Pode estar localizada e ser acessada emqualquer ponto do mundo.

Central de Servios LocalDesenho deve existir aqui!!!

Central de Servios CentralizadaDesenho deve existir aqui!!!

Central de Servios VirtualDesenho 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 possafaz-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 oimpacto contrrio nas operaes de negcio.

1 Objetivo

O Objetivo do Gerenciamento de Incidentes assegurar que nveis de serviode alta qualidade sejam mantidos e que a disponibilidade do servio atendaaos requisitos do cliente.

Operao normal de servio definida como a operao de servio efetiva eeficiente dentro dos limites de Acordo de Nvel de Servios (ANS) ou dasexpectativas do usurio.

Definio

9


10/54

- Incidente- Qualquer evento que no faa parte da operao padro de um servio

e que causa, ou possa causar, uma interrupo, ou reduo, na qualidadedaquele servio.

- Requisio de Servio- Uma categoria de incidente que inclui, por exemplo, um pedido deinformao 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, umevento registrado automaticamente (por exemplo, exceder a capacidade de usode disco) normalmente considerado como parte da operao normal. Esseseventos so includos na definio de incidentes, embora os servios deentrega clientes/usurios no sejam afetados. So simplesmenteconsiderados como sinais de que, a longo prazo, o disco necessitar ser substitudo por um item de maior capacidade. Naturalmente, com o tempo, oprocesso 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 contatopessoal. O servio pode ser grandemente aumentado e ampliado para ocliente, usurios e equipe de suporte por meio da expanso dos mtodos deregistro, atualizao e solicitao de consulta. Isso pode ser alcanadobasicamente por meio de e-mail e internet/intranet para escritrios remotos,

embora o fax tambm possa ser uma ferramenta til. Esses mtodos somelhores 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:

10


11/54

- 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 terceirosnecessitam levar em consideraes o ciclo de vida completo da solicitao e otempo despendido em cada fase. Para uma anlise detalhada, a equipe desuporte deve registrar o tempo que gastou trabalhando em uma solicitao ouem qualquer parte dela. Por exemplo, uma solicitao pode ser aberta efechada pela Central de Servios (Service Desk). No entanto, durando seu ciclode vida, pessoas de outras equipes de suporte podem ter passado tempotrabalhando na solicitao. Portanto, o tempo decorrido de cada pessoa e otempo real gasto necessitam ser contabilizados e colocados no relatrio.

PrioridadeDesenho deve existir aqui!!!

EscalaoDesenho deve existir aqui!!!

3. Definies

3.1 PrioridadePrioridade definida como a seqncia em que um incidente, problema, oumudana necessita ser resolvido, baseado no impacto sobre o negcio e aurgncia.

3.2 ImpactoO 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 UrgnciaA velocidade com que os incidentes devem ser resolvidos.

3.4 Esforo EsperadoA quantidade antecipada de recurso, tempo e custo necessrio para restaurar oservio depois da ocorrncia de um Incidente.

4. EscaladaEscalada o mecanismo que oferece a resoluo adequada de um incidente.

Pode ocorrer durante qualquer atividade durante o processo de resoluo.

11


12/54

4.1 FuncionalTransferir um incidente do grupo de suporte de primeiro nvel para o desegundo nvel ou mais adiante, chamado de escalada funcional. A escaladafuncional basicamente ocorre por falta de conhecimento ou expertise. Aescalada funcional tambm pode ocorrer quando expiram os intervalos de

tempo acordados. A escalada funcional automtica, baseada em intervalos detempo, deve ser planejada cuidadosamente e no deve exceder os tempos deresoluo acordados no ANS.

Inclui todos os nveis (ou faixas) de servio 1, 2, 3,..., N., incluindofornecedores terceirizados.

4.2 HierrquicoEscalada hierrquica pode ocorrer em qualquer momento durante o processode resoluo quando h a probabilidade de que o incidente no seja resolvidodentro do prazo ou satisfatoriamente. Escalada hierrquica automtica podeser considerada depois de um determinado intervalo critico de tempo, quando provvel que uma resoluo adequada v falhar. Isso deve ocorrer antes queseja excedido o tempo do ANS para que aes corretivas possam ser tomadassem o descumprimento do ANS.

AtividadesDesenho 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 decontorno ou escalada.

5.4 Resoluo e Recuperao

12


13/54

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

5.6 Propriedade, Monitorao, Acompanhamento e Comunicao.

PropriedadeO Suporte tem a propriedade do incidente e gerencia at que seja resolvido deacordo com a satisfao do cliente.

Monitorao e AcompanhamentoO Suporte monitora regularmente o status e o andamento em direo soluoe em comparao com os nveis de servio de todos os incidentes abertos.

Comunicao responsabilidade do Suporte, operando dentro do processo deGerenciamento de Incidente, realizar toda a comunicao referente aosincidentes entre a rea de TI e o cliente.

Integrao do Processo de Gerenciamento de IncidentesDesenho deve existir aqui!!!

6. Integrao do Processo de Gerenciamento de Incidentes

Os incidentes entram nos processos vindos de muitas reas, comoGerenciamento de Rede, a partir de usurios via Suporte e/ou das Operaesde Computador.

Deve haver uma interface prxima entre os processos de Gerenciamento deIncidentes, Gerenciamento de Problemas e Gerenciamento de Mudanas bemcomo a funo de Suporte.

Se no so controladas adequadamente, as mudanas podem trazer novosincidentes. Necessita-se de um meio de rastreamento. Portanto, recomenda-seque os registros de incidente permaneam no mesmo Banco de Dados doGerenciamento de Configurao (BDGC) dos problemas, erros conhecidos eregistros de mudana, ou a menos com uma ligao para no precisar seautenticar novamente a fim de melhorar as interfaces e facilitar consultas erelatrios.

Suporte de Primeiro, Segundo e Terceiro Nveis

Desenho deve existir aqui!!!

13


14/54

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 desegundo nvel- Fechamento de Incidentes

Suporte de segundo nvel (grupos especialistas que podem fazer parte doSuporte) 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 aequipe de Gerenciamento de Problemas para que eles faam o registro doProblema.- Resoluo e recuperao dos Incidentes que lhes foram encaminhados.

Suporte de terceiro nvel (grupos de especialistas que podem apoiar o suportede segundo nvel) estar envolvido em tarefas como:

- Pesquisa e diagnostico de Incidentes (incluindo resoluo quando possvel).- Deteco de possveis Problemas e respectivo encaminhamento para aequipe de Gerenciamento de Problemas para que eles faam o registro doProblema.- Resoluo e recuperao dos Incidentes que lhes foram encaminhados.

Gerenciamento de Problemas

Objetivo

- O Objetivo do Gerenciamento de Problemas minimizar o impacto deIncidentes 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. Oaspecto reativo est relacionado com a resoluo de problemas em resposta aum ou mais incidentes. O Gerenciamento de Problemas pr-ativo tem a ver com a identificao e soluo de problemas e erros conhecidos antes que osincidentes ocorram.

14


15/54


16/54

de uma mudana sob controle do processo de Gerenciamento de Mudanas. OObjetivo estar atento aos erros, monitor-los e elimin-los quando seja vivele justifique os custos.

3.2 Gerenciamento Pr-Ativo de Problemas

- Anlise de tendncias.- Foco em ao preventiva- Importantes revises de problemas.

De Incidente Para ProblemaPara Erro Para MudanaDesenho deve existir aqui!!!

4. Relao entre Incidente, Problema e Gerenciamento de Mudanas.

Deve haver uma interface prxima entre os processos de Gerenciamento deIncidentes, Gerenciamento de Problemas e Gerenciamento de Mudanas bemcomo a funo de Suporte. Se no so controladas adequadamente, asmudanas podem trazer novos incidentes. Os registros de incidente devempermanecer no mesmo BDGC dos problemas, erros conhecidos e registro demudana. Ou a menos com uma ligao para no precisar se autenticar novamente. O Gerenciamento de problemas exige o registro exato e detalhadodos incidentes para identificar, efetiva e eficientemente, a causa dos incidentese 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 seencontra o IC que causou o erro, o problema se torna um erro conhecido. Umerro conhecido removido por meio de uma mudana e o Gerenciamento deProblemas assegura-se de que uma RM seja enviada ao Gerenciamento deMudanas.

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 oimpacto de incidentes relacionados a mudanas e melhorar as operaes dodia-a-dia.(Gerenciamento de Mudana no faz a mudana, mas avalia).

1. Objetivo

Um nmero alto de mudanas no indica necessariamente algum tipo deproblema com o sistema de Gerenciamento de Mudanas. Pode simplesmente

16


17/54

refletir um sistema voltil e qualquer tentativa de reduzir o nmero deRequisies de Mudanas (RM) pode sufocar a inovao. No entanto, umGerenciamento de Mudanas eficiente e efetivo deve mostrar claramente queh menos incidentes relacionados a mudanas que antes da implementao doprocesso.

A qualidade do servio em geral ser melhorada como resultado da reduo deincidentes relacionados a mudanas.

de fundamental importncia que os processos de Gerenciamento deMudanas 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) eMudanas 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 MenoresO Gerente de Mudanas aprova Mudanas Menores que so caracterizadaspor causar pequeno impacto. Necessitam-se poucos recursos deDesenvolvimento 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 doNegcio) com autoridade de deciso para Mudanas Significativas. AsMudanas Significativas so caracterizadas como tendo impacto considervel

ou complexo e/ou necessidades de recursos de desenvolvimento ou runtime .

17


18/54


19/54

avaliao adequada e/ou se as mudanas esto alinhadas aos objetivos daorganizao. As RMs rejeitadas so devolvidas ao originador com explicaessobre a rejeio.

3.2 Alocao de Prioridade

O Gerente de Mudanas deve ser responsvel em alocar prioridades. Aprioridade da RM deve ser decidida em colaborao com o solicitante e, senecessrio, com o Comit de Controle de Mudanas (CCM). Contudo, nodeve ser deixada unicamente ao solicitante, pois pode ocorrer uma prioridademais alta que a justificvel. A avaliao de risco de fundamental importncianesta fase.

3.3 Categorizao de Mudana

A questo do risco para o negcio de qualquer mudana deve ser levada emconta antes da aprovao de qualquer mudana. O Gerenciamento deMudanas deve analisar casa RM e decidir como proceder conforme acategoria (pr-definida) em que se encaixa a RM.

3.4 Averiguao de Impactos e Recursos

Baseado nessas avaliaes e nos benefcios potenciais da mudana, cadaavaliador 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 deMudanas, Comit de Controle de Mudanas ou a Gerencia Executiva. Umaavaliao de impacto e recurso dever ser apresentada antes que sejaconcedida a aprovao para a mudana. A mudana colocada nocronograma e acrescentada Programao Futura de Mudanas (PFM).

3.6 Agendamento da Mudana

Sempre que possvel, O Gerente de Mudanas deve programar mudanasaprovadas em liberaes alvo (target) e recomendar a alocao apropriada de

recursos.3.7 Coordenao da construo, teste e implementao.

Mudanas so desenvolvidas e procedimentos de restaurao so preparadose documentados com antecedncia para que, em caso de erros depois daimplementao, esses procedimentos possam ser ativados rapidamente. Asmudanas ento so testadas com antecedncia (incluindo procedimentos derecuperao quando possvel) e implementadas.

19


20/54

3.8 Reviso da Mudana / Reviso Ps-implementao

O Gerenciamento de Mudanas deve revisar rodas as Mudanasimplementadas depois de um perodo pr-definido. Normalmente chamadade Reviso de Ps-Implementao .

RelaesDesenho deve existir aqui!!!

Gerenciamento de Liberaes

Objetivo

- O Gerenciamento de Liberaes assume uma viso holstica (um todo) damudana em um servio de TI e deve garantir que todos os aspectos de umaliberao, tanto tcnicos como no tcnicos, sejam considerados m conjunto.

1. Objetivo

O Gerenciamento de Liberaes se preocupa com as mudanas em serviosdefinidos de TI. O Gerenciamento de Liberaes trabalha em conjunto com osGerenciamento de Mudanas e da Configurao para garantir que o BDGCesteja atualizado, as mudanas adequadamente gerenciadas e todas as novasverses de software estejam armazenadas na Biblioteca de Software Definitivo(BSD). Muitos provedores de servios e fornecedores podem estar envolvidosem 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 deMudana) que a implementa.

- Biblioteca de Software Definitivo (BSD)

- Uma rea fsica e segura onde as verses autorizadas e definitivas detodos 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.

20


21/54

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 consisteem 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 documentosde licena ou informao), software desenvolvido no site e cpias eletrnicasmster da documentao.

2.3 Depsito de Hardware Definitivo (DHD)

Uma rea separada para o armazenamento seguro de peas de reservadefinitivas. Detalhes desses componentes e seus respectivosdesenvolvimentos e contedos devem ser detalhadamente registrados noBDGC.

2.4 Verso

Uma situao identificada de um Item de Configurao dentro de uma estruturadetalhada de produto ou estrutura de configurao com o objetivo deacompanhar e auditar o histrico da mudana. Tambm utilizado para Itens deConfigurao de software para definir uma identificao especfica liberada emdesenvolvimento para esboo (drafting), reviso ou modificao, teste ouproduo.

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 oGerenciamento de Liberao. Esse documento especifica as diretrizes e os

detalhes para cada sistema com suporte ou servio de TI. Em resumo, fazparte do plano geral de Gerenciamento de Mudanas.

21


22/54

2.6 Unidade de Liberao

O principal objetivo de uma Unidade de Liberao decidir o nvel de unidadede release mais apropriado para cada item de software ou tipo de software.

2.7 Tipos de Liberaes2.7.1 Liberao Delta

Inclui somente aqueles ICs dentro da unidade de liberao que forammodificados 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 doprocesso de implementao de uma liberao completa que permite um grandenmero de componentes seja re-testado para garantir que no h degradaona funo ou comportamento do sistema.

2.7.3 Liberao em Pacote

Inclui pelo menos duas verses completa, delta ou ambas agrupadas emconjunto. O objetivo oferecer perodos mais longos de estabilidade por meioda reduo da freqncia de verses introduzidas no ambiente real.

2.7.4 Liberao de Emergncia

Normalmente contm as correes para um nmero pequeno de ProblemasConhecidos.

Atividades de Gerenciamento de LiberaesDesenho deve existir aqui!!!

3. Atividades

3.1 Poltica de VersoGarante que cada verso seja conduzida de acordo com as Diretrizes deLiberaes que tenha um identificador nico para objetivos de rastreamentoque lhe sejam atribudos.

3.2 Planejamento de Verso

Isso envolve acordo sobre polticas e procedimentos a serem utilizados,determinao de funes e responsabilidades, planejamento dos nveis derecursos, etc.

3.3 Desenhar, Desenvolver e/ou Comprar Software.

22


23/54

Os procedimentos devem ser planejados e documentados para desenvolver liberaes de software, reutilizando procedimentos-padro sempre quepossvel.

3.4 Desenvolvimento e Configurao de Software

Isso envolve procedimentos de planejamento e documentao paradesenvolvimento de verses, compilao de mdulos de aplicativos, descriode rotinas de instalao automatizadas, levando em conta requisitos desegurana ao liberar equipamentos novos/modificados, carga de banco dedados de testes com dados de teste, etc.

3.5 Teste de Adequao

Deve incluir teste funcional, teste operacional, teste de desempenho e teste deintegrao. A falta de teste a causa principal de falhas em todas asMudanas e Liberaes.

3.6 Aceite de Verso

Isso envolve verses de teste e inclui procedimentos de reserva. O teste deintegrao realizado pelo pessoal de negcio e envolver a equipe de TI paraverificar qualquer procedimento de suporte modificado.

3.7 Planejamento de Implementao

Isso envolve a criao de um cronograma detalhado de eventos, incluindoresponsabilidades 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 queest planejado e como isso pode afet-los. Revise os planos por meio darealizao de reunies de planejamento de implementao e sesses detreinamento.

3.9 Distribuio e InstalaoIsso envolve a distribuio de verses de software, e, se for o caso, asrespectivas mudanas de hardware, desde o ambiente de desenvolvimentopara o de teste e para o ambiente real. Tambm garante que o equipamentoseja entregue com segurana a seu destino e nas condies esperadas, que asreas de armazenamento sejam seguras, que a integridade do software sejamantida durante o manuseio, embalagem e entrega, que os procedimentossejam seguidos e verificaes automatizadas realizadas para garantir que ospr-requisitos de software e hardware sejam atendidos, etc.

O Modelo de Suporte a ServiosDesenho deve existir aqui !!!

23


24/54

Entrega de Servios

O Modelo de Entrega de ServiosDesenho deve existir aqui !!!

Gerenciamento do Nvel de Servio

Objetivo

- Manter e melhorar a qualidade do servio de TI por meio de um cicloconstante de acordo, monitorao e relatrio para atender aos objetivos enegcio do cliente.

1. Objetivo

O processo de Gerenciamento do Nvel de Servio envolve tanto o clientequanto o provedor de servios de TI. Juntos, eles definem, negociam, aprovame monitoram nveis de servio. Essa comunicao contnua proporciona umrelacionamento mais slido entre o Gerenciamento de servio de TI e seusclientes. A comunicao do Gerenciamento do Nvel de Servio tem o foco nabusca do acordo no em manter uma das partes como refm,

Gerenciamento d o Nvel de Servio o nome dado aos processos deplanejamento, coordenao, elaborao de minuta, acordo, monitorao erelatrio em relao aos Acordos de Nvel de Servio; tambm revisopermanente 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 opese 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 visogeral de todos os servios fornecidos, informao adicional sobre o contedo

do Catlogo de Servios pode ser encontrada na seo subseqente deobservaes.

24


25/54

1.2 Requisitos de Nvel de Servio (RNS)

Requisitos de Nvel de Servio formam uma lista dos requisitos de servio dosclientes. As RNSs devem ser parte integral de critrios de design do servio,dos quais a especificao funcional uma parte.

1.3Acordo de Nvel Operacional (ANO)

Um Acordo de Nvel Operacional um acordo feito entre um departamentointerno de TI (por exemplo, Gerenciamento de Rede) e o Gerenciamento doNvel de Servio.

1.4Contrato de Apoio (CA)

Um contrato com um fornecedor externo, que abrange servios necessriospara suportar Ti na entrega de servios.

1.5Acordo 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 responsabilidadesde ambas as partes. importante observar que essas metas devem ser bementendidas e aprovadas por ambas as partes a fim de evitar disputas e mal-entendidos.

1.6Programa 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 ServioDesenho 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- Horrios de servios

- Horrios de manuteno- Horrios de suporte

25


26/54

- 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 suascaractersticas e detalhes dos clientes e mantenedores de cada servio. Podeser 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, CAsDesenho deve existir aqui !!!

Estruturas de ANSDesenho deve existir aqui !!!

4. Definies Estrutura do Gerenciamento do Nvel de ServioANSs/ANOs/CAs

A maior parte dos provedores de servios de TI dependente, de algumamaneira, dos seus prprios fornecedores (interno e/ou externo). Eles nopodem se comprometer a atender as metas do ANS a no ser que o prpriodesempenho de seus fornecedores suportem essa metas. Contratos comfornecedores externos uma obrigatoriedade, mas muitas organizaestambm tem identificado os benefcios de ter simples acordos com gruposinternos de suporte, normalmente citados como ANOs (Acordos de NvelOperacional).

5. Estruturas de ANS

5.1 Baseado no Cliente

Um acordo com um grupo individual de Clientes, cobrindo todos os serviosque eles utilizam. Por exemplo, podem ser feitos acordos com o DepartamentoFinanceiro de uma organizao, cobrindo por exemplo o Sistema Financeiro, oSistema de Contabilidade, o Sistema de Folha de Pagamento, o Sistema deCobrana, o Sistema de Procurement(obteno) e qualquer outro sistema de TIque eles utilizem.

26


27/54

5.2 Baseado em Servio

o caso em que um ANS cobre um servio para todos os Clientes daqueleservio. Por exemplo, pode ser estabelecido um ANS para o servio e e-mailda 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. Essasquestes tendem a ser menos volteis, consequentementenecessitam-se de menos atualizaes.

2) Nvel Cliente: cobre todas as questes de GNS que so relevantespara um grupo especfico de Clientes, independentemente do servioutilizado.

3) Nvel Servio: cobre todas as questes de GNS que so relevantespara um servio especifico, em relao a esse grupo especfico deClientes (um para cada servio coberto pelo ANS).

AtividadesDesenho deve existir aqui !!!

6. Activies6.1 Funo Estabelecida

6.1.1 Planejamento

Atividades iniciais de planejamento incluem a nomeao de um Gestor de Nvelde Servio, a definio de papis e responsabilidades, o planejamneto demonitorao de habilidades e identificao de ferramentas de suporte. realizada a definio inicial de percepo de servios bem como a reviso dosatuais 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 derisco bem como o planejamento para as estruturas de ANS e Catlogo deServios. Desenvolve0se um formato piloto de ANS.

6.2 Implementar ANS6.2.1 Catalogar Servios

O Catlogo de Servios produzido. A gesto contnua de expectativas importante.

27


28/54

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 capacidadesde monitoramento.

6.2.4 Revisar CAs e ANOs

Revisar CAs e ANOs para verificar a compatibilidade com os ANSs e definir osprocedimentos de relatrio e reviso.

6.2.5 Acordar ANSs

Ocorre a aprovao de ANSs e esses ANSs so divulgados.

6.3 Gerenciar Processo6.3.1 Monitorar

Estimular monitorao e produzir relatrios de realizao de servios erelatrios operacionais.

6.3.2 Reportar

Relatrios peridicos com detalhes de desempenho comparados aos ANSsdevem incluir tendncias, etc.

6.3.3 Revisar

Relatrios peridicos devem ser produzidos e devem circular alguns dias antesdas 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 CAsReunies de Reviso de Servios devem ocorrer regularmente com os clientespara 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.

28


29/54

Contedo Sugerido para ANS

- Introduo- 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 - Datas: comeo, fim, reviso- Ttulo e breve descrio do acordo - Escopo do acordo- Responsablidades TI e Cliente - Descrio de servios includos

7.2 Horas de Servio

Horas de servio devem incluir as horas em que normalmente se necessitacada servio;Proviso para solicitar extenses de servio, incluindo perodo necessriomediante aviso;Horrios especiais como feriados pblicos e um calendrio de servio.

7.3 Disponibilidade

Metas de disponibilidade dentro do horrio acordado so normalmenteexpressas como porcentagens e devem ser includas no ANS bem como operodo de medio e o mtodo.

7.4 Confiabilidade

Normalmente expressada como o numero de interrupes no servio, TempoMdio entre Defeitos (TMED) ou Tempo Mdio entre Incidentes de Sistema(TMEIS).

29


30/54

7.5 Suporte

Horrio de suporte deve ser identificado, especialmente se no for o mesmo dohorrio de servio. Meta de tempo para resposta seja fisicamente ou por outromtodo.

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 daworkstation. 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 MudanaMetas 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

Citao de quaisquer planos de continuidade de TI e como acion-los,incluindo cobertura de quaisquer questes de segurana, em especialquaisquer responsabilidades do cliente. Detalhes de qualquer diminuio oumodificao de meta de servio em caso de ocorrncia de situaes dedesastre.

7.11 Cobrana

Detalhes da frmula de cobrana e perodos. Se o ANS cobre o relacionamentocom terceiro, as taxas devem ser detalhadas no apndice.

7.12 Relatrio e Reviso de ServioContedo, freqncia e distribuio de relatrios de servio; freqncia dareunio 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

30


31/54

A sustentabilidade define o perodo de tempo aceitvel que um cliente podeesperar para que determinado componente ou servio esteja fora do ar ourestaurado. A sustentabilidade tambm se refere ao tempo necessrio pararealizar a manuteno preventiva. Um cronograma do tempo planejado paraestar fora do ar tambm deve ser mencionado no ANS.

A funcionalidade do servio se refere a contratos de servio celebrados comfornecedores terceirizados de TI.

Gerenciamento Financeiro para Servios em TI

Objetivo

- Fornecer administrao rentvel dos ativos de TI e recursos utilizados parafornecer 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 eatribuir 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 deCustos

- Elementos de Custos- Usado para auxiliar a diviso dos tipos de custos

- Categoria de Custos- Capital ou Operacional (Classificao mnima dos Elementos deCustos)- Custos Direto ou Indireto- Custos Fixo ou Varivel

2. Definies

2.1 Modelo de Custo

Modelo de custo baseado no clculo do custo por cada Cliente. Outrosmodelos podem ser desenvolvidos para mostrar o custo por cada servio ou

31


32/54

os custos por cada localidade. Modelos de custos que permitem o clculo decustos por Cliente so o ponto de partida caso seja introduzido um Sistema deCobrana.

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 principaisTipos de Custo selecionados hardware, software, pessoas, acomodaes etransferncia podem ser divididos ainda mais. Por exemplo, hardware podeser dividido em Escritrio, Rede e Servidores Centrais. O objetivo garantir que cada custo identificado na organizao de TI possa ser colocado dentro deuma 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 Custo2.4.1 Capital ou Operacional

Custos de Capital so aqueles custos que tipicamente se aplicam aos ativosfsicos (substanciais) da organizao. Custos Operacionais so os queresultam da operao diria da seo de Servios de TI, por exemplo, custosde pessoal, manuteno de hardware e eletricidade e relacionados apagamentos repetitivos cujos efeitos podem ser medidos dentro de um perodode 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. Custosindiretos so aqueles realizados por todos, ou por um nmero de clientes ouservios, por exemplo: a rede ou o departamento de suporte tcnico, que temque ser dividido com todos, ou com um nmero de clientes de maneira justa.

Observao: A cobrana pelos custos indiretos pode ser feita por meio doCusto Baseado em Atividade (ABC Activity Based Costing). O mtodo ABC comea totalizando todos os custos administrativos em uma organizao e, emseguida, alocando os custos das atividades aos produtos e servios quenecessitaram dessas atividades. Em vez de alocar custos indiretosarbitrariamente, 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 comoelementos de custo que no podem ser facilmente previsveis.

32


33/54

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.

2.5.2 Comunicao de Informao

Os clientes so informados sobre as cobranas para que estejam conscientesdos 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 Preos2.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.

33


34/54

2.6.5 Preo de Contrato Negociado

Esses preos so discutidos com o cliente. Caso o cliente solicite um novoservio, ento se negocia se ele tem que absorver todos os custos deinvestimento ou somente uma proporo.

Modelo de Custo - por ServioDesenho deve existir aqui !!!

Modelo de Custo - por ClienteDesenho deve existir aqui !!!

Atividades

- O oramento capacita uma organizao a:

- Prever o dinheiro necessrio para operar os servios de TI durante umdeterminado perodo.- Garantir que as despesas reais possam ser comparadas com asprevistas em qualquer ponto.- Reduzir o risco de gastar demais.- Garantir que receitas esto disponveis para cobrir as despesasprevistas.

- 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. Atividades3.1 Oramento

Oramento o processo de prever e controlar o gasto do dinheiro dentro daempresa. Consiste em um ciclo de negociao peridica para determinar osoramentos (normalmente anual) e a monitorao dia-a-dia dos oramentosatuais.

3.2 Contabilidade de TI

o conjunto de processos que capacita a organizao de TI a prestar contasde maneira plena do modo como se gasta o dinheiro (em especial a habilidade

34


35/54

de identificar custos por cliente, por servio, por atividade). Normalmenteenvolve 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 pelosservios a eles prestados. Para alcanar isso, necessrio uma boacontabilidade, que alcance um nvel de detalhe determinado pelos requisitosdos processo de anlise, cobrana e relatrios.

Ciclo Financeiro em TIDesenho 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 deseus objetivos de negcio e exige aplicao em toda a empresa para alcana omximo de eficincia e o mnimo de conflito. H dois ciclos distintos: um ciclode planejamento anual em que projees de custo e previso de carga detrabalho formam a base para clculo de custo e determinao de preo e umciclo operacional (mensal ou trimestral) em que os custos so monitorados ecomparados com os oramentos, cobranas so emitidas e receitas socobradas. Mudanas no sistema de contabilidade de TI devem coincidir com asrevises 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 decarga de trabalho formam a base para clculo de custo e determinao depreo. Um ciclo operacional (mensal ou trimestral) em que os custos somonitorados 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 aorganizao na entrega de um nvel de disponibilidade rentvel e sustentvelque capacite o negcio a atingir seus objetivos.

35


36/54

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 paraserem articulados. um processo contnuo, terminando somente quando oservio 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

2. Definies

2.1 Disponibilidade

Disponibilidade a habilidade de um servio ou componente de Ti paradesempenhar a funo requerida em um determinado instante ou durante umperodo 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-estruturade TI que entrega o servio de TI.

2.3 Sustentabilidade (Interno)

A habilidade de um componente da infra-estrutura de TI em ser mantido emseu estado operacional, ou restaurado a esse estado.

2.4 Funcionalidade do servio (Externo)

A funcionalidade do servio descreve as provises contratuais feitas comfornecedores terceirizados de servios de TI para garantir a disponibilidade,confiabilidade e sustentabilidade dos servios de TI e dos componentes sobsua responsabilidade.

36


37/54

2.5 Resilincia (Resistncia)

A capacidade de um servio de TI em permitir a operao contnua de TIapesar 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 negcioconsiderado crtico para o negcio. Em qualquer servio de TI, h um nmerode funes de negcio que podem ser suportadas e algumas so mais vitaisque 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 pararegistrar e armazenar informao necessria para o suporte de atividadesfundamentais, como produo de relatrios, anlise estatstica e previso dedisponibilidade.

2.9 Janela de Servio

Usualmente se refere a um ponto de tempo especfico no qual o servio estdisponvel, ou, de outra forma, o tempo possvel para que uma manutenoseja 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

A determinao dos requisitos de disponibilidade um processo interativo poish a necessidade de equilibrar os requisitos de Disponibilidade de negcio comos outros associados. Os passos necessrios so:

- Determinar o impacto de negcio causado pela perda de servio.

37


38/54

- A partir dos requisitos de negcio, especificar os requisitos para oscomponentes de TI, controlados por TI.- Para componentes e Servios externos de TI, identificar os requisitos defornecimento de servio.- Estimar os custos envolvidos em atender requisitos.

- Determinar com o negcio se os custos envolvidos em atender os requisitosso justificveis.- Determinar a partir do negcio os custos derivados de perda ou degradaodo servio.- Quando so vistos como custos justificveis, definir os requisitos emacordos/contratos.

3.2 Desenhar Atividades3.2.1 Guias para Disponibilidade

Isso se refere ao design tcnico da Infra-estrutura de Ti e ao alinhamentonecessrio de fornecedores internos e externos para atender os requisitos deDisponibilidade para um Servio de TI.

3.2.2 Guias de Recuperao

Isso se refere aos pontos de design necessrios para garantir que, em caso defalha no Servio de TI, o servio possa ser restaurado para possibilitar que aoperao normal de negcios possa ser retomada o mais breve possvel.

3.3 Consideraes de Segurana

Durante o agrupamento dos requisitos de Disponibilidade para os novosServios de TI, importante que os requisitos que abrangem a segurana de TIsejam definidos. Esse requisitos necessitam ser aplicados durante a fase dedesign para a Infra-estrutura de suporte de TI.

3.4 Gerenciamento de Manuteno

Todos os componentes de TI devem estar sujeitos a uma estratgia planejadade manuteno. A freqncia e nveis de manuteno necessrios variam decomponente 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 deDisponibilidade. um plano de longo prazo que trata da disponibilidadedurante os prximos anos. Em primeiro lugar, deve descrever a situao atuale, em estgio posterior, pode ser ampliado para incluir atividade de melhoriapara servios existentes e diretrizes bem como planos para novos servios ediretrizes para manuteno.

38


39/54

3.6 Medio e Relatrios

Mensurao e relatrios so atividades importantes no Gerenciamento daDisponibilidade, pois fornecem a base para verificar acordos de servio,resolver problemas e definir propostas de melhoria.

Entradas & SadasDesenho deve existir aqui !!!

Ciclo de Vida Expandido do IncidenteDesenho 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

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 outroeixo). 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 epodem 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 paradeterminar a seqncia de eventos que causou uma interrupo nos serviosde 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 bsicossejam analisados em profundidade, eles se tornam automaticamente

eventos resultantes.

39


40/54

- Eventos resultantes ndulos intermedirios da rvore de erros, queresultam 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 paraidentificar oportunidades de melhoria d Disponibilidade, de ponta-a-ponta , queresultem em benefcios para o Usurio. Segue a abordagem estruturada parauma atividade de (AIS):

1. Escolha a oportunidade2. Delimite a atividade3. Planeje a atividade4. Desenvolva a hiptese5. Analise de dados6. Entreviste principais funcionrios7. Descobertas e concluses8. Recomendaes9. Relatrios10.Validao

4.4 Clculo de Disponibilidade

O Clculo Bsico de Disponibilidade foi demonstrado anteriormente, no entantoh dois clculos alternativos:

4.4.1 Configurao Simples de Infra-estrutura de TI (Simple IT InfrastructureConfiguration).


Disponibilidade vista a partir da estao de trabalho do Usurio calculadaassim:

Disponibilidade = Host * Rede * Servidor * Estao de TrabalhoClculo = 0.98 * 0.98 * 0.975 * 096 = 0.8989Disponibilidade Total da Infra-estrutura = 89.89%

4.4.2 Configurao somples de TI com Componente de Resistncia.

40


41/54


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.9996Disponibilidade do Host = 99,96%

Relaes com Gerenciamento da Disponibilidade


Gerenciamento de Segurana

Objetivo

- Atender aos requerimentos de segurana do ANSs e outros requerimentosexternos adicionais para contratos, legislao e obrigaes.

- Prover um nvel bsico de segurana, independente de requerimentosexternos.

1. Objetivo

O objetivo geral da segurana de TI obter uma segurana equilibrada emconformidade com controle justificveis implementados para garantir acontinuidade de servio de TI dentro de parmetros seguros.

H potencial para confuso entre os proprietrios de processo para oGerenciamento de Segurana e Gerenciamento da Disponibilidade em relaoaos 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 denovos servios de TI. O Gerenciamento da Disponibilidade responsvel por

garantir que os requisitos de segurana sejam definidos e incorporados dentrodo design geral de disponibilidade.

Definies

- Segurana - Seo de Segurana- Conscientizao de Segurana - Confidencialidade- incidentes de Segurana - Integridade- Nvel de Segurana - Disponibilidade

41


42/54

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 paraaumentar a Conscincia de Segurana em pocas especficas do ano.

2.3 Incidentes de Segurana

Eventos que podem causar dano Confidencialidade, Integridade ouDisponibilidade da informao. Materializado como acidentes ou atospropositais.

2.4 Nvel de Segurana

O grau de segurana aprovado dentro de um Acordo de Nvel de Servio, ouordenado dentro de um Acordo de Nvel Operacional ou Contrato de Apoio.

2.5 Seo de Segurana

Refere-se a uma seo de acordos e contratos em que requisitos especficos edetalhados 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.


3. Atividades

3.1 Atividades

42


43/54

3.1 Controlar poltica de Segurana da Informao e Organizao

A atividade de Controle o primeiro subprocesso do Gerenciamento deSegurana e se relaciona organizao e gesto do processo. Essa atividadedefine os subprocessos, funes de segurana, papis e responsabilidades.

Tambm descreve a estrutura organizacional, providncias de relatrios e linhade controle.

3.2 Planejar

Inclui a definicao da seo de segurana do ANS em consulta com o GNS eas atividade nos UCs relacionadas segurana. Esse subprocesso no apenasrecebe dados do ANS, mas tambm dos princpios de poltica do provedor deservios.

3.3 implementar

Tem o objetivo de implementar todas as medidas especificadas nos planos.rea que devem ser consideradas durante esse subprocesso:

1. Classificao e Gerenciamento dos recursos de TI.2. Segurana de funcionrios.3. Segurana de Gerenciamento.4. Controle de acesso.

3.4 Avaliar

A avaliao independentemente da implementao de medidas planejadas fundamental.

- Auto-avaliaes: principalmente implementadas por gruposoperacionais 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

A manuteno realizada com base nos resultados do subprocesso deAvaliao e na avaliao de mudanas nos riscos. As propostas podem ser introduzidas tanto no subprocesso de Planejamento como includas namanuteno do ANS como um todo. As propostas podem resultar na incluso

de atividades no plano anual de segurana.

43


44/54

3.6 Reportar

Relatar no um subprocesso, mas o resultado dos outros subprocessos. Osrelatrios so produzidos para fornecer informao sobre o desempenho desegurana 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 daconfidencialidade e integridade nem comprometimento posterior dadisponibilidade de servio.

- Acesso Fsico ao computador e rede deve ser restrito somente ao pessoalautorizado.

- ANOs e CAs devem demonstrar adeso aos controle de segurana exigidospela organizao de suporte de TI.

Gerenciamento de Capacidade

Objetivo

- Garantir que todos os aspectos de capacidade e de desempenho, atuais efuturos, dos requisitos de negcio sejam atendidos de maneira rentvel.

1. Objetivo

Custo versus Capacidade

Assegurar que a capacidade de processamento adquirida no justificadasomente em termos de necessidade de negcio, mas tambm do mais eficienteuso desses recursos.

Oferta versus Demanda

Assegurar que a oferta disponvel de poder de processamento combina com ademanda solicitada pelo negcio, tanto agora como no futuro. Pode ser necessrio tambm gerenciar ou influenciar a procura por um recursoespecfico.

O Gerenciamento de Capacidade necessita compreender os requisitos denegcio (a entrega de servio requerida), a operao da organizao (aentrega de servio atual) e a infra-estrutura de TI (os meios de entrega deservio). Utilizar essa informao de maneira efetiva garante que todos osaspectos de capacidade e de desempenho dos requisitos e negcio, atuais e

futuros, sejam atendidos de maneira rentvel.

44


45/54

O Gerenciamento da Capacidade significa tambm compreender o potencialpara a entrega de servio. A nova tecnologia necessita ser compreendida e, sefor adequada, utilizada para entregar os servios solicitados pelo negcio. OGerenciamento da Capacidade necessita reconhecer que a velocidade damudana 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 paraservios de TI sejam consideradas, planejadas e implementadas de maneiraoportuna.

Gerenciamento da Capacidade de Servio

- O gerenciamento do desempenho dos servios de TI no ar e operacionaisusados pelos clientes.

Gerenciamento da Capacidade dos Recursos

- O gerenciamento dos componentes individuais da infra-estrutura de TI.

2. Definies

2.1 Gerenciamento da Capacidade do Negcio

Um objetivo fundamental deste subprocesso garantir que as futurasnecessidades quanto a servios de TI sejam levadas em conta ecompreendidas, e que suficiente capacidade para suportar os servios sejaplanejada e implementada em uma escalada de tempo apropriada. Embora oprocesso de Gerenciamento da Capacidade deva atender aos requisitos queconstantemente 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 podemser produzidos pelo negcio ou podem se originar do prprio processo deGerenciamento da Capacidade. Como exemplo, pode ser a recomendao defazer um upgrade para aproveitar a nova tecnologia, ou a implementao deuma atividade de sintonia fina para resolver um problema de desempenho.

O Gerenciamento da Capacidade no deve ser um X de ltima hora noquadrinho 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 doServio identificar e entender os servios de TI, a utilizao de seus recursos,

45


46/54

padres de trabalho, picos e ociosidades, e garantir que os servios possam ecumpram as metas do ANS. Portanto, o foco em gerenciar o desempenho deservio, 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 setornou operacional, ento o subprocesso de Gerenciamento da Disponibilidadedo Servio se torna responsvel em assegurar que o servio atende as metasaprovadas de servio. O servio monitorado fornece dados que podemidentificar tendncias, a partir das quais se estabelecem os nveis normais deexceo podem ser definidas, identificadas e colocadas em relatrios. Assim, oGerenciamento 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 acapacidade e a utilizao das partes de cada componente da infra-estrutura deTI. Isso garante o uso ideal dos recursos atuais de hardware e de software afim de atingir e manter os nveis de servio aprovados. Esse subprocessotambm se mantm atento a novas tecnologias.


3. Atividades

Contnuas: Atividade Repetitivas, Gerenciamento de demanda eArmazenamento 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 Repetitivasconsistem 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.

46


47/54

3.2 Gerenciamento da Demanda

O objetivo do Gerenciamento da Demanda influenciar a demanda e o uso deum recurso de informtica. Normalmente se realiza em curto prazo porque hcapacidade insuficiente, mas pode ser utilizado em longo prazo, quando difcil

justificar umupgrade caro.3.3 Modelagem

O propsito da modelagem prever o comportamento dos servios de TI, sobdeterminado volume e variedade de trabalho. Os diferentes tipos demodelagem vo desde a preparao de oramentos baseados na experinciaat benchmarking de escala completa. O primeiro barato, embora no sejato exato, ao passo que o ultimo caro e mais exato pode ser aconselhvelpara um projeto novo e grande.

3.4 Dimensionamento da Aplicao

O objetivo inicial estimar os requerimentos de recursos necessrios parasuportar uma proposta de mudana de aplicativo, e garantir que isso atendaaos nveis de servio exigido. A dimenso de aplicativo tem um perodo de vidafinito. Comea no estgio de iniciao para um novo aplicativo ou quando huma grande mudana de um aplicativo existente e se completa quando oaplicativo aceito dentro do ambiente operacional.

3.5 Armazenamento dos Dados de Gerenciamento da Capacidade

O Banco de dados do Gerenciamento da Capacidade (BGC) fundamentalpara o sucesso do processo de Gerenciamento da Capacidade. Deve ser tidocom 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 edesempenho de servio. Depois de considerar os planos e a estratgia denegocio, 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 recomendaesquantificadas em termos de recurso solicitado, custo, benefcios, impacto, etc.

Entradas & SadasDesenho deve existir aqui !!!

Relaes com Gerenciamento da CapacidadeDesenho deve existir aqui !!!

47


48/54

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 dentrodas 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 TInecessrias (incluindo sistemas de computadores, redes, aplicativos,telecomunicaes, suporte tcnico e servio) sejam recuperadas dentro dasescalas de tempo de negcio solicitadas e aprovadas.

GCN & GCSTI

- O Gerenciamento da Continuidade do Negcio (GCN) se preocupa com oGerenciamento da Continuidade de Negcio que incorpora todos os serviosdos quais o negcio depende, entre eles TI.

- O Gerenciamento da Continuidade dos Servios em TI (GCSTI) est focadona continuidade dos servios de TI para o negcio.

- As organizaes exigem que o GCSTI se torne parte integral dogerenciamento corporativo para que objetivos de negcio e metas sejamalcanados e mantidos.

2. Definies GCN & GCSTI

2.1 Gerenciamento da Continuidade do Negcio (GCN)

O Gerenciamento da Continuidade do Negcio (GCN) se preocupa com agesto de riscos para garantir que a organizao possa continuar operando emum nvel mnimo, pr-determinado. O Processo GCN envolve a reduo do

risco a um nvel aceitvel e o planejamento da recuperao dos processos denegcio 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 doprocesso geral do Gerenciamento da Continuidade do Negcio (GCN) edepende de informao derivada desse processo.

O Gerenciamento da Continuidade dos Servios em TI (GCSTI) deve ser partedo processo geral do Gerenciamento da Continuidade do Negcio (GCN) e

depende de informao derivada desse processo. O GCSTI est focado naContinuidade dos servios de TI para o negcio. O GCN se preocupa com o

48


49/54

Gerenciamento da Continuidade do Negcio que incorpora todos os serviosdos quais o negcio depende, um dos quais TI.

H a necessidade de que requisitos mnimos de negcio sejam determinadosem 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 sejadefinido. Esses requisitos podem definir a necessidade de estabelecer umatransferncia imediata do servio para um site alternativo ou um requisito derecuperar elementos do servio durante um perodo de tempo mais longo (por exemplo, uma semana). fundamental que esse pr-requisitos sejamplenamente compreendidos, definidos e aprovados pelo negcio como parte doprocesso GCN para garantir que o GCSTI seja especificamente usado damaneira 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 esforosignificativo para restaur-lo ao nvel original de desempenho.

3.2 Gerenciamento de Crise

O processo pelo qual uma organizao gerencia o impacto maior de umdesastre, 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 doGCN.

3.4 Anlise de Risco de Gerenciamento do CCTA (*)

CRAMM descreve um meio de identificar contramedidas justificveis paraproteger a Confidencialidade, Integridade e Disponibilidade da Infra-estrutura

de TI. Os conceitos gerais so representados por um simples diagrama que

49


50/54

mostra a Anlise de Risco e a Gesto de Risco como duas atividadesrelacionadas, porm separadas.(*) CCTA Risk Analisys & Management Method - CRAMM


A Anlise de Risco envolve a identificao e avaliao do nvel (medida) dosriscos calculados a partir dos valores avaliados dos ativos e dos nveisavaliados de ameaas a esses ativos e vulnerabilidade desses ativos. AGesto de Risco envolve a identificao, seleo e adoo de contramedidas justificadas pelos riscos identificados aos ativos em termos de impactopotencial sobre servios caso ocorra uma falha e a reduo desses riscos a umnvel aceitvel.

3.5 Opes de Recuperao

- No faa nada. (Do nothing) - Recuperao Gradual (Cold Standby)- Soluo Provisria Manual - Recuperao Intermediria (Warm Standby)- Providncias Recprocas - Recuperao Imediata (Hot Standby)


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 dositens 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 quobem uma organizao sobreviver uma interrupo de negcio ou desastre eos custos que podem existir.

50


51/54

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 interrupono 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 potencialque pode ser causada a organizao como resultado de uma interrupo dosprocessos crticos de negcio.- O impacto medido em comparao a vrios cenrios e normalmente cai emuma ou mais das seguintes categorias defeito em alcanar os nveis deservio aprovados internamente, perdas financeiras, custos adicionais, perdaimediata 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 deque um desastre ou uma interrupo grave de servio vai ocorrer. Isso significauma avaliao do nvel de ameaa e at que ponto uma organizao estvulnervel a essa ameaa.

4.2.3 Estratgia da Continuidade do Negcio

A informao extrada da anlise de impacto e da avaliao de risco, alm dosmecanismos de GCSTI associados, oferece uma estratgia adequada para quea organizao se desenvolva com um equilbrio ideal de reduo de risco erecuperao ou opes de Continuidade. Isso inclui a considerao dasprioridades relativas de recuperao de servio e as mudanas na prioridaderelativa de servio para o horrio do dia, dia da semana e variaes mensais eanuais.

Estgio 3: Implementao

4.3 Implementao

4.3.1 Organizao e Planejamento da Implementao

O planejamento da implementao critico para o processo de implementaoe 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 deacordos em reserva (standby), incluindo acomodao bem como sistemas etelecomunicaes. Determinadas aes so necessrias para implementar osacordos em reserva, como:

- Contratar instalaes de recuperao terceirizadas- Preparar e equipar acomodaes de reserva

51


52/54

- 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 informaonecessria a fim de que sistemas crticos, servios e instalaes continuem aser fornecidos ou sejam restaurados dentro de um perodo aceitvel para onegcio.

4.3.4 Implementao de Medidas de Reduo de Risco

Arquivamento e armazenamento offsite; estrutura de dados RAID eespelhamento de disco para servidores de LAN para prevenir perda de dados egarantir disponibilidade contnua de dados; sistemas tolerantes de defeitodevem ser implementados para aplicaes crticas em que mesmo um tempomnimo 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 ecomum.- Fusos horrios diferentes em uma organizao multinacional e pontos decorte de negcio.

4.3.6 Teste Inicial

Um teste completo precisa replicar a invocao de todos os preparativos dereserva, incluindo a recuperao de processos de negcio e o envolvimento degrupos externos. Isso testa a integridade dos planos e confirma os objetivos deprazo, a resposta, estado de alerta a preparao da equipe.

Estgio 4: Gerenciamento Operacional

4.3 Gerenciamento Operacional4.4.1 Educao e Conscientizao

Deve abranger a organizao e, em particular, a organizao de TI, para itensespecficos de continuidade de servio. Isso garante que todo o pessoal estejaconsciente das implicaes da continuidade de negcio e da continuidade deservio e as considerem como parte de sua rotina normal de trabalho e de seuoramento.

52


53/54

4.4.2 Reviso e Auditoria

Necessita ser realizada a reviso regular de todos os entregveis do processode 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 umamudana nos provedores de servio. Isso inclui os casos em que h mudanasno rumo do negcio, na estratgia do negcio ou na estratgia de TI. Como asorganizaes normalmente mudam rapidamente, necessrio investir em umprograma de reviso contnua e incorporar o GCSTI aos processosorganizacionais de justificativa de negcio. Novos requisitos seroimplementados em conformidade com o processo de controle de mudanas.

4.4.3 Teste

Depois do teste inicial, necessrio estabelecer um programa de testesregulares para garantir que os componentes crticos da estratgia so testadospelo menos anualmente ou conforme orientao da Gerencia Executiva ou daauditoria. importante que quaisquer mudanas na infra-estrutura de TI sejamincludas na estratgia, implementadas de modo adequado e testadas paragarantir 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 demudanas para garantir que quaisquer mudanas na infra-estrutura sejamrefletidas nos panos de contingncia fornecidos por TI ou por terceiros. Planosinadequados e capacidades de recuperao inadequadas podem resultar nodefeito da GCSTI.

4.4.5 Treinamento

A TI pode estar desenvolvida em treinar os integrantes da equipe derecuperao de negcio que no sejam da rea de TI para garantir que elestenham 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 gerenciamentooperacional 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/ouservios.

53


54/54

- O horrio do dia/ms/ano e o impacto potencial no negcio. No final do ano, anecessidade de invocar pode ser maior para garantir que o processamento defim de ano seja completado dentro do prazo.- Requisitos especficos do negcio dependendo do trabalho que est sendorealizado no momento.

5. Invocao

Esta deciso normalmente feita por uma equipe de gerenciamento de criseformada 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 deworkstation, etc, armazenadas off-site.- Mobilizao de pessoal tcnico apropriado.- Entrar em contato e deixar e

fundamentos itil portugues brasil br completo

Documents