Marcio iti lv3_5_operacao_deservicos

Especialização em Gestão de TI

Gestão de Serviços de TI
com ITIL Versão 3
5. Operação de Serviços
Márcio Aurélio Ribeiro Moreira
marcio.moreira@uniminas.br
http://si.uniminas.br/~marcio/

Operação de Serviços
 Conceitos chaves:
 Eventos
 Processos envolvidos:  Incidentes
 Gestão de Eventos  Problemas
 Requisições de Fulfillment  Erro Conhecido
 Gestão de Incidentes  Operação de Serviços:
 Gestão de Problemas  Pode ser chamada de a Fábrica
 Gestão de Acessos de Serviços de TI
 Funções Envolvidas:  Seu propósito é entregar e
 Service Desk manter serviços de TI
 Gestão Técnica  Seu propósito é coordenar e
entregar atividades e processos
 Gestão de Operações de TI
necessários para entregar e
 Gestão de Aplicações manter o nível de serviço
 Atividades Comuns: combinado com o cliente e o
 Monitoramento e Controle negócio
Márcio Moreira 5. Operação de Serviços – Slide 2 Gestão de Serviços de TI com ITIL V3

Gestão de Eventos
 Evento:
 Qualquer ocorrência detectável ou discernível que tem impacto e
significância para a gestão de infra-estrutura ou entrega de serviços de TI.
 Normalmente, são notificações criadas pelo serviço, itens de configuração
ou ferramenta de monitoramento.
 Propósito:
 É um processo que trabalha todos os eventos que ocorrem na infra-
estrutura de TI que permitem a operação normal e também a detecção e
escalação de exceções. Trabalha os eventos gerados pelo monitoramento.
 Tipos de Monitoramento:
 Ativo: Monitora CIs chaves e notifica corretamente as exceções.
 Passivo: Detecta e correlaciona alertas operacionais e comunicações
geradas pelos CIs.
 Aplicações:
 CIs, ambiente (fumaça ou fogo), software, segurança, aplicações, etc.


Processo de Gestão de Eventos
Informational Trigger Exception


Importância e atividades
da Gestão de Eventos
 Importância:  Atividades:
 Mecanismo de detecção  Ocorrência e notificação
de incidentes, mesmo  Detecção
antes do serviço cair  Filtragem
 Significância:
 Monitoramento de  Informação, aviso, exceção
exceções  reduz  Correlação
custos e o downtime  Gatilho
 Se integrado a outros  Resposta:
processos  sinaliza  Registro, auto-resposta,
exceções para equipe alerta/intervenção humana,
incidente, problema ou RFC
 Base para automação  Revisão de ações
 aumenta eficiência  Fechamento

Gestão de Incidentes
 Incidente:
 Evento que não faz parte da operação padrão de um serviço e que
causa, ou pode causar, interrupção e/ou redução na qualidade
desses serviços.
 Podem ser comunicados pelo cliente ou detectados (Gestão Eventos).
 Propósito:
 Processo reativo, cujo principal objetivo é restaurar o nível de
serviço o mais rápido possível, minimizando os efeitos negativos no
negócio.
 Objetivos:
 Garantir o melhor uso dos recursos que suportam o negócio
 Desenvolver e manter registros eficazes sobre os incidentes.
 Desenvolver e aplicar uma abordagem consistente para todos os
incidentes relatados.

Importância da Gestão de Incidentes
 O gerenciamento de incidentes envolve o
processamento de solicitações e eventos de
qualquer tipo.
 É executado por um grupo de especialistas que
trabalham virtualmente ligados.
 Assume papel de manter contato com o sistema
de TI e o negócio.
 Junto com o Service Desk é o primeiro e mais
importante ponto de contato com o usuário.
 Usa o CMDB freqüentemente consultando e
atualizando CIs

Processo de Gestão de Incidentes





Atividades da Gestão de Incidentes
 Registro  Investigação & diagnóstico:
 Categorização:  O que realmente ocorreu
 Tipificação do Hardware  Ordem dos eventos e fatos
 Tipificação do Software  Pesquisa de ocorrências
 Priorização:  Resolução e recuperação:
 Urgência (3):  Resolver (usando recursos
 Baixa, Média ou Alta internos e parceiros) e testar
 Prioridade (5):  Fechamento:
 Planejada, Baixa, Média,  Categorizar fechamento
