ENTREGA E SUPORTE

EM TECNOLOGIA DA
INFORMAÇÃO

autor do original
CHRISTIAN GANZERT

1ª edição
SESES
rio de janeiro  2015
Conselho editorial  fernando fukuda, luis di marcello, jeferson ferreira fagundes

Autor do original  christian ganzert

Projeto editorial  roberto paes

Coordenação de produção  rodrigo azevedo de oliveira

Projeto gráfico  paulo vitor bastos

Diagramação  fabrico

Revisão linguística  aderbal torres bezerra

Imagem de capa  nome do autor  —  shutterstock

Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida
por quaisquer meios (eletrônico ou mecânico, incluindo fotocópia e gravação) ou arquivada em
qualquer sistema ou banco de dados sem permissão escrita da Editora. Copyright seses, 2015.

Diretoria de Ensino — Fábrica de Conhecimento

Rua do Bispo, 83, bloco F, Campus João Uchôa
Rio Comprido — Rio de Janeiro — rj — cep 20261-063
Sumário

Prefácio 7

1. Continuidade e Capacidade 10
Gerenciamento da Continuidade 11
Responsabilidades 17
Gerenciamento de Capacidade 25

2. Gerência Financeira e Disponibilidade 46

Gerenciamento Financeiro de TI 47
Visão Geral do Processo 48
Benefícios 51
Principais Áreas 52
Custos de Serviços de TI 52
Modelo de Custos 53

3. Indicadores de Desempenho e Qualidade

e Planejamento de Capacidade 78

Indicadores de Desempenho e Qualidade de Serviço em TI 79

Gerenciamento da Capacidade 93
4. Custos dos Serviços de TI e Análise
das Vulnerabilidades 104

Gerenciamento de Custos em TI 105

Análise e Vulnerabilidade em TI 109

5. Gerenciamento de Crise e Melhoria Contínua 118

Plano de Gerenciamento de Crise e Recuperação de Negócios 119

Processo de Melhoria Contínua 128
Prefácio
Prezados(as) alunos (as)

Atualmente é impossível imaginar a vida das pessoas sem a tecnologia da

Informação. Este é um fenômeno relativamente recente. Basta verificarmos
que a internet, no modelo que se tornou absoluto sucesso, foi formatada por
Tim Berners-Lee em 1990. De lá para cá ela foi invadindo a vida das pessoas
e principalmente modificando o relacionamento de negócios dos agentes do
mundo corporativo.
De fato, a internet facilitou o relacionamento das pessoas, das empresas
com seus clientes e fornecedores elevando o mercado a um nível global. Além
disso, se popularizou a partir do momento que invadiu a telefonia móvel, fican-
do acessível a qualquer momento e em qualquer lugar, a partir de um smartfo-
ne.
Para amparar este crescimento sem precedentes, ambientes propícios de
infraestrutura tecnológica precisaram ser criados, tanto no ambiente público e
corporativo, quanto nas diversas faixas de operação das empresas de telecomu-
nicações. As empresas (incluindo o serviço público) se aparelharam para aten-
der a demanda crescente por soluções de serviços on-line e a massa de informa-
ção decorrente deste crescimento, necessitou de sistemas de armazenamento
cada vez maiores.
A tecnologia da informação provê soluções de integração comercial, social
e de serviços fascinantes, entretanto contêm em seu arcabouço de processos,
riscos inerentes a dependência cada vez maior de nossas vidas cotidianas ao
pleno funcionamento de toda esta infraestrutura tecnológica, composta por
data-centers e seus servidores, linhas de comunicação de dados de alta veloci-
dade, serviços de BigIp e BigData, servidores locais, aplicativos para celulares,
aplicativos para desktop, proteção e segurança de rede, backup de dados, servi-
ços de controle e manutenção de energia em sistemas de nobreak, redundância
crítica de provimento de serviços e recursos críticos e uma seleção sem fim de
outros exemplos que dariam um capítulo exclusivo.
Este livro contém em seu escopo as melhores práticas estabelecidas
internacionalmente para a manutenção deste grande negócio. Conven-
cionou-se chamar o setor da empresa responsável pelos serviços desta na-
tureza de “Equipe de TI” ou “Help Desk” e atualmente “Service Desk”. Sua

7
atuação perpassa os sistemas próprios, a administração de contratos ter-
ceirizados, a gestão dos riscos, a governança corporativa e o conhecimento
mais íntimo dos processos envolvidos, medindo e analisando os indicadores
gerados por ferramentas de controle. As metodologias estão ancoradas nas
duas principais suítes de melhores práticas existentes, o ITIL (Information
Technology Infrastructure Library) mais diretamente ligada à Infraestrutura, ope-
ração e manutenção dos serviços e o COBIT (Control Objectives for Information
and related Technology) um modelo do tipo framework, mais voltado à gover-
nança. Elas incorporam o que existe de mais atual para o efetivo entendimento
e controle deste grande negócio conhecido como Tecnologia da Informação.
Falaremos destas suítes e de outros conceitos complementares no decorrer
deste livro, apresentados em seus mínimos detalhes, comentadas e colocadas
em situações cotidianas, para sua melhor compreensão.
Contudo é importante ressaltar que as bibliotecas do ITIL V3, utilizadas
como uma das principais fontes de informação deste livro, é composta de 5 vo-
lumes de cerca de 400 páginas cada um, o que soma cerca de 2000 páginas,
enquanto este livro tem pouco mais de 100 páginas, o que determina um conte-
údo bastante resumido. Sugerimos que o aluno busque por informações mais
detalhadas nas referências bibliográficas, caso queira aprofundar seus conhe-
cimentos a respeito das práticas aqui descritas.
 1
Continuidade e
Capacidade
1  Continuidade e Capacidade
Continuidade em tecnologia significa “o que fazer se parar de funcionar”. São
medidas objetivas e práticas que tem a intenção de estabelecer rotinas alterna-
tivas para os negócios de uma organização continuarem funcionando no caso
de indisponibilidade. Este é o assunto deste capítulo.
Precisamos conseguir garantir a capacidade das tecnologias manterem a ope-
ração do negócio, como calcular seu custo e entregar por valores justos e acessí-
veis para os operadores de negócios da organização seremos capazes de garan-
tir sua manutenção em alto nível? Gerenciar a capacidade é fazer isso. Vamos
entender os processos para realiza-la com sucesso.

OBJETIVOS
Neste capítulo você deverá aprender a:
• Definir um plano de continuidade;
• Definir as responsabilidades para continuidade;
• Definir as estratégias que garantam a continuidade;
• Planejar a continuidade, as respostas emergenciais, o gerenciamento de crise e a recu-
peração dos serviços;
• Implementar e atualizar os plano de continuidade;
• Entender a gerência da capacidade;
• De quem são as responsabilidades;
• Como planejá-la e quais os seus benefícios;
• Implementar e medir o seu desempenho.

REFLEXÃO
No seu dia a dia você precisa estabelecer continuidade para situações imprevistas que im-
peçam a execução de suas rotinas. Se durante a noite a energia acaba, é bom ter uma vela
sempre à mão (hoje em dia acendemos a lanterna do celular). Com certeza você já deve ter
ouvido a expressão “Estamos trabalhando off-line”, o que significa que um serviço que deveria
estar conectado pela internet, está sendo executado desconectado. Essa medida, que é
tratada de maneira trivial pelos operadores, demonstra uma atividade do plano de continui-
dade da organização executora desta operação. O serviço continuou a ser prestado para o
cliente, mesmo com uma falha de tecnologia.

10 • capítulo 1
Antes da popularização (parece que é muito antigamente, mas não é) a tecnologia tinha sem-
pre um custo alto e uma capacidade para resolver os problemas da organização de caráter
duvidoso. Isso acontecia porque os clientes, por não conhecer os aspectos técnicos, acei-
tavam como bom qualquer resultado obtido, afinal era moderno. Hoje tudo mudou e o que
interessa é o resultado prático e a concorrência de níveis elevadíssimos não permite vacilo. É
preciso ter capacidade para manter a tecnologia na linha de frente da inovação dos negócios
da organização. Vamos ver como isso é possível?

1.1  Gerenciamento da Continuidade

1.1.1  Introdução

Definimos continuidade como sendo o estado de um serviço ou componente

sempre ativo em operação sem falhas garantindo a operação do negócio.
Se falhas não ocorressem não seria necessário gerenciar a continuidade.
Continuidade diz respeito ao negócio, ou seja, ele não pode parar, mesmo que
a tecnologia não consiga suportá-lo. E se falhas acontecem, sendo parte de to-
dos os negócios, precisamos estar preparados para agir quando acontecerem.
Neste capítulo falaremos da importância da continuidade na manutenção
dos processos de negócio de uma organização e sua gerência, de como uma
organização deve se preparar para que os negócios continuem na ocorrência de
falhas e quais as reponsabilidades envolvidas nestes processos.
Falaremos também sobre a estratégia que deve ser adotada para que a conti-
nuidade dos negócios seja mantida a partir de uma análise de vulnerabilidades
(elas sempre existem em todas as organizações).
Se agirmos de acordo com estes indicadores de melhores práticas, quais be-
nefícios poderemos obter? Trataremos também da necessidade de mantermos
o plano de continuidade constantemente atualizado em face das atualizações
tecnológicas cotidianas.

1.1.2  A Importância da Continuidade e da sua Gerencia

Atualmente, a grande maioria das organizações tem uma grande dependência

das tecnologias de informação para suas operações de negócio.
Esta dependência vai desde a manutenção de seus negócios em si, passa pelo
ambiente de vendas, pelo relacionamento com seus clientes e fornecedores, pelo

capítulo 1 • 11
dimensionamento da participação dos colaboradores da empresa nos processos,
por todas as atividades de controle do uso da própria tecnologia… enfim, para a
grande maioria das organizações é impossível operar sem o suporte da TI.
Quando um serviço de TI falha não existe mais a dúvida se haverá prejuízo à
operação, a questão é saber o tamanho do problema e o que fazer para sua cor-
reção. Também importante é conseguir a reativação do processo em questão
no menor lapso de tempo possível.
Para que isso possa ocorrer de forma padronizada e eficiente é que existe a
gerência da continuidade. Não se trata de monitorarmos os serviços para verifi-
carmos sua estabilidade e sua resistência à falhas, isso é gerenciar disponibilida-
de. Trata-se de verificar como os negócios dependem da disponibilidade e de que
forma a continuidade das operações de sustentação dos negócios da organização
podem ser mantidas, mesmo na ausência momentânea de serviços de TI.

ATENÇÃO
A prevenção é uma grande arma para a manutenção da continuidade e os profissionais que
mais de destacam no exercício desta gerência em particular, são aqueles que conseguem
estar adiante do desastre, aqueles que conseguem prever a tragédia, anunciada ou não.

No ambiente de tecnologia, decisões de continuidade devem estar prontas,

devem fazer parte dos planos de ação do Service Desk, devem ser do conhecimen-
to de todos os envolvidos. Devem ser treinadas em sua execução crítica para que,
nos casos em que necessitem ser tomadas, sejam executadas com perfeição.
À gerência cabe o planejamento destas ações, sua execução e direção, bem
como a medida dos resultados destas ações e seu estudo pormenorizado para o
exercício da melhoria contínua dos processos.
Grandes organizações são estruturadas para que a gerência de continuida-
de dos processos de negócio, principalmente os críticos (aqueles que têm rela-
ção direta com a operação) possa ser exercida de forma proativa, tentando se
antevir ao desastre e não para resolvê-lo depois de ocorrido
Não é uma qualidade trivial. O seu desenvolvimento depende de muito co-
nhecimento técnico, empírico e também de muita experiência adquirida no
campo das operações. Portanto caberá ao analista adquirir o conhecimento ne-
cessário ao exercício desta gerência não apenas no conteúdo deste livro ou nas
suítes de melhores práticas, mas também no aprendizado cotidiano, no exercí-
cio de suas funções e de suas observações no campo de trabalho.

12 • capítulo 1
 A figura 1 demonstra um mapa adaptado dos processos descritos no ITIL
V3 para Gerência da Continuidade dos Serviços de TI. Os mapas do ITIL são
sempre demonstrados no formato “Ciclo de vida”. Mas para finalidade didá-
tica, este modelo sequencial é mais adequado. Porém é necessário que fique
claro que as diretrizes e atividades do processo são revistas e adaptadas conti-
nuamente, então este processo se repete em ciclos contínuos que perdurarão
enquanto o negócio existir e for dependente das tecnologias que o mantém.

Estágio 1 Iniciar GCN

Iniciação

Estágio 2
Necessidades e Análise de impacto no negócio
estratégia

Avaliação de risco

Estratégia de continência
dos serviços em TI

Estágio 3
Planejamento da
Implementação
organização e da
implementação

Implementar
providencias Desenvolver planos Implementar medidas
para recuperação de recuperação de redução de risco

Desenvolver precedimentos

Teste inicial

Revisão e Teste Gerenciamento

auditoria de mudanças
Educação e
consciência Treinamento

Garantia

Estágio 4
Gerenciamento operacional

Figura 1 – Processo de Gerenciamento de Continuidade

Adaptado ITIL V3 - (ITIL,2014).

capítulo 1 • 13
1.1.3  Plano de Continuidade do Negócio

O plano de continuidade de negócios é a resposta natural à análise de impacto.

A empresa precisa continuar funcionando, o que fazer se os serviços de TI fa-
lharem ou operarem em condições abaixo dos níveis aceitáveis?
A visão de negócio de um administrador tende a ser mais voltada à realiza-
ção da operação, obtenção de resultados como lucro, aumento do Market Sha-
re, escoamento da produção, vantagens com fornecedores, enquanto o gerente
de TI estará preocupado com o número de requisições ao site, volume armaze-
nado no banco de dados, capacidade de recuperação de sistemas com alto nível
de stress, sistema de segurança baseados em firewall e assim por diante.

CONCEITO
Market Share – Participação no mercado.

Para que o plano de continuidade de negócios tenha eficiência, precisa ter

o olhar do administrador. As operações críticas devem ser prioritárias e o plano
deve olhar para elas em primeiro lugar.
Uma empresa que tem sua operação baseada em vendas pela internet, ob-
viamente terá um plano de continuidade de negócios que privilegia a manuten-
ção das infraestruturas necessárias ou os serviços contratados tendo em vista a
manutenção deste serviço sem interrupções.
A análise de impacto com certeza já sinalizou ao analista que este é o ponto
numero 0 de sua escala de prioridades. Se este serviço parar, a empresa para.
Na verdade, o plano de continuidade de serviços de TI deverá estar alinhado
de tal forma ao plano de continuidade de negócios, que suas prioridades obe-
deçam a mesma ordem. As operações constantes no segundo com os serviços
que as suportam no primeiro. Se o catálogo de serviços foi montado a partir das
diretrizes de negócios, este alinhamento ocorrerá de forma natural.
É uma boa ideia adotar sistemas de checklist para verificação de serviços,
como parte das rotinas de manutenção do plano de continuidade de negócios.
Muitas vezes situações de falha são originadas pelo aumento de utilização de um
serviço e a rotina de checagem periódica pode revelar a necessidade de aumento
da disponibilidade deste serviço antes que ele falhe por stress ou esgotamento.

14 • capítulo 1
1.1.4  Plano de Contingências

Uma estratégia de continuidade normalmente começa pela Análise de Impacto

no Negócio (BIA, do inglês Business Impact Analisys). Ela pressupõe a investi-
gação de um desastre no negócio, se ele consegue operar com o desastre, por
quanto tempo ele se mantém e se esta manutenção depende dos serviços de TI.
Depois identificamos o quanto a organização pode aguentar de perdas com
o desastre ou interrupção de um serviço de TI.
Verificamos a velocidade do escalonamento destas perdas, avaliadas a par-
tir da Identificação dos processos críticos de negócio e a identificação do estra-
go potencial ou perda que um desastre ou interrupção de um processo crítico
de negócio podem causar à organização.
Estratégias de continuidade de serviços de TI tem influência do tipo de ne-
gócio às quais estão suportando.
Estratégias de continuidade podem ser divididas (para finalidade didática)
em duas abordagens.
A primeira diz respeito às práticas proativas, que são indicadas nos planos
de ação como preventivas. Situações de verificação e checagem periódicas que
garantam o bom funcionamento dos sistemas de TI, mantendo os negócios em
funcionamento. A apuração da efetividade destas ações é complexa, pois não
há como garantir que o procedimento tenha de fato impedido o acidente de
acontecer, mas são uma alternativa economicamente viável em muitos casos
e podem ser realizadas em conjunto com os treinamentos da equipe para os
casos de contingência, diminuindo os custos de sua aplicação.
A segunda abordagem é a clássica. Nela classificamos os tipos de ação estra-
tégica adotada para recuperação ou contingência no caso de falta de continui-
dade do negócio em razão de falha dos serviços de TI. As mais conhecidas são:
•  Nenhuma contingência. É o que ocorre quando nenhuma ação é neces-
sária. É a escolha a ser feita quando a análise de riscos(veremos adian-
te) sugerir que a falha do sistema não afeta o negócio de forma cabal.
Em alguns casos é possível que se deparem com esta situação. Man-
tenha uma documentação com a ciência e anuência das partes envol-
vidas, para evitar complicações posteriores quanto a responsabilidade
(no caso de um desastre ocorrer e nenhum plano de recuperação do
serviço estiver disponível).

capítulo 1 • 15
 •  Procedimentos Administrativos. Nos casos em que a recuperação de um
serviço de TI for muito demorada, é possível recorrer a procedimentos
administrativos, como por exemplo a utilização de formulários de papel,
para execução do serviço.
•  Estratégia de fortificação. Um sistema de tal forma protegido que sua
falha é inexistente ou praticamente impossível. São os casos onde nada
pode dar errado e não há substituição para o serviço de TI. Geralmente o
custo desta estratégia é alto.
•  Arranjos recíprocos. São os casos em que organizações que utilizam in-
fraestruturas parecidas se colocam a disposição uma da outra para em-
prestarem seus serviços de TI reciprocamente. No caso de um desastre, o
serviço de TI necessário para a operação da organização será emprestado
pela outra. Também é possível, neste tipo de abordagem, que empresas
realizem a adoção de estruturas de redundância critica para suportar
seus processos de forma conjunta com empresas parceiras, rateando o
custo da aquisição para as duas organizações. A desvantagem mais evi-
dente deste tipo de abordagem estratégica é a falta de confidencialidade.
•  Recuperação Gradual (Cold stand-by) permanente ou portável. É a manu-
tenção de um território neutro, muitas vezes fora da área da organização,
com a infraestrutura de eletricidade, link de dados, linhas telefônicas, ar
condicionado e equipamentos de TI (servidores, switches, etc) para dar su-
porte às operações, onde as aplicações da organização possam migrar e
funcionar em modo alternativo até que a estrutura original possa ser res-
taurada. Atualmente espaços como este podem ser alugados, mas algu-
mas organizações preferem investir em instalações próprias por motivos
de segurança. Este tipo de estratégia também é razoavelmente cara e so-
mente se justifica pelo nível de dependência do negócio aos serviços de TI.
•  Recuperação Intermediária (Warm stand-by) interna / externa / móvel.
Esta estratégia esta ancorada na utilização de unidades móveis, para uso
interno ou externo, alugada ou comprada. O exemplo mais conhecido é
uma solução de serviços fornecida pela IBM, conhecida como IBM Truck,
um caminhão com uma série de serviços de TI oferecidos pela empresa
disponibilizados ao contratante para contingência.
•  Recuperação Imediata (Hot stand-by). É a extensão das duas anteriores. São
casos de serviços extremamente críticos onde a sobrevivência do negócio
está ameaçada. Um exemplo clássico é o sistema de operações de ações de
uma bolsa de valores. As opções de compra e venda precisam estar em sin-

16 • capítulo 1
 cronismo total e o ambiente deve estar disponível durante todo o período de
operação. A adoção de um sistema distribuído como o BigIP associado a um
sistema de cluster de servidores, por exemplo, pode garantir a continuidade
dos serviços, mesmo se o endereço original do site estiver inoperante por
qualquer motivo. As requisições direcionadas ao site original seriam desvia-
das para um site ‘espelho” e o usuário nem perceberia o ocorrido.

A adoção desta ou qualquer outra estratégia, como dito no início deste

tópico, dependerá do tipo de organização a que nos referimos. Mas é impor-
tante ter em mente que elas serão o caminho a seguir, o mapa que manterá o
negócio funcionando.

CONEXÃO
Veja alguns vídeos desta solução no site da IBM em https://www-304.ibm.com/partne-
rworld/wps/servlet/ContentHandler/stg_com_sys_technologytruck_video

1.2  Responsabilidades

As responsabilidades do analista na gerência da continuidade dos serviços

de TI estão relacionadas diretamente à continuidade dos negócios da organi-
zação. A abordagem mais atual não desvincula um do outro, em face da total
dependência das organizações às Tecnologias da Informação.
O analista deverá desenvolver e gerenciar o Plano de Continuidade dos Ser-
viços de TI para assegurar que os objetivos de recuperação do negócio possam
ser alcançados sempre.
Como consequência direta do plano de continuidade, todas as áreas cor-
relatas deverão estar prontas para responder a uma necessidade do plano
de continuidade.
Para que esta capacidade de resposta possa ser garantida, uma agenda de testes
deverá ser cumprida periodicamente, capacitando os operadores do Service Desk.
Para que o plano dê certo, toda a equipe de colaboradores envolvidos nos
processos de negócio suportados deverão ser conscientizados pela equipe do
Service Desk. Esse passo é essencial porque muitos dos problemas se iniciam na
operação do negócio e podem ter suas consequências sensivelmente diminuí-
das se os procedimentos de controle forem acionados rapidamente.

capítulo 1 • 17
 E finalmente o analista ainda será responsável pela entrega dos serviços
contingenciais no período de crise.
Comparando com a equipe de fórmula 1 do início do livro, significa que o
analista será responsável pelo plano que manterá o carro andando na pista.
Este plano deverá conter todas as ações que precisarão ser tomadas para os im-
previstos. Obviamente que se tudo der certo (o melhor dos mundos), nada deste
plano precisará ser executado.
Então, de posse do plano, o analista irá treinar a equipe para os procedimentos
em caso de imprevistos ou desastres. Cada uma das situações previstas no plano
será simulada em condições de trabalho para que a equipe possa realizar as ações
conforme o planejado. Ainda utilizando o exemplo da fórmula um, estes testes vão
desde uma simples troca de pneus prevista ou imprevista durante a prova, uma
substituição do bico ou outras partes do carro avariadas em um acidente, até corre-
ções do desempenho do carro em movimento, através da telemetria.
Na organização significa que o analista fará um plano baseado na estratégia
da organização e na definição dos negócios com participação crítica de TI e todas
as variáveis possíveis de desastre. O objetivo é manter o negócio em operação.
Para isso vai estabelecer rotinas que deverão ser seguidas em cada um dos
casos de interrupção de serviços previstos e treinar sua equipe na execução des-
tas rotinas. Por exemplo, o que fazer se o link de internet principal caiu? Como
proceder se o sistema de frente de caixa não responde? As ações estão previstas
no plano de continuidade e a equipe precisa saber executá-las.
O treinamento nesta execução é fundamental para que na hora do incidente
não haja indecisão ou dúvida.
Então o analista elaborará estratégias para conscientizar todos os colaborado-
res da organização sobre estes procedimentos do plano de ação. Cada colaborador
deverá saber como proceder em caso de incidente ou limitação de um serviço ou
componente, como se reportar ao Service Desk, como resolver aqueles de ação lo-
cal, enfim, ter um protocolo de procedimentos para cada um dos incidentes possí-
veis que possam gerar impacto negativo nos processos de negócio da organização.

1.2.1  Análise de Impacto

Todo incidente ou desastre nos serviços do Service Desk (os serviços do catálogo
da organização) tem um impacto nos negócios.

18 • capítulo 1
 Para criarmos um bom plano de continuidade, para que ele tenha a efici-
ência esperada, precisamos conhecer os impactos que a falha de cada serviço
causará nos negócios da organização.
Para cumprir esta finalidade, o analista responsável deverá conhecer os ne-
gócios da organização e sua relação com os serviços de TI do catálogo. Deverá
conhecer a estratégia da organização com relação ao atendimento das regras de
negócio e como deverá estar no futuro.
Analisar impactos significa sempre imaginar o pior dos mundos. A melhor
análise de impactos começa com a frase “E se tudo der errado?”, ou se você for
otimista, “E se tudo não der certo?”. Obviamente devemos trabalhar para nada
dar errado. Mas quando se trata de analisar impactos, o olhar é sempre para os
negativos, aqueles que atrapalham os negócios da empresa.
Nesta análise também existe influência do tipo de negócio praticado pela
organização. Quanto maior sua dependência de serviços de TI, maiores serão
os impactos causados pela falha ou vulnerabilidade destes serviços e mais com-
plexa será a análise a ser realizada.
Ao criar um modelo de análise de impacto, precisamos levar em conta:
•  Serviços críticos do negócio de TI, aqueles que por si só provocam a para-
da do negócio ou sua interrupção por períodos longos;
•  Impactos causados pela indisponibilidade do serviço. Cada área envolvi-
da, prejuízos causados por tempo, pela exposição de marca e valor, pela
não realização de operações, etc...
•  Cenários de impacto, como forma de estabelecer perímetros de ação, di-
minuindo a intensidade do impacto com a adoção de medidas paliativas
ou corretivas;
•  Obrigações da empresa perante a lei vigente, que obriguem um nível de
fornecimento de serviços para a operação,
•  Tempo em que a empresa aguentaria sem os serviços e TI adotando me-
didas administrativas e qual o custo do retrabalho para a inserção das
operações realizadas em papel na base de dados no decorrer deste tem-
po, quando o serviço estivesse recuperado;

Como dito anteriormente, essa abordagem deverá variar de acordo com a

organização e sua operação, o que sugere que outras abordagens menos con-
vencionais possam ser adotadas.

capítulo 1 • 19
1.2.2  Análise de Recuperaçã

Ao analisarmos o impacto que a falha na continuidade de um serviço de TI cau-

sará nas operações que sustentam o negócio, obrigatoriamente temos que pen-
sar em como vamos fazer para recuperá-lo. Ações de continuidade são realiza-
das para suportarem o negócio por um tempo e não para substituí-los.
A recuperação ocorrerá em paralelo às ações de continuidade. Todas as
ações de recuperação de cada serviço do catálogo de serviços de TI da organiza-
ção devem estar descritas no plano de continuidade. Todas as dependências de
serviços de terceiros, todos os passos que deverão ser seguidos pela equipe do
“Service Desk” para que o serviço venha a ser recuperado.
Abaixo alguns aspectos importantes a serem considerados:
•  Requisitos para recuperação de um ou mais serviços da organização para
serem fundamentados no plano de continuidade e façam parte dos SLAs
de contratos e acordos quando for o caso;
•  Determinar o tempo mínimo e máximo dos níveis de serviços a serem re-
cuperados para que a equipe do Service Desk os utilize como parâmetros
em suas ações e para que sejam exigidos quando o serviço for praticado
por terceiros (SLAs);
•  Definir quais processos de negócio devem ser recuperados por comple-
to, pois suas informações podem ser essenciais à continuidade da ope-
ração, como por exemplo um processo de vendas onde houve processo
administrativos (anotação em papel) referentes ao tempo que o proces-
so esteve inoperante, deverá ser lançado manualmente no sistema e ser
totalmente recuperado. Por outro lado, o sistema de monitoramento de
câmeras de vigilância não terá como refazer as cenas perdidas durante
um período de falha, sendo impossível a sua total recuperação.

A Recuperação de um serviço tem importância explícita. Obviamente existe

uma operação do negócio que será beneficiada. Mas existem outros aspectos
a serem analisados quando um serviço é recuperado. A adoção de medidas de
continuidade normalmente obriga ao retrabalho, mesmo que eletrônico, das
operações realizadas durante a ação. Existem casos de serviços inoperantes que
interferem na segurança dos sistemas que suportam as operações, expondo a
organização a um risco. Enfim, recuperação deve sempre ocorrer no menor
tempo possível, evitando assim problemas acessórios à sua utilização.

20 • capítulo 1
 ATENÇÃO
Uma boa prática para análise de impactos é manter um histórico dos incidentes com informações
minuciosas sobre os impactos observados. Esta é uma situação onde se aprende muito com os
erros cometidos. Com base nestas informações o analista terá mais subsídios para produzir uma
análise mais consistente dos impactos provocados por falhas na continuidade dos serviços de TI.

1.2.3  Análise de Vulnerabilidades

Organizações, assim como as pessoas, estão expostas a riscos diariamente.

Quanto maior a organização, maior será a complexidade dos serviços de TI
aos quais estará dependente e por consequência, maiores serão suas vulnerabi-
lidades às falhas destes serviços.
Com a transformação cada vez mais evidente das tecnologias de informação
em meio de viabilidade de negócios, maior ainda a importância de uma análise
das principais vulnerabilidades dos serviços de TI.
Abaixo, a tabela publicada na suite ITIL V3 (tabela 1.1) com as principais
vulnerabilidades dos serviços de TI.

RISCO AMEAÇA VULNERABILIDADE

Fogo, falha de energia, vandalismo,
Perda interna de inundação, impacto aéreo, danos Empresa fica sem co-
sistemas de TI/ climáticos (vendaval), desastre municação interna e seu
redes, PABX, ACDs, ambiental, ataque terrorista, sabo- negócio depende desse
etc. tagem, falha catastrófica, dano elé- fator
trico, baixa qualidade de software

Perda de serviços Todos os anteriores e ainda Exces-

externos de TI/ siva demanda pelo serviço, Proi- Empresa depende do
redes Ex: ecom- bição a um ataque a serviços, por serviço para operar
meerce, servido- exemplo, contra o firewall da or- vendas com segurança.
res, sistemas de ganização, falha de tecnologia, por Negócio para.
criptografia exemplo, no sistema de criptografia

capítulo 1 • 21
 RISCO AMEAÇA VULNERABILIDADE
Empresa controla ope-
Falha de tecnologia, erro humano, ração com transações
Perda de dados vírus, software maliciosos. Ex: Ata- exclusivamente por
ques por sql inserction. meio eletrônico. Pode
sofrer graves prejuízos.

Dano ou proibição de acesso às

regras do serviço de provedor de A empresa perde a
Perda de serviços rede, perda do serviço de rede ou linha de comunicação
de rede. sistemas de TI, Perda de dados no necessária ao fluxo da
provedor do serviço de rede, falha operação.
do provedor de serviço

Indisponibilidade
Ação sindical, proibição de acesso As operações depen-
de pessoal técnico
aos locais, renúncia, doença ou le- dem do suporte técnico
especializado de
são, dificuldades de transporte. para se manterem
suporte

Falha comercial (insolvência),

A operação do negócio
Falha de provedo- Proibição de acesso, indisponibili-
depende do serviço
res de serviço. Ex dade de pessoal da contratada do
e não prevê medidas
TI terceirizada. serviço, falha ao cumprir os níveis
substitutas.
do serviço contratado.

Tabela 1.1 - Tabela de vulnerabilidades - (ITIL V3, 2011)

Traduzido e ampliado pelo autor

A análise de vulnerabilidade deve ser realizada para dar subsídios ao pla-

no de continuidade dos serviços de TI. A partir da análise poderemos concluir
quais as melhores opções para cada caso.

CONEXÃO
Link pra uma reportagem da Folha de São Paulo, publicada em 04 de julho de 2008 so-
bre um incidente de queda de internet que atingiu boa parte do estado de São Paulo, dis-

22 • capítulo 1
ponível em http://www1.folha.uol.com.br/fsp/dinheiro/fi0407200801.htm visualizado em
14/10/2014

1.2.4  Roteiro Para Implementação

A implementação do plano de continuidade dos serviços de TI deverá ocorrer em

