Você está na página 1de 38

INSTITUTO FEDERAL DE EDUCAO, CINCIA E TECNOLOGIA FLUMINENSE

CAMPUS CAMPOS-CENTRO
CURSO DE PS-GRADUAO LATO SENSU EM
ANLISE E GESTO DE SISTEMAS DE INFORMAO

PATREZZE DE ALVARENGA SILVA


RAFAEL NASCIMENTO GOMES

ESTUDO DE CASO DE UTILIZAO DA METODOLOGIA DEVOPS PARA ATENDER


AO PROCESSO DE CONTINUIDADE DE SERVIOS CONFORME O FRAMEWORK
ITIL

CAMPOS DOS GOYTACAZES


2016
PATREZZE DE ALVARENGA SILVA
RAFAEL NASCIMENTO GOMES

ESTUDO DE CASO DE UTILIZAO DA METODOLOGIA DEVOPS PARA ATENDER


AO PROCESSO DE CONTINUIDADE DE SERVIOS CONFORME O FRAMEWORK
ITIL

Monografia apresentada ao Instituto Federal


Fluminense, Campus Campos-Centro, como
requisito parcial para concluso do Curso de Ps-
graduao Lato Sensu em Anlise e Gesto de
Sistemas de Informao.
Orientador: M.e Fernando Carvalho

CAMPOS DOS GOYTACAZES


2016
Dados Internacionais de Catalogao na Publicao (CIP)
Biblioteca. Setor de Processos Tcnicos (IFF)

S586e Silva, Patrezze de Alvarenga


Estudo de caso de utilizao da metodologia DevOps para atender o
processo de continuidade de servios conforme o framework ITIL
/ Patrezze de Alvarenga Silva, Rafael Nascimento Gomes 2016.
36 f.: il. color.

Orientador: Fernando Luiz de Carvalho e Silva

Monografia (Psgraduao Lato Sensu em Anlise e Gesto de


Sistemas de Informao). Instituto Federal de Educao, Cincia e
Tecnologia Fluminense. Campus Campos Centro. Campos dos
Goytacazes (RJ), 2016.
Referncias: p. 31-33.

1. 1. Servio de informao - Administrao. 2. Tecnologia da


2. informao Administrao. I. Gomes, Rafael Nascimento. II.
3. Silva, Fernando Luiz de Carvalho e, orient. III.Ttulo.

CDD 658.4038
PATREZZE DE ALVARENGA SILVA
RAFAEL NASCIMENTO GOMES

ESTUDO DE CASO DE UTILIZAO DA METODOLOGIA DEVOPS PARA ATENDER


AO PROCESSO DE CONTINUIDADE DE SERVIOS CONFORME O FRAMEWORK
ITIL

Monografia apresentada ao Instituto Federal


Fluminense, Cmpus Campos-Centro, como
requisito parcial para concluso do Curso de Ps-
graduao Lato Sensu em Anlise e Gesto de
Sistemas de Informao.
Orientador: M.e Fernando Carvalho

Aprovada em 08 de abril de 2016

Banca Avaliadora:

.......................................................................................................................................................
Prof. D.r Breno Fabrcio Terra Azevedo
Doutor em Informtica na Educao - UFRGS
Instituto Federal de Educao, Cincia e Tecnologia Fluminense Campus Campos-Centro

.......................................................................................................................................................
Profa. D.ra Simone Vasconcelos Silva
Doutora em Computao - UFF
Instituto Federal de Educao, Cincia e Tecnologia Fluminense Campus Campos-Centro

.......................................................................................................................................................
Prof. M.e Fernando Luiz de Carvalho e Silva (Orientador)
Mestre em Engenharia de Produo - UENF
Instituto Federal de Educao, Cincia e Tecnologia Fluminense Campus Campos-Centro
Dedico a meus familiares e minha esposa
Gislaine, os quais sempre me apoiaram em todas
as decises difceis. Compartilho com eles a
alegria dessa conquista.
Patrezze de Alvarenga Silva

Aos meus pais, minha irm e minha namorada


que, com muito carinho dedicao, no
mediram esforos para que eu chegasse at esta
etapa de minha vida.
Rafael Nascimento Gomes
AGRADECIMENTOS

A Deus, por ter nos dado sade e fora para superar as dificuldades. A esta instituio
de ensino, seu corpo docente e discente, que proveram os meios e a estrutura necessria para
alcanar o to sonhado ttulo. Ao nosso orientador, Fernando Carvalho, pelo apoio no pouco
tempo que lhe coube, pelas suas correes e incentivos. Aos nossos pais, pelo incentivo e
apoio incondicional, e a nossas companheiras, pelo amor e presena, 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 inovaes.
Steve Jobs
RESUMO

O objetivo deste trabalho demonstrar a eficcia da utilizao de conceitos DevOps


em conformidade com as melhores prticas descritas pelo framework ITIL. Principalmente,
na gerncia de continuidade de servio de TI, no que diz respeito habilidade de restaurar
servios considerados de grande risco ao negcio. Por este motivo, foi elaborado um estudo
de caso para avaliar a automao de um processo de provisionamento de sistemas em uma
instituio pblica, em comparao ao modelo de suporte executado atravs de procedimentos
manuais. O trabalho destaca-se em trazer uma soluo simples para reduzir os problemas da
continuidade dos servios de TI. Alm disso, garantir a eficincia e flexibilidade da
infraestrutura de TI para atender grandes demandas e administrar cenrios complexos.

Palavras-chave: DevOps, ITIL, Continuidade de Servio 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 Informao

VOI Value On Investiment


LISTA DE QUADROS

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


10

SUMRIO

1 INTRODUO ................................................................................................................... 11
1.1 Objetivo ........................................................................................................................... 11
1.2 Justificativa ..................................................................................................................... 12
1.3 Metodologia .................................................................................................................... 12
1.4 Estrutura do Trabalho ...................................................................................................... 12
2 REFERENCIAL TERICO ................................................................................................ 14
2.1 Governaa de TI .............................................................................................................. 14
2.2 Framework ITIL.............................................................................................................. 15
2.2.1 Gerenciamento de continuidade de servios de TI ......................................................... 17
2.2.2 Gerenciamento de Configuraes e Ativos de Servio ................................................... 18
2.3 DevOps ............................................................................................................................ 19
2.3.1 Automatizao 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 Soluo Implementada .................................................................................................... 26
3.5 Resultados ....................................................................................................................... 27
4 CONCLUSO ..................................................................................................................... 30
REFERNCIAS ....................................................................................................................... 31
APNDICE A Cdigo fonte de implementao do Puppet .................................................. 34
11

1 INTRODUO

Este trabalho tem como tema um Estudo de caso de utilizao da metodologia


