UNIVERSIDADE SÃO FRANCISCO CURSO DE...
45
UNIVERSIDADE SÃO FRANCISCO CURSO DE ENGENHARIA DA COMPUTAÇÃO Paulo Gustavo Turco Cunha RA 002200800426 “ESTUDO DA APLICAÇÃO DE ROOT CAUSE ANALYSIS (RCA) PARA INCIDENTES CRÍTICOS EM AMBIENTES DE TI” Itatiba 2012
Transcript of UNIVERSIDADE SÃO FRANCISCO CURSO DE...
UNIVERSIDADE SÃO FRANCISCO
CURSO DE ENGENHARIA DA COMPUTAÇÃO
Paulo Gustavo Turco Cunha RA 002200800426
“ESTUDO DA APLICAÇÃO DE ROOT CAUSE ANALYSIS (RCA) PARA INCIDENTES
CRÍTICOS EM AMBIENTES DE TI”
Itatiba
2012
UNIVERSIDADE SÃO FRANCISCO
CURSO DE ENGENHARIA DA COMPUTAÇÃO
Paulo Gustavo Turco Cunha RA 002200800426
“ESTUDO DA APLICAÇÃO DE ROOT CAUSE ANALYSIS (RCA) PARA INCIDENTES
CRÍTICOS EM AMBIENTES DE TI”
Monografia apresentada ao curso de Engenharia de Computação
da Universidade São Francisco, como requisito parcial para a
obtenção do título de Bacharel em Engenharia de Computação.
Orientador: Prof. Esp. Ricardo César Boaretto
Itatiba
2012
DEDICATÓRIA
Será um tanto extenso.
À Deus, por acreditar na sua existência e principalmente por acreditar que todos os
acontecimentos enquanto aqui encarnado, mesmo os piores, fazem parte de seu plano para
minha evolução.
À meus pais Renato e Teresa, cuja saúde física não mais os acompanha desde
antes do meu nascimento. Mesmo com todas as suas doenças, acompanhadas de
dificuldades financeiras e a falta de perspectiva em relação a si mesmos , não hesitaram em
momento algum a me ensinar (quase) tudo o que eu precisava saber e não pouparam
esforços para me fazer chegar até este momento.
Ao meu irmão Daniel, presente em todos os momentos da minha vida e, mesmo
sendo o caçula, não se privando de me atrapalhar sempre que possível. Sem o seu carisma
e companherismo, parte de minha vida estaria incompleta.
À minha esposa Eliane, presente na minha vida há sete anos e companheira
presente nos até agora muitos bons momentos e poucos maus, por estar cuidando de mim
como o “homem” da casa, principalmente no ano em que este trabalho foi desenvolvido.
E finalmente, ao meu filho Yago, que há três anos atrás veio iluminar meus dias com
sua presença, e que há um ano atrás descobrimos ser portador de autismo. E que desde
então, me faz ver a vida de outra forma, celebrando todas as suas pequenas evoluções
como grandes vitórias que são. E que provavelmente não sabe o quanto seu progenitor
sofreu tendo que se preocupar com este trabalho, os estudos, o seu emprego e a falta de
mais oportunidades para “ser seu pai”.
AGRADECIMENTOS
À todos os meus amigos da IBM e da USF, sem citar nenhum em especial, para não
causar discórdia. Em algum momento, estiveram presentes também neste trabalho e
estarão presentes na minha vida para sempre.
À todos os meus outros familiares e amigos, por me proporcionarem alegrias
espontâneas e por me fazerem saber o quanto sou querido, mesmo àqueles a quem pouco
vejo.
Aos professores da Univesidade São Francisco, por contribuirem ativamente na
minha formação como estudante universitário e profissional, em especial o Professor
Ricardo Boaretto, como meu orientador neste trabalho, e os Professores Renato Franco de
Camargo e Rodrigo Brossi, a quem considero como mestres e amigos.
“O sucesso é ir de fracasso em fracasso sem nunca perder o entusiasmo”
Winston Churchill
RESUMO
A gestão dos serviços de Tecnologia da Informação (TI), é hoje considerada uma prática
essencial (e em muitos casos, de importância vital) realizada pelas grandes e médias
corporações, em especial àquelas que oferecem TI como um serviço destinado ao
gerenciamento do ambiente computacional de seus clientes. A capacidade que uma
corporação possui de oferecer esses serviços - baseados em sólidos frameworks de TI -
permite a ela oferecer produtos diferenciados, dentro de um portfolio de serviços que
costuma ser amplamente variado. Uma das boas práticas normalmente adotadas no
fornecimento de soluções em TI baseia-se na utilização do framework ITIL, que consiste em
um modelo de negócios a ser seguido com base em implementações e cases de sucesso
anteriores (a biblioteca ITIL foi originalmente construída através de múltiplos feedbacks de
corporações e analistas acerca dos comportamentos considerados ideais para a boa gestão
da tecnologia da informação). A ITIL, em sua versão mais recente (version 3 – publicada em
maio de 2007), lista cinco livros que dividem o gerenciamento de TI em partes, também
conhecidas por ciclos de vida ou fases: Estratégia de Serviço, Desenho de Serviço,
Transição de Serviço, Operação de Serviço e Melhoria de Serviço Continuada. Dentro da
fase de Transição de serviços, encontra-se, entre outros processos e funções, o
Gerenciamento de Incidentes e o Gerenciamento de Problemas, que foram desenhados
para tratar dos eventos não desejados que acontecem no dia - a - dia de um ambiente
informatizado de serviços. O sub-processo de Root Cause Analysis (RCA), dentro do
processo de Gerenciamento de Problemas, deverá ser aplicado apenas em determinadas
situações, e tem como característica principal retornar aos interessados do processo
informações precisas referentes a determinado incidente ocorrido no ambiente de serviços
de um cliente. A boa capacidade de uma empresa em fornecer métodos e soluções efetivas
para determinado mau comportamento em um determinado sistema ou componente reside
em uma gestão inteligente e eficiente dos processos de Gerenciamento de Incidentes e
Problemas.
PALAVRAS-CHAVE: Gestão de TI, Tecnologia da Informação, ITIL, Gerenciamento de
Problemas, Gerenciamento de Incidentes, RCA.
ABSTRACT
The Information Technology management services are considered today an essential role
(and in some cases, of vital importance) offered by large and medium companies, especially
those which can offer IT as a service intended to manage their client’s computer
environment. The capacity of some company has to offer these services – based on
consolidated IT frameworks – allows the corporation to offer distinguish products within a
service portfolio - which is, usually, broadly diversified. One of the best practices usually
adopted for the IT solutions deployment is based on the using of the ITIL™ framework, which
consists in a business model to be followed based on previous success cases and
implementations (the ITIL library was originally built through multiple feedbacks from
companies and analysts, aiming to what would be ideally considered a good behavior for a
successful IT management). ITIL, in its latest version released (version 3 – published in May,
2007), consists on five books which divide the IT management in parts, also know by life
cycles or phases: Service Strategy, Service Design, Service Transition, Service Operation
and Service Continual Improvement. Within the Service Transition phase, we can found,
between some other processes and roles, the Incident Management and Problem
Management, which were designed to deal with the undesired events which happen every
day in a automated service environment. The Root Cause Analysis (RCA) sub process,
within the Problem Management process, shall be applied only in specific situations, and has
as its main feature the return to the process’s stakeholders of the accurate information
referred to an incident occurred on a service environment. A good ability of a corporation by
offering effective solutions for an unusual bad behavior from a system or component lies on
an intelligent and efficient management from Incident and Problem Management processes.
KEY WORDS: ITIL, IT Management, Information Technology, Problem Management,
Incident Management, RCA.
LISTA DE ILUSTRAÇÔES
FIGURA 1 - Distribuição dos modelos de Governança de TI no Brasil 17
FIGURA 2 - ITIL V3: Publicações x Processos 19
FIGURA 3 - Representação do gerenciamento de incidentes pela lógica de sistemas 23
FIGURA 4 - Representação do Gerenciamento de Incidentes por fluxograma 24
FIGURA 5 - Categorização de Incidentes 25
FIGURA 6 - Representação do Gerenciamento de Problemas por fluxograma 30
FIGURA 7 - Modelo Genérico do Diagrama de Ishikawa 33
FIGURA 8 - Gráfico de Pareto: Causas de falhas de rede em uma determinada empresa 36
LISTA DE TABELAS
TABELA 1: Organizações prejudicadas por falhas em serviços de TI 21
TABELA 2: Prioridades versus Tempo de Resolução Incidentes - ITIL 28
TABELA 3: Análise de Pareto: Causas de falhas de rede em uma determinada empresa 34
LISTA DE ABREVIATURAS E SIGLAS
CCTA Central Computer and Telecommunications Agency
IT Information Technology
ITIL IT Infrastructure Library
KEDB Known Error Data Base
OGC Office of Government Commerce
RCA Root Cause Analysis
SLA Service Level Agreement
SLM Service Level Management
TI Tecnologia da Informação
SUMÁRIO
INTRODUÇÃO ….................................................................................................................. 12
1. OBJETIVOS ….................................................................................................................. 13
2. METODOLOGIA …........................................................................................................... 14
3. GESTÃO DE SERVIÇOS DA TECNOLOGIA DA INFORMAÇÃO (TI) …......................... 15
3.1 O Brasil, o Mercado de TI e a Demanda por Serviços........................................ 15
3.2 Estrutura do Framework ITIL ….......................................................................... 18
4 OPERAÇÃO DE SERVIÇOS E OS DESAFIOS DO PROVEDOR DE TI ......................... 20
4.1 Gerenciamento de Incidentes ............................................................................. 22
4.2 Incidentes Críticos …........................................................................................... 27
4.3 Os Valores do Processo de Gerenciamento de Incidentes ................................ 28
4.4 Gerenciamento de Problemas …........................................................................ 29
4.4.1 O Subprocesso de Root Cause Analysis …......................................... 32
4.4.2 Análise Cronológica …......................................................................... 32
4.4.3 Análise por Valor da Dor ….................................................................. 32
4.4.4 Análise de Krepner/Tregoe ….............................................................. 32
4.5.5 Brainstorm …........................................................................................ 33
4.4.6 Diagrama de Ishikawa …...................................................................... 33
4.4.7 Análise de Pareto ................................................................................ 34
4.4.8 Five Whys ............................................................................................ 36
4.5 Planos de Ação .................................................................................................. 38
4.6 Os Valores do Processo de Gerenciamento de Problemas …............................ 39
5 CONCLUSÃO …................................................................................................................ 39
12
INTRODUÇÃO
As empresas de Tecnologia da Informação (TI) que hoje entregam serviços para
seus clientes buscam seu diferencial através de muitas maneiras, sendo que a capacitação
de pessoas e a melhoria contínua de seus processos estão hoje em dia como pilares de um
bom “delivery”, designação aplicável aos departamentos que entregam serviços para um ou
mais clientes.
Dessa mesma forma, qualquer empresa que esteja alinhada com as exigências de
mercado atualmente busca sempre manter-se atualizada e em conformidade com os
frameworks (boas práticas) que surgiram com o passar dos anos e que são recomendadas
em um ambiente de Tecnologia da Informação, como por exemplo a ITIL, ISO-20000, entre
outras.
Foi a partir do surgimento da ITIL, na década de 90, que muitas das empresas
passaram a comportar-se de maneira diferente, criando departamentos específicos que
pudessem manter o padrão de excelência sugerido por esse framework. Nesse conceito,
existe no nível de transição de serviços (um dos ciclos propostos pela ITIL) os processos de
Gerenciamento de Incidentes e Gerenciamento de Problemas, que podem ou não ser
contratados pelos clientes em seu pacote de delivery de serviços.
De maneira resumida, Gerenciamento de Incidentes e Gerenciamento de Problemas
preocupam-se em lidar, entender e estudar formas para evitar os acontecimentos
inesperados (incidentes) no dia-a-dia operacional do ambiente de serviços de um cliente.
Neste trabalho, será focada a análise do processo de Gerenciamento de Problemas,
considerado de sumária importância para uma organização, uma vez que afere o real
problema que ocorreu em um determinado ambiente de serviços de uma determinada
empresa. Para tanto, é invocado o subprocesso chamado RCA (Root Cause Analysis –
Análise de Causa Raiz). A análise de causa raiz em um determinado serviço de TI deverá
apontar falhas, planos de ação e soluções para evitar novas incidências de um mesmo
problema.
Este trabalho irá apresentar a maneira como os processos se comportam de maneira a
garantir com que o objetivo do Gerenciamento de Problemas seja atingido.
13
1.OBJETIVOS
Será analisada a maneira como o processo de RCA aborda incidentes ocorridos em
ambientes operacionais, causando a interrupção de um serviço de TI provido por uma
empresa a seu cliente. Esses incidentes são normalmente reportados pelas partes afetadas
(através de um service desk ou não), e a partir desse momento será exemplificado como as
abordagens dos processos deverão ser feitas para que ao final sejam propostas, de forma
definitiva, a correção e melhoria contínua para evitar reincidências. Para isso, serão
apresentados os processos de gerenciamento de incidentes e gerenciamento de problemas,
a estrutura de um incidente e de um problema e as metodologias adotadas para solução de
problemas.
Não está no escopo deste trabalho a elaboração de um documento em um caso real,
mas sim as projeções deste documento, bem como as atribuições de cada usuário envolvido
no processo e a abordagem inferida por ele.
14
2.METODOLOGIA
Um documento de RCA pode ser aberto por diversas razões, porém este trabalho irá
focar na análise de causa raiz de incidentes considerados críticos para uma organização, ou
seja, um incidente que causou impacto no ambiente, provocando um outage (serviços fora
do ar). O seu objetivo é identificar o que ocorreu, qual o motivo por ter ocorrido e quais
ações a serem tomadas para evitar a reincidência do problema.
Em um primeiro momento, será feita uma breve explanação sobre o conceito de
gerenciamento de serviços de TI, bem como a aplicação do ITIL como ferramenta de
melhores práticas em um ambiente. Em seguida, já abordando a parte teórica sugerida por
este framework, será feita uma avaliação sobre quais são os tipos de incidentes que são
considerados de alta severidade para um ambiente de TI e que obrigatoriamente invocam o
processo de Gerenciamento de Problemas, visando sua solução definitiva. Após essa
primeira etapa, será explicado como é desenvolvido um documento de RCA baseando-se
nesses incidentes, desde a análise inicial, passando pela investigação dos acontecimentos,
e a chegada a uma conclusão factível, que irá determinar a causa raiz do problema.
Será realizada uma análise baseada nas referências bibliográficas apresentadas, bem
como outras a serem pesquisadas no andamento do trabalho.
.
15
3.GESTÃO DE SERVIÇOS DE TECNOLOGIA DA INFORMAÇÃO (TI)
Para o completo entendimento do significado deste trabalho e dos processos e
termos que são apresentados por ele (ainda que alguns deles possam ter nomes auto-
explicativos, que possibilitam prever o que devem realizar em um determinado contexto), é
inevitável primeiro que sejam verificadas as suas origens. Se hoje existem processos e
funções definidas para se estabelecer o gerenciamento do comportamento de um
determinado ambiente de TI, é porque a constante evolução do modelo de negócios trouxe
a tecnologia de informação para um novo patamar, onde grande parte dos processos de
negócio dependem dos serviços de TI para operarem de maneira adequada. Logo, para
suportar essa demanda e outras novas que se desenvolvem ao decorrer dos anos, tornou-
se necessário a criação de funcionalidades que pudessem permitir a gestão eficiente das
mesmas.
O conceito de tecnologia da informação é definido por BEAL (2002, p.8):
Solução ou conjunto de soluções sistematizadas baseadas no uso de
métodos, recursos de informática, de comunicação e de multimídia que
visam a resolver problemas relativos à geração, tratamento,
processamento, armazenamento, veiculação e reprodução de dados, e a
subsidiar processos que convertem dados em informação.
Um serviço de tecnologia da informação pode ser considerado um conjunto de
fatores (que comumente irão englobar software, hardware, pessoas e processos) que são
oferecidos por um provedor de TI a um ou mais clientes.
Estendendo o conceito apresentado à outros departamentos além da alta
administração, cujos fatalmente irão suportar os processos vendidos, a administração de
serviços de TI visa entender e agregar valor, de maneira planejada, ao negócio das
empresas, de modo com que passe a ser usada para criar soluções baseadas
principalmente em análises de dados e nos relacionamentos presentes nas organizações
empresariais.
3.1 O Brasil, o Mercado de TI e a Demanda por Serviços
A história da gestão de serviços de TI no Brasil se confunde com a própria história da
tecnologia da informação. Durante a década de 80, as empresas começaram a adotar, de
maneira tímida, a entrega de serviços, juntamente com o início da disponibilização dos
computadores pessoais. De acordo com DANTAS (1988, p. 162), no início da década de 80,
ainda durante a ditadura, um projeto fora lançado com o intuito de tornar o mercado
tecnológico restrito apenas às empresas nacionais. Ainda conforme DANTAS (1988, p.
172), o projeto tomou forma, foi implementado e ficou conhecido como a “Lei de Reserva de
16
Mercado” para a área da informática (também conhecido por “Política Nacional de
Informática”). Durante o tempo em que a lei perdurou (de 1984 à 1992), o mercado
Brasileiro esteve restrito à mão de obra puramente nacional, por conta da proibição da
importação de produtos e bens nesse setor. NAMOUR (2009) afirma que se por um lado a
restrição imposta pela lei acarretava na criação de produtos alternativos ou cópias literais
(muitas vezes de pior qualidade e mais caras) de outros importados, além de diversas
outras considerações nos campos tecnológico e político, por outro permitiu com que fosse
desenvolvida a expertise nacional em lidar com a gestão de tecnologia, por meio da “criação
de mão de obra especializada e altamente qualificada”.
A década de 90 trouxe ao Brasil o fim da Lei de Reserva de Mercado e o início dos
computadores pessoais (PC’s). As empresas começavam a utilizar o processamento
computacional, já acompanhando o crescimento intenso da informatização de processos. No
entanto, como referencia BALDIN (2012), foi somente na década seguinte que o contexto
‘Gestão de Serviços de Tecnologia da Informação’ foi fortemente absorvido e então adotado
pelas empresas como um diferencial competitivo. Nesse cenário, nascem os conceitos de
melhores práticas e frameworks (modelos de boas práticas na gestão de TI) , capitalizados
por diversos documentos produzidos com o intuito de se determinar como um serviço de TI
deve ser gerenciado, do início ao fim de seu ciclo de vida. A ITIL (Information Technology
Infrastructure Library - Em tradução livre, “Biblioteca de Infraestrutura para Tecnologia da
Informação”) surge dentro desses frameworks como um dos modelos mais aceitados e
disseminados entre as principais organizações mundiais.
A ITIL foi desenvolvida no início da década de 90, quando, de acordo com MACÊDO
(2012), o governo britânico, em sua necessidade de coletar informações que pudessem
padronizar os serviços de tecnologia da informação, recebeu informações de sua Agência
de Telecomunicações e Computação Central (CCTA - Central Computer and
Telecommunications Agency) contendo uma coletânea de informações de diversas
empresas. As orientações mais úteis foram compiladas e passaram a ser utilizadas pelas
empresas ligadas ao governo. Outras empresas, com o passar do tempo, perceberam que
essas orientações também poderiam ser utilizadas para normalizar as suas atividades
ligadas à TI. Todo esse processo levou à criação dos livros que se tornariam parte de uma
única biblioteca.
A primeira versão da ITIL, como informa MACÊDO (2012), contava com quarenta
livros. No entanto, a disseminação da biblioteca no Brasil se deu a partir do lançamento da
versão 2 (chamada popularmente de ITIL V2), no início dos anos 2000. A ITIL V2 contou
com uma redução considerável no volume de livros, reduzidos a dez volumes:
- Introduction to ITIL
17
- Service Support - Limited Stock Available
- Service Delivery - Limited Stock Available
- Planning to Implement Service Management
- Security Management
- Business Perspective
- ICT Infrastructure Management
- Application Management
- Software Asset Management
- ITIL V2 Small-Scale Implementation
Embora a versão 3 tenha sido lançada em 2007 e reduzida a cinco livros, ainda é a
versão 2 a predominar na maioria das empresas em solo nacional. Será visto adiante sobre
a estrutura da ITIL a partir da versão 3, a última a ser lançada.
Atualmente, diversas empresas nacionais e também multinacionais prestadoras de
serviços utilizam a ITIL, oferecendo aos seus clientes serviços que seguem fielmente o
modelo sugerido pelo Cabinet Office, um departamento do Governo Britânico e hoje detentor
deste framework. O ITIL é hoje um dos frameworks mais utilizados pelas empresas que
entregam serviços de TI no Brasil, conforme exemplificado na FIGURA 1, em uma extração
publicada em 2007.
Fonte: MACÊDO, 2012 apud ITSMF, 2007 FIGURA 1 - Distribuição dos modelos de Governança de TI no Brasil
18
3.2 Estrutura do Framework ITIL
Não é difícil definir o contexto de um serviço em tecnologia da informação. A entrega
de um serviço (que pode ser desde um software até a manutenção de um parque de
servidores, por exemplo) para uma empresa qualquer através de um provedor de TI envolve
etapas que passam pelo planejamento, execução e posterior manutenção, sendo que em
todas essas etapas pessoas atuam de acordo com processos e rotinas pré-estabelecidos
pelo provedor visando garantir a estabilidade do recurso sendo oferecido ao cliente. Todo
serviço de TI possui suas particularidades, que devem ser estudadas para que sejam
evitados problemas durante a sua projeção, implantação e manutenção. Nesse contexto
surge o chamado ciclo de vida do serviço. O ciclo de vida do serviço é um termo muito
comum no ambiente de tecnologia da informação. Ele se refere ao serviço em relação às
suas fases de existência, desde a sua requisição até sua obsolescência.
Como já visto anteriormente, a ITIL é um compêndio dedicado ao gerenciamento de
serviços dividido por etapas, fundamentado no ciclo de vida do serviço e na manutenção de
infraestrutura de tecnologia da informação. Sua última versão (ITIL V3), lançada em 2007, é
composta de cinco livros diferentes (reduzindo ainda mais o volume em relação às suas
versões antecessoras):
- Estratégia de Serviço;
- Design de Serviço;
- Transição de Serviço;
- Operação de Serviço;
- Melhoria Contínua de Serviço.
O entendimento do mercado em relação a adoção ao framework foi rápido. Hoje, um
profissional qualificado para o entendimento de ITIL é reconhecido e valorizado pelas
empresas de TI. Foi assim que, com o tempo, empresas acreditadas pela ITIL passaram a
emitir certificações para os profissionais de tecnologia da informação. Essa certificação hoje
é definida em três partes: ITIL Foundation, Practicioner e Service Manager. A ITIL
foundation é emitida após os candidatos participarem de uma avaliação com diversas
perguntas sobre cada etapa presente nos livros emitidos pela extinta OGC (Office of
Government Commerce, que foi integrada ao atual Cabinet Office Britânico). Já as
certificações Practicioner e Service Manager são emitidas após obtenção de especialização
através de cursos e exames. No mundo todo estima-se um total de 600.000 pessoas já
obtiveram algum nível da certificação ITIL, conforme dados de 2011 (ITIL Free, 2011).
Conforme já mencionado, a biblioteca ITIL divide-se em cinco publicações, que
detalham a percepção de analistas, gerentes e outras pessoas inerentes aos processos e
19
funções de TI exercidas ao longo do tempo pelas corporações. A FIGURA 2 mostra os ciclos
de vida expressos pela ITIL, bem como os processos inerentes à cada um deles (de acordo
com a coloração exibida para cada ciclo):
FONTE: http://www.teclogica.com.br/blog/?p=508 FIGURA 2: ITIL V3: Publicações x Processos
No nível de Estratégia de Serviço, são realizadas as definições de como o serviço irá
operar, ou seja, são fornecidos os detalhes de como traçar, desenvolver e implementar o
gerenciamento dos serviços (OGC, 2007). Como referencia LUNA (2010 apud OGC, 2007),
“[...] nesta fase, são providas orientações sobre os princípios que sustentam o
gerenciamento de serviços que são úteis no desenvolvimento de políticas de gerenciamento
de serviços,recomendações e processos em todo o ciclo de vida de serviço da ITIL.”
Já na etapa de Projeto de Serviço (Design de Serviço), são oferecidas as
ferramentas necessárias para que se possa verificar o que foi acertado na etapa de
estratégia e converter em ativos de serviço. Dessa forma consegue-se alinhar o serviço
oferecido com a necessidade de negócio. Nessa fase, é prioritário com que o serviço seja
20
desenvolvido de forma ser compatível com as políticas, processos e práticas desenvolvidas
a fim de que seja facilitada a execução do serviço, no momento em que este for entregue.
A Transição de Serviço é a fase responsável por coordenar a adição ou modificação
de serviços para um ambiente. De acordo com LUNA (2010 apud OGC, 2007), é a fase
onde são apuradas as definições da Estratégia de Serviço já codificadas no Design de
Serviço e que serão posteriormente implementadas na próxima etapa - Operação de
Serviço.
A Operação de Serviço inicia a parte prática, ou seja, os serviços entram
verdadeiramente em produção. Essa fase deverá:
“[...] prover diretrizes para adquirir eficácia e eficiência na
entrega e suporte dos serviços, assegurando a entrega de
valor ao cliente e ao provedor de serviço. Além de proporcionar
orientações para manter a estabilidade dos serviços em
operação, permitindo realização de mudanças no projeto,
escopo e níveis de serviços acordos” (LUNA, 2010 apud OGC,
2007).
A Melhoria Contínua de Serviço engloba todas as fases anteriores. Ela é
considerada de sumária importância para permitir a manutenção de valores agregados.
Através da Melhoria Contínua de Serviço, as empresas podem realizar melhorias em seus
serviços, agregando qualidade aos mesmos. Permite também com que os serviços possam
ser reajustados conforme necessidade do negócio, o que garante qualidade na execução e
agregar valor ao cliente final (OGC, 2007).
Esta publicação não irá tratar dos pormenores de cada um dos processos expostos
na FIGURA 2. Para efeito de consideração, a Gestão de Incidentes e a Gestão de
Problemas, temas abordado nesse trabalho acadêmico, encontram-se detalhadas na etapa
de Operação de Serviços no framework ITIL.
4. A OPERAÇÃO DE SERVIÇOS E OS DESAFIOS DO PROVEDOR DE TI
Antes de serem visualizados definitivamente os conceitos de gerenciamento de
incidentes e problemas, é importante referir à etapa do ciclo de serviço à qual os mesmos se
aplicam. A ITIL, de acordo com sua organização, coloca o gerenciamento de incidentes e
problemas na fase de Operação de Serviços, ou seja, no momento onde o serviço está
sendo executado e sob a supervisão do provedor de TI (muitas vezes referenciado como
“pós-venda”). Será verificado posteriormente que um registro de incidente poderá ter uma
21
gama de impactos ao ambiente operacional de uma empresa, passando por casos extremos
- desde um usuário solicitando revalidação de senha para uma aplicação, até um outage
(interrupção) de serviços que causam penalidades milionárias aos provedores. Essas
situações são inerentes ao comportamento de um ambiente de TI e os provedores deverão
estar sempre atentos à possíveis descompassos como esses. SANTOS (2010) atenta para
a mudança de cenários e valores das corporações, ressaltando que os provedores devem
estar preparados para essas mudanças e que a gestão consciente dos contratos,
manutenção de serviços e valores deverá estar sempre em prioridade.
Um dos pontos de maior relevância sobre o serviço disponibilizado pelo provedor diz
respeito à sua importância para o negócio do cliente e o quão mensurável ele é. Para tanto,
a ITIL propõe o processo de Gerenciamento de Nível de Serviço (SLM - acrônimo do inglês
Service Level Management). A partir do SLM, surgirá o SLA (Service Level Agreement -
Acordo de Nível de Serviço), que irá definir as métricas referentes à disponibilidade do
serviço, bem como o seu valor para o negócio (MAGALHÃES E PINHEIRO, 2007, p.76).
Dados advindos de pesquisas, ainda de acordo com MAGALHÃES e PINHEIRO
(2007, p.28), mostram que no ano de 2002 80% da indisponibilidade dos serviços advinham
da operação das atividades pertinentes à operação de serviços. Apesar de se tratar de um
período relativamente distante (cerca de dez anos), é interessante notar que esse é um dos
principais, senão o principal fator de problemas nos ambientes controlados por um provedor.
A TABELA 1 mostra, a título ilustrativo, alguns dos problemas que ocorreram em grandes
empresas por conta de problemas com a operação de serviços.
FONTE: MAGALHÃES E PINHEIRO, 2007. TABELA 1: Organizações prejudicadas por falhas em serviços de TI
22
A importância do provedor nesses tipos de situações não se limita apenas a
administrar as falhas no momento em que elas ocorrem, buscando as soluções de maneira
emergencial para evitar o passar das horas e a multa que irá se somar a elas. É preciso que
as soluções sejam visualizadas, mas que sejam igualmente visualizados planos de ação e
propostas para evitar (se possível anular) as chances de recorrência deste problema.
4.1 Gerenciamento de Incidentes
Para que se possa ser falado sobre gerenciamento de incidentes, é necessário antes
abordar o tema “Incidente”. Afinal, o que define um incidente em um ambiente de
tecnologia da informação?
De acordo com VIANA (2010), Incidente é todo evento que interrompe um serviço ou
diminui seu nível de qualidade, contendo uma solução conhecida. Este tipo de evento não
será abordado diretamente neste trabalho, uma vez que serão considerados os eventos
com soluções não conhecidas, que deverão por sua vez requerer uma análise de causa
raiz para determinar a solução final. Isso será visto adiante no capítulo “Gerenciamento de
Problemas”.
O gerenciamento de incidentes sugere a administração de um incidente do início ao
fim, por meio de algumas ações protocolares, visando a solução rápida do problema e com
o menor impacto possível para o(s) usuário(s) final(is).
Tomando agora como base as atividades do processo, apontadas por VIANA (2010):
- Detecção do Incidente;
- Registro do Incidente;
- Classificação do Incidente;
- Priorização do Incidente;
- Escalonamento;
- Restauração;
- Fechamento.
A FIGURA 3 mostra um diagrama utilizado para melhor compreender as atividades
acima mencionadas. Por ser em formato de lógica de sistemas, podem ser vistos os
elementos referentes a cada etapa equivalente à Engenharia de Software, onde são
analisadas Entradas, Saídas, Papéis e Recursos e Indicadores. Cada uma das atividades é
enquadrada em uma dessas etapas, fornecendo uma leitura mais abrangente e abstrata em
relação ao processo. Como gatilhos, além do próprio incidente, aparecem também as
requisições de serviço e também requisições de mudança, estando as especificações das
mesmas sob os processos de Request Fulfillment (Cumprimento de Requisição) e Change
Management (Gerenciamento de Mudanças), também abordados na ITIL v3. Os recursos e
23
papéis cabem ao sistema ou software envolvido no incidente, bem como as informações já
armazenadas na Base de Dados de Erros Conhecidos (a ser vista detalhadamente adiante).
Os processos abordados no gerenciamento de incidentes também possuem seus
indicadores e metas para futuras avaliações de desempenho, sendo que os dados são
compartilhados entre outros processos também presentes na etapa de Service Operations,
proposta pela ITIL. Ao final do ciclo temos as saídas, que podem ser os dados obtidos pela
resolução do incidente ou, caso necessário, uma nova requisição de mudança para solução
do problema encontrado.
FONTE: http://www.ciclocapd.com.br/paginas/capd/c/c1/index.html FIGURA 3: Representação do gerenciamento de incidentes pela lógica de sistemas.
Já a FIGURA 4 mostra uma representação em fluxograma específica dos subprocessos
dentro do gerenciamento de incidentes:
24
Fonte: http://www.pedrofcarvalho.com.br/PDF/ITIL_OPERACAO_SERVICOS.pdf FIGURA 4: Representação do Gerenciamento de Incidentes por fluxograma
Como uma entrada, tem-se o registro do incidente. De acordo com a OGC (2007),
ela poderá ser realizada por um usuário através de um service desk ou não, dependendo da
forma como o serviço foi acordado e de suas peculiaridades. O incidente deverá ser
registrado em uma ferramenta própria para o gerenciamento de incidentes. Também
existem os incidentes abertos eletronicamente por máquinas autônomas, que emitem alertas
quando constatado um desvio anormal em relação ao monitoramento de uma atividade (um
exemplo comumente utilizado é o de alerta de baixo espaço em disco). Com o advento da
última versão da ITIL, foi incluído o processo de Gerenciamento de Eventos. O
Gerenciamento de Eventos irá se preocupar exatamente com estas situações de baixa
representatividade e baixo risco, que podem ser controlados por meio de um software
proativamente, antes de se tornarem verdadeiramente um incidente.
Para efeito de interpretação, nesta monografia, será considerado um incidente aberto
com a utilização do service desk.
25
Após a abertura do registro, algumas ações devem ser realizadas de imediato. A
categorização do incidente e seu impacto em relação aos negócios é a primeira e talvez
principal ação que será realizada. Categorizar, de acordo com a ITIL (OGC, 2007), significa
atribuir a um incidente um código que permita com que, futuramente, os registros possam
ser avaliados em relação ao ambiente que ficou indisponível, estabelecendo tendências que
possam ser usadas para avaliação. A FIGURA 5 mostra exemplos de categorização para
um ou mais incidentes.
Fonte: OGC (2007, p.93) FIGURA 5: Categorização de Incidentes
Neste caso, temos dois exemplos: Duas categorizações principais, de dois incidentes
distintos (Hardware/Software), que foram expandidas por ramificações até que se pudessem
fornecer vários códigos e um nível de abstração relativamente menor em relação a apenas
um nível de categorização. Esse modelo, conforme a ITIL (OGC, 2007), é usualmente
26
utilizado na maioria das ferramentas de incidente, e comumente variam entre três a quatro
níveis para expansão.
O impacto do incidente é normalmente decidido no momento da abertura de acordo
com a avaliação do usuário. Normalmente utiliza-se o número de usuários afetados como o
a indicação do fator de impacto a ser analisado, porém a ITIL (OGC, 2007) sugere outros
fatores para a priorização dos incidentes. São eles:
- Risco de vida ou para algum membro;
- Número de serviços afetados;
- Impacto financeiro;
- Impacto sobre a reputação do negócio;
- Quebra de legislações ou regulamentações.
A partir do momento em que é atribuída uma severidade a um ticket, os custos em
relação ao SLA deverão ser atribuidos automaticamente à ele (quanto maior a severidade,
maior será o SLA e, consequentemente, as penalidades aplicadas em caso de
descumprimento do serviço). Logo, a priorização (impacto) do registro irá ditar o
comportamento do provedor de serviços, bem como a alocação de recursos necessária para
a resolução do incidente. Para exemplificar, um incidente crítico precisará de uma
abordagem muito mais delicada, enérgica e rápida em relação a um incidente menos
importante.
As ações referentes ao ciclo de vida do incidente, mostradas abaixo, são sugeridas
pela ITIL (OGC, 2007):
O suporte inicial geralmente é feito por um recurso do service desk. Ele poderá
verificar qual é o problema, efetuar (ou receber) uma ligação ao usuário para obter mais
detalhes (caso necessário) e então transferir o registro para a equipe com competência para
trabalhar no caso.
A fase de investigação e diagnóstico deverá ser realizada em conjunto pelas equipes
do provedor de serviços que estiverem aptas a tomar parte do problema e trabalhar para
resolvê-lo. É importante frisar que nem sempre um registro de incidente é resolvido por
apenas um único grupo, podendo envolver vários grupos em etapas distintas de diagnóstico
e reparação.
É importante notar que a ITIL sugere um processo separado para a o tratamento de
incidentes críticos, que serão vistos adiante.
A resolução se dá quando é constatado a causa do problema, bem como a solução
apresentada. Existem inúmeras possibilidades para a resolução de um incidente. É
27
primordial o contato com a(s) parte(s) afetada(s) para a confirmação da solução do
problema apontado.
Após as confirmações, o incidente poderá ser fechado. É neste momento onde o
relógio irá apontar se houve perda de SLA em relação ao tempo de resolução do serviço
versus a severidade do incidente. Caso positivo, as penalidades presentes em contrato
poderão ser aplicadas pelo cliente para a provedora de serviços.
Para efeitos de importância em relação à este trabalho, pode-se notar que o
Gerenciamento de Incidentes possui uma interface de envio e recebimento de dados junto
ao Gerenciamento de Problemas. Isso ocorre pois, uma vez que tem-se um registro de um
incidente em andamento, será necessário verificar se o mesmo possui uma solução já
conhecida em uma determinada base de dados, como sugere a ITIL (conhecida por Base de
Dados de Erros Conhecidos (Known Error Database (KEDB)) - utilizada pelo processo de
Gerenciamento de Incidentes e também Gerenciamento de Problemas para consulta de
soluções (ITIL Glossary, 2012)) - ou se o mesmo carece de solução e necessita de
investigação, necessitando da intervenção do gerenciamento de problemas.
Normalmente, isso irá acontecer quando o incidente é considerado de alto impacto e
a solução rápida não pôde ser provida a tempo de evitar transtornos maiores ao usuário
final. Neste contexto, apresentam-se os incidentes críticos.
4.2 Incidentes Críticos
Um incidente crítico ocorre quando um evento de proporções muito graves ocorre no
ambiente de TI de uma empresa, impossibilitando um grupo ou mais de usuários a
realizarem uma determinada tarefa - que geralmente é importante para o chamado core
business (parte principal de um determinado negócio) da empresa em questão.
Dentre uma variada gama de eventos que se encaixam nesse quadro, pode-se citar
alguns exemplos:
- Um servidor de e-mails deixa de operar repentinamente, funcionários ficam
sem acesso às suas caixas pessoais;
- A fibra óptica, link de dados principal da matriz de uma empresa, é rompida
em um determinado trecho. Toda a operação da empresa é interrompida;
- Falhas em aplicativos de segurança;
- Ataques de vírus em grande escala;
- Entre outros...
É importante notar que um incidente crítico irá envolver muito mais recursos para a
análise e constatação do problema, pois normalmente ele não irá possuir uma resolução
28
conhecida na base de dados, sendo necessário o envolvimento do processo de
Gerenciamento de Problemas para apoio.
A TABELA 2 mostra, de acordo com a ITIL (OGC, 2007), os prazos esperados para
resolução de incidentes de acordo com sua prioridade:
Fonte: http://www.devmedia.com.br/gerenciamento-de-incidentes-itil/7174
TABELA 2: Prioridades vs Tempo de Resolução Incidentes - ITIL
Isso significa que logo que um incidente considerado crítico (conhecido por algumas
designações como “Prioridade Um” ou “Severidade Um” ) seja aberto através do service
desk, o provedor deverá começar a trabalhar rapidamente em busca de uma solução que
atenda o prazo de uma hora. A ferramenta utilizada para o registro do ticket referente ao
incidente em questão deverá ser provida de algumas funcionalidades que possam mostrar o
progresso realizado, as últimas intervenções que foram realizadas, qual(is) os times
atuantes, a data/hora de abertura do ticket e o target para resolução. É importante também
que a ferramenta contenha códigos ou desginações geralmente utilizadas para identificar o
atual status do ticket (OGC, 2007).
4.3 Os Valores do Processo de Gerenciamento de Incidentes
A ITIL define os valores do processo de gerenciamento de incidentes através de
tópicos (OGC, 2007):
- Habilidade de resolver incidentes que resultem em um período baixo de
inatividade para o usuário(s) afetado(s), o que representa maior avaliabilidade do serviço;
- Habilidade de identificar prioridades e alocar recursos baseado na
necessidade do negócio;
- Habilidade de identificar pontos de melhoria, baseado na avaliação e
compreensão do que constitui um incidente e no trabalho junto à equipe de operações;
- Possibilidade de serem oferecidos treinamentos ou serviços adicionais,
enquanto o incidente está sendo gerenciado, pelo time de Service Desk.
29
Ainda segundo o OGC (2007), o processo de Gerenciamento de Incidentes possui
grande visibilidade para todos os segmentos da empresa, pois pode ser usado para mostrar
quais são as áreas que necessitam de mais atenção, e, consequentemente, prover
justificativa para a implementação de recursos ou investimentos adicionais.
4.4 Gerenciamento de Problemas
O gerenciamento de problemas é invocado sempre que um incidente ocorre e sua
causa/solução não é conhecida de imediato (VIANA, 2010). O objetivo desse processo é
tratar a ocorrência de forma com que não existam dúvidas em relação ao que causou o
incidente, mostrando a solução que visa eliminar o problema ocorrido de maneira
permanente e, em alguns casos, proativamente (CAVALCANTE.US, 2008).
A definição de problema, de acordo com CAVALCANTE.US (2008):
[...] Uma condição identificada originada por múltiplos incidentes que mostram sintomas comuns ou por um incidente significativo do qual não se conhece a causa. Um problema pode ser definido por:
- A repetição de incidentes com sintomas comuns, nos quais a causa é desconhecida; - Um incidente principal, do qual se desconhece a sua causa raiz.
Através dessa definição, pode-se notar que os processos de gerenciamento de
incidentes e gerenciamento de problemas irão se relacionar sempre quando descobrir a
causa de um incidente se fizer necessária. Apesar do relacionamento entre processos, é
importante com que cada um deles desenvolva seu fluxo de atividades independentemente
do outro. Conforme ALVES (2010 ? apud TIEXAMES, 2008), um registro de incidente não
deverá ser utilizado como um problema, devendo haver alguma forma de que seja
registrado um outro ticket para o controle de ambos processos. Um incidente deve ser
solucionado de forma rápida para evitar maiores problemas no ambiente de TI, ao passo
que um problema deve ser tratado de maneira com que a causa do evento possa se tornar
conhecida e a sua recorrência seja evitada.
A FIGURA 6 mostra o fluxograma do processo de gerenciamento de problemas:
30
FONTE: ALVES (2010 ? apud JONG, 2008) FIGURA 6: Representação do Gerenciamento de Problemas por fluxograma
Como é possível verificar no topo da figura, existem vários relacionamentos com
outros processos referentes à etapa de Operação de Serviço, proposta pela ITIL, que
funcionam como gatilhos para o início do processo de gerenciamento de problemas. De
acordo com a OGC (2007), a ferramenta utilizada no gerenciamento de incidentes e
problemas deve ser capaz de popular os respectivos regitros, caso exista um vínculo entre
eles, em cada um dos tickets.
O ciclo de vida de um registro de problema possui etapas parecidas com a de um
registro de incidente, com pequenas alterações. A categorização, de acordo com a ITIL,
deverá ser mantida igual ao registro de incidente. O impacto deve ser considerado da
mesma forma fronte a um registro de incidente, porém algumas considerações devem ser
tecidas em relação a este ponto. A severidade do problema, diferentemente da severidade
do incidente, deverá atentar ao ponto de vista em relação à criticidade do problema para a
infra-estrutura do ambiente. Algumas perguntas são sugeridas pelo framework para a
avaliação da severidade (OGC, 2007):
31
- O sistema pode ser recuperado ou deve ser substituído?
- Qual será o custo?
- Quantas pessoas e com quais habilidades serão necessárias para resolver
este problema?
- Quanto tempo o problema irá levar para ser resolvido?
- O quão extenso é o problema? (No sentido de quantidade de recursos
afetados).
Na fase de investigação e diagnóstico, as equipes de suporte irão trabalhar para
identificar a causa raiz do problema utilizando técnicas de solução de problemas adequadas
(cujo exemplo será visto adiante).
No momento em que é encontrada uma solução para este problema, essa solução
irá ser reportada na Base de Dados de Erros Conhecidos determinada pela provedora de
serviços, para que possa ser aplicada em futuros incidentes com a mesma
causa/característica. Isso contribui para a agilização do fechamento dos incidentes e
também para indicar soluções permanentes para um determinado problema (OGC, 2007).
Ainda de acordo com ALVES (2010 apud TIEXAMES, 2008 e JONG, 2008), os
seguintes conceitos são aplicados dentro do gerenciamento de problemas:
- Erro Conhecido (Known Error): é um Problema que possui sua causa raiz
documentada e a solução identificada.
- Solução de Contorno (Workaround): É uma forma utilizada para restaurar
ambiente após a ocorrencia de um incidente, sem resolver definitivamente o
problema.
- Solução Definitiva: Um problema que pode ser resolvido por uma requisição
de mudança (abordada pelo processo de Gerenciamento de Mudanças) para
eliminar a falha da infra-estrutura de TI que causou o problema e seu(s) incidente(s).
- Base de Dados de Erros Conhecidos: Uma base utilizada pelo provedor de
serviços que contém soluções definitivas e/ou de contorno para Incidentes e
Problemas.
- Impacto: Extensão do dano causado por Incidentes e Problemas.
- Urgência: Indica o senso de imediatismo necessário para resolver um
Incidente ou Problema.
- Prioridade: Aqui pode-se definir a ordem em que os Problemas devem ser
tratados, baseada no impacto sobre o cliente e na urgência.
A partir das informações oferecidas sobre os processos de gerenciamento de
incidentes e problemas, é possível dirigir-se ao sub-processo de Root Cause Analysis.
32
4.4.1 O subprocesso de Root Cause Analysis (RCA)
Root Cause Analysis (em tradução livre, Análise de Causa Raiz) é uma rotina
executada dentro do processo de Gerenciamento de Problemas, na etapa de diagnóstico e
investigação do problema. Ela tem a premissa de propor auxílio no método como os
problemas serão identificados e posteriormente sanados mediante investigação.
A ITIL (OGC, 2007) define algumas metodologias para a análise de um problema a
partir de técnicas conhecidas, utilizadas frequentemente e amplamente como ferramentas
de qualidade.
4.4.2 Análise Cronológica
Consiste em montar uma linha do tempo com os principais eventos ocorridos
durante o problema. A partir dessa linha do tempo, são verificados os eventos que podem
ter sido gerados a partir de outros, bem como refutar análises incorretas que não constem
nessa sequência.
4.4.3 Análise por “Valor da Dor”: Aqui serão verificados os incidentes e problemas de
acordo com o real impacto de suas dimensões perante ao negócio. Essa análise permite
com que se chegue a uma visão mais ampla sobre os principais incidentes/problemas que
causam ou causaram mais impacto, e determinar com que eles sejam priorizados em
relação a outros para investigação e solução.
4.4.4 Análise de Kepner/Tregoe:
Desenvolvida por Charles Kepner e Benjamin Tregoe (por isso o surgimento deste
nome), consiste em uma sugestão de etapas a serem seguidas para identificação do
problema, a saber:
- Definir o problema: Neste momento, é analisado qual desvio aconteceu em
relação ao nível de serviço acordado. Uma causa aproximada do problema deve ser
estabelecida, sem que conclusões precipitadas sejam tomadas, evitando que a
investigação tome um rumo incorreto.
- Descrever o problema em termos de identidade, localização, tempo e
tamanho: É definido o que “é” o problema. É feita uma análise em um ambiente
similar para que seja feita uma comparação daquilo que está funcionando
corretamente e o que não está. Essa análise irá determinar as diferenças entre os
dois ambientes e possivelmente facilitará o entendimento do erro.
33
- Estabelecer possíveis causas: As diferenças encontradas no passo
anterior irão provavelmente conter a causa do problema. Logo essas diferenças
podem gerar as causas prováveis.
- Testar a causa mais provável: Cada uma das causas mais prováveis deve
ser verificada, pois ela pode ser a causa de todos os sintomas do problema.
- Verificar a verdadeira causa do problema: Nesse momento as causas
que tiverem sobrado devem ser tratadas como sendo a raiz do problema.
4.4.5 Brainstorming
Consiste em alinhar algumas pessoas consideradas importantes no desenrolar do
processo (stakeholders) para discutir a respeito do problema ocorrido, onde cada pessoa
expõe seu ponto de vista - contribuindo para a análise de causa e resolução.
4.4.6 Diagrama de Ishikawa
Desenvolvido por Kaoru Ishikawa e também conhecido por “Fishbone” (Espinha de
Peixe), “Diagrama de Causa e Efeito” ou “Diagrama de Árvore”, consiste em um
desenvolvimento de diagrama (usualmente após uma sessão de Brainstorm entre os
stackholders), onde ficam definidos o problema (Tronco), as causas primárias (ramos),
sendo que outras prováveis causas são adicionadas posteriormente nos ramos (caules).
Essas prováveis causas podem incluir o uso da técnica dos “5 whys” (os cinco porquês), a
ser visto adiante. A FIGURA 7 mostra um exemplo genérico do Diagrama de Ishikawa:
Fonte: http://en.wikipedia.org/wiki/Ishikawa_diagram FIGURA 7: Modelo Genérico do Diagrama de Ishikawa.
34
4.4.7 Análise de Pareto
Consiste na manipulação de dados gerados por meio de uma tabela e,
posteriormente, da criação de um gráfico para exibição dos resultados. Ela permite separar
as possíveis causas mais impactantes em problemas em relação às mais triviais. Foi
desenvolvida por Joseph Moses Juran e também é conhecida por “Regra 80/20”, por meio
de uma definição trazida por Juran, que diz que 80% dos problemas existentes são
causados por 20% dos fatores (CASTRO, 2010).
As etapas a seguir devem ser tomadas como referência para a construção da
tabela de análise de Pareto (OGC, 2007):
- Montar uma tabela contendo as causas dos problemas encontrados
em um determinado ambiente, e identificar a porcentagem de sua ocorrência;
- Sortear as linhas por ordem de importância (o framework sugere
como exemplo partir da causa com maior incidência de acontecimentos até a
menor);
- Adicionar uma coluna contendo a porcentagem acumulativa de
falhas.
A TABELA 3, extraída do próprio livro Service Operation da ITIL, mostra um
exemplo de uma análise de Pareto a partir das causas de problemas na rede em
uma empresa (caso fictício):
35
Fonte: OGC (2007, p.117) TABELA 3: Tabela de Pareto: Causas de falhas de rede em uma determinada empresa
Após a análise dos dados da tabela, é gerado um gráfico de barras com os
resultados. Ele deverá ordenar as frequências das ocorrências (da maior para a
menor). Essa estratégia irá mostrar os chamados “20%” das causas consideradas
mais importantes, separando-as das restantes (80%) consideradas triviais. Para
tanto, a ITIL (OGC, 2007) sugere que esse gráfico deverá ser montado de forma com
que:
- A porcentagem de causas forme o eixo Y1 e a porcentagem de
frequências cumulativas das causas forme o eixo Y2.
- As causas formem o eixo X;
- Um gráfico de linha seja sobreposto em relação ao gráfico de barras.
Ele deve ser formado com os valores de frequências cumulativas.
- Uma linha tracejada deverá ser traçada no ponto “80” do eixo de
frequência cumulativa.
36
- A intersecção dessa linha com o gráfico de frequências cumulativas
irá determinar o ponto de separação. À esquerda, as causas mais importantes, à
direita, as triviais.
A FIGURA 8 também é extraída do livro Service Operation e mostra como
ficaria o gráfico final:
Fonte: OGC (2007, p.118) FIGURA 8: Gráfico de Pareto: Causas de falhas de rede em uma determinada empresa
4.4.8 Five Whys
Esse não é um método indicado diretamente pela ITIL através do livro Service
Operation, mas trata-se de outra ferramenta de qualidade também muito utilizada na
detecção das causas de problemas de TI. BAPTISTA [2007 ?] indica que muitas empresas
utilizam o processo de Five Whys (conhecido no Brasil por “cinco porquês”) quando a
37
relação de causa e consequência é linear, ou seja, não existem muitas ramificações para o
que possa ser considerada a causa de um problema. Porém, apesar de não ter seu uso
indicado pelo framework, os Five Whys também podem ser utilizados como uma parte
consituinte do Diagrama de Ishikawa, conforme já mencionado.
Este método consiste na repetição da pergunta Why? (Porquê?) durante a
investigação das causas do problema, até o momento em que considera-se não haver mais
questionamentos sobre a último fator analisado, determinando nesse momento a causa raiz
do problema. O número de porquês adotado (cinco) não corresponde necessariamente ao
mínimo de perguntas necessárias a serem realizadas antes de determinar a causa raiz. Isso
irá depender principalmente da complexidade do problema que está sendo verificado.
Porém, estatisticamente, a causa raiz de um problema normalmente pode ser obtida após
exatos cinco questionamentos (REMPEL, 2009 apud Ribeiro, 2005).
Sendo o método dos five whys originário da metodologia do Sistema Toyota de
Produção, uma referência de padrões de qualidade e processos que é continuamente
adotada por empresas de todos os setores, sua aplicação aos processos de TI sofre alguma
alteração, principalmente quando se faz necessário efetuar adaptações ao processo para
que ele fique em conformidade com outras metodologias adotadas pelas companias (no
caso em questão, a ITIL). Porém, sua estrutura não deverá sofrer alterações.
Um exemplo de um problema analisado pelo método dos cinco porquês é descrito
abaixo (Problem Solve iT, 2012):
Incidente: Um servidor não está funcionando
Causa Aproximada: Não se aplica por hora, servidor não opera.
Why #1: Porque o servidor não está funcionando?
Resposta: Porque não há energia elétrica para o servidor.
Neste momento, as respostas obtidas a cada nova questão tornam-se as próximas
perguntas.
Why #2: Porque não há energia elétrica para o servidor?
Resposta: Por que o filtro de linha não liga.
Why #3: Porquê o filtro de linha não liga?
Resposta: Não existe energia elétrica na tomada.
Why #4: Porque não existe energia elétrica na tomada?
Resposta: O disjuntor elétrico não funcionou.
38
Why #5: Porque o disjuntor elétrico não funcionou?
Resposta: Porque a manutenção apropriada não foi realizada para mantê-lo
funcionando adequadamente.
Ainda que simples, a situação informada nos permite, por exemplo, diferenciar um
fator de contribuição de um problema (ex.: falta de energia elétrica), para a verdadeira
causa raiz do mesmo (falta de manutenção no componente elétrico).
Apesar de ser considerado um método linear de análise de causa e efeito, a
aplicação da técnica dos 5W pode gerar uma pergunta que tenha mais do que uma
resposta. Neste caso, todas as novas respostas geram novas perguntas, que ao final podem
gerar mais do que uma causa raiz para o problema.
4.5 Planos de Ação
Após a detecção da causa raiz do problema, são realizados os chamados planos de
ação, que visam garantir que o problema será resolvido através de algumas atividades a
serem realizadas pelas partes integrantes e suporte técnico responsáveis pelo ocorrido.
A ITIL não define como os planos de ação devem ser executados, uma vez que já
nesta etapa atinge-se o nível de procedimentos de processo, e isso irá variar de empresa
para empresa.
Pode haver mais do que um plano de ação, dependendo do caso, e ele(s) pode(m)
ser cumprido(s) a curto, médio ou longo prazo. Os planos de ação determinados para o
exemplo dado na resolução através do método dos cinco porquês (Problem Solve iT, 2012)
foram os seguintes:
Plano de ação a curto prazo: Substituição do disjuntor.
Esse plano de ação seria uma forma de workaround, que é definido por ALVES
(2010) como uma maneira temporária de se resolver um incidente, restaurando o serviço ao
estado normal, sem resolver o problema definitivamente. A substituição do disjuntor
resolveria o incidente, mas não o problema.
Plano de ação a longo prazo: Implementar um plano periódico de manutenção do
sistema elétrico.
Conforme diagnosticado, a verdadeira causa raiz do problema consistia na ausência
de um plano de manutenção dos equipamentos elétricos, o que causou o incidente e, muito
provavelmente, causaria outros incidentes no futuro. Com a adoção desse plano, os
39
incidentes deixariam de acontecer por conta de falhas com o disjuntor. O problema, dessa
forma, é considerado resolvido.
4.6 Valor Agregado pela utilização de Root Cause Analysis
De acordo com a OGC (2007), a alta disponibilidade juntamente com a qualidade do
serviço entregue deverão ser garantidas através do Gerenciamento de Problemas, isso
devido à análise realizada junto a incidentes e problemas que são resolvidos e à informação
de resolução gerada (e devidamente armazenada) pelos mesmos. Dessa forma, é possivel
com que a provedora de serviços possa agir proativamente contra novos problemas ou
resolvê-los mais rapidamente quando isso ocorrer. Outros valores também são
mencionados pela OGC através do processo de Gerenciamento de Problemas:
- Alta disponibilidade dos serviços de TI;
- Maior produtividade dos negócios e da equipe de TI;
- Redução das despesas em soluções ou correções que não funcionam;
- Redução do custo de esforço na resolução de incidentes repetidos ou em
uma situação de emergência.
5.0 CONCLUSÃO
O processo de Gerenciamento de Problemas (e também o de Incidentes e todos
outros sugeridos pela ITIL) de fato tem suas dificuldades de implantação e adaptação.
BARBOSA, ARAÚJO e TORRES (2011, p.35 apud CATER-STILL, TOLEMAN e TAN, 2006)
divulgam um estudo de caso realizado em cinco grandes corporações Australianas, onde
alguns gerentes de projetos que efetuaram a implementação do ITIL foram indagados sobre
os benefícios dessa ação, três anos após a efetivação do framework:
[...] muitos gerentes relataram que não fizeram tanto progresso
como desejavam, devido a problemas como a falta de apoio à
gestão, a mudança cultural em termos de resistência da equipe
técnica, e os atrasos na criação de um conjunto de ferramentas
adequadas. Mencionaram também o desafio de se otimizar as
ferramentas de software. Ocorreram atrasos na especificação
de compra e implementação de pacotes de software
adequados para o registro de incidentes, o banco de dados e
gerenciamento de configuração.
40
Mesmo após os gerentes de implantação informarem as dificuldades com a
adaptação ao ITIL, a avaliação final foi positiva (BARBOSA, ARAÚJO e TORRES (2011,
p.36 apud CATER-STILL, TOLEMAN e TAN, 2006):
[...] mesmo com algumas dificuldades, os estudos de caso
apresentados demonstram que a implementação da ITIL pode
melhorar o gerenciamento de serviços e trazer benefícios às
organizações, tais como: infra-estrutura mais previsível,
controle mais rigoroso de testes e alterações do sistema,
redução de falhas do servidor, melhor atuação da área de TI
dentro da organização, documentação dos processos de
serviços de gestão de TI e a eficácia e coerência no registro
de incidentes.
A utilização do processo de Gerenciamento de Problemas inegavelmente traz
benefícios, seja para a provedora de TI, seja para o seu cliente, pois irá facilitar a análise de
erros que ocorrem no ambiente de serviços bem como a atuação para evitá-los e por fim
eliminá-los de forma definitiva. Baptista [2007 ?] aponta alguns argumentos que são
utilizados para evitar a adoção do mesmo:
- Processo burocrático e caro;
- Uma forma de encontrar e punir os culpados por erros;
- Trata-se de uma moda passageira;
- Entre outros...
Porém, fica claro que a inclusão do Gerenciamento de Problemas ao portfolio de
serviços de uma empresa provedora de serviços de TI deixa em evidência que a mesma
tem (ou terá) estrutura para suportar eventuais situações de risco ou indesejadas em
relação aos seus serviços entregues.
A utilização de qualquer metodologia de solução de problemas, seja por meio das
técnicas neste trabalho apresentadas ou por outras ferramentas de qualidade, contribui para
o bom desenvolvimento de um documento de RCA, pois facilitam a leitura e a compreensão
das atividades a serem executadas pelos envolvidos no processo e permitem com que a
avaliação final das causas de um problema realmente tragam a causa raiz do mesmo, o que
contribuirá de maneira efetiva para a solução e também no diagnóstico de futuros
incidentes. Dessa forma, a provedora de serviços pode ir adquirindo maturidade e expertise
na manutenção dos seus serviços, evitando problemas de infra-estrutura e, inclusive,
atenuando perdas financeiras em situações adversas.
41
REFERÊNCIAS BIBLIOGRÁFICAS
ALVES, Leandro Santana Moraes. Gerenciamento de Problemas usando ITIL: um
estudo de caso. Monografia (Especialização em Gestão da Tecnologia da Informação).
Faculdade Pitágoras de Uberlândia, Minas Gerais. Disponível em <
http://si.lopesgazzani.com.br/docentes/marcio/ori_p/gti_2_20100410_LeandroAlves_Gerecia
mento%20de%20Problemas%20Utilizando%20ITIL.pdf>. Acesso em 03 set. 2012.
BALDIN, Fernando. EVOLUÇÃO DE SERVIÇOS TI: Da Pré-história a atualidade. Disponível em < http://mefosbrasil.blogspot.com.br/2012/05/evolucao-de-servicos-ti-da-pre-historia.html>. Acesso em 19 mai. 2012. BAPTISTA, José Antonio. A IMPORTÂNCIA DA ANÁLISE DE CAUSA RAIZ (ROOT CAUSE ANALYSIS) NA MELHORIA DO DESEMPENHO DA MANUTENÇÃO INDUSTRIAL. Disponível em <http://www.abraman.org.br/Arquivos/191/191.pdf>. Acesso em 01 out. 2012
BARBOSA, Cristian Suzuki; ARAÚJO, David Campos de; TORRES, Isabelle Vasconcelos.
Governança de TI Usando as Práticas da ITIL. Revista Tecnologias em Projeção, v.2, n.
1, p. 34-38. Disponível em
<http://revista.faculdadeprojecao.edu.br/revista/index.php/projecao2/article/viewFile/79/66>.
Acesso em 25 set. 2012.
BEAL, Adriana. Segurança da Informação: Princípios e Melhores Práticas para a Proteção
dos Ativos de Informação nas Organizações. São Paulo: Editora ATLAS S.A., 2008. 175p.
CARVALHO, Pedro F. OPERAÇÃO DE SERVIÇO – ITIL FOUNDATION V3. Disponível em
< http://www.pedrofcarvalho.com.br/PDF/ITIL_OPERACAO_SERVICOS.pdf>. Acesso em 15
jul. 2012.
CASTRO, Cláudio Henrique de. Curva ABC - Análise de Pareto - O Que é e Como
Funciona. Disponível em <http://www.sobreadministracao.com/o-que-e-e-como-funciona-a-
curva-abc-analise-de-pareto-regra-80-20/>. Acesso em 27 set. 2012.
DANTAS, Vera. Guerrilha Tecnológica: A Verdadeira História da Política Nacional de
Informática. Rio de Janeiro: LTC-Livros Técnicos e Científicos, 1988. 176p.
42
Gerenciamento de Problemas. Disponível em
<http://cavalcante.us/Concursos/Analista_de_Sistemas/ITIL/acadger-Modulo2-
Problemas.pdf>. Acesso em 18 mai. 2012.
How Many ITIL Certified Professionals Are There? Disponível em
<http://www.itilfree.com/how-many-itil-certified-professionals-are-there.html>. Acesso em
16.jun 2012.
Ishikawa Diagram. Disponível em <http://en.wikipedia.org/wiki/Ishikawa_diagram>. Acesso
em 27 set. 2012.
IT PROCESS MAPS. Itil Glossary. Disponível em <http://wiki.en.it-
processmaps.com/index.php/ITIL_Glossary>. Acesso em 10 jul. 2012.
LUNA, Marcelo Fernandes de. Gestão da Segurança da Informação com ITIL® v3 e
ISO/IEC 27002. Monografia (Graduação em Ciência da Computação). Universidade
Estadual de Londrina, Paraná, 2010. Disponível em
<http://www.gaia.uel.br/media/uploads/gaia/TCC_Marcelo.pdf>. Acesso em 15 jun 2012.
MACÊDO, Diego. Introdução à ITIL - Conceitos Básicos, História e Organizações.
Disponível em <http://www.diegomacedo.com.br/introducao-a-itil-conceitos-basicos-historia-
e-organizacoes/>. Acesso em 06. jun 2012.
MAGALHÃES, Ivan Luizio; PINHEIRO, Walfrido Brito. Gerenciamento de Serviços de TI
na Prática: Uma abordagem com base na ITIL. São Paulo: Novatec, 2007. 672 p.
NAMOUR, Roberta. Os efeitos colaterais da Lei de Informática. Isto É Dinheiro, São
Paulo, v1, n.628. Disponível em
<http://www.istoedinheiro.com.br/noticias/772_OS+EFEITOS+COLATERAIS+DA+LEI+DE+I
NFORMATICA>. Acesso em: 03. jun 2012.
OGC - Office of Government Commerce. Service Strategy. Londres, Inglaterra: The
Stationary Office, 2007.
43
OGC - Office of Government Commerce. Service Design. Londres, Inglaterra: The
Stationary Office, 2007.
OGC - Office of Government Commerce. Service Transition. Londres, Inglaterra: The
Stationary Office, 2007.
OGC - Office of Government Commerce. Service Operation. Londres, Inglaterra: The
Stationary Office, 2007.
OGC - Office of Government Commerce. Continual Service Improvement. Londres,
Inglaterra: The Stationary Office, 2007.
PROCESSO CONSULTORIA LTDA. C1 Controle das Ocorrências. Disponível em
<http://www.ciclocapd.com.br/paginas/capd/c/c1/index.html>. Acesso em 07 jul. 2012.
REMPEL, Ângelo. ANÁLISE DE PROCESSO E APLICAÇÃO DAS FERRAMENTAS DA
QUALIDADE PARA AUMENTAR EFICIÊNCIA DE UMA SOPRADORA DE GARRAFAS
PET. Monografia (Graduação em Engenharia Mecânica). Universidade Federal do Rio
Grande do Sul, Rio Grande do Sul, 2009. Disponível em
<http://www.lume.ufrgs.br/bitstream/handle/10183/24252/000742672.pdf?sequence=1>.
Acesso em 10 ago. 2012
SANTOS, Gilmar Souza. Modelo de Outsourcing para Gestão da Oferta e Operação de
Serviços de TI: Múltiplos Casos de Aplicação. Disponível em
<http://www.unimep.br/phpg/bibdig/pdfs/docs/15032011_111311_tese_gilmar_vfinal_100520
10.pdf>. Acesso em 09 set. 2012.
SCHWEBEL, Samuel. Semelhanças e diferenças entre ITIL e CMMI para serviços.
Disponível em <http://www.teclogica.com.br/blog/?p=508>. Acesso em 16 jun. 2012.
VERNAY, Diogo. Gerenciamento de Incidentes - ITIL. Disponível em
<http://www.devmedia.com.br/gerenciamento-de-incidentes-itil/7174>. Acesso em 15 jun.
2012.
44
VIANA, Helder de Souza. GOVERNANÇA TI E SUAS METODOLOGIAS DENTRO DO
MUNDO CORPORATIVO. Monografia (Pós-graduação em Engenharia da Produção).
Universidade Candido Mendes, Rio de Janeiro, 2010.
45