conjunto com o plano de continuidade de negócios. Suas principais ações são:
•  Planejamento da organização e da implementação;
•  Providências para recuperação;
•  Planos para recuperação;
•  Medidas de redução de risco;
•  Desenvolver procedimentos;
•  Testar;
•  Educar e conscientizar;
•  Revisar e auditar;
•  Testar novamente e periodicamente;
•  Gerenciar mudanças;
•  Capacitar a equipe através de treinamentos constantes;
•  Alcançar altos índices de garantia de continuidade de serviços.

ATENÇÃO
A análise criteriosa das vulnerabilidades, alinhada as estratégias de negócio, com o olhar
atento no manejo dos custos de viabilidade, poderá determinar um plano de continuidade
adequado que não tenha falhas de omissão nem exageros espetaculares sem sentido. Ela
será a linha mestra de conduta para a formalização do plano.

Demonstrar individualmente cada ação é desnecessário pois foram deta-

lhadas nos tópicos anteriores deste capítulo. Apenas comento a ocorrência de
duas instâncias com testes. Não houve engano, testes devem ocorrer em perí-
odos determinados, sendo sempre atualizados, numa rotina incansável, sem
esmorecimento. Eles são diretamente responsáveis pelo êxito na garantia de
continuidade (passo final da implementação).
Igualmente importantes são os treinamentos da equipe para capacitação.
Uma equipe capacitada trabalha melhor sob pressão, comete menos erros de
operação e responde mais rapidamente em situações de emergência.

capítulo 1 • 23
 A figura 2 demonstra o relacionamento destas ações no processo de implanta-
ção do plano. Ela é um recorte da figura 1, mostrada anteriormente neste mesmo
capítulo. O analista poderá verificar o alinhamento da implantação do plano de
continuidade dos serviços de TI com o plano de continuidade do negócio na figura
2, nela o plano de continuidade se inicia com o plano de continuidade do negócio.

Estágio 3
Planejamento da
Implementação
organização e da
implementação

Implementar
providencias Desenvolver planos Implementar medidas
para recuperação de recuperação de redução de risco

Desenvolver precedimentos

Teste inicial

Revisão e Teste Gerenciamento

auditoria de mudanças
Educação e
consciência Treinamento

Garantia

Estágio 4
Gerenciamento operacional

Figura 2 – Implementação do plano de continuidade

Adaptado ITIL V3 - (ITIL,2014).

1.2.5  Atualização do Plano de Capacidade

É certo que tecnologias evoluem, negócios também. O plano de capacidade

deve ser atualizado periodicamente principalmente em função destes dois fa-
tos. O que sustenta a operação hoje pode estar obsoleto amanhã. Os negócios
sofrem pressões diferentes com o passa do tempo.
É recomendável que as atualizações do plano de capacidade sejam realiza-
das anualmente, mas revisões podem ser feitas em períodos menores, a cada
90 dias por exemplo.

24 • capítulo 1
 Em casos em que a tecnologia tem uma ação crítica no negócio as revisões
poder ser mensais.
Se a revisão determinar um atualização imediata, não é obrigatório aguar-
dar uma atualização programada. Ela pode ser antecipada para atender a ne-
cessidade do negócio.

1.3  Gerenciamento de Capacidade

1.3.1  Introdução

O gerenciamento da capacidade na entrega de serviços de TI tem por objetivo

assegurar que a capacidade da infra estrutura, dos serviços constantes do ca-
tálogo de serviços de TI da organização, seja mantida e esteja alinhada com as
necessidades do negócio.
O propósito deste gerenciamento é entender e manter os níveis de serviço
requisitados a um custo aceitável.
A partir de uma investigação cotidiana sobre as necessidades de capacida-
des técnicas do negócio ele poderá ser planejado e entregue para atendê-las.
A garantia de capacidade é um processo dinâmico, pois diversos aspectos ine-
rentes ao negócio são severamente influenciados pela demanda do negócio. Se
as operações estão aquecidas, o nível de entrega precisará ser mais alto, caso con-
trário, mais baixo. Bons contratos tiram vantagens destas variações ou na pior
das hipóteses, deverão estar preparados para elas.
O gerenciamento da capacidade dará ao analista esta visão dos requisitos do
negócio e uma exata noção da distância entre a necessidade de cada operação e o
serviço que vai ser efetivamente entregue para mantê-la.
Gerenciar a capacidade é estar atento a todos estes aspectos, é ter em mãos o
mapa do comportamento dos serviços entregues e poder encontrar, sem maio-
res dificuldades, os pontos críticos de cada um. É poder encaixar cada nova
oportunidade de melhoria nos serviços entregues pela TI sem muitas dúvidas
sobre sua repercussão na operação.
O ITIL V3 (2011) Lista uma série de objetivos da gerência de capacidades:
•  Produzir e manter um Plano de Capacidade atualizado e apropriado, que
reflita as necessidades atuais e futuras do negócio;
•  Fornecer aconselhamento e orientação para todas as outras áreas de ne-
gócio, em todas as questões de capacidades relacionadas com o desem-
penho dos serviços;

capítulo 1 • 25
 •  Certificar-se que o desempenho do serviço atenda ou exceda todas as
metas de desempenho acordadas, através da gestão do desempenho e
gestão da capacidade de ambos, serviços e recursos;
•  Auxiliar no diagnóstico e solução de problemas e incidentes relaciona-
dos à capacidade;
•  Avaliar o impacto de todas as mudanças no Plano de Capacidade e a per-
formance e a capacidade de todos os serviços e recursos;
•  Garantir que medidas proativas que melhorem o desempenho dos servi-
ços sejam implementadas onde quer que tenham uma relação custo-be-
nefício que justifique sua implantação.

Mais uma vez lembro que o analista deverá levar em consideração as parti-
cularidades dos negócios da organização. Este livro está baseado na formula-
ção de melhores práticas, de aceitação geral. Mas elas não são únicas e algumas
podem não ser totalmente adequadas quando as particularidades da organiza-
ção são muito específicas em suas operações. Quando houver alguma dúvida
quanto a aplicação de qualquer uma das práticas sugeridas, o bom senso conti-
nua sendo uma boa opção, então coloque o seu em prática.

1.3.2  Planejamento da Capacidade

O plano de capacidade é um documento fundamental para a gerência de TI. Ele

é a base da operação e o futuro do investimento da organização em TI.
Por sua importância, deve espelhar os requisitos de negócio da organiza-
ção, deve estar voltado para garantir a capacidade da gerência de TI de manter
suas entregas.
Também tem um comprometimento com o futuro da organização, pois
deve ser o relatório base para os investimentos em infraestrutura que irão man-
ter as operações por pelo menos os próximos 12 meses.
Deve conter dados pormenorizados a respeito dos níveis de recursos utili-
zados pela organização e a influência de sua série histórica deve ser usada para
formulações de recursos para o futuro.
Deve manter os SLAs sob controle, garantindo o cumprimento dos acordos
com os fornecedores de serviço e garantindo a entrega. Deve estar atenta aos
SLRs, pois são a norma base para a relação da TI com os negócios. Lembre-se, a
tecnologia é a que propicia o negócio, se os requisitos do negócio deixam de ser
atendidos, perde a razão de ser na operação.

26 • capítulo 1
 Outro aspecto importante são as relações de financiamento dos servi-
ços. As informações financeiras fazem parte do plano e da base de dados
do CMIS.
Quando um serviço vai ser implementado ou descontinuado gerará impac-
to financeiro na organização.
O plano de capacidade, ao olhar para o futuro dos negócios da organização,
deverá estar alinhado aos requisitos de negócio, deve estar atento ao cresci-
mento esperado e qual o impacto destas decisões no ambiente de Ti e nas en-
tregas de serviços contratadas.
A partir das análise criteriosas dos serviços em execução e suas séries his-
tóricas é possível demonstrar com clareza ao staff diretivo quais investimentos
serão necessários par adequar os serviços de TI para que realizem entregas sa-
tisfatórias aos requisitos de negócio da organização e da mesma forma atestar
de forma categórica quando um serviço poderá deixar de ser entregue, pois não
está alinhado com os interesses da organização .
Para que a gerência de capacidade possa se posicionar da maneira correta
em relação aos negócios da organização, deverá ter em seu plano, dados que
demonstrem os fatores internos e externos à organização que tem influência
nas decisões a serem tomadas. Deve refletir a posição da empresa quanto ao
mercado, dados regulatórios e estratégia de negócios.
Planejar a capacidade é estar atento a como a empresa funciona hoje, como
ela tem se comportado em relação à utilização de recursos de tecnologia, ler os
dados referentes à utilização de seus serviços, traçar linhas de comportamento
destes serviços, agir para corrigir se necessário. Pegar todas as informações pro-
duzidas por estas ações, procurar no mercado como o serviço está sendo prestado
(benchmarking) e proporcionar um ambiente seguro para tomada de decisões
pelo staff diretivo da organização com relação ao produto ou serviço utilizado. Se
o caso for a contratação de uma nova demanda de serviços, também municiar o
staff, para desta vez melhor escolher o fornecedor de um novo serviço.
O Gerenciamento da Capacidade é parte da Entrega de Serviços e está dire-
tamente relacionado com os requisitos do negócio. Não está preocupado ape-
nas com a performance dos componentes dos sistemas, individualmente ou
coletivamente. A confecção do plano de capacidade determina uma relação da
área de capacidade com outras áreas da gerência de TI.
Os processos da Central de Serviços, Gerenciamento de Incidentes e Pro-
blemas irão fornecer ao Gerenciamento da Capacidade informações sobre in-
cidentes e problemas relacionados à Capacidade. O Gerenciamento da Capaci-

capítulo 1 • 27
dade irá suportar estes processos resolvendo incidentes e problemas e também
fornecendo a eles informações sobre desempenho.
As atividades do Gerenciamento de Capacidade irão abrir Requisições de
Mudanças (RDM’s) da Gerenciamento de Mudanças e Liberações para assegu-
rar que a capacidade apropriada esteja disponível. Este é um assunto do pro-
cesso de Gerenciamento de Mudanças. As implantações podem afetar muitos
Itens de Configuração (IC’s), incluindo hardware, software e documentação,
desta forma será necessário um Gerenciamento de Liberação eficiente.
O vínculo entre o Gerenciamento de Capacidade e o Gerenciamento da Dispo-
nibilidade é muito forte, para que se tenha certo nível de disponibilidade será ne-
cessária certa capacidade relacionada aos itens de configuração. Sem a capacidade
necessária, você jamais vai conseguir a disponibilidade necessária. Além disto, os
valores medidos pelo Gerenciamento da Capacidade são importantes para o Ge-
renciamento da Disponibilidade em relação à disponibilidade e confiabilidade.
No Gerenciamento do Nível de Serviço, tanto o Gerenciamento da Capacida-
de como o Gerenciamento de Disponibilidade precisam fornecer ao gerente de
nível de serviço informações para que ele faça negociações de SLA’s. O Geren-
ciamento da Capacidade informa ao Gerenciamento do Nível de Serviço sobre
os níveis que podem ser fornecidos ao cliente.
O Plano de Capacidade fornece uma importante entrada para o Gerencia-
mento Financeiro para Serviços de TI, o qual dá uma visão mais precisa sobre o
plano de investimento para a capacidade.
O Gerenciamento da Capacidade fornece ao Gerenciamento da Continuida-
de dos Serviços de TI (GCSTI) informações sobre a capacidade mínima necessá-
ria para a recuperação. É importante considerar o impacto (para a capacidade
necessária) de mudanças para os Serviços de TI nos procedimentos do GCSTI.

1.3.3  Balanceamento de Recursos, Demanda, Custos e Benefícios

No planejamento da capacidade é preciso observar cuidadosamente a manu-

tenção do equilíbrio entre custos, recursos, demanda e benefícios esperados.
Muitas vezes, em função do despreparo ou do planejamento equivocado,
acabam sendo observados despropósitos desnecessários para a manutenção
da capacidade de operação do negócio.
Em um plano de capacidade equilibrado, balanceado, as necessidades se-
riam analisadas, levando em consideração estes aspectos. Qual seria o bene-

28 • capítulo 1
fício alcançado com a adoção de um bunker a prova de choque de aeronaves?
Será que a chance de um acidente deste tipo ocorrer existe? Claro que se trata
de um exagero utilizado para fins didáticos. Contudo a ideia de um link redun-
dante é perfeitamente viável. Mantem a capacidade de operação da unidade em
um nível mais elevado, com claros benefícios para a operação.
O analista deverá considerar também a demanda necessária por serviços
com características de consumo. É o caso dos serviços de transmissão de dados
e voz, os serviços de armazenagem, banco de dados, manutenção de energia e
outras de igual característica.
Tomando o caso dos serviços de transmissão de dados como exemplo, po-
deríamos verificar:
•  as diversas operadoras que operam no mercado;
•  as propostas para bandas maiores, pois muitas vezes o valor para uma
banda maior diminui o custo por Mbps (megabits por segundo).
•  relação de custo por disponibilidade de banda, quando a operadora co-
bra mais caro pelo nível de disponibilidade dos seus serviços (garantidos
por SLAs rígidos e controle efetivo por KPIs adequados).
•  pacotes de dados por horário, nos casos onde a operação da organização
permite a negociação em horários de pouca utilização.
•  mídias de transmissão alternativa, rádio, fibra ótica, par metálico, saté-
lite são algumas das formas de transmissão que podem ser analisadas.

Além destes aspectos, outros poderão influenciar a decisão, como a estraté-

gia dos planos de negócio e as necessidades futuras da organização. Um plano
de capacidade deve levar em consideração o crescimento esperado para o negó-
cio e estar preparada para a possibilidade de recuos de demanda, permitindo a
diminuição de um determinado serviço.
Um balanceamento de custos adequado, como vocês devem ter notado, não
é um resultado conseguido facilmente. Exige análise cuidadosa, conhecimento
e experiência do analista.
Uma ferramenta que possibilita uma gestão mais equilibrada da capacida-
de é o CMIS (Capacity Management Information System, do inglês sistema de in-
formação de gerenciamento de capacidade).
Mais uma vez lembro que o analista deverá levar em consideração as particula-
ridades dos negócios da organização. Este livro está baseado na formulação de me-
lhores práticas, de aceitação geral. Mas elas não são únicas e algumas podem não

capítulo 1 • 29
ser totalmente adequadas quando as particularidades da organização são muito
específicas em suas operações. Quando houver alguma dúvida quanto a aplicação
de qualquer uma das práticas sugeridas, o bom senso continua sendo uma boa op-
ção, então coloque o seu em prática.
A figura 3 contém um mapa simplificado de como se comporta a gerência de
capacidade (neste caso amparado por um sistema de informação).

AJUSTES

IMPLEMENTAÇÃO ANÁLIZES

MONITORAMENTO

Relatórios de
Relatórios
Indices de de excessão
excessão de
utilização de
utilização de Indices de SLA Sistema de informação
de serviços
recursos
recursos da gerencia de capacidade
CMIS

Figura 3 – Mapa de atividades da Gerência da capacidade

Traduzido do ITIL V3 - (ITIL,2014).

CONEXÃO
Verifique o artigo O PROCESSO DE GERENCIAMENTO DA CAPACIDADE NA UTILIZAÇÃO
DA TELEFONIA VoIP COM O USO DE FERRAMENTAS DE ANÁLISE EM REDES SOCIAIS,
publicado por VIEIRA et All, Disponível em < http://proceedings.copec.org.br/index.php/
shewc/article/view/804/753#.VENQBvnF8WI

30 • capítulo 1
1.3.4  Criando o Plano de Capacidade

Um roteiro de implementação da gerência de capacidade pode ser feito a partir

de duas realidades, uma tendo como referência o plano de capacidade anterior
e outra começando do zero. Mesmo em empresas onde nunca foi realizada, é
uma boa prática utilizar dados de experiências anteriores e optar pela utiliza-
ção de um sistema de informação para ser o repositório de dados da gerência e
a ferramenta de trabalho do dia a dia.
Vamos utilizar neste livro um modelo de implementação de gerência de ca-
pacidade sugerido por KLOSTERBOER(2011) em seu guia “O caminho para a
gerência de capacidade efetiva”
•  Passo 1 - Comece pela elaboração dos pools de capacidade que serão
observados. Eles deverão conter o catálogo de serviços da organização,
devidamente descritos, com seus SLAs, seus níveis de utilização de recur-
sos e o alinhamento com os requisitos de negócio de cada operação re-
lacionada. Tudo vai estar aqui, hardware, software, serviços de terceiros,
serviços internos, tudo mesmo.
•  Passo 2 - Com os pools definidos, comece a reunir dados de tendência. Es-
tes dados podem ser obtidos observando os dados históricos armazenados
nos sistemas próprios, em sistemas Solaris por exemplo, você pode rodar o
comando iostate;
•  Passo 3 – Comece a fazer previsões usando as tendências recolhidas. Você
vai conseguir estabelecer dados consistentes de crescimento de utilização
dos seus recursos. Vai ficar fácil você observar o crescimento da utilização
dos discos do servidor em 3% ao mês. Também vai ser fácil, a partir do seu
conhecimento, das informações fornecidas pelo fornecedor e das trocas
de informação com as áreas de negócio, que um novo aplicativo a ser ins-
talado irá provocar um acréscimo além do normal a esta taxa;
•  Passo 4 – Definir quando usar scale up ou scale out é importante na gerên-
cia de capacidade. Scale up é quando um recurso será aumentado em fun-
ção da necessidade. Aumentar a capacidade de memória de um servidor, a
banda de um link de internet, etc. Scale out é quando ao invés de aumentar
o recurso, por uma série de razões, é melhor desdobrar. Ao invés de au-
mentar a capacidade de memória de um servidor, comprar outro servidor,
a invés de aumentar a banda do link de internet, contratar outro link;

capítulo 1 • 31
 •  Passo 5 – Estabelecer o CMIS. Com todos os dados e tendências recolhidos,
com todos os parâmetros de cada serviço e suas entregas você terá uma
grande quantidade de dados para analisar. O CMIS será o responsável por
dizer a você qual será o dia exato que o disco do servidor estará no limite de
sua capacidade, e vai te avisar com uns dois meses de antecedência;
•  Passo 6 – Construir e gerenciar o plano de capacidade. A esta altura você
terá subsídios suficientes para elaborar seu plano de capacidade. Ele
contemplará uma lista completa do que existe instalado e do que será
necessário instalar de recursos e serviços para o período determinado;
•  Passo 7 – Crescer na capacidade de gerenciar serviços. A partir de ago-
ra você terá informações suficientes para agregar valor aos serviços de
TI que gerencia. O plano de capacidade é o caminho para o sucesso que
você precisa para tornar isso possível;
•  Passo 8 – Esforce-se para o gerenciamento de capacidade para o negócio.
Depois de gerar valor para os serviços, gere valor para o negócio. Se as
suas ações estiverem alinhadas com os requisitos de negócio da organi-
zação, este passo ocorrerá quase que naturalmente.

1.3.5  O Que é Itil®

ITIL® é uma biblioteca de melhores práticas criada nos anos 80 pelo governo
britânico para garantir a qualidade do nível de serviço entregue, que ele julgava
insuficiente à época. A agência central de computadores e telecomunicações
(CCTA), atualmente denominada OGC (Escritório de comércio do governo) foi
incumbida de desenvolver um framework que garantisse o uso responsável e
sustentável das tecnologias de informação e comunicação, tanto para o uso pú-
blico quanto privado.
A primeira versão era chamada de GITIM (Government Information Techno-
logy Infrastructure Management, do inglês Gerenciamento da infraestrutura de
tecnologia do governo). De lá pra cá passou por algumas versões até a atual (V3),
editada em 2007, revisada em 2011.
Essencialmente ela define como organizar os serviços de tecnologia para
atender os interesses da organização. Estabelece um novo paradigma, colocan-
do este setor como prestador de serviços para a organização, sendo responsável
por garantir o nível da entrega dos serviços de tecnologia e pela satisfação das
expectativas dos setores atendidos pelos serviços de tecnologia.

32 • capítulo 1
 Para que estes objetivos possam ser atendidos a ITIL®V3 disponibiliza uma co-
leção de livros composta por 5 volumes de cerca de 400 páginas cada um.
São eles:
•  Service Strategy – O livro que alinha os negócios da organização com os
serviços de TI, ele especifica que cada estágio do ciclo de vida do serviço
deverá estar focado nos requisitos do negócio, seus objetivos e princí-
pios de gestão.
•  Service Design – Este livro determina como deverá ser gerida a produção e
manutenção de documentos, políticas e arquitetura da tecnologia da in-
formação.
•  Service Transition – O livro que contem as orientações para a transição
dos serviços para o ambiente de negócios.
•  Service Operation – O livro das atividades dos processos de controle e en-
trega baseados na seleção dos pontos de controle de desempenho da en-
trega e suporte dos serviços prestados.
•  Continual Service Improvment – O livro que controla os elementos de pro-
cessos dos serviços que deverão ser introduzidos e os que sairão do catá-
logo de serviços de TI da organização.

Na versão anterior, a V2, havia uma divisão diferente. Duas grandes áreas, a
de suporte do serviço e entrega do serviço. O suporte de serviço era dividido em
6 processos principais:
•  Gerenciamento da mudança
•  Gerenciamento de versões
•  Gerenciamento de problemas
•  Gerenciamento de incidentes
•  Gerenciamento da configuração

A entrega de serviço tinha 5 processos principais:

•  Gerenciamento financeiro da TI
•  Gerenciamento da continuidade de TI
•  Gerenciamento da capacidade
•  Gerenciamento da disponibilidade
•  Gerenciamento de nível de serviço

capítulo 1 • 33
 A versão V3, tem 26 processos descritos nos seus 5 volumes. Foi uma grande
evolução que ocorreu principalmente em função da grande modificação da reali-
dade da participação da TI nos destinos das organizações.
Esta nova abordagem deixou mais evidente a participação da TI em todas as
fases do negócio, desde a estratégia até a entrega do produto ao cliente. Sendo
a própria TI uma fornecedora de serviços, tendo as outras áreas da organiza-
ção como clientes. Este novo tipo de relacionamento entre a TI e o restante da
organização modificou a imagem da TI. Antes era vista como um setor caro e
dispendioso, com pessoas isoladas e distantes. Agora é parte de uma equipe
empenhada em entregar seu serviço com excelência.
A gerência de capacidade traz muitos benefícios para a organização. Em
princípio garante a capacidade da gerência de TI de continuar fornecendo ser-
viços em alto nível para a organização, monitorando seus recursos e serviços,
produzindo relatórios de entrega para alinhamento com os SLAs contratados.

1.3.6  Evolução Maturidade no Gerenciamento da Capacidade

Em termos gerais, o Gerenciamento da Capacidade permite:

•  Uma visão geral sobre a capacidade atual existente na infraestrutura por-
que tem todos os dados disponíveis para esta resposta em seu banco de
dados;
•  A possibilidade de planejar a capacidade antecipadamente, uma conse-
quência natural do plano de capacidade, que tem como função dimen-
sionar a capacidade atual e estimar a do próximo período;
•  Estimar o impacto de novas aplicações ou modificações porque tem todas
as capacidades de todos os serviços sob seu controle, inclusive onde se re-
lacionam direta e indiretamente;
•  Economizar custos ao dimensionar corretamente cada serviço dentro
das capacidades necessárias para a operação da organização, evitando
contratações de serviços acima da capacidade esperada quando isso não
for necessário ou ainda promovendo ajustes em serviços que precisam
de menor capacidade que a inicialmente contratada, fato verificado nos
relatórios de utilização de recursos;
•  Melhores serviços em harmonia com os requisitos do negócio, porque
com o monitoramento dos serviços e as análises consequentes é possível
manter o alinhamento das entregas com o serviço contratado, garantin-
do um alto nível de harmonia com os requisitos de negócio.

34 • capítulo 1
 CONEXÃO
Veja a tese de doutorado de CANCIAN(2013), com o título Um modelo de capacidade
e maturidade para melhoria de processo de software para saas colaborativo, disponível
em <https://repositorio.ufsc.br/bitstream/handle/123456789/106830/318112.
pdf?sequence=1&isAllowed=y>.

1.3.7  Gerenciamento de Níveis de Serviço – Objetivo

Uma organização, seja ela de qualquer área, funciona como um organismo.

Cada uma de suas áreas se relaciona, gerando fluxos de informação envolvendo
entregas. Cada entrega é gerenciada por um conjunto de atividades que é cha-
mado de processo. Normalmente um processo possui algumas entradas trans-
formadas em saídas definidas.
Existe uma relação íntima entre os processos de uma organização, de tal
forma que é possível afirmar que todo processo interno tem:
1.  Um início, geralmente atrelado a uma demanda definida nas estraté-
gias da organização, originado de uma solicitação externa à organiza-
ção ou devido a uma solicitação interna de um processo predecessor;
2.  quando se trata de um processo interno, um fornecedor, que entrega o
resultado de seu processo para seu sucessor;
3.  um ator, que executará sua tarefa previamente definida para gerar um
novo resultado, objeto de uma nova entrega;
4.  uma entrega, resultado da execução de sua tarefa dentro dos requisitos
estabelecidos pelo processo (saída). Ela será remetida a um sucessor,
inciando um novo processo, ou ao cliente final, se for o processo fim.

Processos também devem ser ou ter:

•  Mensuráveis - devemos poder medir os processos em suas tarefas de ma-
neira relevante, verificando sua performance quanto a custo, qualidade e
outras variáveis potencialmente importantes no processo produtivo
•  Resultados específicos - Resume a razão do processo existir, ter uma en-
trega específica que deverá ser possível contar e identificar individual-
mente. Enquanto pudermos contar mudanças, será impossível determi-
nar quantos serviços foram completados.

capítulo 1 • 35
 •  Consumidores - Cada processo é entregue a alguém ou área de atuação.
Pode ser interno ou externo à organização, devendo estar dentro das ex-
pectativas para as quais foi criado.
•  Respostas a um evento específico - Quando um processo pode ser contínuo
ou iterativo, precisa ser rastreável, respondendo a um gatilho específico.

Podemos dizer que a grande maioria dos processos de uma organização

pode ser realizada manualmente, sem a utilização de nenhuma tecnologia.
Mas se quisermos obter produtividade e eficiência para competir no merca-
do de negócios globalizado, é impossível imaginar este cenário sem a forte e
marcante presença das ferramentas de tecnologia e comunicação.
A relação entre cada uma das áreas envolvidas se torna muito mais transpa-
rente e eficiente se ocorrer dentro de mecanismos informatizados.
Quando se trata de serviços prestados pela internet temos um cenário ainda
mais dinâmico, pois os serviços são arquitetados e produzidos para serem tes-
tados pelo consumidor durante a demanda. É impossível prever como os con-
sumidores irão reagir, as respostas quanto a satisfação dos clientes e a qualida-
de do serviço prestado somente serão perceptíveis após sua utilização. Muitas
vezes os ajustes de melhoria precisam ser imediatos, sob pena da perda total da
oportunidade de negócio.
Então os processos devem ser mensuráveis dinâmica e iterativamente para
permitir esta atualização constante.
O que nos leva a uma nova definição da tecnologia da informação. Até algum
tempo atrás ela tratada como produto (como hardware e software). Atualmente,
frente a todo o aparato tecnológico disponível, criou-se uma nova relação. Um
consumidor adquire um serviço ou produto através dela, que é um produto em si.
Não interessa quais os caminhos necessários, os riscos inerentes, o custo envolvi-
do para que a entrega seja feita, se houver alguém disposto a pagar. O consumidor
final não está interessado nisso, ele quer a facilidade de obter o objeto desejado.
Mas o que é serviço neste contexto?
Serviço é um meio de entregar valor ao cliente sem a responsabilidade direta
sobre custos e riscos inerentes, facilitando a obtenção ou alcance de um objetivo.
Exemplificando, seria como decidir comer no restaurante ao invés de co-
mer em casa. Você estaria escolhendo o serviço, se eximindo da obrigação e dos
riscos de escolher os ingredientes, preparar o jantar, colocar a mesa e depois
ainda lavar a louça.

36 • capítulo 1
 Você chega ao restaurante, senta-se à mesa posta, escolhe o que comer, pede
urgência se necessário, come, paga, levanta e vai embora (a louça… alguém vai
lavar, faz parte do serviço).
Existem alguns conceitos relacionados a serviços de tecnologia que fazem
parte do conhecimento necessário à sua gestão:
•  Serviços são intangíveis, não são fisicamente perceptíveis, portanto não po-
dem ser entregues como produtos e sua mensuração é bastante complexa;
•  Serviços são produzidos e consumidos ao mesmo tempo. O serviço é en-
tregue no momento da solicitação. Se o usuário reclama ao suporte, a
maneira de lidar com a reclamação é o serviço;
•  Serviços são inconsistentes, entregues por máquinas e pessoas. Pessoas não
são máquinas e fazem suas entregas dependendo de seu estado e capacidade.
Isso causa flutuações na entrega do serviço e não garante sua estabilidade;
•  O usuário participa da produção do serviço, isso causa interferência dire-
ta do usuário na entrega a ser realizada. O consumidor é uma influência
significativa na qualidade do serviço demandado.

A satisfação na utilização de um serviço é subjetiva, porque é diretamente

influenciada pelo usuário. Por esta razão somente poderá ser medida depois
que o serviço for utilizado, nunca antes.
No ambiente corporativo podemos citar como exemplo o serviço de arma-
zenamento. No passado recente pensávamos em Hard Drives (HD) implanta-
dos no servidor local ou na estação do usuário. Hoje em dia pensamos em “Sto-
rage”, um termo que define uma política de armazenagem que pode estar no
datacenter próprio de uma organização ou oferecido como serviço, hospedado
em nuvem. O Storage não guarda somente arquivos, mas também fotos, con-
figurações de equipamentos, vídeos, dados de dispositivos móveis, banco de
dados online, informações das mais diversas.
A utilização de cada usuário definirá o nível de utilização do serviço.
Estará em uso no momento que qualquer usuário decidir utilizá-lo.
É operado por máquinas e pessoas, tornando-o imprevisível quanto a sua
estabilidade.
O usuário poderá nem perceber o valor de sua utilização, ao menos que pre-
cise recuperar um arquivo perdido.
No entanto, storages tem se mostrado uma parte sensível do negócio de
qualquer organização, no que se refere à segurança de manutenção da infor-

capítulo 1 • 37
mação em repositórios e na proposta de manutenção de um ativo de conheci-
mentos acumulados que podem ter papel importante no desenvolvimento de
novos produtos e estratégias de negócio.
Para os consumidores de serviços online, representam a quantidade de infor-
mação que estará disponível em um determinado serviço, como uma loja virtu-
al. Não terá importância para o usuário a formatação de toda a infraestrutura de
armazenamento necessária para a manutenção desta loja no ar. O que interessa
pra ele é o ato da compra de seu objeto de desejo da forma mais simples possível.
Mas se o negócio precisar crescer em face de maior demanda de usuários,
sua utilização como serviço permitirá um crescimento imediato, com a respon-
sabilidade e risco por conta do fornecedor do serviço. Também fica por conta
do fornecedor de soluções toda preocupação com a segurança, redundância a
falhas, backups, manutenção e serviços de garantia de fornecimento contínuo
de energia, como nobreaks e geradores. Para o negócio, este é o melhor dos
mundos, para o usuário é a garantia da qualidade do serviço.
Para que esta tipo de gerenciamento possa acontecer, é necessário definir
um catálogo de serviços de TI da organização.

O catálogos de serviços

Visão do catálogo de Processo de Processo de Processo de

serviços do negócio negócio 1 negócio 2 negócio 3

Serviço A Serviço B Serviço C Serviço D Serviço E

Serviço 1 Serviço 2 Serviço 3 Serviço 4 Serviço 5 Serviço 6

Visão do catálogo de serviços técnicos ou de suporte

Links para
informação
relacionada

Bens de serviço/registros de configuração

Legenda = Registro voltados ao consumo = Serviços de suporte

Figura 4 – Catálogo de serviços de TI, (OGC, 2007).

Traduzido pelo autor, disponível em http://itil.org/osSite/osPicWin.php?pic=/osMedia/
pic/servicekatalogmanagement_3828_or.png&template=1