DevOps para atender ao processo de continuidade de servios conforme o framework ITIL.
A partir desta temtica foi prescrito um processo, aderente ao framework Information
Technology Infrastructure Library (ITIL), atualmente na verso 3, que proporcionou garantias
de segurana e qualidade, em um exemplo de servio de Tecnologia da Informao (TI),
mantido de forma repetitiva e manual em uma repartio pblica municipal. Juntamente ao
ITIL, foram aplicados mtodos e ferramental que seguem a linha de agilidade provenientes do
conceito DevOps, a fim de garantir uma rpida retomada das operaes aps possveis
interrupes provocadas por um desastre que paralisem parte ou totalmente o negcio.
O trabalho explora os conceitos e benefcios oriundos do manifesto DevOps que
atualmente vem ganhando mais fora pelos resultados que esto sendo obtidos no provimento
dos servios de TI, trazendo consigo uma nova forma de cooperao entre equipes de
trabalho, com o objetivo de facilitar a rotina de operaes e minimizar a interveno humana
durante o processo (MUELLER, 2010).
A questo central desta monografia : ser que tcnicas DevOps conseguem aumentar
a competncia da rea de TI atravs 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 tcnicas geis,


observadas no conceito DevOps, podem ser realmente eficientes e efetivas na garantia da
continuidade de servios de TI, trazendo os benefcios que superam o modelo de trabalho
tradicional, no que diz respeito a escalabilidade, flexibilidade e velocidade, particularmente na
rea de infraestrutura que importante e responsvel pelo provisionamento de ambientes de
forma segura e rpida. Como tambm avaliar o alinhamento dos conceitos de DevOps com
ITIL.
Prope-se utilizar e analisar uma contribuio na conduo de problemas que so
recorrentes, agindo de maneira padronizada, segura, rpida e rastrevel conforme os padres
de governana j estabelecidos no mercado. Dessa maneira possvel que questes
operacionais sejam deixadas em segundo plano, dando condies aos profissionais de TI para
12

atuarem mais livremente na criao de solues, desenvolver melhorias ou dedicados a


questes estratgicas e que sejam diferenciais para o segmento no qual atuam.

1.2 Justificativa

A relevncia deste trabalho que a rea de TI possui o desafio de manter as suas aes
e tomadas de decises sempre de acordo com o planejamento estratgico das instituies e
clientes, bem como diminuir o prejuzo e o custo com tecnologia, de modo que seja possvel
garantir o retorno sobre os investimentos.
Cabe acrescentar tambm que o tema deste trabalho no mbito do servio pblico
ainda no muito difundida. Sendo assim, o projeto aborda questes que visam melhorar os
servios de TI oferecidos por instituies pblicas para a sociedade.
A fim de solucionar as questes levantadas na introduo deste documento, foi
necessrio conduzir uma investigao sobre as tcnicas e teorias utilizadas nesta pesquisa.

1.3 Metodologia

Neste trabalho buscou-se estudar o ganho de eficincia e qualidade dos servios de TI


obtidos pela aplicao de processos apoiados pelo modelo ITIL. Tambm foi necessrio
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 em relao aos resultados encontrados ps implantao
de uma ferramenta DevOps.

1.4 Estrutura do Trabalho

No captulo 2, so feitas as correspondncias que do base ao trabalho, iniciando com


o levantamento de concepes de governana de TI, os quais permitem direcionar o trabalho
para desafios reais encontrados por empresas de todos os portes. Alm disso, os textos
destacam os benefcios da aplicao desse tipo de modelo de gesto, principalmente, para
buscar a eficincia e capacidade de adaptao a diferentes necessidades de mercado.
Ainda sobre gesto, mas com um enfoque operacional, so abordadas nos subcaptulos
seguintes as melhores prticas constatadas pelo framework ITIL, j que o seu modelo foi
13

desenvolvido para dar resposta s necessidades de governana. Alm disso, ele nativamente
aborda a problemtica da continuidade de servios de TI, oferecendo direcionamentos para
minimizar seus impactos. Houve ainda a necessidade de conceituar o gerenciamento de
configuraes e ativos de servio, j que se trata de uma gerncia que controla diretamente os
componentes fsicos e abstratos da infraestrutura de TI, os quais podem ser acometidos por
algum desastre e consequentemente afetar a continuidade do negcio de uma instituio.
No captulo 2.3 feito o levantamento dos conceitos DevOps, mostrando sua
relevncia para agilizar tarefas e aumentar a coeso dos trabalhos em equipe. No captulo
2.3.1 abordada a importncia da automatizao dos processos de infraestrutura para garantir
a padronizao dos servios prestados e rapidez na realizao das aes operacionais. Esse
tpico ainda descreve e exemplifica ferramentas DevOps com as caractersticas de facilitar a
automatizao da gerncia de configurao.
O captulo 3 trata do estudo de caso montado para avaliar a integrao do ITIL com o
DevOps, a fim de agilizar o processo de retomada dos servios interrompidos por algum
sinistro e que o ambiente recuperado atenda a continuidade do negcio. So descritos em seus
subcaptulos a descrio do ambiente estudado, os problemas encontrados, a metodologia
aplicada, as solues implementadas e os resultados encontrados.
14

2 REFERENCIAL TERICO

Para compor o estudo foi necessrio o entendimento dos conceitos de Governana de


TI, framework ITIL, DevOps, como tambm Rastreabilidade e Continuidade de Servio de
TI.

2.1 Governaa de TI

A Governana pode ser entendida como um conjunto de normas, processos,


regulamentaes e polticas internas, definidas pela alta administrao, que ditam como a
empresa deve funcionar e ser controlada para garantir suas metas e seus objetivos. Essa viso
remete ao objetivo administrativo de obter melhores resultados, principalmente econmicos.
Porm, os desafios para fazer com que as empresas funcionem como um organismo
cooperativo so muito complexos. Alm disso, os seus integrantes devem estar concentrados
dentro de um alinhamento estratgico definido pela governana (LUNARDI, 2008).
Segundo o IBGC (1995),

Governana corporativa o sistema pelo qual as empresas e demais organizaes so


dirigidas, monitoradas e incentivadas, envolvendo os relacionamentos entre scios,
conselho de administrao, diretoria, rgos de fiscalizao e controle e demais partes
interessadas..

Observando a estrutura organizacional das empresas atuais, seja ela pequena, mdia ou
grande, possvel afirmar que elas so totalmente dependentes de tecnologia para se
manterem vivas frente a um mercado to exigente por qualidade nos produtos e servios que
so ofertados. (LUNARDI, 2008). Historicamente, a competio sempre levou as instituies
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 eficincia das suas rotinas de trabalho, revelando o setor de TI como pea
chave, visto que, muitas rotinas poderiam ser facilmente mapeadas e simplificadas em
sistemas.
Perante a esse cenrio to exigente, no qual o mercado seleciona os melhores e a
complexidade de gerir posta a prova, uma mudana estrutural passou a ocorrer dentro das
organizaes. Esta restruturao foi a capacitao da TI para os moldes de gesto, com o
intuito de ajudar na formulao de estratgias para obter vantagem competitiva.
15

