Estudo de Caso de Utilização Da Metodologia Devops Para Atender Ao Processo de Continuidade de Serviços Conforme o Framework

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA FLUMINENSE  CAMPOS-CENTRO CAMPUS  CAMPOS-CENTRO CURSO DE PÓS-GRADUAÇÃO LATO SENSU  EM  EM ANÁLISE E GESTÃO DE SISTEMAS S ISTEMAS DE INFORMAÇÃO

PATREZZE DE ALVARENGA SILVA RAFAEL NASCIMENTO GOMES

ESTUDO DE CASO DE UTILIZAÇÃO DA METODOLOGIA DEVOPS PARA ATENDER  FRAMEWORK  AO PROCESSO DE CONTINUIDADE DE SERVIÇOS CONFORME O  FRAMEWORK 

ITIL

CAMPOS DOS GOYTACAZES 2016

PATREZZE DE ALVARENGA SILVA RAFAEL NASCIMENTO GOMES

ESTUDO DE CASO DE UTILIZAÇÃO DA METODOLOGIA DEVOPS PARA ATENDER  FRAMEWORK  AO PROCESSO DE CONTINUIDADE DE SERVIÇOS CONFORME O  FRAMEWORK 

ITIL

Monografia apresentada ao Instituto Federal Fluminense, Campus  Campos-Centro, como requisito parcial para conclusão do Curso de Pósgraduação  Lato Sensu  em Análise e Gestão de Sistemas de Informação. Orientador: M.e Fernando Carvalho

CAMPOS DOS GOYTACAZES 2016

Dados Internacionais de Catalogação na Publicação (CIP) Biblioteca. Setor de Processos Técnicos (IFF)

S586e

Silva, Patrezze de Alvarenga Estudo de caso de utilização da metodologia DevOps para atender o processo de continuidade de serviços conforme o framework ITIL / Patrezze de Alvarenga Silva, Rafael Nascimento Gomes  – 2016. 36 f.: il. color. Orientador: Fernando Luiz de Carvalho e Silva Monografia (Pósgraduação Lato Sensu em Análise e Gestão de Sistemas de Informação). Instituto Federal de Educação, Ciência e Tecnologia Fluminense. Campus Campos Centro. Campos dos Goytacazes (RJ), 2016. Referências: p. 31-33. 1. Serviço de informação - Administração. 2. Tecnologia da informação  – Administração. I. Gomes, Rafael Nascimento. II. Silva, Fernando Luiz de Carvalho e, orient. III.Título. CDD  – 658.4038

PATREZZE DE ALVARENGA SILVA RAFAEL NASCIMENTO GOMES

ESTUDO DE CASO DE UTILIZAÇÃO DA METODOLOGIA DEVOPS PARA ATENDER  FRAMEWORK  AO PROCESSO DE CONTINUIDADE DE SERVIÇOS CONFORME O  FRAMEWORK 

ITIL

Monografia apresentada ao Instituto Federal Fluminense, Câmpus Campos-Centro, como requisito parcial para conclusão do Curso de Pósgraduação  Lato Sensu  em Análise e Gestão de Sistemas de Informação. Orientador: M.e Fernando Carvalho

Aprovada em 08 de abril de 2016

Banca Avaliadora:

.......................................... ................................................................ ............................................ ............................................. ............................................. .......................................... .................... Prof. D.r Breno Fabrício Terra Azevedo Doutor em Informática na Educação - UFRGS Instituto Federal de Educação, Ciência e Tecnologia Fluminense Campus Campos-Centro

.......................................... ................................................................ ............................................ ............................................. ............................................. .......................................... .................... Profa. D.ra Simone Vasconcelos Silva Doutora em Computação - UFF Instituto Federal de Educação, Ciência e Tecnologia Fluminense Campus Campos-Centro

.......................................... ................................................................ ............................................ ............................................. ............................................. .......................................... .................... Prof. M.e Fernando Luiz de Carvalho e Silva (Orientador) Mestre em Engenharia de Produção - UENF Instituto Federal de Educação, Ciência e Tecnologia Fluminense Campus Campos-Centro

Dedico a meus familiares e minha esposa Gislaine, os quais sempre me apoiaram em todas as decisões difíceis. Compartilho com eles a alegria dessa conquista. Patrezze de Alvarenga Silva

Aos meus pais, minha irmã e minha namorada que, com muito carinho е dedicação, não mediram esforços para que eu chegasse até esta etapa de minha vida. Rafael Nascimento Gomes

AGRADECIMENTOS

A Deus, por ter nos dado saúde e força para superar as dificuldades. A esta instituição de ensino, seu corpo docente e discente, que proveram os meios e a estrutura necessária para alcançar o tão sonhado título. Ao nosso orientador, Fernando Carvalho, pelo apoio no pouco tempo que lhe coube, pelas suas correções e incentivos. Aos nossos pais, pelo incentivo e apoio incondicional, e a nossas companheiras, pelo amor e presença, nos confortando nas dificuldades. E a todos que direta ou indiretamente fizeram parte da nossa jornada, nosso muito obrigado.

Às vezes, quando você inova, comete erros. É melhor admiti-los rapidamente e continuar a melhorar suas outras inovações. Steve Jobs

RESUMO

O objetivo deste trabalho é demonstrar a eficácia da utilização de conceitos DevOps em conformidade com as melhores práticas descritas pelo framework ITIL. Principalmente, na gerência de continuidade de serviço de TI, no que diz respeito à habilidade de restaurar serviços considerados de grande risco ao negócio. Por este motivo, foi elaborado um estudo de caso para avaliar a automação de um processo de provisionamento de sistemas em uma instituição pública, em comparação ao modelo de suporte executado através de procedimentos manuais. O trabalho destaca-se em trazer uma solução simples para reduzir os problemas da continuidade dos serviços de TI. Além disso, garantir a eficiência e flexibilidade da infraestrutura de TI para atender grandes demandas e administrar cenários complexos. Palavras-chave: Palavras-chave: DevOps, ITIL, Continuidade de Serviço S erviço de TI.

ABSTRACT

The objective of this work is demonstrate the effectiveness of using DevOps concepts in accordance with the best practices described in the ITIL framework. Mainly in the IT service continuity management, regarding the ability to restore considered high risk to  business services. For this reason, a case study was designed to evaluate the automation of a system provisioning process in a public institution, compared to the support model runs through manual procedures. The work stands out in bringing a simple solution to reduce the  problems of IT services continuity. Also, ensure the efficiency and flexibility of the IT infrastructure to attend large demands and manage complex scenarios.

Keywords: DevOps, ITIL, IT Service Continuity, Agility.

LISTA DE ABREVIATURAS

DSL – Domain Specific Language ITIL – Information Technology Infraestructure Library PHP – Personal Home Page ROI – Return On Investment SLA – Service Level Agreement SSH – Secure Shell TI – Tecnologia da Informação VOI – Value On Investiment

LISTA DE QUADROS

Quadro 1 – Comparativo de resultados em caso de falhas no ambiente produtivo ................ 29

10

SUMÁRIO

1 INTRODUÇÃO ............................................. ................................................................... ............................................ ............................................ .......................... .... 11 1.1

Objetivo............................................ .................................................................. ............................................ ............................................ ................................... ............. 11

1.2 Justificativa ............................................ ................................................................... ............................................. ............................................ ............................ ...... 12 1.3

Metodologia ........................................... ................................................................. ............................................ ............................................ ............................. ....... 12

1.4

Estrutura do Trabalho .......................... ................................................ ............................................ ............................................ ................................ .......... 12

2 REFERENCIAL TEÓRICO .......................................... ................................................................ ............................................ ................................ ..........14 2.1