Alta ou Crítica  Checar satisfação do usuário
 Diagnóstico inicial  Documentar incidente
 Escalação:  Incidente recorrente ou novo
 Funcional e hierárquica  Fechamento formal

Escalação e níveis dos incidentes
 Funcional (Horizontal): • Atendentes
1º Nível
 Envolvem mais • Suporte inicial e resolução

privilégios ou acesso à
especialistas técnicos
• Analistas
para resolução 2º Nível • Diagnóstico e resolução
 Os limites de áreas
podem ser excedidos
• Engenheiros
 Hierárquica (Vertical): 3º Nível • Diagnóstico e resolução

 Escalação direta aos
níveis hierárquicos
• Especialistas/Fornecedores
superiores, independe Consultoria • Diagnóstico e resolução
de competências

Benefícios e modelos da Gestão de
Incidentes
 Detecção e resolução de  Os modelos deve incluir:
incidentes  menor  Passos necessários para a
downtime  maior gestão do incidente
disponibilidade  Ordem cronológica de
execução dos passos,
 Alinhamento atividades de considerando paralelismo e
TI com prioridades de dependências aplicáveis
negócio  Responsabilidades
 Identificação de pontos de  Tempo máximo e limiares
melhoria do serviço das atividades
 Procedimento de escalação
 Identificação de novas
 Preservação de evidências,
oportunidades de negócio
especialmente para
(serviços, treinamento, etc.) segurança e capacidade


Interfaces e problemas comuns
 A falta de compromisso da
gerência
 Falta de SLAs com clientes
 Falta de conhecimento ou
de recursos para resolver
os incidentes
 Baixo nível de integração
com outros processos
 Falta ou inadequação das
ferramentas de software
 Usuário e staff de TI
burlando o processo

Requisições de Fulfillment
 Requisição de Serviços (Service Request) (SR):
 Requisição do usuário para suporte, entrega, informação, conselho
ou documentação, não sendo uma falha na infra-estrutura de TI.
 Exemplos: reset de senha, criação de usuário, restauração de
backup, troca de impressora de lugar, instalação de software, etc.
 Podem ser pequenas mudanças de baixo risco e alta freqüência.
 Propósito:
 Entregar as SR evitando congestionamento ou obstrução da Gestão
de Incidentes e de Mudanças.
 Considerações:
 Muitas empresas ficam a vontade para gerir as SR junto com os
incidentes. Mas, as SR são “eventos que podem ser planejados”.
 A junção ou separação depende do volume e estrutura da empresa.
 As SR também podem ter workflows bem definidos para cada caso.

Objetivos e importância das SR
 Objetivos para os  Importância:
usuários e clientes:  Acesso rápido e efetivo
 Um canal para solicitar e a serviços padrões
receber serviços padrões  Melhora produtividade e
e entregas de qualidade do staff
componentes (ex: mídia,  Redução da burocracia
licenças, etc.) e do custo de operação
 Informações de  Aumenta o nível de
disponibilidade controle
 Assistência com  Aumenta o poder de
informações, reclamações negociação com
e comentários fornecedores

Atividades e interfaces das SR
Menu de • Opções de SR  Interfaces:
Seleção • Auto-serviço  Service Desk:
Porta de entrada da SR
Aprovação • Se necessário
Financeira • Interna/Cliente  Gestão de Incidentes:
Pode atender boa parte
Outras • Regulatória das SR (depende do
Aprovações • Interna/Cliente modelo de entrega)
 Gestão de Liberações e
• Workflow por SR Distribuição & Gestão
Entrega
• Buscar o FCR de Configuração e
Ativos de Serviços:
• Fechar a SR
Fechamento Muitas SR referem-se a
• No Service Desk Liberações e CIs

Gestão de Problemas
 Conceitos:
 Problema:
 Causa desconhecida de um ou mais incidentes (existentes ou não).