O ITGI (2003, p. 10, traduo nossa) afirma,

Governana de TI da responsabilidade do Conselho de Administrao e Gesto


Executiva. uma parte integrante da governana corporativa e consiste nas estruturas
de liderana e organizacionais e processos que garantam que TI da organizao
sustenta e se estende a estratgias e objetivos da organizao..

Em muitas organizaes, a TI vista como mais um setor independente das aes que
so realizadas dentro da empresa, mas os seus gestores muitas vezes no compreendem que a
TI indispensvel para tomar qualquer atitude estratgica. Isso porque ela, metaforicamente,
passou a ser a espinha dorsal que interliga todas as reas, direcionando e tratando os estmulos
provenientes de todos os setores e tambm os regulamentando com os direcionamentos da
gesto. A Governana atua fornecendo informao a Gesto para a tomada de deciso e
auxilia na delegao das responsabilidades garantindo maior eficincia.
Segundo FILHO (2012, p.2),

A integrao da TI aos negcios faz com que a rea de TI se torne parceira


estratgica. As decises sobre os investimentos em TI so tratadas nas reunies de
planejamento estratgico pelo conselho administrativo da empresa. A TI deixou de ser
tratada por tcnicos e passou a ser incorporada na estratgia da empresa para alcanar
seus objetivos..

Dentro do tema proposto a governana nortear o trabalho, j que ela fornece a base
para garantir a qualidade nas atividades desempenhadas por qualquer equipe de TI.
Para atender aos critrios estabelecidos pela governana, faz-se necessrio o uso de
um framework de boas prticas como, por exemplo, o ITIL.

2.2 Framework ITIL

Os frameworks so esquemas, bibliotecas e abstraes fornecendo possveis solues


para um determinado problema. Essas estruturas genricas podem ser definidas como:

[...] uma abstrao de um domnio de aplicaes, a ser especializada em aplicaes


deste domnio. A principal caracterstica buscada ao desenvolver um framework a
generalidade em relao a conceitos e funcionalidades de domnio tratado. Alm disto,
fundamental que a estrutura produzida apresente as caractersticas 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 referncia das melhores prticas de gesto de
infraestrutura de TI para empresas pblicas e privadas. Foi criada, nos fins dos anos 80, pelo
16

Office of Government Commerce (OGC), rgo do governo britnico responsvel por manter
os livros que compem o seu framework. Atualmente est em sua terceira verso, agrupados
em cinco volumes (FILHO, 2012, p. 3-4).
O ITIL tem um paradigma orientado a servios, o que significa que toda a relao de
TI com as reas de negcio podem ser mapeadas, definindo polticas, estratgias e aplicando
melhorias contnuas (FILHO, 2012, p. 9). Neste contexto, o gerenciamento da TI baseado
em um conjunto de processos (boas prticas), que sero responsveis pelo bom
funcionamento da TI e das atividades na qual do suporte.
O objetivo do uso do ITIL est em aumentar a eficincia da rea de TI dentro do
negcio, maximizando a produtividade e consequentemente garantindo o Return On
Investment (ROI). Alm disso, a aplicao do padro na organizao traz consigo o Value On
Investimento (VOI), pois acaba impactando na melhoria dos processos que envolvem toda a
organizao. Para isso ele conta com algumas tcnicas de controle, que so as mensuraes e
auditorias gerenciais, guiando as operaes a andarem no ritmo que a organizao necessita
(OGC, 2007a, p. 132-140).
Uma caracterstica intrnseca que qualifica o uso do ITIL nesta pesquisa que ele pode
realizar a rastreabilidade dos processos que so gerenciados por ele. Isso assegura que o
mesmo pode sofrer uma otimizao para se adequar a necessidade da organizao, podendo
at mesmo, restaurar formas anteriores de trabalho caso se identifique alguma falha posterior.
Rastreabilidade, segundo a norma NBR ISO 8402 , [...] capacidade de recuperao
do histrico, da aplicao ou da localizao de uma entidade [...] por meio de identificaes
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 restaurao previamente identificado.
fundamental garantir o funcionamento de uma infraestrutura de TI confivel e mais
adaptvel as necessidades da empresa, atravs dos modelos de processos do framework ITIL.
Eles ainda enfatizam que o ITIL possui uma excelente orientao para o ciclo de vida de um
servio de TI. Porm, sua implementao nas organizaes acaba se tornando uma tarefa
rdua, sendo necessrio desenvolver procedimentos e ferramentas que se encaixam na
aplicao do processo, tornando-o prtico e eficaz (AIELLO; SACHS, 2014).
Como o foco do trabalho est na definio de um mtodo que garanta, de forma
padronizada e gil, a recuperao de servios de TI acometidos por um evento desastroso, se
fez necessrio explorar as definies e recomendaes, que so encontradas na Gerncia de
Continuidade de Servio de TI. Tambm foram avaliados os conceitos contidos na Gerncia
17

de Configurao, pois ela trata de fornecer informaes atualizadas sobre os ativos de TI


(hardware, software, licenas, entre outros) em uso.

2.2.1 Gerenciamento de continuidade de servios de TI

De acordo com a OGC, a continuidade de servio de TI trata da capacidade de anlise