Governaça de TI .................................................. ........................................................................ ............................................ ...................................... ................ 14

2.2  Framework ITIL........................................ ITIL.............................................................. ............................................ ............................................ .......................... .... 15 2.2.1 Gerenciamento Gerenciamento de continuidade de serviços de TI ......................................................... ......................................................... 17 2.2.2 Gerenciamento Gerenciamento de Configurações e Ativos de Serviço ........................................... ................................................... ........ 18 2.3

DevOps............................................ .................................................................. ............................................. ............................................. ................................... ............. 19

2.3.1 Automatização de Processos de Infraestrutura de TI .......................................... ...................................................... ............ 20 3 ESTUDO DE CASO ................................. ....................................................... ............................................ ............................................ ............................... ......... 23 3.1

Ambiente do estudo de caso........................................... ................................................................. ............................................ ........................... ..... 23

3.2

Sobre o problema ............................................................... ..................................................................................... ............................................ ........................ 24

3.3

Procedimentos ............................................ .................................................................. ............................................ ............................................ ......................... ... 25

3.4

Solução Implementada......................................................... ................................................................................ ........................................... ....................26

3.5

Resultados ........................................... ................................................................. ............................................ ............................................ ................................ .......... 27

4 CONCLUSÃO .......................................... ................................................................ ............................................ ............................................. ............................... ........ 30 REFERÊNCIAS ........................................... ................................................................. ............................................ ............................................ ................................ .......... 31 APÊNDICE A – Código fonte de implementação do Puppet ........................... ................................................. ........................ 34

11

1

INTRODUÇÃO Este trabalho tem como tema um  Estudo de caso de utilização da metodologia

 DevOps para atender ao processo de continuidade continuidade de serviços conforme o framework ITIL.

A partir desta temática foi prescrito um processo, aderente ao  framework Information Technology Infrastructure Library (ITIL), atualmente na versão 3, que proporcionou garantias

de segurança e qualidade, em um exemplo de serviço de Tecnologia da Informação (TI), mantido de forma repetitiva e manual em uma repartição pública municipal. Juntamente ao ITIL, foram aplicados métodos e ferramental que seguem a linha de agilidade provenientes do conceito DevOps, a fim de garantir uma rápida retomada das operações após possíveis interrupções provocadas por um desastre que paralisem parte ou totalmente o negócio. O trabalho explora os conceitos e benefícios oriundos do manifesto DevOps que atualmente vem ganhando mais força pelos resultados que estão sendo obtidos no provimento dos serviços de TI, trazendo consigo uma nova forma de cooperação entre equipes de trabalho, com o objetivo de facilitar a rotina de operações e minimizar a intervenção humana durante o processo (MUELLER, 2010). A questão central desta monografia é: será que técnicas DevOps conseguem aumentar a competência da área de TI através da melhoria dos procedimentos de infraestrutura, de acordo com o ITIL? 1.1

Objetivo O objetivo principal desse trabalho é o de demonstrar que ferramentas e técnicas ágeis,

observadas no conceito DevOps, podem ser realmente eficientes e efetivas na garantia da continuidade de serviços de TI, trazendo os benefícios que superam o modelo de trabalho tradicional, no que diz respeito r espeito a escalabilidade, flexibilidade e velocidade, particularmente na área de infraestrutura que é importante e responsável pelo provisionamento de ambientes de forma segura e rápida. Como também avaliar o alinhamento dos conceitos de DevOps com ITIL. Propõe-se utilizar e analisar uma contribuição na condução de problemas que são recorrentes, agindo de maneira padronizada, segura, rápida e rastreável conforme os padrões de governança já estabelecidos no mercado. Dessa maneira é possível que questões operacionais sejam deixadas em segundo plano, dando condições aos profissionais de TI para

12

atuarem mais livremente na criação de soluções, desenvolver melhorias ou dedicados a questões estratégicas e que sejam diferenciais para o segmento no qual atuam. 1.2

Justificativa A relevância deste trabalho é que a área de TI possui o desafio de manter as suas ações

e tomadas de decisões sempre de acordo com o planejamento estratégico das instituições e clientes, bem como diminuir o prejuízo e o custo com tecnologia, de modo que seja possível garantir o retorno sobre os investimentos. Cabe acrescentar também que o tema deste trabalho no âmbito do serviço público ainda não é muito difundida. Sendo assim, o projeto aborda questões que visam melhorar os serviços de TI oferecidos por instituições instit uições públicas para a sociedade. A fim de solucionar as questões levantadas na introdução deste documento, foi necessário conduzir uma investigação sobre as técnicas e teorias utilizadas uti lizadas nesta pesquisa.

1.3

Metodologia  Neste trabalho buscou-se estudar o ganho de eficiência e qualidade dos serviços de TI

obtidos pela aplicação de processos apoiados pelo modelo ITIL. Também foi necessário analisar as ferramentas e metodologias DevOps voltadas, principalmente, para a área de infraestrutura de TI. Realizar um estudo de caso comparando se houve ganho ou perda de  produtividade do modelo tradicional tr adicional em relação aos resultados encontrados pós implantação de uma ferramenta DevOps. 1.4 Estrutura do Trabalho  No capítulo 2, são feitas as correspondências que dão base ao trabalho, iniciando com o levantamento de concepções de governança de TI, os quais permitem direcionar o trabalho  para desafios reais encontrados por empresas de todos os portes. Além disso, os textos destacam os benefícios da aplicação desse tipo de modelo de gestão, principalmente, para  buscar a eficiência eficiência e capacidade capacidade de adaptação adaptação a diferentes necessidades necessidades de mercado. Ainda sobre gestão, mas com um enfoque operacional, são abordadas nos subcapítulos seguintes as melhores práticas constatadas pelo  framework   ITIL, já que o seu modelo foi

13

desenvolvido para dar resposta às necessidades de governança. Além disso, ele nativamente aborda a problemática da continuidade de serviços de TI, oferecendo direcionamentos para minimizar seus impactos. Houve ainda a necessidade de conceituar o gerenciamento de configurações e ativos de serviço, já que se trata de uma gerência que controla diretamente os componentes físicos e abstratos da infraestrutura de TI, os quais podem ser acometidos por algum desastre e consequentemente consequentemente afetar a continuidade do negócio de uma instituição.  No capítulo 2.3 é feito o levantamento dos conceitos DevOps, mostrando sua relevância para agilizar tarefas e aumentar aumentar a coesão dos trabalhos em equipe. No capítulo 2.3.1 é abordada a importância da automatização dos processos de infraestrutura para garantir a padronização dos serviços prestados e rapidez na realização das ações operacionais. Esse tópico ainda descreve e exemplifica ferramentas DevOps com as características de facilitar a automatização da gerência de configuração. O capítulo 3 trata do estudo de caso montado para avaliar a integração do ITIL com o DevOps, a fim de agilizar o processo de retomada dos serviços interrompidos por algum sinistro e que o ambiente recuperado atenda a continuidade do negócio. São descritos em seus subcapítulos a descrição do ambiente estudado, os problemas encontrados, a metodologia aplicada, as soluções implementadas e os resultados encontrados.

14

2

REFERENCIAL TEÓRICO Para compor o estudo foi necessário o entendimento dos conceitos de Governança de

TI,  framework  ITIL,   ITIL, DevOps, como também Rastreabilidade e Continuidade de Serviço de TI. 2.1

Governaça de TI A Governança pode ser entendida como um conjunto de normas, processos,