Falha na
 Erro conhecido: infra-estrutura
 Problema com causa raiz e solução determinadas.
 RFC (Request For Change): Incidente
 Solicitação de mudança para eliminação de um Erro Conhecido.
 Gestão de Problemas: Problema
 Processo responsável por gerir o ciclo de vida dos problemas, evitar
novos problemas, reduzir a ocorrência ou recorrência de incidentes Erro
e minimizar o impacto de incidentes que não podem ser previstos. Conhecido

 Objetivos:
 Priorizar, pela necessidade do negócio, e resolver os problemas rápida e RFC
eficientemente.
 Minimizar os incidentes resolvendo proativamente os erros conhecidos.
 Melhorar a produtividade da equipe de suporte provendo informações relevantes. Resolução
Estrutural


Sobre a Gestão de Problemas
Importância Sub-processos
 Garante a disponibilidade e Reativo Proativo
a qualidade do serviço em
conjunto com Gestão de • Atua • Procura
Incidentes e de Mudanças mediante descobrir
gatilhos da e resolver
 Reduz o downtime e as Operação futuros
interrupções críticas de problemas
 Valores derivados: Serviços • É parte da
 Alta disponibilidade • Gestão de Melhoria
 Alta produtividade do staff Problema Contínua
 Redução de custos de
e Erro de
paliativos e de incidentes
Conhecido Serviços

Processo de Gestão de Problemas
 




Atividades da Gestão de Problemas
 Detecção  Soluções de contorno
 Registro  Registro do erro conhecido
 Categorização  Resolução
 Priorização  Fechamento
 Investigação e  Revisão de problemas
Diagnóstico, métodos: grandes (críticos)
 Investigação cronológica  Proativo:
 Análise de valor da dor  Detecção de erros no
(pessoas, duração e custo) desenvolvimento
 Método de Kepner e Tregoe  Registro na KEDB (Known
 Brainstorming Errors Data Base ou Base de
 Diagrama de Ishikawa Dados de Erros
 Análise de Pareto Conhecidos)

Análise de Pareto
 Análise de falhas: 100

20% Causas  80% Falhas
98 99 100
90 94 96
91
Causa % % Acum 80 86
80
Placa de Rede 35% 35% 70
60 61
Corrupção de arquivo 26% 61% %
50
Conflito de IP 19% 80% % acum
40
35
SO do servidor 6% 86% 30
Erro de script 5% 91% 20
Mudança não testada 3% 94% 10
Erro do operador 2% 96% 0

Falha de backup
Mudança não testada
Placa de Rede

Conflito de IP
Corrupção de arquivo

SO do servidor

Erro do operador
Erro de script

Tentativa de invasão

Falha de disco
Falha de backup 2% 98%
Tentativa de invasão 1% 99%
Falha de disco 1% 100%


Exemplo do Diagrama de Ishikawa


Método de Kepner e Tregoe
• Definição do problema, descrevendo
Definição claramente o desvio do esperado

• Descrever o problema em termos de:
Descrição identidade, localização, tempo e amplitude

Causas • Estabelecer as possíveis causas

• Analisar as causas, identificar e testar a
Teste causa mais provável

• Verificar dentre as causas a que realmente
Verificação provoca o problema


Interfaces da Gestão de Problemas
Estratégia Projeto de Transição Melhoria
de Serviços Serviços de Serviços Contínua
Gestão Financeira Gestão de Gestão de Gestão do Nível de
• Fornece o custos das Disponibilidade Mudanças Serviço
soluções • Sugere medidas pró- • Submete e gerencia as • Problemas afetam o SLA
ativas RFC das soluções • SLM sugere medidas pró-
•  downtime e  uptime ativas

Gestão de Gestão de
Capacidade Configuração
• Investiga as causas • Pontos de falha
• Apóia proativamente • Analisa o impacto da
solução

Continuidade dos Gestão de
Serviços de TI Liberação e
• Problemas são pontos de Distribuição
análise de continuidade • Aplica a solução no
ambiente de produção


SKMS: Service Knowledge Management System
Sistema de Gestão do Conhecimento de Serviço