38 • capítulo 1
 A figura 4, acima, mostra bem como é estruturado um catálogo de serviços
de TI de uma organização. Escolhi este exemplo porque mostra todas as cama-
das que interagem com o catálogo, mas isso não significa que é o melhor mode-
lo. Cada organização pode adotar o modelo de catálogo de serviços que for mais
conveniente ao seu portfólio de serviços.
Na área superior temos os retângulos brancos que mostram os processos de
negócio da organização. Estes processos estão reunidos em uma camada deno-
minada “visão do catálogo de serviços de negócio”.
Abaixo dela, os quadrados com serviços nominados por letras A, B, C, D e E
mostram os serviços de TI utilizados pela organização, e os numerados de 1 a 6,
que estão reunidos na camada “Visão do Catálogo de serviços técnicos ou de su-
porte”, a que nos interessa neste item. O catálogo define as áreas da tecnologia
que estão presentes na organização e que são atendidas pelo Service Desk, tendo
todos os seus elementos perfeitamente definidos, inclusive quanto ao custo de
utilização de cada elemento.

1.3.8  Acordo de Nível de Serviço (Sla)

Uma relação de entrega de serviço de TI é normalmente definida por um acordo

de nível de serviço (ANS) ou Service Level Agreement (SLA). Esta entrega é nor-
malmente o resultado de uma análise de Implementação de melhorias, realiza-
da conforme o disposto no item 1.8. O SLA é o documento que dará sustentação
para a operação do serviço, mediando a relação entre o cliente e fornecedor.
Deverá ser assinado pelas duas partes, contratante e contratada, tendo seu
conteúdo expresso em um linguajar perfeitamente entendido pelas partes.
Deve possuir metas mensuráveis, padrões e procedimentos determinados, cus-
tos definidos com regulamentos para bônus e multas, além de outras métricas
e soluções que se fizerem necessárias.
Ele pode ser baseado em serviço, cliente ou multinível.
Por serviço, quando atinge todos os clientes da organização. Ex: Link de in-
ternet, todos usuários da organização deverão utilizar.
Por cliente, quando se aplica a grupos individuais. Ex: Sistema de contas a
pagar e receber, incluindo a contabilidade, onde somente os interessados das
áreas envolvidas seriam usuários.
Multinível, quando uma combinação de situações exige que seja segmenta-
dos por serviço e cliente. Ex: Serviço de gestão documental da empresa utiliza
uma banda considerável de internet para subir imagens para um repositório

capítulo 1 • 39
em nuvem, o que sugere que sua contratação de serviços de internet seja dife-
rente dos outros setores da organização.
Não é incomum que um SLA tenha componentes legais envolvidos. Prazos
a serem cumpridos, normas a serem verificadas e outras situações exigidas por
leis específicas às quais a organização está obrigada a seguir. Por esta razão,
sugere-se que estes contratos devam contar com uma supervisão do departa-
mento jurídico das organizações.
Os documentos para a manutenção dos serviços de TI, diretamente ligados
à aplicação do conceito do SLA são os CAs (Contratos de Apoio) utilizado para
contratos de fornecedores de serviços externos à organização e os OLAs (Opera-
tional Level Agreement ou Acordo de nível Operacional) para os acordos realiza-
dos com os fornecedores internos da organização.

ATIVIDADE
Vamos usar para atividade deste capítulo o exemplo clássico da Biblioteca. Todos sabem
como funciona, você se cadastra, paga a taxa de utilização anual, retira e devolve os livros do
acervo no prazo indicado. Se atrasar paga multa. Se procurar um livro e ele estiver empres-
tado, fica na fila de espera. Para facilitar, a nossa biblioteca é restrita a cidade, uma cidade
pequena, com poucos habitantes.
Não se trata de um estudo de viabilidade, pois seria muito mais barato um sistema local de
pequeno porte. Vamos utilizar uma situação apropriada para a didática da disciplina que leva
em consideração a modernidade dos serviços e componentes utilizados.

Catálogo dos serviços do negócio

a) Cadastro de livros do acervo
b) Cadastro de usuários da biblioteca
c) Controle de movimentos de entrada e saída do acervo
d) Controle financeiro

Catálogo de serviços de tecnologia

a) Link de internet operadora 1
b) Link de internet operadora 2
c) Switche load balanced para rede WAN-LAN
d) Computadores para operação
e) Infraestrutura de rede interna

40 • capítulo 1
 f) Contrato de manutenção para infraestrutura interna
g) Aplicativo de controle do tipo SaaS (Sofware as a Service)
h) Nobreak com capacidade suficiente para manter os computadores e a infraestrutura
funcionando
i) Contrato de storage em nuvem, para os arquivos compartilhados utilizados pelos ope-
radores.

Explicando: Biblioteca é um tipo de negócio bem simples, com poucas operações e requisi-
tos. Optamos por um do tipo SaaS.
Levando em conta o tipo do aplicativo, o mais importante é manter a internet no ar dentro do
ambiente de trabalho, por isso dois links de internet de operadoras diferentes (redundância)
gerenciados por um switche alugado WAN-LAN do tipo load balanced (você tem duas entra-
das de WAN (internet) ), este equipamento controla para que pareça uma só, de tal forma que
se um link cair, o outro suporta a operação, sem que ninguém perceba.
Dentro da biblioteca a infraestrutura será fornecida por uma firma especializada. A mesma
firma ou outra do mesmo ramo ficará responsável pela manutenção.
Os computadores serão alugados. Se quebrarem, podem ser substituídos pelo contrato.

1.  Conhecendo todos os detalhes do negócio “Biblioteca”, estabeleça um plano de Conti-

nuidade que mantenha em operação os serviços de negócio mantidos pelos serviços
de TI em caso de falhas.

2.  Com relação a capacidade, os serviços poderão sofrer pressão de demanda?

3.  Está previsto crescimento para serviços, infraestrutura e componentes?

4.  Defina os serviços do negócio e os serviços de tecnologia que suportarão os requisitos do

negócio, faça seu catálogo de serviços para atender as necessidades do negócio Biblioteca.

5.  Defina os SLAs dos contratos de serviços de tecnologia do catálogo.

REFLEXÃO
Continuidade é manter o negócio em funcionamento, mesmo que não exista TI. É a capacidade
de se recuperar do acidente, com o menor prejuízo para a organização. É, antes de tudo, se ante-
cipar à tragédia, para que ela não aconteça. Se conseguir, seu valor profissional não terá preço.

capítulo 1 • 41
Manter a capacidade dos serviços de tecnologia da organização não é tarefa trivial. Exige
foco, atenção, observação e análise sistemática de todos os dados interligados. É uma posi-
ção de grande destaque na estrutura da organização, pois exige trânsito em diversas áreas
de negócio, gerando grande visibilidade do profissional. Desenvolva esta aptidão e o sucesso
profissional estará garantido.

LEITURA
ASSUNÇÃO, M.R.P., Reflexão para gestão tecnológica em cadeias de suprimento, GES-
TÃO & PRODUÇÃO, São Carlos, v.10, n.3, p.345-361, dez. 2003, disponível em <http://www.
scielo.br/pdf/gp/v10n3/19167.pdf visitado em 17/10/2014> visitado em 17/10/2014.

BRASILIANO, Antonio., Gestão de Continuidade de Negócios - GCN, 1ª edição, São

Paulo: Editora Sicurezza, 2014. 105p.

KARANACUS, C., Contratos de SaaS são vagos sobre níveis de serviço, diz Gartner ,
computerworld, USA, Framingham, IDG News Service, 05/08/2013, disponível em
<http://computerworld.com.br/gestao/2013/08/05/contratos-de-saas-sao-vagos-sobre-
niveis-de-servico-diz-gartner/ > visitado em 17/10/2014.

VIOLINO, B., Quatro tendências críticas em TI para a continuidade dos negócios,

San Francisco, USA, CIO/INFOWORLD, 03/04/2012. Disponível em < http://cio.com.br/
gestao/2012/04/03/quatro-tendencias-criticas-em-ti-para-a-continuidade-dos-negocios/
> . Visitado em 18/10/2014.

REFERÊNCIAS BIBLIOGRÁFICAS
CANCIAN, Maiara Heil. Um modelo de capacidade e maturidade para melhoria de processo
de software para saas colaborativo, 2013, 305p. Doutorado em Engenharia e Automação de
Sistemas, Universidade Federal de Santa Catarina, Florianópolis

KLOSTERBOER,Larry, The Road to Effective Capacity Management, 31/03/2011

disponível em http://www.ibmpressbooks.com/articles/article.asp?p=1693533 visitado em
15/10/2014

42 • capítulo 1
NASH, K., Quando o desastre acontece, como deve agir a liderança de TI?, Computerworld,
USA, Framingham,16/09/2011. Disponível em < http://computerworld.com.br/
gestao/2011/09/15/quando-o-desastre-acontece-como-deve-agir-a-lideranca-de-ti/ >
Visitado em 18/10/1014

GORGES, Eduardo, Os benefícios da ITIL disponível em http://inov9.blogspot.com.br/,

28/08/2009, visitado em 28/09/2014

OGC, ITIL Version 3: Information Technology Infrastructure Library - Service Design Volume.
London, England: ITIL Foundation – OGC, 2011. 449p

PROCEEDINGS OF SAFETY, HEALTH AND ENVIRONMENT WORLD CONGRESS, 11,

2011, Guimarães, PORTUGAL. O processo de gerenciamento da capacidade na utilização
da telefonia voip com o uso de ferramentas de análise em redes sociais, Guimarães: COPEC,
28/09/2011. Disponível em < http://proceedings.copec.org.br/index.php/shewc/article/
view/804/753#.VENQBvnF8WI >. Visitado em 18/10/2014 (É preciso se cadastrar, mas
o cadastro é gratuito).

NO PRÓXIMO CAPÍTULO
Neste capítulo aprendemos como manter a continuidade dos serviços de TI da organização.
Aprendemos também a gerenciar a capacidade dos serviços de tecnologia da organização.
Olhar para o negócio e as tecnologias de suporte alinhados, com custos balanceados. É
planejar para que a organização se mantenha capaz de operar.
No próximo vamos entender como ficam os custos financeiros destas operações, como a
organização se relaciona com a TI, como os serviços de TI devem ser financiados e mantidos
com os recursos da organização. Veremos também como funciona a disponibilidade dos ser-
viços de TI. O dinheiro deve remunerar os serviços? Os sistemas podem cair, como devemos
agir para minimizar este risco?

capítulo 1 • 43
 2
Gerência Financeira
e Disponibilidade
2  Gerência Financeira e Disponibilidade
O assunto é dinheiro. E todos sabem que quando o assunto é dinheiro, os âni-
mos ficam mais exaltados. No ambiente corporativo não é diferente, a relação
financeira entre a TI e as outras áreas da organização exige atenção e cuidado
para que a harmonia necessária possa ser mantida e os serviços tenham uma
entrega com a qualidade esperada.
Disponibilidade é um substantivo que significa estar disponível, livre, sem im-
pedimento. Talvez neste último sentido se fundamente seu significado para a
gestão de TI por nível de serviço. Estar sem impedimento para funcionar, estar
sempre disponível para o uso.
É destes assuntos que trataremos neste capítulo.

OBJETIVOS
•  Concluindo este capítulo, o aluno deverá ser capaz de:
•  Definir indicadores financeiros;
•  Conhecer as metodologias atuais;
•  Definir a estratégia de processos, modelos de custos e os custos de TI;
•  Compreender os processos de prestação de serviços;
•  Conhecer as principais áreas do planejamento;
•  Conhecer os custos dos serviços de TI;
•  Entender o conceito de disponibilidade;
•  Aprender tolerância a falhas e a relação entre erro, defeito e falha;
•  Aprender a classificar as falhas
•  Entender os benefícios do gerenciamento de disponibilidade para a operação.

REFLEXÃO
Há um tempo as tecnologias eram caras e computador era artefato de empresa grande.
Salas enormes, especialistas que cobravam por hora. Uma despesa necessária para a mo-
dernização. O tempo passou e a despesa se transformou em investimento e agora é serviço.
Serviço que deixou de ser custo para organização, agora pode ser rentável e é parte do pro-
cesso. Para determinados tipos de negócio é todo o processo.

46 • capítulo 2
E falando em dinheiro, com certeza já aconteceu com você. Viagem de férias, praia lotada,
seu dinheiro acaba. Aí você passa a mão na carteira, avisa o pessoal que vai ali no banco 24
horas (tem sempre algum por perto). Quando você vai chegando perto, estranha.... não tem
fila. Ao chegar ao terminal você descobre porque, um aviso na tela diz: Este terminal está fora
de operação! Utilize outro por gentileza.
Só que no quiosque só tem aquele. Você acaba descobrindo a indisponibilidade do modo mais
cruel, vai andar bastante e sofrer outro tanto até conseguir colocar a mão no seu rico dinheirinho.

2.1  Gerenciamento Financeiro de TI

Como funciona o relacionamento financeiro entre os processos de negócios da

organização e os processos de entrega de serviços de TI?
Existe muita confusão no ambiente organizacional quanto aos limites desta
relação. A administração da organização geralmente acha que o investimento
em TI é alto e muitas vezes exagerado enquanto a área de TI entende que está
fazendo um bom trabalho, mas tem dificuldade para justificar o nível de inves-
timento às outras áreas da organização.
Todos entendem a dependência dos negócios da organização às entregas
de serviço de TI, mas a justificativa dos custos é necessária face aos altos inves-
timentos exigidos.
Este capítulo vai facilitar a vida do analista responsável pela gerência dos
serviços de TI. É possível transformar os serviços de TI em custos aceitáveis
para os negócios da organização através de uma gerência que defina indicado-
res e metodologias que demonstrem estes custos de maneira simples e clara.
Que divida as responsabilidades da operação dos serviços com a operação dos
negócios. Que transforme o Service Desk no fornecedor interno de tecnologia
para todas as áreas da organização. Desta forma deixará de ser um custo, um
peso nos ombros da organização para se tornar um departamento rentável, for-
necedor de recursos e que recebe pelos serviços prestados, mesmo que a co-
brança destes valores dos clientes internos seja opcional.
Esta mudança de visão é na verdade o principal eixo de mudança quando
falamos de Tecnologia da Informação entregue como serviço. Este novo for-
mato de prestação de serviços é o coração de todas as boas práticas definidas
na ITIL V3.

capítulo 2 • 47
2.2  Visão Geral do Processo

Os princípios da administração financeira devem ser aplicados na gestão finan-

ceira dos serviços de TI. É necessário definir indicadores que serão utilizados
para o monitoramento de desempenho, definição de resultados alcançados.
Os valores clássicos de indicadores financeiros são custo, faturamento e
lucro. São conhecidos no meio administrativo como indicadores de leg, pois
medem o passado.
Pense bem, custo tem a ver com a aquisição de um bem. O bem já está na
posse da organização então deve ser contabilizado. O Faturamento é o processo
que ocorre como consequência da venda, ou seja, o bem ou serviço já foi ven-
dido e está na posse do cliente. Lucro se obtém como resultado da operação se
ela for positiva, isto é, se a soma de todos os custos envolvidos for menor que
o obtido na venda do serviço ou produto, caso contrário é prejuízo. Lucro ou
prejuízo também se referem a dados ou informações consolidadas, referentes
ao que aconteceu.
Segundo MAGALHÃES (2007), O modelo financeiro da gestão de TI por ní-
veis de serviço, deve levar em consideração os seguintes indicadores:
•  Índice de redução da relação de gasto de TI sobre receita do negócio;
•  Índice de redução do gasto de TI por cliente;
•  Índice de investimento em serviços de TI frente ao investimento no negócio.

O primeiro diz respeito à rentabilidade do negócio. TI não somente faz parte

do negócio, mas muitas vezes é o meio onde ele se desenvolve. Este é um indica-
dor importante para demonstrar aos envolvidos nas operações da organização,
como o Service Desk tem conseguido ser mais eficiente para que a organização
consiga mais receita com menor custo relacionado a aquisições de serviços de TI.
O segundo está relacionado à distribuição dos custos dos serviços de TI na
estrutura da organização. Clientes (internos) são cada uma das áreas solicitan-
tes de serviços de tecnologia para o suporte de suas operações. No caso de ser-
viços utilizados por mais de uma área (link de dados por exemplo) a melhor
prática e o rateio do custo proporcional a carga de uso.

48 • capítulo 2
 O terceiro índice diz respeito à participação dos custo de tecnologia no pla-
nejamento estratégico da organização. O quanto representará o investimento
em aquisição de serviços de TI em relação a quanto será investido para a opera-
ção do negócio em outras áreas.
Este último indicador tem um comportamento interessante à medida que a or-
ganização dependa mais da TI ou seja uma empresa embarcada em TI, pois quanto
maior for sua dependência, mais próximo de 1 este índice estará.
As metodologias atuais levam em consideração a participação dos serviços
de TI no planejamento estratégico da organização. Nesta abordagem, devemos
considerar como modelo mais aderente às estratégias de negócio da organiza-
ção o BSC (Balanced Scorecard). O BSC é um modelo que analisa além da visão
financeira pura e simples. É um modelo de causa e efeito que pretende indicar
como atingir os objetivos , levando em consideração as seguintes visões:
•  financeira, como devemos aparecer para nossos investidores;
•  clientes, com devemos ser vistos pelos clientes;
•  processos internos, em quais dos nossos processos internos devemos
nos sobressair;
•  aprendizado e crescimento, como manter a habilidade de mudar e pro-
gredir.

Não se trata de previsão, mas de traçar objetivos alcançáveis (factíveis) para que as
imagens produzidas no BSC se materializem no futuro programado.
Para o gerenciamento financeiro dentro da Gerência de TI por Níveis de
Serviços significa ter em mente os mesmos objetivos estratégicos da organi-
zação, ao menos no que diz respeito à parcela de participação da TI nas ope-
rações da organização.
Este modelo foi criado pelos professores Robert Kaplan e David Norton
(Harvard Business School) tendo como objetivo medir a performance de uma
organização em uma perspectiva onde a abordagem financeira estivesse balan-
ceada com métricas não financeiras, menos ortodoxas e tradicionais. A figura 5
a seguir, mostra o modelo básico do BSC.

capítulo 2 • 49
 Financeiro

Aprendizado Visão e
e Cliente
crescimento
estratégia

Processos
internos do
negócio

Figura 5 – BSC - básico - Balanced Scorecard Institute (1998-2014)

Traduzido e adaptado

O BSC pode ser operado a partir de software próprio e neste caso, também
funciona como um formato de comunicação intraorganizacional. Reports de
desempenho podem ser enviados do BSC de um departamento para compor
os dados do BSC da organização. Desta forma o Service Desk pode alimentar os
dados referentes às métricas de TI estabelecidas na estratégia da organização
para cada uma das áreas estratégicas (financeiro, cliente, aprendizado e proces-
sos) diretamente no framework, que a composição dos dados da TI nos dados
da organização ocorrerá de forma automática.

CONEXÃO
Uma cópia free para uso pessoal do software de controle do BSC pode ser obtida em
<http://www.strategykpi.com/Downloads/CurrentDownloads.aspx>. A página está em in-
glês mas tem imagens com os passos necessários para a instalação para facilitar o processo.

50 • capítulo 2
2.3  Benefícios

Alguns dos benefícios que podem ser alcançados com a gerência financeira dos
serviços de TI:
•  Aumento da segurança em elaborar e gerenciar orçamentos. Com uma
boa gerência, as informações necessárias para boas negociações estarão
sempre a mão;
•  Uso mais eficiente dos recursos de TI na organização, o que se mostra
óbvio face ao controle exercido sobre as aquisições e gastos periódicos,
além das comparações cotidianas com as práticas de mercado;
•  Aumento da satisfação dos clientes a partir do momento em que eles
souberem pelo que eles estão pagando, já que a transparência da gestão
e o BSC indicam a importância do bom relacionamento com os clientes;
•  Decisões de investimentos podem ser feitas através de informações mais
precisas, pois a gestão financeira monitora o desempenho e o andamen-
to dos custos diariamente, revelando comportamentos dos serviços com
extrema precisão;
•  Aumento do profissionalismo da equipe dentro da organização de TI
porque agora esta relação reproduz um modelo cliente-fornecedor e o
cliente insatisfeito pode mudar de fornecedor se assim o desejar.

Dividindo os benefícios por sub-processo:

Orçamento:
•  Estima os custos totais necessários para manter a organização de TI;
•  Reduz o risco de se gastar além do disponível;
•  Compara os custos previstos com o realizado;
•  Garante recursos financeiros para manter a TI dentro dos Níveis de Ser-
viços acordados.

Contabilidade de TI:
•  Informações gerenciais sobre os custos do fornecimento de Serviços de TI;
•  Gerentes de TI e de negócio alinhados, assegurando custo efetivo para
execução dos serviços de TI;
•  Possibilidade de contabilizar de maneira precisa todas as despesas feitas
pela organização de TI;
•  Demonstrar o consumo de serviços em termos financeiros;

capítulo 2 • 51
 •  Possibilidade de determinar os custos que determinem NÃO fazer um
investimento específico;
•  Fundamentar uma forma de cobrança.

Cobrança:
•  Recupera os custos da TI de uma maneira mais bem elaborada;
•  Influencia a demanda de serviços e o comportamento do cliente.

2.4  Principais Áreas

2.4.1  Planejamento de Capital

Para este planejamento os dados financeiros devem estar alinhados com as práti-
cas de controle financeiro. Esta relação é desejável para que a TI trabalhe nos mes-
mos moldes de controle que o restante da organização. Todo o aporte de capital,
próprio da organização ou capitado junto a agentes financeiros deve ser feito atre-
lado a um estudo de viabilidade e fazer parte do orçamento da organização.

2.4.2  Planejamento da Demanda dos Serviços

O analista deverá verificar as necessidades futuras de investimentos e mudan-

ças nos custos planejados. Esta análise deverá levar em conta todos projetos de
crescimento previstos ou aquisição de novos ativos ou serviços.

2.4.3  Planejamento Regulatório dos Custos de TI

Todo movimento financeiro realizado deverá estar alinhado com as regras de

negócio da organização.
Estes três planejamentos ocorrem anualmente, dentro do ciclo de planeja-
mento anual (descrito mais adiante), precedendo o orçamento da organização,
onde o orçamento específico da TI está inserido.

2.5  Custos de Serviços de TI

Os custos de serviço de TI estão diretamente relacionados com os processos de

fornecimento de serviços necessários à operação dos negócios da organização.

52 • capítulo 2
 Para melhor entendimento, são todos os custos dos serviços constantes do
catálogo de serviços da organização.
A gerência financeira deve determiná-los para a elaboração do orçamento.
Normalmente podem ser divididos em custos de hardware, software, pessoal,
acomodações, transferência e serviços externos.
Saiba mais – Veja neste artigo de Ann Bednarz, da Network World/EUA
(2011), uma visão de quanto custa TI na Empresa. Disponível em http://cio.com.
br/gestao/2011/01/27/quanto-custa-ti-na-empresa/ Visitado em 18/10/2014.
Os custos de hardware são custos de capital relacionados à aquisição de com-
ponentes do tipo servidores, equipamentos de infraestrutura de rede, impresso-
ras, estação de trabalho e outras que serão incorporados ao patrimônio da organi-
zação. Estes sofrem depreciação que pode ser calculada a partir de três métodos:
•  Método Linear onde um montante igual (um valor fixo de 10% por exem-
plo) do valor do ativo é depreciado a cada ano.
•  Método Redução Percentual, com um percentual do custo do capital de-
duzido a cada ano.
•  Depreciação por uso, sendo a depreciação determinada pelo tempo de
uso do equipamento.

2.6  Modelo de Custos

Os modelos de custos da contabilidade da gerência de TI por nível de serviço são

de certa forma triviais. Obedecem a um modelo clássico de contabilidade, utili-
zado pela maioria dos processos contábeis de montagem de processos de custos.

Custos Diretos ou Indiretos

Custos diretos são aqueles que podem ser associados a um serviço especí-
fico. O custo de uma impressora que é usada somente por um departamento é
um custo direto, pois ela é usada somente por ele.
Custos indiretos não podem ser relacionados a um serviço exclusivo. A ener-
gia elétrica do departamento TI é um custo compartilhado para todos os clien-
tes que ele atende, sendo impossível associá-lo a um só cliente ou serviço.

Custos de Capital x Custos Operacionais

Custos de capital referem-se a compra de itens que serão usados durante
alguns anos e estão sujeitos à depreciação. Computadores, storages e impres-

capítulo 2 • 53
soras são deste tipo. Custos operacionais são os resultantes do dia-a-dia dos
serviços de TI da organização. Neste grupo podemos incluir os custos de equi-
pe, eletricidade, manutenção de hardware, etc…
Normalmente significam pagamentos repetitivos, cujos efeitos podem ser
medidos dentro de um curto espaço de tempo. A eletricidade é mensal, manu-
tenção de hardware pode ser por demanda, mas normalmente ocorre em perí-
odos menores que 12 meses.

Custos Fixos ou Variáveis

Os custos fixos são permanentes de valor fixo, sem mudanças em curto pra-
zo. Um bom exemplo deste tipo é o aluguel do prédio.
Custos variáveis mudam de acordo com uso do serviço. Serviço de tele-
fonia pode ser um bom exemplo deste tipo, energia elétrica também. São
custos definidos pelo consumo. No caso do telefone é possível determinar
em negociações para que a parte variável tenha um menor impacto nos cus-
tos da organização.

2.6.1  Gerenciamento de Disponibilidade

Este capítulo tem como objetivo definir a importância dos conceitos de dispo-
nibilidade, a gerência, os níveis de disponibilidade aceitáveis para o ambiente
corporativo, sua relação com os níveis de SLA contratados e as responsabilida-
des envolvidas. Também serão tratados os conceitos de tolerância a falhas, as
diferenças entre falha, erro e defeito.
Exploraremos a latência, a classificação de falhas e a medição da disponibi-
lidade e seus fatores para calcular os coeficientes que determinarão o cálculo
da disponibilidade. São medidas essenciais para que se estabeleça dentro da
organização um processo de gerenciamento da disponibilidade.
Traçaremos um roteiro para sua implementação, falaremos sobre seus be-
nefícios e os fatores críticos de sucesso.

2.6.2  A Importância da Disponibilidade e da sua Gerência

Imagine a cena, você está na sala de cirurgia de um hospital sendo submetido a

uma cirurgia de pulmão que exige um processo conhecido como circulação ex-
tracorpórea. Esse processo literalmente tira o sangue do seu corpo e faz ele cir-
cular por uma série de aparelhos para que seja oxigenado e depois ser devolvido

54 • capítulo 2
para seu corpo, para que o oxigênio seja levado as células do seu organismo.
Parece claro que um sistema como esse, movido por energia elétrica, preci-
sa ser mantido a todo custo em funcionamento, pois se ele parar de funcionar
enquanto a cirurgia estiver ocorrendo, você vai morrer. Ficar vivo é o requisito
principal do negócio “sua vida”.
Usei este exemplo extremo porque é exatamente esta visão que a maioria
das organizações tem hoje dos sistemas informatizados. Sua dependência de-
les é tão grande, que se eles pararem de funcionar parcial ou totalmente, a or-
ganização está com seus negócios em grande risco.
Esta situação que acabamos de descrever ajuda a entender o conceito de
disponibilidade das tecnologias de informação. Significa ter a infraestrutura
de serviços em condições de funcionar sem problemas, de forma contínua, de
maneira que os negócios da organização possam ser realizados sem interrup-
ção de qualquer espécie. Indo além disso, significa estar pronto para que, caso
um problema ocorra, a recuperação da situação normal possa ser restabelecida
com o menor trauma possível, no menor lapso de tempo.
Desta forma, gerenciar a disponibilidade desta infraestrutura de serviços,
que viabiliza os negócios, passou a ter uma importância fundamental para a
grande maioria das organizações.
Mas como é possível estabelecermos os níveis e critérios desta gerência?
O ITIL define que disponibilidade é um aspecto crítico da garantia do servi-
ço e seu propósito é garantir que o nível de disponibilidade entregue em todos
os serviços de TI atenda de maneira eficaz às necessidades de disponibilidade
e/ ou metas de nível de serviço acordadas (SLA).
Portanto, no caso das tecnologias de informação, disponibilidade pode ser
traduzida como a manutenção dos SLAs acordados que visam à manutenção
dos requisitos de negócios da organização.
Gerenciar disponibilidade será então, tendo em mente o que foi discutido
no primeiro capítulo, a gerência da manutenção dos níveis de SLA, conforme
foram contratados.
O que torna ainda mais importante a boa configuração dos índices de de-
sempenho a serem medidos para o monitoramento dos serviços.
No primeiro momento da discussão destes índices, no capítulo 1, poderia
parecer que deveríamos priorizar desempenho e volume de negócio. Neste ca-
pítulo começamos a perceber mais claramente outras facetas importantes que
devem ter amparo de métricas no SLA. Disponibilidade tem grande importân-
cia na discussão de um SLA com o fornecedor de serviços.

capítulo 2 • 55
 ATENÇÃO
Conceitualmente disponibilidade é expressa, via de regra, em valores percentuais relacionados
ao tempo total (24h por dia, 7 dias por semana).
Um serviço está, ou deveria estar, disponível X por cento do tempo. Ex: A internet do Supersho-
pping deverá ter disponibilidade de 98%

Vendo de forma prática:

Pergunta: Será que o provedor de internet vai conseguir manter o link de da-
dos operando dentro dos parâmetros necessários para a operação dos negócios
da organização?
Resposta: Se os negócios da organização ocorrem exclusivamente pela in-
ternet (se ela falhar não haverá meio alternativo de operação), indicará ao ser-
vice desk que um contrato de suporte de uma segunda solução deverá existir
para entrar em operação imediatamente, no caso de falha da principal. Mas
a exploração das possíveis falhas e suas soluções veremos mais adiante, em
tópico próprio.

2.6.3  Visão Geral e Objetivos

2.6.3.1  Responsabilidades
Dois aspectos devem ser observados quanto à responsabilidade na gestão
da disponibilidade.
O primeiro deles quanto aos profissionais envolvidos que responderão pela
gestão. O tamanho da organização terá influência na definição do responsável
pela gestão da disponibilidade. Em organizações menores, o próprio gerente
do “Service Desk” poderá exercer a função. Nas organizações maiores, ou de de-
pendência mais crítica deste quesito, a responsabilidade recairá sobre um staff
próprio para a área, com gestor, supervisor e time de analistas.
O segundo aspecto de responsabilidade está na própria ação da gerência.
A gerência da disponibilidade não será responsável por gerenciar a con-
tinuidade do negócio, particularmente nos incidentes de grandes propor-
ções caracterizados como desastres. Existe uma área gerencia própria para
esta finalidade.

56 • capítulo 2
 São atribuições da gerência:
•  Monitorar todos os aspectos da disponibilidade relativos aos serviços de
TI e os componentes de suporte, com os eventos, alarmes com scripts
automatizados para recuperação;
•  Manutenção de uma série de métodos, técnicas e cálculos para medir e
reportar todas as métricas envolvidas;
•  Assistência com avaliação e gestão de riscos;
•  Entender as atuais e futuras demandas de disponibilidade, objetos de
contrato;
•  Influenciar o desenho dos processos de serviços e componentes para
que estejam alinhados aos processos de negócio;
•  Produzir um plano de disponibilidade que permita ao provedor de ser-
viços dar continuidade ao trabalho de providenciar e disponibilizar
serviços alinhados aos objetivos definidos nos SLAs, permitindo que se
planeje o futuro dos níveis de disponibilidades necessários, conforme
definido no requisitos de níveis de serviço (SLRs);
•  Manter uma rotina agendada de testes para os componentes e mecanis-
mos de serviços que sejam sujeitos à falha;
•  Assistir a identificação e solução dos diversos acidentes e problemas as-
sociados à indisponibilidade de serviços;
•  Melhoria proativa da disponibilidade de serviços ou componentes, onde
quer que seja justificável, alinhando às necessidades do negócio.