regulamentações e políticas internas, definidas pela alta administração, que ditam como a empresa deve funcionar e ser controlada para garantir suas metas e seus objetivos. Essa visão remete ao objetivo administrativo de obter melhores resultados, principalmente econômicos. Porém, os desafios para fazer com que as empresas funcionem como um organismo cooperativo são muito complexos. Além disso, os seus integrantes devem estar concentrados dentro de um alinhamento estratégico definido pela governança (LUNARDI, 2008). Segundo o IBGC (1995), “Governança corporativa é o sistema pelo qual as empresas e demais organizações são dirigidas, monitoradas e incentivadas, envolvendo os relacionamentos entre sócios, conselho de administração, diretoria, órgãos de fiscalização e controle e demais partes interessadas.”.

Observando a estrutura organizacional das empresas atuais, seja ela pequena, p equena, média ou grande, é possível afirmar que elas são totalmente dependentes de tecnologia para se manterem vivas frente a um mercado tão exigente por qualidade nos produtos e serviços que são ofertados. (LUNARDI, 2008). Historicamente, a competição sempre levou as instituições a se aprimorarem e, consequentemente, as fizeram buscar incessantemente instrumentos que alavancassem a produtividade. Diante dessa necessidade, as empresas passaram a se  preocupar com a eficiência das suas rotinas de trabalho, revelando r evelando o setor de TI como peça chave, visto que, muitas rotinas poderiam ser facilmente mapeadas e simplificadas em sistemas. Perante a esse cenário tão exigente, no qual o mercado seleciona os melhores e a complexidade de gerir é posta a prova, uma mudança estrutural passou a ocorrer dentro das organizações. Esta restruturação foi a capacitação da TI para os moldes de gestão, com o intuito de ajudar na formulação f ormulação de estratégias para obter vantagem competitiva.

15

O ITGI (2003, p. 10, tradução nossa) afirma, “Governança de TI é da responsabilidade do Conselho de Administração e Gestão Executiva. É uma parte integrante da governança corporativa e consiste nas estruturas de liderança e organizacionais e processos que garantam que TI da organização sustenta e se estende a estratégias e objetivos da organização.”.

Em muitas organizações, a TI é vista como mais um setor independente das ações que são realizadas dentro da empresa, mas os seus gestores muitas vezes não compreendem que a TI é indispensável para tomar qualquer atitude estratégica. Isso porque ela, metaforicamente,  passou a ser a espinha espinha dorsal que interliga interliga todas as áreas, áreas, direcionando e tratando os estímulos estímulos  provenientes de todos os setores e também os regulamentando regulamentando com os direcionamentos direcionamentos da gestão. A Governança atua fornecendo informação a Gestão para a tomada de decisão e auxilia na delegação das responsabilidades responsabilidades garantindo maior eficiência. Segundo FILHO (2012, p.2), “A integração da TI aos negócios faz com que a área de TI se torne parceira estratégica. As decisões sobre os investimentos em TI são tratadas nas reuniões de  planejamento estratégico pelo conselho administrativo da empresa. A TI deixou de ser tratada por técnicos e passou a ser incorporada na estratégia da empresa para alcançar seus objetivos.”.

Dentro do tema proposto a governança norteará o trabalho, já que ela fornece a base  para garantir a qualidade nas atividades atividades desempenhadas desempenhadas por qualquer qualquer equipe de de TI. Para atender aos critérios estabelecidos pela governança, faz-se necessário o uso de um framework  de  de boas práticas como, por exemplo, o ITIL. 2.2  Framework  ITIL  ITIL Os frameworks são esquemas, bibliotecas e abstrações fornecendo possíveis soluções  para um determinado determinado problema. Essas Essas estruturas genéricas genéricas podem ser definidas como: “[...] uma abstração de um domínio de aplicações, a ser especializada em aplicações deste domínio. A principal característica buscada ao desenvolver um  framework  é a generalidade em relação a conceitos e funcionalidades de domínio tratado. Além disto, é fundamental que a estrutura produzida apresente as características flexibilidade e extensibilidade.” (SILVA; PRICE, 1998).

O ITIL é uma biblioteca desenvolvida a partir de pesquisas realizadas por consultores, especialistas e doutores e que serve de referência das melhores práticas de gestão de infraestrutura de TI para empresas públicas e privadas. Foi criada, nos fins dos anos 80, pelo

16

Office of Government Commerce

(OGC), órgão do governo britânico responsável por manter

os livros que compõem o seu  framework . Atualmente está em sua terceira versão, agrupados em cinco volumes (FILHO, 2012, p. 3-4). O ITIL tem um paradigma orientado a serviços, o que significa que toda a relação de TI com as áreas de negócio podem ser mapeadas, definindo políticas, estratégias e aplicando melhorias contínuas (FILHO, 2012, p. 9). Neste contexto, o gerenciamento da TI é baseado em um conjunto de processos (boas práticas), que serão responsáveis pelo bom funcionamento da TI e das atividades na qual dão suporte. O objetivo do uso do ITIL está em aumentar a eficiência da área de TI dentro do negócio, maximizando a produtividade e consequentemente garantindo o  Return On  Investment  (ROI).  (ROI). Além disso, a aplicação do padrão na organização traz consigo o Value On  Investimento (VOI),

pois acaba impactando na melhoria dos processos que envolvem toda a

organização. Para isso ele conta com algumas técnicas de controle, que são as mensurações e auditorias gerenciais, guiando as operações a andarem no ritmo que a organização necessita (OGC, 2007a, p. 132-140). Uma característica intrínseca que qualifica o uso do ITIL nesta pesquisa é que ele pode realizar a rastreabilidade dos processos que são gerenciados por ele. Isso assegura que o mesmo pode sofrer uma otimização para se adequar a necessidade da organização, podendo até mesmo, restaurar formas anteriores de trabalho caso se identifique alguma falha posterior. Rastreabilidade, segundo a norma NBR ISO 8402 é, “[...] capacidade de recuperação do histórico, da aplicação ou da localização de uma entidade [...] por meio de identificações registradas.” (ABNT, 1994, p. 7). É o poder de identificar todos os passos que foram realizados até o estado atual, de forma que o processo possa ser restaurado a partir de qualquer ponto de restauração previamente identificado. É fundamental garantir o funcionamento de uma infraestrutura de TI confiável e mais adaptável as necessidades da empresa, através dos modelos de processos do  framework  ITIL.   ITIL. Eles ainda enfatizam que o ITIL possui uma excelente orientação para o ciclo de vida de um serviço de TI. Porém, sua implementação nas organizações acaba se tornando uma tarefa árdua, sendo necessário desenvolver procedimentos e ferramentas que se encaixam na aplicação do processo, tornando-o prático e eficaz (AIELLO; SACHS, 2014). Como o foco do trabalho está na definição de um método que garanta, de forma  padronizada e ágil, a recuperação de serviços de TI T I acometidos por um evento desastroso, se fez necessário explorar as definições e recomendações, que são encontradas na Gerência de Continuidade de Serviço de TI. Também foram avaliados os conceitos contidos na Gerência

17

