UNIVERSIDADE SÃO FRANCISCO CURSO DE ENGENHARIA DA COMPUTAÇÃO. Paulo Gustavo Turco Cunha RA

Transcrição

1 UNIVERSIDADE SÃO FRANCISCO CURSO DE ENGENHARIA DA COMPUTAÇÃO Paulo Gustavo Turco Cunha RA ESTUDO DA APLICAÇÃO DE ROOT CAUSE ANALYSIS (RCA) PARA INCIDENTES CRÍTICOS EM AMBIENTES DE TI Itatiba 2012

2 UNIVERSIDADE SÃO FRANCISCO CURSO DE ENGENHARIA DA COMPUTAÇÃO Paulo Gustavo Turco Cunha RA 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

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

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

5 O sucesso é ir de fracasso em fracasso sem nunca perder o entusiasmo Winston Churchill

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

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

8 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

9 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

10 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

11 SUMÁRIO INTRODUÇÃO OBJETIVOS METODOLOGIA GESTÃO DE SERVIÇOS DA TECNOLOGIA DA INFORMAÇÃO (TI) O Brasil, o Mercado de TI e a Demanda por Serviços Estrutura do Framework ITIL OPERAÇÃO DE SERVIÇOS E OS DESAFIOS DO PROVEDOR DE TI Gerenciamento de Incidentes Incidentes Críticos Os Valores do Processo de Gerenciamento de Incidentes Gerenciamento de Problemas O Subprocesso de Root Cause Analysis Análise Cronológica Análise por Valor da Dor Análise de Krepner/Tregoe Brainstorm Diagrama de Ishikawa Análise de Pareto Five Whys Planos de Ação Os Valores do Processo de Gerenciamento de Problemas CONCLUSÃO... 39

12 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 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 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 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 autoexplicativos, 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, tornouse 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 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 A ITIL V2 contou com uma redução considerável no volume de livros, reduzidos a dez volumes: - Introduction to ITIL

17 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 Fonte: MACÊDO, 2012 apud ITSMF, 2007 FIGURA 1 - Distribuição dos modelos de Governança de TI no Brasil

18 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 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 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: 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 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 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 % 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, TABELA 1: Organizações prejudicadas por falhas em serviços de TI

22 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 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: 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 24 Fonte: 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 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 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 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 s 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 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: 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 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 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 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 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 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 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 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 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 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 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: FIGURA 7: Modelo Genérico do Diagrama de Ishikawa.

34 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 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 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 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