de risco e recuperao de componentes essenciais para os servios de TI, depois de ocorrido
um evento de desastre como, por exemplo, falha de hardware, incndios, enchentes,
terrorismos, tempestades, vandalismos, blackouts e apages. Suas aes devem dar suporte e
ser planejadas acompanhando o gerenciamento de continuidade do negcio (OGC, 2007b, p.
125-132).
Esta gerncia est descrita na ITIL dentro de um domnio maior chamado de Desenho
de Servio. Segundo a OGC, trata de um modelo que enfoca os elementos de processos
envolvidos em identificar e introduzir aprimoramentos ao gerenciamento de servios. So
voltados para atividades repetveis, direcionando as organizaes a aprenderem a perceber
melhorias incrementais na qualidade de servio. Alm disso, oferece suporte a TI para se
adaptar a partir de qualquer planejamento que a empresa tome como direo (OGC, 2007b, p.
16-26).
Importante salientar a diferena entre desastre e incidente, o qual abordado por outro
processo do ITIL e que no faz parte desde estudo. O incidente se trata de paralisaes
temporrias ou queda da qualidade de servio, no impactando obrigatoriamente em toda
instituio (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 servio sempre ativo e que atenda as necessidades
atuais e futuras do negcio. (OGC, 2007c, p. 97). Sendo assim, este trabalho se concentra em
dar uma resposta aos riscos previamente identificados com o desenvolvendo de estruturas
automatizadas de retorno que garantam a continuidade dos servios.
Segundo o plano de continuidade de servios de TI descrito pelo ITIL, as perdas que
as empresas sofrem com o acontecimento de desastres, devem ser analisadas avaliando os
impactos que so gerados ao negcio. Estes servios precisam ser priorizados tendo como
referncia as atividades mais vitais. Em seguida deve ser feito a anlise dos riscos, pontuando
as possveis ameaas, que so descritas em suas vulnerabilidades, efeitos e contra medidas.
Sendo que de posse dessas informaes necessrio definir as estratgias de continuidade do
18

negcio, com as aes que devem ser tomadas mediante o acontecimento do desastre,
garantindo os requisitos mnimos de operao. Em outras palavras essas etapas vo definir o
plano de ao que deve ser seguido para retomar as operaes (OGC, 2007b, p. 128-137).
A implementao das medidas para minimizar os impactos devem seguir a orientao
do plano de ao e realizar testes simulados para evitar que os servios restaurados no
deixem de atender os requisitos mnimos para o seu funcionamento. Outro enfoque que deve
ser feito a otimizao do tempo de recuperao. Quanto menor o prazo de retorno, menos a
empresa arcar com prejuzos. Indiretamente isso pode levantar a necessidade de rever os
prazos acordados nos nveis de servio (SLA).
Uma das sadas que podem ser encontradas para auxiliar a retomada de operaes
descritas na continuidade de servio e que so abordadas por esse trabalho, so os processos
automatizados.

2.2.2 Gerenciamento de Configuraes e Ativos de Servio

O processo de gerenciamento de itens de configurao um processo que pertence a


fase de transio de servio.
Neste processo so administrados os itens de configurao dos servios. So
considerados itens de configurao, entre outros:
equipamentos;
softwares;
configuraes (setup);
relao entre itens de configurao;
os prprios servios.
Este processo tem sua importncia por manter o inventrio e os histricos sobre cada
item de configurao, permitindo que se possam guardar informaes sobre todos os
componentes utilizados pela TI. Sendo assim, a maioria dos processos de gerenciamento do
ITIL, recorrem base de dados da gerncia de configurao (BDGC) (OGC, 2007d, p. 65-84).
Em ambientes automatizados que seguem o framework ITIL o status dos itens de
configurao so atualizados automaticamente, atravs de testes automticos feitos via rede,
por exemplo, utilizando o sistema NAGIOS. Desta forma pode-se consultar quais itens de
configurao esto fora de produo, 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 configurao 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 fuso das palavras Desenvolvedor e
Operaes e foi popularizado atravs de uma srie de eventos chamados DevOps Days,
iniciados na Blgica em 2009. Seus idealizadores prope uma nova abordagem de trabalho,
buscando automatizar o mximo possvel os processos e quebrar as barreiras existentes entre
os setores de uma mesma empresa. Garantindo o aumento da colaborao entre as equipes na
troca de experincias e no compartilhamento de ferramentas. A ideia no perder tempo com
questes operacionais e rotineiras, dessa forma, os profissionais estaro focados na busca de
solues em suas respectivas reas, promovendo o papel que os gestores e demais colegas
realmente esperam que eles desenvolvam (DEVOPS, 2010).
Sua necessidade se mostrou mais aparente com o surgimento e aplicao das
Metodologias geis no trabalho das equipes de desenvolvimento, na qual aumentou a
demanda por deploys, que passaram a ser mais frequentes (entrega contnua). O que acabou
revelando um gargalo na publicao, rea essa de responsabilidade da equipe de
infraestrutura. Isso mostra claramente que as equipes evoluem em ritmos diferentes e a falta
de comunicao e contribuio entre elas muito grande. Com essa viso de integrao dos
times, o DevOps auxilia no gerenciamento e lanamento de novos produtos, isso porque o
processo pode ser totalmente automatizado e existe suporte maior para publicao. Existe
ainda o benefcio do processo ter que ser padronizado para que um nmero maior de
envolvidos interajam (SATO, 2013, p. 4-6).
Metodologia gil [...] uma nova forma de gesto e desenvolvimento de software que
usa uma abordagem de planejamento e execuo iterativa e incremental voltado para
processos empricos [...] (STEFFEN, 2012), aproximando o time de desenvolvimento ao de
negcios e que separa o produto em pequenos problemas, de modo que, seja possvel entregar
continuamente partes funcionais. Possui outras caractersticas como: a comunicao face-to-
face; reduo dos riscos associados s incertezas dos projetos; abraar e responder s
mudanas de forma mais rpida e natural, com intuito de atender da melhor forma as
expectativas dos clientes, por meio da adoo de prticas de gesto e de Engenharia de
20

Software com foco nos valores e princpios do Lean (sistema Toyota de produo)
(STEFFEN, 2012). Seu principal objetivo entregar um produto que o cliente realmente
deseja, usvel (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 gerncia dos processos e gerao de relatrios granulares. O desenvolvedor
ganha maior autonomia em relao ao ambiente que hospeda os servios, e a infraestrutura
maior compreenso sobre as aplicaes que ele administra. Mesmo que j exista previamente
alguma parte do processo j automatizado, essas rotinas muitas vezes no tem uma
flexibilidade desejada, pois possuem implementaes muito amarradas e dependentes de
outras estruturas.
Empresas que aplicaram essas prticas de DevOps com sucesso no enxergam mais
o departamento de TI como um gargalo, mas sim como um agente de capacitao do
negcio. (SATO, 2013, p. 6).
Os principais fundamentos DevOps extrados de seu manifesto podem ser expressos
de forma resumida (DEVOPS, 2010):
Avaliao: so as mtricas, medies, verificao de performance, logs e
integrao;
Automao: facilitar os processos repetitivos no deploy, controle, monitorao,
gerncia de configurao e orquestrao;
Compartilhamento: assuntos relacionados a feedback e comunicao entre a
equipe.
Cultura: envolve colaborao, fim das divises, relao saudvel entre as reas e
mudana de comportamento;
Dentre as caractersticas citadas, as de comunicao entre a equipe, colaborao e
automao foram as mais utilizadas na aplicao do estudo de caso.

2.3.1 Automatizao de Processos de Infraestrutura de TI

O termo automatizao remete aos conceitos industriais baseados em mquinas com a


capacidade de executar e controlar tarefas em sequncia sem a interveno humana
(KUIAWINSKI; LUZ, 2006). Seguindo essa linha, a automatizao da infraestrutura de TI
pode ser compreendida como um processo de planejar e descrever instrues para serem
21

tratadas por um software de gerncia de configurao, responsvel por interpret-las e


execut-las. O script tem a capacidade de conter comandos desde a instalao de um sistema
operacional at executar complexas configuraes para prover um servio. Portanto a
infraestrutura de TI e sua configurao sero descritas como um conjunto de scripts, para que
os ambientes sejam reproduzidos de forma menos propensa a erros.
Apesar dos conceitos DevOps no 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 necessrio combinar 3 tipos de ferramentas:
orquestradores, que invocam aes em tempo real em servidores distintos; gerenciadores de
configurao, que facilitam a administrao e criao de novos ambientes alm de centralizar
as informaes; provisionamento, que ajudam na instalao dos sistema operacionais tanto em
ambientes fsicos quanto virtuais.
Como o estudo se tornaria muito grande analisando cada tipo de ferramenta, os
esforos foram concentrados em uma que atendesse a gerncia de configurao, j que ela
demonstraria melhor os impactos dentro da continuidade de servio.
Na pesquisa realizada, foram encontradas algumas ferramentas que seguem o
propsito DevOps, no que diz respeito a dar suporte automao da infraestrutura de TI,
podendo ser aplicadas em ambientes na nuvem, virtuais ou fsicos. Entre elas esto:
Ansible (ANSIBLE, 2016): Os seus parmetros so definidos para um grupo de
hosts. Sua comunicao feita atravs de SSH, o que dispensa a necessidade de
agentes. Escrito em Python e utiliza o YAML ( um tipo de codificao de dados
mais legvel para seres humanos) para descrio das configuraes. Disponvel na
verso Tower e Community;
Chef (CHEF, 2016): Modelo cliente servidor, que utiliza agentes nos hosts para
aplicar as configuraes. Seus cdigos so descritos em forma de recipes e so
agrupadas em cookbooks, utilizando a linguagem Ruby e uma DSL prpria.
Disponvel na verso Enterprise e Community;
Puppet (PUPPET, 2016): Modelo cliente servidor, que utiliza agentes nos hosts
para aplicar as configuraes. Possui linguagem prpria e foi desenvolvido em
Ruby. Disponvel na verso Enterprise e Community;
Para o estudo de caso, foi adotado o Puppet, pelo fato de ser um software que possui
uma boa documentao e uma comunidade ativa que sempre disponibiliza atualizaes e
novos mdulos. Sua instalao muito simples, tanto do servidor quanto dos agentes que so
executados nos clientes. Outro ponto que influenciou sua escolha est na declarao das
22

instrues utilizando sua linguagem especfica de domnio (DSL). Por ser muito intuitiva, ela
acaba sendo de fcil interpretao para os administradores de sistema, sendo diferente, por
exemplo, da utilizada pelo Chef (outra ferramenta similar), na qual sua escrita mais
apropriada para programadores.
O Puppet foi escrito em Ruby e distribudo como um software livre sob a Licena
Pblica Geral (GPL) pelos seus criadores. Nele possvel automatizar todos os passos do
processo de entrega de software, desde o provisionamento de mquinas fsicas e virtuais para
orquestrao at relatrios (PUPPET, 2016).
Resumidamente, o Puppet uma ferramenta de automatizao de gerncia de
configurao. Funciona utilizando um servidor principal (Puppet Master), que centraliza as
configuraes (facts) entre os servidores (nodes) e os organiza pelo tipo no seu repositrio
(catalog). O seu agente (Puppet Agent) executado como um processo independente nos
clientes, permitido implementar mudanas de infraestrutura em vrios ns 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 cdigo. Como se trata de textos e
instrues 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 instalao do sistema operacional,
passando pela configurao dos seus servios, at sua publicao, um trabalho muito
dispendioso, ainda mais sendo feito manualmente, inserindo mdias, copiando arquivos e
executando instrues. Em contra partida, criar o mesmo servidor, com as mesmas
caractersticas atravs 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 flexvel, escalvel e sem a necessidade de acrscimos de pessoal.
De maneira geral o objetivo dessas ferramentas liberar tempo para os profissionais se
dediquem em projetos que oferecem mais valor de negcio, garantir a coerncia, fiabilidade e
estabilidade e Facilitar a colaborao mais estreita entre os administradores de sistemas e
desenvolvedores.
23

3 ESTUDO DE CASO

Neste captulo ser descrito o ambiente do estudo de caso, o processo atual e a soluo
encontrada, provando que a implementao mais confivel e eficaz.
O estudo analisou o processo de trabalho que realizado em uma instituio municipal
governamental que prov servios de tecnologia para os demais rgos ligados a sua
organizao. A fim de mapear os processos mais crticos de provisionamento de ambientes e
aplicar conceitos e ferramentas DevOps para otimizar a produtividade na recuperao de um
servio.

3.1 Ambiente do estudo de caso

O Centro de Informaes de Dados de Campos (CIDAC) uma superintendncia da


Prefeitura Municipal de Campos dos Goytacazes responsvel pela rea de tecnologia de
informao. Suas principais atribuies vo desde a elaborao de polticas de tecnologia de
informao, passando por servios de geoprocessamento, elaborao de termos tcnicos,
desenvolvimento de soluo de software e a distribuio do link de internet para os principais
rgos municipais por meio de um anel de fibra ptica. Sua principal funo descrita em sua
misso: Prover solues tecnolgicas de informao e comunicao integradas e inovadoras
para uma gesto pblica eficiente e colaborativa, que reflitam na melhoria de vida da cidade e
dos cidados. (PMCG, 2016).
O CIDAC dispe de um corpo tcnico de 10 analistas, sendo que 7 atuam na equipe de
desenvolvimento, criando solues de software e 3 trabalham na equipe de infraestrutura,
garantindo o funcionamento de toda a rede de dados e configurao dos servidores.
A instituio possui uma sala site prpria para processamento de dados bastante
heterognea, composta por 13 servidores fsicos e 35 servidores virtuais com diferentes
sistemas operacionais. Esta estrutura responsvel por oferecer diversos servios de TI, em
que muitas dessas aplicaes so desenvolvidas pelo prprio rgo, destacando as ilhas de
produo utilizando as linguagens de programao PHP e Rails.
Dentre toda essa estrutura, foi selecionado para estudo, o ambiente de produo dos
sistemas feitos com Rails, que um framework para desenvolvimento de software (RUBY
ON RAILS, 2016). Esta escolha atribuda ao fato de que existem mais profissionais atuando
24

com a linguagem dentro da instituio e que frequentemente so lanadas novas verses para
as aplicaes, alm de envolver o uso de 5 servidores em sua infraestrutura de funcionamento.

3.2 Sobre o problema

Sero descritos a seguir os problemas relacionados ao provisionamento e restaurao


de ambientes produtivos de infraestrutura de TI, mapeados nesse estudo, para propor
possveis melhorias na continuidade de servio. O levantamento dos dados referentes aos
eventos foi feito atravs de entrevistas aos integrantes das equipes, isto porque o rgo no
mantem uma base de conhecimento e nem registros histricos de desastres.
A equipe de infraestrutura responsvel diretamente pelo provisionamento dos
ambientes e servios. No entanto, necessita de 2 analistas da equipe de desenvolvimento, os
quais so os nicos que conhecem todos os passos para construir novos ambientes Rails.
Esses analistas tambm possuem autonomia para alterar as configuraes desses servidores.
Contudo, as mudanas que ocorrem no ambiente no so rastreveis, o que dificulta
identificar se alguma atualizao ou configurao impactou no bom funcionamento dos
sistemas.
As configuraes so realizadas manualmente e com pouca frequncia. Dessa forma,
existe o risco de algumas instrues serem esquecidas, gerando ambientes defeituosos e que
precisam ser corrigidos. Impactando na disponibilizao do servio em produo
rapidamente. Este tipo de risco, decorrente de falha humana, foi identificado nos ltimos
eventos realizados pelos profissionais responsveis pela restaurao do servio.
Estas questes influenciam negativamente no tempo de recuperao e na qualidade do
ambiente aps um evento de desastre.
As falhas mais recorrentes identificadas so as quedas de energia. Porm, as que
causaram maior impacto foram as ocasionadas por falha de hardware nos servidores,
paralisando totalmente a operao dos servios da instituio. Em um desses eventos
desastrosos, podemos destacar um servio que levou trs dias para ser restabelecido. O
agravante se deu pelo fato de se tratar de um servidor que hospedava uma aplicao de
tramitao de documentos que envolvia toda organizao. O tempo foi elevado porque a
equipe no possua informaes suficientes para instalar e configurar o servio em outro
equipamento, mesmo de posse dos arquivos de backup. Alm paralisar o trabalho dos
servidores pblicos, a falha impediu indiretamente o atendimento aos cidados.
25

Partindo destes problemas, sero descritos a seguir os mtodos e solues


desenvolvidas para minimizar o esforo de recuperao de servios para esse estudo de caso.

3.3 Procedimentos

Este trabalho no seria possvel sem a unio das concepes de governana e DevOps,
sendo que a parte que cabe governana : o que fazer, e para o DevOps a incumbncia :
como fazer.
Os procedimentos aplicados ao estudo de caso para alcanar os objetivos deste
trabalho so descritos seguindo a metodologia:
(I) Inicialmente foi feito a escolha do ambiente. Foram selecionados ambientes que
sofrem frequentes modificaes nas configuraes e que geram risco ao negcio em caso de
falhas. Outro fator levantado em conta foi a verificao da frequncia com que ocorre a
indisponibilidade. A avaliao foi executada em conformidade com o framework ITIL no que
se diz respeito a continuidade de servio.
(II) A prxima etapa teve como objetivo contabilizar o tempo mdio gasto para
concluir as configuraes e o perodo de indisponibilidade dos servios 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 mtodo dedutivo com auxlio do framework ITL
para identificar a existncia de rastreabilidade das mudanas que foram realizadas no
ambiente produtivo. Foi verificado tambm se era possvel restaurar um servio no mesmo
estado em que se encontrava antes de ocorrer a indisponibilidade ou catstrofe. A execuo
desta etapa foi importante para descrever com mais preciso o estudo de caso.
(IV) Aps a identificao da rastreabilidade foi selecionado as caractersticas da
cultura DevOps que melhor se adequam aos objetivos propostos nesta temtica. Foi escolhida
uma ferramenta, que proporcionasse maior facilidade e velocidade na adoo da metodologia,
de modo que, pudesse interagir diretamente com a infraestrutura de servios de TI.
(V) A quinta etapa se caracterizou em contabilizar o tempo gasto para instalar ou
restaurar um servio aps aplicar a metodologia. Este procedimento foi executado mais de
uma vez em um servio construdo para simular a queda do ambiente produtivo, o qual foi
selecionado nas etapas anteriores.
(VI) De posse de todas as informaes coletadas foi verificado se a forma de trabalho
sugerida pelo DevOps garantiu a continuidade do servio. Analisaram-se os resultados
26

extrados antes da utilizao da metodologia, comparando-os com os resultados obtidos aps


o experimento.
(VII) Alm disso, foi analisado se a equipe poderia ficar mais confortvel e segura
para realizar suas atividades com qualidade, e apresentar um melhor desempenho para atender
rea de negcio.
(VIII) O estudo de caso foi finalizando com a descrio da experincia obtida,
revelando os seus resultados.

3.4 Soluo Implementada

Nesta etapa do trabalho foram utilizadas duas caractersticas importantes da


metodologia DevOps para desenvolver a soluo do problema: a colaborao entre as equipes
e a automatizao de atividades repetitivas. Alm disso, sero combinados a elas os
direcionamentos do framework ITIL.
A colaborao entre as equipes foi primordial na elaborao da soluo,
principalmente dos profissionais diretamente envolvidos no problema estudado. A equipe de
infraestrutura forneceu informaes sobre segurana da informao e componentes
responsveis pela operao do ambiente produtivo. Os detalhes tcnicos e peculiaridades
referentes ao uso do Rails na instituio foram identificados e obtidos com o setor de
desenvolvimento de software. Todos os elementos foram organizados e estruturados para
entender o que necessrio para o provisionamento adequado do ambiente e implantao do
servio.
A automatizao do procedimento de instalao do ambiente produtivo um
componente essencial neste processo. Ento, as especificaes do servio foram
transformadas em instrues, conforme o Apndice Cdigo fonte de implementao do
Puppet, possibilitando o ganho de velocidade da equipe.
No experimento foram utilizadas duas mquinas virtualizadas, sendo uma delas o
servidor Puppet Master, que contm o cdigo com as definies do ambiente e a outra a
mquina com o agente Puppet e que recebeu as configuraes (PUPPET, 2016).
Com o intuito de simplificar o laboratrio, a mquina alvo j possua um sistema
operacional Linux instalado, dispensando o uso de uma ferramenta de orquestrao. O motivo
pelo qual se utilizou a virtualizao no trabalho foi para simular com mais facilidade as
situaes de desastre.
27

Na simulao, a mquina alvo, que possui o servio Rails implementado, teve sua
instncia destruda para emular os efeitos de um desastre. A partir deste momento, foi iniciado
o processo de restaurao, aguardando o servidor Puppet aplicar automaticamente as
configuraes pr-estabelecidas. Esta ao foi realizada diversas vezes para analisar o
ambiente resultante e coletar informaes sobre a aplicabilidade do mtodo e seu tempo de
resposta.
Uma vez que a prova de conceito de uma recuperao e provisionamento automtico
foi desenvolvida atravs da ferramenta, avaliou-se a contribuio das caractersticas da
metodologia DevOps, que foram citadas no incio deste tpico, para alcanar os objetivos do
gerenciamento de continuidade de servio descritos neste trabalho. Os resultados obtidos pela
soluo so explicados na prxima seo.

3.5 Resultados

A construo de um ambiente de produo para aplicaes Rails atravs de um


processo automatizado com uma ferramenta DevOps gerou resultados satisfatrios e sero
apresentados neste tpico.
Com o auxlio do Puppet na recuperao do ambiente no houve interrupes no fluxo
de trabalho. Diferente do que se percebeu na anlise do cenrio original, na qual a execuo
manual acabou tendo algumas interrupes e desvios de mo de obra para atender outras
atividades distantes do propsito inicial.
Durante todas as simulaes automatizadas, a ferramenta seguiu rigorosamente todas
as etapas do procedimento. Os pacotes necessrios foram instalados, verificou as
dependncias e aplicou as configuraes que foram definidas. Ou seja, todo ambiente de
produo provisionado dessa forma adquiriu todas as especificaes que foram determinadas.
Por outro lado, a execuo manual do procedimento resultou em um ambiente de produo
diferente em cada simulao. Isto aconteceu mesmo sendo realizado pela mesma pessoa, o
que significa que o procedimento foi interpretado de forma distinta a cada iterao.
A interveno manual na recuperao do servio apresentou variaes na execuo,
seja por esquecimento ou interpretao equivocada em algum dos passos do procedimento,
enquanto o processo automatizado no gerou erros, o que torna a segunda abordagem mais
eficaz. Em outras palavras, eliminou este ponto fraco no processo, entregando um servio
confivel.
28

Outra preocupao do gerenciamento de continuidade o tempo de recuperao do


servio. Este item tambm obteve um resultado interessante, porque foi possvel reduzi-lo
significantemente. Enquanto que a realizao manual de todos os passos do procedimento
dura em torno de 150 minutos, na ferramenta a situao foi bem diferente, a concluso da
rotina gastou cerca de 3 minutos, cumprindo com mais facilidade os prazos. Alm disso,
contribuiu para uma futura reviso do SLA estipulado para esse servio.
Os testes da estrutura de recuperao do servio uma atividade da gerncia de
continuidade que tambm foi possvel trabalhar melhor. A partir do momento a rotina passou
a ser executada com mais facilidade em um espao de tempo bem menor, a frequncia dos
testes do plano de contingncia foi ampliada e os seus resultados podem ser obtidos a
qualquer momento.
O fato da ferramenta que automatiza a gerncia de configurao versionar os cdigos
da estrutura, possibilitou rastrear e garantir que a infraestrutura retornasse para o ponto
desejado.
Conforme descrito no tpico anterior, os conhecimentos das pessoas que participam do
processo atual foram previamente mapeados atravs da metodologia DevOps e consolidados
no mecanismo de automatizao. Isto permitiu que a rotina adquirisse condies suficientes
para executar todo processo com menos dependncia das pessoas, o que implicou em um
nmero reduzido de profissionais envolvidos para recuperar o servio aps 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


Descrio Antes da implementao Aps implementao
(Processo Manual) (Processo DevOps)
Rastreabilidade e As mudanas no podem ser As mudanas nas
Versionamento rastreadas nem versionadas. configuraes so
versionadas o que possibilita
a restaurao do servio a
partir do ponto desejado
(infraestrutura como cdigo).
Tempo de recuperao Alto podendo chegar a Muito Muito baixo. Possibilidade
Muito Baixo: < 30min. Alto se o especialista no de reduo do SLA.
Baixo: < 60min.
estiver presente.
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 servio)
ausncia dos especialistas o restaurao, j que o
Muito Ruim: 0% at 25%.
trabalho interrompido. processo simplificado com
Ruim: 26% 49%
Bom: 51%. < 75%. auxlio de uma ferramenta.
Excelente 76% < 100%.
Padronizao Pouca Padronizao. Mesmo Padronizao Moderada. S
Ausente: processo manual os passos sendo descritos por existe uma maneira de
realizado aleatoriamente.
um script detalhado, o executar a restaurao, mas o
Pouca: processo manual que segue
processo no tem garantias. processo necessita ser
passos descritos em um modelo.
Moderada: processo automatizado, Pode haver modificaes dos iniciado e acompanhado por
assistido por um operador. passos por quem implementa. um operador.
Alta: sem a interveno humana.
Confiabilidade do ambiente Alto Risco. Os resultados Baixo risco. Os resultados
Baixo Risco: apresenta sempre os podem no ser os mesmos so previamente testados e
mesmos resultados.
desejados pelo negcio por garantidos por um processo
Alto Risco: pode apresenta
se tratar de um processo padronizado e automatizado.
resultados diferentes.
manual.
Fonte: elaborao prpria
30

4 CONCLUSO

Observou-se que os resultados obtidos com a implementao de algumas atividades


preconizados pelo ITIL, atravs da abordagem DevOps, incrementam a qualidade, e
melhoraram a continuidade dos servios de TI, quando comparados a processos manuais.
Supondo que os dois modelos confrontados seguem os mesmos passos para soluo de um
problema. Dessa forma foi possvel demonstrar que o ITIL e o DevOps so compatveis e que
juntos reduzem, significativamente, o tempo de retorno de aplicaes paralisadas por algum
tipo de desastre.
Nesta pesquisa, a colaborao entre as equipes e a automao de processo foram as
caractersticas da metodologia DevOps que apoiaram com sucesso a implementao de uma
estrutura de retorno dos servios, minimizando os impactos causados por um desastre. Do
mesmo modo que a metodologia favoreceu as atividades do gerenciamento de continuidade
dos servios de TI, sua aplicao poderia ser estudada para tambm reduzir o esforo em
outros processos e fases do ITL.
A soluo implementada para o estudo de caso entregou um servio confivel e que
garante o funcionamento da rea de negcio. Assim como a instituio citada na pesquisa se
beneficiou dos resultados obtidos, esta soluo pode ser usada como referncia por outras
organizaes governamentais.
Vale destacar tambm que o tema pouco difundido entre os profissionais TI e pode
ampliar os conhecimentos sobre uma mudana de cultura que elevem sua capacidade de
gerenciamento e a facilidade de lidar com grandes estruturas de servios de TI.
Foi notado durante o experimento, o potencial da automao de processos de
gerenciamento de continuidade de servio de TI na melhoria da elaborao de planos de
contingncia. Possibilitando a realizao de uma futura pesquisa envolvendo a integrao de
ferramentas de monitoramento de servio com o processo de restaurao automatizada. Ou
seja, dependendo do tipo de desastre e se ele foi mapeado pelo plano de continuidade de
servio, no seria necessrio acionar uma equipe de suporte, as prprias ferramentas poderiam
se encarregar de restaurar os servios.
31

REFERNCIAS

ABNT. NBR ISO 8402: Gesto 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. Disponvel em: <http://www.ibm.com/developerworks
/library/d-implement-itil-devops>. Acesso em: 15 nov. 2015.

ANSIBLE. Overview: How Ansible works. 2016. Disponvel em: <https://www.ansible.


com/how-ansible-works>. Acesso em: 10 jan. 2016.

CHEF. All about Chef. 2016. Disponvel em: <https://docs.chef.io>. 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. Disponvel em: <http://theagile
admin.com/what-is-devops/>. Acesso em: 10 jul. 2015.

DURVALL, Paul. Agile DevOps: Automao de infraestrutura. IBM: DevelopersWorks. Out.


2012. Disponvel em: <http://www.ibm.com/developerworks/library/d-implement-itil-dev
ops>. Acesso em: 16 nov. 2015.

FILHO, Felcio Cestari. ITIL v3 Fundamentos. Escola Superior de Redes: Rio de Janeiro,
2012. Disponvel em: <http://pt.scribd.com/doc/50809607/ITIL-v3-Fundamentos>. 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. Mecanizao, Autonomao e


Automao Uma Reviso Conceitual e Crtica. In SIMPSIO DE ENGENHARIA DE
32

PRODUO, 13., 2006, Bauru. Disponvel em: <http://www.simpep.feb.unesp.br/


anais/anais_13/artigos/1210.pdf >. Acesso em: 12 de jan. 2016.

LUNARDI, Guilherme Lerch. Um estudo emprico e analtico do impacto da Governana de


TI no desempenho organizacional. 2008. Tese (Doutorado em Administrao) Universidade
Federal do Rio Grande do Sul, Porto Alegre, 2008. Disponvel em: <http://www.
lume.ufrgs.br/bitstream/handle/10183/13248/000642838.pdf?sequence=1>. Acesso em: 01 de
fev. 2016.

INSTITUTO BRASILEIRO DE GOVERNANA CORPORATIVA (IBGC). Governana


Corporativa. So Paulo: IBGC, 1995. Disponvel em: <http://www.ibgc.org.br/inter.php?
id=18161> . Acesso em: 03 de fev. 2016.

IT GOVERNACE INSTITUTE (ITGI). Board briefing on IT governance. 2. ed. Rolling


Meadows: ITGI, 2003. Disponvel em: <http://www.isaca.org/knowledge-center/research/
researchdeliverables/pages/board-briefing-on-it-governance-2nd-edition.aspx>;. Acesso em:
29 jan. 2016.

MUELLER, Ernest. A DevOps Manifesto. The agile admin. Out. 2010. Disponvel em:
<http://theagileadmin.com/2010/10/15/a-devops-manifesto>. Acesso em: 10 jul. 2015.

OFFICE OF GOVERNMENT COMMERCE (OGC). ITIL: Continual Service Improvement.


Londres: TSO, 2007.

_______. ITIL: Service Design. Londres: TSO, 2007.

_______. ITIL: Service Operation. Londres: TSO, 2007.

_______. ITIL: Service Transition. Londres: TSO, 2007.

PREFEITURA MUNICIPAL DE CAMPOS DOS GOYTACAZES (PMCG).


Superintendncia do Centro de Informaes de Dados de Campos. Misso, Viso e Valores.
2015. Disponvel em: <http://cidac.campos.rj.gov.br/missao-visao-e-valores/>. Acesso em: 10
out. 2015.

PUPPET. What is Puppet?. 2016. Disponvel em: <https://puppetlabs.com


/puppet/what-is-puppet>. Acesso em: 14 mar. 2016.

RUBY ON RAILS. Rails. Disponvel em: <http://rubyonrails.org>. Acesso em: 15 fev. 2016.
33

SATO, Danilo. DevOps na prtica: entrega de software confivel e automatizada. So Paulo:


Casa do Cdigo, 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 Informtica/UFRGS, v.2, 1998,
pp. 298-309, Torres, Rio Grande do Sul. Disponvel em: <http://www.inf.ufsc.br/~ricardo/
publications/Ideas98.PDF>. Acesso em: 11 jan. 2016.

STEFFEN, Juliana Berossa. O que so essas tais de metodologias geis?. IBM:


DevelopersWorks. Jan. 2012. Disponvel em: <https://www.ibm.com/developerworks/
community/blogs/rationalbrasil/entry/mas_o_que_s_c3_a3o_essas_tais_de_metodologias__c3
_a1geis?lang=en>. Acesso em: 09 set. 2015.
34

APNDICE A Cdigo fonte de implementao do Puppet

# Configurao para montagem de Servidor Rails


node "puppetnode01" {

# Removendo pacotes desnecessarios


$packages_to_remove = ['bsd-mailx', 'exim4', 'exim4-
base', 'exim4-config', 'exim4-daemon-light', 'mutt',
'procmail']
package { $packages_to_remove:
ensure => 'purged',
}

# Instalando pacotes para suporte.


$admin_packages = ['vim', 'htop', 'nmap', 'tcpdump',
'ntpdate', 'curl']
package { $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,
35

require => Package['monit'],


}

file { 'rails.conf':
path => '/etc/monit/conf.d/rails.conf',
owner => 'root',
group => 'root',
mode => '0700',
content => 'include /home/deployer/apps/*/shared/
config/monit',
require => Package['monit'],
notify => Service['monit'],
}

# Adicionando usuario responsavel pelas aplicacoes


user { 'deployer':
ensure => 'present',
managehome => true,
home => '/home/deployer',
password =>'$6$PNPiIH1m$3C8IoXlML4MTwupA3cQfiPeVf
fkkDH2JRrWWfeNWfYN.CnHWt1bLlj1qKebg1Bh12Fk4Z3Cr0zub
TxPYgZtNo1',
shell => '/bin/bash',
uid => '1001',
}

file { '/home/deployer/apps':
ensure => 'directory',
owner => 'deployer',
group => 'deployer',
mode => '0755',
require => User['deployer'],
}
36

# Instalando o rvm
exec { 'rvm-gpg-import':
command => 'curl -sSL https://rvm.io/mpapis.asc |
gpg --import -',
path => '/usr/local/sbin:/usr/local/bin:/usr/
sbin:/usr/bin:/sbin:/bin',
user => 'deployer',
environment => ['HOME=/home/deployer'],
logoutput => true,
}

exec { 'rvm-install':
command => 'curl -L https://get.rvm.io | bash s
stable',
path => '/usr/local/sbin:/usr/local/bin:/usr/
sbin:/usr/bin:/sbin:/bin',
user => 'deployer',
environment => ['HOME=/home/deployer'],
logoutput => true,
require => Exec['rvm-gpg-import'],
}

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

service { 'nginx':
ensure => 'running',
enable => true,
require => Package['nginx'],
}

Você também pode gostar