de Configuração, pois ela trata de fornecer informações atualizadas sobre os ativos de TI (hardware, software, licenças, entre outros) em uso. 2.2.1 Gerenciamento de continuidade de serviços de TI De acordo com a OGC, a continuidade de serviço de TI trata da capacidade de análise de risco e recuperação de componentes essenciais para os serviços de TI, depois de ocorrido um evento de desastre como, por exemplo, falha de hardware, incêndios, enchentes, terrorismos, tempestades, vandalismos, blackouts e apagões. Suas ações devem dar suporte e ser planejadas acompanhando o gerenciamento de continuidade do negócio (OGC, 2007b, p. 125-132). Esta gerência está descrita na ITIL dentro de um domínio maior chamado de Desenho de Serviço. Segundo a OGC, trata de um modelo que enfoca os elementos de processos envolvidos em identificar e introduzir aprimoramentos ao gerenciamento de serviços. São voltados para atividades repetíveis, direcionando as organizações a aprenderem a perceber melhorias incrementais na qualidade de serviço. Além disso, oferece suporte a TI para se adaptar a partir de qualquer planejamento que a empresa tome como direção (OGC, 2007b, p. 16-26). Importante salientar a diferença entre desastre e incidente, o qual é abordado por outro  processo do ITIL e que não faz parte desde estudo. O incidente se trata de paralisações temporárias ou queda da qualidade de serviço, não impactando obrigatoriamente em toda instituição (OGC, 2007c, p. 86). Já o desastre é muito mais grave, pois trata da perda da capacidade de se manter as atividades da empresa funcionando (OGC, 2007c, p. 126). Outro conceito a ser esclarecido é que a continuidade se difere do processo de disponibilidade, o qual trata como manter o serviço sempre ativo e que atenda as necessidades atuais e futuras do negócio. negócio. (OGC, 2007c, p. 97). Sendo assim, este este trabalho se concentra concentra em dar uma resposta aos riscos previamente identificados com o desenvolvendo de estruturas automatizadas de retorno que garantam a continuidade dos serviços. Segundo o plano de continuidade de serviços de TI descrito pelo ITIL, as perdas que as empresas sofrem com o acontecimento de desastres, devem ser analisadas avaliando os impactos que são gerados ao negócio. Estes serviços precisam ser priorizados tendo como referência as atividades mais vitais. Em seguida deve ser feito a análise dos riscos, pontuando as possíveis ameaças, que são descritas em suas vulnerabilidades, efeitos e contra medidas. Sendo que de posse dessas informações é necessário definir as estratégias de continuidade do

18

negócio, com as ações que devem ser tomadas mediante o acontecimento do desastre, garantindo os requisitos mínimos de operação. Em outras palavras essas etapas vão definir o  plano de ação ação que deve ser ser seguido para para retomar as operações operações (OGC, 2007b, 2007b, p. 128-137). A implementação das medidas para minimizar os impactos devem seguir a orientação do plano de ação e realizar testes simulados para evitar que os serviços restaurados não deixem de atender os requisitos mínimos para o seu funcionamento. Outro enfoque que deve ser feito é a otimização do tempo de recuperação. Quanto menor o prazo de retorno, menos a empresa arcará com prejuízos. Indiretamente isso pode levantar a necessidade de rever os  prazos acordados acordados nos níveis de serviço (SLA). Uma das saídas que podem ser encontradas para auxiliar a retomada de operações descritas na continuidade de serviço e que são abordadas por esse trabalho, são os processos automatizados. 2.2.2 Gerenciamento de Configurações Configurações e Ativos de Serviço O processo de gerenciamento de itens de configuração é um processo que pertence a fase de transição de serviço.  Neste processo são administrados os itens de configuração dos serviços. São considerados considerados itens de configuração, entre outros: 



equipamentos;  softwares;



configurações (setup);



relação entre itens de configuração;



os próprios serviços.

Este processo tem sua importância por manter o inventário e os históricos sobre cada item de configuração, permitindo que se possam guardar informações sobre todos os componentes utilizados pela TI. Sendo assim, a maioria dos processos de gerenciamento do ITIL, recorrem à base de dados da gerência de configuração (BDGC) (OGC, 2007d, p. 65-84). Em ambientes automatizados que seguem o  framework   ITIL o status dos itens de configuração são atualizados automaticamente, através de testes automáticos feitos via rede,  por exemplo, utilizando o sistema NAGIOS. Desta forma pode-se consultar quais itens de configuração estão fora de produção, e consequentemente o impacto causado nos outros itens.

19

Alguns autores (KOLSMIN, 2012; GALUP et al., 2007) indicam a necessidade de automatizar o monitoramento de itens de configuração como servidores, switches, roteadores, visando produzir alertas de disponibilidade e principalmente de continuidade, por estar associado à problemas mais graves. 2.3

DevOps O termo “DevOps”, nada mais é do que uma fusão das palavras Desenvolvedor e

Operações e foi popularizado através de uma série de eventos chamados “DevOps Days”, iniciados na Bélgica em 2009. Seus idealizadores propõe uma nova abordagem de trabalho,  buscando automatizar o máximo possível os processos e quebrar as barreiras existentes entre os setores de uma mesma empresa. Garantindo o aumento da colaboração entre as equipes na troca de experiências e no compartilhamento de ferramentas. A ideia é não perder tempo com questões operacionais e rotineiras, dessa forma, os profissionais estarão focados na busca de soluções em suas respectivas áreas, promovendo o papel que os gestores e demais colegas realmente esperam que eles desenvolvam desenvolvam (DEVOPS, 2010). Sua necessidade se mostrou mais aparente com o surgimento e aplicação das Metodologias Ágeis no trabalho das equipes de desenvolvimento, na qual aumentou a demanda por deploys, que passaram a ser mais frequentes (entrega contínua). O que acabou revelando um gargalo na publicação, área essa de responsabilidade da equipe de infraestrutura. Isso mostra claramente que as equipes evoluem em ritmos diferentes e a falta de comunicação e contribuição entre elas é muito grande. Com essa visão de integração dos times, o DevOps auxilia no gerenciamento e lançamento de novos produtos, isso porque o  processo pode ser totalmente automatizado e existe suporte maior para publicação. publicação. Existe ainda o benefício do processo ter que ser padronizado para que um número maior de envolvidos interajam (SATO, 2013, p. 4-6). Metodologia ágil é “[...] uma nova forma de gestão e desenvolvimento de  software que usa uma abordagem de planejamento e execução iterativa e incremental voltado para  processos empíricos [...]” (STEFFEN, 2012), aproximando o time de desenvolvimento ao de negócios e que separa o produto em pequenos problemas, de modo que, seja possível entregar continuamente partes funcionais. Possui outras características como: a comunicação  face-to face;

redução dos riscos associados às incertezas dos projetos; abraçar e responder às

mudanças de forma mais rápida e natural, com intuito de atender da melhor forma as expectativas dos clientes, por meio da adoção de práticas de gestão e de Engenharia de

20

Software 

com foco nos valores e princípios do Lean (sistema Toyota de produção)

(STEFFEN, 2012). Seu principal objetivo é entregar um produto que o cliente realmente deseja, usável (mesmo que a entrega seja de uma pequena parte) e que tenha garantia de qualidade. Com DevOps os eventos podem ser monitorados com maior clareza, do mesmo modo que facilita a gerência dos processos e geração de relatórios granulares. O desenvolvedor ganha maior autonomia em relação ao ambiente que hospeda os serviços, e a infraestrutura maior compreensão sobre as aplicações que ele administra. Mesmo que já exista previamente alguma parte do processo já automatizado, essas rotinas muitas vezes não tem uma flexibilidade desejada, pois possuem implementações muito amarradas e dependentes de outras estruturas. “Empresas que aplicaram essas práticas de DevOps com sucesso não enxergam mais o departamento de TI como um gargalo, mas sim como um agente de capacitação do negócio.” (SATO, 2013, p. 6). Os principais fundamentos DevOps extraídos de seu manifesto podem ser expressos de forma resumida (DEVOPS, 2010): 

Avaliação: são as métricas, medições, verificação de performance, logs e integração;



Automação: facilitar os processos repetitivos no deploy, controle, monitoração, gerência de configuração e orquestração;



Compartilhamento: assuntos relacionados a  feedback   e comunicação entre a equipe.