Gestão de Acessos
 Propósito:
 Garantir o acesso de usuários autorizados ao uso do serviço e
evitar o acesso dos demais usuários.
 Em algumas organizações também é chamado de Gestão de Direitos
ou Gestão de Identidade.
 Objetivos:
 Garantir a execução da política de controle de acesso da Gestão de
Segurança.
 Garantir a confidencialidade das informações.
 Garantir a eficiência do controle de direitos do staff.
 Reduzir o nível de erros na entrada de dados sensíveis ao negócio
por desconhecimento ou uso indevido.
 Permitir a auditoria e rastreabilidade do abuso dos serviços.
 Habilitar a concessão e retirada de direitos e a adequação legal.

Conceitos da Gestão de Acesso
 Acesso:  Serviços ou grupos de
 Refere-se ao nível e serviços:
extensão de uma  Um usuário ou grupo de
funcionalidade do usuários pode ter
serviço que o usuário acesso a serviços ou
quer usar grupos de serviços
 Identidade:  Serviços de diretório:
 Forma de identificação  Tipo de ferramenta que
única de cada usuário é utilizada para
 Direitos (privilégios): gerenciar acessos,
direitos e usuários e
 Funcionalidades que o
grupos
usuário pode acessar

Atividades da Gestão de Acesso
 Mudanças de estados:
Requisitar
acesso
Verificar  Mudanças de funções
 Promoções ou
rebaixamento
 Transferências
Monitorar
Fornecer  Morte, abandono ou
estado da
direitos
identidade renúncia
 Aposentadoria
 Ação disciplinar
Registrar e Remover ou
rastrear restringir  Demissão
acessos direitos  Etc.

Atividades Comuns:
Monitoramento e controle
 Conceitos:
 Monitoramento:
 Refere-se a atividade de observar uma situação e detectar mudanças
que acontecem ao longo do tempo.
 Reportar:
 Refere-se à atividade de analisar, produzir e distribuir um relatório da
saída de uma atividade de monitoramento.
 Propósito:
 Medir e controlar o serviço baseado no monitoramento, reportar e
se necessário gerar ações subseqüentes.
 Consideração:
 Como o monitoramento é uma atividade operacional, para agregar
valor, todas as fases anteriores do ciclo de vida dos serviços devem
garantir que as medidas e controles sejam definidos e executados.

Monitoramento simples
 A saída é medida e comparada
com um padrão aceitável, se não
aceitável uma ação corretiva é
acionada
 Tipos:
 Sistemas de ciclo aberto:
 Executa uma atividade independente
das condições do ambiente
 Ex.: Sistemas de backup (executa o
backup nas datas e horas definidas)
 Sistemas de ciclo fechado:
 Monitora o ambiente e responde a
mudanças nele
 Ex.: Balanceamento de carga


Monitoramento complexo
1 ciclo externo (geral)
Controlando o processo

3 ciclos simples (internos)
Controlando 3 atividades

Processo com 3 Atividades


Usos do monitoramento
 Performance de atividades em um processo ou
procedimento
 Ex.: Gestão de Incidentes (monitora e escala)
 Efetividade de um processo, procedimento ou
papel
 Ex.: Gestão de Mudanças (as mudanças devem ser
implementadas no tempo e custo esperado)
 Performance de um dispositivo
 Ex.: Tempo de resposta de um servidor a plena carga
 Performance de uma série de dispositivos:
 Ex.: Tempo de resposta da aplicação para o usuário

Loop de monitoramento de ITSM


Loop de monitoramento de ITSM

 Seta 1: ajustados (ex: melhoria
 O CSI detectou que o de performance ou
serviço precisa melhorar preço)
(ex: ampliação do
portfólio ou arquitetura
 Seta 3:
errada) e submete uma  Os valores padrões
RFC para a Estratégia precisam ser ajustados
(ex: inadequado, falta
 Seta 2: de treinamento, etc.) ou
 Os SLRs precisam ser adequado às regras

Tipos de monitoramento de ITSM 1
 Ativo x Passivo:  Reativo x Proativo:
 Ativo:  Reativo:
 Verificação on-line de um  Gera uma requisição ou