Além de outras responsabilidades onde a disponibilidade do serviço ou

componente sejam fator de risco ou necessidade para o negócio.

CONCEITO
SLR (System Level Requirement) Requisitos de nívels de serviço de um sistema. Níveis espera-
dos pelo negócio a serem suportados pelos sistemas de informação agregados a ele.

O exercício desta gerência poderá também exercer papeis indiretos na rela-

ção da gestão com as outras áreas de negócio da organização.
Será responsabilidade dela controlar os anseios das áreas menos familiariza-
das com conceitos técnicos (administração, financeiro, RH) quanto as expectati-
vas de disponibilidade. Explicar por exemplo, que uma disponibilidade de 98%,

capítulo 2 • 57
o que significa dizer que das 24 horas de cada dia, ela deve estar no ar por pelo
menos 23h31m12s , custará 5 vezes mais barato que uma disponibilidade de 99%
(23h45m36s). E que se olharmos de forma objetiva, não existe uma diferença signi-
ficativa entre os dois valores, a ponto de comprometer o desempenho do negócio.
Também será responsabilidade da gestão o alinhamento cuidadoso dos re-
quisitos do negócio e suas necessidades, com os SLAs acordados com fornece-
dores internos e externos. Quanto mais crítica for a dependência do negócio
em relação às infra estruturas de TI, mais cuidadoso e apurado deverá ser o
olhar da gerência de disponibilidade na negociação dos SLAs.
Também deverão se reportar aos níveis hierárquicos superiores, quanto aos
resultados obtidos na gestão.
A gestão das disponibilidades tem importância direta nos tópicos relativos
a manutenção dos serviços que iremos discutir a seguir.

2.6.3.2  Tolerância a Falhas

É a habilidade de um serviço de TI ou item de configuração de continuar a ope-
rar corretamente após a falha de um componente.
É parte integrante da análise de impacto no negócio e da análise de riscos
e irá proporcionar uma melhor compreensão dos processos contidos na conti-
nuidade dos serviços de TI e dos negócios da organização.
Serviços com tolerância a falhas geralmente são compostos de estruturas
internas que podem reconhecer a falha por meio de scripts verificadores, sen-
sores ou outros meios de verificação efetivos.
Sua capacidade de recuperação está disponível para que o serviço se mante-
nha a maior parte do tempo ativo sem a necessidade de intervenções externas
(disponibilidade).
Muitas vezes você estará sendo beneficiado pela utilização de um dispositi-
vo com tolerância a falhas e não perceberá sua ação. Alguns dispositivos e servi-
ços com esta capacidade tem uma recuperação muito rápida.
Vejamos uma lista dos serviços e componentes com tolerância a falha
mais conhecidos:
•  UPS (popularmente conhecido como nobreak) e BP (Backup Power) Os mais
comuns são os geradores), que são utilizados para manutenção do fluxo de
energia sem quedas, aos sistemas de TI. São usados em sequência, o UPS
suporta os primeiros momentos de queda de energia até que os geradores
sejam ligados e atinjam o limite de energia necessário ao sistema;

58 • capítulo 2
 •  RAID (Redundant Array of Independent Drives), um sistema de utiliza-
ção de discos rígidos que permite a gravação dos dados em múltiplos vo-
lumes (dois ou mais), baseado em um sistema de controle de erro, que
permite que um disco seja substituído com o sistema em funcionamen-
to em caso de falha, sem perda de dados. Este mecanismo é conhecido
como HOTSWAP (Troca a quente);

CONEXÃO
Uma cópia free para uso pessoal do software de controle do BSC pode ser obtida em
<http://www.strategykpi.com/Downloads/CurrentDownloads.aspx>. A página está em in-
glês mas tem imagens com os passos necessários para a instalação para facilitar o processo.

•  Duplicação de servidores ou CLUSTER, quando o sistema operacional

opera “espelhado” em outra unidade. Dois ou mais servidores, que con-
tém o mesmo conteúdo, sendo atualizados ao mesmo tempo, funcio-
nando como um só, de tal modo que se um deles deixa de funcionar, o
outro assume a tarefa sozinho, sem perda de dados;

CONEXÃO
Um artigo da revista Exame informática tem uma dica para montar um cluster. Você pode
acessá-lo em <http://info.abril.com.br/dicas/arquivos/transforme-uma-rede-de-pcs-num-
cluster-p-1013.shtml visitado em 15/10/2014>.

•  Servidores com redundância interna de fonte, memória e outros compo-

nentes, são equipamentos idealizados para minimizar o tempo de indis-
ponibilidade. Estes componentes duplicados entram em ação na falha
do componente principal, sem perda de dados;
•  Internet load balance, um sistema baseado em roteador específico que
permite a unificação de dois ou mais serviços de provimento de inter-
net de fornecedores diferentes conectados como um só. Para o usuário
o funcionamento é transparente. No caso de queda de um dos fornece-
dores de serviço, a internet e os serviços de dados continuam operando,
utilizando as outras linhas conectadas. Para o serviço parar, todos os
operadores de internet contratados precisam parar ao mesmo tempo.

capítulo 2 • 59
 Você deve ter percebido que a maior parte dos sistemas de tolerância a falhas
está embarcado em um dispositivo (hardware) e não em aplicativos. Mas existem
sistemas de aplicativos para gerenciamento de contingências, criando redun-
dâncias críticas e tolerância a falhas. Um bom exemplo é o Big-IP. Imagine uma
conexão de internet como uma central telefônica multi linhas com um certo nú-
mero de linhas tronco recebendo chamadas simultâneas. Ela vai conseguir aten-
der chamadas enquanto o número de chamadas for menor que as linhas-tronco.
Quando atingir o limite de linhas, quem ligar, vai receber sinal de ocupado.
É isso que ocorre com requisições de conexão a um website. Quando o nú-
mero de requisições ultrapassa a capacidade do site, as conexões “entrantes”
entram em colapso e o sistema deixa de responder.
O Big-IP controla as conexões, redirecionando o excesso de conexões ao ende-
reço original para outro endereço virtual, fazendo um balanceamento automático
da carga de conexões, parece que seu endereço IP ficou grande. Dai o nome Big-IP.
E tudo acontece em tempo de execução, sem que o usuário perceba.
Existem atualmente um sem número de soluções de tolerância a falhas disponíveis
para incremento dos serviços, diminuição dos riscos e aumento da disponibilidade
dos serviços utilizados pelo “Service Desk” de uma organização.

2.6.3.3  Falha, Erro e Defeito

Para compreendermos melhor os conceitos de disponibilidade e tolerância a
falhas, estudados nos capítulos anteriores, vamos definir a diferença entre fa-
lha, defeito e erro.
Erro é um resultado incorreto provocado por uma intervenção humana. No
caso de um programa de computador por exemplo, pode ser uma instrução de
código escrita sem a sintaxe adequada. Na rotina de fabricação de um produto,
pode ser o manejo de uma ferramenta sem a habilidade necessária, causando
dano ao produto fabricado. Na aviação, uma manobra executada fora dos padrões
de segurança e além da capacidade de suporte da aeronave, podendo causar sua
queda. Você conhece muitas outras definições de erro e poderá enumerá-las na
sua mente com facilidade.
Defeito é a manifestação do erro. No caso do software o nome do defeito é Bug.
Falha é o que é observado quando ocorre um defeito, normalmente uma
situação indesejada.
Durante o gerenciamento de disponibilidade, monitoramento de falhas é uma
forma reativa de solução do problema. Estaremos sempre “atrás” da solução. Pode-

60 • capítulo 2
remos saber que existe um erro. Poderemos localizá-lo, corrigí-lo. Depois da corre-
ção, voltaremos ao monitoramento e o ciclo se repetirá.
Esse é um formato adequado para gerar estatísticas e métricas para defini-
ção de SLAs nos próximos contratos, que estejam mais alinhados com os requi-
sitos do negócio.
Mas existem situações onde uma abordagem proativa pode resultar em um
cenário muita mais atraente para os negócios da organização.
Existem situações de falhas que funcionam como tragédia anunciada. Nor-
malmente aquelas que têm influência do número de requisições a um serviço, ou
aquelas em que um componente tem desgaste conhecido com o passar do tempo
(Lembra das baterias do exemplo da loja de departamentos do capitulo 1.6 ?). Tam-
bém se encaixam neste cenário as situações de serviços que tem limite de execu-
ção, que podem ser ultrapassados com o crescimento do negócio da organização.
Nestes casos, o analista não pode deixar a tragédia acontecer, deve se antecipar
ao problema. O plano de disponibilidade deve contemplar uma análise das possibi-
lidades de falhas para este tipo, face aos dados levantados pelas métricas de monito-
ramento e providenciar seu ajuste antes que a falha ocorra.
Atitudes proativas custam menos aos negócios da organização do que
as reativas.
Sempre fica mais barato evitar que o problema ocorra do que solucioná-lo de-
pois do acidente. Sobram os custos da solução e o prejuízo causado pela falha.
A abordagem proativa ainda tem a seu favor a diminuição do stress orga-
nizacional. A falha provoca um desacerto dentro da área fim provocando um
stress que se propaga dentro da organização atingindo além dos usuários dire-
tos, seus superiores imediatos, a administração geral, o service desk e em mui-
tos casos a diretoria e os acionistas (serviços em situação pública de desastre
podem alterar o comportamento das ações da organização momentânea ou
definitivamente, podendo até levá-la a falência). Exageros a parte, com a pro
atividade atuando, o stress diminui.
Devemos partir do pressuposto que falhas deverão existir. Elas fazem parte do
negócio e precisam ser tratadas com seriedade, conhecidas, corrigidas quando
possível, evitadas quando prováveis, diminuindo sua incidência no âmbito dos ne-
gócios da organização. Quanto mais próximos estivermos do “zero falhas”, mais
disponibilidade dos serviços necessários ao andamento do negócio poderemos ga-
rantir. Mais confiável será o serviço fornecido.
Então tenham sempre os 100% como objetivo.

capítulo 2 • 61
 CONEXÃO
Veja este artigo de David Talbot, publicado pela Mit Technology Review (Uma revista do
Massachusetts Institute of Technology) em 29 de agosto de 2014, contando a história
de um apagão que deixou mais de 11 milhões de pessoas e empresas sem internet nos
Estados Unidos, disponível em: < http://www.technologyreview.com.br/read_article.
aspx?id=45966>, visitado em 17/10/2014

2.6.3.4  Latência
Latência é a diferença de tempo entre o início de um evento e a percepção dos
seus efeitos. Você liga seu notebook e tem aquele tempinho até as luzes come-
çarem a piscar e o monitor acender, isso é latência.
Para entendermos a magnitude deste conceito no ambiente de uma organi-
zação, vamos voltar ao exemplo da equipe de fórmula 1, no começo deste livro.
Você é o piloto. Dentro do veículo existem sensores que detectam anomalias
no funcionamento dos componentes. O carro está bom, veloz e estável. Você
está no primeiro lugar da prova e tudo conspira pra que você vença a corrida.
De repente, sem aviso prévio, o carro começa a perder potência. Os técnicos
procuram a falha nos monitores da telemetria enquanto você se arrasta pela
pista. Então o defeito é descoberto. Os técnicos enviam um sinal para o car-
ro corrigindo o problema remotamente. Mas o motor demora uma eternidade
(na fórmula um, segundos viram eternidade) para retomar a potência e quando
isso acontece você está em décimo lugar na prova. Que azar!
A situação descrita demonstra a latência que existiu entre o início do evento
“corrigir o defeito do motor remotamente” e o efeito perceptível “o motor reto-
mar a potência”. Em TI, este efeito também é conhecido como lag (a abreviação
de Latency At Game ou Latência no jogo).
Existem muitas variáveis que interferem nos serviços de uma organização,
criando latência. A quantidade de serviços interligados de forma encadeada,
a distância entre as diversas unidades da organização, a quantidade de dispo-
sitivos de segurança entre os nós de uma rede, a fragmentação da rede em su-
bredes, gerenciadas em diversas camadas diferentes, congestionamento por
excesso de uso, recuperação de falhas que dependam de reinício de sistemas
servidores de alta performance a lista é grande, diretamente proporcional à
quantidade de serviços do catálogo da organização.

62 • capítulo 2
 O problema fica mais evidente em sistemas encadeados. A rede de computado-
res de uma organização é um exemplo típico. Vamos percorrê-la de ponta a ponta.
Começando pelo servidor principal. Se ele estiver desligado, levará um bom tempo
entre o apertar do botão e a disponibilidade de seu serviço para a rede. Se for um
equipamento do tipo mainframe, isso pode ser mais de uma hora de espera.
Com o servidor ligado, o próximo passo físico da rede será um switchcore, um
equipamento que controla a administração de regras da rede e suas subredes, que
também tem uma latência, depois vem os switches de borda, ligados ao switchcore.
O próximo passo vai depender da distância a ser percorrida. Vamos encurtar
o caminho e colocar o seu computador a uma distância que permita a conexão
via cabo de rede comum. Então você estará conectado.
Um evento que for iniciado no servidor principal, sofrerá todos os efeitos
de latência de cada um dos dispositivos e softwares embarcados do início até o
final da linha.
Se o servidor estiver do outro lado do mundo, multiplique o tempo de latên-
cia várias vezes.
A latência ainda pode variar em tempo, ora mais demorada, ora mais rápi-
da. Este fenômeno é conhecido como Jitter.
A gerência de disponibilidade precisa monitorar estes efeitos porque trazem
prejuízo a qualidade dos serviços da organização. Nos casos mais graves, podem
causar falhas de operação. Os serviços de internet mais afetados pela latência são
as operações de voz sobre ip (VoIP), streaming de vídeo (youtube, vimeo e outros),
serviços de podcast, enfim, todos os casos de fluxo contínuo de informações.
Seus efeitos são menos percebidos em operações que ocorrem por requisi-
ções fragmentadas.

CONCEITO
Latência é indisponibilidade, mesmo que por tempos relativamente pequenos. Mas fica claro
que, quando seus efeitos ocorrem em ambientes conectados, eles se potencializam.
Latência também é o tempo que um serviço leva para ser restabelecido, depois da ocorrência
de uma falha. É uma responsabilidade direta da gerência de disponibilidade.

capítulo 2 • 63
2.6.3.5  Classificação de Falhas
Falhas fazem parte dos processos em geral. São inevitáveis em ambientes de
tecnologia, tamanha a quantidade de variáveis e dispositivos que fazem parte
do catálogo de serviços de qualquer organização atualmente.
Existem várias definições de classificação para falhas descritas na literatura
especializada.
A principio são divididas em Falhas físicas, provocadas pelos componentes
e as humanas, de projeto e interação.
Podemos dividi-las, para fins de entendimento:
•  Originadas por especificação incorreta - A solicitação do serviço foi equi-
vocada ao especificar o escopo;
•  Originadas por implementação inadequada - A implementação pulou
etapas, deixou de treinar adequadamente;
•  Originadas por componentes com defeito - Componentes incluídos nos
serviços tem defeito na concepção;
•  Fadiga - O uso além dos limites para os quais um componente foi concebido;
•  Externas ao serviço - Caso das radiações eletro-magnéticas e variações
ambientais (raios, tempestades, etc…).
•  Operacionais - A operação, composta de pessoas, comete erros e provoca
a falha do serviço.
•  Podemos ainda definir as falhas quanto a:
•  Natureza - falha de software, hardware, operação e projeto;
•  Duração - se é permanente ou temporária;
•  Extensão - se é local ou global;
•  Valor - determinado ou indeterminado.

Falhas provocadas pela ação criminal ou mal intencionada (hackers) também

fazem parte do ambiente das organizações e tem crescido nestes últimos anos.
Lamentavelmente o Brasil tem juma grande incidência de ações desta nature-
za, principalmente com a utilização de redes zumbis (utilizadas principalmente
para execução de serviços mensageiros de grande volume) e fraudes bancárias.
Com a classificação das falhas, é possível agrupá-las para finalidade estatís-
ticas e para instituição de melhores métricas de desempenho, visando uma me-
lhor administração dos KPIs e por consequência, dos SLAs dos contratos para
fornecimento de serviços internos e externos da organização.

64 • capítulo 2
 SISTEMAS TRADICIONAIS REDES CLIENTE -
SERVIDOR
TOLERANTES A (NÃO TOLERANTES
NÃO TOLERANTES A FALHA
FALHAS A FALHAS)

Mean time to failure :

Mean time to failure:
6 a 12 meses Disponibilidade mé-
21 anos
Indisponibilidade após defeito: dia: 98%
(Tandem)
1a4h

Defeitos Defeitos
Defeitos
hardware: 50% software: 65%
projeto: 60%
software: 25% operações: 10%
operações: 24%
comunicações/ambiente: 15% hardware: 8%
físico: 16%
operações: 10% ambiente: 7%

Tabela 2.1 – Quadro de defeitos provocadores de falhas por setor e tolerância.

(LAPRIE, 1998)

Conforme podemos constatar no quadro acima, construído com dados

coletados (LAPRIE, 1998), os equipamentos e serviços com tolerância a falhas
apresentam uma estabilidade e disponibilidade significativamente maior da-
queles que não apresentam. Atualmente, motivado pelos preços mais acessí-
veis destes equipamentos e serviços, tem crescido substancialmente sua pre-
sença nas organizações. Esta realidade tem deixado mais evidentes as falhas
decorrentes de projeto, operações e as de software

2.6.3.6  Medição da disponibilidade

Medir a disponibilidade dos serviços de TI é parte da definição das métricas
necessárias, incluídas posteriormente nas negociações de índices de desempe-
nho e confiabilidade dos SLAs de serviços contratados interna e externamente.
A suite ITIL V3 tem uma série de métricas relacionadas à disponibilidade
que dariam para preencher um capítulo deste livro. Para a finalidade desta dis-
ciplina, focaremos nossa atenção à que tem maior aplicação prática.
Os mecanismos de monitoramento dos aplicativos de configuração do catá-
logo de serviços estão quase sempre preparados para incluir em suas métricas

capítulo 2 • 65
a ocorrência de falhas de um serviço ou componente. Geralmente tem incorpo-
rados em seus relatórios gerenciais todos os demonstrativos necessários para
a administração.
Contudo, é indicado realizar a medição da disponibilidade a partir da verifi-
cação dos critérios a seguir:
•  Confiabilidade - O tempo que um componente ou serviço funciona inin-
terruptamente sem ocorrência de falhas de qualquer natureza. Este índi-
ce traduz a busca da perfeição na prestação do serviço ou da qualidade
do componente, quanto maior o tempo, mais próximo dela estará.
•  Sustentabilidade - O tempo que um serviço ou componente do catálogo de
uma organização demora para ser restaurado após uma falha. Este índice
é medido a partir do tempo utilizado para que o serviço retorne à operação.
•  Função de negócio vital - É quando o serviço ou componente é crítico
para os interesses do negócio. Quanto maior a importância do serviço ou
componente para os interesses do negócio, maior deverá ser a sua dispo-
nibilidade. Para a composição deste valor, observar tolerância a falhas,
alta disponibilidade, operação e disponibilidade contínua.

CONEXÃO
Veja o artigo de Cezar Taurion intitulado “Disponibilidade é a solução” disponível em: <http://
computerworld.com.br/seguranca/2001/11/07/idgnoticia.2006-05-15.8338554806/>.
Em 2001 ele já ressaltava a importância desse quesito para as empresas com negócios
em e-business.

2.6.3.7  Fatores da Disponibilidade

Você poderá, a partir do que foi dito até aqui, concluir comigo quais são os fa-
tores que determinam a disponibilidade de um serviço ou componente de TI,
pertencente ao catálogo de uma organização. Os mais importante são:
•  complexidade da infraestrutura de TI. Obviamente, quanto mais com-
plexa a infraestrutura de TI para garantir o suporte de um processo críti-
co ou de alto valor pra o negócio, maior deverá ser dificuldade em garan-
tir a disponibilidade;
•  confiabilidade dos ativos e componentes. Existe um velho ditado que diz
que tudo fica mais fácil quando a ferramenta utilizada para o trabalho é

66 • capítulo 2
 boa. Isso vale para os equipamentos e serviços de tecnologia também.
Economizar neste quesito pode sair mais caro no final das contas;
•  reação rápida e eficiente a falhas. Aqui devemos pensar na reação física
e humana. Os equipamentos deverão conter níveis consideráveis de tec-
nologia de tolerância à falhas, recuperando-se automaticamente quan-
do elas ocorrerem e a equipe de TI deve contar com profissionais pre-
parados para o trabalho sob pressão e motivados constantemente para
enfrentar desafios;
•  qualidade na manutenção tanto preventiva(proativa) quanto correti-
va(reativa), a cargo da equipe de TI (interna ou outsourcing).

Além destes, outros fatores podem influenciar a manutenção da disponibi-

lidade dos serviços de tecnologia de uma organização:
•  Fatores ambientais, como presença de umidade, calor, elementos quími-
cos ou corrosivos podem afetar o funcionamento de alguns componentes;
•  Fornecimento de serviços externos sujeitos a falhas que não tem como
ser objetos de ações corretivas diretas, tais como energia elétrica, link de
comunicações e outros;
•  Atuação de elementos externos à organização, através de falhas na se-
gurança de rede, para utilização dos recursos da organização de forma
criminosa (hackers).

2.6.3.8  Cálculo da Disponibilidade

O cálculo primário de disponibilidade é definido pela fórmula:

Tempo de serviço acordado − tempo de queda

.100
Tempo de serviço acordado

Exemplo de uso da fórmula: Verificar se um serviço contratado com 99% de dis-

ponibilidade, para funcionar 24 horas, 7 dias por semana, em 30 dias, tendo ocor-
rido duas falhas de 1 hora em 30 dias está dentro da disponibilidade contratada.

24 x 30 = 720 horas de serviço acordado com 2 horas de queda

então : 720 − 2 . 100 99, 72%
720

capítulo 2 • 67
 Podemos concluir que o serviço está dentro da disponibilidade acordada,
com 99,72% de disponibilidade para um acordo de 99%

COMENTÁRIO
Estas rotinas de cálculo normalmente vem inseridas nos aplicativos de gerenciamento de con-
figuração de serviços, definindo os percentuais diretamente no dashboard de controle, o que
acaba eliminando a necessidade do cálculo em si. Entretanto consideramos importante conhe-
cer a origem do cálculo e seus fundamentos.

2.6.3.9  . Processo de Gerenciamento da Disponibilidade

O diagrama abaixo, figura 6, resume o processo de gerenciamento de disponibi-
lidade:

Necessidades de Critérios de projeto para

disponibilidade do negócio disponibilidade e recuperação

Avaliação do impacto Resiliência e avaliação de risco

no negócio da infraestrutura de TI

Necessidades de disponibilidade, Alvos acordados para disponibilidade,

confiabilidade e sustentabilidade confiabilidade e sustentabilidade
Gerenciamento da
Dados de incidentes e disponibilidade Relatórios sobre disponibilidade,
de problemas confiabilidade e sustentabilidade alcançadas

Dados de configuração Monitoramento da

e monitoração disponibilidade

Realizações quanto ao Planos de aperfeiçoamento

nível de serviço da disponibilidade

Figura 6 – Processo de disponibilidade - Entradas e saídas.

Fonte: (MACEDO, 2012).

O processo de gerenciamento de disponibilidade é um fluxo contínuo, que

existe até a extinção do processo. As entradas estão à esquerda e as saídas à direita.
Dados de entrada:
•  necessidades de disponibilidade do negócio;
•  avaliação do impacto no negócio para todos os processos com suporte da TI;

68 • capítulo 2
 •  necessidade de disponibilidade, confiabilidade e sustentabilidade para
componentes de infraestrutura de TI;
•  dados sobre incidentes e problemas que possam afetar componentes da
infraestrutura de TI. Esses dados podem ser adquiridos a partir de regis-
tros e relatórios;
•  dados de configuração e monitoração tanto de componentes de infraes-
trutura de TI quanto de serviços;
•  realizações quanto ao nível de serviço alcançado. A obtenção será possí-
vel através de comparação com os níveis de serviço acordados.

Dados de saída:
•  critérios de projeto para disponibilidade e recuperação para todos os ser-
viços de TI. Isso vale tanto para novos serviços quanto para os melhorados;
•  resiliência e avaliação de risco da infraestrutura TI, proporcionando re-
dução ou até mesmo a eliminação do impacto causado pela falha de al-
gum componente de infraestrutura;
•  alvos acordados para disponibilidade, confiabilidade e sustentabilidade
para os componentes de infraestrutura de TI necessários para garantir o
funcionamento dos serviços;
•  relatórios sobre disponibilidade, confiabilidade e sustentabilidade al-
cançadas;
•  Monitoração da disponibilidade;
•  planos de aperfeiçoamento proativo da disponibilidade de infraestrutu-
ra de TI.
Fonte: (MACEDO, 2012).

Comentando cada uma das entradas e saídas correspondentes descritas

por MACEDO(2012):
•  Necessidades de disponibilidade do negócio são as necessidades que o ne-
gócio ou operação tem em relação aos serviços oferecidos no catálogo da
organização e quanto é exigido de disponibilidades destes serviços para a
operação a saída correspondente é critérios de projeto para disponibilida-
de e recuperação para todos os serviços de TI. Isso vale tanto para novos
serviços quanto para os melhorados e estabelece os critérios que deverão
estar contidos nos projetos de TI no que diz respeito à disponibilidade ne-
cessária para a operação de um determinado negócio da organização;

capítulo 2 • 69
 •  Avaliação do impacto no negócio para todos os processos com suporte
da TI indica ao analista como deve proceder quando estiver avaliando
a disponibilidade de um produto ou serviço a ser colocado a disposição
de um processo de negócio da organização, o quanto de risco à operação
este processo envolve, como ele deverá estar disponível para garantir a
continuidade da operação e sua saida correspondente resiliência e ava-
liação de risco da infraestrutura TI, deve sempre estar proporcionando
redução ou até mesmo a eliminação do impacto causado pela falha de
algum componente de infraestrutura, diminuindo o nível de risco ao pa-
tamar ideal, ou seja, a não ocorrência do incidente.
•  a necessidade de disponibilidade, confiabilidade e sustentabilidade
para componentes de infraestrutura de TI é um parâmetro indispensá-
vel na análise de disponibilidade pois determinará se a operação de um
negócio da organização estará coberta pela solução disponibilizada no
catálogo ou se esta solução precisará ser substituída por uma melhor e
sua saída não poderia ser outra, alvos acordados para disponibilidade,
confiabilidade e sustentabilidade para os componentes de infraestrutu-
ra de TI, nada mais que os contratos e acordos e seus SLAs;
•  Dados sobre incidentes e problemas que possam afetar componentes
da infraestrutura de TI são a análise do histórico existente interna e ex-
ternamente à organização, dos pontos críticos à operação e a definição
de KPIs adequados para o seu perfeito monitoramento enquanto a sa-
ída relatórios sobre disponibilidade, confiabilidade e sustentabilidade
alcançadas é o resultado do monitoramento realizado pelo Service Desk
em sua ação cotidiana, são o resultado da coleta dos KPIs, centralizados
em dashboards de operação e concentrados em gráficos e relatórios pró-
prios para indicação de níveis dentro ou fora dos limites acordados.

CONCEITO
Dashboard – Painel de instrumentos, em tecnologia é um aplicativo que centraliza as infor-
mações de maneira organizada, em uma única tela, para proporcionar subsídios em proces-
sos de tomada de decisão.

70 • capítulo 2
 •  A entrada dados de configuração e monitoração tanto de componentes
de infraestrutura de TI quanto de serviços define os parâmetros levanta-
dos a partir do CMDB, a partir das definições de cada contrato de serviço
ou componente, dos KPIs de cada um e sua compilação em meios legí-
veis e sua saída é a operação do monitoramento pelo Service Desk em si;
•  As realizações quanto ao nível de serviço alcançado são o resultado
de todas as ações do processo resumidas em ações a partir de um pro-
cesso de melhoria contínua que resultarão em planos de aperfeiço-
amento proativo da disponibilidade de infraestrutura de TI, sempre
objetivando níveis de excelência em disponibilidade de serviços para
a operação da organização

CONEXÃO
O artigo “Confira 5 dicas para garantir a disponibilidade da infraestrutura de TI” traz uma visão
bastante interessante de como agir “proativamente” na solução de incidentes de disponibili-
dade no ambiente corporativo.
INFOWORLD/EUA, Confira 5 dicas para garantir a disponibilidade da infraestrutura de TI, USA,
Framingham,COMPUTERWORLD,05/03/2013 Disponível em: <http://computerworld.
com.br/tecnologia/2013/03/05/confira-5-dicas-para-garantir-a-disponibilidade-da-
infraestrutura-de-ti/>.

2.6.3.10  Indicadores de Desempenho

Além da abordagem clássica de medição por cálculo direto, devemos consi-
derar a existência de outros índices, utilizados com a finalidade de facilitar a
percepção da disponibilidade de um serviço a partir de índices de tempo abso-
lutos. estes indicadores de desempenho resumem a disponibilidade do serviço
ou componente da organização. A forma mais utilizada está demonstrada na
figura 7, a seguir.

capítulo 2 • 71
 MTTR

Detecção Reparo Restauração

Incidente Diagnóstico Recuperação Incidente

MTBF

MTBSI
Tempo

MTTR - Mean time to repair DOWNTIME Maintainability (Serviceability)

MTBF - Mean time between failure UPTIME Reliability, Availability
MTBSI- Mean time between system incident Média de confiabilidade Reliability

Figura 7 – Régua de diagnóstico de falhas e recuperação em função do tempo.

Adaptado pelo autor a partir da metodologia ITIL V3

Analisando os índices:
•  MTTR - (Mean Time To Repair) Tempo para reparo de um serviço após a
ocorrência de uma falha. Quanto menor o tempo deste índice, melhor
e mais disponível o serviço analisado. Este índice teve sua nomenclatu-
ra atualizada para MTRS (Mean Time to Restore Service) para evitar o en-
tendimento de que mediria somente o tempo para o reparo do serviço,
quando na verdade cobre todo o tempo da ocorrência do incidente, da
falha até a restauração estável do serviço.
•  MTBF - (Mean Time Between Failures) Tempo entre a restauração do ser-
viço de TI e uma nova ocorrência de falha. Quanto maior o valor deste
índice, maior a disponibilidade do serviço. este índice também recebe o
nome de confiabilidade. Ele também pode ser medido e reportado como
o índice abaixo
•  MTBSI - Tempo entre incidentes de um serviço, da mesma forma que o
anterior, quanto maior, maior a disponibilidade. Também conhecido
como confiabilidade.

72 • capítulo 2
2.6.4  Gerenciamento de Serviços de TI

O gerenciamento de serviços de TI é a ideia principal das bibliotecas ITIL.

Uma abordagem simples, porém poderosa.
Antes do ITIL, no anos 80, a área de TI das organizações era responsabili-
dade da administração da empresa e fazia parte do custo geral da organização.
Esta visão deixava a área de tecnologia como um fardo que a empresa toda
deveria carregar. Um fardo caro.
Com a nova abordagem a área de tecnologia passou a ser um fornecedor de
serviços. E cada setor da organização tem sua responsabilidade no custo das
tecnologias que utiliza. Esta abordagem tem a habilidade de demonstrar cla-
ramente para cada setor da organização que ele é dependente dos serviços de
tecnologia para executar suas funções. E que se está usando um serviço, certa-
mente terá um custo a pagar por ele, mesmo que simbolicamente.
A partir desta nova concepção a área de tecnologia das organizações deixou
de ser um fardo caro para se tornar um parceiro que colabora fortemente para
a obtenção dos objetivos da organização.
Por outro lado também deu a área de TI a responsabilidade de demonstrar
eficiência, controlar seus custos, ser inovador o tempo todo e obviamente, apre-
sentar resultados.

2.6.5  Processos Principais do Itil