Cultura: envolve colaboração, fim das divisões, relação saudável entre as áreas e mudança de comportamento;

Dentre as características citadas, as de comunicação entre a equipe, colaboração e automação foram as mais utilizadas na aplicação do estudo de caso. 2.3.1 Automatização de Processos de Infraestrutura de TI O termo automatização remete aos conceitos industriais baseados em máquinas com a capacidade de executar e controlar tarefas em sequência sem a intervenção humana (KUIAWINSKI; LUZ, 2006). Seguindo essa linha, a automatização da infraestrutura de TI  pode ser compreendida como um processo de planejar e descrever instruções para serem

21

tratadas por um  software  de gerência de configuração, responsável por interpretá-las e executá-las. O  script  tem  tem a capacidade de conter comandos desde a instalação de um sistema operacional até executar complexas configurações para prover um serviço. Portanto a infraestrutura de TI e sua configuração serão descritas como um conjunto de  scripts, para que os ambientes sejam reproduzidos de forma menos propensa a erros. Apesar dos conceitos DevOps não estejam exclusivamente ligados a ideia do uso de ferramentas para solucionar os problemas, elas acabam fazendo boa parte do trabalho. Basicamente para construir uma infra ágil é necessário combinar 3 tipos de ferramentas: orquestradores, que invocam ações em tempo real em servidores distintos; gerenciadores de configuração, que facilitam a administração e criação de novos ambientes além de centralizar as informações; provisionamento, que ajudam na instalação dos sistema operacionais tanto em ambientes físicos quanto virtuais. Como o estudo se tornaria muito grande analisando cada tipo de ferramenta, os esforços foram concentrados em uma que atendesse a gerência de configuração, já que ela demonstraria melhor os impactos dentro da continuidade de serviço.  Na pesquisa realizada, foram encontradas algumas ferramentas que seguem o  propósito DevOps, no que diz respeito a dar suporte à automação da infraestrutura de TI,  podendo ser aplicadas em ambientes ambientes na nuvem, nuvem, virtuais ou físicos. Entre Entre elas estão: 

Ansible (ANSIBLE, 2016): Os seus parâmetros são definidos para um grupo de hosts.

Sua comunicação é feita através de SSH, o que dispensa a necessidade de

agentes. Escrito em Python e utiliza o YAML (é um tipo de codificação de dados mais legível para seres humanos) para descrição das configurações. Disponível na versão Tower  e  e Community; 

Chef (CHEF, 2016): Modelo cliente servidor, que utiliza agentes nos hosts para aplicar as configurações. Seus códigos são descritos em forma de recipes  e são agrupadas em cookbooks, utilizando a linguagem Ruby e uma DSL própria. Disponível na versão  Enterprise e Community;



Puppet (PUPPET, 2016): Modelo cliente servidor, que utiliza agentes nos hosts  para aplicar as configurações. Possui linguagem própria e foi desenvolvido em Ruby. Disponível na versão  Enterprise e Community;

Para o estudo de caso, foi adotado o Puppet, pelo fato de ser um  software que possui uma boa documentação e uma comunidade ativa que sempre disponibiliza atualizações e novos módulos. Sua instalação é muito simples, tanto do servidor quanto dos agentes que são executados nos clientes. Outro ponto que influenciou sua escolha está na declaração das

22

instruções utilizando sua linguagem específica de domínio (DSL). Por ser muito intuitiva, ela acaba sendo de fácil interpretação para os administradores de sistema, sendo diferente, por exemplo, da utilizada pelo Chef (outra ferramenta similar), na qual sua escrita é mais apropriada para programadores. programadores. O Puppet foi escrito em Ruby e distribuído como um  software  livre sob a Licença Pública Geral (GPL) pelos seus criadores. Nele é possível automatizar todos os passos do  processo de entrega de  software, desde o provisionamento de máquinas físicas e virtuais para orquestração até relatórios (PUPPET, 2016). Resumidamente, o Puppet é uma ferramenta de automatização de gerência de configuração. Funciona utilizando um servidor principal (Puppet Master), que centraliza as configurações (facts) entre os servidores (nodes) e os organiza pelo tipo no seu repositório (catalog). O seu agente (Puppet Agent) é executado como um processo independente nos clientes, permitido implementar mudanças de infraestrutura em vários nós ao mesmo tempo. O fato que mais marcou com a chegada das ferramentas trazidas com o movimento ágil foi, literalmente, tratar a infraestrutura como um código. Como se trata de textos e instruções similares aos escritos para desenvolver qualquer programa de computador, eles  podem ser editados, versionados, testados e otimizadas a qualquer momento (COYNE; SHARMA, 2015, p. 25). Criar um servidor, desde a instalação do sistema operacional,  passando pela configuração dos seus serviços, até sua publicação, publicação, é um trabalho muito dispendioso, ainda mais sendo feito manualmente, inserindo mídias, copiando arquivos e executando instruções. Em contra partida, criar o mesmo servidor, com as mesmas características através de uma chamada por linha de comando ou automaticamente ativadas  por algum evento, torna o trabalho muito mais eficiente. Desta maneira a infraestrutura se torna muito mais flexível, escalável e sem a necessidade de acréscimos de pessoal. De maneira geral o objetivo dessas ferramentas é liberar tempo para os profissionais se dediquem em projetos que oferecem mais valor de negócio, garantir a coerência, fiabilidade e estabilidade e Facilitar a colaboração mais estreita entre os administradores de sistemas e desenvolvedores.

23

3

ESTUDO DE CASO  Neste capítulo será descrito descrito o ambiente do estudo de caso, caso, o processo atual e a solução

encontrada, provando provando que a implementação é mais confiável e eficaz. O estudo analisou o processo de trabalho que é realizado em uma instituição municipal governamental que provê serviços de tecnologia para os demais órgãos ligados a sua organização. A fim de mapear os processos mais críticos de provisionamento de ambientes e aplicar conceitos e ferramentas DevOps para otimizar a produtividade na recuperação de um serviço.

3.1

Ambiente do estudo de caso O Centro de Informações de Dados de Campos (CIDAC) é uma superintendência da

Prefeitura Municipal de Campos dos Goytacazes responsável pela área de tecnologia de informação. Suas principais atribuições vão desde a elaboração de políticas de tecnologia de informação, passando por serviços de geoprocessamento, elaboração de termos técnicos, desenvolvimento desenvolvimento de solução de  software e a distribuição do link  de  de internet para os principais órgãos municipais por meio de um anel de fibra óptica. Sua principal função é descrita em sua missão: “Prover soluções tecnológicas de informação e comunicação integradas e inovadoras  para uma gestão pública eficiente e colaborativa, colaborativa, que reflitam na melhoria de vida da cidade e dos cidadãos.” (PMCG, 2016). O CIDAC dispõe de um corpo técnico de 10 analistas, sendo que 7 atuam na equipe de desenvolvimento, criando soluções de  software  e 3 trabalham na equipe de infraestrutura, garantindo o funcionamento de toda a rede de dados e configuração dos servidores. A instituição possui uma sala  site  própria para processamento de dados bastante heterogênea, composta por 13 servidores físicos e 35 servidores virtuais com diferentes sistemas operacionais. Esta estrutura é responsável por oferecer diversos serviços de TI, em que muitas dessas aplicações são desenvolvidas pelo próprio órgão, destacando as ilhas de  produção utilizando utilizando as linguagens linguagens de programação programação PHP e Rails. Dentre toda essa estrutura, foi selecionado para estudo, o ambiente de produção dos sistemas feitos com Rails, que é um  framework  para   para desenvolvimento de  software  (RUBY ON RAILS, 2016). Esta escolha é atribuída ao fato f ato de que existem mais profissionais atuando