dispositivo ou sistema para aciona um gatilho para um
determinar seu estado. certo tipo de falha ou evento
 Pode consumir muitos  Ex: Prompt após batch
recursos é usado no  Não é utilizado somente
monitoramento proativo para exceções
 Passivo:  Proativo:
 O próprio dispositivo gera e  Usado para detectar
transmite eventos para um padrões de eventos que
ouvinte (listener) ou agente indicam uma possível falha
 Tipo mais comum, depende  Ex: Ataque eminente
da geração dos eventos e  Requer maturidade
do sucesso do agente ou
 Podem ser ativo ou passivo
ouvinte
e vice-versa

Tipos de monitoramento de ITSM 2
 Medição contínua:  Todas as combinações
 O sistema ou dispositivo são possíveis:
é verificado em tempo
real (de tempos em
tempos) para ver se
atende ao valor padrão
Contínuo x Exceções
 Medição baseado em

Reativo x Proativo
exceções:
 Não monitora em tempo
real, somente detecta e
trata as exceções
geradas pelo dispositivo

Função: Service Desk (SD)
 Função (não processo) de Service Desk:
 Unidade funcional criada para lidar com uma série de
eventos, recebidos via: telefone, site, gerências de
monitoramento de infra-estrutura, etc.
 Objetivos:
 Deve ser o ponto único de contato dos usuários para
questões do dia-a-dia e irá gerenciar todos os
incidentes, requisições de serviços (SR).
 Sua presença é vital para o sucesso da unidade de TI.
 Ajudar os usuários a restaurar o nível normal de serviços
o mais rápido possível, sejam por incidentes ou SR.
Isto pode ou não envolver incidentes. Ex: SR de reset de senha.

Responsabilidades do SD
 Registrar incidentes e  Manter os usuários
SR, definindo categoria informados do trabalho
e prioridade  Fechar os incidentes e
 Fornecer o 1º nível de SR resolvidos
investigação e  Verificar a satisfação
diagnóstico do cliente e usuários
 Resolver os incidentes  Negociar janelas de
e SR de 1º nível mudanças com cliente
 Escalar e gerenciar os e usuários
incidentes e SR de  Atualizar o CMS, se
outros níveis combinado com SACM

Papéis de gestão do SD
 Gerente:  Supervisor:
 Gerir o SD  Gerenciar um grupo,
 Em grandes empresas turno ou clientes do SD
requer supervisores  Atividades:
 Atividades: Garantir perfil adequado
a qualquer hora no SD
Gestão geral incluindo os
supervisores Gerir os analistas
Receber escalações Receber escalações
Cuidar dos clientes Gerir relatórios
estatísticos
Reportar aos superiores
incidentes significantes Gerir treinamentos
Participar do CAB Representar SD em
reuniões
Responder pelo SD

Analistas do SD e Tipos de SD
 Analistas de TI:  Tipos de SD:
 Gerenciar incidentes e SR  Local:
alocados a ele  O SD está fisicamente próximo
 Atividades: aos usuários (por local/setor)
 Fazem suporte 1º nível  Centralizado:
 Reportar incidentes e SR  Atendimento centralizado,
suportado por equipes de
 Super-usuários: apoio
 Analistas de negócios  Virtual:
 Atividades:  O SD é distribuído mas
 Facilitar a comunicação acessado por uma rede global
 Gerir expectativas de uso  Seguindo o sol:
 Treinar usuários da área  O SD segue o sol pelo mundo
 Suportar incidentes comuns  Grupos especializados:
 Apoiar novas liberações  Cada grupo de algo específico

Tipos de SD – Diagramas 1
Local Centralizado

Atendimento centralizado, mas
suportado por equipes de apoio

Por local ou departamento


Tipos de SD – Diagramas 2
Virtual Seguindo o Sol

Rede global coordenada, com turnos abertos
e fechados pelo fuso-horário do local
Uma rede mundial proporciona cooperação