Esta abordagem foi colocada neste livro para manter compatibilidade com o
ITIL® V2. Muitas empresas ainda utilizam este modelo de implementação.
Contudo a versão atual V3, engloba estes processos e muitos mais, sendo mais
abrangente e completa.
São 6 os processos principais da versão V2:
•  Change Management – Gestão da mudança
•  Release Management – Gestão de versões
•  Problem Management – Gestão dos problemas.
•  Incident Management – Gestão de incidentes
•  Configuration Management – Gestão de configuração
•  Service Desk – Central de serviços

capítulo 2 • 73
 ATIVIDADE
6.  Utilizando o caso da biblioteca definido no Capítulo 1 criar um plano de custos dos serviços
de TI. Utilize hardware, software, pessoal, acomodações, transferência e serviços externos
como os índices do plano.

* Para todas as questões seguintes, considere o mês com 30 dias

7.  Faça o cálculo da disponibilidade esperada para os SLAs definidos nas atividades do capí-
tulo anterior item 3 (SLA) solicitados a seguir:
a) Qual a disponibilidade para o SLA do link de internet com tempo sem operação por um
período máximo de 5 horas por mês, com no máximo 50% em uma única ocorrência?
b) Para o SLA do switch load balanced, com 2 horas de indisponibilidade máxima ?
c) A disponibilidade de atendimento técnico local do SLA do contrato de manutenção
será de?

REFLEXÃO
Dinheiro é sempre uma área sensível. Sabemos disso pessoalmente, nas organizações não
é diferente. Conseguir alinhar os custos da TI com as necessidades da organização exige
conhecimento e habilidade. Conseguir desenvolvê-los é navegar por mares onde poucos se
atrevem. Se fizer isso com frequência, pode chegar a capitão rapidamente.
A garantia de disponibilidade dos serviços e componentes de TI é hoje um processo crítico
na maioria das organizações. Isso ocorre em função da alta dependência dos processos de
negócio às entregas dos serviços de TI. Em alguns casos, como por exemplo uma organiza-
ção baseada em um site de comércio eletrônico, a TI é o negócio, então mais crítica ainda a
necessidade de disponibilidade. O Profissional que conseguir eficiência neste terreno, tem
colocação garantida no mercado de trabalho.

LEITURA
COPUTERWORLD, Virtualização: como garantir alta disponibilidade, USA, Framingham,
Computerworld/EUA, 22/08/2013, disponível em <http://cio.com.br/tecnologia/2013/08/22/
virtualizacao-como-garantir-alta-disponibilidade/ > visitado em 18/10/2014.

74 • capítulo 2
MONTE, F, Por que a Telefônica tem enfrentado tantos problemas técnicos? São Paulo,
20/05/2009, disponível em <http://computerworld.com.br/telecom/2009/05/20/por-
que-a-telefonica-tem-enfrentado-tantos-problemas-tecnicos/> visitado em 18/10/2014.

OVERBY, S., 9 pré-requisitos para vender seu plano de terceirização de TI para o

CFO, CIO/EUA, 25/04/2013. Disponível em <http://cio.com.br/gestao/2013/04/26/9-
pre-requisitos-para-vender-seu-plano-de-terceirizacao-de-ti-para-o-cfo/>. Visitado em
18/10/2014.

TAURION, C., A importância da TI nas estratégias de negócio, IDG NOW!, São Paulo,
28/11/2013. Disponível em <http://idgnow.com.br/blog/tecnologia/2013/11/28/a-
importancia-da-ti-nas-estrategias-de-negocio/>. Visitado em 18/10/2104.

REFERÊNCIAS BIBLIOGRÁFICAS
BEDNARZ, A., Quanto custa TI na empresa?, CIO/Network World, Framingham, MA/USA,
27/01/2011. Disponível em < http://cio.com.br/gestao/2011/01/27/quanto-custa-ti-na-
empresa/ >. Visitado em 18/10/2014

INFOWORLD/EUA, Confira 5 dicas para garantir a disponibilidade da infraestrutura de TI,

USA, Framingham,COMPUTERWORLD,05/03/2013 Disponível em <http://computerworld.
com.br/tecnologia/2013/03/05/confira-5-dicas-para-garantir-a-disponibilidade-da-
infraestrutura-de-ti/>, visitado em 18/10/2014.

LAPRIE, J. C.; Dependability: von concepts to limits. In: Proceedings of the IFIP International
Workshop on Dependable Computing and its Applications. DCIA 98, Johannesburg, South
Africa, 12/01/2014, 1998. p. 108-126.

MACEDO, Diego; Processo de gerenciamento da disponibilidade in: Um pouco de tudo

sobre TI - Disponível em <http://www.diegomacedo.com.br/processo-de-gerenciamento-
da-disponibilidade/> 09/10/2012, visitado em 03/10/2014

capítulo 2 • 75
MAGALHÃES,I.; PINHEIRO, W., Gerenciamento de serviços de TI na prática: uma abordagem
com base na ITIL. São Paulo: Novatec, 2007, 672p.

OGC, ITIL Version 3: Information Technology Infrastructure Library - Service Design Volume.
London, England: ITIL Foundation – OGC, 2011. 449p

OGC, ITIL Version 3: Information Technology Infrastructure Library - Service Strategy Volume.
London, England: ITIL Foundation – OGC, 2011. 373p

TAURION, C., Disponibilidade é a solução, USA, Framingham, COMPUTERWORLD,

07/11/2001. Disponível em <http://computerworld.com.br/seguranca/2001/11/07/
idgnoticia.2006-05-15.8338554806/>, visitado em 18/10/2014

NO PRÓXIMO CAPÍTULO
Neste capítulo percebemos a importância de cuidarmos das finanças da TI, e de mantermos
a disponibilidade dos serviços de TI.
No próximo capítulo nós seremos apresentados ao COBIT, uma outra suite de melhores
práticas, voltada a governança, Aprenderemos também a trabalharmos com indicadores de
desempenho e resultado. São ferramentas necessárias para indicar o andamento do trabalho
realizado pela equipe de TI, a qualidade de suas entregas e até a satisfação de seus clientes.
Vamos ver como é?

76 • capítulo 2
 3
Indicadores de
Desempenho
e Qualidade e
Planejamento de
Capacidade
3  Indicadores de Desempenho e Qualidade e
Planejamento de Capacidade

O gerenciamento de nível de serviço é o coração das diretrizes do ITIL V3. Ele

funciona baseado numa constatação simples. O mais importante é que a satis-
fação do cliente seja garantida. Você deve estar se perguntando: - Mas espera aí,
essa não é a condição para qualquer negócio?
Claro que é. E foi esta mudança de olhar que transformou a área de tecnologia,
aquele departamento caro, que ficava isolado na empresa, colocando empeci-
lho em todas as ações que qualquer departamento da empresa precisasse rea-
lizar. Agora ela é o fornecedor de serviços e soluções que precisa apresentar re-
sultados e agradar seus clientes (as outras éreas da empresa agora são clientes),
esse é o verdadeiro sentido do gerenciamento de nível de serviço. Seus serviços
são monitorados e os resultados são utilizados para processos de melhoria que
refletem uma entrega de qualidade a preço justo.
A gerência da capacidade na entrega dos serviços de TI já foi inicialemtne abor-
dada na aula dois, em suas atuações básicas. Nesta aula serão abordadas as
questões relativas à capacidade de recursos e o gerenciamento da demanda.
Vamos lá?

OBJETIVOS
•  Conhecer o COBIT;
•  Entender o que são indicadores de desempenho e sua gestão;
•  Entender o que são indicadores de resultado;
•  Aprender a medir qualidade em TI
•  Conhecer métricas de processo e projeto e suas diferenças;
•  Entender o ciclo de Deming, conhecido como PDCA;
•  Entender o que é balanceamento da capacidade;
•  Capacidade de recursos e suas incertezas;
•  Gerenciamento da demanda.

78 • capítulo 3
 REFLEXÃO
Há alguns anos atrás o computador ficava em uma sala com ar condicionado (muitas vezes era a
única com esse conforto alem da do presidente da empresa), cercado de segurança e cuidados.
Hoje ele está presente nos lugares mais exóticos e inesperados, ele está presente em pratica-
mente tudo com o que você se relaciona.
Também é certo que a capacidade de um serviço de TI suprir a operação de um negócio está
presente em sua vida e você nem se dá conta disso. Cada vez que você usa um cartão de débito,
cada vez que você acessa um site de compras, faz check-in de uma passagem aérea ou utiliza
um serviço público em um balcão de atendimento. Mesmo quando fala ao telefone celular, esta
ligação só é possível porque um serviço de TI tem a capacidade de manter a operação. Você
somente se dá conta disso quando ele falha!

3.1  Indicadores de Desempenho e Qualidade de Serviço em TI

3.1.1  Introdução

O uso de indicadores de desempenho para medir o trabalho realizado por uma

equipe ou pessoa não é uma ideia nova. Já existia desde as linhas de produção
e mesmo antes, na concepção do engenheiro americano Frederick Taylor, ao fi-
nal do século XIX. Mas então porque ganho tanta importância nos dias de hoje,
com a tecnologia?
A resposta não é tão simples. A história recente da tecnologia da informação
em sua relação com as organizações tem sido pautada pelo uso indiscriminado
de recursos para o apoio às operações de negócio, como se a TI fosse a solução
imediata para todos os problemas.
Quando recentemente acontecimentos de ordem global obrigaram as cor-
porações a reverem suas estratégias e sistemas de controle, acabaram desco-
brindo que podiam fazer o mesmo resultado com uma parcela bem menor de
recursos de tecnologia. Poderiam se mais eficientes.
A adoção de políticas de melhores práticas e controle veio de encontro a
essa necessidade. A partir destes acontecimentos, a adoção de indicadores de
desempenho foi o próximo passo.

capítulo 3 • 79
 A adoção destas métricas tornou possível a obtenção de resultados objetivos
para o uso de recursos de tecnologia e sua consequente adequação às necessida-
des das organizações, de forma mais equilibrada, sem desperdícios de recursos.
Com o aumento da competitividade e como consequência do processo de
globalização da economia, estas práticas forma elevadas a um nível muito alto.
A busca da excelência em serviços tem conduzido o departamento de TI, agora
denominado “Service Desk”, a estabelecer indicadores de desempenho cada
vez mais precisos e melhor alinhados ao modelo de negócio das organizações.
A partir desta constatação, vários modelos de atuação foram surgindo na
tentativa de orientar os profissionais de TI em melhores práticas que conduzis-
sem à obtenção dos resultados esperados.
As mais utilizadas atualmente são a biblioteca ITIL®, apresentada a vocês
no capítulo 2 e o COBIT, que conhecerão neste capítulo.

3.1.2  Apresentando o Cobit

O COBIT é um guia de melhores práticas do tipo Framework, voltado ao geren-

ciamento, a governança de TI. Atualmente está em sua 5ª versão (2012) com 94
páginas, dividido em 8 capítulos, 7 apêndices e o glossário.
Mas como entender governança? Governança é a palavra utilizada atual-
mente para definir o conjunto de regras, leis internas ou externas, processos,
costumes e regulamentos utilizados para regular a maneira que uma empresa
ou departamento será gerido.

CONCEITO
Framework – Termo utilizado em tecnologia para designar arcabouço de processos, regras,
programas e princípios de conduta relacionados a um objetivo ou finalidade específica.

Por esta definição simples é possível perceber que se trata de uma área de múl-
tiplas abordagens, que permite o entrelaçamento de áreas distintas da organização
e que naturalmente enfrenta situações de atrito natural, dificuldades de relaciona-
mento e trânsito de informações. O COBIT (Control Objectives for Information and
related Technology, do inglês Objetivos de controle para Informação e tecnologia
relacionada) é um conjunto de melhores práticas que colabora para que estas áreas
distintas de uma organização possam se comunicar sem maiores problemas, difun-

80 • capítulo 3
dindo a informação de forma ordenada e com aferição de resultados que permitem
uma gerência sólida e descomplicada.
Ele tem 5 princípios básicos que norteiam sua ação, demonstrados na figura.

1 - Encontrar
as necessidades
dos
stakeholders

5 - Separar 2 - Cobrir a
a governança do organização
gerenciamento fim-a-fim
Princípio
do
COBIT 5

4 - Habilitar 3 - Aplicar
uma abordagem um framework
holística único e integrado

Figura 8 – 5 princípios do COBIT – IT Governance Institute(2012)

Adaptado pelo autor.

Analisando os princípios do COBIT V5

Princípio 1 – Encontrar as necessidades dos stakeholders – Organizações
existem com a finalidade de criar valor aos stakeholders, para que sejam capa-
zes de manter o equilíbrio entre a realização de benefícios, a otimização dos
riscos e utilização dos recursos. Como cada organização tem suas particulari-
dades, o COBIT facilita a obtenção destes objetivos em cascata até o nível do ge-
renciamento de TI, oferecendo uma interface configurável, que pode ser ajus-
tada para atender as necessidades específicas de cada organização, mapeando
seus processos e práticas particulares.
Princípio 2 – Cobrir a organização fim-a-fim – o COBIT integra a governança
de TI na governança da organização. Cobre todas as funções e processos da or-

capítulo 3 • 81
ganização, não se limita aos processos de TI, trata informação e as tecnologias a
ela relacionadas como parte do todo da organização e considera todos os agen-
tes facilitadores relacionados aos serviços e componentes de TI com relevância,
como parte da governança e gestão da organização.
Princípio 3 – Aplicar um Framework único e integrado – existem muitas bi-
bliotecas de melhores práticas que são utilizadas para orientar as atividades de
TI. O COBIT se alinha a todas as bibliotecas relevantes em alto nível, podendo
se tornar o ponto de referência para a gestão de TI da organização.
Princípio 4 – Habilitar uma abordagem holística – O gerenciamento efetivo e
eficiente de uma organização requer uma abordagem holística, levando em conta
a grande quantidade de componentes que interagem. Ele define uma lista de facili-
tadores que dão suporte a implementação de um sistema de governança e gerência
de TI da organização que seja abrangente. Os 7 facilitadores do COBIT são:
•  princípio, categorias e frameworks
•  processos
•  estruturas organizacionais
•  cultura, ética e comportamento.
•  informação
•  serviços, infraestrutura e aplicações
•  pessoas, habilidades e competências

Princípio 5 – Separar a governança do gerenciamento – O COBIT 5 faz uma

clara distinção entre gerenciamento e governança. Estas duas disciplinas incor-
poram diferentes tipos de atividades, requerem estruturas organizacionais dife-
rentes e servem a propósitos diferentes. Resumindo, o COBIT 5 estabelece que:
•  Governança assegura que as necessidades, condições e opções dos stake-
holders são levantadas e medidas para determinar que os objetivos acor-
dados sejam alcançados de forma equilibrada, através das prioridades
relevantes aos processos de tomada de decisão, para que esteja em con-
formidade com os objetivos.
•  Gerenciamento planeja, constrói, executa e monitora atividades alinha-
das na direção do corpo da governança, colaborando para alcançar os
objetivos da organização. (IT GOVERNACE INSTITUTE,2012).

82 • capítulo 3
3.1.3  O Que é Kpi ou Pid

KPI (Key Performance Indicator) ou PID(ponto indicador de desempenho) são a

mesma coisa. PID é a nomenclatura utilizada em língua portuguesa.
De que adianta planejar o alcance de resultados se não for possível medí-
-los, mensurá-los para verificação de seu alcance? E como podemos fazer isso?
Existe um conceito bastante claro para executar esta tarefa utilizando ferra-
mentas de tecnologia, chamado KPI.

CONCEITO
Board – Termo em inglês que significa comitê, utilizado em gestão de negócios para deter-
minar o grupo de stakeholders (partes interessadas) que decide os destinos da organização.
KPI - (Key Performance Indicator) - Indicador chave de desempenho, termo utilizado em con-
troles de processos para indicar um ponto chave onde o desempenho deve ser medido atra-
vés de contagem numérica ou qualitativamente

Esta chave é obtida em localidades específicas no andamento dos processos

de negócio de uma organização.
Com ele é possível determinar se o processo foi iniciado, se as decisões neces-
sárias para seu andamento foram tomadas, se está parado em alguma fase e por
que, se a quantidade ou taxa esperada para a tarefa foi alcançada e se o tempo gasto
para a realização de uma fase foi satisfatório, além de muitas outras possibilidades.
Estes indicadores estão diretamente ligados ao plano estratégico da organiza-
ção (atualmente o mais utilizado é o BSC), sendo de vital importância para o board
da organização. Seu monitoramento mantém a direção e o rumo, de forma simples
e eficiente, dando aos condutores do negócio um mapa claro da situação, online.
Os KPIs podem ser atributos (valores lógicos 0 e 1, posicionais numéricos
exclusivos (1,2,3,4,5,6…) ou verdadeiro ou falso) e paramétricos relacionais
(percentuais relacionados). Os primeiros são mais utilizados para a definição
de uma escolha ou decisão enquanto os segundos para medição de níveis de
atendimento do requisito.
Você vai gerar os KPIs da equipe de vendas e, depois de ter consultado as
estratégias (BSC), poderá criar alguns deste tipo:

capítulo 3 • 83
 Crescimento das vendas - um KPI relacional que indicará o quanto suas vendas
estão crescendo por período, dentro das decisões estratégicas. Será demonstrado
graficamente como um velocímetro, onde o planejado será a faixa verde, o “pouco
abaixo do esperado” em amarelo e o “muito abaixo do esperado” em vermelho;
Oportunidade de vendas - Você pode organizar suas vendas em fechadas,
propostas, iniciadas e prospecção. Um KPI de atributos, que teria uma excelen-
te apresentação em formato de gráfico pizza;
Performance de produto - Medir o desempenho de vendas por produto pode
demonstrar com clareza quais estão dentro das expectativas do BSC e quais ne-
cessitam atenção.
Exemplos como estes demonstram a eficiência e importância dos índices
de desempenho. eles dão para os condutores do negócio informações essen-
ciais no processo de tomada de decisão. São termômetros do desempenho da
empresa e balizam novas estratégias e criação de novos produtos ou serviços.
Os indicadores de desempenho são fundamentais para o controle dos acor-
dos do SLA, na verdade são parte integrante dele. Um acordo de serviços precisa
das métricas de desempenho monitoradas para ser efetivo. O gerenciamento
por níveis de serviço não funciona sem KPIs que garantam os níveis de SLA.

3.1.4  O Que é Gestão de Desempenho?

Gestão de desempenho é o monitoramento das atividades e processos de TI

com a finalidade de alcançar métricas que conduzam ao objetivo acordado.
Dentre os valores medidos estão, velocidade, disponibilidade, confiabilidade,
continuidade, capacidade, etc... Todos estes critérios sã relativos aos serviços
entregues pela TI para sustentação das operações de negócio da organização.
Para que a gestão de desempenho alcance o sucesso desejado deverá estar
atrelada aos interesses da organização.
Uma corporação precisa ter definidos todos os seus requisitos de negócio,
se quiser utilizar os recursos de tecnologia com eficiência.
As definições de estratégia corporativa para a realização dos objetivos da or-
ganização irão definir os requisitos de tecnologia necessários.
Abaixo os princípios definidos pelo COBIT:
•  Efetividade: lida com a informação relevante e pertinente para o proces-
so de negócio, bem como a mesma sendo entregue em tempo, de manei-
ra correta, consistente e utilizável.

84 • capítulo 3
 •  Eficiência: relaciona-se com a entrega da informação através do melhor
uso dos recursos, de forma mais produtiva e econômica.
•  Confidencialidade: proteção das informações confidenciais a fim de se
evitar sua divulgação indevida.
•  Integridade: relaciona-se com a fidedignidade e totalidade da informa-
ção, bem como sua validade para o negócio.
•  Disponibilidade: relaciona-se a disponibilidade das informações quan-
do esta é exigida para processamento pelo negócio. Também possui rela-
ção com a salvaguarda dos recursos necessários e sua capacidade.
•  Conformidade: aderência a leis, regulamentos e obrigações contratuais
relacionadas ao negócio.
•  Confiabilidade: relaciona-se com a entrega da informação apropriada
para tomada de decisão.

Fonte: IT GOVERNANCE INSTITUTE (2007, p. 16).

Se você quiser realizar um trabalho eficiente na definição dos serviços

que atenderão os requisitos ou regras do negócio da organização deverá estar
atento a estes princípios. O estudo dos requisitos é iniciado por um documen-
to conhecido como RNS (Requisitos de Nível de Serviço) ou SLR (Service Level
Requirement), que contém todos os requisitos de negócio do cliente, relacio-
nados ao uso de TI.
Uma boa conduta para definição de requisitos de negócio é alinhá-los ao
Balanced Scorecard (BSC) da organização. O BSC define a estratégia da orga-
nização para um futuro próximo, define como ela pretende crescer e se posi-
cionar no mercado.
A gerência ou gestão do desempenho está diretamente liga a estratégia da
organização, muitas vezes resultado de levantamentos de inteligência compe-
titiva, com ações determinadas pela estratégia corporativa, gerando uma estra-
tégia competitiva e de operações, que refletirá nas atividades dos processos de
gerenciamento de TI.
Para seguir os princípios descritos você deverá ter sempre em mãos as infor-
mações necessárias para cumpri-los, ou no mínimo justificar a não aderência
de uma solução e seus motivos.

capítulo 3 • 85
 Existe um princípio descrito no ITIL®V3 (IT GOVERNANCE INSTITU-
TE,2012) que diz:

Medição é a primeira etapa que leva ao controle e, eventualmente à melhoria.

Se você não mede algo, você não pode entender o processo.
Se você não entende o processo, você não o controla.
Se você não o controla, você não consegue aperfeiçoá-lo.

Ferramentas de tecnologia são normalmente percebidas no ambiente cor-

porativo como formas eficientes de redução de custos de operação. Esta visão,
muito comum na maioria das empresas, sugere um plano de cortes de custos
operacionais, em função da adoção de serviços de TI. Esta abordagem deverá
estar alinhada com a estratégia corporativa, definida em um BSC.
Se o analista quiser realizar um bom trabalho, deverá entrevistar os atores,
aqueles que trabalham no departamento, verificando as ações realizadas, as
necessidades não cumpridas, o tempo gasto nas operações, as habilidades ne-
cessárias, as informações disponíveis e as necessárias, os recursos do sistema
informatizado atual para a realização da tarefa e as críticas dos usuários ao pro-
cesso como um todo.
A confrontação do processo atual, chamado na nomenclatura de processos
como “as is”, com o pretendido, conhecido como “to be”, gerará uma lista de
diferenças que pode ser definida como os requisitos do negócio.
A partir destas constatações será possível definir um novo processo que, se
factível, atenda aos requisitos do negócio.
Mas por que “se factível”?
Se pergunte se é possível atingir o objetivo desejado, pois muitas vezes o
objetivo traçado no plano de ações não pode ser atingido no processo descrito,
as expectativas foram mal dimensionadas.
Resistências a mudanças em ambiente corporativo ocorrem naturalmente,
as pessoas envolvidas nos processos tendem a defender sua posição. Mas exis-
tem limites humanos e tecnológicos para certas mudanças que inviabilizam o
processo, alguns claramente definidos pelos princípios citados anteriormente.
Uma solução inteligente deste problema para grandes organizações, que
possuem diversas unidades espalhadas em plantas distantes (em outras cida-
des ou países), é a adoção de um sistema compartilhado de serviços.

86 • capítulo 3
 A redução de custos operacionais ocorre pela evidente centralização dos re-
cursos em um único lugar, aumentando a escala dos produtos ou matérias pri-
mas adquiridas e pela nova relação que este poder de compra irá proporcionar
junto aos fornecedores.
À tecnologia caberá viabilizar a infraestrutura necessária para atender esta
configuração do serviço, compreendendo links de dados compatíveis, ambien-
tes de aplicativos adequados, repositórios de dados compartilhados e outras
medidas que permitam a realização dos processos no novo formato.
Outra situação interessante pode ocorrer.
Você chegará a conclusão que o objetivo pretendido poderá ser rapidamen-
te alcançado com a adoção de outsorcing (serviço terceirizado), a um custo ain-
da menor que o pretendido pelo stakeholder.

CONCEITO
Outsourcing – Termo utilizado para referência à serviço realizado fora do ambiente da orga-
nização ou por pessoas externas ao quadro de funcionários.

Isso é possível porque um sistema terceirizado adota processos de escala

diferentes, envolvendo uma quantidade maior de itens comprados, utilizando
uma rede de fornecedores cadastrados on line, oferecendo condições especí-
ficas de pagamento e entrega, enfim, um cenário que a sua organização não
poderá alcançar.
O serviço de TI de sua organização, com a adoção desta solução, seria sim-
plesmente substituído e extinto.
Você deverá estar com a mente aberta à todas as possibilidades.

3.1.5  Importância dos Indicadores de Desempenho

Os indicadores de desempenho são fundamentais na indicação dos parâmetros

da gestão de desempenho. Como dito no início deste capítulo, de que adianta
estabelecer requisitos de desempenho para os negócios da organização se não
for possível medi-los.
Com a presença cada vez maior das ferramentas, componentes e serviços de
TI nas operações que suportam os negócios da organização, estes indicadores
puderam ser conseguidos com mais facilidade.

capítulo 3 • 87
 Sua associação a sistemas de tomadas de decisão, baseados em Business
Intelligence com interface do tipo “painel gerencial” permitem uma ação ime-
diata dos gestores, diretamente no ponto onde está ocorrendo a defasagem em
relação aos parâmetros.
Usando o exemplo da equipe de fórmula1, é a telemetria recebendo um avi-
so que o consumo de pneu está acima do esperado para este momento da cor-
rida, sugerindo uma parada adicional antes do final da prova. Percebam que o
sinal foi recebido pela equipe enquanto a prova esta em andamento, em tempo
real, enquanto o veículo está andando. A tomada de decisão leva em conta o
fato que se o veículo continuar na pista poderá ter seu pneu furado, levando
um tempo muito maior para retornar aos boxes, perdendo tempo precioso e
comprometendo todo o planejamento da equipe para a prova e se a medida for
tomada a tempo, existe a possibilidade de recuperar o tempo da parada, conse-
guindo pontos importantes para o campeonato.
Da mesma forma é o ambiente corporativo, muitas vezes decisões podem
ser tomadas com maior antecedência, ou problemas corrigidos com maior efi-
ciência em função do monitoramento de indicadores de desempenho. Desas-
tres podem ser evitados.
Imaginem um sistema de manutenção de fornecimento de energia tipo UPS
(no-break) que sustente os servidores e a infraestrutura de rede de uma organiza-
ção. Este sistema tem indicadores de desempenho para medir a meia vida de suas
baterias. Meia vida é um indicador de capacidade, que demonstra com bastante
precisão, a capacidade de sustentação das baterias de um UPS em uso. O que sig-
nifica dizer que dá pra saber o tempo que as baterias suportam o sistema até desli-
garem. Existe um limite conhecido da TI, que é de cerca de 40%, onde as operações
do UPS passam a ser perigosas ( a energia acaba mais depressa quando a carga da
bateria vai chegando ao fim). Então é hora de substituí-las. Antes da tragédia (a
energia da rua acabar e as baterias desligarem logo depois do UPS entrar em ação).
Indicadores de desempenho são parte primordial de todas as gerências de
entrega por nível de serviço. Gerencia de capacidade precisa de indicadores, a
de disponibilidade idem, a financeira, a de continuidade, enfim, não é possível
gerenciar a TI sem eles.
Indicadores de desempenho fazem a diferença entre uma ação reativa e
uma ação proativa em relação ao problema verificado.
Como mostrado no exemplo das baterias, a atitude de troca antes do proble-
ma ocorrer é a mais indicada(atitude proativa).

88 • capítulo 3
3.1.6  Métricas de Projeto X Métricas de Processos

Métricas de projeto e de desempenho diferem na forma e no grau de detalha-

mento.
Tratam de temas semelhantes, porem com abordagem muito diferentes.
No projeto, são divididas em três fases distintas. Planejamento, onde as es-
timativas de esforço, custo, recursos, qualidade e produtividade são calculadas;
desenvolvimento onde são realizadas as composições e analise dos defeitos,
atualização das estimativas, falhas e produtividade e depois o produto, com o
resultado do projeto e sal posterior manutenção.
As métricas de processo são mais lineares, começando com a exatidão das es-
timativas, produtividade, tempos médios esperados e a densidade dos defeitos,
passando pela satisfação do usuário, custo médio por ponto de função e o esforço
médio, sendo na verdade uma agregação do estimado X realizado de cada projeto.
As métricas de processos são utilizadas para melhoria contínua e para a ges-
tão dos processos no dia a dia da organização.

3.1.7  Indicadores de Resultados

Abaixo uma lista dos indicadores de resultados mais utilizados nas organi-
zações:
Resultados de custos
•  Custo por Ponto de Função
•  Custo TI/Receita da Empresa
•  Custo unitário de processamento

Resultados produtividade ƒ
•  Pontos de função por homem-mês
•  Desktops/número de funcionários
•  Pontos de função/headcount de produção
•  Chamadas hekp-desk/headcount

Resultados relativos ao cliente ƒ

•  Indice de customer satisfaction
•  Atendimento a níveis de serviços
•  Imagem da organização de TI

capítulo 3 • 89
 Indicadores de Processos
•  Qualidade – densidade de defeitos
•  Atendimento ao schedule de produção
•  Tempos médios por tipo de serviço de desenvolvimento
•  Confiabilidade de entrega
•  Esforço de retrabalho
•  Exatidão de estimativas
•  Eficiência
•  MTTR
•  Taxa de retorno de solicitações
•  Eficiência do helpdesk.

Estes indicadores alimentam a base de dados dos aplicativos de Gestão de

entrega de serviços e outras áreas da organização, par subsidiarem os proces-
sos de tomada de decisão, de planejamento, de definição de orçamento e ou-
tras áreas beneficiadas

3.1.8  Como Medir a Qualidade de TI

A utilização de índices de desempenho são uma ferramenta adequada para me-

dir qualidade, mas não a única.
Nos processos de qualidade existem outras informações relevantes.
Qualidade é um adjetivo intangível. Definir qualidade significa definir defeitos
e defeitos estão dispostos em diversas classes e estão distribuídos a nível pessoal.
O que é defeito pra mim, pode não ser pra você. Nos processos de negócio são clas-
sificados a partir da ocorrência em uma atividade que impeça sua realização por
completo ou que comprometa o desempenho esperado para uma atividade.
No que diz respeito à tecnologia, defeito são anomalias da produção ou proces-
so que determinam o não funcionamento de um dispositivo ou serviço.
O primeiro modelo que definiu métricas de qualidade foi o Lean Manufactu-
ring, desenvolvido pela Toyota, em meados dos anos 80, tinha cinco princípios
fundamentais.
São eles:
•  Especificar valor do ponto de vista do consumidor final, o que vale é agra-
dar ao cliente do produto ou serviço;

90 • capítulo 3
 •  Identificar todos os passos na cadeia de valor para cada família de pro-
dutos ou serviços, eliminando todos os passos que não agreguem valor
ao produto;
•  Faça com que as etapas restantes ocorram de forma justa e eficiente,
fluindo suavemente em direção ao cliente;
•  Inverta o fluxo da produção para que o cliente determine a demanda ao
comprar o produto. Desta forma os estoques são naturalmente reduzi-
dos e não existe a necessidade de desova de estoques acumulados;
•  Como estes passos levam a transparência, permitindo que os gestores e
times eliminem mais resíduos, buscar a perfeição através da contínua
melhoria.
Fonte: (LEAN INSTITUTE, 1985, apud ITIL V3, 2011, p.66).

CONEXÃO
Veja mais sobre Lean acessando o Link https://www.youtube.com/watch?v=PbmotQJNr5E

No mesmo período, a Motorola começou a utilizar pioneiramente uma suí-