24

com a linguagem dentro da instituição e que frequentemente são lançadas novas versões para as aplicações, além de envolver o uso de 5 servidores em sua infraestrutura de funcionamento. 3.2

Sobre o problema Serão descritos a seguir os problemas relacionados ao provisionamento e restauração

de ambientes produtivos de infraestrutura de TI, mapeados nesse estudo, para propor  possíveis melhorias na continuidade de serviço. O levantamento dos dados referentes aos eventos foi feito através de entrevistas aos integrantes das equipes, isto porque o órgão não mantem uma base de conhecimento e nem registros históricos de desastres. A equipe de infraestrutura é responsável diretamente pelo provisionamento dos ambientes e serviços. No entanto, necessita de 2 analistas da equipe de desenvolvimento, os quais são os únicos que conhecem todos os passos para construir novos ambientes Rails. Esses analistas também possuem autonomia para alterar as configurações desses servidores. Contudo, as mudanças que ocorrem no ambiente não são rastreáveis, o que dificulta identificar se alguma atualização ou configuração impactou no bom funcionamento dos sistemas. As configurações são realizadas manualmente e com pouca frequência. Dessa forma, existe o risco de algumas instruções serem esquecidas, gerando ambientes defeituosos e que  precisam ser corrigidos. Impactando Impactando na disponibilização do serviço em produção rapidamente. Este tipo de risco, decorrente de falha humana, foi identificado nos últimos eventos realizados pelos profissionais responsáveis pela restauração do serviço. Estas questões influenciam negativamente no tempo de recuperação e na qualidade do ambiente após um evento de desastre. As falhas mais recorrentes identificadas são as quedas de energia. Porém, as que causaram maior impacto foram as ocasionadas por falha de hardware  nos servidores,  paralisando totalmente a operação dos serviços da instituição. Em um desses eventos desastrosos, podemos destacar um serviço que levou três dias para ser restabelecido. O agravante se deu pelo fato de se tratar de um servidor que hospedava uma aplicação de tramitação de documentos que envolvia toda organização. O tempo foi elevado porque a equipe não possuía informações suficientes para instalar e configurar o serviço em outro equipamento, mesmo de posse dos arquivos de backup. Além paralisar o trabalho dos servidores públicos, a falha impediu indiretamente o atendimento aos cidadãos.

25

Partindo destes problemas, serão descritos a seguir os métodos e soluções desenvolvidas para minimizar o esforço de recuperação de serviços para esse estudo de caso. 3.3

Procedimentos Este trabalho não seria possível sem a união das concepções de governança governança e DevOps,

sendo que a parte que cabe à governança é: “o que fazer”, e para o DevOps a incumbência é: “como fazer”. Os procedimentos aplicados ao estudo de caso para alcançar os objetivos deste trabalho são descritos seguindo a metodologia: (I) Inicialmente foi feito a escolha do ambiente. Foram selecionados ambientes que sofrem frequentes modificações nas configurações e que geram risco ao negócio em caso de falhas. Outro fator levantado em conta foi a verificação da frequência com que ocorre a indisponibilidade. A avaliação foi executada em conformidade com o  framework  ITIL   ITIL no que se diz respeito a continuidade de serviço. (II) A próxima etapa teve como objetivo contabilizar o tempo médio gasto para concluir as configurações e o período de indisponibilidade dos serviços escolhidos no item anterior. A contagem considerou o tempo total para preparar e restabelecer um ambiente da forma habitual. (III) No terceiro passo foi aplicado o método dedutivo com auxílio do  framework  ITL   ITL  para identificar a existência de rastreabilidade das mudanças que foram realizadas no ambiente produtivo. Foi verificado também se era possível restaurar um serviço no mesmo estado em que se encontrava antes de ocorrer a indisponibilidade ou catástrofe. A execução desta etapa foi importante para descrever com mais precisão o estudo de caso. (IV) Após a identificação da rastreabilidade foi selecionado as características da cultura DevOps que melhor se adequam aos objetivos propostos nesta temática. Foi escolhida uma ferramenta, que proporcionasse maior facilidade e velocidade na adoção da metodologia, de modo que, pudesse interagir diretamente com a infraestrutura de serviços de TI. (V) A quinta etapa se caracterizou em contabilizar o tempo gasto para instalar ou restaurar um serviço após aplicar a metodologia. Este procedimento foi executado mais de uma vez em um serviço construído para simular a queda do ambiente produtivo, o qual foi selecionado nas etapas anteriores. (VI) De posse de todas as informações coletadas foi verificado se a forma de trabalho sugerida pelo DevOps garantiu a continuidade do serviço. Analisaram-se os resultados

26

extraídos antes da utilização da metodologia, comparando-os com os resultados obtidos após o experimento. (VII) Além disso, foi analisado se a equipe poderia ficar mais confortável e segura  para realizar suas atividades atividades com qualidade, qualidade, e apresentar um melhor desempenho desempenho para atender à área de negócio. (VIII) O estudo de caso foi finalizando com a descrição da experiência obtida, revelando os seus resultados. 3.4 Solução Implementada  Nesta etapa do trabalho foram utilizadas duas características importantes da metodologia DevOps para desenvolver a solução do problema: a colaboração entre as equipes e a automatização de atividades repetitivas. Além disso, serão combinados a elas os direcionamentos do framework  ITIL.  ITIL. A colaboração entre as equipes foi primordial na elaboração da solução,  principalmente dos profissionais diretamente envolvidos no problema estudado. A equipe de infraestrutura forneceu informações sobre segurança da informação e componentes responsáveis pela operação do ambiente produtivo. Os detalhes técnicos e peculiaridades referentes ao uso do Rails na instituição foram identificados e obtidos com o setor de desenvolvimento de  software. Todos os elementos foram organizados e estruturados para entender o que é necessário para o provisionamento adequado do ambiente e implantação do serviço. A automatização do procedimento de instalação do ambiente produtivo é um componente essencial neste processo. Então, as especificações do serviço foram transformadas em instruções, conforme o Apêndice – Código fonte de implementação do Puppet, possibilitando o ganho de velocidade da equipe.  No experimento foram utilizadas duas máquinas virtualizadas, sendo uma delas o servidor Puppet Master, que contém o código com as definições do ambiente e a outra é a máquina com o agente Puppet e que recebeu r ecebeu as configurações (PUPPET, 2016). Com o intuito de simplificar o laboratório, a máquina alvo já possuía um sistema operacional Linux instalado, dispensando o uso de uma ferramenta de orquestração. O motivo  pelo qual se utilizou a virtualização no trabalho foi para simular com mais facilidade as situações de desastre.

27

 Na simulação, a máquina alvo, que possui o serviço Rails implementado, teve sua instância destruída para emular os efeitos de um desastre. A partir deste momento, foi iniciado o processo de restauração, aguardando o servidor Puppet aplicar automaticamente as configurações pré-estabelecidas. Esta ação foi realizada diversas vezes para analisar o ambiente resultante e coletar informações sobre a aplicabilidade do método e seu tempo de resposta. Uma vez que a prova de conceito de uma recuperação e provisionamento automático foi desenvolvida através da ferramenta, avaliou-se a contribuição das características da metodologia DevOps, que foram citadas no início deste tópico, para alcançar os objetivos do gerenciamento gerenciamento de continuidade de serviço descritos neste trabalho. Os resultados obtidos pela solução são explicados na próxima seção. 3.5