Benefícios do SD
 Melhora o serviço, a percepção e a satisfação do cliente
 Aumenta a acessibilidade do serviço
 Melhora a qualidade e a rapidez das SR
 Melhora a comunicação e o trabalho em equipe
 Aumenta o foco e a proatividade da equipe
 Reduz os impactos negativos no negócio
 Melhora a gestão e o controle da infra-estrutura
 Melhora o uso dos recursos de TI e melhora a
produtividade do staff
 Oferece mais e melhores informações para decisão
 Fornece um ponto de entrada para novos talentos no staff

Função:
Gestão de Operações de TI
 Gestão de Operações:
 Refere-se ao departamento, grupo ou equipe responsável pela
organização operacional das atividades cotidianas.
 Gestão de Operações de TI:
 É a função responsável pela gestão e manutenção on-line da infra-
estrutura de TI para garantir a entrega do nível de serviço de TI
combinado com o negócio.
 Objetivos:
 Garantir que os dispositivos, sistemas ou processos estejam
rodando ou trabalhando.
 Transformar os planos em ações.
 Focar na execução de atividades diárias ou de curto-prazo, que
serão executadas várias vezes por longos períodos de tempo.
 Alocar o staff técnico correto na execução destas atividades.

Papéis da Gestão de Operações TI
 Controle de operações:  Gestão de facilidades:
 Visão de execução e  Gestão física do
monitoramento de ambiente de TI
atividades e eventos  Data center, salas,
 Tarefas: computadores, sites de
Console de gestão recuperação e ar
Agendamento do condicionado
trabalho  Coordenação de
Backup e restauração projetos
Gestão de impressões e
saídas eletrônicas  Consolidação de
Atividades de servidores
manutenção  Gestão de contratos

Perfil e Objetivos da G. O. de TI
 Perfil:  Objetivos:
 Entender como usar a  Manter a estabilidade dos
tecnologia para serviços processos e atividades
 Entender a importância e diárias da organização
impacto dos serviços para o  Exames detalhados e
negócio implementar melhorias para
 Descrever manuais e melhorar os serviços, reduzir
procedimentos de TI custos mantendo a
 Diferenciar métricas estabilidade
 Reportar a eficácia e a  Aplicação rápida de perfis
eficiência da infra operacionais para
diagnosticar e resolver
 Como a performance de TI qualquer falha nas
afeta a entrega de serviços operações de TI que
 Balancear custos e requisitos ocorrerem

Gestão de Operação de TI e
Projeto de Serviços
 A Operação de Serviços  Benefícios do Projeto de
normalmente está focada Serviços:
na execução de  Clareza dos benefícios
procedimentos padrões, e esperados e atingidos
tende a não utilizar o  Mais visibilidade do que
Projeto de Serviços precisa ser feito e como
 Facilidade na distribuição do
 Por exemplo, grandes trabalho
mudanças na infra-  Maior facilidade de obter os
estrutura usualmente recursos necessários
geram melhores  Alta consistência e melhoria
resultados, em termos de da qualidade
custos e prazos, se  Aumento da credibilidade por
gerenciadas como projetos atingir objetivos e resultados

Staff Operacional no Projeto e
Transição de Serviços
 Todo o staff de TI deve  Neste contexto, suportável
estar envolvido no Projeto significa:
e na Transição de Serviços  Capaz de ser suportado pelo
garantindo que o serviço time técnico
entre no ar em boas  Não gere impacto extra em
condições trabalhos, processos e
agendas
 Adicionalmente o staff de  Sem nenhum custo extra não
Operação deve estar esperado ou não planejado
envolvido no começo do  Sem nenhuma complicação
Projeto e da Transição legal ou regulatória
para garantir que o serviço  Nenhuma complicação de
seja suportável quando suporte por parte do staff
entrar em Operação técnico ou de parceiros


Avaliação e Gestão de Riscos na
Operação de Serviços
 Existem várias  Outras situações que
situações na Operação requerem avaliação de
riscos e impactos:
de Serviços que é
 Falhas ou potenciais falhas
imperativo fazer uma (reportadas pela Gestão de
avaliação de riscos e Eventos)
agir rapidamente  Novos projetos ou serviços
entrando em produção
 As situações mais  Riscos ambientais (contexto
comuns, que requerem externo e continuidade)
avaliação de riscos,  Fornecedores novos ou não
envolvidos em componentes
são as Mudanças e os chaves de serviços
Erros Conhecidos  Riscos de segurança