te de qualidade chamada SIXSIGMA. Consiste em um conjunto de métodos
para reduzir o nível de defeitos de fabricação abaixo de seis desvios-padrão, daí
o nome SIXSIGMA. Depois foi utilizado também na GE, tornando-se um dos
modelos mais utilizados e aceitos no mundo.
Sua implementação consiste da utilização de duas sub-metodologias, DMAIC
(define, measure, analyse,improve, control (definir, medir, analisar, implementar,
controlar)) e DMADV (define, measure, analyse, design, verify (definir, medir, anali-
sar, desenhar ou projetar, verificar). Seus objetivos são estatisticamente definidos
como 3.4 defeitos por milhão, o que percentualmente significa um sistema com
99.99966% de acerto. Qual das duas metodologias utilizar? Existem Outras?
A experiência de campo demonstra que nenhuma das duas é completa o su-
ficiente para a gestão de TI e que a melhor ideia de utilização seria uma junção
das duas. O que parece perfeitamente possível visto que não são conflitantes.
A IBM recomenda a combinação de ITIL, CMMI, Lean e SIXSIGMA como
forma de promover transformação nas organizações, outras organizações esco-
lhem ITIL, CMMI e SIXSIGMA como sua fórmula de sucesso.

capítulo 3 • 91
 Muitas organizações ficam na dúvida, perdendo um tempo precioso nas cadeiras da
direção, enquanto o monitoramento não cessa, e as equipes de tecnologia continuam
trabalhando. Na verdade não se trata de escolher entre as duas, mas qual será aplicada
primeiro. Os resultados irão aparecer.
Depois que você já viu nos capítulos anteriores como as práticas descritas são impor-
tantes na manutenção do negócio, deve estar claro que a qualidade de um serviço ou
produto será obtida como consequência da adoção destas práticas.

3.1.9  Ciclo de Deming ou Pdca

Uma matriz PDCA é um sistema de qualidade criado pelo físico Walter A.

Shewhart e popularizado pelo estatístico William Edwards Deming, considera-
do o pai dos processos de qualidade.
Consiste em quatro atividades básicas de um processo de melhoria traduzidas
pelos atos de Planejar (Plan em inglês) onde se decide quais os caminhos e objetivos
de uma determinada atividade ou processo; Fazer (Do em inglês) onde a atividade ou
processo está definido e pronto, sendo colocado em execução; Checar (Check em in-
glês) onde os resultados da atividade ou processo são medidos e comparados com as
métricas definidas no planejamento; e Agir (Act em inglês) para corrigir os eventuais
desvios ou erros de execução.
Em resumo define os atores responsáveis por cada uma destas ações duran-
te a execução de uma atividade, buscando os mais elevados índices de qualida-
de e performance para a execução da tarefa ou processo.
Para a implementação do gerenciamento de níveis de serviço em TI, estas
etapas servirão para definição dos pontos de melhoria que deverão ser parte
integrante de um SLA (Service Level Agreement). A figura 9 demonstra grafica-
mente um ciclo PDCA:

92 • capítulo 3
 P
lan D o

A ct
C heck

Figura 9 – Ciclo PDCA

Diagram by Karn G. Bulsuk (http://www.bulsuk.com) in Wikipedia under CC license.

O ciclo PDCA é uma ferramenta fundamental para os programas de gestão

de qualidade, sendo um padrão de referência na indústria da informação

3.2 Gerenciamento da Capacidade

3.2.1 Introdução

Já está claro para vocês que existe uma grande dependência dos negócios das
organizações aos serviços de TI. A maioria delas pode parar suas operações se
um serviço de TI essencial parar de funcionar por qualquer motivo.
Ocorre que no mundo dos negócios a influência dos resultados muitas ve-
zes pode comprometer o cuidado em manter serviços essenciais em funciona-
mento, opu ainda não é possível atender uma certa requisição de negócios pois
elas estão acima das capacidades disponíveis, que nem sempre podem ser ad-
quiridos sob pena de ficarem ociosos.
Este equilíbrio é de fato delicado. Como resolver esta equação?

capítulo 3 • 93
 Existe sempre uma pressão do controle da organização para diminuir cus-
tos e esta pressão direciona a equipe do Service Desk e seu gestor na busca de
soluções que possam atender essa demanda sem a perda de qualidade inerente
à entrega do serviço de TI e suas consequências.
O processo de gerenciamento da capacidade é fundamental para o planeja-
mento da TI de qualquer organização.
Podemos defini-lo diretamente como a garantia de entrega dos serviços de
forma adequada, com custos justificados, alinhados aos interesses do negócio
da organização.
O planejamento deve conter:
•  Procedimentos;
•  Sistemas;
•  Recursos de TI (especificados e analisados);
•  Desempenho esperado para os serviços de TI.

3.2.2  Balanceamento da Capacidade

O balanceamento da capacidade está relacionado com a verificação de real ne-

cessidade.
Podemos imaginar a situação em que um serviço está ocioso, com baixos
níveis de utilização atestados por indicadores de desempenho e demanda.
A análise pode claramente indicar que o serviço foi contratado com hiperdi-
mensionamento ou ocorreu um fato novo que o tornou dispensável.
Nem sempre um contrato dimensionado acima do necessário é uma condu-
ta de visão de futuro. O benefício esperado pode não ocorrer e o recurso utiliza-
do para este contrato poderá fazer falta para outro serviço.
O mesmo vai ocorrer se um sistema estiver sobrecarregado, ele vai gerar
dificuldade na execução das operações a ele subordinados e os operadores ou
clientes sofrerão com a baixa qualidade do serviço ofertado.

3.2.3  Definindo o Plano da Capacidade de Recursos

Como já visto, um plano de capacidade é discutido ao menos anualmente, nor-

malmente por ocasião do orçamento da organização. Ocorre desta forma porque
a capacidade tem uma grande afinidade com a liberação de recursos da organiza-
ção. O aporte de novos serviços ou a desistência tem forte impacto no orçamento

94 • capítulo 3
 Entretanto é recomendado que revisões sejam realizadas em períodos me-
nores, de acordo com a operação e cada organização. Ao menos a cada três me-
ses. Sua visão deve ser entendida e realizada de forma contínua, visando uma
entrega que possa suprir o atendimento das demandas dos processos de negó-
cio da organização.
Para ser efetivo, deverá começar por levantar a capacidade de todos os recursos
e serviços do catálogo de serviços de TI da organização, verificando se estão alinha-
das às necessidades da organização, dimensionando seu csuto para que atendam
a demanda. A evolução natural das ações do plano fazem as ações do Service Desk
deixarem de ser corretivas (reativas) para ações preventivas (proativas).
O plano de capacidade visa principalmente:
•  demonstrar a necessidade de melhorias em face dos custos necessários
para implementá-las;
•  Prever o impacto da aquisição de novos serviços ou aplicativos nos cus-
tos do orçamento, na infraestrutura existente e nos aplicativos legados
em produção;
•  Maximizar a produtividade proporcionada pelos serviços de TI com o
menor custo possível.

O Plano de Capacidade deve incluir:

•  Recursos computacionais
•  Hardware (desktop, servidores e etc)
•  Software (Sistema operacional, pacotes, gerenciamento)
•  Equipamentos de rede (LAN, WAN)
•  Periféricos
•  Recursos humanos
•  As pessoas que serão necessárias ao corpo da TI.

Base de dados da Capacidade (BDC)

O plano de Capacidade é definido com base nos dados do BDC (base de da-
dos da capacidade), que compreende:

Dados do negócio
•  Que mudanças no negócio afetam a capacidade de entrega da TI?
•  Ação: prever e validar as mudanças no negócio que afetam a capacidade.

capítulo 3 • 95
3.2.3.1  Base de Dados da Capacidade
A base de dados da capacidade é fornecida pelo CMIS (Sistema de informação
da Gerência da capacidade, no inglês Capacity Management Information Sys-
tem). ele é a pedra angular que possibilita a análise sistemática e acurada de
todos os dados referentes a capacidade. É um ambiente complexo, pois envolve
muitos tipos de dados diferentes, incluindo dados de negócios, serviços, recur-
sos ou utilização e dados financeiros de todas as áreas da tecnologia.
Entretanto o CMIS não é um sistema trivial, ligado a uma única base de da-
dos. A começar pelo fato das operações de TI não estarem restritas a um único
local (muitas vezes estão em muitas localidades distintas). Além disso, dados
de diversas áreas da TI e todos os componentes que suportam suas operações
poderão ser combinados para as análises, sendo necessários para a produção
de relatórios técnicos de gestão. E somente quando todas as áreas estiverem
integradas será possível produzir relatórios end-to-end (de ponta a ponta).
A integridade e a precisão dos dados utilizados pelo CMIS devem ser ma-
nipuladas com muito cuidado. Se o CMIS não for parte de um sistema integra-
do maior como um SKMS (Service Knowledge Management System, Sistema de
Gerenciamento do Conhecimento do Serviço) deverá ser interligado a ele para
garantir consistência e precisão às informações registradas.
A informação do CMIS é utilizada para formalizar os relatórios básicos de
performance e gerencia de capacidade do que será entregue aos consumidores
de serviços da TI.
Alguns tipos de dados a serem considerados nos relatórios:
Dados de negócio
São essenciais para garantir qualidade de informação das atuais e futuras
necessidades do plano de negócios da organização. Todas as ações de negócio
geram impacto na infraestrutura de TI e seus dados são utilizados para validar
as mudanças planejadas e as do futuro da organização. Dados de negócio in-
cluem transações, numero de créditos concedidos, numero de vendas, volume
de vendas, numero de linhas de produtos, etc….

Dados de serviço
Para uma abordagem mais direta, dados sobre serviço podem estar direta-
mente armazenados nos bancos de dados do CMIS.
Entendemos como dados típicos de serviços por exemplo tempos de res-
posta de transações, volumes acumulados por trabalho, taxas de transação. Em

96 • capítulo 3
geral, o SLA (Acordos de Nivel de Serviços) e o SLR (Requisitos de Nível de Ser-
viço) são suficientes para prover o CMIS dos dados necessários aos objetivos de
registro e monitoramento. Para garantir estes objetivos é aconselhável acres-
centar dados do SLM (Gerência de nível de serviço), desta forma será possível
receber relatórios com avisos antes que os serviços parem.

Dados de utilização de recursos

O CMIS precisa registrar o nível de utilização dos recursos de todos os compo-
nentes de serviços de suporte de TI. Muitos dos recursos de TI tem limitações no
nível de utilização. Sua utilização inadequada pode gerar resultados imprevisíveis,
alguns param de funcionar. Outros podem comprometer as operações do negó-
cio, provocando prejuízos em relação a operações em níveis normais. Por exemplo,
processadores não devem ter mais que 80% de utilização, redes do tipo LAN não
podem ter mais que 40% de uso compartilhado de sua banda. Recursos tem outras
limitações físicas através das quais uso e conectividade ficam comprometidos, o
numero de conexões de um gateway de rede ou um tipo de disco físico comparti-
lhado. Todas as limitações de cada componente, o histórico existente de sua per-
formance e de seu comprometimento e muitos outros dados referentes ao dia a dia
da utilização dos recursos disponíveis da TI. Uma característica deste tipo de dados
é que ele, por ser gerado automaticamente pela maior parte dos componentes de
hardware, normalmente se refere a um enorme volume de dados, o que exige um
apuro técnico para guarda e análise destas informações com precisão.

Dados financeiros
O processo da gerência de capacidade precisa de dados financeiros. Estes
dados são utilizados para avaliar possibilidades de modernização alternati-
vas, novos cenários para o plano de capacidade e o custo de financiamento dos
componentes de infraestrutura de TI. É necessário sempre comparar os custos
atuais dos recursos de hardware de TI com os que são praticados pelo mercado.

A maioria destes dados está presente no processo de gerência financeira

dos serviços de TI, mas a gerência da capacidade precisa considerar estas infor-
mações para gerenciar os futuros requisitos de negócio da organização.
Você já deve ter percebido que capacidade é um conceito bastante comple-
xo. É a condição a ser mantida, é o negócio sempre funcionando, sendo avalia-
do, para se ter certeza que a infraestrutura vai dar conta do recado.

capítulo 3 • 97
 A manutenção de uma base de dados precisa é de fundamental importância
para que as ações tomadas no sentido de garantir a capacidade sejam funda-
mentadas e com maior chance de garantir o futuro da organização.
O Banco de Dados da Capacidade (BDC) é a pedra fundamental do processo.
Ele é usado para formar a base dos relatórios e contem informações técnicas rele-
vantes para o Gerenciamento da Capacidade. Desta forma a informação contida
aqui fornece para os outros processos os dados necessários para as suas análises.
O Gerenciamento da Demanda é responsável pelo gerenciamento ou carga
de trabalho na infraestrutura, para utilizar melhor a capacidade atual ao invés
de aumentá-la. O comportamento do usuário é influenciado para que se use
uma carga de trabalho diferente, por exemplo, usar determinado recurso da TI
em outro horário do dia para aliviar a falta de capacidade.
O Dimensionamento de Aplicação está relacionado à avaliação dos requisi-
tos de capacidade das aplicações durante seu planejamento e desenvolvimen-
to. Os requisitos de capacidade de uma nova aplicação precisam ser entendidos
e a infraestrutura pode ser ajustada para atendê-los.
Através de simulação ou com auxílio de modelos matemáticos é possível a
predição dos requisitos futuros da capacidade. Os resultados desta atividade
podem ser usados como uma entrada no Plano de Capacidade.
O Plano de Capacidade é desenhado a partir da base dos dados do BDC
(banco de dados da capacidade) do core do CMIS, dados financeiros, dados do
negócio, dados técnicos, etc. O plano é orientado para o futuro, tendo como
base um período de pelo menos 12 meses.
Os relatórios conferem o desempenho da capacidade durante um determi-
nado período. Os relatórios podem trazer números que sirvam para comparar
os índices dos SLA’s.

3.2.4  Incertezas Sobre a Capacidade

No planejamento da capacidade é comum que o analista ou CIO se depare com

algumas incertezas. Com o aumento da participação da responsabilidade dos ser-
viços de TI nas operações de negócio da organização, é uma consequência natural.
A maior parte delas diz respeito a adequação da relação custo-benefício harmo-
niosa com os interesses da organização e alinhada ao orçamento anual.
O gerenciamento financeiro da entrega dos serviços de TI tem forte influên-
cia na diminuição destas incertezas.

98 • capítulo 3
 O plano de capacidade deverá estar sempre alinhado ao gerenciamento fi-
nanceiro da TI e da organização, atento a novas tecnologias, inovações disponi-
bilizadas pelos parceiros terceirizados e da equipe própria. Novas formas de re-
alizar o mesmo serviço ou de substituir um componente oneroso estão sempre
surgindo e devem ser testadas nas condições de trabalho para uma transição
tranquila, caso sejam adotadas.

3.2.5  Gerenciamento da Demanda

O gerenciamento da demanda diz respeito ao monitoramento dos serviços e

componentes utilizados pela organização. Conforme visto na aula 5, a defini-
ção de indicadores de desempenho tem como uma de suas atribuições corri-
queiras a verificação da demanda. Na verdade ela é um resultado obtido em
função dos indicadores.
Demandas são por definição, índices variáveis. Suas variações podem ser maio-
res ou menores, ligadas a períodos do dia, a épocas do ano, a situações de emer-
gência ou eventuais, uma série de fatores particulares de cada modelo de negócio.
Um exemplo simples de demanda eventual é a declaração de renda recebida
pelo site da Receita Federal do Brasil. É uma demanda forte, de magnitude, po-
rém restrita a um período do ano. O serviço tem que estar preparado para aten-
dê-la. No entanto, no restante do ano é um serviço com quase nenhuma procura.
O gerenciamento deve procurar uma solução que seja pontual, para que os
custos de infraestrutura não seja onerados. Deve ser uma solução preparada
para atender a necessidade eventual e que possa ser descartada nos períodos
de ociosidade. Um contrato de serviço sazonal.
O gerenciamento de demanda pode ser realizado a partir de planilhas com
os níveis de atividade dos serviços e com o perfil dos usuários de cada serviço.
Além disso é possível criar um tipo de segmentação dentro do quadro de usuá-
rios para limitar a utilização de recursos por grupo. Este tipo de expediente está
sugerido no ITIL®V3, (OGC,2012, Service Strategy, p 204-207).

ATIVIDADE
8.  Com o exemplo da Biblioteca, determine quais são os índices de desempenho que po-
derão ser medidos para a obtenção de serviços de TI com qualidade necessária para a
manutenção das operações.

capítulo 3 • 99
9.  Utilizando o exemplo da biblioteca, faça um plano de gestão de demanda para definir um
novo orçamento de serviços de TI. Considere a possibilidade de substituir o aplicativo
SaaS por um de operação local.

REFLEXÃO
Não é necessário ressaltar a importância do gerenciamento do desempenho nas entregas
dos serviços de TI. As métricas de desempenho são a base para todos os outros gerencia-
mentos. O analista deve estar sempre atento aos requisitos de negócio para estabelecer
métricas factíveis, que atendam os interesses da organização.
O gerenciamento da capacidade deve ser uma ferramenta de uso intenso dentro da orga-
nização. Se utilizada com sabedoria poderá ser a fonte de inovação no processo de forneci-
mento de serviços de TI, no ambiente da organização. Seu gestor estará sempre em contato
com outras áreas da empresa, e sua ação será visível. O risco inerente à responsabilidade é
grande, mas os resultados podem elevar o profissional à outra categoria.

LEITURA
COMPUTERWORLD, Redação, Como os data centers devem se preparar para a Internet
das Coisas, COMPUTERWORLD/EUA, 03/04/2014, disponível em <http://computerworld.
com.br/negocios/2014/04/03/como-os-data-centers-devem-se-preparar-para-a-internet-
das-coisas/> acesso em 26/10/2014

LEWIS, B, Gestão: veja como definir indicadores e métricas mais assertivas, INFOWORLD/
EUA, 04/04/2014, disponível em <http://computerworld.com.br/gestao/2014/04/04/
gestao-veja-como-definir-indicadores-e-metricas-mais-assertivas/> acesso em: 26/10/2014

PRATT,M, Como avaliar o desempenho da equipe de TI: Com o aumento de

responsabilidades, é necessário encontrar melhores formas para medir contribuições da
área para os negócios, COMPUTERWORLD/EUA, 06/05/2014, disponível em <http://
computerworld.com.br/gestao/2014/05/06/como-avaliar-o-desempenho-da-equipe-de-ti/
> acesso em 26/10/2014

100 • capítulo 3
YOSHIDA,H., As 10 principais tendências em TI para 2014 - Big Data redefine a
capacidade de armazenamento virtual, CIO/EUA, 10/01/2014, disponível em <http://
cio.com.br/tecnologia/2014/01/10/as-10-principais-tendencias-em-ti-para-2014-big-
data-redefine-a-capacidade-de-armazenamento-virtual/> acesso em 26/10/2014.

REFERÊNCIAS BIBLIOGRÁFICAS
IT Governance Institute, COBIT 4.1: Modelo, Objetivo de controle, Diretrizes de gerenciamento.
USA, Rolling Meadows: IT Governance Institute, 2007. 212p

IT Governance Institute, COBIT 5: A Business Framework for the

Governance and Management of Enterprise IT. USA, Rolling Meadows: IT Governance Institute,
2012. 94p

OGC, ITIL Version 3: Information Technology Infrastructure Library - Service Design Volume.
London, England: ITIL Foundation – OGC, 2011. 449p

OGC, ITIL Version 3: Information Technology Infrastructure Library - Service Strategy Volume.
London, England: ITIL Foundation – OGC, 2011. 373p

NO PRÓXIMO CAPÍTULO
Neste capítulo aprendemos sobre a gerência do desempenho e a gerência de capacidade sob o
prisma do controle de desastres e crises, como gerenciar a capacidade em função dos custos e
demanda da organização. No próximo veremos com mais detalhes os custos de TI, e como in-
fluenciam as diretrizes dos negócios da organização.

capítulo 3 • 101
 4
Custos dos Serviços
de TI e Análise das
Vulnerabilidades
4  Custos dos Serviços de TI e Análise das
Vulnerabilidades

A gestão de TI está cada dia mais pressionada por obter melhores serviços com
custos reduzidos. Entretanto essa é uma via perigosa, que precisa se trilhada
cm cuidado. A redução pura e simples do valor dos serviços pode ser uma arma-
dilha mortal para as operações de negócio da organização.
A falha de um dos serviços críticos principalmente pode resultar em prejuízo de
alta monta, stress dos colaboradores, dos clientes, prejuízo a imagem da com-
panhia, enfim, a lista pode ser longa.
Análise de vulnerabilidades, parte deste conteúdo, foi visto na aula 1 e terá con-
tinuidade neste capítulo.
Aqui estaremos tratando mais diretamente dos casos onde a operação corre ris-
cos eminentes. Você com certeza já ouviu falar de casos de empresas ou órgãos
governamentais que sofreram ataques de hackers.

CONCEITO
Hackers – Indivíduos não identificados que utilizam ambiente eletrônico para praticar crimes

É um fato corriqueiro. Dados extraoficiais relatam que o sistema financeiro

é vítima destas ações diariamente, sofrendo milhões de reais de prejuízo.
Os hackers se aproveitam de “brechas” na segurança dos sistemas para reali-
zarem suas ações. Esse tipo de atividade vem se intensificando no mundo todo e
no Brasil a partir da década de 90. Mas ações ficaram mais críticas de 2011 para cá.

OBJETIVOS
•  Definir custos de TI e suas implicações;
•  Entender o conceito de custo e suas divisões;
•  Compreender o gerenciamento financeiro dos custos der TI;
•  Conceituar vulnerabilidade, ameaça e risco;
•  Entender porque temos problemas de segurança;
•  Ser capaz de analisar vulnerabilidades;
•  Entender a relação da vulnerabilidade com a disponibilidade.

104 • capítulo 4
 REFLEXÃO
Houve um tempo que os custos de TI eram responsabilidade da direção da empresa. Es-
tavam além do alcance das outras áreas de operação da organização. Hoje esta ideia esta
completamente mudada. Cada parte do negócio contribui com o resultado de suas opera-
ções para manter as tecnologias necessárias para operá-las.
Há pouco tempo atrás, em junho de 2011, o site da presidência da República do Brasil e
outros sites do governo foram invadidos e o governo virou manchete de jornais. Na verdade
ninguém, nem mesmo órgãos governamentais de segurança máxima como a Presidência da
República, estão livres de ações como esta. Então tome cuidado com suas andanças pela
internet, de repente o próximo pode ser você!

4.1  Gerenciamento de Custos em TI

4.1.1  Introdução

Para uma gestão de custos eficiente o gestor ou analista deverá ter em mente
alguns conceitos básicos de gestão administrativa e financeira. Deve separar
custos de investimentos, deve identificar corretamente os custos na faixa con-
tábil correspondente (fará uma grande diferença no momento que estes valo-
res forem resgatados pela contabilidade).
Outra atitude que pode facilitar o entendimento dos envolvidos na decisão dos
custos é mostrar seus benefícios. Fica mais fácil do stakeholders entenderem.

4.1.2  Conceito de Custos de Serviços de TI

Custos em TI são cíclicos. São os responsáveis pela manutenção da operação

nos seus moldes atuais e no seu planejamento para o futuro.
Outro aspecto importante dos custos de TI é a necessidade constante que as
organizações tem de investir na aquisição de novos componentes ou serviços
de TI para o suporte das operações de negócio.
Os investimentos em TI exigem grande capacidade das organizações em
face do alto valor que representam, sem a segurança de que produzam o resul-
tado das expetativas que sempre geram. A verdade é que muito pouco se pode
garantir em ternos de resultado, a não ser o uso responsável dos recursos e a
prática constante da gestão da demanda.

capítulo 4 • 105
 Como medir o retorno do investimento então? Como entender como fun-
ciona um mercado que, já no ano de 1998, segunda pesquisa realizada pelo
Gartner Group, movimentou mas da metade do investimento das empresas
(incluindo prédios instalações e maquinas). No Brasil este índice, extraoficial-
mente, beira os 40%.
Podemos entendê-lo melhor se dividirmos em dois grupos distintos:
Quanto a tangibilidade
•  Tangíveis, onde podemos ter redução de custos, melhoria de qualidade e
participação de mercado.
•  Intangíveis, onde a percepção e menor, talvez institucional (interpretativo)

Quantificação
•  Podem ser quantificados, seus resultados são facilmente mensuráveis
por métricas adequadas.
•  Não podem, mas contribuem para as decisões da organização.

Investimento
•  Investimentos com infraestrutura para viabilizar os serviços de suporte
•  Em aplicações do negócio, para atender aos requisitos de negócios da
organização.

Os custos de TI podem ser classificados em:

Despesas correntes
•  Despesas com aluguel de imóveis;
•  Manutenção de instalações prediais;
•  Deslocamento da equipe para atendimento externo;

Custos de Hardware
•  Suprimentos de TI.
•  Peças de reposição
•  Locação Equipamentos.
•  Manutenção e conservação de Equipamentos.
Software
•  Locação
•  Manutenção.

106 • capítulo 4
 Serviços
•  Suporte a usuários (serviços do service desk no atendimento ao usuário
final).
•  Serviços de suporte a infraestrutura (link de dados, rede corporativa, etc...).
•  Consultoria.

Infra estrutura
•  Serviços Técnicos (Exceto desenvolvimento e suporte a usuários).
•  Comunicação de Dados, links de dados e voz
•  Hospedagem de Sistemas em nuvem, para arquivos ou aplicativos nego-
ciados no modelo SaaS .

Custos de software são do tipo fixo e compreendem a aquisição de licen-

ças de uso definidas pela quantidade de usuários da organização que necessi-
tem do software para exercício de suas funções. Atualmente existem softwares
entregues como serviço, onde o custo da licença é transformado em tempo ou
carga de utilização. Existem softwares que suportam a operação como os sis-
temas operacionais de servidores e estações e os softwares para escritório, de
utilização rotineira (Editores de texto, planilhas eletrônicas, etc...) e softwares
específicos para determinada área como um CRM, utilizado pela área de ven-
das e faturamento.
Custos de pessoal são os decorrentes da manutenção da folha de pagamen-
to e os custos sociais dos operadores do Service Desk, os responsáveis pela ope-
ração dos serviços do catálogo da organização.
Custo de acomodação estão relacionados ao provimento de locais adequa-
dos para instalações dos serviços de TI. Estes locais precisam atender certos
requisitos como climatização, acesso externo a dados (links), mobiliário ade-
quado, segurança, etc

ATENÇÃO
Serviços externos tem se tornado uma opção viável para pequenas e médias empresas que
não tem capacidade de investimento para suportar aquisições de ativos patrimoniais de gran-
de monta, mas tem oportunidades de negócio que necessitam deste tipo de infraestrutura.

capítulo 4 • 107
 As transferências ocorrem por diversos motivos. Podem ser causadas por
ocorrência de desastres, por crescimento da demanda dos serviços ou por ra-
zões econômicas. São custos ocasionais. Em organizações de grande porte, aco-
modações podem ser projetadas para suportar desastres e terem espaço sufi-
ciente para longos períodos de crescimento sem necessidade de transferências.
Serviços externos são utilizados como alternativas viáveis de entrega para
necessidades de algumas operações ou até para a maioria das operações de
uma organização, quando se mostram confiáveis e com custos atraentes. A
contratação de servidores em nuvem para hospedagem de serviços como site
corporativo, loja eletrônica, portal, email corporativo e mesmo a contratação de
servidores completos, operados remotamente, são exemplo deste tipo de custo.

4.1.3  Gerenciamento Financeiro para Custos de Ti

O gerenciamento financeiro dos custos de TI esta diretamente ligado ao ser-

viço prestado. Apesar de óbvia, esta frase contém uma quebra de paradigma.
Até o advento do ITIL, os valores de custos da TI eram custos da organização.
Hoje eles são parte da operação da empresa, cobrados de cada uma das áreas
da organização de tal forma que cada operação tem incluída em seus custos, os
valores utilizados por sua área dos serviços de TI.
Por sua vez a TI tem que negociar periodicamente a elaboração de orça-
mentos e o monitoramento das despesas cotidianas.
A contabilidade faz o acompanhamento dos gastos e a cobrança recebe pe-
los serviços prestados.
Como atividades do Processo da Gerência Financeira temos a elaboração do
orçamento, com a previsão dos custos e controles inerentes e o método utiliza-
do. Incremental (toma como base o orçamento anterior) ou não e o período a
que se refere (normalmente anual).
A contabilidade de TI implica em monitorar os gastos da verba disponível
para as despesas, prevista no orçamento
As métricas de monitoramento devem privilegiar os interesses da organização,
por cliente ou por serviço, por atividade ou qualquer que se mostrar adequado.

4.1.3.1  Categorias de Custos

Custos diretos são aqueles devidos pelos serviços executados (contrato de loca-
ção de hardware), os indiretos são os causados pela ação do serviço, mas não
são utilizados na totalidade (serviços de mão de obra por hora técnica).

108 • capítulo 4
 Custos de capital são aqueles que podem ser medidos por depreciação
(aquisições de bens como impressoras e computadores)
Custos operacionais são os pertinentes ao cotidiano da organização, nor-
malmente são pagamentos repetitivos.
Custos Fixos são os que permanecem os mesmos sem mudanças em curto
prazo. É o caso das locações de edifícios.
Os variáveis são aqueles cujo valor tem diferentes apresentações no decor-
rer do temo, como as contas telefônicas por chamada por exemplo.
Devemos considerar os métodos de depreciação a utilizar para que façam
parte de nossa gerência de custos.
Depreciação Linear considera um montante, sempre de igual valor, diluído
a cada ano.
Depreciação por redução percentual considera um valor percentual do bem
diluído por ano
Depreciação por uso considera o tempo de uso do bem adquirido.

4.2  Análise e Vulnerabilidade em TI

4.2.1  Introdução

Este capítulo tem como objetivo conceituar vulnerabilidade, ameaça e risco. Esta
conceituação é necessária pois existe uma certa confusão com estes três conceitos.
Também é objetivo deste capítulo esclarecer o porquê de termos problemas
com segurança de informação, em todos os níveis. Como devemos nos compor-
tar em relação a este problema no ambiente corporativo e como o ITIL sugere
enfrentarmos o problema.
Analisaremos a vulnerabilidade dos serviços de TI no ambiente corporativo
em especial no seu alinhamento e intercorrências com a gerência da disponibi-
lidade dos serviços de TI.

4.2.2  Conceitos

4.2.2.1  Vulnerabilidade
Vulnerabilidade de TI pode ser definida como qualquer ponto frágil na segu-
rança ou na manutenção de um serviço de suporte que possa colocar em risco
os negócios da organização. Esse risco pode ser explorado por uma ameaça ou
pode ocorrer por conta de um incidente ou desastre.

capítulo 4 • 109
4.2.2.2  Ameaça
Uma ameaça é qualquer coisa que pode explorar uma vulnerabilidade. Uma
causa potencial de um incidente é uma ameaça. Um ladrão é uma ameaça se
conseguir explorar a vulnerabilidade da porta de seu veículo. Um vírus é uma
ameaça se conseguir superar as defesas de seu organismo. No conceito geral,
ameaça está oposta e em sentido contrário à vulnerabilidade.
No caso de TI, tem seu sentido utilizado nas disciplinas de segurança da infor-
mação e na manutenção da disponibilidade dos serviços de TI das organizações.
As ameaças estão ligadas à exposição da organização a um risco. A explora-
ção das vulnerabilidades sempre pressupõe um risco. Se considerarmos o caso
da porta do seu carro, o risco é seu DVDPlayer ser subtraído pelo indivíduo que
explorou a vulnerabilidade. Se for um vírus que entrou no seu organismo, o ris-
co é com a sua saúde.
Na organização pode significar a subtração de informações de seu cadastro
de clientes ou da invasão de sua rede para utilizá-la para finalidades alheias ao
seu negócio, como a disseminação de mensagens de spam por exemplo.

4.2.2.3  Risco
O risco é o que se tem a perder. O seu DVDPlayer, sua saúde comprometida, o ca-
dastro de clientes que vai ser usado pelo seu concorrente ou a sua rede a passos de
tartaruga, vítima dos milhões de spam que estão sendo enviados do seu endereço.
O risco, no ambiente organizacional, pode ser traduzido quase sempre como
prejuízo financeiro. E de fato as empresas perdem milhões com isso todos os anos.
Hoje em dia ninguém está a salvo. Seu telefone celular pode ter sido inva-
dido e você nem sabe disso. Suas mensagens podem estar sendo observadas,
sua banda de internet sendo usada para finalidades que você não contratou,
esgotando sua capacidade muito antes do que você espera.

CONEXÃO
Veja como está a vulnerabilidade do seu celular android, no texto divulgado pelo IDGNOW,
publicado em 26/08/2014 disponível em < http://idgnow.com.br/mobilidade/2014/08/26/
vulnerabilidade-inedita-afeta-6-de-cada-7-aplicativos-para-android-alerta-eset/ > acesso
em 27 out. 2014

110 • capítulo 4
4.2.3  Porque Temos Problemas de Segurança

A infraestrutura de TI da maioria das organizações de pequeno e médio porte

do Brasil e do mundo tem uma preocupação de nível moderado com políticas
de segurança. O que as torna vulneráveis a todo tipo de ameaças.
As redes que interligam o mundo são uma via de acesso fácil para os ha-
ckers. Estes indivíduos tem um grande conhecimento do funcionamento desta
tecnologia, explorando todas as vulnerabilidades, conhecidas ou não.
Utilizam ferramentas específicas para vasculhar a rede e conseguir um pon-
to de entrada qualquer.
O maior erro que as empresas deste tipo cometem é pensar que são tão pe-
quenas que estão livres do interesse dos hackers. O interesse é indicriminado,
todos correm o mesmo risco.

CONEXÃO
Veja os sete erros que as empresas cometem na gestão de risco de segurança em <http://cio.
com.br/gestao/2014/06/06/sete-erros-na-gestao-de-riscos-de-seguranca-que-as-empresas-
insistem-em-cometer/> Acesso em 27 out. 2014

Por este motivo, mesmo as empresas consideradas de pequeno porte devem

estabelecer protocolos de segurança no intuito de se protegerem, resguardan-
do seus ativos de informação.
As grandes corporações levam este assunto a sério. Investem parte de seu
orçamento de TI para a gerência de riscos e análise de vulnerabilidades. Con-
tratam serviços específicos de segurança com Firewalls, antivírus, servidores
proxy e outras ferramentas com reconhecido sucesso, fazendo testes periódi-
cos de varredura para se certificarem que tudo está sob controle.
O lado ruim da utilização deste tipo de ambiente (sempre existe o lado ruim)
é que quanto maior a ação destes mecanismos, mais lentidão de resposta os
usuários observam nas suas atividades triviais.
A análise de riscos e vulnerabilidades precisa verificar a relação custo-benefí-
cio de certas medidas em relação a sua capacidade instalada para não prejudicar
a disponibilidade de serviços em virtude do excesso de salvaguardas de seguran-
ça. A adoção de uma política hierarquizada, determinando faixa de uso por gru-
pos de usuários pode ser uma alternativa interessante para grandes ambientes
cooporativos. Outra solução estanque baseada em hardware é a utilização de su-

capítulo 4 • 111
blans (vlans ou subredes com endereços físicos determinados com políticas de
segurança específicas, coibindo os abusos de acesso indiscriminado).
Mesmo assim, ainda temos o fator humano. O grande Hacker norte ameri-
cano Kevin David Mitnick, preso por vários anos por fraudes cibernéticas, que
depois de solto se transformou em renomado consultor de segurança, tem uma
frase emblemática para a participação humana no risco à segurança:

“Há um ditado popular que diz que um computador seguro é aquele que está desligado. Isso
é inteligente, mas é falso: O hacker convencerá alguém a entrar no escritório e ligar aquele
computador. Tudo é uma questão de tempo, paciência, personalidade e persistência.”

Esta frase é o manifesto da engenharia social. O hacker que pretende inva-

dir uma organização não agirá somente através da internet para conseguir seu
intento, ele irá utilizar as pessoas da empresa para garantir seu acesso.
Neste cenário, cabe ao CIO ou analista estar atento às inovações disponibi-
lizadas no mercado e manter sua base instalada sempre atualizada para dimi-
nuir a possibilidade de amargar prejuízos em função de falhas de segurança.
Outro expediente simples mas eficiente é manter a base de sistemas operacio-
nais da organização permanentemente atualizada, diminuindo a existência de
falhas de segurança nativas dos SOs.

4.2.4  Análise de Vulnerabilidade

Para um negócio ameaçado o remédio é a adoção de ferramentas analíticas que

possam definir o planejamento estratégico na identificação das ameaças que
afetem ou até destruam o negócio da organização.
Esta ferramenta fornece um método que permite identificar ameaças, trans-
formando a análise de vulnerabilidade em processo de execução obrigatória e
periódica dentro das políticas de segurança da TI da organização
A palavra certa é “vigilância” e com ela iremos conseguir tratar os riscos da
vulnerabilidade com uma maior possibilidade de sucesso.

Visão do Analista de Risco

•  Identificar a vulnerabilidade.
•  Verificar se afeta o negócio
•  Corrigir o problema no menor tempo possível.

112 • capítulo 4
 O resultado é listado no relatório de Análise de Vulnerabilidade. Este re-
latório tem um formato que traz as principais caraterísticas da ameaça e sua
interação com os negócios da organização. Em cada vulnerabilidade identifi-
cada, apresentar:
•  Nome da vulnerabilidade
•  Componente ou recurso vulnerável
•  Detalhes da vulnerabilidade.
•  Identificar o nível (baixo, médio e alto) do risco associado à vulnerabilidade.
•  Ações sugeridas para corrigir a vulnerabilidade.

São de Alto Risco

•  Todas que possam comprometer a integridade dos dados, expor infor-
mações confidenciais ou utilizá-las para tornar indisponível os sistemas.

São de Médio Risco

•  As que podem abrir o sistema para pessoas não autorizadas, expor da-
dos confidenciais, arquivos particulares e informações pertinentes ao
negócio ou ainda causar algum tipo indisponibilidade em alguma apli-
cação específica.

São de Baixo Risco

•  Ameaças que não chegam a obter acesso mas mesmo assim procuram
explorar alguns ativos.

4.2.5  Vulnerabilidade X Disponibilidade

Vulnerabilidades tem relação direta com disponibilidade. Na grande maioria

das vezes uma vulnerabilidade explorada por uma ameaça vai tornar um servi-
ço de TI indisponível, total ou parcialmente.
Os prejuízos anuais que uma empresa pode acumular em função destas
ocorrências podem comprometer o resultado da organização.
Alguns exemplos, por serviço:
Serviço de arquivos: pode ter seu acesso negado por ação de vírus ou inter-
rupção voluntária de estrutura física (corte de cabos).
Rede interna: pode ter seu desempenho sensivelmente diminuído pela ação
de malwares ou algoritmos de inundação.

capítulo 4 • 113
 Serviço de internet: Pode ter seu desempenho comprometido pela ação de
vírus distribuidores de spam, colocando as estações como parte de uma botnet
(rede zumbi).

CONCEITO
Spam – mensagem indesejada recebida por email, normalmente uma oferta de produto
ou serviço.
Botnet – Rede zumbi formada por computadores escravos, infectados por vírus

Servidores de dados (SGBD): Podem dados alterados ou mesmo tabelas in-

teiras apagadas por ações de hackers e scripts de sql-injection.

ATIVIDADE
10.  Considerando a proposta da atividade anterior, onde equipamentos e serviços foram adquiri-
dos em substituição ao modelo anterior, propor um modelo de depreciação se for aplicável.

11.  Utilizando a configuração da última tarefa, com o sistema da Biblioteca operando localmen-
te, faça uma análise de vulnerabilidade (preencha o relatório utilizando o modelo de dados
da aula) do sistema de controle e dos arquivos dos usuários no servidor local.

REFLEXÃO
A gestão de custos e seus modelos é de vital importância para a entrega dos serviços de TI.
Com custos adequados, alinhados às necessidades de negócio e ao orçamento da organi-
zação, pode produzir um orçamento adequado e que garanta a capacidade de operação da
empresa sem maiores sustos.
A gerência das vulnerabilidades pode aumentar a disponibilidade dos serviços de TI da orga-
nização. Ninguém está inteiramente a salvo da ação de invasores, nem mesmo seu celular.
Sua postura séria e pontual em relação ao problema é a melhor opção.

114 • capítulo 4
 LEITURA
BEDNARZ,A, Sua empresa sabe o custo da TI?, NETWORK WORLD/EUA, 28/01/2011,
disponível em, <http://computerworld.com.br/gestao/2011/01/28/sua-empresa-sabe-o-
custo-da-ti/>, acesso em 27/10/2014

CONSTANTIN, L, Principais navegadores foram hackeados em concurso

Pwn2Own, IDGNOW NEWS SERVICE, 14/03/2014, disponível em <http://idgnow.
com.br/internet/2014/03/14/principais-navegadores-foram-hackeados-em-concurso-
pwn2own/>, acesso em 27/10/2014

IDG, Redação, Microsoft alerta: vulnerabilidade afeta TODAS as versões do IE, IDGNOW/
Brasil, 27/04/2014, disponível em <http://idgnow.com.br/internet/2014/04/27/microsoft-
alerta-nova-vulnerabilidade-afeta-todas-as-versoes-do-ie/>, acesso em 27/10/2014
SOARES,E., Boa gestão reduz custos com telecom, COMPUTERWORLD/BRASIL,
29/03/2010, disponível em <http://computerworld.com.br/telecom/2010/03/29/boa-
gestao-reduz-custos-com-telecom/>, acesso em 27/10/2014.

REFERÊNCIAS BIBLIOGRÁFICAS
HULME, G., Sete erros na gestão de riscos de segurança que as empresas insistem em
cometer, CIO/EUA, 06/06/2014, disponível em <http://cio.com.br/gestao/2014/06/06/
sete-erros-na-gestao-de-riscos-de-seguranca-que-as-empresas-insistem-em-cometer/>,
acesso em 27/10/2014

OGC, ITIL Version 3: Information Technology Infrastructure Library - Service Design Volume.
London, England: ITIL Foundation – OGC, 2011. 449p

OGC, ITIL Version 3: Information Technology Infrastructure Library - Service Strategy Volume.
London, England: ITIL Foundation – OGC, 2011. 373p

capítulo 4 • 115
 NO PRÓXIMO CAPÍTULO
Aprendemos como gerenciar custos, a tratar a vulnerabilidade da organização.
No próximo capítulo faremos o plano de gerenciamento de crise após um incidente na or-
ganização. É um momento sempre tenso, onde as pessoas da equipe da organização devem
estar preparadas para agir e recuperar a capacidade do negócio. Aprenderemos também
como tratar a melhoria contínua dos serviços de TI. Vamos lá!

116 • capítulo 4
 5
Gerenciamento de
Crise e Melhoria
Contínua
5  Gerenciamento de Crise e Melhoria
Contínua

A organização parou, o desastre ocorreu. Como reagir a esta situação? Como

defender os interesses do negócio, das pessoas envolvidas? Como estar prepa-
rado para restabelecer todos os processos essenciais no menor tempo possível?
Melhoria contínua é um conceito que nasceu no Japão, na fabricante de teares
TOYODA, que mais tarde se transformaria na poderosa fábrica de automóveis
TOYOTA. Lá ele ganhou o nome de Kaizen.
Esta prática possibilitou a indústria japonesa em primeiro lugar e depois a to-
das as empresas que tivessem intenção de exercê-la, níveis de qualidade e pro-
dutividade sem precedentes.
A partir de conceitos simples, de ações diretas no processo produtivo, estes ní-
veis foram alcançados, aumentando o poder de concorrência de seus pratican-
tes frente a concorrência.
É um fato corriqueiro. Dados extraoficiais relatam que o sistema financeiro é
vítima destas ações diariamente, sofrendo milhões de reais de prejuízo.
Os hackers se aproveitam de “brechas” na segurança dos sistemas para realiza-
rem suas ações. Esse tipo de atividade vem se intensificando no mundo todo e no
Brasil a partir da década de 90. Mas ações ficaram mais críticas de 2011 para cá.

OBJETIVOS
•  Entender o plano de continuidade de negócios;
•  Conceituar o gerenciamento de crise;
•  Entender como funciona o plano de recuperação de desastre e como elaborá-lo;
•  Entender o processo de melhoria continua;
•  Conceituar o Kaizen e PDCA;
•  Como os gerenciamentos de serviços do ITIL moti­va a qualidade;
•  Ver os 7 passos para melhoria contínua do ITIL V3;
•  Como fazer um plano de melhoria contínua, monitorando e controlando.

118 • capítulo 5
 REFLEXÃO
Você se lembra do dia 11 de setembro de 2003? Foi o dia do ataque as torres gêmeas do
World Trade Center, em Nova Yorque. A duas torres foram destruídas por aviões terroristas
e milhares de pessoas morreram. Sem dúvida que a maior perda do acidente foi a morte de
milhares de pessoas naquele dia. Mas outras perdas ocorreram, entre elas o colapso total de
todas as tecnologias de informação de Manhattan, que ficaram inoperantes por vários dias,
até que tudo pudesse retornar ao normal.
Já ouviu falar de just in time? Esta expressão define um dos aspectos do processo de me-
lhoria contínua criado pela TOYOTA. Este conceito define os estoques comandados pela
demanda do cliente. O produto sé é fabricado se houver pedidos. Então os estoques de ma-
téria prima e peças são colocados na linha de montagem praticamente na hora em que será
utilizados, dai a expressão ”just in time”.

5.1  Plano de Gerenciamento de Crise e Recuperação de Negócios

5.1.1  Introdução

Neste capítulo revisaremos o plano de continuidade de negócios com ênfase a

recuperação de desastres. Você vai conhecer as atitudes que devem ser toma-
das, os planos que devem ser preparados para que seja possível enfrentar os
incidentes da melhor maneira possível.
Conhecerá o conceito de mitigação dos riscos, como podemos trabalhar
para que se não pudermos evitar o incidente, que seus efeitos sejam menores
aos negócios da organização.
Também será orientado a estar pronto a responder emergencialmente, re-
cuperando os serviços críticos da TI, para que as operações básicas do negócio
sejam restabelecidas com o menor prejuízo para os negócios.

5.1.2  Plano de Continuidade de Negócios

Como pode ser visto na figura 1 a seguir, o plano de continuidade de negócios

tem como objetivo a manutenção do negócio, mesmo que não seja possível
contar com a TI.

capítulo 5 • 119
 É uma prática comum nas grandes organizações e já foi abordado no capí-
tulo um deste livro. Neste capítulo daremos especial enfoque para os processos
de mitigação de riscos, nas atitudes proativas que podem ser tomadas para que
a continuidade dos negócios possam ser garantidas.
A continuidade dos negócios da organização precisa ser preservada. Atual-
mente esta responsabilidade aumentou, pois a participação das tecnologias
nos processos de negócio atingiu níveis altíssimos, sendo que em alguns casos
ela é o próprio negócio (caso dos sites de compras on-line por exemplo).
Notem que o porção mais alta do gráfico exibido na figura 10 é totalmente volta-
da ao negócio, na análise que o risco pode impactar nas operações que suportam o
negócio. Este alinhamento se traduz na mitigação dos riscos que veremos a seguir.

Estágio 1 Iniciar GCN

Iniciação

Estágio 2
Necessidades e Análise de impacto no negócio
estratégia

Avaliação de risco

Estratégia de continência
dos serviços em TI

Estágio 3
Planejamento da
Implementação
organização e da
implementação

Implementar
providencias Desenvolver planos Implementar medidas
para recuperação de recuperação de redução de risco

Desenvolver precedimentos

Teste inicial

Revisão e Teste Gerenciamento

auditoria de mudanças
Educação e
consciência Treinamento

Garantia

Estágio 4
Gerenciamento operacional

Figura 10 - Processo de Gerenciamento de Continuidade

Adaptado ITIL V3 - (ITIL,2014).

120 • capítulo 5
 Mitigar significa suavizar, reduzir o impacto. Mitigar riscos significa dimi-
nuir o impacto de uma falha, reduzir a possibilidade de sua ocorrência, adotar
contramedidas para diminuir o prejuízo provocado.
Na atuação do analista, mitigar riscos significa estar atento a tudo que pode
ser feito em relação a cada episódio de desastre ocorrido ou por ocorrer na or-
ganização, que tenha impacto direto ou indireto nas operações que suportam
ou viabilizam o negócio. Ter medidas prontas ou em operação para que as con-
sequências de um desastre sejam as menores possíveis.
Muitas vezes o desastre acontece por uma causa inevitável, como incên-
dio, inundações, ou outro motivo de força maior, mas na maioria das vezes
(conforme demonstrado na tabela 5.1) as causas são conhecidas e os riscos
podem ser mitigados.
Lembrando do exemplo da equipe de fórmula 1, a adoção de cockpits mais
resistentes a impactos, que protegem a vida do piloto, diminuíram sensivel-
mente a ocorrência de mortes nas pistas de fórmula um. Infelizmente muitas
ocorreram até que o modelo atual de proteção fosse adotado.

EVENTO PERCENTUAL
Roubo 36%

Vírus 20%

Ataque de hachers 16%

Falha de Hadware e Comunicaçao 11%

Ambiente 7%

Falhas de Software 4%

Incêndio / Enchentes / Forças Maiores 3%

Outros 3%

Tabela 5.1 - Causas de eventos de desastre em TI

Fonte: Gartner Study 2001.

capítulo 5 • 121
 CONCEITO
LAN – Local area network, rede local de computadores interligados. Restrita fisicamente a
um ambiente comum. Pode ser entendida como aquela que pode ser alcançada dentro do
mesmo endereço físico.
Mitigar – Suavizar, reduzir.
Resiliente – O que insiste em permanecer. Na tecnologia indica os sistemas ou componentes
que conseguem se recuperar, superando falhas através de scripts inteligentes e sistemas
reduntantes.

Segundo o ITIL V3, no cotidiano do Service Desk, medidas de mitigação de

riscos podem incluir:
•  Sistemas de manutenção de energia do tipo UPS (nobreak) e a utilização
de mais de uma fonte de energia (geradores);
•  Sistemas de tolerância a falhas para aplicações críticas onde a indisponi-
bilidade é inaceitável (Ex: sistemas de bancos);
•  Sistemas de array do tipo RAID em espelhamento de disco para servido-
res LAN (Local Aerea Network) prevenindo perda de dados ou facilitando
sua recuperação;
•  Sistemas de reposição de componentes baseados em cópias do tipo Spa-
re (componentes com a mesma configuração na reserva, prontos para
uso) com processos de substituição dos originais que venha a falhar,
de forma rápida. Ex Um servidor de rede com a mesma configuração de
hardware do que está em uso, pronto para substituí-lo no menor tempo,
com o menor custo para a operação;
•  Eliminação dos SpoFs (Single point of Failures, do inglês Ponto único su-
jeito a falha), por exemplo uma única entrada de rede ou de fornecimen-
to de energia em um edifício da organização;
•  Sistemas de rede e TI resilientes (capazes de superar as falhas com a reto-
mada automática do serviço);
•  Serviços terceirizados para mais de um provedor (um tipo de redundân-
cia de contrato utilizada para serviços críticos) como por exemplo contar
com dois fornecedores de serviços de link de dados distintos (incluindo
a utilização de tecnologias diferentes) para manter o portal de vendas no
ar, sem interrupções;
•  Controles de segurança físicos baseados em TI robustos;

122 • capítulo 5
 •  Os melhores controles de interrupção de serviços, como os detectores de
incêndio, acoplados a a sistemas de supressão, evitando danos severos
aos equipamentos e dados;
•  Sistema de backup e recuperação de dados abrangente, incluindo siste-
mas de armazenagem off-site (armazenagem em nuvem).

Percebam que mitigação de riscos são procedimentos quase que exclusi-

vamente reativos. As medidas são tomadas após a ocorrência do incidente ou
contando com a sua ocorrência.
A análise dos processos de mitigação envolve na maioria das vezes o conjun-
to de ações que devam ser tomadas durante e após a ocorrência de um desastre.
Mas existe uma categoria em especial que permite o uso de medidas preven-
tivas com maior eficiência. É o caso dos riscos ligados a segurança dos dados e
transações utilizadas nas operações da organização, causadas por hackers ou
vírus. Sistemas atuais baseados em hardware (firewalls físicos) e em Softwares
(anti-vírus, servidores proxy e outras contramedidas de segurança) tem de-
monstrado eficiência cada vez maior e impedido muitas ações maliciosas de
hackers no ambiente das organizações.
Quanto aos eventos externos (roubo de infraestrutura de operadoras de servi-
ços de internet, eventos climáticos, é necessário estar preparado para ações rápi-
das. Treinamentos para recuperação de dados e serviços em situações de catástrofe
não podem ser deixados de lado. Quanto maior for o preparo da equipe do Service
Desk e seus contratados para lidar com a situação, melhor se sairá e menores serão
as consequências e impactos nas operações de negócio da organização.

5.1.3  Plano do Gerenciamento de Crise

Crise é o resultado mais visível do desastre. É o que aparece na imprensa, para

os acionistas, enfim, a relação pública e hierárquica do incidente.
Um plano de gerenciamento de crise deve indicar os interlo-
cutores responsáveis para relatar os fatos ocorridos às instâncias
superiores e à imprensa se for o caso.
Deve também estabelecer regras para as ações a serem tomadas em conti-
nuidade ao plano de resposta emergencial.
Imaginem nossa equipe de Fórmula 1 estar envolvida em um acidente du-
rante a prova onde existe a suspeita de erro na reposição de um dos pneus nos

capítulo 5 • 123
boxes… Como explicar o ocorrido para a imprensa (que viu tudo pela TV em
vários ângulos)? Como justificar a imagem negativa gerada pelo incidente aos
membros da diretoria e aos acionistas? Como convencer os patrocinadores a
manterem seus contratos? Como gerenciar a desconfiança e o stress emocional
da equipe depois do acidente?
O plano de gerenciamento de crise de uma organização deve estar prepara-
do para responder a situações como esta.
Em organizações de grande porte isso pode representar a diferença entre a
vida ou a morte de uma organização. Um banco jamais poderia sobreviver à um
incidente que envolvesse a segurança das informações de seus correntistas e
principalmente o dinheiro que está sob sua guarda. Se essa informação viesse
a público de forma incorreta provocaria uma corrida de saques. Da mesma for-
ma seus acionistas podem ser prejudicados pelo comportamento das ações da
organização no mercado após o anúncio do desastre.
Por causa da importância destas ações e sua repercussão, tanto interna
quanto externa à organização, que o papel de interlocução com as hierarquias
e com a imprensa é geralmente exercido por um membro sênior da direção da
empresa, com bom trânsito junto à todas as áreas envolvidas.

5.1.4  Plano de Recuperação

Bem, já vimos todos os aspectos envolvendo a ocorrência de um desastre. Como

entender os impactos de um incidente nas operações de negócio da organiza-
ção, como mitigar seus riscos, como responder em situação de emergência,
como gerenciar a crise gerada pelo incidente. E depois que o evento ocorreu,
como fazer para recuperar os serviços afetados pelo desastre? Numa linguagem
coloquial, como fazer para arrumar a casa?

CONEXÃO
Um exemplo de plano de recuperação de desastre publicado pelo MIT, o renomado Instituto
de Tecnologia de Massachusetts, para sistemas LINUX, disponível em <http://web.mit.edu/
rhel-doc/4/RH-DOCS/rhel-isa-pt_br-4/ch-disaster.html> visitado em 14/10/2014 (o texto
está em português)

124 • capítulo 5
 Um bom plano de recuperação deverá começar sua ação para recuperar os ser-
viços mais críticos e depois ir se preocupando com os serviços menos essenciais.
Mas na prática nem todos os mares são calmos, ou seja, nem sempre o ser-
viço mais crítico poderá se o primeiro, em função de várias razões. O executor
do plano deverá recuperar os imediatamente possíveis, mesmo que não sejam
os primeiros da lista. A recuperação de parte dos serviços em curto espaço de
tempo gera uma expectativa positiva no restante da equipe, colaborando para
levantar os ânimos de todos os envolvidos.
Devemos entender que aspectos psicológicos podem alterar o comporta-
mento da operação para melhor ou pior, então façamos a nossa parte para me-
lhorar o astral de todos depois do desastre.
Nas empresas que optam por serviços redundantes, este é o momento onde
podem obter vantagem. Uma conexão de dados que precisa ser restaurada após
um desastre, poderá ser recuperada com maior êxito se estiver ancorada em
mais de um provedor de serviços e mais ainda, se as tecnologias de suporte fo-
rem diferentes. Num exemplo prático, imagine os links de internet interrompi-
dos por uma inundação que carregou diversos postes no caminho do provedor
até a organização (dias serão necessários para o restabelecimento da linha).
Uma conexão alternativa no catálogo de serviços da organização, que opere via
rádio, permitirá a recuperação do serviço em tempo bem menor (pode aconte-
cer que não ocorra a queda do serviço, mesmo com a inundação).
O plano de recuperação deverá conter todas as alternativas para a recupe-
ração de um serviço ou componente, para que seja realizada com êxito total ou
parcial no menor tempo possível.
Também é pressuposto para sua execução a capacitação da equipe do Ser-
vice Desk e dos contratados para situação de desastre. Se todos os testes e si-
mulações tiverem sido cumpridos e avaliados, as chances de êxito na execução
aumentam muito. Comparando com a equipe de Fórmula 1, se o bico do carro
quebrar num incidente dentro da pista, será muito mais rápido substituí-lo se
a equipe estiver treinada, caso contrário quando conseguirem realizar a troca, o
carro já terá perdido duas voltas (o que corresponde a menos de 3 minutos nas
provas atuais) e poderá dar adeus a qualquer chance de pontuação.
Mais uma vez ressaltamos a importância do alinhamento dos planos de
continuidade dos serviços de Ti com o plano de continuidade do negócio.
As prioridades de recuperação estarão alinhadas com os interesses estraté
gicos da organização.

capítulo 5 • 125
5.1.5  Dicas Para Criação do Plano de Recuperação de Desastre

Uma boa dica para criação de um plano de continuidade é definida pelo COBIT
nas suas diretrize DS4 e DS6 (COBIT 4.1, 2007).
DS4: Assegurar a continuidade dos Serviços
Objetivo do processo é assegurar a continuidade do negócio e dos serviços
com um impacto mínimo nas atividades do negócio se houver interrupção dos
serviços de TI.
Controles
DS4.1 Estrutura de Continuidade
DS4.2 Planos de Continuidade da TI
DS4.3 Recursos Críticos de TI
DS4.4 Manutenção do Plano de Continuidade de TI
DS4.5 Teste do Plano de Continuidade de TI
DS4.6 Treinamento do Plano de Continuidade de TI
DS4.7 Distribuição do Plano de Continuidade de TI
DS4.8 Recuperação e retomada dos Serviços de TI
DS4.9 Armazenamento de cópias de segurança em locais remotos.
DS4.10 Revisão Pós-retomada dos serviços
Modelo de Maturidade
Classificamos o processo como:
Inexistente, quando não há conhecimento dos riscos, vulnerabilidade e ame-
aças as operações de TI ou do impacto da perda dos serviços de TI nos negócios.
Otimizado quando a gerência de continuidade de serviços faz ben-
chmarking pratica as melhores práticas. O plano de continuidade da TI está
perfeitamente alinhado ao plano de continuidade do negócio...
Classificamos o gerenciamento do processo como:
Inexistente, quando a organização não vê necessidade de implementar se-
gurança da informação. Não existe responsabilidades que garantam a seguran-
ça. Medidas de apoio a gestão de segurança não existem
Definido quando existe conscientização da segurança patrocinada pela di-
reção. Os procedimentos de segurança de TI são definidos e alinhados com a
política de segurança de TI. Atribuem-se responsabilidades com perfeito en-
tendimento por parte da equipe.

126 • capítulo 5
 DS6.1 Definição dos serviços
DS6.2 Contabilidade de TI
DS6.3 Modelagem de custo e cobrança
DS6.4 Manutenção do modelo de custo
Classificamos o gerenciamento do processo como:
Inexistente, quando a ausência é completa para qualquer processo para
identificação e alocação de custos dos serviços de informação fornecidos.
Processo definido quando existe um modelo de custo de serviços de infor-
mação definidos e documentado. Existe um processo definido para relacionar
os custos de TI aos serviços prestados aos usuários. Há um nível adequado de
ciência dos custos atribuíveis aos serviços de informação.
O Processo é avaliado e classificado em um dos 5 níveis

5.1.6  Elaboração do Plano de Recuperação de Desastre

O principal benefício obtido com a implementação de um plano de continuida-

de dos serviços de TI é a continuidade dos negócios de uma organização.
A gerência da continuidade aplica o plano para garantir a operação pelo
maior espaço de tempo possível, num cenário ideal, para que ela nunca pare.
Continuidade é de vital importância para negócios executados em ambiente
virtuais, pois para estes serviços não existe dia ou noite, final de semana ou feriado.
Operam no ciclo conhecido como 24 X 7 (vinte e quatro horas por dia, sete
dias da semana).
Como benefícios mais comuns, obtidos a partir da gerência da continuida-
de, temos:
•  O gerenciamento de riscos e consequente redução de impacto das fa-
lhas, este é óbvio;
•  Redução dos prêmios pagos aos contratos de seguro, pois as companhias
seguradoras reduzem o valor das apólices para empresas que tem planos
de continuidade definidos;
•  Atender aspectos obrigatórios ou regulamentares (acordos, leis);
•  Melhor relacionamento entre o negócio e a TI, tornando a TI mais foca-
da no negócio, ciente dos impactos e prioridades;
•  Aumento da confiança do cliente, possível vantagem competitiva e au-
mento da credibilidade da organização;

capítulo 5 • 127
 E se um desastre ocorrer:
•  Redução de interrupções no negócio, recuperando-os de forma eficiente
e na prioridade adequada às operações de negócio da organização;
•  Diminuição do tempo de recuperação;
•  TI mais estável e aumento da disponibilidade dos Serviços de TI.

Durante a operação normal podem ser verificados os resultados dos testes

feitos no plano e os custos do processo.
Durante ou após um desastre os pontos fracos do plano, os tempos de recu-
peração comparados ao tempo estimado e as perdas resultantes do desastre.
Este é outro ponto que sofre influência do tipo de organização. Cada uma
poderá estabelecer os KPIs que respondam melhor às suas necessidades de
continuidade.

5.2  Processo de Melhoria Contínua

5.2.1  Introdução

Este capítulo tem como objetivo mostrar como funciona o processo de melho-
ria contínua do ITIL V3 para os serviços de TI que dão suporte aos processos de
negócio da organização.
Os conceitos utilizados nesse aprendizado são herdados da filosofia conhe-
cida como Kaizen ou Toyotismo.
Originaram-se nos anos 80 e foram aperfeiçoados, sendo utilizados por
diversas bibliotecas de melhores práticas ao redor do mundo. Graças a estes
conceitos, hoje somos capazes de produzir mais, melhor e por um custo bem
menor. Isso serve para edifícios, carros, aparelhos eletrônicos, serviços finan-
ceiros, serviços de tecnologia... serve para qualquer processo de produção que
envolva procedimentos mensuráveis e repetitivos.

5.2.2  Conceito de Melhoria Contínua

O conceito de melhoria contínua foi definido na aula 5, mas faremos uma revi-
são aqui para reavivar a memória.
O conceito de melhoria contínua teve origem em um movimento que ocor-
reu no Japão, nas décadas de 50 a 70, que recebeu o nome de toyotismo. O nome

128 • capítulo 5
deve sua origem ao fato de ter ocorrido nas linhas de produção da Toyota, in-
dústria de automóveis japonesa.
Consiste em analisar o processo continuamente a procura de pontos de
possível melhoria. A melhoria pode ser em função do tempo necessário para
executar uma tarefa, a quantidade de pessoas, o número de peças ou passos de
serviço executado, partes do processo que podem ser excluídas, enfim, formas
de tornar o processo mais eficiente sem comprometimento da qualidade.
No caso dos serviços de tecnologia, envolve o levantamento dos dados refe-
rentes ao processo utilizados pelas ferramentas de trabalho.
O conceito está fundamentado nas diretrizes do ITIL, com base no moni-
toramento das métricas de desempenho (KPIs). Este monitoramento é o fun-
damento para estabelecimento de novas métricas, baseadas na ocorrência de
falhas, acertos, recuperação de serviços em tempo de execução, etc…
Correções de processos de negócio são fundamentais para a manutenção
do alto nível de competitividade exigido atualmente. São necessidades intrín-
secas ao trabalho do analista e devem ser realizadas de forma proativa.
A imagem a seguir demonstra como é o fluxo de tratamento dos questiona-
mentos utilizados no processo de melhoria continua do ITIL

Qual é a visão? Objetivo

Avaliação
Onde estamos agora?

Benefícios
Onde queremos chegar?

Implementação
Como chegaremos lá?

Como podemos checar se Métricas

chegarmos?

Como mantemos? Aperfeiçoamento

Figura 11 - Programa de melhoria contínua ITIL

Adaptado (GORGES,2009).

capítulo 5 • 129
 Um exemplo prático pode ser observado de maneira simples, dentro de um
sistema avançado de garantia de manutenção de fornecimento de energia (no-
breaks e geradores) de uma grande loja de departamentos. Nesta situação de-
vemos analisar todos os processos e suas métricas, incluindo os sistemas de
vendas, de segurança, de iluminação de emergência, etc…
Os KPIs do sistema de garantia de manutenção de energia mostram o limi-
te de utilização das baterias, o índice de falhas do fornecimento de energia da
operadora de energia elétrica quanto a quantidade de falhas e sua duração, a
quantidade de vezes que o sistema foi acionado, quanto tempo ele suporta até o
restabelecimento do fornecimento de energia externo e a vida útil das baterias.
Sua análise, realizada durante o monitoramento, percebe que a quantidade de
falhas é considerável (mais de 10 por mês), que a duração das falhas é relativamen-
te grande (mais de meia hora) e que o tempo de suporte do sistema atual (baseado
em nobreaks) é de cerca de 40 minutos, tendendo a diminuir com o uso das bate-
rias, com vida útil de 2 anos (hoje elas estão no meio do ciclo, com um ano de uso).
Várias abordagens para diminuir o risco de parada podem ser adotadas, mas
nesse caso é possível observar que parte das ocorrências são de responsabilidade
externa ao negócio, onde não é possível atuar. As restrições levam a três hipóteses:
•  Aumento da capacidade de autonomia dos sistemas de manutenção de
energia, o que envolve custos de aquisição e tende a ser superado paulati-
namente com o aumento da demanda interna (autonomia está diretamen-
te relacionada com a quantidade de dispositivos conectados ao sistema)
•  Adoção de um ou mais sistemas de grupo geradores para serem acio-
nados automaticamente, quando o tempo de falha for maior que 30
segundos. Esta solução envolve custos e a disponibilidade de espaço
físico considerável dentro ou próximo à unidade (grupos geradores são
grandes e barulhentos)
•  Aquisição de equipamentos para a área de venda, detentores de tecnolo-
gia com menor consumo de energia, que gerem menor impacto na auto-
nomia do sistema de manutenção de energia.

As decisões podem ser tomadas de forma única ou agrupadas.

Pode ainda existir outro critério que envolva inovação nos processos de ven-
da, para que utilizem dispositivos móveis, diminuindo a necessidade de equi-
pamentos desktop na área de vendas e por consequência reduzindo o consumo
global de energia.

130 • capítulo 5
 O que é importante perceber, dentro do modelo de melhoria contínua, é que o
monitoramento continua gerando novos KPIs e a situação deverá se modificar com o
passar do tempo, exigindo novas revisões, gerando novas análises que modificarão a
atuação do analista referente ao processo demonstrado.
Todo o ciclo descrito será repetido enquanto o processo existir, em todos os
processos existentes na organização.
Algumas vantagens nas relações da organização:
•  Negócio X consumidores - consumidores tem maior disponibilidade do
serviço, se sentem mais satisfeitos e portanto reclamam menos;
•  Financeiro - o custo total da operação tende a ser menor quando compa-
rado a uma operação com falhas e portanto com prejuízos diretos;
•  Inovação - A análise constante em busca de melhorias gera novos olha-
res e entendimentos do negócio sendo forte motivador de procedimen-
tos inovadores;
•  Benefícios internos - Aumenta a efetividade dos colaboradores, melhora
as métricas de desempenho dos processos de negócio, define regras e
responsabilidades de forma equilibrada e pontual, alinha custo e estru-
turas necessárias para o bom andamento do negócio.

As métricas desempenham um papel preponderante na melhoria continua,

medimos para:
•  Validar - monitoramos e medimos para validar decisões anteriores;
•  Direcionar - monitoramos e medimos para acertar a direção de ativida-
des para que atinjam seus objetivos. Esta a maior razão para monitorar-
mos e medirmos;
•  Justificar - monitoramos e medimos para justificar, face a uma evidência
ou prova, que uma ação é necessária;
•  Intervir - monitoramos e medimos para identificar um ponto de inter-
venção, incluindo mudanças subsequentes e ações corretivas.

O que nos leva à razão final de medir e monitorar, que é manter ou superar
as metas de alinhamento definidas nos requisitos de negócio.
Definido o que deve ser medido, levantamos o que pode ser medido e vamos
a busca dos dados definidos nas métricas, ajustando, inovando, criando meca-
nismos que proporcionem o alcance do objetivo.

capítulo 5 • 131
5.2.2.1 PDCA

Plan Do

Act Check

Figura 12 – Ciclo PDCA

Diagram by Karn G. Bulsuk (<http://www.bulsuk.com>) in Wikipedia under CC license.

Este ciclo de melhoria de qualidade foi definido anteriormente na aula 5,

mas vamos recordar seus pontos principais.
Uma matriz PDCA é um sistema de qualidade criado pelo físico Walter A.
Shewhart e popularizado pelo estatístico William Edwards Deming, considera-
do o pai dos processos de qualidade.

ATENÇÃO
Para a implementação do gerenciamento de níveis de serviço em TI, estas etapas servirão
para definição dos pontos de melhoria que deverão ser parte integrante de um SLA (Service
Level Agreement).

Consiste em quatro atividades básicas de um processo de melhoria traduzi-

das pelos atos de Planejar (Plan em inglês) onde se decide quais os caminhos e
objetivos de uma determinada atividade ou processo; Fazer (Do em inglês) onde

132 • capítulo 5
a atividade ou processo está definido e pronto, sendo colocado em execução;
Checar (Check em inglês) onde os resultados da atividade ou processo são me-
didos e comparados com as métricas definidas no planejamento; e Agir (Act em
inglês) para corrigir os eventuais desvios ou erros de execução.
Em resumo define os atores responsáveis por cada uma destas ações duran-
te a execução de uma atividade, buscando os mais elevados índices de qualida-
de e performance para a execução da tarefa ou processo.

5.2.2.2  KAIZEN
Kaizen significa mudança para melhor. É um princípio japonês que norteia o
lean manufacturing, sistema de melhoria contínua, criado na TOYOTA. Ele
nasceu no pós guerra e tem como lema principal o “hoje melhor do que on-
tem, amanhã melhor do que hoje”. Sempre é possível melhorar, mesmo que
já esteja bom. Uma visão mais detalhada do lean manufactoring pode ser lida
no item 3.1.8 deste livro.

5.2.3  Gerenciamento de Serviços de TI - Motivadores

O gerenciamento por nível de serviço permite uma visão mais rápida e eficaz dos
suportes tecnológicos das organizações. Como benefício mais esperado está a re-
dução de custos de aquisição e manutenção das tecnologias. Mas não é o único.
Uma visão de serviços é mais flexível, própria para mudanças rápidas, per-
mitindo que as organizações se adaptem às exigências do mercado de forma
mais tranquila e eficaz. As que têm um portfólio de serviços bem dimensiona-
do, tanto podem crescer, quando uma demanda assim o exige, quanto recuar,
quando o mercado se retrai.
Seus custos serão proporcionais a cada uma das situações e as demandas
resultantes do aumento ou da diminuição terão pouco ou nenhum reflexo na
estrutura da organização.
A visibilidade dos processos e a adoção de métricas de desempenho, aliadas a
um processo de melhoria contínua, vão impulsionar a empresa a um novo pata-
mar de qualidade de serviços e produtos, recheado de inovações.

capítulo 5 • 133
5.2.4  Como Identificar Resultados de Melhoria Contínua

Abaixo, uma lista dos benefícios que são esperados pela adoção do gerencia-
mento de nível de serviço:
•  O serviço em TI terá uma qualidade maior e irá causar menos interrupção.
Por consequência a produtividade dos clientes da TI será aperfeiçoada.
•  Os recursos da equipe de TI serão usados de forma mais eficiente.
•  A organização de TI fornecerá serviços que satisfaçam as expectativas
dos clientes.
•  O serviço fornecido poderá ser medido.
•  A percepção da organização de TI será melhorada.
•  Redução de custo.
•  Os serviços fornecidos por fornecedores são mais bem gerenciados com
contratos de apoio, reduzindo a possibilidade de influência negativa no
serviço de TI fornecido.

O monitoramento do serviço se torna possível identificando os pontos fra-

cos que podem ser melhorados.

CONEXÃO
Veja como alcançar a excelência operacional utilizando processos de melhoria contínua, se-
gundo a visão profissional da área (SANTOS, 2014). Disponível em <http://cio.com.br/ges-
tao/2014/09/12/como-alcancar-a-excelencia-operacional/>, acesso em 28/10/2014

5.2.5  Plano de Melhoria Continua e os 7 Passos

O roteiro de implementação do ITIL para melhoria segue uma linha de raciocí-

nio de ciclo contínuo. Veja a figura a seguir (figura 13), onde o ciclo de imple-
mentação é definido:

134 • capítulo 5
 Sabedoria Dados
1. Identificar a estratégia
de melhoria
- Visão
- Necessidades do negócio 2. Definir o que será medido
- Estratégia
- Gols táticos
- Gols operacionais
3. Recolher os dados
PLAN - Quem? Como? Quando?
- Critério para avaliar a
integridade dos dados
7. Implementar melhorias - Gols operacionais
- Gols táticos
- Medição do serviço

ACT DO

6. Apresentar e usar
as informações
- Resumo da avaliação
- Planos de ação
- Etc...
CHECK 4. Processar os dados
- Frequência?
5. Analisar a informação - Formato?
e dados - Ferramentas e sistemas?
- Tendências? - Gols táticos
- Objetivos? - Precisão
- Melhorias necessárias?
Conhecimento Informação

Figura 13 – Ciclo de Implementação de melhorias, (OGC, 2007).

Disponível em <http://itil.org/en/vomkennen/itil/serviceimprovement/csiprozesse/
siebenstufen.php visitado em 28/09/2014> – modificado pelo autor

Este gráfico representa os 7 passos para o processo de implantação de me-

lhorias do ITIL V3. Vamos analisar passo a passo:
12.  Identificar a estratégia de melhoria - Localizado no quadrado da sabedo-
ria, este passo estabelece como posições importantes a visão, necessida-
des ou requisitos do negócio, a estratégia, acertos táticos e operacionais.

Cada um destas posições está previamente definida, nas atividades anteriores.

13.  Definir o que será medido - Este passo está no quadrado dos dados. As
métricas que serão utilizadas serão as que medem a agregação de valor
para a entrega do serviço ou produto a que se refere a implantação.
14.  Recolher os dados - Também do quadrado dos dados, este passo define
quais os dados deverão ser recolhidos para responder aos questiona-
mentos Quem? Como? Quando? qual o critério para avaliar a integri-
dade dos dados recolhidos, os acertos operacionais e táticos a serem
observados e o mensuramento do serviço.

capítulo 5 • 135
 Até este momento, não existe relevância observada, somente critérios de coleta.
15.  Processar os dados - No quadrado da informação, tem como premissas
não obrigatórias, mensurar a frequência com que os dados observados
ocorrem, o formato que eles tem, ferramentas e sistemas utilizados
para a apuração, acertos táticos e a precisão que os dados contêm.

Em suma, transformando dados em informação.

16.  Analisar informação e dados - No quadrado do conhecimento, este pas-
so verifica as tendências e objetivos observados e se as melhorias são de
fato necessárias. Pode ocorrer que, após a verificação dos dados e mé-
tricas apurados, confrontando-os com as tendências e objetivos, che-
guemos a conclusão que a melhoria não trará resultado significativo.
17.  Apresentar e usar a informação - No quadrado do conhecimento, este
passo coloca em prática toda a informação levantada durante o ciclo de
implementação, começando com o resumo da avaliação, praticando os
planos de ação resultantes e traçando as diretrizes que irão nortear o
processo de implantação da melhoria.
18.  Implementar melhorias - O último passo deste roteiro é a implantação
em si. Se você deu os passos anteriores de forma correta, não vai errar.

Não é a toa que ele está no quadrado da sabedoria. Este é o ganho maior
para o analista.
Estes passos estão inseridos em uma matriz PDCA, um sistema de qualida-
de criado pelo físico Walter A. Shewhart e popularizado pelo estatístico William
Edwards Deming, considerado o pai dos processos de qualidade. Consiste em
quatro atividades básicas de um processo de melhoria traduzidas pelos atos de
Planejar (Plan em inglês) onde se decide quais os caminhos e objetivos de uma
determinada atividade ou processo; Fazer (Do em inglês) onde a atividade ou
processo está definido e pronto, sendo colocado em execução; Checar (Check
em inglês) onde os resultados da atividade ou processo são medidos e compa-
rados com as métricas definidas no planejamento; e Agir (Act em inglês) para
corrigir os eventuais desvios ou erros de execução. Em resumo define os atores
responsáveis por cada uma destas ações durante a execução de uma atividade,
buscando os mais elevados índices de qualidade e performance para a execu-
ção da tarefa ou processo.

136 • capítulo 5
 ATIVIDADE
1.  Com o exemplo da Biblioteca, estabeleça um plano de recuperação de desastre para o
caso dos dois links de internet pararem de funcionar por causa de uma tempestade. Con-
sidere para esta questão a configuração original dos serviços, com o aplicativo sendo exe-
cutado a partir de uma solução SaaS e com o diretório de arquivos hospedado em nuvens.

2.  Crie um plano de melhoria continua anterior ao momento de mudança da biblioteca para
os serviços de TI executados localmente. Verifique se as soluções pretendidas realmen-
te significam uma melhoria. Utilize os 7 passos.

REFLEXÃO
Desastres podem acontecer a qualquer momento. Podem ser de pequenas ou grandes propor-
ções. O que importa é estar preparado para responder com agilidade às necessidades da orga-
nização, tornando seus efeitos o menor possível. É um momento de colocar em prática toda a
preparação e destreza adquirida nos treinamentos periódicos do plano de recuperação.
Processos de melhoria contínua estabelecem sempre novas formas de olhar os processos. O
exercício é diário, suas repostas podem significar pequenos passos a primeira vista, mas quanto
você coloca em prática em soluções de grande produtividade, os resultados são surpreendentes.

LEITURA
CALVO, S., Como vai a contingência no Brasil?, COMPUTERWORLD/Brasil, 05/06/2012,
disponível em < http://computerworld.com.br/negocios/2012/06/01/como-vai-a-
contingencia-no-brasil/ > acesso em 27/10/2014

KARANACUS, C., Contratos de SaaS são vagos sobre níveis de serviço, diz Gartner
, COMPUTERWORLD, USA, Framingham, IDG News Service, 05/08/2013, disponível em
<http://computerworld.com.br/gestao/2013/08/05/contratos-de-saas-sao-vagos-sobre-
niveis-de-servico-diz-gartner/ > visitado em 17/10/2014.

capítulo 5 • 137
MESQUITA, M.; ALLIPRANDINI, D., Competências essenciais para melhoria contínua
da produção: ESTUDO DE CASO EM EMPRESAS DA INDÚSTRIA DE AUTOPEÇAS, São
Carlos, 04/2003, Revista Gestão e Pordução, V10, nº1, p17-33, Disponível em < http://
www.scielo.br/pdf/gp/v10n1/a03v10n1 > acesso em 27/10/2014

ZETLIN, M., Sua empresa está preparada para reagir a uma catástrofe?, San
Francisco, USA, CIO/INFOWORLD, 09/09/2011. Disponível em < http://cio.com.br/
gestao/2011/09/09/sua-empresa-esta-preparada-para-reagir-a-uma-catastrofe/ >.
Visitado em 18/10/2014.

REFERÊNCIAS BIBLIOGRÁFICAS
IT Governance Institute, COBIT 4.1: Modelo, Objetivo de controle, Diretrizes de gerenciamento.
USA, Rolling Meadows: IT Governance Institute, 2007. 212p

MIT, Planejamento para Desastres, USA,Massachusetts, sem data de publicação, disponível

em <http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-isa-pt_br-4/ch-disaster.html>
Visitado em 18/10/2014

NASH, K., Quando o desastre acontece, como deve agir a liderança de TI?, COMPUTERWORLD,
USA, Framingham,16/09/2011. Disponível em <http://computerworld.com.br/
gestao/2011/09/15/quando-o-desastre-acontece-como-deve-agir-a-lideranca-de-ti/>
Visitado em 18/10/1014

OGC, ITIL Version 3: Information Technology Infrastructure Library - Service Design Volume.
London, England: ITIL Foundation – OGC, 2011. 449p

SANTOS, M, Como alcançar a excelência operacional: A atitude e a mentalidade de todos os

colaboradores têm que estar alinhadas com as metas de melhoria continua da empresa., CIO/
COMPUTERWORLD, 12/09/2014, disponível em <http://cio.com.br/gestao/2014/09/12/
como-alcancar-a-excelencia-operacional/> acesso em 28/10/2014

138 • capítulo 5
 EXERCÍCIO RESOLVIDO
Capítulo 1

1.  Conhecendo todos os detalhes do negócio “Biblioteca”, estabeleça um plano de Conti-

nuidade que mantenha em operação os serviços de negócio mantidos pelos serviços
de TI em caso de falhas.
Resposta: 1 – Manter prontas fichas de papel para utilizar sistemas administrativos para ano-
tar o movimento de entrada e saída de livros e lançamentos financeiros. Este procedimento
deverá ser adotado na falha do sistema de controle da biblioteca por qualquer motivo;
2 – Manter os livros na estante, ordenados por um índice CDD, muito comum nas biblio-
tecas, que separa os livros por código numérico de assunto. Facilita sobremaneira a loca-
lização dos livros na prateleira enquanto o sistema estiver inoperante por qualquer motivo;
3 – Deixar pronto um contrato de emergência para uma solução de internet via satélite,
previamente testada e homologada, para restabelecer o sistema no caso os links princi-
pais deixem de operar;
4 – Ter em local visível os números de telefone de todos os prestadores de serviço asso-
ciados e os SLAs de cada contrato, para tornar mais fácil a ação no momento da falha;
5 – Testar quinzenalmente a meia vida das baterias do nobreak. Substituí-las quando
atingirem 40% da capacidade;
6 – Verificar mensalmente a evolução do espaço ocupado pelos arquivos no contrato
de storage, solicitar sua ampliação quando os arquivos atingirem 70% da capacidade
total contratada;
7 – Manter um computador com a mesma configuração dos utilizados na operação para
a substituição imediata no caso de ocorrência de falha;
8 – Verificar a evolução da base de dados do aplicativo de controle contratado, solicitan-
do o aumento da sua capacidade se ela atingir 70% do contratado;
9 – Manter a equipe de TI e operação treinada, realizando testes e simulações periódicas
para que todos saibam o que fazer no caso de falha.

2.  Com relação a capacidade, os serviços poderão sofrer pressão de demanda?

Resposta: Dificilmente no modelo escolhido, por ser todo ele baseado em entregas por
serviço, se ela ocorrer é imediatamente aliviada. O Único ponto onde pode ocorrer pres-
são é se a qualidade do link de dados estiver abaixo do nível acordado, gerando demora
no atendimento.

capítulo 5 • 139
3.  Está previsto crescimento para serviços, infraestrutura e componentes?
Resposta: Sim, modelos baseados em nuvem tem grande escalabilidade. O crescimento
pode ser efetuado sob demanda, em tempo de execução. A infraestrutura local poderá
crescer em até 6 vezes o seu tamanho original, considerando que o único limitador seria
um switche de distribuição interno, alugado, que normalmente tem 24 portas (apenas 4
portas ocupadas na configuração inicial).

4.  Defina os serviços do negócio e os serviços de tecnologia que suportarão os requisitos do

negócio, faça seu catálogo de serviços para atender as necessidades do negócio Biblioteca.
Resposta:
- Catalogo dos serviços do negócio
a) Cadastro de livros do acervo
b) Cadastro de usuários da biblioteca
c) Controle de movimentos de entrada e saída do acervo
d) Controle financeiro
- Catálogo de serviços de tecnologia
a) Link de internet operadora 1
b) Link de internet operadora 2
c) Switche load balanced para rede WAN-LAN
d) Computadores para operação
e) Infraestrutura de rede interna
f) Contrato de manutenção para infraestrutura interna
g) Aplicativo de controle do tipo SaaS (Sofware as a Service)
h) Nobreak com capacidade suficiente para manter os computadores e a infraestrutura
funcionando
i) Contrato de storage em nuvem, para os arquivos compartilhados utilizados pelos
operadores.