Resultados A construção de um ambiente de produção para aplicações Rails através de um

 processo automatizado com uma ferramenta DevOps gerou resultados satisfatórios e serão apresentados neste tópico. Com o auxílio do Puppet na recuperação do ambiente não houve interrupções interrupções no fluxo de trabalho. Diferente do que se percebeu na análise do cenário original, na qual a execução manual acabou tendo algumas interrupções e desvios de mão de obra para atender outras atividades distantes do propósito inicial. Durante todas as simulações automatizadas, a ferramenta seguiu rigorosamente todas as etapas do procedimento. Os pacotes necessários foram instalados, verificou as dependências e aplicou as configurações que foram definidas. Ou seja, todo ambiente de  produção provisionado dessa forma adquiriu todas as especificações que foram determinadas. Por outro lado, a execução manual do procedimento resultou em um ambiente de produção diferente em cada simulação. Isto aconteceu mesmo sendo realizado pela mesma pessoa, o que significa que o procedimento foi interpretado de forma distinta a cada iteração. A intervenção manual na recuperação do serviço apresentou variações na execução, seja por esquecimento ou interpretação equivocada em algum dos passos do procedimento, enquanto o processo automatizado não gerou erros, o que torna a segunda abordagem mais eficaz. Em outras palavras, eliminou este ponto fraco no processo, entregando um serviço confiável.

28

Outra preocupação do gerenciamento de continuidade é o tempo de recuperação do serviço. Este item também obteve um resultado interessante, porque foi possível reduzi-lo significantemente. Enquanto que a realização manual de todos os passos do procedimento dura em torno de 150 minutos, na ferramenta a situação foi bem diferente, a conclusão da rotina gastou cerca de 3 minutos, cumprindo com mais facilidade os prazos. Além disso, contribuiu para uma futura revisão do SLA S LA estipulado para esse serviço. Os testes da estrutura de recuperação do serviço é uma atividade da gerência de continuidade que também foi possível trabalhar melhor. A partir do momento a rotina passou a ser executada com mais facilidade em um espaço de tempo bem menor, a frequência dos testes do plano de contingência foi ampliada e os seus resultados podem ser obtidos a qualquer momento. O fato da ferramenta que automatiza a gerência de configuração versionar os códigos da estrutura, possibilitou rastrear e garantir que a infraestrutura retornasse para o ponto desejado. Conforme descrito no tópico anterior, os conhecimentos das pessoas pessoas que participam do  processo atual foram previamente mapeados através da metodologia DevOps e consolidados no mecanismo de automatização. Isto permitiu que a rotina adquirisse condições suficientes  para executar todo processo com menos dependência dependência das pessoas, o que implicou em um número reduzido de profissionais envolvidos para recuperar o serviço após um desastre. Os resultados dos testes podem ser apresentados de forma resumida no Quadro 1.

29

Quadro 1 - Comparativo de resultados em caso de falhas no ambiente produtivo

Descrição

Antes da implementação

Após implementação

(Processo Manual)

(Processo DevOps)

Rastreabilidade e

As mudanças não podem ser

As mudanças nas

Versionamento

rastreadas nem versionadas.

configurações são versionadas versionadas o que possibilita a restauração do serviço a  partir do ponto desejado desejado (infraestrutura como código).

Tempo de recuperação

Alto podendo chegar a Muito Muito baixo. Possibilidade

Muito Baixo: < 30min.

Alto se o especialista não

Baixo: < 60min.

estiver presente.

de redução do SLA.

Moderado: 61min. < 120min. Alto: 121min. < 360min. Muito Alto: > 361min.

Conhecimento da equipe

Muito Ruim. Poucos sabem

Bom. Mais membros

(membros que sabem restabelecer

restabelecer o ambiente. Na

conhecem o processo de

o serviço)

ausência dos especialistas o

restauração, restauração, já que o

trabalho é interrompido.

 processo é simplificado com

Muito Ruim: 0% até 25%. Ruim: 26% 49%

auxílio de uma ferramenta.

Bom: 51%. < 75%. Excelente 76% < 100%.

Padronização

Pouca Padronização. Mesmo

Padronização Moderada. Só

Ausente: processo manual

os passos sendo descritos por

existe uma maneira de

realizado aleatoriamente.

um script  detalhado,  detalhado, o

executar a restauração, mas o

 processo não tem garantias.

 processo necessita ser

Moderada: processo automatizado,

Pode haver modificações dos

iniciado e acompanhado por

assistido por um operador.

 passos por quem quem implementa. um operador.

Pouca: processo manual que segue  passos descritos em um modelo. modelo.

Alta: sem a intervenção humana.

Confiabilidade do ambiente

Alto Risco. Os resultados

Baixo risco. Os resultados

Baixo Risco: apresenta sempre os

 podem não ser os mesmos

são previamente testados e

mesmos resultados.

desejados pelo negócio por

garantidos por um processo

se tratar de um processo

 padronizado e automatizado.

Alto Risco: pode apresenta resultados diferentes. Fonte: elaboração própria

manual.

30

4

CONCLUSÃO Observou-se que os resultados obtidos com a implementação de algumas atividades

 preconizados pelo ITIL, através da abordagem DevOps, incrementam a qualidade, e melhoraram a continuidade dos serviços de TI, quando comparados a processos manuais. Supondo que os dois modelos confrontados seguem os mesmos passos para solução de um  problema. Dessa forma foi possível demonstrar que que o ITIL e o DevOps são compatíveis e que  juntos reduzem, significativamente, o tempo de retorno de aplicações paralisadas por algum tipo de desastre.  Nesta pesquisa, a colaboração entre as equipes e a automação de processo foram as características da metodologia DevOps que apoiaram com sucesso a implementação de uma estrutura de retorno dos serviços, minimizando os impactos causados por um desastre. Do mesmo modo que a metodologia favoreceu as atividades do gerenciamento de continuidade dos serviços de TI, sua aplicação poderia ser estudada para também reduzir o esforço em outros processos e fases do ITL. A solução implementada para o estudo de caso entregou um serviço confiável e que garante o funcionamento da área de negócio. Assim como a instituição citada na pesquisa se  beneficiou dos resultados obtidos, esta solução pode ser usada como referência por outras organizações organizações governamentais. Vale destacar também que o tema é pouco difundido entre os profissionais TI e pode ampliar os conhecimentos sobre uma mudança de cultura que elevem sua capacidade de gerenciamento gerenciamento e a facilidade de lidar com grandes estruturas de serviços de TI. Foi notado durante o experimento, o potencial da automação de processos de gerenciamento de continuidade de serviço de TI na melhoria da elaboração de planos de contingência. Possibilitando a realização de uma futura pesquisa envolvendo a integração de ferramentas de monitoramento de serviço com o processo de restauração automatizada. Ou seja, dependendo do tipo de desastre e se ele foi mapeado pelo plano de continuidade de serviço, não seria necessário acionar uma equipe de suporte, as próprias ferramentas poderiam se encarregar de restaurar os serviços.

31