Função:
Gestão de Aplicações
 Propósito:
 Gerir as aplicações por todo o ciclo de vida delas.
 Execução:
 Esta função é executada por um departamento, grupo ou equipe
envolvida na gestão e suporte operacional de aplicações,
dependendo do tamanho da empresa.
 Objetivos:
 Suportar os processos de negócio da organização ajudando na
identificação de requisitos funcionais e de gestão de aplicações.
 Apoiar projeto, desenvolvimento, testes, distribuição e melhorias de
aplicações.
 Melhorar o projeto e a resiliência das aplicações com custo efetivo.
 Desenvolver e manter competências adequadas para diagnosticar e
resolver rapidamente qualquer falha técnica nas aplicações.

Princípios da Gestão de Aplicações
 Comprar ou fazer:  Modelos operacionais:
 Decisão do CTO (Chief  Descrição do ambiente
Technical Officer ou Diretor operacional onde a aplicação
Técnico) ou de um comitê, irá rodar
apoiada pela Gestão de  O modelo será utilizado no
Aplicações através de: Projeto e Transição de
 Tamanho da aplicação e Serviços para:
carga de trabalho  Simulação dos ambientes
 Requisitos de gestão, durante fases de testes e
administração e segurança transição
 Custo de desenvolvimento e  Garantir que a aplicação
de operação (incluindo staff) seja dimensionada de forma
 Requisitos de acesso para que os requisitos ambientais
relatórios e integrações sejam documentados e
 Customização na aplicação entendidos por todos
x Extensão de outras

Ciclo de vida das aplicações
 Nomes do ciclo de gestão
e desenvolvimento:
 SLC: Software Lifecycle
 SDLC: Software
Development Lifecycle
 Abordagens usadas:
 SSADM: Structured Systems
Analysis and Design
Methodology
 DSDM: Dynamic Systems
Development Method
 RAD: Rapid Application
Development
 etc.

Fases do ciclo de vida da aplicação
 Requisitos:  Distribuição:
 Fase onde requisitos são
Transição de
 Nesta fase, aplicação e modelo
coletados:
 Os requisitos podem ser:
Serviços
de operação são distribuídos, ou
seja, entregues para Operação
 Funcionais, gestão, usabilidade,  Operação:
arquiteturais, interface e SLR  Nesta fase, ocorrem as entregas
 Projeto:
Projeto de Operação de
de serviços para os clientes e
 Fase onde os requisitos são para o negócio da empresa
traduzidos para especificações
Serviços Serviços
 O desempenho da aplicação é
 Construção: constantemente comparado aos
níveis de serviço esperados
 Nesta fase a aplicação e o
modelo de operação são  Otimização:
construídos Melhoriaanalisados para
Contínua
 Nesta fase, os resultados do
 Os componentes da aplicação serviço são
são codificados ou comprados,
integrados e testados
de Serviços
identificar pontos de melhoria ou
manutenção das aplicações

Papéis da Gestão de Aplicações
 Gerente de aplicações  Arquitetos e analistas
ou líderes de equipe: de aplicações:
 Um para cada equipe  Adequação de requisito
ou aplicação às aplicações
 Tarefas:  Tarefas:
Liderança, controle e Identifica necessidades
decisões da equipe e de Requisitos de alto nível
aplicações Análises custo-benefício
Fornece conhecimento e Desenvolve o modelo
liderança técnica operacional, padrões de
Garante treinamento dimensionamento e
Comunicação com modelo de performance
usuários e alta gestão Requisitos de aceitação

Função: Gestão Técnica
 Propósito:
 Fornecer expertise técnica e gerência da infra-estrutura
de TI
 É feita por grupos, departamentos ou equipes
 Objetivos:
 Melhorar o projeto e a resiliência da topologia técnica a
um custo-ótimo
 Utilizar perfis técnicos adequados para manter a infra-
estrutura técnica em ótimas condições
 Utilizar perfis técnicos para diagnosticar e resolver falhas