5.  Defina os SLAs dos contratos de serviços de tecnologia do catálogo.

Resposta: Os SLAs serão utilizados para manutenção dos níveis de serviço, para garantir
a entrega dos serviços de tecnologia com qualidade, dentro dos requisitos do negócio.
a) O contrato das operadoras de link de internet deve ter uma SLA que contemple um
máximo de tempo sem operação. Neste caso, podemos imaginar que um período
máximo de 5 horas por mês, com no máximo 50% em uma única ocorrência, estaria
dentro do aceitável;

140 • capítulo 5
 b) O contrato de aluguel do Switche load balanced deve prever um equipamento de
reposição imediata, com a presença de um técnico no local em no máximo 2 horas,
tendo este equipamento de reposição as mesmas especificações técnicas e configu-
rações do principal, no local, para ser colocado no lugar do que apresentar defeito,
sendo o defeituoso obrigatoriamente recolocado na instalação em 72 horas;
c) O contrato de aluguel dos computadores deve prever um computador com a mesma
configuração e especificações técnicas dos outros três, para ser colocado em opera-
ção no caso de falha de um dos computadores em uso.
d) O contrato de manutenção deve prever um técnico em atendimento no local em no
máximo 24 horas após um chamado. Também deve disponibilizar um atendimento
de primeiro nível para dúvidas, realizado por telefone. Deve contemplar treinamento
aos operadores para procederem a troca de um computador com falha pelo reserva.
Deve conter testes a cada 60 dias para medir a meia vida das baterias do no break,
indicando a troca quando elas atingirem 40% do tempo de carga total.
e) O contrato do aplicativo deve prever um índice de disponibilidade (assunto do próximo
capítulo) de 95%, com interrupções não maiores que 2% por ocorrência. Deve sina-
lizar ao cliente quando a utilização do repositório de dados contratado atingir 70%
do total. Os valores para os ajustes de crescimento devem estar acertados antes do
início da operação. Deve conter cláusula de confidencialidade.
f) O contrato de Storage deve contemplar 95% de disponibilidade, responsabilidade
pela segurança dos dados (backup periódico diário e recuperação de dados de arqui-
vos se necessário) e confidencialidade.