REFERÊNCIAS ABNT. NBR ISO 8402: Gestão da qualidade e garantia da qualidade - Terminologia. Rio de Janeiro: ABNT, 1994. AIELLO, Bob; SACHS, Leslie. DevOps best practices: Part 3 Implement ITIL with DevOps. IBM: DevelopersWorks. Feb. 2014. Disponível em: . Acesso Acesso em: 15 nov. 2015. ANSIBLE. Overview: How Ansible works. 2016. Disponível em: . com/how-ansible-works>. Acesso em: 10 jan. 2016. CHEF. All about Chef. 2016. Disponível em: . Acesso em: 10 jan. 2016. COYNE, Bernie; SHARMA, Sanjeev. DevOps for Dummies: IBM Limeted Edition. 2. ed. Hoboken: John Wiley & Sons, Inc., 2015. DEVOPS. What is devops? The agile admin. Out. 2010. Disponível em: . admin.com/what-is-devops/>. Acesso em: 10 jul. 2015. 2015. DURVALL, Paul. Agile DevOps: Automação de infraestrutura. IBM: DevelopersWorks. Out. 2012. Disponível em: . Acesso em: 16 nov. 2015. FILHO, Felício Cestari. ITIL v3 Fundamentos. Escola Superior de Redes: Rio de Janeiro, 2012. Disponível em: . Acesso: 19 dez. 2015. GALUP, S.; QUAN, J.J.; DATTERO, R. & Conger, S. “Information technology service management: an emerging area for academic research and pedagogical development” Proceeding do SIGMIS CPR '07. Conference on Computer personnel research: The global information technology workforce. ACM New York, NY, USA. p. 46-52. 2007. KOSMIN, Adam.  Puppet and nagios: a roadmap to advanced configuration . Linux  Journal , v. 2012, n. 216. 2012. KUIAWINSKI, Darcí Luiz; LUZ, Gilberto Barbosa. Mecanização, Autonomação e Automação – Uma Revisão Conceitual e Crítica. In SIMPÓSIO DE ENGENHARIA DE

32

PRODUÇÃO, 13., 2006, Bauru. Disponível em: . Acesso em: 12 de jan. j an. 2016. LUNARDI, Guilherme Lerch. Um estudo empírico e analítico do impacto da Governança de TI no desempenho organizacional. 2008. Tese (Doutorado em Administração) – Universidade Federal do Rio Grande do do Sul, Porto Alegre, 2008. Disponível em: . 1>. Acesso em: 01 de fev. 2016. INSTITUTO BRASILEIRO DE GOVERNANÇA CORPORATIVA (IBGC). Governança Corporativa. São Paulo: Paulo: IBGC, 1995. Disponível em: . Acesso em: 03 de fev. 2016. IT GOVERNACE INSTITUTE (ITGI). Board briefing on IT governance. 2. ed. Rolling Meadows: ITGI, 2003. Disponível em: ;. Acesso em: 29 jan. 2016. MUELLER, Ernest. Ernest. A DevOps DevOps Manifesto. Manifesto. The agile agile admin. Out. 2010. Disponível em: . ops-manifesto>. Acesso em: 10 jul. 2015. OFFICE OF GOVERNMENT COMMERCE (OGC). ITIL: Continual Service Improvement. Londres: TSO, 2007.  _______. ITIL: Service Service Design. Londres: Londres: TSO, 2007.  _______. ITIL: Service Service Operation. Londres: Londres: TSO, 2007. 2007.  _______. ITIL: Service Service Transition. Londres: Londres: TSO, 2007. 2007. PREFEITURA MUNICIPAL DE CAMPOS DOS GOYTACAZES (PMCG). Superintendência do Centro de Informações de Dados de Campos. Missão, Visão e Valores. 2015. Disponível em: . -visao-e-valores/>. Acesso em: 10 out. 2015. PUPPET. What is Puppet?. 2016. Disponível /puppet/what-is-puppet>. /puppet/what-is-puppet>. Acesso em: 14 mar. 2016.

em:


RUBY ON RAILS. Rails. Disponível em: . Acesso em: 15 fev. 2016.

33

SATO, Danilo. DevOps na prática: entrega de software confiável e automatizada. São Paulo: Casa do Código, 2013. SILVA, Ricardo P; PRICE, Roberto. T. “A busca de generalidade, flexibilidade e extensibilidade no processo de desenvolvimento de frameworks orientados a objetos”. In: WORKSHOP IBEROAMERICANO DE ENGENHARIA DE REQUISITOS E AMBIENTES DE SOFTWARE, (IDEAS), 1998, Instituto de Informática/UFRGS, v.2, 1998,  pp. 298-309, Torres, Rio Grande do Sul. Disponível em: .  publications/Ideas98.PDF>. Acesso Acesso em: 11 jan. 2016. 2016. STEFFEN, Juliana Berossa. O que são essas tais de metodologias ágeis?. IBM: DevelopersWorks. Jan. 2012. Disponível em: .  _a1geis?lang=en>. Acesso Acesso em: 09 set. 2015. 2015.

34

APÊNDICE A – Código fonte de implementação do Puppet

# Configuração para montagem de Servidor Rails node "puppetnode01" {

# Removendo pacotes desnecessarios $packages_to_remove $packages_to_remove = ['bsd-mailx', ['bsd-mailx', 'exim4', 'exim4base', 'exim4-config', 'exim4-daemon-light', 'exim4-daemon-light', 'mutt', 'procmail'] package { $packages_to_remove: $packages_to_remove: ensure => 'purged', }

# Instalando pacotes para suporte. $admin_packages

=

['vim',

'htop',

'ntpdate', 'curl'] package { $admin_packages: $admin_packages: ensure => 'present', }

# Pacotes necessarios para o rails package { 'libpq-dev': ensure => 'present', }

# Instando e configurando o monit package { 'monit': ensure => 'present', }

service { 'monit': ensure

=> 'running',

enable

=> true,

'nmap',

'tcpdump',

35

require => Package['monit'], Package['monit'], }

file { 'rails.conf': path

=> '/etc/monit/conf.d/rails. '/etc/monit/conf.d/rails.conf', conf',

owner

=> 'root',

group

=> 'root',

mode

=> '0700',

content => 'include /home/deployer/apps/*/shared/ /home/deployer/apps/*/shared/ config/monit', require => Package['monit'], Package['monit'], notify

=> Service['monit'], Service['monit'],

}

# Adicionando usuario responsavel pelas aplicacoes user { 'deployer': ensure

=> 'present',

managehome => true, home

=> '/home/deployer', '/home/deployer',

password

=>'$6$PNPiIH1m$3C8IoXlML4MTwupA3cQfiPeVf

fkkDH2JRrWWfeNWfYN.CnHWt1bL fkkDH2JRrWWfeNWfYN.CnHWt1bLlj1qKebg1Bh12 lj1qKebg1Bh12Fk4Z3Cr0zub Fk4Z3Cr0zub TxPYgZtNo1', shell

=> '/bin/bash',

uid

=> '1001',

}

file { '/home/deployer/apps': '/home/deployer/apps': ensure => 'directory', owner

=> 'deployer',

group

=> 'deployer',

mode

=> '0755',

require => User['deployer'], User['deployer'], }

36

# Instalando o rvm exec { 'rvm-gpg-import': 'rvm-gpg-import': command

=> 'curl -sSL https://rvm.io/mpapis.asc https://rvm.io/mpapis.asc |

gpg --import -', path

=> '/usr/local/sbin:/usr/loca '/usr/local/sbin:/usr/local/bin:/usr/ l/bin:/usr/

sbin:/usr/bin:/sbin:/bin', user

=> 'deployer',

environment => ['HOME=/home/deployer'], ['HOME=/home/deployer'], logoutput

=> true,

}

exec { 'rvm-install': 'rvm-install': command

=> 'curl -L https://get.rvm.io https://get.rvm.io | bash –s

stable', path

=> '/usr/local/sbin:/usr/loca '/usr/local/sbin:/usr/local/bin:/usr/ l/bin:/usr/

sbin:/usr/bin:/sbin:/bin', user

=> 'deployer',

environment => ['HOME=/home/deployer'], ['HOME=/home/deployer'], logoutput

=> true,

require

=> Exec['rvm-gpg-import'], Exec['rvm-gpg-import'],

}

# Instalando nginx package { 'nginx': ensure => 'present', }

service { 'nginx': ensure

=> 'running',

enable

=> true,

require => Package['nginx'], Package['nginx'], }

}