técnicas


Organização da Gestão Técnica
 Esta gestão é fornecida  Exemplos de times:
usualmente por mais de  Mainframe
um setor ou grupo  Servidores
 Em cada setor as funções  Storage
são agrupadas por área de  Redes (WAN/LAN)
conhecimento técnico  Desktop
 Banco de dados
 Cada área técnica requer
 Middleware (integrações)
um perfil específico, alguns
 Serviços de diretório
generalistas outros
 Internet e web (acessos)
especialistas
 Mensagens (e-mails)
 Cada perfil determina as
 Telefonia baseada em IP
necessidades de gestão
 Etc.

Papéis da Gestão Técnica
 Gestores ou líderes  Arquitetos e analistas
técnicos: técnicos:
 Gerencia cada equipe ou  Atividades padrões:
setor técnico  Levantamento de
 Responsabilidades: necessidades
 Liderança, controle e  Requisitos de alto nível x
decisões da equipe orçamentos x restrições
 Conhecimento e liderança  Define e mantém as
técnica relações entre sistemas
 Garantir treinamento  Análises custo-benefício
técnico, sensibilização e  Desenvolver modelos de
níveis de experiência operação
 Responder aos gerentes  Garantir configuração da
superiores sobre questões infra-estrutura em relação à
de sua equipe ou setor arquitetura e ferramentas


Métricas da Gestão Técnica
 Dependem diretamente da tecnologia aplicada
 Seguem algumas genéricas:
 Saídas combinadas:
 Contribuições (+/-) para o negócio, taxa de transações, treinamentos,
registro de problemas na KEDB, etc.
 Métricas de processos:
 Tempos de resolução de incidentes (2º e 3º nível) e problemas, número
de escalações, RFCs bem sucedidas, etc.
 Performance tecnológica:
 Taxa de uso, disponibilidade, tempos de respostas, etc.
 Tempo médio entre falhas por equipamentos
 Atividades de manutenção:
 Manutenções no prazo, número de janelas perdidas, objetivos atingidos, etc.
 Desenvolvimento de perfis, competências e treinamentos

Questões de prova
 Qual é o primeiro passo do registro de um incidente?
 A. Registrar os dados do incidente.
 B. Atribuir um número ao incidente.
 C. Pesquisar as possíveis soluções do incidente.
 D. Determinar a prioridade do incidente.

 Quando a causa de um ou mais incidentes não é
conhecida, recursos adicionais são alocados para descobrir
esta causa. Qual processo ITIL é responsável por isto?
 A. Gestão de Capacidade.
 B. Gestão de Incidentes.
 C. Gestão de Problemas.
 D. Gestão do Nível de Serviços. Respostas: B e C.


Questões de prova
 Como a Gestão de Problemas contribui para aumentar o %
de solução aplicada pelo 1º nível de suporte?
 A. Analisando os incidentes abertos.
 B. Avaliando os incidentes com os clientes.
 C. Prevenindo incidentes.
 D. Disponibilizando a base de dados de Erros Conhecidos (KEDB).

 Quem é responsável por monitorar um incidente?
 A. O Gerente de Problemas.
 B. Os analistas da Gestão de Problemas.
 C. O Service Desk.
 D. O Gerente de Nível de Serviço.
Respostas: D e C.


Referências
 ITSMF. An Introduction to ITIL 2. 2006.
 ITIL – Information Technology Infrastructure Library:
www.itil.co.uk
 ITIL and ITSM World: www.itil-itsm-world.com
 Márcio Moreira. Apresentações sobre ITIL (5º CONTECSI e
Uniminas). www.websec.com.br/marcio/
 OGC. Service Operation. TSO. Londres. 2007.
 OGC. The Official Introduction to the ITIL Service Lifecycle.
TSO. Londres. 2007.
 OGC - Office of Government Commerce: www.ogc.gov.uk
 Ray Hoving Associates LLC: www.rayhoving.com


Marcio iti lv3_5_operacao_deservicos

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Marcio iti lv3_5_operacao_deservicos

Mais de fernandao777

Marcio iti lv3_5_operacao_deservicos