Capítulo 2

1.  Utilizando o caso da biblioteca definido no capítulo 1 criar um plano de custos dos ser-
viços de TI. Utilize hardware, software, pessoal, acomodações, transferência e serviços
externos como os índices do plano.
Resposta: O software escolhido é do tipo SaaS, que é uma prestação de serviço externa,
todos os componentes de infraestrutura e as estações de trabalho serão alugadas.Com
esta escolha o plano ficaria com todos os custos concentrados no índice “Serviços externos”
Listando:
Hardware – Não há custos de hardware, todos os componentes desta natureza são
alugados;
Software – Não há custos de aquisição pois foi decidida a utilização de SaaS – Software
as a Service;

capítulo 5 • 141
 Pessoal – Não existe pessoal da organização alocado para equipe de TI, os serviços são
todos no modelo outsourcing;
Acomodações – Não há custos para acomodação, pois a infraestrutura de hospedagem
e storage é em nuvem;
Transferência – Não é perceptível neste modelo, se o fornecedor do serviço transferir
sua infraestrutura, provavelmente isso ocorrerá sem que a organização fique sabendo;
Serviços Externos – Aplicativo de controle (SaaS), Infraestrutura de rede e estações de
trabalho (alugadas), Pessoal técnico para suporte e manutenção terceirizada, Links de
dados e serviços de storage para arquivos compartilhados e banco de dados.

2.  Faça o cálculo da disponibilidade esperada para os SLAs definidos nas atividades do
capítulo anterior, item 3 (SLA) solicitados a seguir:
a) Qual a disponibilidade para o SLA do link de internet com tempo sem operação por um
período máximo de 5 horas por mês, com no máximo 50% em uma única ocorrência?
Resposta: 30 dias, com 24 horas cada um, teremos o tempo total de utilização em
horas = 720 horas

Disponibilidade =
(720 − 5 )
. 100 99.31%
720

b) Para o SLA do switche load balanced, com 2 horas de indisponibilidade máxima?

Resposta:

Disponibilidade =
(720 − 2 )
. 100 99.72%
720

c) A disponibilidade de atendimento técnico local do SLA do contrato de manutenção

será de?
Resposta:

(720 − 24 )
Disponibilidade = . 100 96.67%
720

Capítulo 3

142 • capítulo 5
1.  Com o exemplo da Biblioteca, determine quais são os índices de desempenho que po-
derão ser medidos para a obtenção de serviços de TI com qualidade necessária para a
manutenção das operações.
Resposta: As respostas podem diferir, pois existem várias possibilidades de indicadores
para este caso.
Índice de custo unitário de processamento
Índice de disponibilidade do serviço de internet 1
Índice de disponibilidade do serviço de internet 2
Índice de ocupação do Storage/espaço contratado
Índice de utilização do SGBD aplicativo/espaço contratado
Índice de disponibilidade do serviço de software contratado
Índice de disponibilidade do switche load balanced
Índice de disponibilidade das estações de trabalho
Índice de tempo de atendimento/SLA contratado da equipe de manutenção.

2.  Utilizando o exemplo da biblioteca, faça um plano de gestão de demanda para definir um
novo orçamento de serviços de TI. Considere a possibilidade de substituir o aplicativo
SaaS por um de operação local.
Resposta:
A utilização de um serviço local teria como consequência direta a aquisição ou locação
de um servidor de arquivos e aplicativos. Podemos considerar a compra de um único
equipamento, face o tamanho da operação a ser suportada. Após as verificações de
utilização de arquivos e SGBD remotos, chegou-se a conclusão que os serviços estavam
superdimensionados, onerando a operação.
A aquisição de um aplicativo local poderá ser amortizada em 1 ano e o servidor em 36 meses.
Será necessária a contratação de um especialista para converter a base de dados, sem
que haja perda de informação.
O serviço de arquivos será baixado para o servidor local.
Deverá ser verificado se o nível de suporte das unidade UPS garantem a manutenção de
energia para o novo equipamento.
Os serviços de internet serão diminuídos, apenas um link de capacidade reduzida pode
ser suficiente. O Switche load balanced poderá ser substituído por um mais barato, sem
prejuízo a nova operação.

capítulo 5 • 143
Capítulo 4

1.  Considerando a proposta da atividade anterior, onde equipamentos e serviços foram adquiri-
dos em substituição ao modelo anterior, propor um modelo de depreciação se for aplicável.
Resposta: Para o modelo criado pelo autor, seria indicada para o servidor adquirido a
utilização de uma depreciação do tipo percentual, com 20% do valor do bem deduzido
por ano. Estaria de acordo com a política de obsolescência habitualmente utilizada pra
bens desta natureza.

2.  Utilizando a configuração da última tarefa, com o sistema da Biblioteca operando local-
mente, faça uma análise de vulnerabilidade (preencha o relatório utilizando o modelo
de dados da aula) do sistema de controle e dos arquivos dos usuários no servidor local.
Resposta: Existem diversas abordagens possíveis
Nome da vulnerabilidade – Acesso a arquivos
-Componente ou recurso vulnerável – link de internet
-Detalhes da vulnerabilidade – endreço de IP fixo, facilita localização
-Identificar o nível (baixo, médio e alto) do risco associado à vulnerabilidade. Médio
Ações sugeridas para corrigir a vulnerabilidade – instalação de políticas de firewall no
roteador, firewall nas máquinas locais e servidor devem ser ativados.
-Nome da vulnerabilidade – Acesso a informações do aplicativo
-Componente ou recurso vulnerável – Aplicativo com SGBD
-Detalhes da vulnerabilidade. Hacker pode retirar dados do SGBD por acesso não au-
torizado.
-Identificar o nível (baixo, médio e alto) do risco associado à vulnerabilidade. alto
Ações sugeridas para corrigir a vulnerabilidade. instalação de políticas de firewall no
roteador, firewall nas máquinas locais e servidor devem ser ativados e programas anti-
virus para evitar malwares
-Nome da vulnerabilidade – Acesso não autorizado a conteúdo
-Componente ou recurso vulnerável – Estações de trabalho
-Detalhes da vulnerabilidade – Acesso conseguido através de malwares e spywares, na
estação de trabalho do operador.
-Identificar o nível (baixo, médio e alto) do risco associado à vulnerabilidade. médio
-Ações sugeridas para corrigir a vulnerabilidade. Antivirus eficientes e atualizados, edu-
cação de segurança para orientação dos usuários.

144 • capítulo 5
Capítulo 5

1.  Com o exemplo da Biblioteca, estabeleça um plano de recuperação de desastre para o

caso dos dois links de internet pararem de funcionar por causa de uma tempestade. Con-
sidere para esta questão a configuração original dos serviços, com o aplicativo sendo exe-
cutado a partir de uma solução SaaS e com o diretório de arquivos hospedado em nuvens.
Resposta: a diferença para um plano de continuidade é que o plano de recuperação de
desastre procura viabilizar o restabelecimento dos serviços essenciais em primeiro lugar,
depois do incidente.
Nesse caso a primeira ação do plano é colocar procedimentos administrativos em fun-
cionamento imediatamente, para manter a operação em curso.
Segundo passo seria acionar o contrato de emergência para o link de internet via saté-
lite, que deve entrar em funcionamento o quanto antes.
Assim que a conexão for restabelecida, lançar todos os procedimentos administrativos
para alimentar o sistema com as informações.
Quando um dos links de internet retornar à operação por um tempo considerado seguro,
suspender o contrato emergencial do link via satélite.

2.  Crie um plano de melhoria continua anterior ao momento de mudança da biblioteca para
os serviços de TI executados localmente. Verifique se as soluções pretendidas realmente
significam uma melhoria. Utilize os 7 passos.
Resposta: 1 - Estratégia de melhoria – Mudar os sistemas de serviços de aplicativos e
hospedagem de arquivos para uso local. Os requisitos de negócio apontam, para uma
necessidade de redução de custos a longo prazo, pois o pagamento dos serviços em
nuvem está comprometendo a lucratividade do negócio.
2 – O que será medido? A diferença de desempenho e o custo benefício da mudança
3 – Recolher os dados – Os dados foram levantados, a disponibilidade foi medida, Os custos
foram levantados e todos os parâmetros que interferem no negócio foram considerados
4 – processar os dados – o dados foram processados e disponibilizados em formato de
gráficos e relatórios.
5 - Analisar informação e dados - os dados foram analisados e comparados com as
tendências de mercado e preços levantados junto a fornecedores
6 – Apresentar e usar a informação – Com os dados analisados, apresentar as propos-
tas para a gerência da biblioteca, justificando a ação de melhoria.
7 – Implementar melhorias – se tudo correu bem até aqui, é só colocar seu plano em prática

capítulo 5 • 145